O Linux é um sistema operacional que oferece mecanismos de segurança diferenciados e bastante flexíveis – de gerência de recursos internos até especificação granular de regras de acesso.
Por padrão, o controle de acesso de usuários, no sistema de arquivos do Linux, segue uma “lógica matemática de conjuntos” (usuários, grupos e outros), mas nada impede a adoção de ACLs para ajustes mais granulares, com a utilização dos comandos getfacl (verifica) e setfacl (aplica). Vale lembrar que existem controles ainda mais avançados…
Em uma instalação “servidor”, normalmente, o acesso aos dados de dispositivos externos depende da montagem manual do dispositivo. Além disto, uma partição pode ser montada com restrições como noexec (nega a execução de binários) ou nosuid (ignora a permissão suid bit), por exemplo. Existe ainda a possibilidade de trabalhar com o MAC (Controle de Acesso Mandatório), como SELinux, Apparmor ou GrSecurity. Porém, a adoção do MAC costuma ser evitada porque a complexidade de gerência aumenta consideravelmente (é extremamente granular). Trata-se de uma configuração mais indicada para servidores que disponibilizam serviços sensíveis e de acesso público (ftp e web, por exemplo).
Em relação aos controles de rede, existe uma infinidade de possibilidades. A execução de ataques de synflood, por exemplo, é simples e pode ser danosa se o firewall não prever este tipo de ataque – levando, algumas vezes, ao envenenamento da tabela de estados. Este tipo de ataque pode ser contido com a ativação do recurso tcp_syncookies e SYNPROXY. São recursos que tenho ativado em soluções de IPS e o resultado tem sido impressionante. Acreditem ou não, foi assim que consegui impedir o envenenamento da tabela de estados de um firewall Aker (colocando um IPS Linux na frente, ativando o SYNPROXY). Há alguns anos, houve uma falha de kernel que desencorajava a ativação do tcp_syncookie, mas não se aplica as versões mais atuais (faz tempo). Este assunto será tratado ao longo do tempo.
Desde o kernel 2.4, a infraestrutura de firewall do Linux é conhecida como netfilter. O iptables é uma ferramenta administrativa que interage com esta infraestrutura e estabelece as regras de acesso aos recursos de rede. Porém, a partir da versão 3.13 (aproximadamente – não sei ao certo) esta infraestrutura vem sofrendo alterações e otimizações, para dar entrada a uma nova ferramenta conhecida como nftables. Não se assuste, muita coisa já mudou. Se você usa o iptables, no Ubuntu 16.04, saiba que já está trabalhando em modo de compatibilidade. Não é mais uma opção, comece a estudar o nftables desde já.
Em relação as opções de filtragem (pacotes), há uma infinidade de recursos. É possível filtrar uma string no payload (extensão string), identificar o país de origem (geoip), aplicar limites de pacotes por IP (hashlimit) ou conexão (connlimit), identificar o tipo de aplicação (ndpi) ou enviar um fluxo de pacotes para uma fila que será inspecionada e controlada por uma aplicação específica (IPS Suricata ou Snort em modo inline, por exemplo). Tudo isto oferece uma flexibilidade gigantesca. Basta saber como explorar. A identificação de uma string no payload, por exemplo, nos permite filtrar consultas de DNS diretamente – algo que implementei no projeto FwGuardian.
Aguardem, há muito por vir! 😉