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.
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
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 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 seqüê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).
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
É 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.
É 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.
É 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.
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.
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.
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.
Freqüentemente 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...
Copyright © 1999-2020 - Gleydson Mazioli da Silva