Uma das coisas mais chatas acredito quando estamos administrando servidores, é ler logs. Tudo bem, eu sei que é lá que conseguimos descobrir 90% dos problemas que estão acontecendo e também, são as mensagens de erro dos mesmos, que através de documentações ou até, o Pai Google, nos levam a solução do problema.
Em firewalls, a coisa é assim também. Às vezes, temos um tipo de pacote filtrado pelo nosso firewall, sem nem ao menos saber o porque.
Isto acontece, principalmente no mundo Linux, por causa do advento do Shorewall, uma ferramenta de “criação” de regras do Iptables. O Shorewall na realidade, funciona como um framework para criação de firewalls.
Para mim, ele foi um achado. Criar e modificar um script de firewall todas as vezes que se ia fazer um servidor, era um parto. Com o shorewall a coisa já está ali, prontinha e é só atacar e começar a usar.
Tudo bem que eu ainda acho que ele possa ter problemas e ainda, por cima, eu não domino plenamente a ferramenta, mas o Shorewall é sem dúvida talvez um dos projetos mais promissores nesta área atualmente ( até porque, ele já é pacote oficial na maioria das distros … ).
Mas, sempre, há aquele ponto. Ler os logs via tail -f, filtrar com o grep, etc etc etc, que são as ferramentas que temos no mundo *Nix para monitorar nossos servidores.
Na maioria das ferramentas tradicionais, temos interfaces web que nos ajudam nesta parte chata, fornecendo alguma coisa mais amigável para lermos os logs, fugindo um pouco da mesmice de sempre.
Hoje, procurando por uma ferramenta de leitura de logs do iptables via web, descobri a ferramenta Iptables Log Analyser, que parece resolver o problema.
<a href=“https://cybernetus.com/wp-content/uploads/2015/09/iptablesloganalyser01102007.gif" data-rel=“lightbox-image-0” data-rl_title=”" data-rl_caption="" title="">
Pelo que diz a página inicial do projeto, ele mostra os logs do NetFilter do kernel 2.4.x, que literalmente, tem a mesma estrutura dos kernel atuais, da série 2.6.x. Assim, a ferramenta ainda se mantém bem atual, e pode ser usada em qualquer estrutura …
Bom, teoricamente sim. Mas ao mesmo tempo não. O que temos nesta ferramenta é um “segundo” repositório de logs. Ou seja, tal qual o IDS SNORT, que tem ao opção de guardar os logs em um MYSQL, você na realidade, estará fazendo isto com os logs do iptables.
Assim, todos os seus logs do iptables estarão replicados em uma base de dados do mysql.
E, assim, você terá um aumento considerável de I/O em disco, que não aconteceria em um firewall tradicional onde o consumo de hardware é praticamente irrisório.
Há uma outra solução. Retirar-se o MySQL de dentro da máquina e replicar os logs para outra máquina, por exemplo, um servidor de Banco de Dados.
Aí teríamos que levar em consideração um aumento considerável de pacotes para uma máquina da rede e uma possível saturação de tráfego em algum segmento específico da rede.
Ou seja, na realidade, apesar de ser uma solução muito legal, ao mesmo tempo necessita por parte do Analista que está a implementando, muita, mais muita análise mesmo 🙂
Agora, vamos aos pontos. Como instalar nosso amiguinho, que talvez seja o que se está esperando após ler esta intensa explanação sobre o que deve ser feito ou não para implementar esta solução :
Primeiro, vamos ao MySQL :
# mysql -u root -p
_ mysql > create database iptables_
_ mysql > grant create,select,insert on iptables. to iptables_admin@localhost identified by ‘xx’;*_
_ mysql > grant select on iptables. to iptables_user@localhost identified by ‘xx’;*_
_ mysql > grant create temporary tables on iptables. iptables_user@localhost identified by ‘xx’;*_
# mysql -u root -p iptables < sql/db.sql
Instale a interface web :
# cp -R web /var/www/iptables
E finalmente, passe aos wrappers de log ( levando em consideração somente as configurações para o shorewall e para o iptables-log comum ), que no caso aqui são os feed-db.pl e feed-db-shorewall.pl ( há um para o SuSe-Firewall, mas sinceramente, como não uso SuSE em casa, nem vou levar ele em consideração ):
my $dsn = ‘DBI:mysql:iptables:localhost’;
my $db_user_name = ‘iptables_admin’;
my $db_password = ‘xxxx’;
my $log_file = ‘/var/log/messages’;
my $pid_file = “/var/run/iptablelog.pid”
A linha em negrito, é a linha onde o seu firewall grava os logs. A maioria grava direto no messages, mas em alguns casos ( com edição do syslog-ng e syslog comum ), você pode jogar os logs do iptables para um arquivo específico.
Feito isto, é só finalmente subir o wrapper e se divertir com o que está acontecendo.
Um porém deste projeto é : ele parece estar um pouquinho “abandonado”. Não vi grandes movimentações no mesmo pelo menos no SourceForge, o que é, e não é um problema.
É porque você não tem suporte oficial, e não é, porque, sendo Perl e PHP, qualquer um pode pegar e editar os arquivos, sem qualquer problema aparente.
Portanto, agora vamos ao famoso sript de inicialização do bichinho.
# mv feed_db-shorewall.pl /etc/rc.d/rc.iptableslog
# chmod 755 /etc/rc.d/rc.iptableslog
E editamos o /etc/rc.d/rc.local e adicionamos :
if [ -x /etc/rc.d/rc.iptableslog ]; then
. /etc/rc.d/rc.iptableslog
fi
E, finalmente, subimos o serviço com :
# /etc/rc.d/rc.iptableslog start
Até o momento ele atendeu razoavamente bem …. resta saber se com o tempo ele não vai me apresentar nenhum bug crítico 🙂 Mas nada que uma nerdadazinha não resolva 🙂