Guia do Linux/Avançado/Rede/Segurança da Rede e controle de Acesso

Segurança da Rede e controle de Acesso

Deixe-me iniciar esta seção lhe alertando que a segurança da rede em sua máquina e ataques maliciosos são uma arte complexa. Uma regra importante é: "Não ofereça serviços de rede que não deseja utilizar".

Muitas distribuições vem configuradas com vários tipos de serviços que são iniciados automaticamente. Para melhorar, mesmo que insignificantemente, o nível de segurança em seu sistema você deve editar se arquivo /etc/inetd.conf e comentar (colocar uma "#") as linhas que contém serviços que não utiliza.

Bons candidatos são serviços tais como: shell, login, exec, uucp, ftp e serviços de informação tais como finger, netstat e sysstat.

Existem todos os tipos de mecanismos de segurança e controle de acesso, eu descreverei os mais importantes deles.

/etc/ftpusers

O arquivo /etc/ftpusers é um mecanismo simples que lhe permite bloquear a conexão de certos usuários via ftp. O arquivo /etc/ftpusers é lido pelo programa daemon ftp (ftpd) quando um pedido de conexão é recebido. O arquivo é uma lista simples de usuários que não tem permissão de se conectar. Ele se parece com:

     # /etc/ftpusers - login de usuários bloqueados via ftp
     root
     uucp
     bin
     mail

/etc/securetty

O arquivo /etc/securetty lhe permite especificar que dispositivos tty que o usuário root pode se conectar. O arquivo /etc/securetty é lido pelo programa login (normalmente /bin/login). Seu formato é uma lista de dispositivos tty onde a conexão é permitida, em todos os outros, a entrada do usuário root é bloqueada.

     # /etc/securetty - terminais que o usuário root pode se conectar
     tty1
     tty2
     tty3
     tty4

O mecanismo de controle de acessos tcpd

O programa tcpd que você deve ter visto listado no mesmo arquivo /etc/inetd.conf, oferece mecanismos de registro e controle de acesso para os serviços que esta configurado para proteger. Ele é um tipo de firewall simples e fácil de configurar que pode evitar tipos indesejados de ataques e registrar possíveis tentativas de invasão.

Quando é executado pelo programa inetd, ele lê dos arquivos contendo regras de acesso e permite ou bloqueia o acesso ao servidor protegendo adequadamente.

Ele procura nos arquivos de regras até que uma regra confira. Se nenhuma regra conferir, então ele assume que o acesso deve ser permitido a qualquer um. Os arquivos que ele procura em sequência são: /etc/hosts.allow e /etc/hosts.deny. Eu descreverei cada um destes arquivos separadamente.

Para uma descrição completa desta facilidade, você deve verificar a página de manual apropriada (hosts_access (5) é um bom ponto de partida).

/etc/hosts.allow

O arquivo /etc/hosts.allow é um arquivo de configuração do programa /usr/sbin/tcpd. O arquivo hosts.allow contém regras descrevendo que hosts tem permissão de acessar um serviço em sua máquina.

O formato do arquivo é muito simples:

     # /etc/hosts.allow
     #
     # lista de serviços: lista de hosts : comando

lista de serviços: É uma lista de nomes de serviços separados por vírgula que esta regra se aplica. Exemplos de nomes de serviços são: ftpd, telnetd e fingerd.
lista de hosts: É uma lista de nomes de hosts separada por vírgula. Você também pode usar endereços IP's aqui. Adicionalmente, você pode especificar nomes de computadores ou endereço IP usando caracteres coringas para atingir grupos de hosts.

Exemplos incluem: gw.vk2ktj.ampr.org para conferir com um endereço de computador específico, .uts.edu.au para atingir qualquer endereço de computador finalizando com aquele string. Use 200.200.200. para conferir com qualquer endereço IP iniciando com estes dígitos. Existem alguns parâmetros especiais para simplificar a configuração, alguns destes são: ALL atinge todos endereços, LOCAL atinge qualquer computador que não contém um "." (ie. está no mesmo domínio de sua máquina) e PARANOID atinge qualquer computador que o nome não confere com seu endereço (falsificação de nome). Existe também um último parâmetro que é também útil: o parâmetro EXCEPT lhe permite fazer uma lista de exceções. Isto será coberto em um exemplo adiante.

comando: É um parâmetro opcional. Este parâmetro é o caminho completo de um comando que deverá ser executado toda a vez que esta regra conferir. Ele pode executar um comando para tentar identificar quem esta conectado pelo host remoto, ou gerar uma mensagem via E-Mail ou algum outro alerta para um administrador de rede que alguém está tentando se conectar.

Existem um número de expansões que podem ser incluídas, alguns exemplos comuns são: %h expande o endereço do computador que está conectado ou endereço se ele não possuir um nome, %d o nome do daemon sendo chamado.

Se o computador tiver permissão de acessar um serviço através do /etc/hosts.allow, então o /etc/hosts.deny não será consultado e o acesso será permitido.

Como exemplo:

     # /etc/hosts.allow
     #
     # Permite que qualquer um envie e-mails
     in.smtpd: ALL
     # Permitir telnet e ftp somente para hosts locais e myhost.athome.org.au
     in.telnetd, in.ftpd: LOCAL, myhost.athome.org.au
     # Permitir finger para qualquer um mas manter um registro de quem é
     in.fingerd: ALL: (finger @%h | mail -s "finger from %h" root)

Qualquer modificação no arquivo /etc/hosts.allow entrará em ação após reiniciar o daemon inetd. Isto pode ser feito com o comando kill -HUP [pid do inetd], o pid do inetd pode ser obtido com o comando ps ax|grep inetd.

/etc/hosts.deny

O arquivo /etc/hosts.deny é um arquivo de configuração das regras descrevendo quais computadores não tem a permissão de acessar um serviço em sua máquina.

Um modelo simples deste arquivo se parece com isto:

     # /etc/hosts.deny
     #
     # Bloqueia o acesso de computadores com endereços suspeitos
     ALL: PARANOID
     #
     # Bloqueia todos os computadores
     ALL: ALL

A entrada PARANOID é realmente redundante porque a outra entrada nega tudo. Qualquer uma destas linhas pode fazer uma segurança padrão dependendo de seu requerimento em particular.

Tendo um padrão ALL: ALL no arquivo /etc/hosts.deny e então ativando especificamente os serviços e permitindo computadores que você deseja no arquivo /etc/hosts.allow é a configuração mais segura.

Qualquer modificação no arquivo /etc/hosts.deny entrará em ação após reiniciar o daemon inetd. Isto pode ser feito com o comando kill -HUP [pid do inetd], o pid do inetd pode ser obtido com o comando ps ax|grep inetd.

/etc/hosts.equiv e /etc/shosts.equiv

O arquivo /etc/hosts.equiv é usado para garantir/bloquear certos computadores e usuários o direito de acesso aos serviços "r*" (rsh, rexec, rcp, etc) sem precisar fornecer uma senha. O /etc/shosts.equiv é equivalente mas é lido somente pelo serviço ssh. Esta função é útil em um ambiente seguro onde você controla todas as máquinas, mesmo assim isto é um perigo de segurança (veja nas observações). O formato deste arquivo é o seguinte:

     #Acesso  Máquina                   Usuário
     -        maquina2.dominio.com.br   usuario2
     -        maquina4.dominio.com.br   usuario2
              maquina1.dominio.com.br    @usuarios

O primeiro campo especifica se o acesso será permitido ou negado caso o segundo e terceiro campo confiram. Por razões de segurança deve ser especificado o FQDN no caso de nomes de máquinas. Grupos de rede podem ser especificados usando a sintaxe " @grupo".

Para aumentar a segurança, não use este mecanismo e encoraje seus usuários a também não usar o arquivo .rhosts.

ATENÇÃO O uso do sinal " " sozinho significa permitir acesso livre a qualquer pessoa de qualquer lugar. Se este mecanismo for mesmo necessário, tenha muita atenção na especificação de seus campos.

Evita também A TODO CUSTO uso de nomes de usuários (a não ser para negar o acesso), pois é fácil forjar o login, entrar no sistema tomar conta de processos (como por exemplo do servidor Apache rodando sob o usuário www-data ou até mesmo o root), causando enormes estragos.

Verificando a segurança do TCPD e a sintaxe dos arquivos

O utilitário tcpdchk é útil para verificar problemas nos arquivos hosts.allow e hosts.deny. Quando é executado ele verifica a sintaxe destes arquivos e relata problemas, caso eles existam.

Outro utilitário útil é o tcpdmatch, o que ele faz é permitir que você simule a tentativa de conexões ao seu sistema e observar ser ela será permitida ou bloqueada pelos arquivos hosts.allow e hosts.deny.

É importante mostrar na prática como o tcpdmatch funciona através de um exemplo simulando um teste simples em um sistema com a configuração padrão de acesso restrito:

O arquivo hosts.allow contém as seguintes linhas:

     ALL: 127.0.0.1
     in.talkd, in.ntalkd: ALL
     in.fingerd: 192.168.1. EXCEPT 192.168.1.30

A primeira linha permite o loopback (127.0.0.1) acessar qualquer serviço TCP/UDP em nosso computador, a segunda linha permite qualquer um acessar os servidor TALK (nós desejamos que o sistema nos avise quando alguém desejar conversar) e a terceira somente permite enviar dados do finger para computadores dentro de nossa rede privada (exceto para 192.168.1.30).

O arquivo hosts.deny contém a seguinte linha:

     ALL: ALL

Qualquer outra conexão será explicitamente derrubada.

Vamos aos testes, digitando: "tcpdmatch in.fingerd 127.0.0.1" (verificar se o endereço 127.0.0.1 tem acesso ao finger):

     client:   address  127.0.0.1
     server:   process  in.fingerd
     matched:  /etc/hosts.allow line 1
     access:   granted

Ok, temos acesso garantido com especificado pela linha 1 do hosts.allow (a primeira linha que confere é usada). Agora "tcpdmatch in.fingerd 192.168.1.29":

     client:   address  192.168.1.29
     server:   process  in.fingerd
     matched:  /etc/hosts.allow line 3
     access:   granted

O acesso foi permitido através da linha 3 do hosts.allow. Agora "tcpdmatch in.fingerd 192.168.1.29":

     client:   address  192.168.1.30
     server:   process  in.fingerd
     matched:  /etc/hosts.deny line 1
     access:   denied

O que aconteceu? como a linha 2 do hosts.allow permite o acesso a todos os computadores 192.168.1.* exceto 192.168.1.30, ela não bateu, então o processamento partiu para o hosts.deny que nega todos os serviços para qualquer endereço. Agora um último exemplo: "tcpdmatch in.talkd www.debian.org"

     client:   address  www.debian.org
     server:   process  in.talkd
     matched:  /etc/hosts.allow line 2
     access:   granted

Ok, na linha 2 qualquer computador pode te chamar para conversar via talk na rede, mas para o endereço DNS conferir com um IP especificado, o GNU/Linux faz a resolução DNS, convertendo o endereço para IP e verificando se ele possui acesso.

No lugar do endereço também pode ser usado a forma daemon@computador ou cliente@computador para verificar respectivamente o acesso de daemons e cliente de determinados computadores aos serviços da rede.

Como pode ver o TCPD ajuda a aumentar a segurança do seu sistema, mas não confie nele além do uso em um sistema simples, é necessário o uso de um firewall verdadeiro para controlar minuciosamente a segurança do seu sistema e dos pacotes que atravessam os protocolos, roteamento e as interfaces de rede. Se este for o caso aprenda a trabalhar a fundo com firewalls e implemente a segurança da sua rede da forma que melhor planejar.

Firewall

Dentre todos os métodos de segurança, o Firewall é o mais seguro. A função do Firewall é bloquear determinados tipos de tráfego de um endereço ou para uma porta local ou permitir o acesso de determinados usuários mas bloquear outros, bloquear a falsificação de endereços, redirecionar tráfego da rede, ping da morte, etc.

A implementação de um bom firewall dependerá da experiência, conhecimentos de rede (protocolos, roteamento, interfaces, endereçamento, masquerade, etc), da rede local, e sistema em geral do Administrador de redes, a segurança de sua rede e seus dados dependem da escolha do profissional correto, que entenda a fundo o TCP/IP, roteamento, protocolos, serviços e outros assuntos ligados a rede.

Frequentemente tem se ouvido falar de empresas que tiveram seus sistemas invadidos, em parte isto é devido a escolha do sistema operacional indevido mas na maioria das vezes o motivo é a falta de investimento da empresa em políticas de segurança, que algumas simplesmente consideram a segurança de seus dados e sigilo interno como uma despesa a mais.

Um bom firewall que recomendo é o ipchains, Sinus e o TIS. Particularmente gosto muito de usar o ipchains e o Sinus e é possível fazer coisas inimagináveis programando scripts para interagirem com estes programas...