From UnderLinux Wiki

Tabela de conteúdo 1 Introdução 2 Objetivos do projeto 3 Topologia proposta 4 Definição do projeto 5 Execução e discussão 5.1 Modificando o kernel 6 Regras do firewall 6.1 Regras de NAT (ou masquerading) 6.1.1 “Afinando” o sysctl 7 Finalização: 8 Referências 9 Têrmos de (Ir)responsabilidade 10 Extras: 11 Quem é o Irado?

Introdução

Há tempos venho trabalhando com segurança de redes e, francamente, acho decepcionante a displicência com que o assunto é tratado pela maioria das emprêsas e pelos gerentes de TI.

Nota-se, claramente, que a maioria desses profissionais continua confiando em produtos tradicionais, de código fechado, talvez por ser mais fácil. Ou, presumívelmente, pelo conceito americano de “distribuição de responsabilidade”, resumido em apenas uma frase: "QUEM vai ter o ra** comido por isso?".

O mais comum é a busca pelo responsável, desde que não seja EU o responsabilizado (me inclua fora disso (risos)).

Para aquêles que são mais conscientes, que têm uma politica minimamente razoável de segurança, com backups adequados e etc, creio que já encontraram a solução de suas preocupações via um dos *BSD's. Em nosso caso, usamos o FreeBSD, sentimo-nos melhor com um firewall estabelecido nêste do que em outro SO “quase *nix” de código aberto tipo 'bazaar', uma vez que o conceito de 'statefull' é recente nêsse último, e já bem estabelecido nos produtos básicos dos *BSD's (ipfw, ipfilter e, mais recentemente, ip). Além do fato de que um firewall bem fechado nos *BSD's exige cêrca de 20 linhas de script (se tanto), enquanto naquêle outro, mesmo com a assistência dos produtos específicos (tuxfrw, bastille, ezfirewall, e outros) nós terminamos com um script de até 130 linhas, no caso mais simples, e com terminologia (comandos) criptográficos, cheio de pré e post-tratamentos, sabem os deuses de quê, além do fato de que só recentemente começaram a usar sistemas "statefull" (os geradores mencionados não usam essa característica do iptables). Pelo menos as regras em ipf.rules (ou rc.firewall) são compreensíveis (risos), além de eficientes, e o "statefull" é uma condição bem conhecida e bem estabelecida nos *BSD's. :-).

Bem, chega de digressões. Vamos aos pontos:

Objetivos do projeto

Estabelecer um firewall/gateway statefull, permitindo a conexão de uma rede interna à Internet, protegendo-a adequadamente. Será usado (nêste exemplo) o ipfilter, que é um dos produtos amparados no FreeBSD - o outro é o ipfw. Tenho usado ambos, e considero-os como bastante seguros bem como facéis de utilizar-se/configurar. Nosso firewall deve ser do tipo default closed ou seja, TUDO é proibido, permite-se apenas o que desejamos que transite.

Topologia proposta

Apenas para facilitar, consideraremos que NÃO temos qualquer servidor para disponibilizar serviços para a internet, portanto não precisaremos de uma DMZ. Claro, como bom NetAdmin você sequer imagina que um firewall possa abrigar servidores acessíveis a partir da Internet, né mesmo? (risos). Estou certo de que você só cogita de colocar seus servidores FAMP (FreeBSD+Apache+MySQL+PHP) bem como Postfix/pop3d protegidos em DMZ. (mais risos).

A sério: se você alguma vez cogitou colocar seus servidores na mesma máquina do firewall sugiro revisar seus conceitos de segurança.

Definição do projeto

Nossa rede interna (LAN) deverá, de maneira segura, navegar pela Internet e acessar todos os serviços eventualmente disponibilizados por esta (ftp, http, pop e smtp, icq, etc), através de um gateway/firewall. Nêste momento não disporemos de um proxy/cache, nem disponibilizaremos serviços ao mundo externo (Internet). Todos os serviços requisitados por nossa rede interna será atendido transparentemente, mas o firewall/gateway NÃO será acessível diretamente, tanto pela LAN quanto pela Internet, exceto via canal SSH (apenas pela nossa Lan, não pela Internet), para fins administrativos. Mesmo êsse acesso poderá ser restrito a uma única máquina (do NetAdmin). A característica do firewall é 'bloqueado por default', ou seja, TUDO é rejeitado, seja qual for a origem, exceto pelas autorizações especificadas pelo NetAdmin. Usaremos o IPFilter e IPNat, dos quais existe farta documentação na Internet.

Execução e discussão

O modem ADSL (ou roteador) que nos conecta à Internet apresenta o ip-addr 200.204.151.65 e o consideramos como nosso roteador.

O firewall, com duas placas de rêde, tem dois ip-address: 200.204.151.121, ligado ao modem (roteador), e 192.168.1.1, ligado à LAN. A placa de rede ligada à LAN deverá ter SEMPRE um dos endereçamentos autorizados pela RFC-1918. Selecionamos, dentre os permitidos, um e 'C', que é mais do que o suficiente para nossos propósitos. Tivéssemos uma rede maior e poderíamos escolher um da e 'B' (mais de um milhão de hosts) ou mesmo e 'A´, para uma rede monstruosamente grande (mais de 16 milhões de hosts). Sugere-se ainda que esta LAN tenha seus ipaddr iniciais a partir de .21, deixando a gama de 2 a 20 para eventuais servidores/roteadores internos. Ah sim, convém deixar os ip-addr .230~.254 livres para máquinas eventuais de teste, por exemplo. Em minha opinião, se forem mais de 10 máquinas em sua rede fica compensador estabelecer um servidor DHCP (em 192.168.1.2, por exemplo), respeitando êsses ip-addr pré-definidos. Mas enfim, voltemos ao projeto:

Modificando o kernel

options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)"
options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)"
options IPSTEALTH #support for stealth forwarding
options RANDOM_IP_ID
options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN
options ICMP_BANDLIM
options IPFILTER #ipfilter support
options IPFILTER_LOG #ipfilter logging
options IPFILTER_DEFAULT_BLOCK #block all packets by default

esses têrmos deverão ser acrescentados ao texto do nosso kernel.

Em nosso caso, copiamos o GENERIC para o NOME_NOVO

cp -fv /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/NOME_NOVO

ou seja, um kernel com um nome qualquer, de nossa escolha. As opções realmente essenciais estão entre as cerquilhas (#), e tratam do nosso ipfilter, as demais são ou cosméticas (green|..), pra deixar o monitor com letrinhas verdes em fundo prêto ou são convenientes para a segurança. Sugiro utilizar estas últimas e, se estiver interessado em saber sua ação, uma boa lida no LINT esclarecerá suas dúvidas. Todos sabem como compilar um kernel, portanto...

Vamos para o /etc/rc.conf

blanktime="120"
clear_tmp_enable="YES"
cursor="blink"
defaultrouter="200.204.151.65"
fsck_y_enable="YES"
gateway_enable="YES"
hostname="infoway.irado.org"
icmp_drop_redirect="YES"
icmp_log_redirect="YES"
ifconfig_rl0="inet 200.204.151.121 netmask 255.255.255.192"
ifconfig_rl1="inet 192.168.1.1 netmask 255.255.255.0"
inetd_enable="NO"
ipfilter_enable="YES"
ipmon_enable="YES"
ipmon_flags="-Dvn /var/log/ipmon.log"
ipnat_enable="YES"
kern_securelevel="-1"
kern_securelevel_enable="YES"
keymap="br275.iso.acc"
log_in_vain="1"
saver="logo"
sendmail_enable="NONE"
sshd_enable="YES"
syslogd_flags=" -ss "
tcp_drop_synfin="YES" ##--> WEB server não pode fazer isso :-)

Embora todos saibam disso, ainda assim cumpre relembrar: o /etc/rc.conf estabelece os parâmetros básicos para o funcionamento de nosso firewall. Outros *conf se encarregam de várias outras coisas, e o /etc/rc administra todo mundo (risos). Uma boa lida nos *conf (e no /etc/rc) ajuda bem a compreender como as coisas funcionam. Bem, no /etc/rc.conf devem ser colocados os parâmetros que DIVIRJAM do estabelecido no /etc/defaults/rc.conf. Leia êste último, porém NÃO altere nada aqui. Por exemplo, em /etc/defaults/rc.conf o sendmail é ativado, portanto nós o desativamos no nosso /etc/rc.conf. O sshd NÃO é ativado em /etc/defaults/rc.conf, portanto o ativamos aqui. Captaram a idéia?

Então, vamos aos 'porquês' das coisas:

defaultrouter="200.204.151.65"

aqui, você coloca o ip-addr do seu roteador, seja um modem ou um roteador mesmo, aquêle que te leva para a internet.

gateway_enable="YES"

bem, êste deve ser ativado porque esta máquina é um gateway afinal (risos), senão não teria sentido.

icmp_drop_redirect="YES"
icmp_log_redirect="YES"
tcp_drop_synfin="YES"

Bem, êsses refletem preocupações com a segurança. Uma consulta ao google (http://www.google.com/bsd) trará toneladas de razões de “por qué” devemos usa-los e, estou certo de que você vai adorar pesquisar a respeito e eu me odiaria por tirar êsse prazer (pesquisar) de você. :-)

inetd_enable="NO"

você não quer pop3/ftp e outros nesta máquina., são serviços desnecessários e (IMHO) contraproducentes em um firewall.

kern_securelevel="-1"
kern_securelevel_enable="YES"

Embora habilitado (...enable="YES"), não está ativado (..level="-1"). Somente após a finalização de nosso firewall é que vamos modifica-lo para nível 3.

ipfilter_enable="YES"
ipmon_enable="YES"
ipmon_flags="-Dvn /var/log/ipmon.log"
ipnat_enable="YES"

Habilitamos o ipfilter, bem como o ipmon e o ipnat. O ipmon é o que vai gerar o log das ações de nosso firewall, conforme disposto nas regras em ipf.rules (a seguir), 'ipmon_flags' diz o nome do arquivo de log gerado, -Dvn transforma-o em 'daemon', deixa-o um pouco mais “falante” (-v) e associa os números de portas aos seus respectivos serviços e ip-addr a hosts (-n).

Regras do firewall

As regras de nosso firewall são contidas no arquivo /etc/ipf.rules (vide tabela-1) Notem que são poucas regras, em relação àquelas criadas por (por exemplo) ipkungfu para o iptables/Linux (tabela-2). Em minha opinião, é mais fácil analisar 15/20 linhas de regras do que (como é o caso) mais de 120 linhas. Bem, vamos analisar, ligeiramente, algumas regras de nosso ipf.rules.

Acompanhe-nos na sequencia da tabela-1:

# define policy

Nêste trecho nõs estamos dizendo para REJEITAR tudo o que venha pela interface rl0 (externa, Internet), protocolos tcp, icmp e udp. Ou seja, rejeitamos tudo (risos), mas acalmem-se, essas seriam regras default, ou seja, aplicáveis quando NENHUMA outra se aplique. Com isso, quando (mais tarde) definirmos:

pass in quick on rl0 proto tcp from any to 200.204.151.121 port = 25 flags S/SA keep state

significará que vamos aceitar a entrada (pass in) via rl0 (da Internet) de qualquer host externo (óbvio) para mim (200.204.151.121) na porta 25, flag S(YN), ou seja, estabelecimento de conexão, e manteremos essa conexão em tabela (keep state), abrindo regra dinâmica, o que evitará nova consulta, enquanto for mantida a conexão original. Ou seja, enquanto houver tráfego, será mantida a regra dinâmica, sem nova consulta às regras em ipf.rules. :-).

Se tiver (ou quiser) habilitar outros serviços (pop3, http, dns) em máquinas internas, o conceito é o mesmo. é preciso lembrar que essas máquinas internas deverão ser mapeadas pelo ipnat.rules, mas isso não pertence a êste artigo.. talvez outro dia, outro artigo, com DMZ e tudo o mais ;-)

Creio que com isso vocês já têm o suficiente para analisar as demais regras do ipf.rules, inclusive notando que aceitamos TUDO que venha de nossa LAN. Assim sendo, vocês TAMBÉM estão em condições de fazer essas regras internas de modo contrário, ou seja: proibir TUDO que venha da LAN, autorizando apenas tcp que vá pra porta 80 de qualquer lugar do mundo. Ou portas 25, 80 e 110. Com isso fica-se livre de certas portas inconvenientes (kazaa, icq, chat). Fiquem à vontade, divirtam-se.

Regras de NAT (ou masquerading)

Lembram-se do 'ipnat' lá no /etc/rc.conf? Pois é, o ipf estabelece regras de firewall, mas o ipnat faz com que seja feito o NAT (ou masquerading, em Linuxês..), possibilitando que nossa LAN acesse a Internet através do único IP-address válido, desta nossa máquina. As regras de NAT ficam em /etc/iipnat.rules (vide tabela-3). O ipfilter nos permite criar um proxy de ftp, de mdo que as máquinas internas (LAN) sempre tenham a impressão de estarem executando ftp ativo, quando nem sempre isso ocorre. Também é feito um proxy para RealAudio. Depois mapeamos as máquinas internas para que acessem a Internet com nosso (único) enderêço válido.

“Afinando” o sysctl

Estamos já quase no fim. Na tabela-4 temos o nosso /etc/sysctl.conf, válido para a máquina que está sendo descrita/definida nêste artigo. Os dados podem ser encontrados nas referências que mencionamos; permitimo-nos declinar de esclarecer seu funcionamento em virtude de os artigos (a respeito) serem extensos e seria cansativo repeti-los aqui. Sugiro fortemente que o leitor faça uma busca em regra nas referências dêste artigo.

/etc/newsyslog.conf

Na última linha dêsse arquivo (tabela-5) acrescentamos o comando necessário para permitir a compactação de arquivos de log, e sua substituição por novos. Alguém lembra de algo como o 'logrotate´?

Finalização:

As máquinas de nossa LAN deverão indicar esta nossa (192.168.1.1) como sendo seu gateway. A navegação deverá ser imediata, desde que todos os componentes envolvidos (nic's, switches, etc.) estejam funcionando a contento.

Referências

Referências, com forte sugestão para consulta:

http://truta.sspj.go.gov.br/FreeBSD-STABLE_and_IPFILTER_PT_BR.html

http://www.schlacter.net/public/FreeBSD-STABLE_and_IPFILTER.html site do “paper” original

http://cheops.anu.edu.au/~avalon/ip-filter.html

http://www.freebsddiary.org/ipfilter.html

http://www.obfuscation.org/ipf/ipf-howto.txt

http://www.sys.adm.br (site do Mauricio Goto, conhecido FreeBSD´er)

http:www.fugspbr.org (lista de discussão, mantida pelo Edson Brandi. é a lista oficial do Grupo de Usuários FreeBSD-Brazil)

http://freebsd.ag.com.br site do Edson Brandi. Desatualizado, depois que êle enricou, desinteressou-se (risos sádicos)

http://www.gamk.com.br

http://www.free.bsd.com.br (do Patrick Tracanelli - o melhor tutorial de DNS que já li um dia, vale baixar/imprimir. Tá desatualizado, depois que tornou-se rico empresário, mas é valiosíssimo) (mais risos sádicos)

http://www.inebriated.demon.nl

http://www.myfreebsd.com.br

http://www.astalavista.com/library/hardening/bsd/hardeningbsd1.shtml

http://www.onlamp.com/bsd (OReilly Network: BSD DevCenter)

esses dois últimos têm documentos interessantes sôbre os bsd's.. e (in)segurança, em geral ;-)

Têrmos de (Ir)responsabilidade

Não é previsto que iniciantes venham a executar êste projeto, embora êste não seja, de forma alguma, inacessível aos mesmos. Apenas supôe-se que aquêles que resolverem executa-lo deverão, pelo menos, saber instalar/reinstalar o FreeBSD a partir de qualquer fonte disponível (cdrom/NFS/ftp), bem como entender razoávelmente os têrmos comuns dos shell-scripts empregados. Sempre lembrando: embora o projeto aqui discutido seja comprovadamente reprodutível, nem o autor nem a revista se responsabiliza por quaisquer eventos imprevistos que ocorram com os equipamentos e softwares dos leitores. O autor (e também os editores) não oferecem suporte.

Extras:

Se você (após analisar) julgar as regras simples, saiba que o mesmo firewall, com ipfw, apresenta regras ainda mais simples. A eficiência é a mesma, mas em ipfw temos condições de estabelecer contrôle de banda (via dummynet). Por outro lado (risos) em meu firewall com ipfw não funciona o traceroute :-) 2 - Por curiosidade: na tabela-6 temos os resultados de utilização do Nmap, inicialmente com nmap -sS -P0 -v infoway 20-113 (Stealth Scan). O resultado é de uma única porta disponível (22 - ssh). TODAS as portas recusaram conexão, exceto a 22, que realmente tem o sshd no ar, permitindo o estabelecimento do túnel para podermos administrar remotamente o firewall. Não identificou o sistema operacional quando utilizando o flag -O. Na sequência, utilizamos o comando nmap -sX -P0 -v infoway 20-113 (Christmas Tree). TODAS as portas aparecem como abertas (risos). Mas ainda não identifica o sistema operacional, quando acrescentada a flag -O.

/begin digressão

A não identificação do SO torna mais difícil o trabalho do 'script-kid' mas não impedirá o eventual 'cracker', uma vez que são disponíveis outras (conhecidas) ferramentas que, por exclusão, acabam por permitir essa identificação.. mas uma dificuldade a mais sempre nos ajuda, né? é o mesmo caso com nossos automóveis: se estacionarmos nosso veículo em um pátio, entre vários outros, e o NOSSO veículo estiver com bloqueio eletrônico, vidros marcados, 'tracking' via satélite, alarme ultrasônico, trava "carneiro" (marca registrada), trava de volante/pedais em aço temperado, e, ao lado, um outro sem tudo isso, adivinhe QUAL o ladrão vai querer levar? Por outro lado, se o NOSSO veículo for objeto de eventual “encomenda”, então não tem jeito.. será roubado. Então anote: CRIE o máximo de dificuldades que puder.. e leia os logs (risos).

/end digressão

Em seguida, usando o NetCat tentamos estabelecer conexão com essas portas "abertas" (risos). O comando nc -v -z -t -w 3 infoway 20-113 informa que apenas a porta 22 está aberta, o que é o correto. O que me leva a pensar que se alguém scanear minha máquina com o Xmas e, em seguida, tentar o acesso (telnet ou outro) às portas pretensamente abertas - mesmo as mais comuns, 20,21,23,53,80,110 - vai ter um bocado de trabalho tentando.. :-)

Quem é o Irado?

Consultor técnico, autônomo, P.O.D (Por Ora, Disponível – indica “desempregado”), especialista em segurança de redes, acesso seguro à Internet, servidores seguros e de alta-performance, para e-mail, web-mail, substituição de PDC´s do win-nt4/2000, firewalls, projeto e instalação de provedores Internet (ISP´s).

Pode ser encontrado pelo fone 0(21)11-4232-0746 e também nos canais de irc da freenode br.freenode.net #slackware-br,#freebsd-br e nos newsgroups da usenet brasileira (links em http://www.abusar.org).

• contato: irado [NOSPAM] hotpop.com