Segurança de Rede - Linux

Introdução
A cada dia novos usuários de Linux surgem todos os dias, e graças à facilidade de acesso à Internet nos dias atuais a maior parte deles conecta suas máquinas pessoais a redes abertas sem maiores dificuldades.

Sabendo que o Linux é um sistema capaz de ser administrado remotamente, e que muitas configurações default de distribuições habilitam muitos processos servidores para iniciar automaticamente após a instalação, estes novos usuários acabam se transformando em uma ameaça a si próprios, pois expõem à Internet uma máquina aberta, devido à sua falta de conhecimento técnico.

Para piorar a situação, há abundância de textos sobre "segurança" disponíveis na internet, "ensinando" que para garantir uma configuração segura da sua máquina, tudo o que você tem a fazer é "comentar as linhas do inetd.conf", um conselho enganoso.

Primeiros passos

A segurança começa pela instalação do seu sistema Linux. Se você tem uma máquina sem configurações especiais de segurança e quer torná-la segura, uma opção interessante é reinstalá-la completamente, suprimindo assim qualquer erro que tenha sido cometido no passado; lembre-se que uma máquina invadida e onde estranhos obtiveram privilégios de superusuário jamais poderá ser considerada segura novamente, exceto se totalmente reinstalada a partir de uma mídia original (e se você corrigir as falhas que permitiram a invasão original).

Ao instalar o sistema, lembre-se dos seguintes itens:

*Só exponha o sistema à Internet após completar todos os procedimentos de segurança. Há muitos relatos de máquinas invadidas durante o processo de configuração inicial, graças a administradores que preferem confiar na sorte;
*Se a sua distribuição permitir, opte por uma instalação personalizada, e escolha apenas os pacotes que você sabe que irá usar. É muito fácil adicionar pacotes posteriormente, e será sempre um alívio quando você receber e-mail do seu fornecedor recomendando um upgrade urgente de segurança do servidor de Real Audio, e em seguida perceber que não precisa fazer nada a respeito pois não o instalou;
*Monte seu esquema de partições adequadamente. Se você for rodar algum serviço que gere armazenamento de dados em disco (uma proxy web, um servidor de mail, um servidor de news...), certifique-se de criar uma partição separada para o /var, evitando assim que os arquivos dos seus processos servidores possam lotar o espaço de armazenamento da máquina, tirando-a de operação (coisa que normalmente só pode ocorrer em caso de má configuração dos servidores, mas não há por que não levar a sério esta possibilidade);
*Após instalar todos os pacotes, instale todas as atualizações de segurança disponíveis no web site do seu fornecedor. Assine a lista de divulgação de novas atualizações, se disponível;
*Habitue-se a visitar sites de segurança para saber as novas vulnerabilidades a que você pode estar exposto.

Serviços desnecessários

Uma instalação padronizada de sistema operacional costuma habilitar uma série de serviços dos quais você não precisa, e que podem vir a servir como ponto de acesso para um invasor. Removê-los é relativamente fácil, e um passo essencial.

Editar corretamente o arquivo /etc/inetd.conf é básico. Este arquivo define quais os serviços básicos de internet estarão habilitados na sua máquina, e portanto acessíveis a partir de outras máquinas. Verifique atentamente quais destes serviços estão habilitados, e retire os que você não tiver uma boa justificativa para manter. Na dúvida, retire!

Retirar um serviço do inetd.conf é simples, basta acrescentar um caracter # no início da linha, transformando-a em um comentário. Se posteriormente você precisar habilitar novamente o serviço, basta retirar o #.

Máquinas domésticas em geral não precisam de nenhum serviço habilitado no inetd.conf, e podem até mesmo deixar de carregar o serviço inetd (inetd) na inicialização. Usuários de serviços online (como o irc) podem querer habilitar apenas o serviço auth. Não se deixe enganar pela ilusão de rodar servidores telnet, ftp e finger na sua máquina doméstica, exceto se você realmente tiver uma boa justificativa.

Após definir a sua configuração do inetd.conf, reinicie o processo do inetd, comandando killall -HUP inetd

Em seguida, você precisa verificar os serviços de rede standalone, que não são gerenciados pelo inetd.conf, mas sim pelos init scripts, de modo geral localizados abaixo do diretório /etc/rc.d. Cada distribuição de Linux lida com estes scripts de uma maneira um pouco diferente, então você terá que ler um pouco da documentação da sua preferida. Ferramentas como o ntsysv, o ksysv e o tksysv podem ajudar, e a sua distribuição pode ter oferecido algum outro pacote adicional que permita selecionar os scripts facilmente.

De modo geral, os init scripts definem quais serviços serão inicializados no momento do boot. Alguns serviços são aparentemente inócuos do ponto de vista de uma possível invasão (e.g. sound, random, apmd), enquanto outros claramente oferecem algum raio de ação para o potencial invasor (e.g. portmap, xntpd, netfs, rstatd, rusersd, rwalld, rwhod, bootparamd, squid, yppasswd, ypserv, dhcpd, snmpd, named, routed, lpd, gated, httpd, xfs, linuxconf e muitos outros).

Ao definir quais scripts você executará no boot, use o mesmo critério da seleção dos serviços do inetd; na dúvida, retire - se mais tarde você precisar, adicione novamente (após avaliar o impacto sobre a segurança). Particularmente evite rodar o servidor do linuxconf, rstatd, rusersd, rwalld, rwhod, os serviços do NIS (yp*) e os daemons de roteamento (como o gated). Se você for rodar um servidor web para uso interno, ou para testes, certifique-se de configurá-lo para aceitar requests apenas da sua rede interna, ou de sua máquina pessoal - segurança de servidores não será coberta neste texto.

Cuidado ao mexer nos scripts de inicialização

Leia sempre a documentação antes, e tenha à mão um disquete de inicialização completa, como o tomsrtbt para emergências, já que provavelmente o disquete de boot gerado durante a sua instalação do Linux não resolverá o problema. Outra boa dica é aprender a iniciar o sistema em modo monousuário quando tudo falhar.

Detalhes

*Desenvolva uma estratégia de backups confiável;
*Instale ferramentas de análise e rotação de logs;
*Instale ferramentas de garantia de integridade, como o tripwire (principalmente nos servidores);
*Certifique-se de estar usando shadow passwords (nada de senhas criptografadas visíveis no /etc/passwd - este recurso já vem habilitado como default em algumas das distribuições);
*Se você estiver com o servidor de ftp habilitado, configure-o adequadamente; não permita o acesso de root, restrinja a árvore de diretórios, reveja os direitos de acesso anônimos, considere a possibilidade de as senhas de acesso estarem sendo monitoradas em sua rede local;
*Desabilite o telnet e o ftp. Se você precisar deste tipo de serviço, use o ssh (tanto para login quanto para transferência de arquivos);
*Habilite os tcp wrappers (tcpd) e configure adequadamente os arquivos de restrição e permissão de acesso (em geral, /etc/hosts.deny e /etc/hosts.allow);
*Habilite filtros de pacotes (usando ipfwadm, ipchains ou a ferramenta que estiver disponível na sua versão);
*Não permita que outras máquinas iniciem conexões com a sua, exceto para as portas que você explicitamente definir;
*Bloqueie o acesso às portas dos seus serviços locais (xfs, X, servidor web utilizado para testes...).

Monitoração remota (RMON)

A monitoração emota (RMON) é uma especificação padrão de monitoração, que habilita vários sistemas e console e monitores de rede para o intercâmbio de dados de monitoração de rede. A RMON proporciona aos administradores de rede maior liberdade para seleção de consoles e sondas de monitoração com características que satisfaçam às necessidades específicas de suas redes.

A especificação RMON define um conjunto de estatísticas e funções que podem ser permutadas entre sondas de rede e gerentes de console compatíveis com a RMON. Dessa maneira a RMON, proporciona aos administradores uma diagnose abrangente de falhas na rede, planejamento e informações para o ajuste de desempenho.

Grupos RMON

A RMON fornece informações em nove grupos RMON de elementos de monitoração, cada um oferecendo conjuntos específicos de dados para atender às necessidades de monitoração de rede. Cada grupo é opcional, permitindo que cada fabricante ão precise incluir na MIB (Base de informaçõe de administração) todos os grupos.

Alguns grupos de RMON precisam de suporte de outros grupos RMON para que possam funcionar de maneira correta.

Extraído das páginas 525 e 526 do livro INTERNET WORKING MANUAL DE TECNOLOGIAS - Tradução da Segunda Edição.

IPTables

Iptables é um Firewall.
Um firewall é uma barreira inteligente entre duas redes, através do qual só passa tráfego autorizado.
Este tráfego é examinado pelo firewall em tempo real e a seleção é feita de acordo com a política de segurança estabelecida.
O IPTables composto por 3 tabelas:
¹filter: Tabela de filtros de pacotes;
²NAT (network address translation): Conexão de várias máquinas com endereço falso á internet através de poucos endereços IP ́s válidos;
³mangle: Altera o conteúdo dos pacotes.

O que são regras:

As regras são como comandos passados ao iptables para que ele realize uma determinada ação (como bloquear ou deixar passar um pacote) de acordo com o endereço/porta de origem/destino, interface de origem/destino, etc. As regras são armazenadas dentro dos chains e processadas na ordem que são inseridas.

As regras são armazenadas no kernel, o que significa que quando o computador for reiniciado tudo o que fez será perdido. Por este motivo elas deverão ser gravadas em um arquivo para serem carregadas a cada inicialização.

Um exemplo de regra: iptables -A INPUT -s 123.123.123.1 -j DROP.

O que são chains:

Os Chains são locais onde as regras do firewall definidas pelo usuário são armazenadas para operação do firewall. Existem dois tipos de chains: os embutidos (como os chains INPUT, OUTPUT e FORWARD) e os criados pelo usuário. Os nomes dos chains embutidos devem ser especificados sempre em maiúsculas (note que os nomes dos chains são case-sensitive, ou seja, o chain input é completamente diferente de INPUT).

Quando um pacote chega a uma table é verificado se alguma regra se aplica a ele. Caso não haja, é aplicada a política defaut.
Constituído por 3 chains:

INPUT – Pacote destinado a maquina de firewall.
OUTPUT – Pacote originado da maquina de firewall.
FORWARD – Pacote com destino e origem
separados pela maquina de firewall.

Quando um pacote entra numa interface de rede:
Se o pacote é para a máquina é enviado para o chain INPUT;
Se o destino não é esta máquina e o serviço de routing está ativo, o pacote vai para o chain FORWARD;
Se um processo da máquina envia um pacote para a rede o pacote vai para o chain OUTPUT.

Política Default:
A política default do firewall consiste na regra que será utilizada caso algum pacote não se encaixe em nenhuma das regras estabelecidas.
É altamente recomendado que a política default seja DROP, ou seja, tudo o que não for expressamente permitido será descartado (proibido).

Squid - proxy

O servidor Squid Web Proxy Cache é gratuito e funciona em código aberto para Unix e Linux. Ele permite que os administradores implementem um serviço de proxy caching para Web, acrescentem controles de acesso (regras) e armazenem até mesmo consultas de DNS.
Ele surgiu de um projeto entre o governo norte-americano e a a Universidade do Colorado.
Muitas das distribuições já vem com o squid instalado, mas caso sua distribuição não tenha o squid instalado visite o site www.squid-cache.org - e baixe a versão conforme a sua distribuição. Caso utilize Ubuntu, para instala-lo basta digitar no terminal: apt-get install squid

Proxy

Os proxies são principalmente usados para permitir acesso à Web através de um firewall (fig. 1). Um proxy é um servidor HTTP especial que tipicamente roda em uma máquina firewall. O proxy espera por uma requisição de dentro do firewall, a repassa para o servidor remoto do outro lado do firewall, lê a resposta e envia de volta ao cliente.

Figura 1: Visão geral de um proxy

O proxy está rodando ou em um servidor firewall ou qualquer outro servidor interno que tenha acesso total a internet - ou em uma máquina dentro do firewall fazendo conexões com o mundo exterior através de SOCKS ou qualquer outro software firewall.

Normalmente, o mesmo proxy é usado por todos os clientes em uma subrede. Isto torna possível para ele fazer caching eficiente de todos os documentos requisitados.

A habilidade que o proxy tem no uso do cache, o torna atrativo para aqueles que não estão dentro do firewall. Configurar um servidor proxy é fácil e os mais populares programas clientes Web já tem suporte a essa ferramenta. Sendo assim, torna-se simples a tarefa de configurar um grupo de trabalho inteiro para usar o serviço de cache do proxy. Isto reduz os custos com tráfego de rede porque muitos documentos que são requisitados são lidos do cache local.

A metodologia atual é baseada em um código de gateway escrito por Tim Berners-Lee como parte do libwww ( WWW commom Library). Kevin Altis, Ari Luotonen e Lou Montulli foram os principais contribuidores para a padronização do proxy.

Lou Montulli, autor de Lynx, fez as primeiras mudanças no libwww em colaboração com Kevin Altis. Ari Luotonen mantém o CERN httpd.


Porque proxy fica no nível de aplicação?

Um nível de aplicação proxy faz um firewall seguramente permeável para os usuários na organização sem criar um furo na segurança onde hackers poderiam entrar na rede da organização.
Para clientes Web, as modificações necessárias para suportar um nível de aplicação proxy são menores (leva-se apenas 5 minutos para adicionar suporte proxy para o Emacs Web Browser).
Não há necessidade de compilar versões especiais de clientes Web com bibliotecas firewall, o cliente "out-of-the-box" pode ser configurado para ser um cliente proxy. Em outras palavras, quando se usa proxy não necessitamos customizar cada cliente para suportar um tipo ou método especial de firewall: o proxy, em si, é um método padrão para acessar firewalls.

Usuários não têm que ter clientes FTP, Gopher e WAIS separados (muito menos modificados) para acessar um firewall - um simples cliente Web com um servidor proxy trata todos esse casos. O proxy também padroniza a aparência de clientes Gopher e FTP.
O proxy permite que os programadores esqueçam as dezenas de milhares de linhas de código necessárias para suportar cada protocolo e se concentrem em coisas mais importantes - é possível ter clientes "peso-leve" que somente compreendam HTTP (nenhum suporte nativo aos protocolos FTP, Gopher, etc) - outros protocolos são manuseados transparentemente pelo proxy. Usando HTTP entre o cliente e o proxy, nenhuma funcionalidade


Clientes sem DNS (Domain Name Service) também podem usar a Web. O endereço IP do proxy é a única informação realmente necessária. Organizações usando endereços, por exemplo, classe A (como 10.*.*.*), em suas redes particulares podem ainda acessar a internet contanto que o proxy seja visível tanto para a rede particular como para a Internet.
Proxy permite um alto nível de log das transações de clientes, incluindo endereço IP, data e hora, URL, contagem de bytes e código de sucesso. Qualquer campo (seja de meta-informação ou seja comum) em uma transação HTTP é um candidato para log. Isto não é possível com log no nível IP ou TCP.

Também é possível fazer a filtragem de transações de clientes no nível do protocolo de aplicação. O proxy pode controlar o acesso a serviços por métodos individuais, servidores e domínios, etc.
Outra feature interessante do proxy é a cache. O uso de cache é mais efetivo no servidor proxy do que em cada cliente. Isto salva espaço em disco, desde que somente uma cópia é guardada, como também permite um uso de "cache inteligente", onde os documentos frequentemente referenciados por muitos clientes são guardados por um periodo mais longo de tempo pelo cache manager.
O uso de cache também torna possível acessar algumas páginas mesmo que servidores estejam fora do ar. Essa facilidade torna o serviço melhor, visto que recursos remotos como um site FTP ocupado que são frequentemente inacessíveis remotamente podem ser agora acessíveis através do cache local. Pode-se citar uma infinidade de usos que podemos fazer com o cache: fazer uma demonstração de algum lugar com uma baixa velocidade de conexão, ler documentos com a máquina não-conectada (obviamente após colocar todos documentos no cache local), etc.

Clientes sem DNS (Domain Name Service) também podem usar a Web. O endereço IP do proxy é a única informação realmente necessária. Organizações usando endereços, por exemplo, classe A (como 10.*.*.*), em suas redes particulares podem ainda acessar a internet contanto que o proxy seja visível tanto para a rede particular como para a Internet.
Proxy permite um alto nível de log das transações de clientes, incluindo endereço IP, data e hora, URL, contagem de bytes e código de sucesso. Qualquer campo (seja de meta-informação ou seja comum) em uma transação HTTP é um candidato para log. Isto não é possível com log no nível IP ou TCP.
Também é possível fazer a filtragem de transações de clientes no nível do protocolo de aplicação.

O proxy pode controlar o acesso a serviços por métodos individuais, servidores e domínios, etc.
Outra feature interessante do proxy é a cache. O uso de cache é mais efetivo no servidor proxy do que em cada cliente. Isto salva espaço em disco, desde que somente uma cópia é guardada, como também permite um uso de "cache inteligente", onde os documentos frequentemente referenciados por muitos clientes são guardados por um periodo mais longo de tempo pelo cache manager.

O uso de cache também torna possível acessar algumas páginas mesmo que servidores estejam fora do ar. Essa facilidade torna o serviço melhor, visto que recursos remotos como um site FTP ocupado que são frequentemente inacessíveis remotamente podem ser agora acessíveis através do cache local. Pode-se citar uma infinidade de usos que podemos fazer com o cache: fazer uma demonstração de algum lugar com uma baixa velocidade de conexão, ler documentos com a máquina não-conectada (obviamente após colocar todos documentos no cache local), etc.

Em geral, autores de clientes Web não tem razão para usar versões de firewalls em seus códigos. O proxy é mais simples para configurar do que SOCKS e trabalha em todas as plataformas, não somente UNIX.

Componentes Básicos do SNMP

Uma rede administrada com o SNMP é composta por três componentes principais: dispositivos gerenciados, agentes e sistemas de administração de redes(NMSs).

Um dispositivo administrado é um nó de rede que contém um agente SNMP e que se encontra em uma rede adiministrada. Os dispositivos administrados coletam e armazenam informações de administração e tornam essas informações disponíveis para os sistemas NMSs que utilizam o protocolo SNMP. Os dispositivos gerenciados, às vezes chamados de elementos de rede, podem ser roteadores e servidores de acesso, switches e bridges, hubs, l com o protocolo SNMPcomputadores hots ou impressora.

Um agente Smith é um módulo de software de administração de rede localizado em um dispositivo administrado. O agente possui um conhecimento local das informações de administração e traduz essas informações em uma forma compatível com o protocolo SNMP.

Os sistemas NMS executam aplicações que monitoram e controlam os dispositivos administrados. Os NMSs fornecem o volume de recursos de processamento e de memória necessários para a administração de rede. É preciso haver um ou mais sistemas NMSs em qualquer rede que seja administrada.

Extraído da página 529 do Livro INTERNET WORKING TECHNOLOGIES HANDBOOK – Tradução da segunda edição.