sexta-feira, 9 de novembro de 2012

Logwatch - Enviando relatórios via e-mail


Introdução e Preparação


Esse artigo foi escrito com o objetivo de apresentar o Logwatch em conjunto com Mutt, como uma forma muito eficaz de manter-se informado acerca das atividades do sistema, através do envio de relatórios por e-mail.

A princípio, precisamos apenas de um e-mail server básico e um cliente de e-mail básico rodando na máquina, para que possamos deixar tudo funcionando.

A noção da importância de se monitorar servidores e serviços, motivou o desenvolvimento deste artigo.

Espero que este texto ajude de alguma forma, toda a comunidade, seja estudante ou sysadmin.

Preparando o sistema

Antes de qualquer coisa, precisamos deixar o servidor de e-mail e o cliente de e-mail configurados de forma correta. Para isso, usei como referência o artigo do Raimundo Alves Portela, o rai3mb da comunidade VOL.

Em resumo, vamos instalar os cliente e o servidor de e-mail:

# apt-get install postfix mutt

Durante a configuração do pacote do Postfix, quando ele configura as opções gerais de funcionamento e tipo de servidor, escolha a opção "No configuration", ou "sem configuração". Isto é feito para que tenhamos apenas o serviço rodando, sem uma configuração específica e possamos usar um e-mail de terceiros, no meu caso, o GMail.

Apos a instalação do Postfix e do Mutt, é necessário criar um arquivo com as configurações de acesso ao servidor de e-mail, que usaremos para mandar as mensagens:

# nano ~/muttrc

Insira:

# Nome do Remetente
set realname="Servidor de intranet - Matriz Empresa do Mané"

# Email do Remetente
set from="emp.do.mane@gmail.com;"

# Usuario da conta de email
set my_user=emp.do.mane@gmail.com

# Senha da conta de email
set my_pass='SENHA_FACIL'

# Autenticacao no servidor smtp de email, nesse caso do gmail.com
set smtp_url=smtps://$my_user:$my_pass@smtp.gmail.com

# Camada de segurança, requerida pelo gmail.com
set ssl_force_tls = yes

# Referencia:
# http:// www.vivaolinux.com.br/artigo/Enviar-email-pelo-terminal-com-mutt/?pagina=1


Feito isso, teremos o nosso servidor pronto para o envio de e-mails. 

Logwatch, o agente gerador de log

Logwatch é um sistema de análise de logs customizável, que age acessando os logs do sistema criando um report das áreas especificadas no arquivo de configuração. 

O Logwatch é muito simples, de fácil instalação e configuração, rodando na maioria dos sistemas Unix-like. 

Site oficial:
Para instalá-lo, use: 

# apt-get install logwatch 

Teste seu funcionamento emitindo o comando logwatch no terminal: 

# logwatch 

Se tudo tiver certo, ele vai gerar um relatório extraindo informações dos logs do seu sistema. 

Enviando logs por e-mail

Analisar logs é uma tarefa que precisa ser vista e praticada pelos sysadmins como algo crucial, uma vez que através dela, podemos identificar ou corrigir problemas antes dos mesmos tomarem proporções que dificultem ou impossibilitem um reparo do erro. 

Muitas vezes, por falta de tempo ou a falta de experiência do sysadmin em analisar cada log, esta tarefa é colocada em último plano, um erro grave. 

Pensando nisso, escrevi o script a seguir para automatizar o envio por e-mail dos logs gerados pelo Logwatch, trazendo praticidade à tarefa de analise de logs. 

Segue abaixo, a ultima peça do nosso canivete suíço, o script que gera o log e o envia por e-mail: 

#!/bin/sh
# Script para envio dos logs do sistema de forma periódica e automática.
# Desenvolvido em Shell script.
# Autor: Alex Sandro Silva
# Twitter: @alexhctp
# Email: alexhctp[at]hotmail[dot]com - alexhctp[at]gmail[dot]com

# CONFIGURACOES LOCAIS

LOGGEN='/usr/sbin/logwatch'
MAIL='/usr/bin/mutt'
LOGDIR='/tmp/logs/'
MAIL='/usr/bin/mutt'
# DATE=`date +%y%m%d`
DATE=`date +%Y-%m-%d`
HOME='/root/'
# MENSAGEM=/root/mensagem.txt #aprendendo uma forma de dar um echo buscando o conteúdo de um arquivo de texto, se alguem souber, conta ae, rsrs

if [ -d $LOGDIR ]
     then
     rm -r $LOGDIR
exit 0
elif [ -d $HOME  ]
     then
     mkdir $LOGDIR

     $LOGGEN > $LOGDIR/log_$DATE.log
     echo 'Logs e estatisticas enviadas automaticamente ao sysadmin' | $MAIL -s 'Estatisticas e Logs diarios - NOME DA FILIAL'  -a $LOGDIR\log* -- ti@seuemail.com

     rm -R $LOGDIR

exit 0
fi


Sintam-se à vontade para mudar, sugerir melhorias ou correções no script. 

Automatizando o processo com o Cron

Para terminar, agendamos uma tarefa com o Cron para que todos os dias um log seja enviado ao sysadmin. Para isso, edite o Crontab adicionando a entrada a seguir: 

# nano /etc/crontab 

Insira: 

# Envio de automatico de logs do sistema por email
59  23    * * *    root    /root/sendMail.sh


Pronto... agora é só criar o vício de analisar os seus relatórios do sistema, uma vez que a falta de tempo, não mais será desculpa para deixar de fazê-lo. 

Espero ter ajudado. 

Comentários com criticas e sugestões são bem-vindos. 

Abraço a todos. ;) 

Referências

Artigo publicado anteriormente por mim no Viva o Linux
http://www.vivaolinux.com.br/artigo/Logwatch-Enviando-relatorios-via-email/?pagina=2

domingo, 15 de julho de 2012

Habilitando IPv6 e alguns macetes úteis no Debian.

Recentemente precisei implantar/habilitar o protocolo IPv6 em um cliente e como se tratava de algo novo, passei por algumas dificuldades. Para dar conta do recado, realizei varias pesquisas, cujo resultado compartilho nesse post. Não me aprofundarei em tópicos como o que é e como o IPv6 funciona, o objetivo desse post é apresentar um norte para o estudante ou profissional de TI/Redes que já tem uma noção básica do que se trata esse protocolo.
Para começar os estudos, acessei o site brasileiro http://ipv6.br/, mantido pelo http://www.ceptro.br/ (Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações), onde todas as informações necessárias para começar a se aventurar pelo protocolo em questão estão disponíveis. Tópicos como endereçamento, cabeçalho e funcionalidades são abordados nos mínimos detalhes. Acesse e aproveite ;)
Uma vez ciente sobre todo o funcionamento do protocolo IPv6, é hora de habilita-lo no seu servidor, mas para isso, é necessário verificar se seu ISP já provê e da suporte a esse protocolo. Para testar, habilite o protocolo IPv6 em seu sistema nas propriedades de rede. Para checar se seu sistema esta apto a receber IPv6, de o seguinte comando em uma janela do terminal:

Linux
ping6 -c5 ::1

O resultado deve ser similar ao do ping normal, com tempo de respostas e estatísticas positivas ao final do teste.


No servidor linux executei os seguintes
Enfim, uma vez checado se o suporte a IPv6 já esta habilitado, basta seguir para as próximas etapas. Caso seu server Linux ainda não tem suporte ao protocolo, basta entrar com os comandos a seguir no terminal:
Habilitar suporte ao IPv6 no kernel:

# modprobe ipv6

Se você esbarrar em algum erro durante esse processo, certamente você precisará recompilar o seu kernel. No link a seguir você encontrará mais detalhes sobre parâmetros para recompilar o seu kernel: http://mirrors.deepspace6.net/Linux+IPv6-HOWTO-pt_BR/systemcheck-kernel.html

Caso a sua distro já suporta IPv6, basta editar o arquivo /etc/modprobe.d/aliases adicionando a seguinte linha ao final do texto:
alias net-PF-10 ipv6

Se por algum motivo precisar desabilitar o IPv6 no futuro, basta editar o mesmo /etc/modprobe.d/aliases e mudar o parâmetro que adicionamos ao final do texto conforme o descrito a seguir:
alias net-PF-10 off

Feito isso, o seu server já possui suporte ao IPv6 e para confirmar, realizaremos novamente o teste do ping como descrevi anteriormente, "ping6 -c5 ::1".

Fecharemos a etapa de configurações básicas do protocolo tornando permanente as alterações feitas. Para isso, edite o arquivo /etc/network/interfaces e deixe-o conforme o apresentado no exemplo abaixo:

iface ethx inet6 static
       pre-up modprobe ipv6
       address 'endereço IPv6'
       netmask 64
       gateway 'endereço IPv6 do gateway'
Onde ethx equivale a interface de rede que recebera o IPv6.


Por hora é isso, em breve vou incrementar o assunto IPv6 com novos posts. Devido a falta de tempo, vou disponibilizar o material que usei para escrever esse pocket tutorial e deixar como base para as suas próprias pesquisas.


Referencias usadas no tutorial:
http://ipv6.br/
http://mirrors.deepspace6.net/Linux+IPv6-HOWTO-pt_BR/systemcheck-kernel.html

Material de apoio para estudos complementares e tópicos avançados:
http://www.rjsystems.nl/en/2100-dhcpv6-stateful-autocfg.php
http://madduck.net/docs/ipv6/

Ferramentas avançadas para segurança e auditoria em redes IPv6:
http://ipv6securitylab.org/ipv6toolbox.html

segunda-feira, 30 de janeiro de 2012

SqStat - Monitorando logs do Squid em tempo real!!!


Oi pessoal,

Essa dica é pra quem assim como eu gosta de montar seus servidores do zero, instalando os serviços que vai precisar de acordo com a demanda exigida.
Geralmente, nos proxyes rodando Squid usamos os Sarg para gerar relatórios, porém é muito incomodo (pra não dizer chato) ficar gerando e analisando os relatorios.
A ferramenta SqStat é um script PHP que acessa os logs do Squid e gera EM TEMPO REAL uma listagem dos sites que estão sendo acessados pelos hosts da rede naquele instante.
Uma das maiores vantagens dessa ferramenta é que com ela conseguimos analisar o trafego na rede, detectando quais usuarios estao consumindo mais banda atraves do protocolo HTTP e HTTPS.
Agora vamos deixar de lero lero e vamos ao que interessa... Mão na Massa!!!

Requisitos necessarios:
  1. PHP 4.1 ou superior
  2. Proxy rodando Squid


Download
  1. Linux - http://samm.kiev.ua/sqstat/sqstat-1.20.tar.gz
  2. FreeBSD - http://www.freshports.org/www/sqstat

Instalando....
  • Descompacte o pack na raiz do seu webserver...

  • Faça uma copia do arquivo config.inc.php.defaults mudando o nome da copia para config.inc.php, edite o arquivo config.inc.php com o vi, vim, nano ou qualquer outro editor da sua preferencia para setar o endereço do seu servidor proxy rodando squid e a sua porta de atuação.

  • Edite o squid.conf adicionando as seguintes linhas
acl manager proto cache_object
# substitua 10.0.0.1 pelo ip do seu webserver...
acl webserver src 10.0.0.1/255.255.255.255
http_access allow manager webserver
http_access deny manager

  • Pra finalizar, basta acessar o seu webserver pelo browser e chamar pela pagina sqstat.php (ex.: http://seu.ip.da.rede/sqstat.php)

Bibliografia:

quarta-feira, 22 de dezembro de 2010

Evitando a perda de dados - Backup via rede com DD e Netcat


Caro leitor, vou mostrar nesse pequeno tutorial uma forma simples e rapidada de fazer backup (clone ou imagem em arquivo) de um hd onde rode um sistema linux. O diferencial desse tutorial é que o backup é feito pela rede...
Vale lembrar que o backup é um topico importante no que se diz respeito a segurança da informação, e a empresa sempre deve ter uma politica bem definida com relação a isso.
Dentre as vantagens que o backup traz consigo é a certeza de que os dados estarão disponiveis e seguros em outras midias (de preferencia externa e longe do local onde a base de dados esta instala) para poderem ser restauradas caso ocorra qualquer avaria na base de dados principal, seja ela proveniente de erros de hardware ou software.

Com base nessas premissas, demosntrarei em um passo a passo como configurar um backup de forma segura e confiavel por meio de rede (LAN).

=> PRIMEIRO PASSO (CONFIGURAÇÃO NA MAQUINA DE DESTINO)
Verificar se o netcat esta instalado em sua estação ou servidor. Caso nao esteja instalado, use o apt para instala-lo:

apt-get install nc

Outra coisa importante é escolher uma porta para configurar o nosso backup la no computador de destino... no link http://www.gamboas.com.br/Scripts/portas.asp tem uma lista com as portas TCP e UDP que podem ser usadas, no nosso caso tem que ser TCP no protocolo...

Configurando o netcat para escutar na porta 15 - # nc -l -p | dd of = /dev/sda (levando em consideração que o disco rígido é sda ao inves de hda):

# nc -l -p 15 | dd of=/dev/sda
=> SEGUNDO PASSO (CONFIGURAÇÃO NA MAQUINA DE ORIGEM)
Enviando o conteúdo do disco para o PC de destino - "# dd if = /dev/sda | nc "

# dd if=/dev/sda | nc 192.168.0.253:15

=> TERCEIRO PASSO
Na maquina de Origem, abriremos um novo shell, no caso do Debian basta apertar ALT+ (->) ou ALT + F2. Nessa nova sessão que abrimos, vamos gerar os dados TCP na placa de rede, aqui na minha rede é a eth1:

tcpdump -tnli eth1 port 15

Uma outra opção, é criar apenas uma "imagem" do hd, que podemos restaurar sempre que necessário através do arquivo gerado no processo, mudando apenas o caminho:

# nc -l -p 15 | dd of=backupsda.img

Vale lembrar que como no caso do uso do dd localmente, (clone de um hd para outro na mesma maquina) a regra sobre o tamanho do hd destino ser do mesmo tamanho ou maior que a origem continua vigorando, uma vez que o dd copia bit a bit, na mesma sequência e posicionamento no disco.

Ta aí a dica, espero ter ajudado... em complemento a dica, cabe ao administrador de redes e sistemas definir a frequência em que esse backup será realizado, podendo ser automatizado por rotinas de shell script, que pode vir a ser o tema de um futuro post, dependendo do retorno dos leitores.

Referencial teórico:
http://www.forum-invaders.com.br/vb/showthread.php/12164-Netcat
http://www.howtoforge.com/ghosting-the-machine
http://www.gamboas.com.br/Scripts/portas.asp
http://www.vivaolinux.com.br/topico/Iniciantes-no-Linux/Comando-dd

domingo, 19 de dezembro de 2010

Previna ataques de BruteForce em servidores Debian


Olá,

Hoje eu venho compartilhar um pouco de conhecimento.

Meu objetivo com essa postagem é mostar como evitar ataques de Brute Force (força bruta) em serviços como SSH e FTP que usam os arquivos
contidos em
/etc/hosts.allow ou /etc/hosts.deny e serviços que nao usam TCP_WRAPPERS, como o pacote ProFTPd do Debian.
Os demais serviços que nao usam /etc/hosts.allow ou /etc/hosts.deny nao serao tratados pois podem ser bloqueados com o iptables.

Presumo que o OpenSSH e o ProFTPd estao devidamente instalados e rodando no seu sistema.

=> PRIMEIRO PASSO
Instalar o Pyton, pois o BlockHosts é escrito nessa linguagem.

aptitude install python

Depois de instalar o Pyton, vamos baixar com os seguintes comandos:

wget http://www.aczoom.com/tools/blockhosts/BlockHosts-2.5.0.tar.gz tar xvfz BlockHosts-2.5.0.tar.gz cd BlockHosts-2.5.0
Para instalar o BlockHosts, use:

python setup.py install --force

Depois de instalado, edite o /etc/clockhosts.cfg e modifique como o exemplo a seguir:

nano /etc/blockhosts.cfg

[...]
HOSTS_BLOCKFILE = "/etc/hosts.allow"
[...]
HOST_BLOCKLINE = ["ALL: ", " : deny"]
[...]
COUNT_THRESHOLD = 3
[...]
AGE_THRESHOLD = 12
[...]
LOGFILES = [ "/var/log/auth.log", "/var/log/proftpd/proftpd.log", ]
[...]
MAIL = True
[...]
NOTIFY_ADDRESS = 'root@localhost.localdomain'
[...]
SMTP_SERVER = "localhost"
SENDER_ADDRESS = 'BlockHosts '
[...]
IPBLOCK = "iptables"
[...]



No HOSTS_BLOCKFILE podemos expecificar /etc/hosts.allow ou /etc/hosts.deny. No meu caso eu escolhi o /etc/hosts.allow, mas fique a vontade para escolher entre ambos. Na linha LOGFILES, indicamos o arquivo de log que o BlockHosts deve buscar. No caso do OpenSSH, os logs de falha de Login ficam em /var/log/auth.log e os logs do ProFTPd ficam em /var/log/proftpd/proftpd.log. O COUNT_THRESHOLD seta o numero de tentativas erradas durante o login vindas de um mesmo host e que o BlockHosts deve bloquea-los. Em AGE_THRESHOLD configuramos quanto tempo depois de bloqueados os hosts serao liberados. IPBLOCK especifica se usaremos o iptables (usado nesse tutorial) ou o iproute e adicionando estes hosts em /etc/hosts.allow ou em /etc/hosts.deny, dependendo da sua escolha. Lembre-se, eu utilizei o /etc/hosts.allow. Para editar o nosso /etc/hosts.allow ou /etc/hosts.deny, dependendo da sua escolha, faça um backup do mesmo. Edite apenas o arquivo que escolheu no inicio das configuraçoes. No meu caso copiei o /etc/hosts.allow.
mv /etc/hosts.allow /etc/hosts.allow_orig
Crie um novoo /etc/hosts.allow com o comando abaixo:
nano /etc/hosts.allow
Copiar o conteudo abaixo para o novo arquivo /etc/hosts.allow
# # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # ---- # see "man 5 hosts_access" for details of the format of IP addresses, #services, allow/deny options. Also see "man hosts_options" # # permanent whitelist addresses - this should always be allowed access ALL: 127.0.0.1 : allow # ALL: 192.168.0. : allow # permanent blacklist addresses - this should always be denied access # ALL: 10. : deny # ---------------------------------------- # next section is the blockhosts section - it will add/delete entries in # between the two marker lines (#---- BlockHosts Additions) #---- BlockHosts Additions #---- BlockHosts Additions # ---------------------------------------- # finally, the command to execute the blockhosts script, based on # connection to particular service or services: sshd: ALL: spawn /usr/bin/blockhosts.py --verbose --mail --iptables \ --echo "%c-%s" --check-ip "%h" >> /var/log/blockhosts.log 2>&1 & \ : allow #--- # add --iproute to enable null-routing, or add --iptables to enable packet # filtering, which blocks all network communication from blocked hosts #--- # remove >> /var/log/blockhosts.log 2>&1 if no logging to blockhosts.log # is needed - without this, it will still log to syslog (minimally) #sshd: ALL: spawn /usr/bin/blockhosts.py --verbose --echo "%c-%s" & : allow #--- # above commands will use default config file - /etc/blockhosts.cfg, edit # it as needed to specify local configuration options # See "man hosts.allow" for info on %c and %s identifiers # for non-verbose, with identification, to syslog only (/var/log/messages), # triggered on any service (using ALL as first word): #ALL: ALL: spawn /usr/bin/blockhosts.py --echo "%c-%s" & : allow #---- # To test hosts.allow, and to find out exact names of SSH/FTP services, # add this line to the beginning of hosts.allow, use ssh/ftp to connect # to your server, and then look at the log (/var/log/messages or # blockhosts.log) to see the name of the invoked service. # IMPORTANT: after your test is done, remove this line from hosts.allow! # Otherwise everyone will always have access. #ALL : ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow # -------------------------------------------------------------------------

Entendendo o arquivo e editando as regras: Na primeira seçao, insira o IP dos hosts que vc quer liberar (whitelist), 127.0.0.1 por exemplo. Podemos liberar os ips de uma sub-rede, para isso, devemos descomentar a linha # ALL: 192.168.0. : allow e adicionar duas linhas, onde serao adicionados os os hosts ou ips bloqueados:

#---- BlockHosts Additions #---- BlockHosts Additions

A seguir mostrarei uma etapa muito importante, com ela, sempre que alguém tenta fazer login usando o SSH, /usr/bin/blockhosts.py é iniciado, verifica os arquivos de log do /etc/blockhosts.cfg, e bloqueia todos os hosts com tentativas de login exedidas no COUNT_THRESHOLD , adicionando o arquivo /etc/hosts.allow e usando o resultado com o iptables que impedem esses ips ou hosts acessarem o sistema). Todas as ações serão registradas em /var/log/blockhosts.log. Nessa etapa, iniciaremos o BlockHosts com a opçao dry-run, com isso podemos analizar se aconteceu algum erro na configuraçao. Usa-se o seguinte comando:
blockhosts.py --dry-run --verbose
O sistema deve retornar um resultado como o que se segue:
server1:/tmp/BlockHosts-2.5.0# blockhosts.py --dry-run --verbose
blockhosts 2.5.0 started: 2010-08-18 14:16:56 CEST
... loaded /etc/hosts.allow, starting counts: blocked 0, watched 0
no logoffsets found, will read from beginning in logfile: /var/log/auth.log
... loading log file /var/log/auth.log, offset: 0
no logoffsets found, will read from beginning in logfile: /var/log/proftpd/proftpd.log
... loading log file /var/log/proftpd/proftpd.log, offset: 0
... discarding all host entries older than 2010-08-18 02:16:56 CEST
... final counts: blocked 0, watched 1
#---- BlockHosts Additions
#bh: ip: 192.168.0.2 : 1 : 2010-08-18 14:16:56 CEST

#bh: logfile: /var/log/auth.log
#bh: offset: 6763
#bh: first line:Feb 16 13:22:10 server1 login[1992]: pam_unix(login:session): session opened for user root by (uid=0)

#bh: logfile: /var/log/proftpd/proftpd.log
#bh: offset: 884
#bh: first line:Feb 16 14:59:18 server1.example.com proftpd[13157] server1.example.com:
ProFTPD 1.3.1 (stable) (built Fri Feb 6 12:26:25 GMT 2009) standalone mode STARTUP

#---- BlockHosts Additions

# ----------------------------------------
# finally, the command to execute the blockhosts script, based on
# connection to particular service or services:

sshd: ALL: spawn /usr/bin/blockhosts.py --verbose --mail --iptables \
--echo "%c-%s" --check-ip "%h" >> /var/log/blockhosts.log 2>&1 & \
: allow

#---
# add --iproute to enable null-routing, or add --iptables to enable packet
# filtering, which blocks all network communication from blocked hosts
#---
# remove >> /var/log/blockhosts.log 2>&1 if no logging to blockhosts.log
# is needed - without this, it will still log to syslog (minimally)
#sshd: ALL: spawn /usr/bin/blockhosts.py --verbose --echo "%c-%s" & : allow
#---
# above commands will use default config file - /etc/blockhosts.cfg, edit
# it as needed to specify local configuration options

# See "man hosts.allow" for info on %c and %s identifiers

# for non-verbose, with identification, to syslog only (/var/log/messages),
# triggered on any service (using ALL as first word):
#ALL: ALL: spawn /usr/bin/blockhosts.py --echo "%c-%s" & : allow
#----
# To test hosts.allow, and to find out exact names of SSH/FTP services,
# add this line to the beginning of hosts.allow, use ssh/ftp to connect
# to your server, and then look at the log (/var/log/messages or
# blockhosts.log) to see the name of the invoked service.
# IMPORTANT: after your test is done, remove this line from hosts.allow!
# Otherwise everyone will always have access.
#ALL : ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

# -------------------------------------------------------------------------
Commands (tentative) to run for IPTables filtering:
... created user-defined chain blockhosts
... creating jump from INPUT to blockhosts chain
... creating jump from FORWARD to blockhosts chain
... no email to send.
server1:/tmp/BlockHosts-2.5.0#


Se tudo estiver Ok, sem erros e nada pendente, estamos prontos para executar o BlockHosts sem a opçao --dry-run.
blockhosts.py --verbose

O resultado sera parecido com o que se segue:

server1:/tmp/BlockHosts-2.5.0# blockhosts.py --verbose
blockhosts 2.5.0 started: 2010-08-18 14:20:20 CEST
... loaded /etc/hosts.allow, starting counts: blocked 0, watched 0
no logoffsets found, will read from beginning in logfile: /var/log/auth.log
... loading log file /var/log/auth.log, offset: 0
no logoffsets found, will read from beginning in logfile: /var/log/proftpd/proftpd.log
... loading log file /var/log/proftpd/proftpd.log, offset: 0
... discarding all host entries older than 2010-08-18 02:20:20 CEST
... final counts: blocked 0, watched 1
... created user-defined chain blockhosts
... creating jump from INPUT to blockhosts chain
... creating jump from FORWARD to blockhosts chain
... no email to send.
server1:/tmp/BlockHosts-2.5.0#

Nesse ponto, o sistema ja esta parcialmente protegido, uma vez que o BlockHosts nao esta configurado para analizar logins falhos no ProFTPd pois o mesmo não é um serviço TCP_WRAPPERS. Resolvemos esse problemas usando uma rotina no cron, que starta o BlockHosts a cada 5 minutos, por exemplo.

=> SEGUNDO PASSO
Criando um job no Cron para serviços não TCP_WRAPPERS. Para bloquear os ips ou hosts qua nao usam serviços TCP_WRAPPERS como o ProFTPd no Debian, use o seguinte comando:
blockhosts.py --ipblock=iptables --verbose

Deve-se criar um script para automatizar essa tarefa em /usr/bin/blockhosts.py.
nano /usr/bin/blockhosts.py
Adicione o conteudo abaixo:

#!/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /usr/bin/blockhosts.py --ipblock=iptables --verbose >> /var/log/blockhosts.log 2>&1

Esse script tem o proposito de passar o PATH (caminho) correto para o script /usr/bin/blockhosts.py, pois se usa-lo diretamente no cron job, nos deparamos com erros como iptables nao encontrado. Adicione privilegio de execuçao ao script:
chmod 700 /usr/local/sbin/blockhosts

Criando uma tarefa no cron com o cmando a seguir:

crontab -e

Adicione a tarefa a abaixo:
*/5 * * * * /usr/local/sbin/blockhosts &> /dev/null

=> TERCEIRO PASSO
Testando Para ver se esta tudo ok e o BlockHosts esta funcionando, tente logar no servidor usando SSH e FTP com um usuario e senha errados. Depois de algumas tentativas erradas, o servidor devera refugar, o que significa que seu ip foi bloqueado. Para acessar o servidor, deve-se alterar o ip do cliente e tentar acessar o servidor novamente, com login correto e executar iptables -L observar que o . Voce poderaip do possivel atacante foi "dropado" (rejeitado)
server1:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
blockhosts all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
blockhosts all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain blockhosts (2 references)
target prot opt source destination
DROP all -- IP DO POSSIVEL ATACANTE anywhere
server1:~#

Agora observe em /etc/hosts.allow que o mesmo endereço ip esta listado na seçao #---- BlockHosts Additions:
nano /etc/hosts.allow
o resultado...

[...]
#---- BlockHosts Additions
ALL: 192.168.0.199 : deny
#bh: ip: 192.168.0.199 : 24 : 2010-08-18 14:37:53 CEST
#bh: ip: 192.168.0.2 : 1 : 2010-08-18 14:20:20 CEST
#bh: logfile: /var/log/auth.log
#bh: offset: 7619
#bh: first line:Feb 16 13:22:10 server1 login[1992]: pam_unix(login:session): session opened for user root byuid=0)
#bh: logfile: /var/log/proftpd/proftpd.log
#bh: offset: 8588
#bh: first line:Feb 16 14:59:18 server1.example.com proftpd[13157] server1.example.com: ProFTPD 1.3.1 (stable) (built Fri Feb 6 12:26:25 GMT 2009) standalone mode STARTUP
#---- BlockHosts Additions
[...]
(


Para finalizar, podemos observar tambem /var/log/blockhosts.log:

tail /var/log/blockhosts.log

server1:~# tail /var/log/blockhosts.log
... discarding all host entries older than 2010-08-18 02:40:02 CEST
... final counts: blocked 1, watched 2
... no email to send.
blockhosts 2.5.0 started: 2010-08-18 14:45:01 CEST
... loaded /etc/hosts.allow, starting counts: blocked 1, watched 2
... loading log file /var/log/auth.log, offset: 7619
... loading log file /var/log/proftpd/proftpd.log, offset: 8588
... discarding all host entries older than 2010-08-18 02:45:01 CEST
... final counts: blocked 1, watched 2
... no email to send.
server1:~#


Ok, tudo pronto e funcionando... considere-se com uma proteço anti-BruteForce

Referencial: