Segurança em Redes com Firewalld e Iptables by intersolar10

Segurança em Redes com Firewalld e Iptables SOLUÇÃO DE FIREWALL DE ALTO DESEMPENHO COM IMPLEMENTAÇÃO DE SOFTWARE LIVRE

André M. H. Taniguchi. andre_mht@terra.com.br

28 de Fevereiro de 2019.

Figura 1: FIRE-RESIST WALL/FIREWALL. – parede resistente à fogo ou parede anti-fogo, é uma estrutura física que inibe o dano, evita o mal, o alastrar do fogo. A verdadeira história do “Fire + Wall / Firewall” e a primeira menção à este termo, sugiu em terras longínquoas Americanas, por volta do ano de 1851. É notório saber que depois da guerra civil de 1812 (forças inglesas queimaram Washigton DC em 1814), às construções das casas governamentais, ficaram mais resistentes à incêndio. Contudo foi devido à regulamentação de uso de materias como telha/ardósia e paredes de tijolos, diminui e muito a dependência do uso exclusivo da madeira. Desde então, o termo Firewall passou a ser empregado com maior frequência, principalmente para designar segurança em edificações modernas.

Resumo O uso acirrado da Net e sobretudo com uma enorme aderência de tecnologias mobile, houve avanços consideráveis que culminou no surgimento da rede formada por telefones inteligentes (LTE mobile networks), os smartphones. Ultrapassando em número, os computadores desktops e notebooks/laptops. Os dispositivos portáteis, como são chamados, possuem possibilidades reais antes inimagináveis. Tanto em termos de alto processamento, armazenamento, bem como Sensores de Geolocalização (GPS ), Redes WIFI, Câmera Fotográfica Digital de alta definição, Redes 4G e 5G, Integração com a Internet das Coisas (ex.: Destravar a fechadura inteligente da porta, regular a intensidade da luz da casa e controlar o voo do Drone, tudo controlado com um app instalado no seu celular ). Mas, infelizmente, nem tudo que reluz é ouro, nem tudo que brilha é prata. O lado sombrio e pavorante dos Cybercrimes

Digitais, coexistem no Universo dos Smartphones. É o local de onde florescem estelionatários, produzindo atividades maliciosas em larga escala, como por exemplo: roubo de senhas, fraude de dados bancários, roubo de certificados digitais, roubo de cartões de créditos, desvios de documentos, bem com sequestro de computadores corporativos e violação de correspondência eletrônica (emails e mensageiros em geral). O lado negro da força não acaba aqui e vai muito além, elas afetam à vida das pessoas. Elas estão mais suscetíveis aos crimes de assassinatos (provenientes de relacionamentos amorosos pela net), assédio e difamação (cyberbullying), exploração do sexo em geral: prostituição; pornografia; e zoofilia. Além do aumento significativo de abuso infantil (redes de pedofilia), interceptação de voz, espionagem industrial, corrupção e lavagem de dinheiro (Cryptocurrencies), venda de drogas e armas no mercado negro (Dark web), compartilhamento de conteúdo com apologia à violência racial e feminicídio, isso sem falar na onda das Fake News que inundam todas Redes Sociais (Whatsapp, Blogs, FacebooK, Twitter, Instagram, e etc), ou seja é a disseminação de notícias falsas. A verdade é que o uso massivo da Internet tem contribuído nos últimos anos, para o aumento substancial da intolerância, discriminação, hostilidade e ódio entre pessoas de todas as nacionalidades. Nesse mundo digital deformado é onde nos encontramos, local que se cultua todas as formas de polêmicas sejam de cunho políticos ou religiosos, trazem à tona a grande podridão, daqueles que escandalizam e agridem até o cenário Econômico Mundial. Isso sem falar nas demais atividades ilícitas, que incluem aí o elemento chamado de Hacker. Mas são os do tipo, maus elementos, de alta periculosidade, marginal capiroto e cramunhão (Exu do Inferno), abominação absoluta de Satanás. Calma irmãos e irmãs, respirem fundo, porque o Apocalipse mal começou. Se conseguirmos juntar toda essa desgraça, ao pouco conhecimento da maioria de nós, meros mortais e relés usuário regular de computador, afirmo à você que exige-se sim – cada vez mais à busca contínua e incessante de ferramentas ou técnicas de segurança especializada, de nível Perito Digital, voltado para análise extrema de incidentes. É preciso um sujeito forte, capaz, preparado, que crie condições para minimizar impactos e ao mesmo tempo, que tire melhor aprendizado da situação, ajudando a conter, barrar, cessar todos os maus elementos(Evil Hacker ) que nos cercam. A Segurança da Informação, acreditem ou não, é ainda o segmento da tecnologia que possui o dever de atuar em falhas de sistemas, garantindo à integridade, à confiabilidade e à disponibilidade dos dados. Tudo isso regido por normas e procedimentos bem específicos e sérios. Mas, porém, todavia, contudo, entretanto. . . na prática as coisas são bem diferentes, e raríssimos são, os bons analistas e administradores de sistemas, que se importam com o quesito “SEGURANÇA”. É pensando nisso, que apresentamos aqui um Guia Rápido e Prático de implementação do nosso perímetro de segurança da rede, o FIREWALL. – Sem complicações, tudo muito descomplicado e mastigadinho.

Palavras-chaves: Firewall Profissional; Iptables; Firewalld; Proteção Digital; Segurança.

Sumário 1 Breve história do Firewall 1.1 Pega o que for melhor . . . . . . . . . . . . . . . . . 1.2 Firewall p/ redes avançadas e p/ ambientes híbridos, 1.3 O universo comercial do Firewall . . . . . . . . . . . 1.4 O mundo opensource do Firewall . . . . . . . . . . .

. . . .

4 4 5 5 6

2 FIREWALLD 2.1 Porque usar o Firewalld? . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Comandos básicos do Firewalld . . . . . . . . . . . . . . . . . . . . . 2.2.1 Lista das zonas usadas no Firewalld com base em seu nível de 2.2.2 Permanência da Regra . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Backup simples das regras . . . . . . . . . . . . . . . . . . . . 2.2.4 Fazendo o restore . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Bloqueio usando Rich Rules . . . . . . . . . . . . . . . . . . . 2.2.6 Bloqueio usando Direct Rules . . . . . . . . . . . . . . . . . . 2.2.7 Bloqueio do facebook . . . . . . . . . . . . . . . . . . . . . . 2.2.8 Outros tipos de bloqueios . . . . . . . . . . . . . . . . . . . . 2.2.9 Como ativar o bloqueio de ICMP . . . . . . . . . . . . . . . . 2.2.10 Ping da Morte . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.11 Redirecionamento de Portas (Port Forwarding) . . . . . . . . 2.2.12 Mascaramento de IP (IP Address Masquerading) . . . . . . . 2.2.13 Firewalld também é capaz de lidar com endereços MAC. . . .

. . . . . . . . . . . . confiança: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

7 8 8 9 10 13 13 14 15 17 17 18 20 23 24 26

3 IPTABLES 3.1 Primeiras configurações do Iptables . . 3.2 Ativando os módulos . . . . . . . . . . 3.3 A filtragem dos pacotes . . . . . . . . 3.3.1 Extras → The black hole . . . 3.3.2 Uso Prático da Tabela Mangle

. . . . .

27 28 29 31 36 37

. . . . .

. . . . . . . . . . . físicos e em Nuvem . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

4 Conclusão

5 Considerações Finais

Breve história do Firewall

Um Firewall por definição é um dispositivo de uma rede de computadores que tem por objetivo aplicar uma política de segurança a um determinado ponto da rede. O Firewall pode ser do tipo filtros de pacotes, proxy de aplicações ou uma suíte completa que junta tudo isso e mais um IDS (software de detecção de intrusão para rede), incluindo até um antivírus integrado. Agora que você já sabe o que é, vamos então tentar entender um pouquinho da sua história, que por sinal tem sido bem documentado com certeza, mas um tanto difícil é identificar exatamente o ponto ou marco zero do obscuro surgimento do Firewall, isso se você levar em consideração o estágio de desenvolvimento/grau de maturidade do software. Segundo a maioria dos especialistas em segurança, é necessário rastrear as raízes do Firewall, voltando lá atrás, ao trabalho feito pela Digital Equipment Corporation no final da década de 1980, atribuído aos esforços de Jeff Mogul, Brian Reid e Paul Vixie o qual resultou no projeto chamado gatekeeper.dec.com e screend. O DEC SEAL, foi lançado em 1992, foi portanto o primeiro Firewall comercial e incluiu proxies desenvolvidos por Ranum. O DEC SEAL era interessante porque tinha um P/N – Part Number (número serial da peça), um manual e uma Corporação por trás disso. Durante o final dos anos 80 e início dos anos 90, William R. Cheswick e Steven M. Bellovin na AT&T também estavam trabalhando em sua própria versão de Firewall. Mas eles estavam construindo uma tecnologia diferente, para resolver um problema diferente. – “A AT&T não queria que nada saísse”, lembra Avolio, agora analista de segurança da informação do laboratório de física aplicada da Universidade Johns Hopkins. Ele diz que as equipes da DEC e da AT&T eventualmente colaboraram com algumas de suas pesquisas. Enquanto isso, o engenheiro israelense Nir Zuk, que ajudou a construir a tecnologia de Firewall da Empresa Check Point Software, não tem vergonha de receber crédito pelo primeiro Firewall comercial. – “Há apenas uma tecnologia de Firewall no mundo hoje, a que eu inventei. O trabalho de todos os outros eram puramente acadêmico e não sairam do papel”, diz Zuk, fundador e CTO da Palo Alto Networks, que vende aplicativos Firewalls. – “O Firewall da Check Point foi o primeiro produto utilizável, que realmente funcionou”, diz ele. – “Nós inventamos a tecnologia chamada de filtragem de pacotes através da tabela de estado ou tabela de conexão (statefull inspection)1 o qual se tornou a base tecnológica para todos os Firewalls modernos. Então, por que os outros especialistas em segurança também foram chamados de pais do Firewall? O sucesso tem muitos pais”, diz ele. Pensak, CTO da V.i. Labs, fala que haviam vários jogadores envolvidos na arena do Firewall, além dele é claro, que tiveram uma parcela importante na evolução do Firewall. – “Cada um de nós tinha um papel sério a desempenhar. Os caras que eu consideraria pais da tecnologia do Firewall são Marcus Ranum e Fred Avolio”, diz ele. Todas as marcas comerciais e marcas registradas que foi exposto nesse artigo, são de propriedade intelectual de seus respectivos donos: – ©Check Point Software Technologies Ltd. (Nasdaq: CHKP); – ©AT&T Labs Research; – ©V.i. Laboratories, Inc; e ©Palo Alto Networks. Todos os direitos são reservados.

1.1

Pega o que for melhor

A escolha de um Firewall deve sempre levar em consideração qual o fabricante desta solução. Procure empresas confiáveis, renomadas em soluções de segurança que irão garantir a atualização dos serviços e suporte adequado sempre que necessário. 1 filtragens sem e com estado (stateless e stateful) formaram a base para a construção e evolução de soluções de Firewall usadas hoje. No entanto foi os Firewalls stateful que foram concebidos posteriormente, a fim de solucionar aspectos de segurança que surgiram com a primeira geração, como por exemplo o caso de forjar (técnica de spoofing) informações de conexão. A importância fundamental foi de orientar a filtragem para conexão e permitir que o mecanismo de filtragem passasse a conhecer as conexões. Com base nisso, legitimaria um pacote ou não. Esse recurso auxiliar ficou conhecido como tabela de conexões ou tabela de estados. Com a tabela de estados, todo início de conexão é devidamente registrado (um novo estado é criado). Quando o pacote retorna, antes de iniciar o processo de avaliação das regras de acesso, o Firewall stateful verifica a tabela de estados, valida se há alguma conexão associada e, caso afirmativo, aceita a conexão, sem processar as regras. Do contrário, descarta o pacote. Em um Firewall stateful há uma economia considerável de recursos computacionais, uma vez que há um esforço inicial para a criação de novas conexões, que é recompensado até o encerramento pela não necessidade de processar as regras de acesso. É muito comum encontrar esse mecanismo de filtragem nas mais modernas soluções, que continua sendo um elemento fundamental na estratégia de defesa em profundidade.

O fornecedor também deve ser uma Empresa capacitada e experiente em projetos de segurança, que conte com o apoio e suporte do fabricante, garantindo assim o correto dimensionamento da solução e a configuração adequada dos serviços do seu Firewall. A escolha do Firewall ideal é uma questão que passa diretamente pelo porte, pelo orçamento, pelas prioridades, perspectivas e necessidades da organização. Sem a consideração desses fatores às chances de se enganar e fazer a escolha errada. . . são grandes, o que comprometeria todo o investimento. O ponto que quero chegar e que todo administrador de tecnologia já está careca de saber. . . que é fundamental analisar a demanda de acordo com o número de computadores em rede, determinar os tipos de dados que devem ser protegidos, definir o que se pode esperar com a implementação, saber o quanto ela tem para investir e o porquê (os motivos) da necessidade, sempre alinhado com as metas e objetivos corporativos ou organizacionais.

1.2

Firewall p/ redes avançadas e p/ ambientes híbridos, físicos e em Nuvem

Veja abaixo às principais diferenças. 1°→ Firewall para redes avançadas: para redes mais amplas e avançadas – ou seja, que possuem um número relativamente grande de computadores e requerem atenção redobrada para evitar ataques feitos por cibercriminosos experientes, – uma solução ainda mais aprimorada se faz necessária. Em alguns casos, o próprio UTM (Unified Threat Management – Gestão Unificada de Ameaças voltado para ambientes de TI pequeno, menos robusto) pode se encaixar como alternativa para as médias empresas – como já dito, dependerá sempre das necessidades de cada uma. Porém, quando a criticidade dos dados é alta ou o nível de tolerância à indisponibilidade é baixo, é possível que os recursos presentes no UTM sejam insuficientes. A carência de uma tecnologia que suprisse as deficiências do UTM foi justamente o que deu origem a uma solução chamada Next-Generation Firewall (NGFW), a mais indicada para esse tipo de demanda. O NGFW funciona de modo similar ao UTM, mas oferece níveis de proteção superiores, representados pela inspeção mais profunda e detalhada, capazes de prevenir a rede, de invasões e otimizar o seu desempenho. 2°→ Firewall para ambientes híbridos, físicos e em nuvem: ambientes com infraestrutura física, em nuvem ou até mesmo híbridos, são realidades extremamente desafiadoras para a Segurança da Informação – afinal, eles estão presentes nas grandes corporações. Isso significa que a rede é potencialmente visada pelos cibercriminosos, além de possuir tendências a crescer rapidamente. Geralmente, as empresas adotam a computação em nuvem (cloud computing) levando em consideração a escalabilidade da tecnologia, ou seja, o serviço se manterá capaz de acompanhar a crescente demanda. O Firewall implementado no próprio ambiente não chega a ter tamanha flexibilidade e extensibilidade. Sempre chegará o momento em que ele se tornará obsoleto ou simplesmente ineficaz – ou seja, precisará ser substituído por uma solução mais robusta (que também terá a sua vida útil limitada a alguns anos). Portanto, para esse tipo de ambiente, é recomendado escolher uma solução de Firewall as a Service (FaaS). O serviço é uma espécie de terceirização, ou seja, toda a responsabilidade que envolve o fornecimento de segurança, manutenção, configuração e upgrade é delegada à empresa contratada. Isso garante que a capacidade e os recursos do Firewall permanecerão inesgotáveis, ao mesmo tempo em que a empresa é poupada de investir periodicamente na atualização dos seus ativos de segurança.

1.3

O universo comercial do Firewall

Há algumas marcas importantes, como por exemplo: – Cisco; – Juniper; – Mikrotik; – e Endian. Eles são apenas umas dentre muitos outros no universo da segurança. Segue abaixo à lista completa, o qual considero o top solution em se tratando de Firewall comercial: 5

Figura 2: Firewall NGFW. – Firewalls de próxima geração (Rack-Mountable Enterprise). 1. 2 Check Point VSX;

2. 2 Fortinet FortiGate;

3. 2 WatchGuard XTM; 4. 2 Cisco ASA;

5. 2 Sophos UTM; 6. 2 Juniper SRX;

7. 2 SonicWall NSA;

8. 2 Untangle NG Firewall.

1.4

O mundo opensource do Firewall

Figura 3: Firewall Gratuito. – Sem custo de software e licenciamento. Todo dispositivo router ou dispositivo Firewall, segue uma arquitetura muito semelhante à de um PC (personal computer/computador pessoal). Estes equipamentos, ativos de uma rede de dados, executam um conjunto diverso de funcionalidades baseadas em software (e também em hardware). Para quem necessita de um router ou Firewall, pode simplesmente usar um PC velho com o pfSense. O pfSense é uma solução leve, gratuita e opensource, baseada no sistema operacional FreeBSD, que permite transformar qualquer máquina (computador/ordenador) num super e potente router/Firewall. Esta plataforma é bastante popular e adaptável a qualquer cenário de rede de dados (ex. rede doméstica, rede empresarial, 6

rede universitária, soho e etc.). O pfSense é, na minha humilde opinião de Zé Ruela, um do mais legais Firewall distro2 que eu já vi, fazendo muito sucesso rodando nas bordas de redes, pelo Brasil afora. É claro que por questões econômicas, todo Firewall gratuito como o pfSense, realmente atormentam seus concorrentes comerciais no cenário nacional atual. Há também outros similares, tão bons ou melhores que o pfSense, e que muitas vêzes possuem um stateful Firewall construído sobre o framework Linux NetFilter ao invés do PF BSD (Packet Filter BSD)3 . Para melhor exemplificação, segue abaixo à lista de Firewall distro: 1. 2 pfSense; 2. 2 IPCop;

3. 2 ClearOS;

4. 2 OPNSense;

5. 2 Smoothwall; 6. 2 UFW;

7. 2 IPFire;

8. 2 ZeroShell;

9. 2 M0n0wall;

10. 2 WIPFW/IPFW.4

FIREWALLD

Até o prezado momento, falou, falou e falou. . . mas não disse nada! – Que raios de Firewall pretende mostrar aqui? Veja bem, há outras soluções open source. . . é possível instalar e configurar um Firewall de perímetro sem custo de software e licenciamento, sendo somente necessário possuir um hardware. Um exemplo é o PFSense como já mencionado anteriormente, o mesmo é baseado no sistema BSD, ele é um Firewall muito interessante, com recursos de controle de navegação, configuração de regras de filtragem, VPN, e entre outros que, se configurados corretamente, irão aumentar à segurança da informação e controle dos dados trafegados entre sua Empresa e o ambiente externo. Acalme seu jaburu, porque vamos voltar à dignificar o GNU/Linux e sobretudo o Firewalld, que é o que interessa! – Só dei umas rápidas pinceladas no que existe por aí em matéria de assunto sobre Firewalls. . . – Eu pessoalmente prefiro o Linux, por ser mais acadêmico, prima para o saber, ganho de conhecimento. Claro, também por uma questão de gosto pessoal mesmo. . . Mano, sei lá, me sinto de certa forma, bem preparado e ou capacitado, em usá-lo como minha única solução de Firewall. Porque consigo adaptá-lo para minhas necessidades, extraindo o melhor para o meu ambiente de produção/simulação. Não gosto de usar Firewall distro, pois para mim elas são como um atalho para soluções mágicas instantâneas, é daquelas soluções instântaneas do tipo que já vêm pronta para servir (miojo lámen). . . Não que ela seja ruim. . . pois há pontos positivos, como quebra galho, bom para estancar o sangramento de forma rápida, quando não se tem Tempo e nem Orçamento para se fazer absolutamente NADA. A dica que dou à você, meu caro leitor: – “Jamais se sinta encurralado, quem gosta de pressão é garrafa de refrigerante, nem engane a si mesmo, sem mágoas e sem angústias, diga não à procrastinação, larga essa fimose mental de RuimWindowsvski aguda, pela raiz! – Comece a usar o Linux e Seja Feliz!” 2 é um projeto que visa criar um pacote de software Firewall, que quando utilizado juntamente com um PC forneça todas as características de um Firewall embutido comercial. 3 até onde sei, o BSD tem 2 aplicativos de Firewall: IPFW – Internet Protocol Firewall e o PF – packet filter. Existem grandes diferenças entre o IPFW e o PF. O IPFW é baseado em lista (ACLs), enquanto o PF é mais orientado à objetos. A configuração do PF é dividida em várias partes, mas o IPFW geralmente usa um shell script com regras processadas em ordem. Entretanto, ambos suportam processamento de conexão statefull e stateless. 4 Firewall opensource (projeto de 2011) que roda em sistemas legado do Windows devido à uma portabilidade do Firewall IPFW do FreeBSD. Portanto o WIPFW é uma versão operável do MS Windows do IPFW para o FreeBSD OS. Suporta as antigas plataformas: Windows Server 2000, 2008, 2008 R2, 98 SE, Vista e até Windows 7. Você pode usar a mesma funcionalidade e configurá-la como só você trabalha com IPFW do FreeBSD (http://wipfw.sourceforge.net/).

Figura 4: Firewalld. – Substitui a interface do antigo script iptables.

2.1

Porque usar o Firewalld?

O Firewalld é o substituto do Iptables nas versões anteriores dos sistemas operacionais Linux. Ele oferece um Firewall gerenciado dinamicamente que faz uso do conceito de zona, cada zona define o nível de confiança de cada conexão ou interface de rede. O Firewalld suporta configurações de Firewall IPv4 e IPv6 separadamente. As opções de configurações são separadas como o runtime e configurações permanentes. No antigo Iptables, quando estava em execução, era necessário um reinício completo do Firewall para todas as alterações feitas, portanto, todos os módulos do kernel que estavam sendo usados tinham que ser descarregados e os módulos do kernel necessários para a nova configuração, carregado. Exceto aqueles que preferem compilar o próprio Kernel, customizando seus drivers. Procuram utilizar menos módulos possíveis, deixando o sistema também mais monolítico. Por outro lado, o daemon do Firewalld gerencia o Firewall dinâmicamente ou seja, isso quer dizer que ele pode aplicar as alterações da modificações, sem ter que recarregar o serviço do Firewall inteiro. O Firewalld garante que o daemon e os módulos do kernel estejam sincronizados enquanto as alterações são feitas. Nós estamos tão acostumados com o bom e velho Iptables, pois é. . . muitos quero dizer os Tiozinhos de nível Sênior. . . esses dificilmente deixariam de usá-lo. Mas chegou a hora da mudança, e definitivamente abir a cabeça. Estou falando de aprender a usar de uma vez por todas, o novo Firewalld, o sucessor do ancião Iptables. Aprender não é bom, é ótimo! Entretanto isso não quer dizer que pode sair trocando seu iptables pelo Firewalld no seu trampo. Não faça isso, não seja radical. . . cuidado com as medidas drásticas! Não vista às calças sobre a cueca, você não é o SUPERMAN! – Entenda que tudo dependerá do tipo de cenário ou projeto que for adotado. Nem sempre é a melhor solução, embora o Firewalld tenha uma melhor otimização e ganho de desempenho em determinadas tarefas, mas ainda assim, o mesmo pode não ser a melhor escolha para o seu ambiente de produção. Não queremos causar nenhuma revolução, pelo contrário, a meta é demonstrar uma alternativa ao Iptables e explorar suas ferramentas para auxiliar no estudo do intrépido iniciante, para que este último possa trilhar seu próprio caminho, com a assertividade que ele merece.

2.2

Comandos básicos do Firewalld

Quem estiver rodando o Gnome, pode utilizar a ferramenta gráfica Firewall-config, ao invés do Firewallcmd: $ sudo Firewall-config

Verificar a versão corrente do Firewalld e confirmar se o mesmo está rodando: # rpm -qf $( which Firewall-cmd ) Firewalld-0.5.2-2.fc28.noarch # systemctl status Firewalld | grep inactive && echo "Firewalld not running!" || echo "firewald its runnig!"

firewald its runnig!

ou alternativamente: # Firewall-cmd --state running

Recarregue o Firewall sem perder as informações do estado de conexões: $ sudo Firewall-cmd --reload

Figura 5: Firewalld stack. – Firewalld Behind Scenes. Recarregue o Firewall e perde às informações do estado das conexões. Essa opção só deve ser usada em caso de problemas graves de Firewall, por exemplo, se houver problemas de informações de estado onde nenhuma conexão pode ser estabelecida, mesmo que as regras de Firewall estejam corretas. $ sudo Firewall-cmd --complete-reload

2.2.1

Lista das zonas usadas no Firewalld com base em seu nível de confiança:

1. Drop ,→ o nível mais baixo de confiança. Todas as conexões de entrada são descartadas sem resposta e somente conexões de saída são possíveis. 2. Block ,→ semelhante ao acima, mas em vez de simplesmente descartar conexões, as solicitações recebidas são rejeitadas com uma mensagem icmp-host-icmp-host-prohibited (proibido) ou icmp6adm-icmp-host-prohibited (proibido). 3. Public ,→ representa redes públicas não confiáveis. Você não confia em outros computadores, mas pode permitir conexões de entrada selecionadas, caso à caso. 4. External ,→ redes externas no caso de você estar usando o Firewall como seu gateway. Ele é configurado para o mascaramento de NAT, para que sua rede interna permaneça privada, mas também acessível. 5. Dmz ,→ usado para computadores localizados em uma DMZ ou Zona Desmilitarizada (onde há computadores isolados que não terão acesso ao resto de sua rede). Apenas certas conexões de entrada são permitidas. 9

6. Work ,→ usado para máquinas de trabalho (escritório). Confie na maioria dos computadores da rede. Mais apenas alguns serviços podem ser permitidos. 7. Home ,→ um ambiente doméstico. Isso geralmente significa que você confia na maioria dos outros computadores e que mais alguns serviços serão aceitos. No Linux Fedora eu uso por padrão a zona FedoraWorkstation que é similar à zona home. 8. Internal ,→ usado para a parte interna de um gateway. Os computadores são bastante confiáveis e alguns serviços adicionais estão disponíveis. 9. Trusted ,→ confie em todas as máquinas da rede. A mais aberta das opções disponíveis e deve ser usada com moderação. Eu costumo usar essa zona apenas para adicionar a interface de rede virbr0 da minha VM (máquina virtual) guest. Listar a configuração atual da zona padrão no Firewalld: $ Firewall-cmd --list-all FedoraWorkstation (active) target: default icmp-block-inversion: no interfaces: wlp2s0 sources: services: dhcpv6-client ssh samba-client mdns samba openvpn ntp imap http https ftp docker-registry dns nfs imaps ipp ipp-client pptp dhcp dhcpv6 shoutcast ports: 1025-65535/udp 1025-65535/tcp 15567/udp 22000/udp 1900/udp 8895/tcp 54807/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

2.2.2

Permanência da Regra

No Firewalld, as regras podem ser designadas como permanentes ou imediatas. Portanto, se uma regra for adicionada ou modificada, por padrão, o comportamento do Firewall atualmente em execução será modificado. Mas na próxima inicialização, as regras antigas serão todas revertidas ou seja, esse tipo de comportamento, serve para você testar bastante as novas regras, antes de querer alterar de forma definitiva e permanente no seu ambiente de produção. + OBS : – Você pode ativar um serviço para uma zona usando o parâmetro: --add-service= .A operação terá como alvo a zona padrão ou qualquer que seja a zona especificada pelo parâmetro: --zone= .Por padrão, isso só ajusta a sessão atual do Firewall. Você pode ajustar a configuração permanente do Firewall incluindo o sinalizador ou a flag: --permanent ou aplicar depois, através do comando: Firewall-cmd --runtime-to-permanent Mostra as zonas e serviços disponíveis, em seguida lista a zona padrão: $ Firewall-cmd --get-zones FedoraServer FedoraWorkstation block dmz drop external home internal public trusted work $ Firewall-cmd --get-active-zones FedoraWorkstation interfaces: wlp2s0 $ Firewall-cmd --get-services RH-Satellite-6 Shoutcast amanda-client amanda-k5-client bacula bacula-client bgp bitcoin bitcoin-rpc

bitcoin-testnet bitcoin-testnet-rpc ceph ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client dns docker-registry docker-swarm dropbox-lansync elasticsearch freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master git high-availability http https imap imaps ipp ipp-client ipsec irc ircs iscsi-target jenkins kadmin kerberos kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls managesieve mdns minidlna mongodb mosh mountd ms-wbt mssql murmur mysql nfs nfs3 nmea-0183 nrpe ntp openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql pptp privoxy proxy-dhcp ptp pulseaudio puppetmaster quassel radius redis rpc-bind rsh rsyncd samba samba-client sane sip sips smtp smtp-submission smtps snmp snmptrap spideroak-lansync squid ssh syncthing syncthing-gui synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client upnp-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local xmpp-server zabbix-agent zabbix-server $ Firewall-cmd --zone=FedoraWorkstation --list-services dhcpv6-client ssh samba-client mdns samba openvpn ntp imap http https ftp docker-registry dns nfs imaps ipp ipp-client pptp dhcp dhcpv6 shoutcast

Comando para ver e configurar a zona padrรฃo: $ Firewall-cmd --get-default-zone Public $ sudo Firewall-cmd --permanent --set-default-zone=FedoraWorkstation FedoraWorkstation $ sudo Firewall-cmd --reload $ Firewall-cmd --zone=FedoraWorkstation --list-all

Adicionar e remover uma porta para sua zona: $ sudo Firewall-cmd --permanent --zone=public --add-port=5000/tcp success $ sudo Firewall-cmd --reload $ sudo Firewall-cmd --zone=public --list-port 5000/tcp $ sudo Firewall-cmd --permanent --zone=public --remove-port=5000/tcp success $ sudo Firewall-cmd --reload $ sudo Firewall-cmd --zone=public --list-port

Adicionar ou remover um serviรงo para sua zona: $ sudo Firewall-cmd --permanent --zone=FedoraWorkstation --add-service=telnet success $ sudo Firewall-cmd --reload $ Firewall-cmd --list-services dhcpv6-client ssh samba-client mdns samba openvpn ntp imap http https ftp docker-registry dns nfs imaps ipp ipp-client pptp dhcp dhcpv6 shoutcast telnet $ sudo Firewall-cmd --permanent --zone=FedoraWorkstation --remove-service=telnet success $ sudo Firewall-cmd --reload

$ Firewall-cmd --list-services dhcpv6-client ssh samba-client mdns samba openvpn ntp imap http https ftp docker-registry dns nfs imaps ipp ipp-client pptp dhcp dhcpv6 shoutcast

Para adicionar múltiplos serviços: $ sudo Firewall-cmd --zone=internal --add-service={http,https,dns} $ sudo Firewall-cmd --list-services

Por exemplo, no caso de usar um serviço “HAProxy”, veja que aqui não tem nenhum serviço parecido com ele, registrado ou associado no Firewall. Ou seja nós temos que criar um novo serviço: $ sudo Firewall-cmd --permanent --new-service=haproxy

Vá para /etc/Firewalld/services/haproxy.xml e edite as linhas à seguir: $ sudo vim /etc/Firewalld/services/haproxy.xml <?xml version="1.0" encoding="utf-8"?> <service> <short>HAProxy</short> <description>HAProxy load-balancer</description> <port protocol="tcp" port="80"/> </service>

Ative o serviço no Firewall e dê um reload para firmar às configurações: $ sudo Firewall-cmd --permanent --add-service=haproxy $ sudo Firewall-cmd --reload

Você pode obter mais detalhes sobre cada um desses serviços, observando o arquivo .xml associado dentro do diretório: /usr/lib/Firewalld/services. Segue abaixo o serviço SSH em /usr/lib/Firewalld/services/ssh.xml: <?xml version="1.0" encoding="utf-8"?> <service> <short>SSH</short> <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a Firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description> <port protocol="tcp" port="22"/> </service>

Alterar a interface de rede da zona: $ sudo Firewall-cmd --permanent --zone=FedoraWorkstation --change-interface=eth0 $ sudo Firewall-cmd --reload $ Firewall-cmd --get-active-zones FedoraWorkstation interfaces: eth0

É possível, especialmente em sistemas remotos, que uma configuração incorreta afete o usuário, impedindo seu acesso ao servidor. Para evitar que tais situações aconteça, use a opção --timeout. Após um período de tempo especificado, qualquer alteração é revertida para seu estado anterior: $ sudo Firewall-cmd --add-service=ssh --timeout 15m

Figura 6: Backup do Firewalld. – Você salvou as regras do Firewall? 2.2.3

Backup simples das regras

$ sudo systemctl stop Firewalld $ sudo ls -l /etc/Firewalld/ $ sudo cp -Rv /etc/Firewalld/ /misc/backup/Firewalld/ direct.xml direct.xml.old Firewalld.conf Firewalld-server.conf Firewalld-standard.conf Firewalld-workstation.conf helpers icmptypes ipsets lockdown-whitelist.xml lockdown-whitelist.xml.old services zones sudo systemctl start Firewalld

2.2.4

Fazendo o restore

sudo systemctl stop Firewalld sudo cp -v /misc/backup/Firewalld/* /etc/Firewalld/ sudo chown root. -R /etc/Firewalld/ sudo systemctl start Firewalld && sudo Firewall-cmd --reload

Outra forma de salvar essas informações, é criando um hard link à partir da pasta /etc/Firewalld/. Caso exclua a pasta original sem querer, vai ter uma cópia em outro lugar. Por compartilhar o mesmo inode, os chamados hard links possuem diferenças bastante claras em relação aos links do tipo simbólico: 99K só podem referenciar arquivos, e nunca diretórios; 99K não podem referenciar arquivos em outros volumes ou partições; 99K hard links continuam funcionando mesmo que o arquivo original tenha sido apagado; 99K hard links fazem referência ao inode do arquivo original. Ao contrário dos softlinks, que referenciam nomes de arquivos e diretórios; 13

99K hard links referenciam uma posição física da partição. O comando: ln <origem> + <link> A origem (source) é o arquivo original que já existe. Já o link é o arquivo que desejamos criar (hard link).

No exemplo abaixo, vou criar o link com nome de arquivo diferente um do outro, só para fins didáticos: sudo mkdir -p /misc/backup/ sudo ln /etc/Firewalld/Firewalld-workstation.conf /misc/backup/Firewalld-workstation.conf.bak

Logo abaixo, perceba o número 2 ao lado da palavra root, significa que há hard link nesse arquivo e que foi criado com 2 inodes idênticos. Esse número aumenta de acordo com a quantidade de links criado para o mesmo arquivo. $ ls -l /misc/backup/Firewalld-workstation.conf.bak -rw-r--r-- 2 root root 2020 Mar 22 13:00 /misc/backup/Firewalld-workstation.conf.bak Os arquivos possuem nomes diferentes mas compartilham o mesmo inode 1967430: $ sudo ls -i /etc/Firewalld/Firewalld-workstation.conf 1967430 /etc/Firewalld/Firewalld-workstation.conf $ sudo ls -i /misc/backup/Firewalld-workstation.conf.bak 1967430 /misc/backup/Firewalld-workstation.conf.bak Vamos achar os arquivos que possuem hard links: $ sudo find / -xdev -inum 1967430 /misc/backup/Firewalld-workstation.conf.bak /etc/Firewalld/Firewalld-workstation.conf

A outra forma de backup muito usando, é através da ferramenta rsync, ele é rápido, versátil e muito fácil de usar. O comando abaixo faz uma cópia incremental: $ sudo rsync --progress -av /etc/Firewalld/ /misc/backup/Firewalld/

2.2.5

Bloqueio usando Rich Rules

Bloqueia por exemplo determinadas estações/máquinas, de se conectarem no server ip (192.168.1.18), impendido o acesso ao serviço de web. No meu caso está rodando o lighttpd nesse servidor. No exemplo abaixo, criamos uma lista chamada de blacklist e em seguida adicionamos nela, os respectivos ips das estações (192.168.1.7 e 192.168.1.8.) $ $ $ $ $ $ $

sudo sudo sudo sudo sudo sudo sudo

Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd

--permanent --new-ipset=blacklist --type=hash:ip --reload --ipset=blacklist --add-entry=192.168.1.7 --permanent --ipset=blacklist --add-entry=162.168.1.8 --permanent --add-rich-rule='rule source ipset=blacklist drop' --permanent --reload --list-all

$ sudo Firewall-cmd --get-ipsets $ sudo Firewall-cmd --info-ipset=blacklist blacklist type: hash:ip options: entries: 192.168.1.7 192.168.1.8

Se você tiver que adicionar muitos IPs de uma vez, é bem mais prático fazer assim: sudo Firewall-cmd --ipset=blacklist --add-entries-from-file="lista_hosts.txt" --permanent

Ou pode também usar a lista XML de armazenamneto localizada em: /etc/Firewalld/ipsets/blacklist.xml ou em: /usr/lib/Firewalld/ipsets/blacklist.xml. Para funcionar, os arquivos XMLs, devem respeitar o seguinte formato: <?xml version="1.0" encoding="utf-8"?> <blacklist type="hash:ip"> <short>My Ipset</short> <description>description</description> <entry>192.168.1.7</entry> <entry>192.168.1.8</entry> </blacklist>

Caso queira bloquear o acesso à todos da sua rede, para tanto adicione corretamente o seu endereço ip: $ sudo Firewall-cmd --ipset=blacklist --add-entry=192.168.1.0/24 --permanent $ sudo Firewall-cmd --reload $ sudo Firewall-cmd --info-ipset=blacklist

Para remover todas as regras, inclusive a lista: $ $ $ $ $ $

sudo sudo sudo sudo sudo sudo

2.2.6

Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd

--ipset=blacklist --remove-entry=192.168.1.7 --permanent --ipset=blacklist --remove-entry=192.168.1.8 --permanent --remove-rich-rule='rule source ipset=blacklist drop' --permanent --permanent --delete-ipset=blacklist --reload --list-all

Bloqueio usando Direct Rules

Nesse exemplo vou bloquear a minha própria máquina/notebook de acessar o destino ip 167.114.251.212, ou seja vou cortar drásticamente o acesso ao stream de rádio online: $ sudo Firewall-cmd --get-default-zone $ sudo Firewall-cmd --permanent --zone=FedoraWorkstation --list-all $ sudo Firewall-cmd --direct --add-rule ipv4 filter \ OUTPUT_direct 1000 -j RETURN $ sudo Firewall-cmd --direct --add-rule ipv4 filter \ OUTPUT_direct 0 -d 167.114.251.212 -j DROP $ sudo Firewall-cmd --direct --get-rules ipv4 filter OUTPUT_direct $ netstat -vatun | grep "167.114.251.212"

ou use o ss - another utility to investigate sockets: $ ss -lnp4 | grep "167.114.251.212"

No exemplo acima, perceba que não é preciso dar reload! (sudo Firewall-cmd –reload). Para remover as regra de bloqueio à rádio online: $ sudo Firewall-cmd --direct --remove-rule ipv4 filter \ OUTPUT_direct 1000 -j RETURN $ sudo Firewall-cmd --direct --remove-rule ipv4 filter \ OUTPUT_direct 0 -d 167.114.251.212 -j DROP $ netstat -vatun | grep "167.114.251.212" $ ss -lnp4 | grep "167.114.251.212"

Veja que na regra acima, foi bloqueado o destino, mas tmabém há como bloquear pela origem. No exemplo abaixo, vamos bloquear acesso das máquinas 192.0.2.10 e 192.0.2.11 de acessarem nosso servidor. Primeiro, vamos criar uma chain personalizada chamada “testchain”, especialmente para incluir as máquinas bloqueadas pela sua origem: $ $ $ $ $ $

sudo sudo sudo sudo sudo sudo

Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd

--direct --add-chain ipv4 filter testchain --direct --add-rule ipv4 filter testchain 1000 -j RETURN --direct --add-rule ipv4 filter testchain 0 -s 192.0.2.10 -j DROP --direct --add-rule ipv4 filter testchain 0 -s 192.0.2.11 -j DROP --permanent --zone=FedoraWorkstation --list-all --direct --get-rules ipv4 filter testchain

-j RETURN -s 192.0.2.10 -j DROP -s 192.0.2.11 -j DROP

Perceba que a ordem de prioridade está errada! – Mas é apenas um bug do Firewalld, portanto desencana aí. . . e use outra ferramenta: sudo iptables -S testchain -N -A -A -A

testchain testchain -s 192.0.2.10/32 -j DROP testchain -s 192.0.2.11/32 -j DROP testchain -j RETURN

$ sudo iptables -vL testchain Chain testchain (0 references) pkts bytes target prot opt in 0 0 DROP all -- any 0 0 DROP all -- any 0 0 RETURN all -- any

out any any any

source 192.0.2.10 192.0.2.11 anywhere

destination anywhere anywhere anywhere

Falae, aí sim heim? Agora temos uma linda lista (na ordem certa), com o Target RETURN por último, sinalizando o fim ou encerramento do processamento dos pacotes da minha chain. Se quiser remover as regras e também a sua chain personalizada, proceda dessa forma: $ $ $ $ $

sudo sudo sudo sudo sudo

Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd

--direct --remove-rule ipv4 filter testchain 1000 -j RETURN --direct --remove-rule ipv4 filter testchain 0 -s 192.0.2.10 -j DROP --direct --remove-rule ipv4 filter testchain 0 -s 192.0.2.11 -j DROP --direct --remove-chain ipv4 filter testchain --permanent --zone=FedoraWorkstation --list-all

2.2.7

Bloqueio do facebook

O uso de redes sociais no ambiente de trabalho, há quem seja à favor, outros contra, fulano estipula um horário fora do expediente, beltrano usa como ferramenta ou canal de divulgação, ciclano mais egocêntrico, usa para exaltar a si mesmo, enfim. . . é uma faca de dois legumes, como diria lá na roça. . . Mas quem senta na graxa é sempre o Cara da TI, e se sobrou para você também, então nós temos a solução para cessar os murros em ponta de faca. Vamos ao bloqueio do facebook. O intervalo (range) do bloco de IP deles sempre mudam ou acrescentam novos, logo deve-se verificar sempre com o whois. $ cat <<EOF> bloqueia.facebook.sh

#!/bin/bash # # get facebook IP range from whois. IP=$(whois -h whois.radb.net '!gAS32934' | grep /) for ip in $IP do Firewall-cmd --direct --add-rule ipv4 filter \ OUTPUT_direct 0 -d $ip -j DROP &> /dev/null done unset ip; unset IP; echo"" echo"" Firewall-cmd --direct --get-all-rules echo"" echo "facebook bloqueado com sucesso!" Firewall-cmd --reload EOF

$ sudo chmod a+x bloqueia.facebook.sh $ sudo ./bloqueia.facebook.sh

Para desfazer o bloqueio execute nessa ordem: $ $ $ $ $

sudo sudo sudo sudo sudo

2.2.8

Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd

--permanent --direct --remove-chain ipv4 filter OUTPUT_direct --permanent --direct --remove-rule ipv4 filter OUTPUT_direct 0 -j DROP --direct --remove-rule ipv4 filter OUTPUT_direct 0 * --reload --complete-reload

Outros tipos de bloqueios

Figura 7: botão do pânico. – panic mode no Firewalld. Há situações na vida que exigem medidas extremas, calma. . . ainda não desconecte o seu cabo de rede e nem jogue seu hd no lago, porque agora, em caso de emergência, você pode ativar o modo pânico (panic 17

mode) no Firewalld e bloquear imediatamente todo o tráfego de rede. Ativar o panic mode: $ sudo Firewall-cmd --panic-on

Desativar o panic mode: $ sudo Firewall-cmd --panic-off

Consultar o panic mode: $ Firewall-cmd --query-panic $ Firewall-cmd --query-panic && echo "On" || echo "Off"

2.2.9

Como ativar o bloqueio de ICMP

Pode-se habilitar o bloqueio de uma mensagem ICMP (Internet Control Message Protocol). As mensagens ICMP são solicitações de informações (echo-request) ou criadas como resposta à solicitações de informações (echo-reply) ou em condições de erro. Um dos principais propósitos das mensagens informativas ICMP é permitir testes e diagnósticos (teste de conexão), para ajudar a identificar e corrigir problemas em um conjunto de redes. O teste mais básico que pode ser realizado entre dois dispositivos é simplesmente verificar se eles são capazes de enviar datagramas uns aos outros. A maneira usual de fazer isso é fazer com que um dispositivo envie uma mensagem de teste para um segundo dispositivo (echo request), que recebe a mensagem e responde de volta (echo reply), para informar ao primeiro dispositivo que recebeu a mensagem. Estou falando da ferramenta, que certamente faz parte da vida cotidiana de todo profissional de redes: – “O bom e velho Ping!” Apesar de parecer simples, o ping vai muito além de simplesmente confirmar se há comunicação com um host remoto qualquer – ele também traz alguns valores importantes para determinar o desempenho de uma rede. Para cada linha de resposta echo-reply do ICMP (protocolo utilizado por trás do ping) ele traz o valor do atraso fim-a-fim na comunicação (latência), conforme pode ser observado abaixo: # ping -c 3 104.104.146.221 PING 104.104.146.221 (104.104.146.221) 56(84) bytes of data. 64 bytes from 104.104.146.221: icmp_seq=1 ttl=52 time=12.4 ms 64 bytes from 104.104.146.221: icmp_seq=2 ttl=52 time=12.1 ms 64 bytes from 104.104.146.221: icmp_seq=3 ttl=52 time=11.7 ms --- 104.104.146.221 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 11.721/12.109/12.423/0.291 ms Onde 1ms equivale à ≈ 0,001s. Também ao final da sequência de respostas ele traz um resumo estatístico com os valores mais baixo, médio e alto da latência nos parâmetros rtt min/avg/max. Ele ainda mostra qual foi a porcentagem de perda de pacotes que, normalmente, não deve exceder 2%. Valores de perda de pacotes acima de 5% são indicativos de que está havendo algum problema na rede, que pode ser desde o cabeamento até a aplicação em si! É importante destacar que no Linux ele calcula o jitter (parâmetro denominado mdev no ping). 18

Tabela 1: Valor padrão TTL para Sistemas Operacionais. OS (Operation System) UNIX Linux Apple Windows

TTL (Time-to-Live) 255 64 48 128

Identificar o Sistema Operacional utilizando o comando ping. Cada Sistema Operacional trabalha com um TTL padrão e desta forma podemos identificar o tipo de sistema. Representamos na tabela abaixo: Com estes números já podemos determinar o Sistema Operacional. No caso do exemplo abaixo o TTL = 64, nos diz que o sistema utilizado é Linux: # ping -c 3 192.168.1.18 PING 192.168.1.18 (192.168.1.18) 56(84) bytes 64 bytes from 192.168.1.18: icmp_seq=1 ttl=64 64 bytes from 192.168.1.18: icmp_seq=2 ttl=64 64 bytes from 192.168.1.18: icmp_seq=3 ttl=64

of data. time=0.050 ms time=0.131 ms time=0.097 ms

Já no exemplo abaixo o TTL = 48, nos diz que o sistema utilizado é um servidor Apple: # ping -c 3 167.114.251.212 PING 167.114.251.212 (167.114.251.212) 56(84) bytes of data. 64 bytes from 167.114.251.212: icmp_seq=1 ttl=48 time=263 ms 64 bytes from 167.114.251.212: icmp_seq=2 ttl=48 time=231 ms 64 bytes from 167.114.251.212: icmp_seq=3 ttl=48 time=240 ms Logo à seguir, pode-se dizer que o sistema usado é um genuíno Windows Server 2012. Perceba que os roteadores estão programados para decrementar o TTL a cada pacote que passa por ele. E nesse caso, a máquina pingada obtêve o valor TTL = 114, isso significa que antes de chegar ao destino existem realmente 14 roteadores. Onde: (128 - 14) → 114 $ expr 128 - 14 114

# ping -c3 62.149.188.200 PING 62.149.188.200 (62.149.188.200) 56(84) bytes of data. 64 bytes from 62.149.188.200: icmp_seq=1 ttl=114 time=265 ms 64 bytes from 62.149.188.200: icmp_seq=2 ttl=114 time=266 ms 64 bytes from 62.149.188.200: icmp_seq=3 ttl=114 time=264 ms Usando o comando traceroute, podemos confirmar que realmente há 14 roteadores até o destino, no caso o servidor Windows:

# traceroute -n 62.149.188.200 traceroute to 62.149.188.200 (62.149.188.200), 30 hops max, 60 byte packets 1 192.168.1.1 7.600 ms * * 2 189.40.251.176 29.899 ms 29.871 ms 29.816 ms 3 10.239.249.173 29.719 ms 10.239.249.181 29.680 ms 10.239.249.165 29.617 ms 4 10.239.249.33 29.569 ms 29.519 ms 29.481 ms 5 10.223.238.58 31.292 ms 32.253 ms 32.245 ms 6 149.3.181.9 32.186 ms 30.430 ms 26.199 ms 7 195.22.209.215 247.817 ms 254.405 ms 248.272 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 82.184.8.222 264.668 ms 265.832 ms 267.098 ms 13 62.149.191.26 265.037 ms 62.149.191.30 264.091 ms 62.149.191.26 255.444 ms 14 62.149.185.27 275.158 ms 62.149.185.28 272.382 ms 62.149.185.27 274.570 ms 15 62.149.191.68 267.584 ms 271.833 ms 274.276 ms Entretanto o ping isoladamente não vai te ajudar a determinar à vazão da sua rede em Mbits/sec, uma vez que ele utiliza às mensagens echo request e echo reply para determinar a latência na comunicação entre os dois hosts. Por essa razão, use a ferramenta chamada iperf para fazer o monitoramento de desempenho da sua rede e solucionar possíveis gargalos no meio de transmissão. 2.2.10

Ping da Morte

Figura 8: POD. – Ping of Death. O ping da morte (POD – Ping of Death) é um tipo de ataque de negação de serviço (DoS – Denial of Service) no qual um invasor tenta travar, desestabilizar ou congelar o computador/serviço, enviando pacotes malformados ou superdimensionados usando um simples comando ping. Enquanto os ataques de PoD exploram as deficiências em máquinas/servidores legados, que pecam com a falta de medidas corretivas por patches de atualização. Em sistemas não corrigidos, o ataque ainda é relevante e perigoso. Mas recentemente, um novo tipo de ataque POD se tornou popular, e comumente conhecido como inundação de ping (Ping flood). Esse tipo de ataque, atinge o sistema alvo comprometidos, com pacotes ICMP enviados rapidamente via ping, sem mesmo esperar por respostas da máquina alvo. Assim, infelizmente, é possível usar as mensagens ICMP, especialmente echo-request e echo-reply, para revelar informações sobre sua rede e fazer uso indevido dessas informações para vários tipos de atividades fraudulentas. Portanto, o Firewalld permite bloquear as solicitações do ICMP para proteger as informações da sua rede. Uma boa forma de se proteger contra esses tipos de ataques é ter um bom controle do que entra e sai da sua rede, e claro, bloquear apenas uma parte do tráfego de icmp no Firewall. Para tanto, vamos aos exemplos à seguir. Listar as consultas ICMP ou ICMP Requests: 20

$ sudo Firewall-cmd --get-icmptypes $ sudo Firewall-cmd --info-icmptype=echo-reply echo-reply destination: ipv4 ipv6 $ sudo Firewall-cmd --info-icmptype=echo-request echo-request destination: ipv4 ipv6 $ sudo Firewall-cmd --query-icmp-block=echo-reply no $ sudo Firewall-cmd --query-icmp-block=echo-request no

Ativar o bloqueio de pacotes ICMP (echo-request) na zona: $ sudo Firewall-cmd --zone=FedoraWorkstation --add-icmp-block=echo-request

Desativar o bloqueio de pacotes ICMP na zona: $ sudo Firewall-cmd --zone=FedoraWorkstation --remove-icmp-block=echo-request

Consulta o bloqueio de ICMP: $ Firewall-cmd --zone=FedoraWorkstation --query-icmp-block=echo-request

Agora dê um reload e recarregue o Firewalld para desfazer a ativação dessa regra, pois a mesma não foi criada com a flag --permanent: $ Firewall-cmd --reload

Outro exemplo de bloqueio na zona pública e consulta para mensagens tipo echo-reply: sudo Firewall-cmd --zone=public --add-icmp-block=echo-reply sudo Firewall-cmd --zone=public --query-icmp-block=echo-reply

Bloqueio de solicitações ICMP sem fornecer nenhuma informação (mais restritiva) Normalmente, se você bloquear solicitações ICMP, os clientes saberão que você está bloqueando. Assim, um invasor em potencial que esteja farejando endereços IP ativos ainda poderá ver que seu endereço IP está on-line. Para ocultar essas informações completamente, você precisa descartar todas as solicitações ICMP. Para bloquear e eliminar todas as solicitações do ICMP: $ sudo Firewall-cmd --set-target=DROP $ sudo Firewall-cmd --runtime-to-permanent

Agora, todo o tráfego, incluindo solicitações ICMP, é descartado, exceto o tráfego que você permitiu explicitamente. Para bloquear e eliminar (drop), determinadas requisições de ICMP, mas permitir outros: $ $ $ $ $

sudo sudo sudo sudo sudo

Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd

--set-target=DROP --add-icmp-block-inversion --add-icmp-block=echo-reply --add-icmp-block=echo-request --runtime-to-permanent

ATENÇÃO: – A Inversão de bloco ICMP serve para bloquear TODAS às solicitações ICMP de uma só vez! A inversão de bloco, inverte a configuração dos blocos de solicitações ICMP, portanto todas as solicitações que não foram bloqueadas anteriormente são então bloqueadas. Aquelas que foram bloqueados não estão bloqueados. Isso significa que, se você precisar desbloquear uma solicitação, deverá usar o comando de bloqueio. Para reverter esses bloqueios e voltar para uma configuração totalmente permissiva: $ $ $ $ $

sudo sudo sudo sudo sudo

Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd Firewall-cmd

--set-target=default --remove-icmp-block=echo-reply --remove-icmp-block=echo-request --remove-icmp-block-inversion --runtime-to-permanent

Bloquear ou Não Bloquear Requisições de ICMP? Quando seu servidor rejeita às solicitações ICMP, ele cumpri o seu papel e não fornece às informações. No entanto, isso não significa que nenhuma informação seja dada. Os clientes recebem certas informações de que a solicitação ICMP específica está sendo bloqueada (rejeitada). O bloqueio das solicitações ICMP deve ser manuseada com extremo “Cuidado”, pois pode causar problemas de comunicação, especialmente com o tráfego IPv6! Muitos administradores de sistema acham que o protocolo ICMP é um risco de segurança e que portanto, devem sempre estar bloqueados no Firewall. É verdade que o ICMP tem alguns problemas de segurança associados a ele e que muitos ICMP devem ser bloqueados. Porém isso não é motivo sair bloqueando tudo. Mesmo porque o ICMP possui muitos recursos importantes, alguns são úteis para solução de problemas, enquanto outros são essenciais para que uma rede funcione corretamente, alguns protocolos como por exemplo o UDP, dependem do ICMP para funcionarem corretamente. Aqui estão os detalhes de alguns dos importantes tráfegos ICMP, o qual você deve conhecer e sobretudo considere também permitir seu tráfego livremente na sua rede. Entenda que Bloquear todo o tráfego de icmp dentro de sua rede não vai ajudar muito, e não é o ideal. . . Por isso prefira aplicar às regras de bloqueio de icmp na zona pública. Lembre-se de que você também pode permitir isso com uma determinada direção em mente; você pode decidir deixar as solicitações de eco da sua rede para a internet e as respostas de eco da internet para sua rede, mas não vice-versa. No entanto vale mencionar que a criação do protocolo ICMP foi motivadas por boas intenções. Ele é necessário para o correto envio de informações do MTU (Unidade de transmissão máxima) entre máquinas da sua rede, e essêncial para manter o tráfego de links heterogêneos. Ela é imprescindível para a comunicação e tráfego de rede IPV6, bem como na operação diária da Internet. Saiba que apenas administradores de sistemas novatos (newbies) é que cometem o equívoco comum de bloquear todo tráfego de ICMP nos seus servidores. Nunca faça isso! Não cometa o mesmo erro praticado por eles! Lembre-se: –Na Dúvida, não use o bloqueio completo das requisiçoes do protocolo ICMP. O Path MTU Discovery é usado para determinar o MTU do caminho entre dois dispositivos. A MTU do caminho é o tamanho de pacote máximo suportado no caminho entre o host de origem e o host de recepção. Se um host enviar um pacote que seja maior que a MTU do host de recebimento ou que seja maior que a MTU de um dispositivo ao longo do caminho, o host ou dispositivo de recebimento retornará a seguinte mensagem ICMP: Destination Unreachable: Fragmentation Needed and Don’t Fragment was Set (Tipo 3, Código 4). Isso quando o host original a ajustar o MTU até que o pacote possa ser transmitido. Importante: Alterar o Firewall da sua instância para permitir Path MTU Discovery não garante que os frames jumbo não serão derrubados por alguns roteadores. Um gateway de Internet na sua rede encaminhará somente pacotes até 1500 bytes. São recomendados 1500 bytes de MTU para o tráfico de Internet. Lembre-se que interfaces de rede com suporte à frame jumbo trabalham com o valor do MTU 22

na casa de 9001 bytes. . . Para saber qual é o MTU da sua placa de rede entre com o comando: netstat -ie e use o ip link set eth0 mtu 1500 para alterar o valor do MTU (nem todas placas suportam frame jumbo, MTU de 9001 bytes!). Mas para verificar o MTU do caminho entre 2 máquinas, use o comando tracepath. Se o seu Firewall não permite nenhum tráfego ICMP de entrada. Para garantir que sua instância possa receber essa mensagem e o pacote não tenha sido derrubado, deverá adicionar uma Regra de ICMP personalizada com o protocolo Destino inacessível para as regras do seu Firewall de entrada para sua instância. Para obter mais informações, consulte sobre Path MTU Discovery no Google. Outra dica é sobre o tamanho máximo do pacote IPv4 que é 65535 bytes e o limite permitido no parâmetro size/lenght do ping é 65500. Por isso, é desejável e mais provável que haja alguma regra de filtro pré-configurada no seu roteador que limite esse parâmetro para 19232 bytes. Com isso vai diminuir bastante o uso irregular do ping na sua rede. Como muitos clientes DHCP, incluindo o Windows e o Linux, não levam em conta o MTU Atributo no DHCP, portanto será necessário permitir protocolos baseados em TCP para definir MSS com base em PMTU. A Descoberta MTU do caminho usa e depende do TCP MSS. Para tanto, adicione a seguinte regra no seu Firewall: Firewall-cmd --permanent --direct --add-passthrough ipv4 -I FORWARD -p \ tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Sobre o MTU: • MTU é o tamanho máximo do pacote IP de um determinado link. MSS é o tamanho máximo do segmento TCP. • MTU é usado para fragmentação de pacotes, isto é, um pacote maior do que o MTU (fora da LAN, tráfego externo), deverá ser fragmentado. Mas no caso do MSS, o pacote maior que o MSS é normalmente descartado. • MSS é especificado durante o handshake TCP basicamente em pacotes SYN e seu valor não pode ser alterado após a conexão ser estabelecida. • MSS = MTU - 40 ( IP header(20 bytes) + TCP header(20 bytes) ). Além disso tudo que foi dito, o valor MSS deriva do valor MTU, ou seja se você tiver um pacote de 800 bytes por exemplo, também pode dizer que tal pacote tinha originalmente 2260 bytes, e ele dividiu em 2 pacotes 1460 + 800 bytes, pois usarmos MTU = 1500. Se seu MSS é de 800 bytes, o MTU deve ser pelo menos 840 bytes. Como sobrecarga de PPPoE é 8 bytes e, portanto, MTU = 1492 bytes e o MSS (1492 - 40) = 1452 bytes. 2.2.11

Redirecionamento de Portas (Port Forwarding)

Usando o Firewalld, você pode configurar o redirecionamento de portas para que qualquer tráfego de entrada que atinja uma determinada porta em seu sistema seja entregue a outra porta interna de sua escolha ou a uma porta externa em outra máquina. Por Exemplo, Redirecionando TCP Porta 80 para Porta 88 na mesma máquina: $ sudo Firewall-cmd --add-forward-port=port=80:proto=tcp:toport=88 $ sudo Firewall-cmd --runtime-to-permanent $ sudo Firewall-cmd --list-all

2.2.12

Mascaramento de IP (IP Address Masquerading)

Os endereços de uma rede privada são mapeados e ocultos por trás de um endereço ip público. Esta é uma forma de tradução de endereços e usada principalmente em roteadores. Depois de habilitar o mascaramento para a zona no meu computador, outros hosts dentro da minha rede, poderão se conectar e navegar na web usando meu IP como gateway de internet. O mascaramento é apenas IPv4 por causa das limitações do kernel. Ativar o mascaramento na zona: $ sudo Firewall-cmd --zone=FedoraWorkstation --add-masquerade

Desativar o mascaramento na zona: $ sudo Firewall-cmd --zone=FedoraWorkstation --remove-masquerade

Consultar o mascaramento em uma zona $ Firewall-cmd --zone=FedoraWorkstation --query-masquerade

Veja que o ip_forward foi ativado automaticamente quando ativamos o mascaramento na zona. Não precisa alterar o sysctl, ele já fez isso para você: $ cat /proc/sys/net/ipv4/ip_forward 1

Caso não tenha ainda ativado o ip_forwad, use o comando sysctl. Isso irá habilitar o tráfego de pacotes nas interfaces de rede do seu servidor. Saiba que isso é muito útil para à comunicação ou à junção entre 2 redes de classe diferentes, e ou, transformar teu servidor em um Gateway de Rede. $ sudo sysctl net.ipv4.ip_forward=1 $ sudo sysctl -p $ sudo sysctl -a | grep forward

Vejamos um outro exemplo: ---------+----------Gateway|192.168.1.1 | External | enp3s0|192.168.1.72 +--------+---------+ | | | fedorasrv | | | +--------+---------+ enp2s0|10.0.0.72 (vlan) Internal | De acordo com o esquema acima, vamos hipotéticamente imaginar que alguém que gosta muito da sua pessoa, teve a brilhante idéia de segmentar a rede da Empresa, e configurou uma linda VLAN. No entanto foi solicitado tão somente à você, uma pequena mãozinha, pediram para ajustar o acesso ao Gateway para essa VLAN, de forma isoladamente. Primeiro vamos alinhar as zonas com as interfaces de rede (internal e external) e em seguida ativar o seu mascaramento: $ sudo Firewall-cmd --permanent --zone=internal --change-interface=enp3s0 $ sudo Firewall-cmd --permanent --zone=external --change-interface=enp2s0 $ sudo Firewall-cmd --reload $ Firewall-cmd --get-active-zones internal interfaces: enp2s0 external interfaces: enp3s0 $ sudo Firewall-cmd --permanent --zone=external --add-masquerade success $ sudo Firewall-cmd --reload success $ Firewall-cmd --zone=external --query-masquerade yes $ cat /proc/sys/net/ipv4/ip_forward 1

Agora precisamos configurar os pacotes de saída através do servidor da rede interna (10.0.0.0/24) sejam permitidos e encaminhados para o lado externo: $ sudo Firewall-cmd --permanent --zone=internal --add-masquerade success $ sudo Firewall-cmd --permanent --direct --add-rule ipv4 nat POSTROUTING 0 -o eth1 -j MASQUERADE $ sudo Firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -i eth0 -o eth1 -j ACCEPT $ sudo Firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT $ sudo Firewall-cmd --reload success

Agora pediram para você configurar os pacotes de entrada que chegam à porta 15567 da zona externa sejam encaminhados para porta 3389 do serviço de Terminal Server (RDP) do Host cujo IP é 10.0.0.20. 25

E os pacotes que chegam à porta 40022 da zona externa sejam encaminhados para porta 22 do serviço SSH do Host cujo IP é 10.0.0.30. Como é uma configuração temporária, não usaremos a opção --permanent: $ sudo Firewall-cmd --zone=external --add-forward-port=port=15567:proto=tcp:toport=3389:toaddr=10.0.0.20 $ sudo Firewall-cmd --zone=external --add-forward-port=port=40022:proto=tcp:toport=22:toaddr=10.0.0.30 $ Firewall-cmd --list-all --zone=external external (active) interfaces: eth1 sources: services: dhcpv6-client ssh samba-client mdns samba openvpn ntp imap http https ftp docker-registry dns nfs imaps ipp ipp-client pptp dhcp dhcpv6 shoutcast ports: masquerade: yes forward-ports: port=15567:proto=tcp:toport=3389:toaddr=10.0.0.20 port=40022:proto=tcp:toport=22:toaddr=10.0.0.30 icmp-blocks: rich rules:

Posteriormente, para remover o redirecionamento das portas: $ sudo Firewall-cmd --reload

2.2.13

Firewalld também é capaz de lidar com endereços MAC.

Você pode usar endereços de MAC para criar regras em determinada zona e também em regras avançadas. Abaixo seguem dois exemplos. Adicionar uma filtragem de endereço MAC bem simples: sudo Firewall-cmd --zone=FedoraWorkstation --add-source=00:11:22:33:44:55 sudo Firewall-cmd --zone=FedoraWorkstation --add-rich-rule='rule source mac=11:22:33:44:55:66 drop'

Veja como verificar o seu endereço Mac: $ head /sys/class/net/*/address ==> /sys/class/net/enp3s0/address <== 54:04:a6:7a:69:bd ==> /sys/class/net/lo/address <== 00:00:00:00:00:00 ==> /sys/class/net/wlp2s0/address <== e0:b9:a5:21:51:b6

Por último, mas definitivamente não menos importante, um dos mais usados, é o comando echo. Este comando pode ser usado para fazer tudo, desde a verificação, para garantir que um for loop irá executar a seqüência esperada ou até para permitir que você verifique se as portas remotas de um servidor estão abertas. A sintaxe é muito simples para verificar se há uma porta aberta: echo > /dev/<udp or tcp>/<server ip>/<port>. Por exemplo: $ echo > /dev/tcp/10.0.0.30/22 -bash: connect: Connection refused -bash: /dev/tcp/10.0.0.30/22: Connection refused $ echo > /dev/tcp/10.0.0.30/40022

Se a porta estiver fechada para o tipo de conexão que você está tentando fazer, você receberá a mensagem: Connection refused. Se o pacote for enviado com sucesso, não haverá nenhuma saída. Outro exemplo, vamos verificar a porta 587 do gmail: $ echo > /dev/tcp/smtp.gmail.com/587

IPTABLES

Figura 9: iptables. – Construindo o 1 ° perímetro de segurança. Nunca diga nunca. . . – Sempre haverá um sistema legado amarrado à regra de negócio da Empresa e tem coisas que só o velho iptables faz por você. – Não há como comprar segurança, ela não vêm pronta. Ela precisa ser construída. Famoso pela sua força e estabilidade, o incansável iptables continua sendo uma solução de baixo custo para implantação de Firewalls. Ele fornece um elevado grau de controle de acesso para recursos de alto valor. É considerado um excelente front end para o filtro de pacotes do Linux, com altíssimo desempenho, capaz de melhorar a segurança da rede, dificultando bastante o acesso não autorizado. Entretanto, as brechas de segurança sempre surgirão na sua rede, sendo praticamente impossivel se imunizar contra todos os ataques oriundos da internet, só podemos mesmo dar uma blindada e diminuir um pouco o risco de invasões e extravio ou roubo de informações. Tenha em mente que qualquer Firewall, seja ele qual for, é apenas a primeira linha de defesa da sua rede e há muitos outros pontos de segurança que devem estar consolidados para garantir a segurança da informação.

Figura 10: netfilter/iptables. serão substituidos pelo bpfilter/BPF (Berkeley Packet Filter).

– “Por quê a comunidade do linux kernel estão dispostos à substituir o iptables (netfilter) pelo novo BPF”? A comunidade do kernel do Linux anunciou recentemente o bpfilter, este substituirá a implementação de longa data do kernel do iptables (netfilter) pela filtragem de rede de alto desempenho desenvolvida pelo Linux BPF (Berkeley Packet Filter), garantindo ao mesmo tempo uma transição sem interrupções para os usuários do Linux. De raízes humildes como o recurso de filtragem de pacotes subjacente a ferramentas populares como o tcpdump e o Wireshark, o BPF tornou-se uma estrutura rica para estender as capacidades do Linux de maneira altamente flexível sem sacrificar as principais propriedades como desempenho e segurança. Essa poderosa combinação levou os usuários avançados da tecnologia de kernel do Linux, como Google, Facebook e Netflix, a escolher o BPF para casos de uso que vão desde segurança de rede e balanceamento de carga até monitoramento de desempenho e solução de problemas. Brendan Gregg, da Netflix, chamou pela primeira vez BPF de “o Superpowers do Linux”. – “Tendo passado os últimos 15 anos no código de criação de comunidades de kernel do Linux para muitos subsistemas, incluindo a pilha TCP / IP, o iptables e muitos outros, eu pude observar os desenvolvimentos do BPF de perto. Logo percebi que o BPF não era simplesmente mais um recurso, mas representava uma mudança tecnológica fundamental que, com o tempo, mudaria quase todos os aspectos da rede e da segurança dentro do Linux. Comecei a contribuir e me tornei um de seus maiores apoiadores, ao lado de Alexei Starovoitov e Daniel Borkmann, que agora estão mantendo o BPF. Assim, a mudança do iptables com o bpfilter é apenas o próximo passo lógico na jornada do BPF para revitalizar a pilha de redes do Linux e modernizar o seu Firewall ”. – Diz Thomas Graf, criador do projeto Cilium. Saiba mais no tópico: introduzindo as ferramentas BPF com a Cloudflare ⇒ https://blog.cloudflare. com/introducing-the-bpf-tools/ e também dê uma olhada no seu código fonte em: https://github. com/cloudflare/bpftools Todos estamos aguardando anciosos por essa transição de tecnologia, vai ser um super upgrade que o Linux estava merecendo faz um bom tempo, pois o iptables coitadinho, ja faz mais de 20 anos que foi escrito, e isso foi na época de internet discada, onde as máquinas possuíam baixa memória e pouco processamento. Hoje as coisas estão bem diferente, temos streamming de video, VMs e containers dockerizados para tudo que é lado, contamos com serviços de nuvem, com altíssima capacidade de armazenamento, temos drones e carros com sistemas autônomos, sem falar na internet que está cada vez mais veloz e acessível como nunca se imaginou antes, ainda mais com a internet das coisas (IoT – Internet of Things) vindo aí, promentendo muita revolução na comunicação entre os aparelhos.

3.1

Primeiras configurações do Iptables

Depois de falar das novidade que vêm por aí, nem dá vontade de seguir com o velho iptables. . . mas como foi prometido, vamos passar a receita de bolo que muitos Admnistradores de Redes já estão carecas de saber. Uma verdadeira retrospectiva para matar a saudade para os tiozinhos de plantão e uma chance para os novatos, se deliciarem com as regras do iptables. O iptables, na maioria das vêzes pode ser encontrado pré-compilado ou pré-instalado em todas as distribuições Linux famosas. Nesses sistemas, o iptables é instalado neste diretório: /usr/sbin/iptables. Ele também pode ser encontrado em: /sbin/iptables, mas como o iptables é mais como um serviço do que como um “binário essencial”, a localização preferida permanece no antigo diretório: /usr/sbin. Verificar a versão corrente: $ sudo iptables --version

Verifique se há alguma regra criada: $ sudo iptables -L

Ele deverá estar no modo permissivo ou seja sem nenhuma regra ativada: 28

Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination

Mas se você não quiser usar a linha de comando, então pode utilizar outra alternativa: SHOREWALL. Shorewall é um gateway/Firewall ferramenta de configuração para GNU/Linux. É ferramenta de alto nível para configuração do netfilter. A descrição completa dele você descobre aqui: http://shorewall. net/Documentation_Index.html. Dando prosseguimento, nós definimos como interface de rede local o dispositivo eth1 e a interface para acesso à internet o dispositivo eth0. Mas para os novos sistemas baseados em systemd/udev, utiliza-se do predictable network interface naming (nomenclatura de interfaces previsíveis) sendo os dispositivos chamados de enp2s0, enp3s1, enp4s2. . . e etc. en ⇒ ethernet p2 ⇒ bus number (2) s0 ⇒ slot number (0) O problema da nomenclatura tradicional é que as interfaces de mesma natureza recebem seus nomes do kernel de maneira sequêncial (no formato eth0, eth1, eth2, etc...) assim que elas são consultadas pelo driver. Ocorre que o mecanismo de comunicação entre o driver e a interface não é previsível, o que implica na possibilidade de alteração nos nomes das interfaces durante o processo de boot de máquinas que tenham múltiplas interfaces de rede em caso de atualização de hardware. Essa situação traz riscos de segurança em ambientes que tenham scripts de Firewall que foram baseados nos nomes tradicionais. Portanto vamos definir como interface de rede local o dispositivo enp2s0 e a interface para acesso à internet o dispositivo enp3s0. Quem quiser pode alterar e voltar para antiga nomenclatura eth(x) mas aqui vou manter o novo padrão: rede interna (lan) <--- enp2s0--{linux server}--enp3s0 ---> [modem] --> (internet) A nossa rede é 10.0.0.0/24

3.2

Ativando os módulos

Agora é necessário que sejam ativados os módulos para garantir o funcionamento do iptables. Cuidado pois se você tem a mania de recompilar o seu kernel sem módulos, para melhorar a velocidade do boot e limar drivers inúteis, fique atento para não esquecer de marcar como módulos o filtro de pacotes ipfilter, caso contrário terá que recompilar tudo denovo. Não que isso seja difícil, mas é trabalhoso e muito demorado! sem falar no maldito kernel panic. . . Vai vendo. . . Mano, antes do systemd, recompilar o kernel era algo necessário mas agora não vale mais a pena, já perdi muito tempo compilando. Hoje uma distribuição de boa qualidade, tem que ter todos os pacotes prontos e atualizados. Isto pra mim é lei, do tipo critério básico/trivial. Além disso, em se tratando de servidor de produção, puxa vida, kernel estável só atualiza quando e se surgir um bug das galáxias, daquelas bem nervosas e invocado, que podem travar e engessar toda a sua operação! Caso contrário, meu chapa, toda proatividade será procrastinada, sem dó e nem piedade. Primeiramente vamos ativar os módulos necessários da mesma forma como instalamos os drivers no sistema. Porém, como tem muitos módulos para instalar, melhor criar uma lista dessa forma: 29

$ cat <<EOF> minhalista.txt ip6t_rpfilter ip6t_REJECT ip6t_MASQUERADE ip6t_LOG ip6t_REDIRECT ip6_tables ip6table_filter ip6table_nat ip6table_mangle ip6table_raw ip6table_security ipt_rpfilter ipt_REJECT ipt_MASQUERADE ipt_LOG ipt_REDIRECT ip_tables iptable_filter iptable_nat iptable_mangle iptable_raw iptable_security EOF

Vamos instalar e listar todos os módulos: $ sudo xargs -n 1 modprobe < minhalista.txt $ lsmod | grep -i ip

O que não aparecer na lista é porque já está rodando no kernel sem a necessidade dos módulos, como por exemplo o ip_tables que no meu caso nem apareceu como módulo: $ modprobe -D ip_tables builtin ip_tables

Esse parametro -D, faz um print das dependências do módulo e nesse caso ele já carregou o mesmo durante a inicialização (builtin). Então finalize, reniciando tudo, só para garantir: $ sudo reboot

Maravilha, modulos estão ativados, vamos limpar as regras residuais das tabelas nat, filter e zerando os contadores como root: su iptables iptables iptables iptables

-F -t nat -F -Z -t nat -Z

A política padrão -P sempre é ACCEPT, por isso para a nossa política, vamos alterá-la e adotar a flag restritiva para a tabela filter, que é a DROP, ou seja descartar tudo que não se encaixar com as regras individuais das nossas chains. Perceba que somente a política de saída (OUTPUT), é que deixaremos ela livre, uma pegada menos agressiva. . . Entretanto caso esteja com sangue nos olhos e queira mesmo restringir o tráfego de pacotes que estiverem saindo (pacotes retirantes), terá que enumerar todas as portas usadas pelo sistema da Empresa, webservers (http e https), vpn, terminal services, pop3, smtp, torrents, voip, databases e etc. . . Além disso se for configurar isso na sua casa, alguém por exemplo que queira usar a Steam para Games, nesse caso você também deverá incluir todas as benditas portas e protocolos da Steam nas regras de OUTPUT. 30

iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT

Mano, até aqui, o nosso Firewall basicamente já está de pé. Mas é claro com bloqueio padrão, mas tudo está fechado, não penetra nem agulha com vaselina! Daqui em diante podemos ir liberando aos poucos, de acordo com a demanda. Temos que criar também as regras individuais das chains para tratamento da tabela filter.

Figura 11: Iptables. – Não entra nem agulha com vaselina. . . ui, que coisa boa!

3.3

A filtragem dos pacotes

Sobre a filtragem de pacotes pode-se dizer que basicamente, a filtragem consiste em um conjunto de regras que analisam e filtram pacotes recebidos ou encaminhados por dispositivos de filtragem (netfilter). A princípio, atua sobre as camadas 3 (rede) e 4 (transporte) do modelo OSI (Open System Interconnection), ou seja, analisando o cabeçalho de protocolos de rede (como IP ou IPX, por exemplo) e protocolos da camada de transporte (como TCP ou UDP). No Linux, a infraestrutura responsável pela filtragem de pacotes é conhecida como netfilter. Ao contrário do que muitos imaginam, iptables (filtragem IP), arptables (filtragem ARP) e ebtables (filtragem MAC/bridge-Firewall) consistem em ferramentas administrativas e oficiais que interagem com esta infraestrutura. Aliás, nos últimos anos, vem sofrendo alterações para dar lugar ao nftables, substituindo todas as demais ferramentas citadas anteriormente e isso sem falar no BPF, não? Por se tratar de uma implementação de Firewall baseada na “inspeção de estados” (capaz de detectar uma conexão inválida, nova, estabelecida, reincidente ou assegurada), o sistema mantém, em memória, uma área reservada para mapear conexões negociadas explicitamente pelo Firewall (área conhecida como conntrack) e outra para validar conexões esperadas posteriormente ou reincidentes (conhecida como expected) — a área de memória principal e responsável por estes mapeamentos é conhecida como tabela de estados. A cada nova requisição, o sistema realizará uma entrada na tabela de estados (conntrack), mapeando a solicitação como NEW (nova). Se não houver impedimento para a abertura de conexão, o mapeamento será atualizado para ESTABLISHED (estabelecido). O processo é automático, mesmo que o administrador não digite uma única regra — basta que o módulo nf_conntrack_ipv4 seja carregado. É o que torna o sistema capaz de inspecionar o estado de conexão. Graças a este recurso, podemos escrever regras de Firewall prevendo apenas o sentido de conexão que desejamos controlar, pois, se o tráfego for autorizado, a resposta será tratada por uma regra global que tratará qualquer fluxo mapeado como ESTABLISHED. Há diferentes estados de conexão, os mais conhecidos e inspecionados são: “INVALID, NEW, ESTABLISHED e RELATED”. O INVALID costuma ser utilizado para impedir tráfego não esperado, como solicitações de conexão TCP sem o bit SYN ativo. Também podemos impedir explicitamente, filtrando o estado NEW, a abertura de conexão originada por interfaces WAN. O estado RELATED é bastante semelhante ao ESTABLISHED, a diferença é que ele trata conexões esperadas posteriormente e negociadas dinâmicamente por protocolos específicos, como FTP e SIP por exemplo. 31

Figura 12: Kernel Firewall. – Netfilter Chains. Cada cadeia (chain) é responsável por um fluxo específico. Veja mais detalhes abaixo: 1. Ao receber um pacote, antes de identificar o destino final, o sistema operacional primeiro avalia a cadeia PREROUTING (pré-roteamento). Ou seja, podemos filtrar qualquer pacote recebido (ingress). É neste momento que podemos interferir nas decisões de roteamento. Por esta razão, tanto o redirecionamento de conexão (NAT de destino) como a manipulação de roteamento por regra de Firewall são feitos na PREROUTING. 2. A cadeia INPUT será verificada APENAS quando o destino de conexão for o próprio Firewall – para disponibilizar o acesso aos serviços providos localmente. Do contrário, o sistema entende que o pacote deve ser encaminhado a outro roteador e, sendo assim, avalia as permissões definidas na FORWARD. Logo, na maioria das vezes, o controle de Internet é feito na FORWARD. Já a cadeia OUTPUT é processada quando o Firewall for origem de conexão ou em resposta a um serviço consumido localmente (em seguida ao INPUT). Na maioria das vezes, a cadeia OUTPUT não é restritiva. 3. Por fim, antes de encaminhar o pacote ao endereço de destino, o sistema avalia a cadeia POSTROUTING (pós-roteamento). Neste momento a decisão de roteamento já foi concluída – o caminho de roteamento, bem como sua respectiva interface rede, já foi selecionado. Ou seja, podemos filtrar qualquer pacote que saia do Firewall (egress). Por esta razão, o NAT de saída (seja SNAT ou MASQUERADE) é feito na POSTROUTING. Este entendimento é essencial para qualquer configuração que envolva o netfilter. Compreendido o papel das cadeias internas, o próximo passo é entender como aplicá-las de acordo com o objetivo do filtro: “filtragem de pacotes, NAT ou manipulação de pacotes (ou tabela de estados)”. Internamente, o sistema separa o tipo de filtragem por tabela (função/objetivo): Tipo → Função/Objetivo; filter → Controle de acesso; nat → Tradução IP (NAT); mangle → Alteração na tabela de estados ou cabeçalho IP; raw → Depuração (TRACE) ou controle de entradas na tabela de estados. Depois da aula de história, vamos voltar e começar liberando aos poucos, de acordo com a demanda. Temos que criar também as regras individuais das chains para tratamento da tabela filter. Só lembrando. . . pois a policy já foi definido lá atrás. . . : 32

Figura 13: iptables/chains. – Obedeça à ordem de execução das regras do iptables.

iptables -P INPUT DROP

As regras deverão ser criadas acima da politica padrão, ou seja para serem executadas antes do DROP, por isso usamos o parâmetro “-I INPUT” para posicionar a regra no início da lista. Se deixar a política padrão como ACCEPT, aí nesse caso pode usar o parâmetro “-A INPUT” e adicionar as regras na ordem e quando chegar na última regra, deve colocar “-A INPUT -j DROP” para descartar tudo que não satisfazer ou não se encaixar nas definições das regras anteriores. Entenda que no iptables, existe uma ordem de execução, que vai de cima para baixo, sempre que processar às regras do Firewall. Manda descartar pacotes inválidos: iptables -I INPUT -m conntrack --ctstate INVALID -j DROP

São aceitos pacotes por estado de conexão, relatados e estabelecidos: iptables -I INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Pacotes de loopback são aceitos: iptables -I INPUT -i lo -j ACCEPT

Aceita conexão via SSH pacotes vindo da LAN: iptables -I INPUT -i enp2s0 -s 10.0.0.0/24 -p tcp --dport 22 -j ACCEPT

Aceita conexão via FTP pacotes vindo da LAN e depois lista as regras de INPUT: iptables -I INPUT -i enp2s0 -s 10.0.0.0/24 -p tcp -m multiport --dports 20, 21 -j ACCEPT iptables -nL INPUT

Aceita consultas de DNS recursivo na rede LAN: iptables -A FORWARD -i enp2s0 -s enp3s0 -p udp --dport 53 -j ACCEPT

Pacotes de redirecionamnetos de loopback são aceitos: iptables -A FORWARD -i lo -j ACCEPT

São aceitos pacotes de redirecionamentos por estado de conexão, relatados e estabelecidos: iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP

Habilitando o NAT: iptables -t nat -A POSTROUTING -s enp2s0 -o enp3s0 -j MASQUERADE

Habilitando o redirecionamento terminal services (ts) na porta 3389 onde a interface do nosso Firewall é enp3s0 com IP 10.0.0.1 e também redirecionar o tráfego http na porta 80 para máquina IP 10.0.0.2. iptables -t nat -A PREROUTING -i enp3s0 -p tcp --dport 3389 -j DNAT --to 10.0.0.200:3389 ou iptables -t nat -I PREROUTING -p tcp --dport 3389 -d 10.0.0.1 -j DNAT --to 10.0.0.200 iptables -t nat -I PREROUTING -p tcp --dport 80 -d 10.0.0.1 -j DNAT --to 10.0.0.2 iptables -t nat -nvL

Aceita o redirecionamento de pacotes com origem de qualquer ip com destino às portas: 3389 e 80: iptables -A FORWARD -s 0/0 -p tcp --dport 3389 -j ACCEPT iptables -A FORWARD -s 0/0 -p tcp --dport 80 -j ACCEPT

Liberando somente 3 máquinas (.10 .13 e .18), acessarem o server 10.0.0.2 na porta 80: iptables iptables iptables iptables iptables

-t filter -I -t filter -I -t filter -I -t filter -I -nvL FORWARD

FORWARD FORWARD FORWARD FORWARD

-s -s -s -s

10.0.0.10 -j ACCEPT 10.0.0.13 -j ACCEPT 10.0.0.18 -j ACCEPT 10.0.0.2 -j ACCEPT

+ OBS : – Lembre-se que a politica padrão para forward é drop, portanto nem precisa executar novamente a regra de bloqueio: iptables -t filter -A FORWARD -j DROP Veja na última regra do FORWARD que foi liberado o IP: 10.0.0.2 -j ACCEPT .Caso contrário bloquearia à resposta de conexão para servidor IP 10.0.0.2 na porta 80. Bloqueia todo o acesso a porta 3000 com excessão do ip 10.0.0.20: iptables -I INPUT -p tcp -s 10.0.0.20/24! --dport 3000 -j DROP iptables -I INPUT -p tcp -s 10.0.0.20/24! --dport 3000 -m conntrack \ --ctstate NEW,ESTABLISHED -j DROP

Bloqueia entrada de pacotes icmp (ping) echo request para seu servidor: iptables -I INPUT -p icmp --icmp-type 8 -j DROP

Como o Mysql/Mariadb está rodando o seu bando de dados, você deve proteger seu servidor de um acesso externo. Permita que os endereços IP do seu servidor de aplicativos confiável apenas se conectem ao seu servidor MySQL. iptables -I INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -m conntrack \ --ctstate NEW,ESTABLISHED -j ACCEPT

Lembra que a política de output esta como accept. . . então podemos bloquear a saída assim para envio email e envio de ping: 34

iptables -I OUTPUT -p tcp --dport 25 -j DROP iptables -I OUTPUT -p icmp --icmp-type 8 -j DROP

(Extras) – Bloqueio de DDoS negação de serviço distribuído: iptables -I INPUT -p tcp --dport 80 -m limit --limit 20/minute --limit-burst 100 -j ACCEPT

Bloqueio de escaneamento de portas: iptables -N block-scan iptables -A block-scan -p tcp -tcp-flags SYN,ACK,FIN,RST RST -m limit -limit 1/s -j RETURN iptables -A block-scan -j DROP

Bloqueio de bad ports, badport=“135,136,137,138,139,445 ” iptables -A INPUT -p tcp -m multiport --dport $badport -j DROP iptables -A INPUT -p udp -m multiport --dport $badport -j DROP

Bloquear ou permitir pings. Para bloquear ou permitir o protocolo ICMP (vulgarmente designado de ping) para a vossa máquina, basta que usem uma das seguintes regras (de acordo com o pretendido). iptables -A INPUT -p icmp --icmp-type echo-request -j DROP iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

Visualizar todas as regras em detalhe e sem resolver nomes de domínio: iptables -L -n --verbose

Visualizar todas as regras com número de linha: iptables -n -L -v --line-numbers

Você consegue modificar ou remover uma regra usando o numero da linha. Por exemplo, para apagar facilmente as regras do Firewall, é importante saber qual a linha a que corresponde essa regra -line-numbers: iptables -L INPUT -n --line-numbers iptables -L -n -v --line-numbers | grep -i 22 3 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW

Vamos considerar para este exemplo, apagar a regra 3: iptables -D INPUT 3

Do mesmo modo que se apagam regras de uma determinada posição, é também possível criar regras para uma determinada posição (Não se esqueçam que o iptables funciona em modo Top-Down). Vamos considerar que pretendemos novamente colocar a regra que apagas novamente na posição 3. iptables -I INPUT 3 -p tcp --dport 22 -j ACCEPT

Por padrão o iptables salva as regras em: /etc/sysconfig/iptables-config. O comando para salvar as regras: iptables -S

Despeje o conjunto atual de regras na saída padrão e em um arquivo chamado minhas_regras.txt digitando: iptables -S | tee minhas_regras.txt

Outra forma de se fazer o backup & o restore no iptables: iptables-save > minhas_regras.txt iptables-restore < minhas_regras.txt

Ao inicializar o sistema, irá carregar tudo automaticamente! No CentOS, RHEL e Fedora, pode-se usar o comando service iptables save. Mas também é recomendável deixar um script pronto do tipo carrega_Firewall.sh para facilitar a edição de novas regras e testes, antes de colocá-lo em produção. Para melhor aprofundamento sobre o iptables, vou deixar o link à seguir: http://www.tldp.org/HOWTO/ Firewall-HOWTO.html 3.3.1

Extras → The black hole

Figura 14: O buraco negro – filtragem de blackhole. Essa é a forma mais rápida que eu conheço para barrar e banir, o maldito miliante e capiroto invasor, da sua rede. – “Melhor que isso só dois disso!” Derrubar ou bloquear imediatamente o IP do atacante cujo endereço é 65.21.34.20, adicionando rotas nulas ou filtragem de blackhole para esse host: sudo route add 65.21.34.20 gw 127.0.0.1 lo netstat -nr

Criar uma rota com o IP da rede do atacante e manda ele lá para casa do chapéu. . . : sudo route add -net 65.21.34.0/24 gw 127.0.0.1 lo route -n

Apagar uma rota: sudo route delete 65.21.34.20

Ou pode também bloquear assim: $ sudo route add -host 192.168.1.7 reject $ sudo ip route get 192.168.1.7 RTNETLINK answers: No route to host

Para fazer o bloqueio usando uma lista de ips: 36

cat <<EOF> lista_ip.txt 192.168.1.3 192.168.1.5 192.168.1.6 192.168.1.7 EOF

Para adicionar todos os hosts através da lista_ip.txt, usaremos um laço de repetição (For ou While): for i in do sudo sleep done unset route

$(cat lista_ip.txt) route add -host $i reject 1 i -n

Ou pode usar o while, assim: cat lista_ip.txt | while read i do sudo route add -host "$i" reject done unset i route -n

Para remover os hosts: for i in $(cat lista_ip.txt) ; do sudo route del -host $i reject; sleep 1 ; done; unset i; route -n; cat lista_ip.txt | while read i; do sudo route del -host "$i" reject; done; unset i; route -n;

3.3.2

Uso Prático da Tabela Mangle

Vamos marcar os pacotes usando a tabela mangle do iptables e identificar essas marcações na regra da tabela de roteamento do iproute2. Isso porque temos basicamente 2 problemas no balanceador de carga, quando utilizamos o iproute2 no Linux: 1. Em um dos links de internet possui um redirecionamento para a rede interna, o qual segue direto para um webserver, portanto se o balanceador de carga estiver ativo, logo os pacotes não serão entregues corretamente no webserver, interrompendo à conexão “client-server”. 2. Um usuário que está na rede interna, precisar acessar um site do banco, mas o mesmo registra a sessão e controla à conexão do usuário via IP do link ou seja, se o balanceador de carga alterar esse IP em dado momento, poderá interromper a sessão atual da página do navegador. Segue o conteúdo do script rc.routes.sh, no exemplo abaixo: #!/bin/bash # variaveis/constantes VIRTUA_IPA="192.168.xxx.xxx" VIRTUA_NET="192.168.xxx.xxx/24" VIRTUA_GAT="192.168.xxx.xxx" VIRTUA_NIC="eth1" EMBRATEL_IPA="200.252.xx.xxx" EMBRATEL_NET="200.252.xx.xxx/26" EMBRATEL_GAT="200.252.xx.xxx" EMBRATEL_NIC="eth2" # limpando tabelas

ip route flush table VIRTUA ip route flush table EMBRATEL ip route flush table BALANCEAMENTO # limpando regras ip ip ip ip ip

rule del from 200.252.xxx.xxx table EMBRATEL rule del from 192.168.xxx.xxx table VIRTUA rule del fwmark 0x2 table BALANCEAMENTO rule del fwmark 0x1 table EMBRATEL route del default

# configuracoes tabela VIRTUA ip route add $VIRTUA_NET dev $VIRTUA_NIC src $VIRTUA_IPA table VIRTUA ip route add default via $VIRTUA_GAT table VIRTUA # configuracoes tabela EMBRATEL ip route add $EMBRATEL_NET dev $EMBRATEL_NIC src $EMBRATEL_IPA table EMBRATEL ip route add default via $EMBRATEL_GAT table EMBRATEL # trafico da eth1 sai pela tabela VIRTUA ip rule add from $VIRTUA_IPA table VIRTUA # trafico da eth2 sai pela tabela EMBRATEL ip rule add from $EMBRATEL_IPA table EMBRATEL # definindo regra para marcacao de pacotes da intranet sairem pelo BALANCEAMENTO ip rule add fwmark 2 table BALANCEAMENTO # definindo regra para pacotes marcados sairem pela EMBRATEL ip rule add fwmark 1 table EMBRATEL # Criando balanceamento multilink para tabela BALANCEAMENTO ip route add default scope global table BALANCAMENTO nexthop via $VIRTUA_GAT \ dev $VIRTUA_NIC weight 1 nexthop via $EMBRATEL_GAT dev $EMBRATEL_NIC weight 1 # definindo rota padrao ip route add default via $EMBRATEL_GAT # fazendo flush no cache de rotas que foram deletadas ip route flush cache

Segue agora o script rc.Firewall: #!/bin/bash # variaveis/constantes IPTABLES="/sbin/iptables" ### limpando tabela filter $IPTABLES $IPTABLES $IPTABLES $IPTABLES $IPTABLES

-t -t -t -t -t

filter filter filter filter filter

-F -P INPUT ACCEPT -P OUTPUT ACCEPT -P FORWARD ACCEPT -X

### limpando tabela nat $IPTABLES $IPTABLES $IPTABLES $IPTABLES $IPTABLES

-t -t -t -t -t

nat nat nat nat nat

-F -P PREROUTING ACCEPT -P OUTPUT ACCEPT -P POSTROUTING ACCEPT -X

### limpando tabela mangle $IPTABLES $IPTABLES $IPTABLES $IPTABLES $IPTABLES $IPTABLES $IPTABLES

-t -t -t -t -t -t -t

mangle mangle mangle mangle mangle mangle mangle

-F -P -P -P -P -P -X

PREROUTING ACCEPT INPUT ACCEPT FORWARD ACCEPT OUTPUT ACCEPT POSTROUTING ACCEPT

### ativando ip forward echo 1 > /proc/sys/net/ipv4/ip_forward ### Fazendo redirecionamento para servidores na rede interna # tratando a ida $IPTABLES -t nat -A PREROUTING -i eth2 -d 200.252.xxx.xxx -p tcp -m tcp --dport 80 \ -j DNAT --to-destination 10.1.0.20:80 # tratando a volta $IPTABLES -t mangle -A PREROUTING -i eth0 -s 10.1.0.20 -p tcp --sport 80 -j MARK \ --set-mark 1 ### Marcando pacotes que serao direcionados para tabela BALANCEAMENTO # especificando uma maquina da rede para usar balanceamento $IPTABLES -A PREROUTING -t mangle -s 10.1.0.100/32 -d 0/0 -j MARK --set-mark 2 # Mascarando conexoes $IPTABLES -t nat -A POSTROUTING -s 10.1.0.20/24 -j MASQUERADE $IPTABLES -t nat -A POSTROUTING -s 10.1.0.100/24 -j MASQUERADE

Ambos os scripts trazem à solução para os nossos problemas (no ambiente específico). Para tudo funcionar, foi preciso usar o iproute2 para criar uma tabela com balanceamento de links para alguns pacotes, em conjunto com o iptables, para poder marcar os pacotes que deveriam sair por essa tabela de roteamento. Não entraremos em detalhes sobre o funcionamento do iproute2 e ou aprofundar na tabela mangle, pois isso está além do escopo desse artigo, que tem por finalidade cobrir apenas o básico sobre Firewalls.

Conclusão

Como visto nos capítulos anteriores, a segurança é um item fundamental para qualquer Corporação, pois uma vez conectado à Internet, todo o instante estarão vulneráveis à ataques, expostos à golpes e fraudes de todo o tipo. Conforme apresentado, o objeto de estudo foi o Firewall com a utilização de Iptables e Firewalld. Em ambos estudos, sem exceção, demonstrou ser um recurso de razoável aprendizado e bem intuitivo, que se for desenvolvido, trará sim inúmeros benefícios para a segurança, sobretudo no quesito custo em termos de aquisição, por se tratar de software opensource, ou seja, o seu valor com gastos é completamente nulo. Os objetivos aqui proposto, foram todos atingidos com resultados satisfatórios, tanto a pesquisa como os conceitos de segurança, chegou ao nível desejado de compreensão, atingiu o foco sem ser muito intrínseco e indigesto numa primeira leitura. Além disso cobriu de forma abrangente desde a base de funcionamento das Redes de Computadores, até o correto funcionamento das Regras das Tabelas do filtro de pacotes do kernel do Linux, à cerne do Firewall em estudo. 39

Às lições aprendidas com o Iptables e Firewalld, juntos apresentaram uma curva maior de aprendizagem. No decorrer do desenvolvimento desse artigo, ambos se tornaram em fonte geradora de informação, muito valiosa, não somente para uma rápida referência de comandos shell, mas sobretudo um verdadeiro Guia Explicativo, para não dizer Manuel de Consulta dos jovens aprendizes em Ambiente Linux. E lembre-se: – Tudo seria fácil se não fossem as dificuldades.

Considerações Finais

Figura 15: Chegou a hora de. . . – Levantar acampamento! Hasta La vista baby! O Firewall é um recurso de segurança muito importante que deve ser usado. Não é só o Linux que desfruta de uma boa segurança, mas no geral, os Firewalls estão cada vez mais robustos. Quando olho para trás e lembro do WinXP, as coisas eram bem diferentes, o Firewall dele fazia um bom trabalho de fazer proxy das respostas de entrada (inbound) para solicitações de conexão de saída (outbound) e bloqueava bem as solicitações de conexão de entrada para conversas TCP ou UDP que você não iniciou. Ele bloqueava qualquer tentativa de conexão que você não tenha permitido especificamente nas configurações. No entanto, isso é apenas metade do que um Firewall precisa fazer. Um Firewall também deve monitorar, inspecionar e fazer o proxy das comunicação de saída, e é exatamente aí que o Firewall do XP falhava. Qualquer programa em seu computador pode iniciar qualquer tipo de conexão com qualquer endereço IP na Internet, e o Firewall do Windows ficava passivo e permitia que isso acontecesse. No que me diz respeito, um mecanismo de Firewall que funciona apenas de uma maneira é um falso recurso de segurança, ele não é um Firewall. Graças aos vírus, worms, cavalos de Tróia e uma série de outras pragas, malwares e spywares que chegam ao seu Computador diariamente, você precisa controlar às comunicações de ambas direções.

Firewall do WinXP: ruim com ele pior sem ele. . . Todo computador conectado a qualquer rede (por exemplo naquela época: Dial-UP, Ethernet ou Wifi) precisava de um Firewall, e o do WinXP, simplesmente não estava à altura da tarefa. Nesse caso por exemplo: Ter metade de um Firewall rodando não era melhor de quem não tinha nenhum. Sair desativando o Firewall nas estações XP era algo natural. Mas isso foi em meados de 2006, hoje tudo mudou, o Firewall do Windows mudou! – Só para se ter uma idéia, hoje o Windows 10 possui um Firewall statefull parrudo, isso quer dizer que é super recomendável que você deixe o Firewall dele rodando em todas as Estações da sua Rede. Isso dificultará, dando muito trabalho para o maldito atacante que está do lado de fora da sua rede. Mesmo que você ache isso ridículo, muitos vão achar isso estranho. . . mas eu tenho que dizer assim mesmo: – Não existe Firewall 100% seguro! E às invasões? – elas vão ocorrer mais cedo ou mais tarde, o pior cenário já está desenhado e sempre constará no teu plano de contigência anti-catástrofes. Isto é uma verdade! Quero dizer, não existe soluções prontas e mágicas, nem justifica gastar milhões com Firewalls XYZ, na realidade nós temos que falar menos e Fazer Mais, Construir a Segurança! Ela não vêm pronta, lembra? – e isso não acontece do dia para noite. . . Por favor, não quero puxar sardinha para Microsoft (foi sem querer, querendo. . . ), mas ela é Hoje um bom exemplo a seguir, possui bons Profissionais de Segurança, senão os melhores que eu já conheci.

– “Espero que todos tenham gostado desse artigo que peca por excessos de irônias, mas desejo de coração, desde já, o almejado sucesso à todos vocês”!

Referências [1] Urubatan Neto, Dominando Linux Firewall Iptables, (Editora Ciência Moderna 2004) – ISBN: 85-7393-320-8. [2] Firewalld Website Oficial https://Firewalld.org; Red Hat Server Hardening (RH413) training course http://www.redhat.com/en/services/training/rh413-red-hat-server-hardening Cógigo fonte no GitHub https://github.com/Firewalld/Firewalld; Documentação Oficial https://Firewalld.org/documentation/ [3] LARTC Linux Advanced Routing & Traffic Control Howto http://www.lartc.org/ [4] André Stato Filho 2a edição. Linux: Controle de Redes, (Editora Visual Books 2009) – ISBN: 9788575022443) https://books.google.com.br/books?id=f-iHPgAACAAJ [5] Evi Nemeth, Garth Snyder, Scott Seebass e Trent R. Heinb – 3a Edição. Manual de Administração do Sistema Unix, Adam Boggs, Rob Braun, Dan Crawl, Ned McClain, Lynda McGinley e Todd Miller (Editora Bookman 2002) – ISBN 85-7307-979-7 [6] Dicas simples visando resolver problemas práticos de instalações de aplicativos no GNU/Linux (com Debian), bem como de melhorar o ambiente de trabalho do usuário. https://concani3.wordpress.com/tag/iptables/ [7] Jessica.Payne, Security Person https://aka.ms/jessica https://youtu.be/InPiE0EOArs Demystifying the Windows Firewall [8] Definições e Pesquisas de termos-chaves. Google e Wiki. . . tks! O que seria de nozes sem eles, não?

Segurança em Redes com Firewalld e Iptables

Articles inside

Seguran\u00E7a em Redes com Firewalld e Iptables