www.shorewall.com.br

Revisado em 20-03-2011

Shorewall – um sistema de firewall a prova de erros

O ser humano erra, o Shorewall não

www.shorewall.com.br

Edson Kazuto Tagusagawa – shorewall.com.br@gmail.com - 55-11-93959687

Formado na Federal em 1988 trabalha na área de TI desde então tendo passado pela Itautec e pela Scopus Tecnologia. Ingressou na Escola Politécnica da USP em 1989, teve formação CNE-Novell e desde 2002 atua com OpenSource, distribuições Linux e Shorewall, sendo especialista em sistemas como Zimbra (Webmail/Groupware), Bacula (Backup em rede) e Zabbix (Monitoramento em rede), trabalha também com projetos de infraestrutura e redes utilizando OpenVPN, Squid, Sarg, Samba, DHCP, DNS, FTP, Debian, Ubuntu, Fedora, Centos, Slax, etc. Trabalha como consultor, realizando projetos, implantações, treinamentos e prestando suporte técnico a empresas que utilizam as tecnologias Open-Source.

Muito importante: www.shorewall.com.br - este é o site brasileiro sobre o Shorewall. O intuito deste site não é substituir o site oficial (www.shorewall.net) mas apenas fornecer a quem ainda não conhece o Shorewall informações úteis e as melhores práticas, mostrando o poder desta ferramenta milagrosa de cerca de 400Kbytes que permite a gestão de empresas pequenas, médias e grandes, com rapidez, eficiência e confiabilidade.

Outro objetivo é receber artigos, cases e documentos em língua portuguesa para a divulgação do Shorewall e das boas práticas de uso, para tanto, caso deseje participar, envie por e-mail artigos, documentos e sugestões que os créditos serão dados, desde que o faça no espírito GPL2 / Creative Commons. Este é um projeto pessoal, e por hora, é o que foi possível fazer.

Quem também quiser treinamentos/consultoria sobre o material disponível neste site, é só entrar em contato.

Boa Leitura!

Introdução ao Shorewall

Muitos usuários de Linux percebem que mesmo sendo muito seguro, o Linux requer um bom firewall.

Para o usuário de Desktop, acostumado com interface gráfica, as boas opções são poucas e quando existem são inadequadas para serem usadas em um host que compartilha Internet, hospeda sites WEB, ou se conecta à VPNs.

Especialistas que trabalham com firewall, para fugir destes problemas, utilizam scripts customizados com iptables, porém a sintaxe do iptables é pesada e cheia de parâmetros, uma letra errada e o firewall deixa de fazer aquilo que é necessário.

Geralmente os scripts de iptables são extensos e difíceis de manter e alterar, a simples troca física de uma placa de rede queimada “pode” inutilizar todo o script (pois algumas distribuições alteram o nome do device da placa de rede de /dev/eth0 para /dev/eth1, por exemplo), de forma que o script é para quem sabe e tem experiência comprovada.

iptables -t filter -A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -i eth0 -o eth1 -j ACCEPT
iptables -t filter -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t mangle -A PREROUTING -i eth0 -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -m connmark --mark 1 -j MARK --set-mark 1
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

Por causa desta complexidade do iptables, normalmente evita-se ao máximo a configuração de DMZs.

DMZ para quem não conhece significa Zona Desmilitarizada, esta expressão serve para designar, uma rede/zona fisicamente separada da rede local (rede privativa em que ficam apenas os servidores da empresa).

Na DMZ ficam instalados apenas os servidores da empresa, desta forma, torna-se possível interceptar toda a comunicação entre os servidores e o mundo externo (Internet e rede local) de forma que apenas as portas necessárias sejam liberadas. Esta comunicação já restrita com o mundo externo pode ainda ser auditada por um sniffer (programa que captura pacotes de comunicação de dados) revelando detalhes importantes de tudo que passa pelo firewall e é enviado para os servidores.

Lendo isto, o leitor se pergunta, se DMZ é tão bom, porque não é muito utilizada?

Exatamente por tornar ainda mais complexa a configuração dos scripts de iptables.

O iptables é um comando que surgiu no Netfilter com o Kernel 2.4 do Linux, em substituição ao ipchains do Kernel 2.2.

O iptables, ao contrário de 99.9% dos programas Linux não roda como daemon, o iptables não fica residente na memória consumindo recursos do Kernel, na verdade o iptables apenas altera o estado de algumas tabelas de tratamento de pacotes de rede internas do Kernel, estas tabelas são:

filter (INPUT, OUTPUT, FORWARD)
nat (PREROUTING, OUTPUT, POSROUTING)
mangle (PREROUTING e OUTPUT)

O nome destas tabelas (filter, nat e mangle) não é nada importante se você utiliza o Shorewall, pois ele fornece um ambiente de configuração em alto nível onde estes nomes de tabelas e de cadeia (PREROUTING, FORWARD, POSROUTING) nunca são utilizados. Você passa a usar as chamadas “zonas” ou “zones” dentro das quais você virtualiza o tratamento das regras e políticas de firewall/roteamento com nomes mais próximos como “loc” = rede local, “net” = internet, “dmz” = área de servidores, “vpn” = conexões através de túneis criptografados, “dir” = diretoria, “prod” = produção, etc.

Entre estas “zonas” selecionadas, basicamente 2 tipos de operação sempre serão utilizados:

ACCEPT – aceita o pacote e permite o “processamento” do pacote.
DROP – descarta o pacote e encerra o “processamento”, como se ele jamais tivesse existido.

Descartar um pacote com DROP, não é o mesmo que rejeitar, cancelar ou bloquear pois o pacote foi recebido, verificado e simplesmente desconsiderado. É como se o Kernel dissesse: desisti, não vou fazer mais nada com este pacote e o descartasse simplesmente, jogando-o fora.

Por serem processados dentro do Kernel, os comandos de firewall do Linux (ACCEPT e DROP) configurados pelo iptables, ou pelo Shorewall, são extremamente eficientes e seguros pois nem o usuário, nem o root, nem ninguém interfere neste processamento interno.

A única forma de modificar este comportamento do Kernel é ligando, desligando, ou reiniciando o Shorewall, para tanto, como o Shorewall não é um Daemon basta executar os comandos abaixo como root, isto em qualquer distribuição:

shorewall stop
shorewall start
shorewall restart

Ao ligar, parar ou reiniciar, o Shorewall processa primeiro todas as configurações de rede, a seguir processa todas as regras e por fim processa todas as políticas para os itens sem regras definidas, verificando a sintaxe item a item. Quando esta verificação termina com sucesso, somente então o Shorewall vai mudar instantaneamente o estados de todas as tabelas de tratamento de pacotes do Kernel em uma única ação. Enquanto houver algum erro de sintaxe, esta ação final não acontece e o Shorewall retorna o número da linha na qual o erro de configuração foi detectado para que você faça a correção.

A utilização do Linux como firewall não consome praticamente recursos, o que permite que processadores muito leves como o Atom sejam usados em um firewall de configurações básicas. Muitos firewalls Linux ainda rodam com micros Pentium I e AMD-K6-II.

Por este mesmo motivo muitos roteadores embarcados utilizam Kernel Linux em seu firmware, pois os recursos necessários para o uso são muito poucos.

O que é o Shorewall?

Conheci o Shorewall em 2002, na época eu usava ainda o RedHat 8.0 com Kernel 2.4, o Shorewall foi a primeira ferramenta de configuração de firewall que conheci. O Shorewall costumava vir na distribuição Mandrake Security e numa distribuição de roteador/firewall que rodava em disquetes de 3 1/2” de 1.44MegaBytes chamada LEAF (leaf.sourceforge.net).

E o que é o Shorewall?

Hoje, depois de anos de uso, costumo definir o Shorewall como: um configurador de iptables inteligente, ou como: a melhor metodologia de configuração de firewall Linux.

O Shorewall ao contrário do iptables, não é um amontoado de parâmetros e sintaxes que se acumulam em linha de comando formando um script frankenstain, o Shorewall é antes de mais nada uma metodologia sistemática de configuração de firewall baseado em linha de comando e que requer pouquíssimos minutos para configurar qualquer cenário.

Suas configurações não possuem dependências em cascata, os arquivos de configuração são independentes, estruturados e integrados.

Basicamente a sequência de configuração para criação, modificação ou verificação do Shorewall é:

Configurar as zonas no arquivo “zones”
Configurar as políticas no arquivo “policy”
Configurar as regras no arquivo “rules”

Lógico que existem outros arquivos importantes que você configura toda vez que altera o Hardware do Linux, mas uma vez colocado em produção e não havendo mais modificações de Hardware, você precisará mexer apenas nestes 3 arquivos, exatamente nesta sequência.

Seja em um firewall simples, como o de um roteador de caixinha com apenas 2 zonas físicas, seja como um firewall corporativo ligado à várias VPNs de diferentes tipos (IPsec, PPTP, OpenVPN), à várias redes (diretoria, comercial, administrativo, produção), DMZs e zonas, o Shorewall é de fato a ferramenta que garante o mais baixo tempo de configuração/manutenção/alteração de firewall mesmo em cenários complexos com uma margem Zero de Erro.

Quando dizemos margem Zero de Erro, isto se refere ao funcionamento dos comandos configurados. Logicamente se o ser humano fizer uma configuração errada, mas com sintaxe correta, o Shorewall vai aceitar, processar e implantar a regra ou política.

O Shorewall é um dos únicos programas para Linux que não requer nenhuma dependência de pacotes para instalar.

Sabendo que o único requisito do Shorewall é o comando iptables e que o iptables é parte integrada do Kernel Linux, então, em todas as distribuições Linux, sempre o Shorewall vai ser fácil e rápido de instalar pois não possui qualquer dependência.

O pacote de instalação rpm da última versão estável do Shorewall (4.4.18) para distribuições RedHat, Fedora, Centos, Suse e Mandriva tem 390Kbytes de tamanho.

O arquivo do código fonte compactado para todas as demais distribuições tem apenas 362Kbytes.

O Ubuntu e o Debian possuem pacotes deb para download pelo apt-get ou pelo aptitude.

Assim em poucos minutos você baixa o Shorewall da Internet, instala, compila e configura desde um RedHat 8.0 com Kernel 2.4 à ultima versão do Ubuntu, Debian, Centos, etc.

A sintaxe do Shorewall é idêntica em todas as distribuições Linux, de forma que você consegue padronizar a manutenção de firewall em ambientes heterogêneos, redes pequenas, médias, grandes e gigantescas.

A documentação disponível para o Shorewall é também muito farta, de ótima qualidade e muito simples de entender, porém está apenas disponível em inglês (www.shorewall.net).

Antes e Depois do Shorewall

Para exemplificar melhor os benefícios do Shorewall vamos fazer uma análise, comparando o Antes e o Depois de uma Consultoria Linux que utilizava scripts iptables em seus clientes.

Veja alguns exemplos de comandos iptables, muito fácil de se perder nestes números, códigos e sintaxe antinatural:

iptables -t filter -A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -i eth0 -o eth1 -j ACCEPT
iptables -t raw -P OUTPUT ACCEPT
iptables -t filter -A FORWARD -d SERVIDOR_WEB -i INTERFACE_EXTERNA -o INTERFACE_INTERNA -j ACCEPT
iptables -t filter -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t mangle -A PREROUTING -i eth0 -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -d SERVIDOR -j CONNMARK --set-mark 1
iptables -t mangle -A OUTPUT -m connmark --mark 1 -j MARK --set-mark 1
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

O perfil dos clientes era heterogêneo, cada cliente usava uma distribuição Linux diferente, havia clientes com DMZ, outros com VPN IPsec, outros utilizavam OpenVPN, outros PPTP.

Alguns servidores eram firewalls dedicados, outros também compartilhavam arquivos através de Samba, outros hospedavam sites e servidores de E-mail, e assim, constantemente ocorriam problemas de configuração de firewall, a maior parte dos técnicos não conseguia atender os casos mais complicados e o Gerente de Suporte da consultoria dependia de um único técnico sênior mais experiente, caso ele faltasse ou morresse o suporte a seus maiores clientes ficaria paralisado.

Antes do Shorewall	Depois do Shorewall
Os técnicos mais novos tinham dificuldades de entender os scripts de configuração do iptables e como o técnico sênior mais experiente estava sempre sobrecarregado, não havia como capacitá-los a atender os clientes de firewall.	Como o Shorewall segue uma metodologia que divide em camadas/etapas a configuração do firewall, com a adoção do Shorewall, os técnicos mais novos conseguiram atender os clientes menores e aos poucos foram ganhando experiência para atender aos grandes clientes.
A placa de rede queimou (/dev/eth0), foi substituída por uma nova, mas o Fedora reconheceu a placa nova como outro dispositivo (/dev/eth1), o script de firewall deixou de funcionar e o técnico mais novo quando abriu o script não sabia o que fazer. O cliente ficou parado até que o técnico sênior tivesse tempo de realizar a manutenção.	Na metodologia do Shorewall, as configurações são feitas a partir das “zonas”. Zonas, são conjunto de redes físicas agrupadas por afinidade e configuradas num único arquivo (/etc/shorewall/interfaces), por telefone o técnico novo foi instruído a editar o arquivo de “interfaces” e com a alteração de um único número de forma quase mágica o firewall já estava totalmente reconfigurado.
O servidor de ERP do cliente estava na mesma rede física das estações Windows e constantemente era alvo de acessos indevidos e ataque de vírus, o uso de um antivírus no servidor ia causar lentidão e as atualizações de segurança constantemente causavam problemas de incompatibilidade e travamento do ERP. Como era um equipamento importante ninguém se arriscava a mexer no servidor, mas ele estava parando.	Foi proposto ao cliente, modificar sua infraestrutura física de rede e implantar uma DMZ. O servidor de ERP ficou na nova DMZ separado fisicamente da rede de estações Windows, todas as portas de acesso não usadas foram bloqueadas e apenas as portas de acesso essenciais foram liberadas. O firewall do servidor ERP tornou-se desnecessário, os problemas de segurança diminuíram, e com o uso de sniffers foram identificados todos os micros que faziam acesso indevido. Os respectivos funcionários que faziam os acessos ilegais foram desligados da empresa.
O técnico sênior entrou de férias e o cliente mais importante ligou dizendo que o seu firewall havia parado. Não havia como atender o cliente e por telefone era impossível dar suporte aos técnicos mais novos devido à complexidade do script de iptables. O cliente acabou achando outra empresa que passou a dar suporte em seu firewall.	Devido à metodologia do Shorewall, em poucos passos o problema foi identificado, através do celular, o técnico sênior deu as orientações devidas e rapidamente os técnicos mais novos conseguiram fazer o servidor de firewall voltar a funcionar. O cliente ficou satisfeito e renovou o contrato de suporte.
Devido à uma parceria, um cliente precisava ativar uma VPN interligando sua empresa a outra no exterior. Não havia muita informação, o firewall precisaria ser reconfigurado, mas a empresa já utilizava DMZ e várias redes físicas, seria difícil alterar o script do iptables sem causar problemas pois ela já era gigantesco.	Com poucos arquivos, o Shorewall consegue configurar cenários complexos de infraestrutura. Foi preciso alterar apenas 2 arquivos no Shorewall, o (/etc/shorewall/tunnels), e o (/etc/shorewall/interfaces) para configurar a VPN no firewall, algumas regras foram criadas (/etc/shorewall/rules) deixando passar pela VPN apenas o que era autorizado. Havia comunicação entre a empresa e o exterior, mas a segurança era elevada.
Um cliente possuía uma rede de lojas, cada qual com um tipo diferente de conexão de internet: IP Dinâmico, PPPOE, IP-Fixo, Internet via rádio sem IP Válido, Link Dedicado. Para interligar os Servidores das lojas eram utilizados roteadores de caixinha com VPNs simples. Com o tempo percebeu-se que através VPNs estavam sendo propagados Vírus e Cavalos de Tróia (Trojan) que contaminaram todas as lojas da rede. Não havia segurança para os Servidores pois eles estavam sob constante ataque.	Todos os roteadores de caixinha foram substituídos por servidores Linux de firewall com Shorewall, Squid e OpenVPN. Todo o acesso à Internet agora era interceptado pelo Proxy que bloqueava sites não autorizados e gerava histórico de auditoria. Todo o tipo de envio de E-mail também foi bloqueado, ficando liberado apenas o E-mail corporativo que possuía auditoria. Os Servidores que precisavam se comunicar foram instalados dentro de DMZs fisicamente separadas e VPNs foram conectadas entre os Shorewalls permitindo que apenas os Servidores se comunicassem, deixando todas as demais estações Windows sem acesso às VPNs. Mesmo entre os Servidores apenas poucas portas autorizadas foram liberadas de forma que a segurança entre os Servidores aumentou e a rede estabilizou. Como cada loja era diferente, todos os firewalls tinham configurações diferentes, mas a linguagem padronizada do Shorewall permitiu a implantação em tempo recorde.
O cliente possuía meia hora de prazo para enviar um arquivo pela Internet e não haviam técnicos disponíveis para enviar ao local, mesmo que houvessem eles gastariam mais de meia hora para chegar e não haveria mais tempo para restabelecer a Internet e enviar o arquivo.	Através do Telefone, o cliente foi sendo instruído a fazer através do terminal em modo texto as alterações no Shorewall, em poucos minutos a configuração foi alterada e dentro do prazo o cliente conseguiu restabelecer a Internet e enviar o seu arquivo.
O firewall era muito antigo e não havia nenhuma documentação, mesmo o técnico sênior demoraria algumas horas para revisar e atualizar o script de iptables pois não havia nada disponível que explicasse o que estava instalado.	Por sua metodologia, o Shorewall se auto documenta. Ao preencher os arquivos de configuração do Shorewall, a lógica das camadas permite compreender, mesmo nos cenários mais complexos a regras e políticas do firewall e as linhas gerais. Mesmo sem documentação uma pessoa que teve treinamento em Shorewall consegue entender rapidamente.
Por causa da grande quantidade de estações (240 micros) a rede local foi segmentada em 4 partes para diminuir o broadcast e lentidão. Foram instaladas 4 placas de rede diferentes e em cada sub-rede foram conectados 60 micros. O problema de lentidão que existia desapareceu, contudo, quando chegou na configuração do firewall ninguém conseguiu alterar o script de iptables, o técnico sênior teve de ser chamado e a reconfiguração do firewall demorou bastante.	Ao mudar a configuração da rede local de 1 para 4 placas de rede, no Shorewall foi necessário alterar apenas um único arquivo, o (/etc/shorewall/interfaces). Foram adicionadas 3 linhas à configuração existente e mais nada foi necessário, em 5 minutos o firewall foi reconfigurado e atualizado para a nova instalação.
O técnico sênior estava alterando um script de iptables de um cliente importante. Quando o novo script foi colocado para funcionar, parou no meio da execução. O erro de script parou a empresa por um bom tempo até que o técnico sênior conseguisse corrigir o problema. O nervosismo atrapalhou bastante, bem como a pressão do cliente que estava com a empresa parada.	Na metodologia do Shorewall, não existe este risco. Quando ocorre uma alteração de configuração, antes de aplicar estas alterações de estado nas tabelas de tratamento de pacotes do Kernel, o Shorewall revisa todas as linhas de configuração. Caso haja um erro de sintaxe ele pára e sinaliza a linha em que o erro ocorreu para que você possa corrigí-lo antes de colocá-lo para funcionar. Somente depois de revisar toda a configuração e eliminar todos os erros de sintaxe o Shorewall altera o estado das tabelas do Kernel. Assim o risco de travar no meio da execução da nova configuração é Zero. Ao final da compilação, a aplicação das novas regras e políticas do firewall ocorre instantaneamente e o cliente que continuou trabalhando normalmente nem percebe quando a mudança ocorre.
Todos os micros e servidores da empresa foram roubados e não existe documentação do firewall, os técnicos mais novos não sabem configurar do zero o firewall.	Um sniffer foi instalado no firewall, e com os dados coletados o Shorewall foi configurado, liberando apenas as portas de comunicação e os serviços autorizados. Mesmo sem documentação rapidamente a maior parte da configuração foi realizada para a empresa voltar a funcionar, depois com calma o técnico sênior revisou o Shorewall e finalizou os últimos detalhes.

Com os exemplos do Antes e Depois do Shorewall, você percebeu que o uso de DMZ é vital para empresas médias e grandes.

Observou também que o Shorewall requer o mínimo de alteração para suportar novas placas de rede, aproveitando toda a configuração já existente no firewall.

Com o Shorewall torna-se possível que até pessoas leigas, como o cliente, façam alterações no firewall através de suporte telefônico pois ele precisa apenas alterar poucos parâmetros de pequenos arquivos organizados por função, a sintaxe é simples de ser compreendida.

O Shorewall é tão fácil de usar que eu não costumo carregar templates de configuração. Em cada novo cliente eu baixo a última versão do Shorewall da Internet e faço as configurações a partir do Zero.

É importante notar que para instalar VPNs é preciso instalar outros programas no Linux além do Shorewall, pois o Shorewall sozinho não levanta uma VPN, é preciso ativar o IPsec, instalar o OpenVPN, ou PPTP.

O Shorewall também tem suporte a controle de tráfego, mas também depende da instalação de programas adicionais que implementam estes novos recursos.

O Shorewall possui uma versões diferentes para IP-V4 e para IP-V6.

Instalando o Shorewall

Baixe o Shorewall sempre do site oficial: www.shorewall.net, lá existe farta documentação e informações importantes.

Em distribuições RedHat, Fedora, Centos basta executar o comando:

yum install shorewall

Em distribuições Debian e Ubuntu e seus derivados basta executar:

apt-get update
apt-get install shorewall

Configurando o Shorewall

Muitas distribuições instalam o Shorewall sem nenhum arquivo de configuração, neste caso você precisará saber quais arquivos devem ser criados e a sintaxe de cada arquivo de configuração, para tanto, no site do Shorewall existe um arquivo de documentação shorewall-docs-html-4.4.18.tgz.

Arquivos de configuração que nunca podem faltar no Shorewall

e que em alguns casos precisam ser criados do Zero

/etc/shorewall/shorewall.conf (requer que você altere STARTUP_ENABLED=Yes )
/etc/shorewall/zones (requer 2 zonas obrigatórias: fw e net)
/etc/shorewall/interfaces (uma zona pode ter várias placas de rede/interfaces)
/etc/shorewall/masq (possibilita a configuração de NAT)
/etc/shorewall/tunnels (configuração de VPNs)
/etc/shorewall/policy (políticas - configuração geral de uma zona)
/etc/shorewall/rules (regras de firewall – se sobrepõe à policy que só vale quando não existem regras definidas no rules)

O que são estes arquivos de configuração principais do Shorewall?

O /etc/shorewall/shorewall.conf só é alterado manualmente, uma vez habilitado o STARTUP_ENABLED=Yes você nunca mais vai usar este arquivo novamente, se você esquecer disto, o Shorewall não sobe, não funciona, fica inativo.

O arquivo de /etc/shorewall/zones é o ponto de partida de toda a configuração, nele são batizadas as zonas, ou redes lógicas que serão utilizadas para agrupar, organizar e controlar as redes físicas existentes. Devem sempre ser usados nomes fáceis que lembrem a função de cada zona, como por exemplo, prod para produção, dir para diretoria, mkt para marketing. Mas existem sempre 2 zonas obrigatórias sem as quais o Shorewall não consegue funcionar: a zona “fw' corresponde à rede física do loopback (127.0.0.1) que representa o Kernel Linux, e a zona “net”, que é a zona externa: a rede local ou a Internet.

O arquivo /etc/shorewall/interfaces é a última referência que se faz às redes físicas numa configuração default. Se for tudo default, a partir deste ponto, toda a configuração do Shorewall não usará mais referências a dispositivos físicos ou endereços de rede IP. Os endereços IPs só voltarão a aparecer no arquivo de regras de firewall (/etc/shorewall/rules) caso seja necessário um ajuste fino. No arquivo de “interfaces” você cadastra todas as interfaces físicas (placas de rede) e lógicas de rede (túneis e VPNs), vinculando estas interfaces a zonas previamente registradas no arquivo de “zones”. Para vários Links de Internet redundantes, você vincula-os à zona “net”. Caso você particione a sua rede local em várias sub-redes através de diferentes placas físicas de rede, todas estas placas serão vinculadas à rede “loc”, o alias da rede local. Caso haja uma placa de rede estabelecendo uma rede física privativa da diretoria, você a vincula na zona “dir”, e assim por diante. O arquivo de “interfaces” é extremamente poderoso, pois pode cadastrar infinitos túneis de VPNs, de forma que a gestão de redes remotas fica extremamente fácil e flexível. O Linux por sua vez, levanta devices lógicos de túneis que podem tranquilamente variar de /dev/tun0, /dev/tun1 a /dev/tun2999, por exemplo, a princípio não existem limitações quanto à quantidade.

O arquivo /etc/shorewall/masq é usado para configurar o NAT (Network Address Translation). O NAT permite que redes locais utilizem apenas um único IP-Válido para ter acesso à Internet. Nos dias de hoje com o fim dos endereços IP-V4 disponíveis isto é vital. Para configurar o NAT bastam 2 palavras, que o NAT é totalmente configurado para uma dada interface de rede.

Em casos raros, você configura o NAT no “masq”, mas o roteamento não funciona, tive problemas deste tipo diversas vezes, com o Kurumin 7, por exemplo, nestes casos a solução é muito simples, basta fazer um append e acrescentar no arquivo /etc/rc.local a seguinte instrução:

echo “1” > /proc/sys/net/ipv4/ip_forward

Com isso você ativa o roteamento de pacotes do Kernel e o NAT vai começar a funcionar normalmente.

O arquivo /etc/shorewall/tunnels é verdadeiramente mágico, pois permite liberar a entrada de túneis e VPNs no Shorewall, sem que estes túneis estejam conectados a nenhuma zona. Assim as VPNs sincronizam mas não conseguem transmitir dados, deixando à cargo do administrador do Shorewall a liberação porta a porta dos acessos necessários na mais alta segurança.

Tipos de VPNs suportadas pelo Shorewall

6to4 - 6to4 or 6in4 tunnel
ipsec - IPv4 IPSEC
ipsecnat - IPv4 IPSEC with NAT Traversal (UDP port 4500 encapsulation)
ipip - IPv4 encapsulated in IPv4 (Protocol 4)
gre - Generalized Routing Encapsulation (Protocol 47)
l2tp - Layer 2 Tunneling Protocol (UDP port 1701)
pptpclient - PPTP Client runs on the firewall
pptpserver - PPTP Server runs on the firewall
openvpn - OpenVPN in point-to-point mode
openvpnclient - OpenVPN client runs on the firewall
openvpnserver - OpenVPN server runs on the firewall
generic - Other tunnel type

O arquivo /etc/shorewall/rules é o coração do firewall, é nele que os ajustes finos são realizados e também é nele que as exceções e regras são definidas. Com o uso de IPs torna-se possível, liberar ou bloquear micros individualmente ou em grupos, portas e protocolos individualmente ou em grupos. No arquivo de “rules” você não precisa definir regras para todos os micros, apenas para os que foram diferentes ou necessitarem de tratamento especial. Toda vez que para um dado micro ou servidor não houver “nenhuma regra definida”, então nestes casos que são a grande maioria, outro arquivo de configuração será utilizado, o arquivo de “policy”.

O arquivo /etc/shorewall/policy sempre deve ser configurado antes do arquivo de “rules”, a função do arquivo de “policy” é definir políticas de firewall que são aplicadas toda a vez que não houver nenhuma regra (rule) estabelecida para um dado micro ou servidor. Nas configurações mais básicas, muitas vezes apenas configurando o arquivo de “policy” você já termina a configuração do Shorewall. No Exemplo 1 podemos ver que o arquivo de “rules” é totalmente desnecessário, caso o usuário não deseje acesso remoto via SSH.

Exemplos de uso do Shorewall

Nesta seção, estaremos colocando exemplos reais retirados de casos reais, nos quais você poderá aprender passo a passo, como evolui a configuração do Shorewall, partindo do cenário mais simples, para o mais complexo. Você poderá observar que existem configurações comuns que quase não mudam e que se você entender o mais simples, pouco a pouco também aprenderá o mais complexo.

Exemplo 1 - Configuração do Shorewall p/ Linux Desktop

Neste exemplo existe apenas uma zona física ligada ao mundo externo, a “net”. A zona “fw” é uma zona virtual criada obrigatoriamente pelo Shorewall para impedir toda a comunicação não autorizada pelo administrador.

/etc/shorewall/zones

fw firewall

net ipv4

Existe apenas uma interface de rede (/dev/eth0), chamada simplesmente de eth0. No Linux, eth0 é a primeira placa de rede física detectada pelo Kernel. A opção “dhcp”, permite que o IP desta placa de rede receba do provedor de Internet um IP dinâmico automaticamente. Sem a opção de “dhcp”, você terá que configurar este IP manualmente.

/etc/shorewall/interfaces

net eth0 detect dhcp

A seguir temos o arquivo de políticas do firewall que é muito simples. A primeira linha é quase sempre obrigatória, pois “fw” é o root das redes e geralmente tem direito de acesso total a todos (all).

A última linha “sempre é” obrigatória, o objetivo desta linha é bloquear qualquer possibilidade de configuração que tenha sido esquecida na “policy” e nas “rules”, ou que não tenha sido definida corretamente. A opção “info” da última linha é usada para gerar log de todas as tentativas descartadas (DROP) desta tentativa de comunicação “all” to “all”. Lembre-se sempre que o arquivo de “policy” sempre é o último arquivo de configuração lido pelo Shorewall, nele, tudo que ainda não tiver sido configurado através de uma regra será tratado por uma política e a última das políticas sempre deverá ser: “all” to “all” DROP info

A linha do meio fecha totalmente o firewall para o mundo externo (net), a única coisa que pode entrar pela placa de rede “eth0” agora é o sinal de dhcp que vai configurar o IP da eth0 quando o Linux ligar, isto foi configurado anteriormente no arquivo /etc/shorewall/interfaces com a opção “dhcp”. “net all DROP” significa que tudo o que vier de fora do firewall/micro/servidor será descartado (DROP), nem ping, nem SSH podem passar. Porém, usando interface gráfica neste micro, você poderá estar sujeito à invasões e vulnerabilidades, pois serviços internos ao seu Desktop podem enviar pacotes para fora e abrir entradas no firewall. Quando isto ocorre, as respostas aos pacotes de dados vindas do exterior penetram pela interface de rede eth0, pois herdam as propriedades de liberação dos pacotes que saíram.

/etc/shorewall/policy

fw all ACCEPT

net all DROP

all all DROP info

Exemplos do Shorewall como roteador (c/ mais de 1 placa de rede)

A partir deste exemplo, todas as placas de rede físicas devem ter IP-Fixo configurado manualmente, não use o Network-Manager.

Exemplo 2 - Configuração do Shorewall para roteador doméstico

com conexão PPPOE (ADSL)

Neste segundo exemplo, temos um micro com 2 placas de rede, uma ligada ao mundo exterior (ppp0 = Internet = net) com IP válido, e uma ligada à rede local (eth1 = loc) com IP privado, esta configuração muito simples e insegura do Shorewall é idêntica a 99.9% dos roteadores domésticos e serve apenas para compartilhar Internet pouquíssima segurança.

Em relação ao Exemplo 1, uma zona adicional foi cadastrada, a zona “loc” que é alias de rede local.

/etc/shorewall/zones

fw firewall

net ipv4

loc ipv4

Com duas placas de rede, temos então a necessidade de 2 linhas no arquivo de “interfaces”. Caso o administrador esqueça de 1 destas linhas, o Shorewall deixa de ser um roteador e torna-se apenas mais um micro comum. Nas duas interfaces de rede temos a opção “dhcp”, isto significa que o IP Válido externo é dinâmico e que a zona “loc” também está liberada para “dhcp”.

/etc/shorewall/interfaces

net ppp0 detect dhcp

loc eth1 detect dhcp

A linha abaixo não existia no Exemplo 1, pois um micro sozinho não faz NAT, já um roteador para compartilhar a Internet, precisa obrigatoriamente fazer NAT, pois existe apenas um único IP Válido conectado à Internet. “pppo” (net) que aparece primeiro é a interface de rede que fornece o sinal de Internet para eth1 da rede local (loc)

/etc/shorewall/masq

ppp0 eth1

A primeira, segunda e última linha são idênticas a do Exemplo 1. Observe que a rede local (loc) está totalmente liberada para acessar a Internet (net), isto significa que estações Windows da rede local (loc) poderão rapidamente pegar vírus e malware logo que alguém clicar em um link malicioso no Internet Explorer.

/etc/shorewall/policy

fw all ACCEPT

net all DROP

loc net ACCEPT

all all DROP info

O arquivo “rules” que não existia no Exemplo 1, agora tem 2 linhas, a primeira libera o ping para todos os micros conectados, tanto interna, quanto externamente, isto não é muito perigoso pois apenas 1 tipo de ping (icmp 8) foi liberado.

A segunda linha libera o acesso remoto criptografado via SSH na porta 22. Durante a implantação você pode temporariamente liberar este acesso “all” to “all” de SSH descomentando esta linha, contudo, quando for configurar um servidor de verdade, não deixe esta regra ativa, pois pode representar uma vulnerabilidade muito explorada na Internet. Para bloquear esta regra, basta comentar esta linha com # e reiniciar o Shorewall.

/etc/shorewall/rules

ACCEPT all all icmp 8

#ACCEPT all all tcp 22

Exemplo 3 - Configuração do Shorewall para pequena empresa

com compartilhamento de arquivos Samba e conexão PPPOE (ADSL)

Nesta configuração, muitas portas foram bloqueadas para as estações da rede local (loc). Apenas 3 tipos de serviços foram liberados para as máquinas Windows: consulta a DNS (porta udp 53), navegação WEB e HTTPS (portas tcp 80 e 443) e serviços de E-mail SMTP, POP3 e IMAP (portas tcp 25, 110, 143). Isto torna a rede um pouco mais segura, pois apenas estes serviços podem ser usados pelas máquinas Windows, contudo não temos nenhum recurso de auditoria e controle de acesso à Internet.

/etc/shorewall/zones

fw firewall

net ipv4

loc ipv4

/etc/shorewall/interfaces

net ppp0 detect dhcp

loc eth1 detect dhcp

/etc/shorewall/masq

ppp0 eth1

Esta já é uma configuração mais protegida, veja que na terceira linha a rede local (loc) está totalmente bloqueada (DROP) através de uma política de firewall. Então será necessário criar regras que permitam que micros da rede local acessem a Internet.

/etc/shorewall/policy

fw all ACCEPT

net all DROP

loc all DROP

all all DROP info

Com o bloqueio da rede local (loc) no arquivo de políticas do firewall (policy), foi necessário criar regras para liberar alguns serviços para que a rede local possa acessar a Internet. A quarta linha libera a consulta de DNS (porta udp 53) ao servidor de DNS do Google (IP = 8.8.8.8), este recurso de segurança impede que servidores de DNS comprometidos e invadidos redirecionem os acessos à Internet.

A sexta linha libera o acesso à WEB e HTTPS para os navegadores de Internet.

A oitava linha libera o acesso a serviços de E-mail da Internet: envio de E-mail (SMTP = porta 25), recebimento de E-mail (POP3 = porta 110) e sincronia de E-mail (IMAP = porta 143).

As duas últimas linhas liberam que os micros da rede local (loc) acessem um serviço de compartilhamento de arquivos Samba / CIFS

/etc/shorewall/rules

ACCEPT all all icmp 8

ACCEPT all all tcp 22

# A linha abaixo libera servidor de DNS do Google

ACCEPT loc net:8.8.8.8 udp 53

# A linha abaixo libera acesso WEB e HTTPS

ACCEPT loc net tcp 80,443

# A linha abaixo libera acesso aos serviços de E-mail

ACCEPT loc net tcp 25,110,143

# As duas linhas abaixo liberam compartilhamento de arquivos / Samba / CIFS

ACCEPT loc fw tcp 137,138,139,445

ACCEPT loc fw udp 137,138,139,445

Exemplo 4 - Configuração do Shorewall para pequena empresa

com compartilhamento de arquivos Samba, transparent proxy

e acesso à Internet por IP Dinâmico (Virtua)

Para saber aonde os usuários da rede local andam navegando na Internet, foi instalado um transparent proxy, um cache de acesso à Internet que permite acelerar o acesso às páginas já navegadas e criar um relatório de uso da Internet.

/etc/shorewall/zones

fw firewall

net ipv4

loc ipv4

No arquivo abaixo a conexão deixa de ser PPPOE para ser uma conexão de IP Dinâmico (eth0).

/etc/shorewall/interfaces

net eth0 detect dhcp

loc eth1 detect dhcp

/etc/shorewall/masq

eth0 eth1

/etc/shorewall/policy

fw all ACCEPT

net all DROP

loc all DROP

all all DROP info

Quando você ativa um transparent proxy, é preciso liberar o acesso de HTTPS (porta 443) à Internet, pois o transparent proxy só consegue trabalhar com a porta 80 da WEB.

/etc/shorewall/rules

ACCEPT all all icmp 8

ACCEPT all all tcp 22

ACCEPT loc net:8.8.8.8 udp 53

# A linha abaixo captura toda a comunicação WEB e redireciona os pacotes para o proxy

REDIRECT loc 3128 tcp 80

# Sem a linha abaixo micros da rede local (loc) não conseguem navegar em HTTPS

ACCEPT loc net tcp 443

ACCEPT loc net tcp 25,110,143

ACCEPT loc fw tcp 137,138,139,445

ACCEPT loc fw udp 137,138,139,445

Exemplo 5 - Configuração do Shorewall para pequena empresa

com compartilhamento de arquivos Samba, proxy autenticado,

VPN c/ OpenVPN e acesso à Internet por IP-Fixo

Neste exemplo, teremos a instalação de uma VPN com OpenVPN. Observe que o arquivo de “zones” precisou ser alterado para receber a zona “vpn”.

/etc/shorewall/zones

fw firewall

net ipv4

loc ipv4

vpn ipv4

O arquivo de “interfaces” também teve que ser alterado para liberar o tun0 que o OpenVPN utiliza para estabelecer a conexão.

/etc/shorewall/interfaces

net eth0 detect

loc eth1 detect dhcp

vpn tun0 detect

O OpenVPN dispensa o uso de NAT, pois ele roteia automaticamente seus pacotes.

/etc/shorewall/masq

eth0 eth1

O arquivo de “tunnels” abre uma porta (1194) da Internet (net) que morre no Shorewall (fw). O endereço 0.0.0.0/0 significa que qualquer IP poderá requisitar a sincronia da VPN, isto é inseguro, contudo, como não sabemos se o outro lado da VPN possui IP-Fixo, não podemos mudar esta configuração por hora.

/etc/shorewall/tunnels

openvpn:1194 net 0.0.0.0/0

A “vpn” é como uma zona normal e precisa ser liberada como as outras, contudo, sempre devemos tomar o cuidado de não liberarmos para a Internet (net), o que nos proíbe de usar a expressão “vpn all ACCEPT”, pois neste caso estaríamos também liberando a “vpn” para Internet.

/etc/shorewall/policy

fw all ACCEPT

net all DROP

loc all DROP

vpn fw ACCEPT

vpn loc ACCEPT

all all DROP info

/etc/shorewall/rules

ACCEPT all all icmp 8

ACCEPT all all tcp 22

ACCEPT loc net:8.8.8.8 udp 53

ACCEPT loc fw tcp 3128

ACCEPT loc net tcp 25,110,143

ACCEPT loc fw tcp 137,138,139,445

ACCEPT loc fw udp 137,138,139,445

Exemplo 6 - Configuração do Shorewall para empresa média

com rede de lojas com DMZs, servidores das DMZs interligados

c/ OpenVPN, proxy autenticado e acesso à Internet por IP-Fixo

Estamos agora entrando num terreno que os scripts de iptables tanto falham. A quantidade de informação aumenta consideravelmente, mas mesmo assim com o Shorewall ainda dá para entender o que acontece.

Um nova zona é acrescentada, a “dmz”, dentro da DMZ somente haverão servidores e nenhuma estação de trabalho.

/etc/shorewall/zones

fw firewall

net ipv4

loc ipv4

dmz ipv4

vpn ipv4

A conexão à Internet (eth0) é IP-Fixo e dispensa o uso de dhcp

/etc/shorewall/interfaces

net eth0 detect

loc eth1 detect dhcp

dmz eth2 detect dhcp

vpn tun0 detect

Veja que com a adição da DMZ (eth2) foi necessário adicionar mais um NAT, sem isto, os servidores não conseguiram se conectar à Internet, nem poderiam ser acessados de fora da empresa.

/etc/shorewall/masq

eth0 eth1

eth0 eth2

/etc/shorewall/tunnels

openvpn:1194 net 0.0.0.0/0

Como não foi declarada uma política para “dmz” to “net”, então, vamos lembrar que vai prevalecer neste caso a opção “all” to “all” = DROP + info, ou seja, será gerado um log de qualquer pacote de dados que sair dos servidores em direção à Internet (net). Em certos casos isto poderá revelar uma vulnerabilidade ou problema de segurança.

/etc/shorewall/policy

fw all ACCEPT

net all DROP

loc all DROP

dmz fw ACCEPT

dmz loc ACCEPT

dmz vpn ACCEPT

vpn fw ACCEPT

vpn dmz ACCEPT

all all DROP info

Todos os servidores da empresa são transferidos para dentro da DMZ onde estarão fisicamente isolados da rede local com máquinas Windows.

/etc/shorewall/rules

ACCEPT all all icmp 8

ACCEPT all all tcp 22

ACCEPT loc net:8.8.8.8 udp 53

ACCEPT loc fw tcp 3128

ACCEPT loc net tcp 25,110,143

# Servidores de compartilhamento de arquivo foi transferido para dentro da DMZ

# juntamente com um servidor WEB/HTTPS que alimentava a Intranet

ACCEPT loc dmz tcp 80,443

ACCEPT loc dmz tcp 137,138,139,445

ACCEPT loc dmz udp 137,138,139,445

Exemplo 7 - Configuração do Shorewall para empresa média

com rede de lojas com DMZs, servidores das DMZs interligados

c/ OpenVPN, proxy autenticado e acesso à Internet duplo c/ failover

(quando conexão de Internet ativa cai, a reserva assume)

/etc/shorewall/zones

fw firewall

net ipv4

loc ipv4

dmz ipv4

vpn ipv4

Veja agora que foram instaladas duas placas de rede (eth0 e eth1) ligadas à Internet (net). Este arranjo permite que em caso de queda de uma conexão, a outra possa assumir a Internet, garantindo que a empresa não pare.

/etc/shorewall/interfaces

net eth0 detect

net eth1 detect

loc eth2 detect dhcp

dmz eth3 detect dhcp

vpn tun0 detect

Com duas placas de rede, a quantidade de NATs tem que ser dobrada, caso isto não ocorra, quando cair uma internet com NAT, a outra conexão de internet vai subir, mas não vai conseguir alimentar as redes locais com seu acesso.

/etc/shorewall/masq

# NAT da primeira conexão de Internet

eth0 eth2

eth0 eth3

# NAT da segunda conexão de Internet

eth1 eth2

eth1 eth3

Com a instalação do acesso duplo de Internet, observe que nenhuma configuração abaixo foi alterada, tudo ficou como antes. Em toda a configuração apenas 3 linhas foram adicionadas para reconfigurar todo o Shorewall.

/etc/shorewall/tunnels

openvpn:1194 net 0.0.0.0/0

/etc/shorewall/policy

fw all ACCEPT

net all DROP

loc all DROP

dmz fw ACCEPT

dmz loc ACCEPT

dmz vpn ACCEPT

vpn fw ACCEPT

vpn dmz ACCEPT

all all DROP info

/etc/shorewall/rules

ACCEPT all all icmp 8

ACCEPT all all tcp 22

ACCEPT loc net:8.8.8.8 udp 53

ACCEPT loc fw tcp 3128

ACCEPT loc net tcp 25,110,143

ACCEPT loc dmz tcp 80,443

ACCEPT loc dmz tcp 137,138,139,445

ACCEPT loc dmz udp 137,138,139,445

Shorewall precisa reiniciar a cada mudança de conexão de Internet, é preciso criar um script automático.

Exemplo 8 - Configuração do Shorewall para empresa grande

com rede de lojas com DMZs, servidores das DMZs interligados

c/ OpenVPN, proxy autenticado, acesso à Internet duplo c/ failover

(quando conexão de Internet ativa cai, a reserva assume)

e particionamento de rede local em 4 segmentos físicos

Neste exemplo temos a situação de congestionamento da rede com 240 estações de trabalho que tiveram de ser segmentadas em 4 sub-redes para diminuir o broadcast e melhorar/redistribuir o fluxo de dados

/etc/shorewall/zones

fw firewall

net ipv4

loc ipv4

dmz ipv4

vpn ipv4

Nesta nova configuração apenas 2 arquivos serão alterados, o arquivo de “interfaces” e o arquivo de “masq” responsável pelo NAT. As 3 novas placas de rede foram adicionadas à mesma zona “loc”, desta forma todas as configurações seguintes foram reaproveitadas e a configuração do Shorewall terminou.

/etc/shorewall/interfaces

net eth0 detect

net eth1 detect

loc eth2 detect dhcp

loc eth3 detect dhcp

loc eth4 detect dhcp

loc eth5 detect dhcp

dmz eth6 detect dhcp

vpn tun0 detect

/etc/shorewall/masq

eth0 eth2

eth0 eth3

eth0 eth4

eth0 eth5

eth0 eth6

eth1 eth2

eth1 eth3

eth1 eth4

eth1 eth5

eth1 eth6

/etc/shorewall/tunnels

openvpn:1194 net 0.0.0.0/0

/etc/shorewall/policy

fw all ACCEPT

net all DROP

loc all DROP

dmz fw ACCEPT

dmz loc ACCEPT

dmz vpn ACCEPT

vpn fw ACCEPT

vpn dmz ACCEPT

all all DROP info

/etc/shorewall/rules

ACCEPT all all icmp 8

ACCEPT all all tcp 22

ACCEPT loc net:8.8.8.8 udp 53

ACCEPT loc fw tcp 3128

ACCEPT loc net tcp 25,110,143

ACCEPT loc dmz tcp 80,443

ACCEPT loc dmz tcp 137,138,139,445

ACCEPT loc dmz udp 137,138,139,445

4 placas de rede segmentam fisicamente a Rede Local em 4 redes IP-V4

Shorewall precisa reiniciar a cada mudança de conexão de Internet, é preciso criar um script automático.

Exemplo 9 - Configuração do Shorewall para empresa grande

com rede de lojas com DMZs, servidores das DMZs interligados

c/ OpenVPN, várias VPNs diferentes, proxy autenticado, acesso à Internet duplo

c/ failover (quando conexão de Internet ativa cai, a reserva assume)

e particionamento em várias zonas

(diretoria, 2 redes locais, produção)

Nesta outra configuração, verificou-se que a adição de novas zonas simplificaria muito as configurações de regras do firewall. Agrupando a diretoria em uma rede privativa, não seria mais necessário liberar as máquinas dos diretores por IP (ajuste fino), além disso, os micros da diretoria passariam a estar fisicamente separados e altamente protegidos do restante da empresa, como se estivessem dentro de uma DMZ particular.

Outra alteração foi que os micros da produção foram isolados totalmente de Internet, pois na produção haviam equipamentos CLP ligados em TCP/IP que poderiam ser alvo de invasões e ataques que poderiam paralisar totalmente e indústria.

/etc/shorewall/zones

fw firewall

net ipv4

loc ipv4

dir ipv4

prod ipv4

dmz ipv4

vpn ipv4

/etc/shorewall/interfaces

# duas entradas de internet sao vinculadas a zona net

net eth0 detect

net eth1 detect

# duas redes fisicas sao vinculadas a mesma zona loc

loc eth2 detect dhcp

loc eth3 detect dhcp

prod eth4 detect dhcp

dir eth5 detect dhcp

dmz eth6 detect dhcp

# varios tuneis de são vinculados a uma unica zona de vpn

vpn tun0 detect

vpn tun1 detect

vpn tun2 detect

vpn tun3 detect

/etc/shorewall/masq

# eth0 = primeiro acesso de internet

eth0 eth2

eth0 eth3

eth0 eth4

eth0 eth5

eth0 eth6

# eth1 = segundo acesso de internet

eth1 eth2

eth1 eth3

eth1 eth4

eth1 eth5

eth1 eth6

Nesta configuração também o número de VPNs aumentou muito, contudo, isto não alterou em nada as configurações do Shorewall

/etc/shorewall/tunnels

# sempre comente seus tuneis, 0.0.0.0/0 quer dizer qualquer endereço IP da Internet

# isto pode ser inseguro

openvpn:2000 net 0.0.0.0/0

openvpn:2001 net 0.0.0.0/0

openvpn:2002 net 0.0.0.0/0

openvpn:2003 net 0.0.0.0/0

/etc/shorewall/policy

fw all ACCEPT

net all DROP

loc all DROP

prod all DROP

dir net ACCEPT

dir loc ACCEPT

dmz fw ACCEPT

dmz loc ACCEPT

dmz prod ACCEPT

dmz dir ACCEPT

dmz vpn ACCEPT

vpn fw ACCEPT

vpn dmz ACCEPT

all all DROP info

/etc/shorewall/rules

ACCEPT all all icmp 8

ACCEPT all all tcp 22

ACCEPT loc net:8.8.8.8 udp 53

ACCEPT loc fw tcp 3128

ACCEPT loc net tcp 25,110,143

ACCEPT loc dmz tcp 80,443

ACCEPT loc dmz tcp 137,138,139,445

ACCEPT loc dmz udp 137,138,139,445

# equipamentos da produção apenas podem acessar os servidores da DMZ

ACCEPT prod dmz tcp 80,443

ACCEPT prod dmz tcp 137,138,139,445

ACCEPT prod dmz udp 137,138,139,445

Diretoria tem pleno acesso à Internet e Rede Local

Produção não tem acesso à Internet, apenas aos servidores da empresa

Shorewall precisa reiniciar a cada mudança de conexão de Internet, é preciso criar um script automático.

Configurações úteis e regras comentadas

O que não se deve fazer

No arquivo de “rules” você jamais deverá colocar endereços de servidores ou estações usando dns/fqdn. O motivo é simples, na primeira queda da Internet, se você tentar restartar o Shorewall ele tentará resolver o nome do host para aplicar a regra que referencia este dns, não conseguindo o Shorewall automaticamente pára, e você não tem alternativa, tem que comentar a regra para o Shorewall iniciar. Exemplo:

ACCEPT loc net:pop3.uol.com.br tcp 110

www.shorewall.com.br

quinta-feira, 19 de maio de 2011

Revista PC & Cia publica artigo sobre o shorewall

O ser humano erra, o shorewall não