Re: [Sshguard-users] 60 danger in 4 attacks over 1 seconds (all: 120d in 2 abuses over 15625s).

[Mij <mi...@ss...>]

Hi Jo,

> Bug 1: seconds counting is broken
> 
> Feb  6 22:32:26 triceratops sshguard[62778]: Blocking 99.124.207.89:4 for >0secs: 60 danger in 4 attacks over 1 seconds (all: 120d in 2 abuses over 15625s).
> 
> Yes, I had six failed passwords.  Five of them from testing sshguard more than six hours earlier in the day.  Here in the log message you see it saying "1 second" and then reporting 15625 seconds. According to the options above it should have forgotten those attempts after 20 minutes.
> 
> # grep 99.124.207.89 /var/log/auth.log
> Feb  6 15:12:04 triceratops sshd[62705]: error: PAM: authentication error for jrhett from 99.124.207.89
> Feb  6 15:12:04 triceratops sshd[62705]: Failed password for jrhett from 99.124.207.89 port 59757 ssh2
> Feb  6 18:12:01 triceratops sshd[64237]: error: PAM: authentication error for jrhett from 99.124.207.89
> Feb  6 18:12:01 triceratops sshd[64237]: Failed password for jrhett from 99.124.207.89 port 54602 ssh2
> Feb  6 18:23:04 triceratops sshguard[62778]: Blocking 99.124.207.89:4 for >450secs: 60 danger in 4 attacks over 663 seconds (all: 60d in 1 abuses over 663s).
> Feb  6 21:12:00 triceratops sshd[65838]: error: PAM: authentication error for jrhett from 99.124.207.89
> Feb  6 21:12:00 triceratops sshd[65838]: Failed password for jrhett from 99.124.207.89 port 53494 ssh2
> Feb  6 21:38:30 triceratops sshd[65968]: Accepted publickey for jrhett from 99.124.207.89 port 61698 ssh2
> Feb  6 21:38:33 triceratops sshd[65970]: Accepted publickey for jrhett from 99.124.207.89 port 61856 ssh2
> Feb  6 21:47:43 triceratops sshd[66034]: Accepted publickey for jrhett from 99.124.207.89 port 50779 ssh2
> Feb  6 22:32:26 triceratops sshguard[62778]: Blocking 99.124.207.89:4 for >0secs: 60 danger in 4 attacks over 1 seconds (all: 120d in 2 abuses over 15625s).

I went through the code and it looks OK. The only reason I could think of
for this to happen is, you have an NTP server that was adjusting the system
clock backwards during those 20 minutes. The logs you paste here don't
help to verify this case.

Here's the relevant logic in sshguard.c :

if (tmpent == NULL) { /* entry not already in list, add it */
[..]
	attackerinit(tmpent, & attack);	# does tmpent->whenfirst = tmpent->whenlast = time()
[..]
} else {	/* entry was already existing, update with new data */
	tmpent->whenlast = time(NULL);
[..]

sshguard_log(LOG_NOTICE, "Blocking %s:%d for >%lldsecs: %u danger in %u attacks over %lld seconds (all: %ud in %d abuses over %llds).\n",
[..]
	(long long int)(tmpent->whenlast - tmpent->whenfirst)



> Bug 2: it timed out an address in the whitelist
> 
> If you read the log report carefully, it appears to think it is blocking 99.124.207.89:4 ... not really sure why it thinks :4 is part of the IP address, but this clearly caused it to avoid the whitelist behavior for some reason.  Contents of the whitelist include
> 
> # cat /usr/local/etc/sshguard.whitelist
> 99.124.207.88/29

The ":4" part says "the type of the address is [IPv]4"; the actual firewall command is composed afterwards.

The netblock "99.124.207.88" mask 29 does match "99.124.207.88", so you are most likely not actually
pointing sshguard to use this whitelist file (check your command line).