Início
#1Sáb 25 maio - 19:26
O que são firewallsUm firewall é a proteção mais básica que um cliente ou mesmo que um servidor deve ter e a primeira linha de defesa de qualquer rede. Sem empregar algum tipo de firewall, fica impossível isolar redes confiáveis de redes não confiáveis ou mesmo impedir que hosts indesejados conectem-se aos serviços disponibilizados pelos nossos servidores.
Da criação de sua primeira geração em 1988, por engenheiros da DEC (Digital Equipment Corporation), até hoje, os firewalls já evoluíram muito. Evoluíram a tal ponto que pouco lembram os primeiros filtros de pacotes que foram implantados em redes. Hoje em dia firewalls conseguem filtrar pacotes por porta, endereços IP, protocolo, conseguem interpretar protocolos e até mesmo os dados que estão dentro dos pacotes e só então tomarem uma decisão sobre o que fazer com eles, sempre obedecendo a política que você configurou nele. Além disso, firewalls mais atuais conseguem até bloquear determinados ataques tanto contra o sistema operacional quanto contra a aplicação hospedada pelo host (inclusive aplicações web!).
O que é um firewall?
Para que você consiga manter a segurança de uma rede, é necessário que você a isole de outras redes que não são tão seguras assim ou mesmo redes que representem perigo para você (como a Internet). Se você não filtrar o tráfego que entra e sai de sua rede, não vai conseguir garantir a segurança dela pois todos terão acesso livre aos recursos oferecidos pela sua rede interna.
Esse é o papel do firewall: isolar uma rede segura para impedir que o tráfego considerado malicioso pela sua política de rede não entre ou saia. Ou seja, o firewall permite a você definir o que pode entrar e o que pode sair. Para exercer este controle, o firewall vai analisar o conteúdo do header do pacote (portas de origem e destino, hosts de origem e destino, as flags do pacote TCP) e, em alguns casos, até mesmo o conteúdo do pacote passando por ele.
Existem firewalls de vários tipos, mas geralmente eles se apresentam de duas maneiras:
Firewalls físicos (também conhecidos como appliances): Estes firewalls geralmente são disponibilizados através de appliances físicas que devem ser colocadas em um rack, por exemplo. Esta appliance é formada por um hardware normal como o de qualquer computador (com diferenças mínimas como um processador ASIC, para melhorar o desempenho de rede dele) e um software especializado em filtrar pacotes. Exemplos deste tipo de firewall são os Cisco PIX (que já não é mais comercializado pela Cisco), Cisco ASA e Juniper Netscreen.Estas appliances chegam a custar milhares de dólares, dependendo do modelo, fora a licença necessária se você quiser expandir a funcionalidade do aparelho. Além disso também oferecem módulos para aumentar ainda mais sua funcionalidade e interfaces gráficas que permitem a você configurar e gerenciar várias appliances ao mesmo tempo. Um exemplo deste tipo de interface é o Cisco Security Manager.
Acredito que o ponto positivo mais atraente seja o desempenho destes equipamentos. Alguns deles conseguem processar vários gigabits de dados por segundo. Porém, isso vem com um preço. E geralmente este preço é bem salgado, chegando ao ponto de ser um impedimento para que empresas de menor porte consigam adquirir um produto deste tipo.
Firewalls lógicos (via software): Esse tem aos montes! Caros, baratos, de graça, que funcionam, que simplesmente enganam, etc. Geralmente, firewalls lógicos em sua maioria são destinados a um público que precise de um nível de segurança mais baixo e que não são técnicos. São geralmente conhecidos como firewalls pessoais.Geralmente, esta funcionalidade é oferecida por suítes de segurança como o Symantec Endpoint Protection que oferece além do firewall um anti-vírus e também um IPS (bem simples, pouco configurável). Existem também os softwares que são especializados em oferecer a funcionalidade de firewall. Um exemplo deste tipo é o Comodo Firewall, que oferece um software de firewall com uma excelente segurança e possui uma versão gratuita.
Uma grande exceção ao que eu falei acima são os firewalls de sistemas operacionais abertos, como Linux e OpenBSD. O Netfilter e o PF são dois grandes firewalls, que oferecem uma segurança absurda (quando bem configurados, obviamente) e um excelente conjunto de funcionalidades. Porém, são geralmente mais utilizados em servidores. Poucos são os clientes que os configuram para melhorar a proteção.
O Windows também oferece um firewall nativo, mas de baixíssima qualidade, desde o Windows XP se não me engano. O problema com este firewall é que sua configuração padrão oferece pouco para aumentar a segurança do usuário e bloqueia apenas os ataques mais simples. Outro grande problema são os usuários que simplesmente entram nas configurações desse firewall e o desabilitam por completo por ele estar causando algum problema por bloquear um software necessário no dia-a-dia de um funcionário. Outras soluções de firewall já oferecem a possibilidade de avisar quando um aplicativo é bloqueado por padrão ou mesmo impedem que o firewall seja finalizado por um usuário sem os privilégios necessários.
Esse firewall foi refeito no Windows Vista/7 e no Windows 8, recém lançado, apresentou várias novidades e agora oferece muito mais opções e uma proteção um pouco mais avançada. Se você não tem como adquirir um firewall de uma empresa de renome, que tenha uma qualidade mais alta, o firewall nativo do Windows vai conseguir quebrar um galho por um tempo, mas assim que tiver a oportunidade não deixe de adquirir uma solução especializada.
Também existem diferenças na forma de se conectar o firewall à rede que será protegida. Porém sobre isso falaremos mais à frente. Vamos agora ver em mais detalhes a diferença entre fluxo ingress e fluxo egress e o motivo de ser tão importante monitorar também o tráfego que sai da sua rede.
Fluxos ingress e fluxos egress
Ingress e egress são os nomes que damos aos fluxos de dados que entram e saem do nosso firewall:
Ingress: Todo o fluxo de dados que está entrando no firewall.
Egress: Todo o fluxo de dados que está saindo do firewall.
Existe uma cultura entre administradores de rede de que apenas o tráfego entrando é o que deve receber mais atenção e o que sai, por ser da rede confiável dele, não importa muito e não precisa ser tão bem filtrado (ou mesmo, não é filtrado de maneira alguma. Isso é ainda mais sério). Cara, nunca vi uma informação errada atravessar tantas gerações quanto essa!
Monitorar o tráfego ingress é sim realmente muito importante. Você precisa definir muito bem o que vai entrar na sua rede, quais hosts podem se conectar a quais serviços, quem pode iniciar conexões, etc. Isso é o básico de um firewall. Porém, o tráfego que sai da sua rede segura e vai para a rede insegura (como a Internet, por exemplo) é tão importante quanto o tráfego ingress.
Se você não monitora o tráfego de saída (egress) você não sabe o que está acontecendo na sua rede. Você não vai ver quando uma máquina da sua rede interna for comprometida por um trojan ou botnet, por exemplo, e começar a se comunicar com o atacante. Ou seja, você foi atacado com sucesso por confiar demais na sua rede interna. Além disso, se você não tiver os firewalls nos pontos corretos analisando os pacotes certos, você nunca vai ver um funcionário tentando extrair informações sigilosas da sua empresa para depois revendê-las à concorrência. Não ache que isso nunca vai acontecer com a sua empresa: já vi várias vítimas e algumas com prejuízos de milhares de reais por causa deste tipo de falha do departamento de TI/Segurança. E sim, a falha é sua – não tem desculpa.
Algumas coisas que você precisa fazer:
Bloqueie broadcasts no firewall de borda e nunca permita que este tipo de tráfego saia da sua LAN;
Bloqueie qualquer acesso à Internet de hosts que não precisam acessar nenhum serviço externo;
Essa não é muito relacionada ao firewall mas vai ter ajudar no geral: use máscaras de sub-rede restritivas. Por exemplo, se você usa uma rede com numeração 10.1.2.0 e a parte da rede é sempre 10.1.2.x, não use a máscara 255.0.0.0 (que é o padrão para o tipo de rede Classe A). Prefira usar uma máscara de sub-rede como 255.255.255.0. Use máscaras de sub-rede longas o suficiente apenas para identificar os hosts e nada mais. Uma máscara como 255.0.0.0 permite muitos hosts numa rede, o que abre brechas;
Especifique qual é a sua rede interna e apenas permita a saída para a Internet de pacotes que se originem nesta rede. Pacotes usando endereços de origem de outras redes que batam na interface interna do seu firewall devem ser descartados na hora e nunca, em hipóstese alguma, devem deixar a sua rede;
Não permita que endereços IP inválidos (os listados na RFC1918) passem do seu firewall e saiam para a Internet. Descarte-os na hora. Se você não sabe quais são estes endereços, são eles: 10.0.0.0 a 10.255.255.255 (também conhecido como Classe A); 172.16.0.0 a 172.31.255.255 (também conhecido como Classe B) e 192.168.0.0 a 192.168.255.255 (também conhecido como Classe C, talvez o mais comum em redes internas hoje em dia);
Permita que hosts internos iniciem conexões apenas em portas nas quais serviços que você confia sejam executados. Por exemplo, se você quer apenas que os hosts internos acessem os serviços HTTP e HTTPS configure o seu firewall para permitir apenas que conexões saintes para as portas 80 e 443 sejam permitidas. Conexões para outras portas devem ser descartadas;
Quando possível, permita que seus hosts acessem serviços da Internet apenas em hosts confiáveis;
Filtre bem tráfego ICMP saindo (veremos isso em mais detalhes adiante);
Não permita que hosts internos façam requisições DNS diretamente para servidores DNS da Internet. Prefira configurar um servidor DNS interno, forçar seus hosts a usar este servidor e faça com que ele faça o redirecionamento das consultas DNS para servidores confiáveis. Assim, fica muito mais fácil para você controlar o tráfego DNS da sua rede e garantir que apenas servidores confiáveis estão sendo usados. Dois serviços que você deveria considerar usar nesta situação são os DNSs do Google (8.8.8.8 e 8.8.4.4) e os do OpenDNS (208.67.222.222 e 208.67.220.220).
Dá mais trabalho? Óbvio. Mas isso tudo aí em cima é o básico para que você tenha uma rede segura e evite perder dinheiro ou mesmo o seu emprego por causa de problemas que podem ser sanados usando uma simples linha na ACL do roteador. Preguiça é a inimiga número 1 da segurança da informação.
Repita comigo: monitorar o tráfego ingress é apenas 50% do trabalho! Um administrador esperto monitora também o tráfego egress e fica atento, analisando o que está acontecendo com as máquinas protegidas!
Firewalls em servidores internos
Esse tópico vai ser bem curto, a mensagem é bastante simples.
Muita gente simplesmente não vê a necessidade de configurar um firewall de um host que está na rede interna e não recebe conexões de fora da rede. Ledo engano.
Existe uma categoria de atacantes muito negligenciada pela maioria dos administradores de rede: os funcionários (também conhecidos como “insiders”)! Não duvide de um funcionário infeliz com a empresa ou com raiva por algum motivo: ele pode causar um estrago ENORME por dois motivos principais. O primeiro é que ele já tem credenciais válidas na sua rede e pode passar pra onde for. A segunda é que ele tem uma boa noção de como a sua rede funciona e quais são os servidores importantes.
Se você não se proteger contra este tipo de ataque, você vai ser pego de calças na mão quando um servidor importantíssimo seu for atacado e derrubado ou mesmo um usuário interno que não deveria ter acesso aos dados armazenados em tal máquina ganhando acesso ilegítimo e vendendo a informação para terceiros. Outro motivo muito importante para ter servidores internos com firewalls é que eles podem ajudar a proteger a máquina de ataques de worms e mesmo trojans.
Sempre, não importa a severidade/importância que você dá ao servidor em questão, configure um firewall nele. E não se esqueça de configurar o filtro para o tráfego entrando e também para o tráfego que está saindo dele! Acabamos de discutir isso, não me mata de vergonha!
Formas de se conectar um firewall à rede
Como você deve imaginar, um firewall só consegue monitorar o tráfego que passa por ele (regra que se aplica a todos os dispositivos, assim como o IPS/IDS). Por isso, posicionamento é importantíssimo: todo o tráfego que você quer que seja monitorado deve ser enviado para as interfaces do firewall para que ele aplique a política de segurança que você configurou.
Se você quer monitorar alguma coisa, mas ela não passa pelo firewall você simplesmente não vai conseguir fazer nada. Por isso, antes de configurar o firewall planeje em que ponto da rede você irá inserí-lo. Esta parte deve ser a primeira no seu plano.
O modo como você conecta o firewall à rede pode acabar modificando a configuração dele. Por exemplo, se você conecta um host Linux com IPTables configurado à rede usando uma bridge, o firewall só irá conseguir monitorar o tráfego se você colocar as regras na chain FORWARD. Por isso é importante conhecer os modos de se conectar e planejar a configuração do firewall previamente.
Existem dois métodos principais de se conectar o firewall à rede:
Modo routed: Neste modo o firewall funciona também como um roteador. Portanto, ele não apenas filtra o tráfego que entra e sai mas também roteia o tráfego corretamente para que ele chegue em seu destino.Um exemplo deste tipo de firewall é uma máquina Linux que tem uma interface na rede interna e a outra conectada à Internet e que faz a filtragem de pacotes através do IPTables, que acredito ser a instalação mais comum deste tipo de firewall. No mundo Cisco, roteadores ISR (Integrated Services Router) conseguem fazer isso também.
Modo transparente: Neste modo, também chamado de “bump in the wire”, o host que tem o software de firewall configurado está conectado à rede através de interfaces em modo bridge e é completamente transparente para os outros hosts. Ninguém consegue vê-lo e, por isso, dificilmente alguém vai conseguir atacá-lo. Este é o modo que eu sempre recomendo: um firewall em modo transparente conectado a um roteador trabalhando em direcionar o tráfego e com uma ACL bem básica fazendo uma filtragem simples de tudo o que passa por ele. Para gerenciar remotamente este tipo de firewall, geralmente o que se faz é colocar uma interface de rede extra, não configurada como bridge, para permitir que hosts autorizados se conectem ao firewall via SSH por exemplo. Note “hosts autorizados”. Você deve configurar o firewall para permitir que apenas hosts que realmente precisam se conecte à esta interface do firewall para evitar ataques e manter a segurança do dispositivo.
Não pense que firewalls devem ficar apenas entre a sua rede interna e a Internet. Em todos os pontos que você precisar isolar uma rede da outra você deve colocar um firewall. Se você tem mais de um link de Internet, você precisa de um firewall para cada um deles (ou uma máquina que os controle e aplique as mesmas regras de firewall); se você precisa filtrar o tráfego que entra na rede do RH, deve colocar um firewall isolando ela de outras redes, e assim por diante.
Lembre-se: não se faça de rogado com firewalls! Se você precisa isolar uma rede de outra, cabe um firewall ali para fazer esta tarefa confiavelmente.
Packet filter
O firewall do tipo packet filter (literalmente, filtro de pacotes) foi o primeiro tipo de firewall a ser desenvolvido e colocado em produção. Os primeiros a implementarem esta tecnologia foram os pesquisadores da DEC (Digital Equipment Corporation) em 1988.
Este tipo de filtro faz uma análise bem simples e rápida do pacote que está passando por suas interfaces e permite que ele passe ou o drope, impedindo que ele chegue até seu destino. Ele não entende o conceito de “sessão” (neste caso, pode considerar uma sessão como sendo uma conexão), ou seja, ele vai tratar cada pacote individualmente aplicando cada entrada de sua política a todos os pacotes passantes até casar com alguma regra independentemente se eles são todos parte de uma mesma conexão.
Para fazer o filtro ele analisa as portas de origem e destino e os IPs dos hosts envolvidos no fluxo. Nada além disso pode ser observado por ele.
Um exemplo deste tipo de firewall são as ACLs que roteadores e switches Cisco usam para filtrar o tráfego. O IPTables também consegue atuar como um packet filter, desconsiderando sessões, mas isso não é o recomendado por ser menos seguro.
Uma desvantagem deste tipo de firewall é sua limitação. Ele não pode analisar muitos parâmetros do pacote para decidir se impede ou permite a sua passagem. Porém, um packet filter bem configurado tem um desempenho excelente dada a simplicidade com a qual trabalha. Um bom local para este tipo de firewall é na borda da rede, fazendo uma filtragem mais simples de coisas que simplesmente nem deveriam entrar ou sair da rede (independentemente de qualquer condição) como pacotes ICMP, por exemplo
Firewall stateful
Durante um bom tempo firewalls stateless (ou packet filters) foram a tecnologia dominante. Muitos dispositivos, sistemas operacionais e softwares especializados tinham como única opção de verificação apenas alguns poucos parâmetros do cabeçalho dos pacotes que chegavam através da rede. Apenas uns anos mais tarde apareceram os primeiros firewalls stateful.
A principal diferença dos firewalls stateful é que eles entendem o conceito de conexão, ao contrário de firewalls packet filters que tratam cada pacote entrante/sainte da mesma maneira e sempre tenta “casá-los” com alguma das regras em sua política para saber se deve eliminá-los ou deixá-los passar. Firewalls stateful possuem uma tabela, mantida em memória, que é utilizada para rastrear o estado atual da conexão (estabelecida, finalizada, etc) e também endereços IPs de origem e destino, portas de origem e destino e também os números de sequência usados pelos hosts para sincronizar a conexão. Muitos não sabem, mas todo esse processo de rastreio é feito também para fluxos UDP (User Datagram Protocol), muito embora este protocolo não estabeleça uma conexão antes de começar a trocar dados.
O processo mais longo é feito apenas no começo da conexão. Quando esta já está estabelecida e dados estão sendo trocados entre os hosts, o processo é mais acelerado pois muitas das verificações não serão feitas já que se determinou que aquela conexão é legítima e autorizada. Isso ajuda a diminuir ainda mais o impacto de um firewall stateful no desempenho da rede.
Como este tipo de firewall analisa mais parâmetros de um pacote e também mantém uma tabela em memória para rastrear conexões, firewalls stateful necessitam de mais recursos para rodarem com mais folga e não acabarem afetando o desempenho da rede que está sendo protegida (ou seja, para que não se tornem um gargalo).
Mais abaixo no item “Melhores práticas de firewalls” vou te dar algumas dicas sobre como manter tudo funcionando direitinho. Por enquanto, é importante que você apenas entenda como as coisas funcionam. Não adianta nada querer aprender a configurar uma coisa se você não entende como ela funciona.
O Cisco ASA, IPTables (presente em sistemas Linux) e o PF (presente em sistemas FreeBSD e OpenBSD) são exemplos de firewalls stateful. Tirando o ASA, são gratuitos e possuem muita documentação online para auxiliar você na configuração deles. Hoje em dia, você deveria dar preferência a usar firewalls stateful ao invés de packet filters pois estes possuem mais recursos para aumentar a segurança do seu sistema. Onde possível, dê preferência a estes firewalls.
Filtros de aplicação (application-level filters)
Algumas pessoas consideram application-level filters (ou filtros de nível de aplicação) apenas como uma extensão de firewalls stateful, mas a meu ver esta visão é errônea.
Firewalls de nível de aplicação têm a capacidade de controlar aplicações ou serviços, diferentemente de firewalls stateful que não conseguem fazer este tipo de análise (por padrão, pelo menos. Alguns firewalls oferecem plugins adicionais que oferecem este tipo de serviço). Este tipo de firewall consegue trabalhar em qualquer camada do modelo OSI (Open Systems Interconnection) – da física até a de aplicação.
Estes firewalls são sub-divididos nas categorias de network-based application firewalls (que trabalham analisando todo o tráfego gerado pelos hosts conectados à rede) e host-based application firewalls (estes são os que conseguem afetar diretamente aplicações e serviços rodando no mesmo host onde foram instalados e habilitados). A decisão de qual deles usar vai depender diretamente do dinheiro a ser investido, do tipo de monitoramento que se quer feito e de quais ações você espera que o firewall tome.
Como são os únicos a conseguirem trabalhar com aplicações e terem uma capacidade de análise mais geral, este tipo de firewall é o único que consegue bloquear efetivamente software Peer-to-Peer (P2P). Embora outros tipos de firewall ofereçam esta filtragem, geralmente não são bem feitas a ponto de não deixar nenhum buraquinho aberto para que o tráfego P2P passe.
Além disso, é necessária uma quantidade considerável de recursos para que este tipo de firewall consiga trabalhar direito já que ele precisa analisar MUITA coisa para tomar uma decisão. Portanto, não é qualquer maquininha que consegue executá-lo e continuar responsivo para o usuário.
Alguns exemplos deste tipo de firewall são AppArmor e Systrace para Linux; e WinGate e WinRoute para Windows. Além disso, existem também os filtros de aplicação extremamente especializados que trabalham protegendo apenas uma única aplicação especificamente.
Proxies
A maioria das pessoas quando instala um proxy não se dá conta de que ele é sim um tipo de firewall. O proxy é um firewall especializado, que atua na camada de Aplicação do modelo OSI e entende o protocolo que está analisando. Por exemplo, o Squid (um proxy HTTP extremamente popular hoje em dia) entende tudo de HTTP. Por isso, ele pode ser usado para filtrar URLs (negando o acesso a alguns sites enquanto permite o acesso a outros), pode ser usado para filtrar determinados comandos do HTTP (comandos são também chamados de requisições por alguns, tipo GET, POST, PUT, etc.) e também extensões de arquivos. Tudo isso só é possível porque o Squid entende o protocolo que está passando por ele.
NOTA: A diferença entre um proxy e um filtro de aplicação é que o proxy não consegue tomar ações que afetem diretamente o processo da aplicação em questão.
Um proxy atua mais ou menos como um atacante durante um ataque de man in the middle. Ele fica entre o cliente e o servidor.
Servidores proxy são muito utilizados em empresas por sua capacidade de proteger o cliente de acessar URLs maliciosas, capacidade de barrar comandos que possam ser maliciosos, possibilidade de fazer cache local para aumentar o desempenho do acesso à Internet, alguns permitem integração com anti-vírus, entre muitas outras coisas. Hoje em dia é difícil encontrar uma rede de empresa que não tenha algum tipo de proxy presente.
Além disso, proxies não trabalham apenas com HTTP. Existem vários proxies diferentes para vários outros protocolos como SMTP (como o SMTP Proxy e E-MailRelay), FTP (como Frox, [Tens de ter uma conta e sessão iniciada para poderes visualizar este link] etc. que podem ajudar você a proteger também outros tipos de servidores ou mesmo controlar o acesso a tais servidores. Com uma busca rápida no Google você vai conseguir encontrar vários softwares que fazem este trabalho.
Também vale lembrar: o proxy não necessariamente precisa estar funcionando na mesma máquina do firewall. Você pode ter duas máquinas completamente diferentes, cada uma rodando um dos serviços e tudo irá funcionar corretamente. O proxy precisa apenas ter uma conexão com a máquina que provê a conexão à Internet. Eu costumo recomendar rodar estes serviços em máquinas diferentes, pois assim cada uma vai ter recursos exclusivos e vai conseguir ter uma performance muito mais alta.
Web application firewalls
Aplicações web são, hoje em dia, talvez o alvo mais popular entre atacantes. Seja por causa do Anonymous, seja por causa da grande quantidade de vulnerabilidades e facilidade de exploração que aflige este tipo de aplicação, o fato é que nenhuma aplicação web por mais simples que seja está a salvo!
Por isso, nos últimos anos tem se tornado mais popular o conceito de Web Application Firewall (WAF) – ou firewall para aplicações web. Este tipo de firewall é especializado em detectar e impedir ataques contra aplicações web e, em alguns casos, também contra o servidor web onde esta está sendo hospedada.
O WAF funciona interceptando todas as requisições que são direcionadas à aplicação web e comparando-as com um banco de dados de assinaturas para definir se aquilo é um ataque ou não (se você leu meu post sobre IPS e IDS vai perceber a semelhança em como as duas tecnologias funcionam). Dependendo do resultado de tal análise, a requisição é enviada à aplicação web ou, caso seja considerada maliciosa, é dropada e o ataque não funciona.
Geralmente, o mínimo que um WAF consegue fazer é garantir que todas as vulnerabilidades listadas no OWASP Top 10 (uma lista anual dos ataques mais populares) sejam identificadas e devidamente bloqueadas antes de causar qualquer prejuízo à aplicação. Geralmente, esta lista inclui falhas como SQL Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), entre várias outras falhas de programação e algumas de configuração.
Além do suporte de detecção de ataques (através de assinaturas desenvolvidas pelo vendor), outros aspectos que devem ser levados em conta são o desempenho, suporte à clusters, proteção contra ataques de brute-force, interface de administração bem desenvolvida, baixa taxa de falsos-positivos, etc. Preste bastante atenção à estes pontos quando pesquisar soluções para fazer uma boa compra e não acabar desperdiçando o dinheiro da sua empresa (todo mundo aqui deve saber como é difícil conseguir verba pra comprar tudo o que o Departamento de TI precisa, né? Imagina se você começar a fazer as compras erradas…).
O WAF que eu mais gosto e sempre recomendo a clientes é o ModSecurity, que hoje em dia é gerenciado e desenvolvido pela Trustwave. Este firewall funciona como um módulo do Apache e também oferece proteção para o Microsoft IIS e para o Nginx (o suporte deste último ainda está em beta e pode não atingir as suas necessidades para ser colocado em produção).
Como você deve imaginar, sozinho o ModSecurity oferece pouquíssima proteção. Por isso a Trustwave disponibiliza gratuitamente, através do site spiderlabs.github.com/owasp-modsecurity-crs/, um pacote com várias regras que suportam a detecção dos ataques listados no OWASP Top 10 e também regras genéricas que ajudam a detectar outros tipos de ataque que não fazem parte desta lista. Já é um excelente começo. Além disso, você também pode escrever as suas próprias regras para detectar coisas mais específicas à sua aplicação web.
Obviamente o ModSecurity não é a única solução disponível no mercado. Existem outros grandes players que também vendem este tipo de dispositivo e que oferecem uma excelente proteção para o seu ambiente. Um exemplo é o Cisco ACE Web Application firewall que oferece uma excelente proteção com um suporte excelente por parte do fabricante e um desempenho de acordo com ambientes de mais alta criticidade.
Deep packet inspection
Firewalls stateful oferecem o que chamamos de “shallow inspection” ou inspeção rasa, traduzindo ao pé da letra. Isso por levarem em consideração apenas informações que estão presentes nos cabeçalhos dos pacotes que passam por ele. Os outros tipos de software não são chamados assim, mas inspecionam apenas o conteúdo, ou seja, não fazem a inspeção dos cabeçalhos como o stateful firewall.
Para sanar esta questão foram criados os firewalls Deep Packet Inspection (análise à fundo de pacotes). Como o próprio nome diz, este tipo de firewall realiza uma inspeção bem completa em todos os pacotes que passam por seu motor de análise. Esta inspeção pode encontrar pacotes que não obedecem ao padrão de um determinado protocolo, vírus, worms,SPAM, ataques, etc. Também são capazes de analisar o tráfego e gerar informações estatísticas para facilitar o gerenciamento da rede.
Embora firewalls DPI possam ser usados para várias finalidades interessantes, que visam o bem tanto de administradores quanto de usuários, eles também têm sido usados por governos ditatoriais para regular o que os usuários de um país podem acessar ou mesmo comunicar com usuários de outros países. Um exemplo deste tipo de firewall é o utilizado pelo governo da China, chamado de The Great Firewall of China, que monitora de perto o que os cidadãos falam ou acessam na Internet. A Austrália tentou implantar uma tecnologia parecida há alguns anos atrás mas o projeto não foi para frente devido aos protestos dos cidadãos.
O funcionamento deste tipo de firewall não difere em nada dos outros. Os dados a serem analisados precisam passar por suas interfaces para que o motor de análise possa aplicar as políticas que você configurou no sistema. Isso é alcançado colocando o firewall in-line (“no meio” do caminho entre a origem e o destino) ou usando Span Ports (portas para onde o switch direciona o tráfego de todas as outras portas para fins de análise). Uma vez dentro do motor de análise do firewall, o pacote será enviado ao destino ou descartado de acordo com o que você configurou na política dele.
Alguns exemplos de firewalls deste tipo são nDPI, PACE, Hippie, Tstat, entre vários outros. Além disso, existe também o módulo L7-Filter que permite ao Netfilter do Linux trabalhar com DPI. Usando este módulo junto do Netfilter você será capaz de bloquear tráfego de aplicações como Kazaa, Jabber, Citrix, Bittorrent, Gnucleus, eDonkey2000, entre vários outros.
Firewalls Deep Packet Inspection oferecem uma excelente oportunidade para que você aumente o nível de proteção da sua rede enquanto coleta informações estatísticas para conseguir otimizar a performance do conjunto. Apenas lembre-se que tudo isso tem um preço: este tipo de firewall precisa de muitos recursos para que não se torne um gargalo na sua rede e comece a afetar o desempenho. Você precisa balancear a proteção e o desempenho neste caso para não ter que ficar ouvindo reclamações de usuários todos os dias .
Melhores práticas de firewalls
Vou aqui dar algumas dicas sobre o que você pode fazer para melhorar a segurança que o firewall oferece à sua rede. Como um não tem muito a ver com o outro, achei mais fácil fazer uma lista de tópicos:
Mantenha o software sempre atualizado: Seja uma appliance específica de firewall, seja um firewall pessoal da Comodo que você baixou para o seu Windows, ou mesmo o IPTables no seu Linux, o software sempre precisa estar atualizado para que o próprio firewall não fique vulnerável a ataques e acabe se tornando um problema ao invés de uma solução de segurança.
Troque a senha padrão: Appliances de todos os fabricantes sempre vêm com usuários criados previamente pelo próprio fabricante/desenvolvedor para permitir o seu login da primeira vez até você configurar tudo para que a appliance passe a proteger o seu ambiente. O problema é que geralmente essas contas têm uma senha padrão. E, como você deve imaginar, estas senhas padrão não são nenhum segredo: todos conhecem, inclusive o hacker que está tentando invadir a sua rede. Por isso, sempre que você compra um novo dispositivo a primeira coisa que você precisa fazer é modificar a senha do usuário criado automaticamente ou mesmo desabilitar a conta e criar uma nova com um novo nome.
Sempre atualize as regras do seu firewall: Redes, principalmente em organizações de médio e grande porte, mudam muito. Novos softwares são adicionados, novos parceiros se conectam à rede, novas máquinas são conectadas. Por isso, você sempre deve analisar e garantir que as regras que estão filtrando o seu tráfego atualmente estão oferecendo o máximo de proteção possível. Precisou fazer alguma alteração para uma aplicação funcionar? Não se esqueça de considerar também as implicações de segurança que essa mudança vai trazer. Pense sempre globalmente.
Controle quem pode fazer mudanças na política do firewall: É inviável permitir que qualquer um faça mudanças na sua política do firewall. Você tem que controlar muito bem quem pode fazer mudanças para evitar confusões com aplicações que não funcionam mais, brechas de segurança que foram abertas por uma mudança, etc. Tome cuidado para o firewall não virar a casa da mãe Joana.
Monitore quais mudanças podem ser feitas na política: Além de monitorar *quem* pode fazer mudanças na política, monitore também *quais* mudanças podem ser feitas. Algumas mudanças são tão grandes que não deveriam ser feitas durante o horário comercial, por exemplo. Sempre pense muito bem antes de alterar aquela linha na sua ACL!
Anote quais mudanças foram feitas, quando e por quem: É de extrema importância que um “log”, ou mesmo um diário, seja sempre atualizado com as mudanças feitas no firewall com o máximo de detalhes possível. Assim, você vai saber o motivo de uma aplicação importantíssima do departamento de Marketing ter parado de funcionar ontem à tarde (logo depois daquela mudança que você fez na política! ). Isso vai facilitar muito a sua vida quando você estiver resolvendo problemas relacionados ao firewall. Na verdade, recomendo que faça isso para todos os sistemas da sua rede, facilitando muito a administração da rede. Isso não é uma simples burocracia, é um meio de acompanhar tudo o que acontece na sua rede de perto para impedir que alguma coisa coloque a produção dos funcionários (e, como reflexo, o faturamento da empresa) em cheque. Seus superiores agradecem!
Sempre filtre o protocolo ICMP na borda: Embora o ICMP seja muito utilizado para reportar e ajudar a solucionar problemas nas redes, ele também pode acabar fornecendo uma grande quantidade de informações cruciais para que um atacante conheça ainda mais sobre a sua arquitetura. Por isso, este protocolo geralmente não entra e não sai – sendo sempre bloqueado pelos firewalls que ficam entre a sua rede interna e a Internet. Porém, eu gosto de permitir algumas mensagens para que tudo continue funcionando corretamente (e não se preocupe, elas não revelam nada importante a um possível atacante). São elas:
3.0: Destination network unreachable (rede inalcançável)
3.1: Destination host unreachable (host inalcançável)
3.2: Destination protocol unreachable (protocolo inalcançável)
3.3: Destination port unreachable (porta inalcançável)
3.4: Fragmentation required and DF flag set (é necessário fragmentação e flag DF)
4: Source Quench (pedido para diminuir o volume de tráfego enviado para o host de destino)
5: Redirect Message (redirecionamento)
11: Time exceeded (tempo excedido)
12: Parameter problem: bad IP header (problema com parâmetros inválidos no cabeçalho do IP)
A maioria dos softwares de firewall atuais conseguem filtrar o ICMP baseando-se no tipo da mensagem. Portanto, você dificilmente vai ter dor de cabeça para conseguir filtrar isso. Basta encontrar a opção correta para fazê-lo.
Liberando apenas estas mensagens, você ainda vai ter bastante ajuda do protocolo ICMP mas nada que vá ajudar um atacante vai ser enviado. Você continua seguro!
Acima, quando me refiro à política do firewall entenda que estou me referindo às regras que você configurou para o seu firewall. Esse conjunto de regras costuma ser chamado de política.
Conclusão
Bom, acredito que o texto te deu uma excelente base teórica sobre o que é um firewall, quais os tipos e qual o papel principal dele na sua rede. Portanto, não tem mais desculpas pra não proteger corretamente a sua rede daqui pra frente!
Lembre-se sempre: idependente do tipo de firewall ou se é uma appliance ou um software fazendo o papel de firewall, nunca deixe de atualizá-lo. Firewalls são como qualquer outro tipo de software e podem apresentar vários bugs no código que podem minar a proteção que eles oferecem. Por isso, sempre use a versão mais recente do firmware (se você usa appliances) ou do software que você usa como firewall. Aliás, essa dica serve para todo tipo de software: sempre use a versão mais recente.
Redes dificilmente ficam imutáveis por muito tempo. Sempre tem uma mudançazinha aqui, outra ali… e o firewall acaba tendo que se adaptar. Obviamente que você não pode se recusar a fazer as mudanças no firewall e ficar impactando o negócio, mas analise muito bem cada mudança que você fizer para não acabar abrindo demais o firewall e causar um problema de segurança. Nenhuma mudança deve ser feita na hora. Entenda o que o cliente/software precisa, estude o impacto disso no firewall e só então faça a mudança. Ah sim: sempre documente a mudança por menor que ela seja!
Não ache que só porque um servidor está na rede interna e apenas usuários internos o acessam ele não precisa de um firewall bem configurado rodando. Usuários internos são sim um grande perigo para uma empresa e você deve tratá-los como tal. Nunca deixe um cliente ou servidor sem um firewall pois isso vai facilitar muito a vida de um atacante localizado na rede interna. Lembre-se: um atacante que, pela Internet, consegue controlar um host interno é agora, para todos os efeitos, um usuário interno. Todo cuidado é pouco, não negligencie nada. Há vários casos Internet afora demonstrando como um ataque lançado por um usuário interno levou uma empresa à falência.
Créditos : Cheio de Gente.
Da criação de sua primeira geração em 1988, por engenheiros da DEC (Digital Equipment Corporation), até hoje, os firewalls já evoluíram muito. Evoluíram a tal ponto que pouco lembram os primeiros filtros de pacotes que foram implantados em redes. Hoje em dia firewalls conseguem filtrar pacotes por porta, endereços IP, protocolo, conseguem interpretar protocolos e até mesmo os dados que estão dentro dos pacotes e só então tomarem uma decisão sobre o que fazer com eles, sempre obedecendo a política que você configurou nele. Além disso, firewalls mais atuais conseguem até bloquear determinados ataques tanto contra o sistema operacional quanto contra a aplicação hospedada pelo host (inclusive aplicações web!).
O que é um firewall?
Para que você consiga manter a segurança de uma rede, é necessário que você a isole de outras redes que não são tão seguras assim ou mesmo redes que representem perigo para você (como a Internet). Se você não filtrar o tráfego que entra e sai de sua rede, não vai conseguir garantir a segurança dela pois todos terão acesso livre aos recursos oferecidos pela sua rede interna.
Esse é o papel do firewall: isolar uma rede segura para impedir que o tráfego considerado malicioso pela sua política de rede não entre ou saia. Ou seja, o firewall permite a você definir o que pode entrar e o que pode sair. Para exercer este controle, o firewall vai analisar o conteúdo do header do pacote (portas de origem e destino, hosts de origem e destino, as flags do pacote TCP) e, em alguns casos, até mesmo o conteúdo do pacote passando por ele.
Existem firewalls de vários tipos, mas geralmente eles se apresentam de duas maneiras:
Firewalls físicos (também conhecidos como appliances): Estes firewalls geralmente são disponibilizados através de appliances físicas que devem ser colocadas em um rack, por exemplo. Esta appliance é formada por um hardware normal como o de qualquer computador (com diferenças mínimas como um processador ASIC, para melhorar o desempenho de rede dele) e um software especializado em filtrar pacotes. Exemplos deste tipo de firewall são os Cisco PIX (que já não é mais comercializado pela Cisco), Cisco ASA e Juniper Netscreen.Estas appliances chegam a custar milhares de dólares, dependendo do modelo, fora a licença necessária se você quiser expandir a funcionalidade do aparelho. Além disso também oferecem módulos para aumentar ainda mais sua funcionalidade e interfaces gráficas que permitem a você configurar e gerenciar várias appliances ao mesmo tempo. Um exemplo deste tipo de interface é o Cisco Security Manager.
Acredito que o ponto positivo mais atraente seja o desempenho destes equipamentos. Alguns deles conseguem processar vários gigabits de dados por segundo. Porém, isso vem com um preço. E geralmente este preço é bem salgado, chegando ao ponto de ser um impedimento para que empresas de menor porte consigam adquirir um produto deste tipo.
Firewalls lógicos (via software): Esse tem aos montes! Caros, baratos, de graça, que funcionam, que simplesmente enganam, etc. Geralmente, firewalls lógicos em sua maioria são destinados a um público que precise de um nível de segurança mais baixo e que não são técnicos. São geralmente conhecidos como firewalls pessoais.Geralmente, esta funcionalidade é oferecida por suítes de segurança como o Symantec Endpoint Protection que oferece além do firewall um anti-vírus e também um IPS (bem simples, pouco configurável). Existem também os softwares que são especializados em oferecer a funcionalidade de firewall. Um exemplo deste tipo é o Comodo Firewall, que oferece um software de firewall com uma excelente segurança e possui uma versão gratuita.
Uma grande exceção ao que eu falei acima são os firewalls de sistemas operacionais abertos, como Linux e OpenBSD. O Netfilter e o PF são dois grandes firewalls, que oferecem uma segurança absurda (quando bem configurados, obviamente) e um excelente conjunto de funcionalidades. Porém, são geralmente mais utilizados em servidores. Poucos são os clientes que os configuram para melhorar a proteção.
O Windows também oferece um firewall nativo, mas de baixíssima qualidade, desde o Windows XP se não me engano. O problema com este firewall é que sua configuração padrão oferece pouco para aumentar a segurança do usuário e bloqueia apenas os ataques mais simples. Outro grande problema são os usuários que simplesmente entram nas configurações desse firewall e o desabilitam por completo por ele estar causando algum problema por bloquear um software necessário no dia-a-dia de um funcionário. Outras soluções de firewall já oferecem a possibilidade de avisar quando um aplicativo é bloqueado por padrão ou mesmo impedem que o firewall seja finalizado por um usuário sem os privilégios necessários.
Esse firewall foi refeito no Windows Vista/7 e no Windows 8, recém lançado, apresentou várias novidades e agora oferece muito mais opções e uma proteção um pouco mais avançada. Se você não tem como adquirir um firewall de uma empresa de renome, que tenha uma qualidade mais alta, o firewall nativo do Windows vai conseguir quebrar um galho por um tempo, mas assim que tiver a oportunidade não deixe de adquirir uma solução especializada.
Também existem diferenças na forma de se conectar o firewall à rede que será protegida. Porém sobre isso falaremos mais à frente. Vamos agora ver em mais detalhes a diferença entre fluxo ingress e fluxo egress e o motivo de ser tão importante monitorar também o tráfego que sai da sua rede.
Fluxos ingress e fluxos egress
Ingress e egress são os nomes que damos aos fluxos de dados que entram e saem do nosso firewall:
Ingress: Todo o fluxo de dados que está entrando no firewall.
Egress: Todo o fluxo de dados que está saindo do firewall.
Existe uma cultura entre administradores de rede de que apenas o tráfego entrando é o que deve receber mais atenção e o que sai, por ser da rede confiável dele, não importa muito e não precisa ser tão bem filtrado (ou mesmo, não é filtrado de maneira alguma. Isso é ainda mais sério). Cara, nunca vi uma informação errada atravessar tantas gerações quanto essa!
Monitorar o tráfego ingress é sim realmente muito importante. Você precisa definir muito bem o que vai entrar na sua rede, quais hosts podem se conectar a quais serviços, quem pode iniciar conexões, etc. Isso é o básico de um firewall. Porém, o tráfego que sai da sua rede segura e vai para a rede insegura (como a Internet, por exemplo) é tão importante quanto o tráfego ingress.
Se você não monitora o tráfego de saída (egress) você não sabe o que está acontecendo na sua rede. Você não vai ver quando uma máquina da sua rede interna for comprometida por um trojan ou botnet, por exemplo, e começar a se comunicar com o atacante. Ou seja, você foi atacado com sucesso por confiar demais na sua rede interna. Além disso, se você não tiver os firewalls nos pontos corretos analisando os pacotes certos, você nunca vai ver um funcionário tentando extrair informações sigilosas da sua empresa para depois revendê-las à concorrência. Não ache que isso nunca vai acontecer com a sua empresa: já vi várias vítimas e algumas com prejuízos de milhares de reais por causa deste tipo de falha do departamento de TI/Segurança. E sim, a falha é sua – não tem desculpa.
Algumas coisas que você precisa fazer:
Bloqueie broadcasts no firewall de borda e nunca permita que este tipo de tráfego saia da sua LAN;
Bloqueie qualquer acesso à Internet de hosts que não precisam acessar nenhum serviço externo;
Essa não é muito relacionada ao firewall mas vai ter ajudar no geral: use máscaras de sub-rede restritivas. Por exemplo, se você usa uma rede com numeração 10.1.2.0 e a parte da rede é sempre 10.1.2.x, não use a máscara 255.0.0.0 (que é o padrão para o tipo de rede Classe A). Prefira usar uma máscara de sub-rede como 255.255.255.0. Use máscaras de sub-rede longas o suficiente apenas para identificar os hosts e nada mais. Uma máscara como 255.0.0.0 permite muitos hosts numa rede, o que abre brechas;
Especifique qual é a sua rede interna e apenas permita a saída para a Internet de pacotes que se originem nesta rede. Pacotes usando endereços de origem de outras redes que batam na interface interna do seu firewall devem ser descartados na hora e nunca, em hipóstese alguma, devem deixar a sua rede;
Não permita que endereços IP inválidos (os listados na RFC1918) passem do seu firewall e saiam para a Internet. Descarte-os na hora. Se você não sabe quais são estes endereços, são eles: 10.0.0.0 a 10.255.255.255 (também conhecido como Classe A); 172.16.0.0 a 172.31.255.255 (também conhecido como Classe B) e 192.168.0.0 a 192.168.255.255 (também conhecido como Classe C, talvez o mais comum em redes internas hoje em dia);
Permita que hosts internos iniciem conexões apenas em portas nas quais serviços que você confia sejam executados. Por exemplo, se você quer apenas que os hosts internos acessem os serviços HTTP e HTTPS configure o seu firewall para permitir apenas que conexões saintes para as portas 80 e 443 sejam permitidas. Conexões para outras portas devem ser descartadas;
Quando possível, permita que seus hosts acessem serviços da Internet apenas em hosts confiáveis;
Filtre bem tráfego ICMP saindo (veremos isso em mais detalhes adiante);
Não permita que hosts internos façam requisições DNS diretamente para servidores DNS da Internet. Prefira configurar um servidor DNS interno, forçar seus hosts a usar este servidor e faça com que ele faça o redirecionamento das consultas DNS para servidores confiáveis. Assim, fica muito mais fácil para você controlar o tráfego DNS da sua rede e garantir que apenas servidores confiáveis estão sendo usados. Dois serviços que você deveria considerar usar nesta situação são os DNSs do Google (8.8.8.8 e 8.8.4.4) e os do OpenDNS (208.67.222.222 e 208.67.220.220).
Dá mais trabalho? Óbvio. Mas isso tudo aí em cima é o básico para que você tenha uma rede segura e evite perder dinheiro ou mesmo o seu emprego por causa de problemas que podem ser sanados usando uma simples linha na ACL do roteador. Preguiça é a inimiga número 1 da segurança da informação.
Repita comigo: monitorar o tráfego ingress é apenas 50% do trabalho! Um administrador esperto monitora também o tráfego egress e fica atento, analisando o que está acontecendo com as máquinas protegidas!
Firewalls em servidores internos
Esse tópico vai ser bem curto, a mensagem é bastante simples.
Muita gente simplesmente não vê a necessidade de configurar um firewall de um host que está na rede interna e não recebe conexões de fora da rede. Ledo engano.
Existe uma categoria de atacantes muito negligenciada pela maioria dos administradores de rede: os funcionários (também conhecidos como “insiders”)! Não duvide de um funcionário infeliz com a empresa ou com raiva por algum motivo: ele pode causar um estrago ENORME por dois motivos principais. O primeiro é que ele já tem credenciais válidas na sua rede e pode passar pra onde for. A segunda é que ele tem uma boa noção de como a sua rede funciona e quais são os servidores importantes.
Se você não se proteger contra este tipo de ataque, você vai ser pego de calças na mão quando um servidor importantíssimo seu for atacado e derrubado ou mesmo um usuário interno que não deveria ter acesso aos dados armazenados em tal máquina ganhando acesso ilegítimo e vendendo a informação para terceiros. Outro motivo muito importante para ter servidores internos com firewalls é que eles podem ajudar a proteger a máquina de ataques de worms e mesmo trojans.
Sempre, não importa a severidade/importância que você dá ao servidor em questão, configure um firewall nele. E não se esqueça de configurar o filtro para o tráfego entrando e também para o tráfego que está saindo dele! Acabamos de discutir isso, não me mata de vergonha!
Formas de se conectar um firewall à rede
Como você deve imaginar, um firewall só consegue monitorar o tráfego que passa por ele (regra que se aplica a todos os dispositivos, assim como o IPS/IDS). Por isso, posicionamento é importantíssimo: todo o tráfego que você quer que seja monitorado deve ser enviado para as interfaces do firewall para que ele aplique a política de segurança que você configurou.
Se você quer monitorar alguma coisa, mas ela não passa pelo firewall você simplesmente não vai conseguir fazer nada. Por isso, antes de configurar o firewall planeje em que ponto da rede você irá inserí-lo. Esta parte deve ser a primeira no seu plano.
O modo como você conecta o firewall à rede pode acabar modificando a configuração dele. Por exemplo, se você conecta um host Linux com IPTables configurado à rede usando uma bridge, o firewall só irá conseguir monitorar o tráfego se você colocar as regras na chain FORWARD. Por isso é importante conhecer os modos de se conectar e planejar a configuração do firewall previamente.
Existem dois métodos principais de se conectar o firewall à rede:
Modo routed: Neste modo o firewall funciona também como um roteador. Portanto, ele não apenas filtra o tráfego que entra e sai mas também roteia o tráfego corretamente para que ele chegue em seu destino.Um exemplo deste tipo de firewall é uma máquina Linux que tem uma interface na rede interna e a outra conectada à Internet e que faz a filtragem de pacotes através do IPTables, que acredito ser a instalação mais comum deste tipo de firewall. No mundo Cisco, roteadores ISR (Integrated Services Router) conseguem fazer isso também.
Modo transparente: Neste modo, também chamado de “bump in the wire”, o host que tem o software de firewall configurado está conectado à rede através de interfaces em modo bridge e é completamente transparente para os outros hosts. Ninguém consegue vê-lo e, por isso, dificilmente alguém vai conseguir atacá-lo. Este é o modo que eu sempre recomendo: um firewall em modo transparente conectado a um roteador trabalhando em direcionar o tráfego e com uma ACL bem básica fazendo uma filtragem simples de tudo o que passa por ele. Para gerenciar remotamente este tipo de firewall, geralmente o que se faz é colocar uma interface de rede extra, não configurada como bridge, para permitir que hosts autorizados se conectem ao firewall via SSH por exemplo. Note “hosts autorizados”. Você deve configurar o firewall para permitir que apenas hosts que realmente precisam se conecte à esta interface do firewall para evitar ataques e manter a segurança do dispositivo.
Não pense que firewalls devem ficar apenas entre a sua rede interna e a Internet. Em todos os pontos que você precisar isolar uma rede da outra você deve colocar um firewall. Se você tem mais de um link de Internet, você precisa de um firewall para cada um deles (ou uma máquina que os controle e aplique as mesmas regras de firewall); se você precisa filtrar o tráfego que entra na rede do RH, deve colocar um firewall isolando ela de outras redes, e assim por diante.
Lembre-se: não se faça de rogado com firewalls! Se você precisa isolar uma rede de outra, cabe um firewall ali para fazer esta tarefa confiavelmente.
Packet filter
O firewall do tipo packet filter (literalmente, filtro de pacotes) foi o primeiro tipo de firewall a ser desenvolvido e colocado em produção. Os primeiros a implementarem esta tecnologia foram os pesquisadores da DEC (Digital Equipment Corporation) em 1988.
Este tipo de filtro faz uma análise bem simples e rápida do pacote que está passando por suas interfaces e permite que ele passe ou o drope, impedindo que ele chegue até seu destino. Ele não entende o conceito de “sessão” (neste caso, pode considerar uma sessão como sendo uma conexão), ou seja, ele vai tratar cada pacote individualmente aplicando cada entrada de sua política a todos os pacotes passantes até casar com alguma regra independentemente se eles são todos parte de uma mesma conexão.
Para fazer o filtro ele analisa as portas de origem e destino e os IPs dos hosts envolvidos no fluxo. Nada além disso pode ser observado por ele.
Um exemplo deste tipo de firewall são as ACLs que roteadores e switches Cisco usam para filtrar o tráfego. O IPTables também consegue atuar como um packet filter, desconsiderando sessões, mas isso não é o recomendado por ser menos seguro.
Uma desvantagem deste tipo de firewall é sua limitação. Ele não pode analisar muitos parâmetros do pacote para decidir se impede ou permite a sua passagem. Porém, um packet filter bem configurado tem um desempenho excelente dada a simplicidade com a qual trabalha. Um bom local para este tipo de firewall é na borda da rede, fazendo uma filtragem mais simples de coisas que simplesmente nem deveriam entrar ou sair da rede (independentemente de qualquer condição) como pacotes ICMP, por exemplo
Firewall stateful
Durante um bom tempo firewalls stateless (ou packet filters) foram a tecnologia dominante. Muitos dispositivos, sistemas operacionais e softwares especializados tinham como única opção de verificação apenas alguns poucos parâmetros do cabeçalho dos pacotes que chegavam através da rede. Apenas uns anos mais tarde apareceram os primeiros firewalls stateful.
A principal diferença dos firewalls stateful é que eles entendem o conceito de conexão, ao contrário de firewalls packet filters que tratam cada pacote entrante/sainte da mesma maneira e sempre tenta “casá-los” com alguma das regras em sua política para saber se deve eliminá-los ou deixá-los passar. Firewalls stateful possuem uma tabela, mantida em memória, que é utilizada para rastrear o estado atual da conexão (estabelecida, finalizada, etc) e também endereços IPs de origem e destino, portas de origem e destino e também os números de sequência usados pelos hosts para sincronizar a conexão. Muitos não sabem, mas todo esse processo de rastreio é feito também para fluxos UDP (User Datagram Protocol), muito embora este protocolo não estabeleça uma conexão antes de começar a trocar dados.
O processo mais longo é feito apenas no começo da conexão. Quando esta já está estabelecida e dados estão sendo trocados entre os hosts, o processo é mais acelerado pois muitas das verificações não serão feitas já que se determinou que aquela conexão é legítima e autorizada. Isso ajuda a diminuir ainda mais o impacto de um firewall stateful no desempenho da rede.
Como este tipo de firewall analisa mais parâmetros de um pacote e também mantém uma tabela em memória para rastrear conexões, firewalls stateful necessitam de mais recursos para rodarem com mais folga e não acabarem afetando o desempenho da rede que está sendo protegida (ou seja, para que não se tornem um gargalo).
Mais abaixo no item “Melhores práticas de firewalls” vou te dar algumas dicas sobre como manter tudo funcionando direitinho. Por enquanto, é importante que você apenas entenda como as coisas funcionam. Não adianta nada querer aprender a configurar uma coisa se você não entende como ela funciona.
O Cisco ASA, IPTables (presente em sistemas Linux) e o PF (presente em sistemas FreeBSD e OpenBSD) são exemplos de firewalls stateful. Tirando o ASA, são gratuitos e possuem muita documentação online para auxiliar você na configuração deles. Hoje em dia, você deveria dar preferência a usar firewalls stateful ao invés de packet filters pois estes possuem mais recursos para aumentar a segurança do seu sistema. Onde possível, dê preferência a estes firewalls.
Filtros de aplicação (application-level filters)
Algumas pessoas consideram application-level filters (ou filtros de nível de aplicação) apenas como uma extensão de firewalls stateful, mas a meu ver esta visão é errônea.
Firewalls de nível de aplicação têm a capacidade de controlar aplicações ou serviços, diferentemente de firewalls stateful que não conseguem fazer este tipo de análise (por padrão, pelo menos. Alguns firewalls oferecem plugins adicionais que oferecem este tipo de serviço). Este tipo de firewall consegue trabalhar em qualquer camada do modelo OSI (Open Systems Interconnection) – da física até a de aplicação.
Estes firewalls são sub-divididos nas categorias de network-based application firewalls (que trabalham analisando todo o tráfego gerado pelos hosts conectados à rede) e host-based application firewalls (estes são os que conseguem afetar diretamente aplicações e serviços rodando no mesmo host onde foram instalados e habilitados). A decisão de qual deles usar vai depender diretamente do dinheiro a ser investido, do tipo de monitoramento que se quer feito e de quais ações você espera que o firewall tome.
Como são os únicos a conseguirem trabalhar com aplicações e terem uma capacidade de análise mais geral, este tipo de firewall é o único que consegue bloquear efetivamente software Peer-to-Peer (P2P). Embora outros tipos de firewall ofereçam esta filtragem, geralmente não são bem feitas a ponto de não deixar nenhum buraquinho aberto para que o tráfego P2P passe.
Além disso, é necessária uma quantidade considerável de recursos para que este tipo de firewall consiga trabalhar direito já que ele precisa analisar MUITA coisa para tomar uma decisão. Portanto, não é qualquer maquininha que consegue executá-lo e continuar responsivo para o usuário.
Alguns exemplos deste tipo de firewall são AppArmor e Systrace para Linux; e WinGate e WinRoute para Windows. Além disso, existem também os filtros de aplicação extremamente especializados que trabalham protegendo apenas uma única aplicação especificamente.
Proxies
A maioria das pessoas quando instala um proxy não se dá conta de que ele é sim um tipo de firewall. O proxy é um firewall especializado, que atua na camada de Aplicação do modelo OSI e entende o protocolo que está analisando. Por exemplo, o Squid (um proxy HTTP extremamente popular hoje em dia) entende tudo de HTTP. Por isso, ele pode ser usado para filtrar URLs (negando o acesso a alguns sites enquanto permite o acesso a outros), pode ser usado para filtrar determinados comandos do HTTP (comandos são também chamados de requisições por alguns, tipo GET, POST, PUT, etc.) e também extensões de arquivos. Tudo isso só é possível porque o Squid entende o protocolo que está passando por ele.
NOTA: A diferença entre um proxy e um filtro de aplicação é que o proxy não consegue tomar ações que afetem diretamente o processo da aplicação em questão.
Um proxy atua mais ou menos como um atacante durante um ataque de man in the middle. Ele fica entre o cliente e o servidor.
Servidores proxy são muito utilizados em empresas por sua capacidade de proteger o cliente de acessar URLs maliciosas, capacidade de barrar comandos que possam ser maliciosos, possibilidade de fazer cache local para aumentar o desempenho do acesso à Internet, alguns permitem integração com anti-vírus, entre muitas outras coisas. Hoje em dia é difícil encontrar uma rede de empresa que não tenha algum tipo de proxy presente.
Além disso, proxies não trabalham apenas com HTTP. Existem vários proxies diferentes para vários outros protocolos como SMTP (como o SMTP Proxy e E-MailRelay), FTP (como Frox, [Tens de ter uma conta e sessão iniciada para poderes visualizar este link] etc. que podem ajudar você a proteger também outros tipos de servidores ou mesmo controlar o acesso a tais servidores. Com uma busca rápida no Google você vai conseguir encontrar vários softwares que fazem este trabalho.
Também vale lembrar: o proxy não necessariamente precisa estar funcionando na mesma máquina do firewall. Você pode ter duas máquinas completamente diferentes, cada uma rodando um dos serviços e tudo irá funcionar corretamente. O proxy precisa apenas ter uma conexão com a máquina que provê a conexão à Internet. Eu costumo recomendar rodar estes serviços em máquinas diferentes, pois assim cada uma vai ter recursos exclusivos e vai conseguir ter uma performance muito mais alta.
Web application firewalls
Aplicações web são, hoje em dia, talvez o alvo mais popular entre atacantes. Seja por causa do Anonymous, seja por causa da grande quantidade de vulnerabilidades e facilidade de exploração que aflige este tipo de aplicação, o fato é que nenhuma aplicação web por mais simples que seja está a salvo!
Por isso, nos últimos anos tem se tornado mais popular o conceito de Web Application Firewall (WAF) – ou firewall para aplicações web. Este tipo de firewall é especializado em detectar e impedir ataques contra aplicações web e, em alguns casos, também contra o servidor web onde esta está sendo hospedada.
O WAF funciona interceptando todas as requisições que são direcionadas à aplicação web e comparando-as com um banco de dados de assinaturas para definir se aquilo é um ataque ou não (se você leu meu post sobre IPS e IDS vai perceber a semelhança em como as duas tecnologias funcionam). Dependendo do resultado de tal análise, a requisição é enviada à aplicação web ou, caso seja considerada maliciosa, é dropada e o ataque não funciona.
Geralmente, o mínimo que um WAF consegue fazer é garantir que todas as vulnerabilidades listadas no OWASP Top 10 (uma lista anual dos ataques mais populares) sejam identificadas e devidamente bloqueadas antes de causar qualquer prejuízo à aplicação. Geralmente, esta lista inclui falhas como SQL Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), entre várias outras falhas de programação e algumas de configuração.
Além do suporte de detecção de ataques (através de assinaturas desenvolvidas pelo vendor), outros aspectos que devem ser levados em conta são o desempenho, suporte à clusters, proteção contra ataques de brute-force, interface de administração bem desenvolvida, baixa taxa de falsos-positivos, etc. Preste bastante atenção à estes pontos quando pesquisar soluções para fazer uma boa compra e não acabar desperdiçando o dinheiro da sua empresa (todo mundo aqui deve saber como é difícil conseguir verba pra comprar tudo o que o Departamento de TI precisa, né? Imagina se você começar a fazer as compras erradas…).
O WAF que eu mais gosto e sempre recomendo a clientes é o ModSecurity, que hoje em dia é gerenciado e desenvolvido pela Trustwave. Este firewall funciona como um módulo do Apache e também oferece proteção para o Microsoft IIS e para o Nginx (o suporte deste último ainda está em beta e pode não atingir as suas necessidades para ser colocado em produção).
Como você deve imaginar, sozinho o ModSecurity oferece pouquíssima proteção. Por isso a Trustwave disponibiliza gratuitamente, através do site spiderlabs.github.com/owasp-modsecurity-crs/, um pacote com várias regras que suportam a detecção dos ataques listados no OWASP Top 10 e também regras genéricas que ajudam a detectar outros tipos de ataque que não fazem parte desta lista. Já é um excelente começo. Além disso, você também pode escrever as suas próprias regras para detectar coisas mais específicas à sua aplicação web.
Obviamente o ModSecurity não é a única solução disponível no mercado. Existem outros grandes players que também vendem este tipo de dispositivo e que oferecem uma excelente proteção para o seu ambiente. Um exemplo é o Cisco ACE Web Application firewall que oferece uma excelente proteção com um suporte excelente por parte do fabricante e um desempenho de acordo com ambientes de mais alta criticidade.
Deep packet inspection
Firewalls stateful oferecem o que chamamos de “shallow inspection” ou inspeção rasa, traduzindo ao pé da letra. Isso por levarem em consideração apenas informações que estão presentes nos cabeçalhos dos pacotes que passam por ele. Os outros tipos de software não são chamados assim, mas inspecionam apenas o conteúdo, ou seja, não fazem a inspeção dos cabeçalhos como o stateful firewall.
Para sanar esta questão foram criados os firewalls Deep Packet Inspection (análise à fundo de pacotes). Como o próprio nome diz, este tipo de firewall realiza uma inspeção bem completa em todos os pacotes que passam por seu motor de análise. Esta inspeção pode encontrar pacotes que não obedecem ao padrão de um determinado protocolo, vírus, worms,SPAM, ataques, etc. Também são capazes de analisar o tráfego e gerar informações estatísticas para facilitar o gerenciamento da rede.
Embora firewalls DPI possam ser usados para várias finalidades interessantes, que visam o bem tanto de administradores quanto de usuários, eles também têm sido usados por governos ditatoriais para regular o que os usuários de um país podem acessar ou mesmo comunicar com usuários de outros países. Um exemplo deste tipo de firewall é o utilizado pelo governo da China, chamado de The Great Firewall of China, que monitora de perto o que os cidadãos falam ou acessam na Internet. A Austrália tentou implantar uma tecnologia parecida há alguns anos atrás mas o projeto não foi para frente devido aos protestos dos cidadãos.
O funcionamento deste tipo de firewall não difere em nada dos outros. Os dados a serem analisados precisam passar por suas interfaces para que o motor de análise possa aplicar as políticas que você configurou no sistema. Isso é alcançado colocando o firewall in-line (“no meio” do caminho entre a origem e o destino) ou usando Span Ports (portas para onde o switch direciona o tráfego de todas as outras portas para fins de análise). Uma vez dentro do motor de análise do firewall, o pacote será enviado ao destino ou descartado de acordo com o que você configurou na política dele.
Alguns exemplos de firewalls deste tipo são nDPI, PACE, Hippie, Tstat, entre vários outros. Além disso, existe também o módulo L7-Filter que permite ao Netfilter do Linux trabalhar com DPI. Usando este módulo junto do Netfilter você será capaz de bloquear tráfego de aplicações como Kazaa, Jabber, Citrix, Bittorrent, Gnucleus, eDonkey2000, entre vários outros.
Firewalls Deep Packet Inspection oferecem uma excelente oportunidade para que você aumente o nível de proteção da sua rede enquanto coleta informações estatísticas para conseguir otimizar a performance do conjunto. Apenas lembre-se que tudo isso tem um preço: este tipo de firewall precisa de muitos recursos para que não se torne um gargalo na sua rede e comece a afetar o desempenho. Você precisa balancear a proteção e o desempenho neste caso para não ter que ficar ouvindo reclamações de usuários todos os dias .
Melhores práticas de firewalls
Vou aqui dar algumas dicas sobre o que você pode fazer para melhorar a segurança que o firewall oferece à sua rede. Como um não tem muito a ver com o outro, achei mais fácil fazer uma lista de tópicos:
Mantenha o software sempre atualizado: Seja uma appliance específica de firewall, seja um firewall pessoal da Comodo que você baixou para o seu Windows, ou mesmo o IPTables no seu Linux, o software sempre precisa estar atualizado para que o próprio firewall não fique vulnerável a ataques e acabe se tornando um problema ao invés de uma solução de segurança.
Troque a senha padrão: Appliances de todos os fabricantes sempre vêm com usuários criados previamente pelo próprio fabricante/desenvolvedor para permitir o seu login da primeira vez até você configurar tudo para que a appliance passe a proteger o seu ambiente. O problema é que geralmente essas contas têm uma senha padrão. E, como você deve imaginar, estas senhas padrão não são nenhum segredo: todos conhecem, inclusive o hacker que está tentando invadir a sua rede. Por isso, sempre que você compra um novo dispositivo a primeira coisa que você precisa fazer é modificar a senha do usuário criado automaticamente ou mesmo desabilitar a conta e criar uma nova com um novo nome.
Sempre atualize as regras do seu firewall: Redes, principalmente em organizações de médio e grande porte, mudam muito. Novos softwares são adicionados, novos parceiros se conectam à rede, novas máquinas são conectadas. Por isso, você sempre deve analisar e garantir que as regras que estão filtrando o seu tráfego atualmente estão oferecendo o máximo de proteção possível. Precisou fazer alguma alteração para uma aplicação funcionar? Não se esqueça de considerar também as implicações de segurança que essa mudança vai trazer. Pense sempre globalmente.
Controle quem pode fazer mudanças na política do firewall: É inviável permitir que qualquer um faça mudanças na sua política do firewall. Você tem que controlar muito bem quem pode fazer mudanças para evitar confusões com aplicações que não funcionam mais, brechas de segurança que foram abertas por uma mudança, etc. Tome cuidado para o firewall não virar a casa da mãe Joana.
Monitore quais mudanças podem ser feitas na política: Além de monitorar *quem* pode fazer mudanças na política, monitore também *quais* mudanças podem ser feitas. Algumas mudanças são tão grandes que não deveriam ser feitas durante o horário comercial, por exemplo. Sempre pense muito bem antes de alterar aquela linha na sua ACL!
Anote quais mudanças foram feitas, quando e por quem: É de extrema importância que um “log”, ou mesmo um diário, seja sempre atualizado com as mudanças feitas no firewall com o máximo de detalhes possível. Assim, você vai saber o motivo de uma aplicação importantíssima do departamento de Marketing ter parado de funcionar ontem à tarde (logo depois daquela mudança que você fez na política! ). Isso vai facilitar muito a sua vida quando você estiver resolvendo problemas relacionados ao firewall. Na verdade, recomendo que faça isso para todos os sistemas da sua rede, facilitando muito a administração da rede. Isso não é uma simples burocracia, é um meio de acompanhar tudo o que acontece na sua rede de perto para impedir que alguma coisa coloque a produção dos funcionários (e, como reflexo, o faturamento da empresa) em cheque. Seus superiores agradecem!
Sempre filtre o protocolo ICMP na borda: Embora o ICMP seja muito utilizado para reportar e ajudar a solucionar problemas nas redes, ele também pode acabar fornecendo uma grande quantidade de informações cruciais para que um atacante conheça ainda mais sobre a sua arquitetura. Por isso, este protocolo geralmente não entra e não sai – sendo sempre bloqueado pelos firewalls que ficam entre a sua rede interna e a Internet. Porém, eu gosto de permitir algumas mensagens para que tudo continue funcionando corretamente (e não se preocupe, elas não revelam nada importante a um possível atacante). São elas:
3.0: Destination network unreachable (rede inalcançável)
3.1: Destination host unreachable (host inalcançável)
3.2: Destination protocol unreachable (protocolo inalcançável)
3.3: Destination port unreachable (porta inalcançável)
3.4: Fragmentation required and DF flag set (é necessário fragmentação e flag DF)
4: Source Quench (pedido para diminuir o volume de tráfego enviado para o host de destino)
5: Redirect Message (redirecionamento)
11: Time exceeded (tempo excedido)
12: Parameter problem: bad IP header (problema com parâmetros inválidos no cabeçalho do IP)
A maioria dos softwares de firewall atuais conseguem filtrar o ICMP baseando-se no tipo da mensagem. Portanto, você dificilmente vai ter dor de cabeça para conseguir filtrar isso. Basta encontrar a opção correta para fazê-lo.
Liberando apenas estas mensagens, você ainda vai ter bastante ajuda do protocolo ICMP mas nada que vá ajudar um atacante vai ser enviado. Você continua seguro!
Acima, quando me refiro à política do firewall entenda que estou me referindo às regras que você configurou para o seu firewall. Esse conjunto de regras costuma ser chamado de política.
Conclusão
Bom, acredito que o texto te deu uma excelente base teórica sobre o que é um firewall, quais os tipos e qual o papel principal dele na sua rede. Portanto, não tem mais desculpas pra não proteger corretamente a sua rede daqui pra frente!
Lembre-se sempre: idependente do tipo de firewall ou se é uma appliance ou um software fazendo o papel de firewall, nunca deixe de atualizá-lo. Firewalls são como qualquer outro tipo de software e podem apresentar vários bugs no código que podem minar a proteção que eles oferecem. Por isso, sempre use a versão mais recente do firmware (se você usa appliances) ou do software que você usa como firewall. Aliás, essa dica serve para todo tipo de software: sempre use a versão mais recente.
Redes dificilmente ficam imutáveis por muito tempo. Sempre tem uma mudançazinha aqui, outra ali… e o firewall acaba tendo que se adaptar. Obviamente que você não pode se recusar a fazer as mudanças no firewall e ficar impactando o negócio, mas analise muito bem cada mudança que você fizer para não acabar abrindo demais o firewall e causar um problema de segurança. Nenhuma mudança deve ser feita na hora. Entenda o que o cliente/software precisa, estude o impacto disso no firewall e só então faça a mudança. Ah sim: sempre documente a mudança por menor que ela seja!
Não ache que só porque um servidor está na rede interna e apenas usuários internos o acessam ele não precisa de um firewall bem configurado rodando. Usuários internos são sim um grande perigo para uma empresa e você deve tratá-los como tal. Nunca deixe um cliente ou servidor sem um firewall pois isso vai facilitar muito a vida de um atacante localizado na rede interna. Lembre-se: um atacante que, pela Internet, consegue controlar um host interno é agora, para todos os efeitos, um usuário interno. Todo cuidado é pouco, não negligencie nada. Há vários casos Internet afora demonstrando como um ataque lançado por um usuário interno levou uma empresa à falência.
Créditos : Cheio de Gente.
