Re: [ipqbdb-users] Is ipqbdb this still being maintained?

[Alessandro Vesely]

On 01/Feb/11 09:17, Didar Hossain wrote:
>> Perhaps number of packets by rule would give more insight?  It is
>> tough to discriminate distributed attacks from random attacks
>> from unrelated sources...  Any idea?
> 
> I am sorry, but, how will looking at packet counts, either allowed/blocked
> help? I am not able to understand this part.

There are three classes of settings that concur in securing a system
this way: iptables rules, bad behavior sensors, and ipqbdb parameters.

Iptables rules can be set up in very many different ways, including
automated rule generators.  At the end of the day some services have
been reachable for some IPs, some have been blocked.  Unusual numbers
of allowed/blocked packets may indicate that something behaved badly,
or that attacks have been unusually strong.  Both reasons may prompt
for taking a closer look at the relevant services' logs.

> I currently look at the failed auth attempts in /var/log/auth.log
> (on a Ubuntu system) to figure out which accounts as in "usernames"
> are being used for brute forcing and then I check that the
> passwords are sufficiently strong. I had the system broken into
> twice because of weak passwords.

Parsing auth.log should nail the offending IP addresses.  This is part
of the bad behavior sensors.  I block all services, but more complex
servers may need to still allow some service for some kind of offense.
 There is an "ibd-del --stats" that lists active sensors.
Some more meaningful logging here might be helpful.

The thirs class, ipqbdb parameters, consist of the initial count and
the decay.  An initial count of 3 will set a blocking probability of
33.3% for an invalid password, for example.  After 3 attempts in a row
the IP is blocked with 100% probability.  Then, a decay of 120 will
allow the IP a 50% probability to connect after two minutes.
For passwords, this is usually low enough to avoid users' phone calls.
 For other services, e.g. receiving email for local spamtraps, a decay
of a couple of days may seem more fit, but what data do I need to
confirm it?

> Sorry for making this mail so long winded.

There's nothing to be sorry about.  I thank you for your interest, and
for giving me an occasion to review how this thing works.

Ciao
Ale