Saltar para o conteúdo

Guia do Linux/Iniciante+Intermediário/Rede/Segurança da Rede e controle de Acesso

Origem: Wikilivros, livros abertos por um mundo aberto.

Segurança da Rede e controle de Acesso

[editar | editar código-fonte]

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

[editar | editar código-fonte]

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

[editar | editar código-fonte]

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

[editar | editar código-fonte]

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

[editar | editar código-fonte]

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

[editar | editar código-fonte]

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

[editar | editar código-fonte]

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

[editar | editar código-fonte]

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.

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...