Re: [SSHGuard-users] firewall doesn't seem to be updating

[@lbutlr <kr...@kr...>]

On 15 Jul 2020, at 01:58, Kevin Zheng <kev...@gm...> wrote:
> On 7/14/20 2:57 PM, @lbutlr wrote:
>> auth.log contains entries like:
>> 
>> sshd[81715] error: PAM: Authentication error for root from 116.98.172.159
>> sshd[81715] Connection closed by authenticating user root 116.98.172.159 port 49832 [preauth]
> 
> Are these the exact lines from your auth.log? SSHGuard is not detecting
> these because it does not recognize your log header. Is this syslogd?

Other than the time stamp and server name, yes. I thought that information was not relevant.

> This is not recognized by 2.4.0 because OpenSSH recently changed their
> log format. The parser in Git does recognize this as an attack. I will
> cut a release soon.
> 
>> So, I try to manually trigger it by manually appending the above bloglines back to auth.log from another session:
>> 
>> # which sshguard
>> /usr/local/sbin/sshguard
>> # env SSHGUARD_DEBUG=foo /usr/local/sbin/sshguard 
>> /usr/local/sbin/sshguard: cannot create : No such file or directory
> 
> The version in FreeBSD ports has a non-standard addition that checks for
> the existence of the PID file. I think it's just saying it can't write
> to the PID file, because $PID_FILE is empty? I'll investigate further.
> 
>> sshguard 94135 - - whitelist: add '***' as plain IPv4.
>> sshguard 94135 - - whitelist: add plain IPv4 ***.
>> sshguard 94135 - - whitelist: add IPv4 block: ***.
>> sshguard 94135 - - whitelist: add IPv4 block: ***.
>> sshguard 94135 - - blacklist: blocking 4832 addresses
>> sshguard 94135 - - whitelist: add '127.0.0.1' as plain IPv4.
>> sshguard 94135 - - whitelist: add plain IPv4 127.0.0.1.
>> sshguard 94135 - - Now monitoring attacks.
> 
> SSHGuard does not accept attacks from standard input.

No, I added the log lines to auth.log in another session (this works fine on a different machine, at least in terms of when I logged in it showed that the IP used was in the whitelist.

> There are several things you can do to troubleshoot SSHGuard, but an
> easy starter is to syscall trace it:
> 
> $ truss -f /usr/local/sbin/sshguard

I'll give that a shot.

What are some other steps to troubleshoot.

-- 
'They say that whoever pays the piper calls the tune.' 'But,
gentlemen,' said Mr Saveloy, 'whoever holds a knife to the
piper's throat writes the symphony.' --Interesting Times