ATENÇÃO: Não estou interessado em transformar isso em uma guerra de chamas! Entendo que muitas pessoas têm fortes convicções sobre esse assunto, em grande parte porque se empenharam muito em suas soluções de firewall e também porque foram doutrinadas a acreditar em suas necessidades.

No entanto, estou procurando respostas de pessoas que são especialistas em segurança. Acredito que essa é uma pergunta importante, e a resposta beneficiará mais do que apenas eu e a empresa em que trabalho. Estou executando nossa rede de servidores há vários anos sem comprometer, sem nenhum firewall. Nenhum dos compromissos de segurança que tenham tido poderia ter sido evitada com um firewall.

Acho que estou trabalhando aqui há muito tempo, porque quando digo "servidores", sempre digo "serviços oferecidos ao público", não "bancos de dados secretos de cobrança interna". Como tal, quaisquer regras que teríamos em qualquer firewall teriam que permitir o acesso a toda a Internet. Além disso, nossos servidores de acesso público estão todos em um datacenter dedicado, separado do nosso escritório.

Outra pessoa fez uma pergunta semelhante, e minha resposta foi votada em números negativos. Isso me leva a acreditar que ou as pessoas que votaram negativamente não entenderam realmente minha resposta ou não compreendo segurança suficiente para estar fazendo o que estou fazendo atualmente.

Esta é minha abordagem à segurança do servidor:

1. Siga as diretrizes de segurança do meu sistema operacional antes de conectar meu servidor à Internet.

2. Use wrappers TCP para restringir o acesso ao SSH (e outros serviços de gerenciamento) a um pequeno número de endereços IP.

3. Monitore o estado deste servidor com Munin . E corrija os graves problemas de segurança inerentes ao nó Munin em sua configuração padrão.

4. Nmap meu novo servidor (também antes de conectar meu servidor à Internet). Se eu fizesse um firewall deste servidor, este deveria ser o conjunto exato de portas às quais as conexões de entrada deveriam ser restritas.

5. Instale o servidor na sala do servidor e atribua um endereço IP público.

6. Mantenha o sistema seguro usando o recurso de atualizações de segurança do meu sistema operacional.

Minha filosofia (e a base da pergunta) é que a segurança forte baseada em host remove a necessidade de um firewall. A filosofia geral de segurança diz que ainda é necessária uma segurança forte baseada em host, mesmo se você tiver um firewall (consulte as diretrizes de segurança ). A razão para isso é que um firewall que encaminha serviços públicos para um servidor habilita um invasor tanto quanto nenhum firewall. É o próprio serviço que está vulnerável e, como oferecer esse serviço para toda a Internet é um requisito de sua operação, restringir o acesso a ele não é o ponto.

Se houver são portas disponíveis no servidor que não precisam ser acessados por toda a Internet, depois que o software necessário para ser desligado no passo 1, e foi verificada a passo 4. Se um atacante quebrar com sucesso no servidor através de software vulnerável e eles mesmos abrem uma porta, o invasor pode (e faz) derrotar facilmente qualquer firewall, estabelecendo uma conexão de saída em uma porta aleatória. O objetivo da segurança não é se defender após um ataque bem-sucedido - que já é comprovadamente impossível - é manter os atacantes afastados em primeiro lugar.

Foi sugerido que existem outras considerações de segurança além de portas abertas - mas para mim isso parece defender a fé. Quaisquer vulnerabilidades no sistema operacional / pilha TCP devem ser igualmente vulneráveis, independentemente de existir ou não um firewall - com base no fato de que as portas estão sendo encaminhadas diretamente para esse sistema operacional / pilha TCP. Da mesma forma, executar o firewall no próprio servidor, em vez de tê-lo no roteador (ou pior, nos dois lugares), parece adicionar camadas desnecessárias de complexidade. Entendo a filosofia "a segurança vem em camadas", mas chega um momento em que é como construir um telhado, empilhando um número X de camadas de madeira compensada umas sobre as outras e depois perfurando todas elas. Outra camada de madeira compensada não vai parar os vazamentos naquele buraco que você

Para ser sincero, a única maneira de ver um firewall sendo útil para servidores é se ele tiver regras dinâmicas que impedem todas as conexões com todos os servidores de invasores conhecidos - como os RBLs para spam (que coincidentemente, é praticamente o que nosso servidor de email) . Infelizmente, não consigo encontrar nenhum firewall que faça isso. A próxima melhor coisa é um servidor IDS, mas isso pressupõe que o invasor não ataca seus servidores reais primeiro e que os invasores se preocupam em investigar toda a sua rede antes de atacar. Além disso, sabe-se que eles produzem um grande número de falsos positivos.

Vantagens do firewall:

1. Você pode filtrar o tráfego de saída.
2. Os firewalls da camada 7 (IPS) podem proteger contra vulnerabilidades conhecidas de aplicativos.
3. Você pode bloquear um determinado intervalo de endereços IP e / ou porta centralmente, em vez de tentar garantir que não haja serviço atendendo nessa porta em cada máquina individual ou negando acesso usando TCP Wrappers .
4. Os firewalls podem ajudar se você precisar lidar com usuários / administradores menos conscientes da segurança, pois eles forneceriam a segunda linha de defesa. Sem eles, é preciso ter certeza absoluta de que os hosts são seguros, o que exige um bom entendimento de segurança de todos os administradores.
5. Os logs do firewall forneceriam logs centrais e ajudariam na detecção de verificações verticais. Os logs do firewall podem ajudar a determinar se algum usuário / cliente está tentando se conectar à mesma porta de todos os seus servidores periodicamente. Para fazer isso sem um firewall, seria necessário combinar logs de vários servidores / hosts para obter uma visão centralizada.
6. Os firewalls também vêm com módulos anti-spam / antivírus, que também aumentam a proteção.
7. Segurança independente do SO. Com base no sistema operacional host, são necessárias diferentes técnicas / métodos para tornar o host seguro. Por exemplo, os TCP Wrappers podem não estar disponíveis em máquinas Windows.

Acima de tudo isso, se você não possui firewall e o sistema está comprometido, como você o detectaria? Não é possível confiar na tentativa de executar algum comando 'ps', 'netstat' etc. no sistema local, pois esses binários podem ser substituídos. O 'nmap' de um sistema remoto não tem proteção garantida, pois um invasor pode garantir que o kit raiz aceite conexões apenas do (s) endereço (s) IP de origem selecionado (s) em momentos selecionados.

Os firewalls de hardware ajudam nesses cenários, pois é extremamente difícil alterar os arquivos / sistemas operacionais do firewall em comparação com os sistemas / arquivos host.

Desvantagens do firewall:

1. As pessoas acham que o firewall cuidará da segurança e não atualiza os sistemas regularmente e interrompe serviços indesejados.
2. Eles custam. Às vezes, é necessário pagar uma taxa de licença anual. Especialmente se o firewall tiver módulos antivírus e anti-spam.
3. Ponto único de falha adicional. Se todo o tráfego passar por um firewall e o firewall falhar, a rede será interrompida. Podemos ter firewalls redundantes, mas o ponto anterior sobre o custo fica ainda mais amplificado.
4. O rastreamento com estado não fornece valor em sistemas públicos que aceitam todas as conexões de entrada.
5. Os firewalls com estado são um gargalo maciço durante um ataque DDoS e geralmente são a primeira coisa a falhar, porque tentam manter o estado e inspecionar todas as conexões de entrada.
6. Os firewalls não conseguem ver o tráfego criptografado. Como todo o tráfego deve ser criptografado de ponta a ponta, a maioria dos firewalls agrega pouco valor aos servidores públicos. Alguns firewalls de última geração podem receber chaves privadas para encerrar o TLS e ver dentro do tráfego, no entanto, isso aumenta ainda mais a suscetibilidade do DDoS ao firewall e quebra o modelo de segurança de ponta a ponta do TLS.
7. Os sistemas operacionais e aplicativos são corrigidos contra vulnerabilidades muito mais rapidamente que os firewalls. Os fornecedores de firewall geralmente enfrentam problemas conhecidos há anos sem aplicar patches, e o patch de um cluster de firewall normalmente requer tempo de inatividade para muitos serviços e conexões de saída.
8. Os firewalls estão longe de serem perfeitos, e muitos são notoriamente defeituosos. Os firewalls são apenas softwares executados em alguma forma de sistema operacional, talvez com um ASIC ou FPGA extra, além de uma CPU (geralmente lenta). Os firewalls têm bugs, mas parecem fornecer poucas ferramentas para resolvê-los. Portanto, os firewalls adicionam complexidade e uma fonte adicional de erros difíceis de diagnosticar a uma pilha de aplicativos.

TCP Wrappers pode ser chamado de implementação de firewall baseado em host; você está filtrando o tráfego de rede.

No ponto em que um invasor faz conexões de saída em uma porta arbitrária, um firewall também fornece um meio de controlar o tráfego de saída; um firewall configurado corretamente gerencia a entrada e a saída de maneira apropriada ao risco relacionado ao sistema.

No ponto sobre como qualquer vulnerabilidade TCP não é atenuada por um firewall, você não está familiarizado com o funcionamento dos firewalls. A Cisco possui várias regras disponíveis para download que identificam pacotes construídos de maneira a causar problemas específicos nos sistemas operacionais. Se você pegar o Snort e começar a executá-lo com o conjunto de regras correto, também será alertado sobre esse tipo de coisa. E, é claro, as iptables do Linux podem filtrar pacotes maliciosos.

Basicamente, um firewall é uma proteção proativa. Quanto mais você se afastar de ser proativo, maior será a probabilidade de se encontrar em uma situação em que está reagindo a um problema em vez de evitá-lo. Concentrar sua proteção na fronteira, como em um firewall dedicado, facilita o gerenciamento das coisas, porque você tem um ponto de estrangulamento central em vez de duplicar regras em todos os lugares.

Mas nada isolado é necessariamente uma solução final. Uma boa solução de segurança geralmente é de várias camadas, onde você possui um firewall na borda, invólucros TCP no dispositivo e provavelmente algumas regras em roteadores internos. Você geralmente deve proteger a rede da Internet e proteger os nós um do outro. Essa abordagem em várias camadas não é como perfurar um buraco em várias folhas de madeira compensada, é mais como colocar um par de portas para que um invasor tenha duas fechaduras para quebrar em vez de apenas uma; isso é chamado de armadilha do homem em segurança física, e quase todo edifício tem um por um motivo. :)

(Você pode ler " Vida sem Firewalls ")

Agora: Que tal ter um sistema legado para o qual não há mais patches publicados? Que tal não poder aplicar os patches às N-máquinas no momento em que você precisa fazê-lo, enquanto ao mesmo tempo você pode aplicá-los em menos nós na rede (firewalls)?

Não faz sentido debater a existência ou necessidade do firewall. O que realmente importa é que você precisa implementar uma política de segurança. Para fazer isso, você usará as ferramentas que o implementarem e o ajudará a gerenciar, expandir e evoluir. Se forem necessários firewalls, tudo bem. Se eles não forem necessários, tudo bem também. O que realmente importa é ter uma implementação funcional e verificável da sua política de segurança.

A maioria de suas explicações parece refutar a necessidade de um firewall, mas não considero conveniente ter um, além da pequena quantidade de tempo para configurá-lo.

Poucas coisas são uma "necessidade" no sentido estrito da palavra. Segurança é mais sobre como configurar todos os bloqueios que você puder. Quanto mais trabalho for necessário para invadir o servidor, menor a chance de ataques bem-sucedidos. Você deseja tornar mais trabalho invadir suas máquinas do que em qualquer outro lugar. Adicionar um firewall faz mais trabalho.

Eu acho que um uso importante é redundância em segurança. Outra vantagem dos firewalls é que você pode simplesmente deixar de tentar se conectar a qualquer porta em vez de responder a solicitações rejeitadas - isso tornará o nmapping um pouco mais inconveniente para um invasor.

O mais importante para mim, na observação prática da sua pergunta, é que você pode bloquear SSH, ICMP e outros serviços internos em sub-redes locais, além de limitar as taxas de conexões de entrada para ajudar a aliviar os ataques do DOS.

"O objetivo da segurança não é se defender após um ataque bem-sucedido - que já se provou impossível - é manter os atacantes de fora em primeiro lugar".

Discordo. A limitação de danos pode ser igualmente importante. (de acordo com esse ideal, por que senhas de hash? ou cole seu software de banco de dados em um servidor diferente dos aplicativos da web?) Acho que o velho ditado "Não cole todos os seus ovos em uma cesta" é aplicável aqui.

Should I firewall my server?Boa pergunta. Parece que há pouco sentido em colocar um firewall em cima de uma pilha de rede que já rejeita as tentativas de conexão a todos, exceto ao punhado de portas que estão legitimamente abertas. Se houver uma vulnerabilidade no sistema operacional que permita que pacotes criados com códigos maliciosos interrompam / explorem um host, um firewall em execução no mesmo host impediria a exploração? Bem, talvez ...

E esse é provavelmente o motivo mais forte para executar um firewall em todos os hosts: um firewall pode impedir que uma vulnerabilidade de pilha de rede seja explorada. Essa é uma razão suficientemente forte? Não sei, mas suponho que alguém possa dizer: "Ninguém nunca foi demitido por instalar um firewall".

Outro motivo para executar um firewall em um servidor é dissociar essas duas preocupações fortemente correlacionadas:

1. De onde e para quais portas, eu aceito conexões?
2. Quais serviços estão executando e ouvindo conexões?

Sem um firewall, o conjunto de serviços em execução (juntamente com as configurações para tcpwrappers e outros) determina completamente o conjunto de portas que o servidor abrirá e de quem as conexões serão aceitas. Um firewall baseado em host oferece ao administrador flexibilidade adicional para instalar e testar novos serviços de maneira controlada antes de torná-los mais amplamente disponíveis. Se essa flexibilidade não for necessária, haverá menos motivos para instalar um firewall em um servidor.

Em uma nota final, há um item não mencionado na sua lista de verificação de segurança que eu sempre adiciono e que é um sistema de detecção de intrusão (HIDS) baseado em host, como o AIDE ou o samhain . Um bom HIDS torna extremamente difícil para um invasor fazer alterações indesejadas no sistema e permanecer sem ser detectado. Acredito que todos os servidores devem estar executando algum tipo de HIDS.

Um firewall é uma ferramenta. Ele não torna as coisas seguras por si só, mas pode contribuir como uma camada em uma rede segura. Isso não significa que você precise de um, e certamente me preocupo com as pessoas que dizem cegamente "Preciso obter um firewall" sem entender por que pensam dessa maneira e que não entendem os pontos fortes e fracos dos firewalls.

Podemos dizer que não precisamos de muitas ferramentas ... É possível executar um computador com Windows sem o Antivirus? Sim, é ... mas é uma boa camada de seguro ter um.

Eu diria o mesmo sobre firewalls - o que mais você pode dizer sobre eles, eles são um bom nível de seguro. Eles não substituem patches, travam máquinas, desativam serviços que você não usa, registram, etc ... mas podem ser um complemento útil.

Eu também sugiro que a equação mude um pouco, dependendo de você estar ou não falando em colocar um firewall na frente de um grupo de servidores cuidadosamente cuidados, como você parece ser, ou de uma LAN típica com uma mistura de estações de trabalho e servidores , alguns dos quais podem estar executando algumas coisas bem peludas, apesar dos melhores esforços e desejos da equipe de TI.

Mais uma coisa a considerar é o benefício de criar um alvo obviamente endurecido. Segurança visível, sejam luzes brilhantes, fechaduras pesadas e uma caixa de alarme óbvia em um prédio; ou um firewall óbvio no intervalo de endereços IP de uma empresa pode impedir o invasor casual - eles procurarão presas mais fáceis. Isso não impedirá o invasor determinado que sabe que você tem as informações que eles desejam e está determinado a obtê-las, mas ainda assim vale a pena deter os invasores casuais - especialmente se você souber que qualquer invasor cujas sondas persistem além do impedimento precisa ser levado a sério. .

Todas ótimas perguntas. MAS - Estou muito surpreso que o DESEMPENHO não foi trazido para a mesa.

Para front-ends da Web altamente usados ​​(em termos de CPU), o firewall local realmente prejudica o desempenho, ponto final. Experimente um teste de carga e veja. Eu vi isso várias vezes. Desativar o firewall aumentou o desempenho (solicitação por segundo) em 70% ou mais.

Essa troca deve ser considerada.

Um firewall é proteção adicional. Três cenários específicos contra os quais ele protege são ataques à pilha de rede (por exemplo, o sistema operacional do servidor tem uma vulnerabilidade em pacotes especialmente criados que nunca atingem o nível de portas), uma invasão bem-sucedida que faz uma conexão com o "telefone residencial" (ou envia spam ou qualquer outra coisa) ) ou uma invasão bem-sucedida abrindo uma porta do servidor ou, menos detectável, observe uma sequência de batidas na porta antes de abrir uma porta. É verdade que os dois últimos têm a ver com mitigar o dano de uma intrusão, em vez de evitá-la, mas isso não significa que seja inútil. Lembre-se de que a segurança não é uma proposta de tudo ou nada; adota-se uma abordagem em camadas, cinto e suspensórios, para atingir um nível de segurança suficiente para suas necessidades.

Não sou especialista em segurança, de forma alguma, mas parece que você está com firewall. Parece que você pegou algumas das principais funcionalidades de um firewall e o tornou parte de suas políticas e procedimentos. Não, você não precisa de um firewall se quiser fazer o mesmo trabalho que um firewall. Quanto a mim, prefiro fazer o melhor possível para manter a segurança, mas ter um firewall olhando por cima do ombro, mas em algum momento em que você pode fazer tudo o que o firewall está fazendo, ele começa a se tornar irrelevante.

Certamente não é necessário um firewall para configurações menores. Se você possui um ou dois servidores, os firewalls do software são mantidos. Dito isso, não corremos sem firewalls dedicados, e há algumas razões pelas quais mantenho essa filosofia:

Separação de funções

Servidores são para aplicativos. Os firewalls são para inspeção, filtragem e políticas de pacotes. Um servidor web deve se preocupar em servir páginas da web, e é isso. Colocar as duas funções em um dispositivo é como pedir que seu contador também seja seu guarda de segurança.

O software é um alvo em movimento

O software no host está sempre mudando. Os aplicativos podem criar suas próprias exceções de firewall. O sistema operacional é atualizado e corrigido. Os servidores são uma área de "administrador" de alto tráfego, e suas políticas de firewall / políticas de segurança geralmente são muito mais importantes para a segurança do que as configurações de aplicativos. Em um ambiente Windows, suponha que alguém cometa algum erro em algum nível da Diretiva de Grupo e desative o Firewall do Windows nos PCs de desktops e não perceba que isso será aplicado aos servidores. Você está aberto em questão de cliques.

Por falar em atualizações, as atualizações de firmware do firewall geralmente são lançadas uma ou duas vezes por ano, enquanto as atualizações de SO e serviço são um fluxo constante.

Serviços / políticas / regras reutilizáveis, gerenciabilidade

Se eu configurar um serviço / política chamado "Servidor da Web" uma vez (por exemplo, TCP 80 e TCP 443) e aplicá-lo ao "grupo de servidores da Web" no nível do firewall, isso será muito mais eficiente (algumas alterações na configuração) e exponencialmente menos propenso a erros humanos do que configurar serviços de firewall em 10 caixas e abrir 2 portas x 10 vezes. Quando essa política precisa mudar, é 1 alteração versus 10.

Ainda posso gerenciar um firewall durante um ataque ou após um comprometimento

Digamos que meu firewall + servidor de aplicativos baseado em host esteja sendo atacado e a CPU esteja fora do gráfico. Para começar a descobrir o que está acontecendo, estou à mercê de minha carga ser menor do que o atacante até mesmo entrar e olhar para ela.

Uma experiência real - uma vez desarrumei uma regra de firewall (deixou portas para QUALQUER, em vez de uma específica, e o servidor tinha um serviço vulnerável), e o invasor realmente teve uma sessão de Área de Trabalho Remota ao vivo na caixa. Toda vez que eu começava a ter uma sessão, o atacante matava / desconectava minha sessão. Se não fosse por poder interromper esse ataque de um dispositivo de firewall independente, isso poderia ter sido muito pior.

Monitoramento Independente

O registro em unidades de firewall dedicadas geralmente é muito superior aos firewalls de software baseados em host. Alguns são bons o suficiente para que você nem precise de um software de monitoramento SNMP / NetFlow externo para obter uma imagem precisa.

Conservação do IPv4

Não há razão para ter dois endereços IP, se um for para web e outro para email. Mantenha os serviços em caixas separadas e roteie as portas adequadamente por meio do dispositivo projetado para fazer isso.

Blockquote Bem, você está certo, eu não coloquei nenhum contra lá. Contras: aumento da complexidade da rede, ponto único de falha, interface de rede única através da qual a largura de banda é gargalada. Da mesma forma, erros administrativos cometidos em um firewall podem matar toda a sua rede. E os deuses proíbem que você se esconda disso enquanto isso é uma viagem de 20 minutos até a sala do servidor.

Primeiro, adicionar no máximo um salto roteado adicional através da sua rede não é complexo. Segundo, nenhuma solução de firewall implementada com um único ponto de falha é completamente inútil. Assim como você agrupa seu servidor ou serviços importantes e usa NICs vinculadas, você implementa firewalls altamente disponíveis. Não fazer isso, ou não reconhecer e saber que você faria isso é muito míope. Simplesmente afirmar que existe uma única interface não torna automaticamente um gargalo em algo. Essa afirmação mostra que você não tem idéia de como planejar e implantar adequadamente um firewall dimensionado para lidar com o tráfego que fluiria pela sua rede. Você está certo ao dizer que um erro na política pode causar danos a toda a sua rede, mas eu argumentaria que a manutenção de políticas individuais em todos os seus servidores é muito mais suscetível a erros que um único local.

Quanto ao argumento de que você acompanha os patches de segurança e segue os guias de segurança; esse é um argumento instável, na melhor das hipóteses. Normalmente, os patches de segurança não estão disponíveis até depois que uma vulnerabilidade é descoberta. Isso significa que, durante todo o tempo em que você estiver executando servidores endereçáveis ​​publicamente, eles ficarão vulneráveis ​​até serem corrigidos. Como outros já apontaram, os sistemas IPS podem ajudar a evitar comprometimentos com essas vulnerabilidades.

Se você acha que seus sistemas são os mais seguros possíveis, é uma boa confiança. No entanto, eu recomendo que você faça uma auditoria de segurança profissional em sua rede. Pode apenas abrir seus olhos.

Em geral, segurança é coisa de cebola, como já mencionado. Existem razões pelas quais existem firewalls, e não são apenas todos os outros lemmings que são idiotas idiotas.

Essa resposta vem, pois a pesquisa de 'fail2ban' nesta página não me deu nenhum resultado. Então, se eu duplicar outro conteúdo, tenha paciência comigo. E desculpe-me, se eu reclamar um pouco, forneço uma experiência clara, pois isso pode ser útil para os outros. :)

Considerações de rede, local x externa

Isso é bastante específico do Linux e se concentra no firewall baseado em host, que geralmente é o caso de uso. O firewall externo anda de mãos dadas com uma estrutura de rede adequada e outras considerações de segurança geralmente entram nessa. Ou você sabe o que está implícito aqui, provavelmente não precisará dessa publicação. Ou não, então continue lendo.

A execução de firewalls externamente e localmente pode parecer um trabalho contra-intuitivo e duplo. Mas isso também oferece a possibilidade de mudar as regras no externo, sem comprometer a segurança de todos os outros hosts por trás dele. A necessidade pode surgir por razões de depuração ou porque alguém acabou de foder. Outro caso de uso será apresentado na seção 'firewall global adaptável', para o qual você também precisará de firewalls globais e locais.

Custo e disponibilidade e a mesma história o tempo todo:

O firewall é apenas um aspecto de um sistema seguro adequado. Não instalar um firewall, pois 'custa' dinheiro, introduz um SPOF ou o que for apenas besteira, perdoe meu francês aqui. Basta configurar um cluster. Ah, mas e se a célula de incêndio tiver uma interrupção? Em seguida, configure seu cluster em dois ou mais compartimentos de incêndio.

Mas e se todo o datacenter estiver inacessível, pois as duas transportadoras externas estão fora do negócio (a escavadeira matou sua fibra)? Apenas faça seu cluster abrangendo vários datacenters, então.

Isso é caro? Clusters são muito complexos? Bem, a paranóia tem que ser paga.

Reclamar sobre SPOFs, mas não querer pagar mais dinheiro ou criar configurações pouco mais complexas é um caso claro de padrões duplos ou apenas uma pequena carteira do lado da empresa ou do cliente.

Esse padrão se aplica a TODAS essas discussões, não importa qual serviço seja o assunto atual do dia. Não importa se é um gateway VPN, um Cisco ASA usado apenas para firewall, um banco de dados MySQL ou PostgreSQL, um sistema virtual ou hardware de servidor, um back-end de armazenamento, switches / roteadores, ...

Até agora você deve ter uma ideia.

Por que se preocupar com firewall?

Em teoria, seu raciocínio é sólido. (Apenas serviços em execução podem ser explorados.)

Mas isso é apenas metade da verdade. O firewall, especialmente o firewall com estado, pode fazer muito mais por você. Os firewalls sem estado são importantes apenas se houver problemas de desempenho como outros já mencionados.

Controle de acesso fácil, central e discreto

Você mencionou os wrappers TCP que implementam basicamente a mesma funcionalidade para proteger o seu. Por uma questão de argumento, vamos assumir que alguém não conhece tcpde gosta de usar o mouse? fwbuilderpode vir à mente.

Ter acesso total a partir da sua rede de gerenciamento é algo que você deveria ter habilitado, que é um dos primeiros casos de uso do firewall baseado em host.

Que tal uma configuração para vários servidores, onde o banco de dados é executado em outro lugar e você não pode colocar ambas / todas as máquinas em uma sub-rede compartilhada (privada) por qualquer motivo? Use o firewall para permitir o acesso MySQL na porta 3306 apenas para o único endereço IP fornecido do outro servidor, pronto, simples.

E isso também funciona perfeitamente para o UDP. Ou qualquer protocolo. Os firewalls podem ser extremamente flexíveis. ;)

Mitigação do Portscan

Além disso, com o firewall, as portas gerais podem ser detectadas e atenuadas, pois a quantidade de conexões por período de tempo pode ser monitorada via kernel e sua pilha de rede, e o firewall pode agir de acordo com isso.

Também pacotes inválidos ou obscuros podem ser manipulados antes que eles cheguem ao seu aplicativo.

Limitação de tráfego de saída

Filtrar o tráfego de saída geralmente é um pé no saco. Mas pode ser uma obrigação, dependendo do contrato.

Estatisticas

Outra coisa que um firewall pode oferecer é a estatística. (Pense watch -n1 -d iptables -vnxL INPUTem adicionar algumas regras para endereços IP especiais logo na parte superior para ver se os pacotes estão chegando).

Você pode ver à luz do dia se as coisas funcionam ou não. O que é MUITO útil na solução de problemas de conexões e na capacidade de informar a outra pessoa pelo telefone que você não recebe pacotes, sem precisar recorrer ao chat tcpdump. A rede é divertida, a maioria das pessoas agora sabe o que está fazendo e, muitas vezes, são apenas erros de roteamento simples. Inferno, nem sempre eu sei o que estou fazendo. Embora eu tenha trabalhado com literalmente dezenas de sistemas e dispositivos complexos, muitas vezes também com tunelamento até agora.

IDS / IPS

O firewall da Layer7 é geralmente óleo de cobra (IPS / IDS), se não for atendido adequadamente e atualizado regularmente. Além disso, as licenças são muito caras, então eu não compraria uma, se você não tiver necessidade real de obter tudo o que o dinheiro pode comprar.

Masqerading

Fácil, tente isso com seus invólucros. : D

Encaminhamento de porta local

Veja mascarada.

Protegendo os canais de acesso por senha com endereços IP dinâmicos

E se os clientes tiverem endereços IP dinâmicos e não houver uma configuração de VPN implantada? Ou outras abordagens dinâmicas para firewall? Isso já foi sugerido na pergunta e aqui virá um caso de uso para o Infelizmente, não consigo encontrar nenhum firewall que faça isso. parte.

Desabilitar o acesso à conta raiz por meio de uma senha é uma obrigação. Mesmo se o acesso for limitado a determinados endereços IP.

Além disso, ainda ter outra conta em branco pronta com um login com senha se as chaves ssh forem perdidas ou a implantação falhar é muito útil se algo der realmente errado (um usuário tem acesso administrativo à máquina e 'coisas aconteceram'?). É a mesma idéia para o acesso à rede, já que o modo de usuário único no Linux ou o uso init=/bin/bashvia grubpara acesso local são realmente muito ruins e não podem usar um disco ativo por qualquer motivo. Não ria, existem produtos de virtualização proibindo isso. Mesmo se a funcionalidade existir, e se uma versão desatualizada do software for executada sem a funcionalidade?

De qualquer forma, mesmo se você executar o seu daemon ssh em alguma porta esotérica e não na 22, se não tiver implementado coisas como porta batendo (para abrir outra porta e, portanto, atenuar as portas), lentamente se tornando muito impraticável), as verificações de portas detectarão seu serviço eventualmente.

Geralmente, você também configura todos os servidores com a mesma configuração, com as mesmas portas e serviços por motivos de eficiência. Você não pode configurar o ssh para uma porta diferente em todas as máquinas. Além disso, você não pode alterá-lo em todas as máquinas sempre que considerar informações "públicas", porque elas já estão após uma verificação. A questão de nmapser legal ou não não é um problema ao ter uma conexão Wi-Fi hackeada à sua disposição.

Se essa conta não for denominada 'root', as pessoas poderão não conseguir adivinhar o nome da conta de usuário do seu 'backdoor'. Mas eles saberão, se conseguirem outro servidor da sua empresa, ou apenas comprarem algum espaço na web, e tiverem uma visão não-enraizada / livre / não contida /etc/passwd.

Para uma ilustração puramente teórica agora, eles poderiam usar um site hackável lá para obter acesso ao seu servidor e verificar como as coisas geralmente são executadas em seu lugar. Suas ferramentas de busca de hackers podem não funcionar 24 horas por dia, 7 dias por semana (normalmente, por motivos de desempenho de disco para as verificações do sistema de arquivos?) E seus antivírus não são atualizados no segundo em que um novo dia zero vê a luz do dia, portanto Não detecte esses acontecimentos de uma só vez e, sem outras medidas de proteção, você nunca saberá o que aconteceu. Para voltar à realidade, se alguém tiver acesso a explorações de dia zero, é muito provável que ele não atinja seus servidores de qualquer maneira, pois eles são caros. Isso é apenas para ilustrar que sempre existe uma maneira de entrar no sistema se a 'necessidade' surgir.

Mas, novamente, sobre o assunto, não use uma conta extra com senha e não se incomode? Por favor, continue a ler.

Mesmo que os invasores obtenham o nome e a porta dessa conta extra, uma combinação fail2ban+ iptablesos interromperá, mesmo que você tenha usado apenas uma senha de oito letras. Além disso, o fail2ban também pode ser implementado para outros serviços, ampliando o horizonte de monitoramento!

Para seus próprios serviços, se surgir a necessidade: Basicamente, todas as falhas de log de serviço em um arquivo podem obter suporte para fail2ban através do fornecimento de um arquivo, qual regex corresponder e quantas falhas são permitidas, e o firewall banirá felizmente todos os endereços IP é dito para.

Não estou dizendo para usar senhas de 8 dígitos! Mas se eles forem banidos por 24 horas por cinco tentativas erradas de senha, você pode adivinhar quanto tempo eles terão que tentar se não tiverem uma botnet à sua disposição, mesmo com uma segurança tão ruim. E você ficaria surpreso com as senhas que os clientes costumam usar, não apenas com ssh. Observar as senhas de e-mail das pessoas via Plesk diz tudo o que você prefere não saber, se quiser, mas o que não estou tentando sugerir aqui, é claro. :)

Firewall global adaptável

fail2bané apenas um aplicativo que usa algo do tipo iptables -I <chain_name> 1 -s <IP> -j DROP, mas você pode criar essas coisas facilmente com alguma mágica do Bash rapidamente.

Para expandir ainda mais algo assim, agregue todos os endereços IP do fail2ban dos servidores dentro da sua rede em um servidor extra, que classifica todas as listas e as passa por sua vez para os firewalls principais, bloqueando todo o tráfego já existente na borda da sua rede.

Essa funcionalidade não pode ser vendida (é claro que pode, mas será apenas um sistema quebradiço e uma merda), mas precisa ser entrelaçada em sua infraestrutura.

Enquanto isso, você também pode usar endereços IP da lista negra ou listas de outras fontes, sejam elas agregadas por você ou por outras externas.

No mundo físico, as pessoas protegem objetos de valor colocando-os em cofres. Mas não há cofre que não possa ser invadido. Os cofres ou contêineres de segurança são classificados em termos de quanto tempo leva para forçar a entrada. O objetivo do cofre é atrasar o atacante por tempo suficiente para que sejam detectados e as medidas ativas parem o ataque.

Da mesma forma, a suposição de segurança adequada é que suas máquinas expostas acabarão sendo comprometidas. Firewalls e hosts bastiões não estão configurados para impedir que seu servidor (com seus dados valiosos) se comprometa, mas para forçar um invasor a comprometê-los primeiro e permitir que você detecte (e detenha) o ataque antes que os objetos de valor sejam perdidos.

Observe que nem firewalls nem cofres bancários protegem contra ameaças internas. Essa é uma das razões pelas quais os contadores bancários tiram duas semanas consecutivas de licença e os servidores têm todas as precauções internas de segurança, mesmo protegidas por hosts bastiões.

Você parece sugerir na postagem original que está encaminhando pacotes "fora do mundo" pelo firewall diretamente para o servidor. Nesse caso, sim, seu firewall não está fazendo muito. Uma melhor defesa de perímetro é feita com dois firewalls e um host bastião, onde não há conexão lógica direta de fora para dentro - toda conexão termina no host bastião DMZ; cada pacote é examinado adequadamente (e possivelmente analisado) antes de encaminhar.

É difícil prever vulnerabilidades. É praticamente impossível prever de que maneira sua infraestrutura será explorada. Ter um firewall "eleva os padrões" para um invasor que deseja explorar uma vulnerabilidade, e essa é a parte importante, ANTES de você saber o que é essa vulnerabilidade. Além disso, as ramificações do firewall podem ser facilmente entendidas com antecedência, portanto, é improvável que você CAUSE problemas com um firewall mais graves do que os que provavelmente evitará.

É por isso que "ninguém nunca foi demitido por instalar um firewall". Sua implementação é de risco muito baixo e tem uma ALTA probabilidade de impedir ou mitigar uma exploração. Além disso, as vulnerabilidades mais realmente desagradáveis ​​acabam sendo exploradas pela automação; portanto, qualquer coisa "incomum" acaba quebrando um bot ou, pelo menos, fazendo com que ele pule você em favor de um alvo mais fácil.

Nota; firewalls não são apenas para a internet. O seu departamento de contabilidade. não precisa de ssh / o que quer que seja para o seu servidor LDAP, portanto não entregue a eles. A compartimentação de serviços internos pode fazer uma grande diferença no trabalho de limpeza, caso algo viole as muralhas do castelo.

Devo dizer a Ernie que, embora você pareça fazer muito para proteger seus servidores e mitigar ataques e vulnerabilidades, eu não concordo com sua posição em firewalls.

Trato a segurança um pouco como uma cebola, pois, idealmente, você tem camadas pelas quais precisa passar antes de chegar ao núcleo e, pessoalmente, acho que é muito equivocado não ter algum tipo de firewall de hardware no perímetro da sua rede.

Admito que estou abordando isso do ponto de vista "com o que estou acostumado", mas sei que todo mês recebo uma pequena lista dos patches da Microsoft, muitos deles sendo explorados na natureza. . Eu imagino que o mesmo acontece com praticamente qualquer sistema operacional e conjunto de aplicativos nos quais você gostaria de pensar.

Agora não estou sugerindo que os firewalls acabem com isso, nem os firewalls são imunes a erros / vulnerabilidades; obviamente, um firewall de "hardware" é apenas um software executado em uma pilha de hardware.

Dito isso, durmo muito mais seguro sabendo que, se eu tiver um servidor que precise apenas da porta 443 para ser acessível a partir da web, meu perímetro Juniper garantirá que apenas a porta 443 seja acessível a partir da web. Não apenas isso, mas meu Palo Alto garante que o tráfego recebido seja descriptografado, inspecionado, registrado e verificado em busca de IPS / IDS - não que isso elimine a necessidade de manter os servidores seguros e atualizados, mas por que você NÃO consideraria esse benefício uma vez que ele pode mitigar explorações de dia zero e bons e velhos erros humanos?

Antes de tudo, por sua palestra sobre encaminhamento de porta, acho que você está confluindo o firewall com o NAT. Embora atualmente os NATs funcionem frequentemente como firewalls de fato, esse não é o objetivo para o qual foram projetados. NAT é uma ferramenta de roteamento. Os firewalls são para regular o acesso. É importante, para maior clareza de pensamento, manter esses conceitos distintos.

É verdade que colocar um servidor atrás de uma caixa NAT e depois configurá-lo para encaminhar qualquer coisa para esse servidor não é mais seguro do que colocar o servidor diretamente na Internet. Não acho que alguém discuta isso.

Da mesma forma, um firewall configurado para permitir todo o tráfego não é um firewall.

Mas, "permitir todo o tráfego" é realmente a política que você deseja? Alguém já precisou ssh para algum servidor seu a partir de um endereço IP russo? Enquanto você está mexendo na configuração de algum novo daemon de rede experimental, o mundo inteiro realmente precisa de acesso a ele?

O poder de um firewall é que ele permite manter aberto apenas os serviços que você sabe que precisam estar abertos e manter um único ponto de controle para implementar esta política.

Firewalls de inspeção de pacotes com estado NÃO pertencem à frente de servidores públicos. Você está aceitando todas as conexões, portanto o rastreamento do estado é bastante inútil. Os firewalls tradicionais são uma grande responsabilidade nos ataques DDoS e geralmente são a primeira coisa a falhar sob um ataque DDoS, mesmo antes que a largura de banda do link ou os recursos do servidor sejam totalmente consumidos.

Os filtros de pacotes sem estado nos roteadores fazem sentido na frente dos servidores públicos, mas somente se eles puderem lidar com a taxa de linha de todo o tráfego de entrada e saída (como uma ACL de hardware em um roteador).

Google, Facebook e até Microsoft não colocam "firewalls" tradicionais em frente a servidores públicos. Qualquer pessoa que tenha executado serviços públicos da Web na escala "mais de um servidor" deve saber disso.

Outras funções encontradas nos firewalls tradicionais, como o Cisco ASAs ou o que for melhor implementado nos próprios hosts, onde podem ser dimensionadas de maneira eficaz. De qualquer forma, o registro em log, o IDS etc. são todos os recursos de software dos firewalls; portanto, eles se tornam um grande gargalo e alvo de DDoS se colocados na frente de servidores acessíveis ao público.

Por que todos os seus servidores precisam de um endereço público?

Instale o servidor na sala do servidor e atribua um endereço IP público.

Dos 14 servidores que eu executo regularmente, apenas 2 têm interfaces acessíveis ao público.

Editado para adicionar : em outras redes que eu tenho ajudado no gerenciamento, tivemos a capacidade de desativar / ativar serviços à vontade, enquanto não tínhamos acesso para gerenciar o firewall. Eu não posso nem começar a dizer quantas vezes, inadvertidamente, é claro, um serviço desnecessário (SMTP) foi ativado e deixado ligado, e a única coisa que nos impediu de nos tornar um depósito de spam e de entrar na lista negra no processo foi um firewall.

Além disso, todo o tráfego que passa entre os servidores é totalmente criptografado?

Você certamente pode dirigir um carro a 100 km / h, sem cintos de segurança, sem airbags e pneus carecas, mas por que você faria?

Os firewalls podem impedir que os usuários do sistema abram serviços acessíveis pela rede dos quais os administradores não tenham conhecimento, ou enviem portas para outras máquinas. Ao usar o módulo hashlimit, os firewalls também podem limitar os abusadores com base no IP remoto.

Um firewall é outra rede de segurança que garante que suas políticas sejam seguidas. Claro, não execute serviços que você não espera.

Definitivamente, recomendo que as atualizações de software sejam aplicadas em tempo hábil, por exemplo, mas também recomendo firewalls em todas as máquinas. É como quando eu dirijo: Claro que tento evitar obstáculos e outros carros, mas também uso cinto de segurança e airbags para o caso de acontecer algo inesperado.

Você pode não estar percebendo o quanto está se beneficiando dos firewalls simplesmente porque todo mundo os está usando. Em um dia em que literalmente todo mundo, usuários domésticos de DSL têm firewalls instalados no local, o sniffing de portas foi praticamente abandonado como um vetor de ataque possível. Um hacker decente não vai perder tempo checando essas coisas.