Not everybody want to use LogWatch. If you want to write a sshdfilter log parsing script, the appropriate patters are(correct for V1.4.2):
# Normally ignore these
/repurgetime=/
/maxblocktime=/
/maxchances=/
/interface=/
/sshdpath=/
/debug=/
/sshd args=/
/ip6toip4=/
/iptables command=/
/cannot fork:/
/couldn\'t run /
/sshdfilter couldn\'t email block event/
/ran sshd and waited one second, it died and said: /
/(pre|post) mail command is /
/Flushing SSHD chain/
/sshd received signal \d+, closing sshdfilter/
/^Cancelled instant block of ([\d\.:a-f]+)/
/^Cancelled guesswork based block of ([\d\.:a-f]+)/
# Main messages, summarise these
/^Illegal user name, instant block of ([\d\.:a-f]+)/
/^Too many password guesses, blocking ([\d\.:a-f]+)/
/^No ssh id string from client, instant block of ([\d\.:a-f]+)/
/^sshdfilter ([\d\.:a-f]+) starting up, running sshd proper/
/^sshd quit, closing sshdfilter/
/is missing SSHD chain, sshdfilter rendered useless./
/is missing SSHD redirect, sshdfilter rendered useless./
# Debugging messages ($debug=1), normally ignored unless you want to report on debugging mode.
/^Chanced ([\d\.:a-f]+), tries=\d+/
/^NOID: ip=([\d\.:a-f]+)/
/^ACCEPT: user=(\S+), ip=([\d\.:a-f]+)/
/^FAILILL: user=(\S+), ip=([\d\.:a-f]+)/
/^FAILVAL: user=(\S+), ip=([\d\.:a-f]+)/
/^INVALID: user=(\S+), ip=([\d\.:a-f]+)/
/^QUIT: signal=(\d+)/
sshdfilter must assume its state tables are in sync with the iptables SSHD chain. If your firewall likes to flush all rules, you need to restart sshdfilter. Unfortunately it isn't practical to automatically repair chains. It is conceivable that every addition or flush of a single rule consisted of flushing the whole chain and then adding those blocks that were still valid, but I don't like the sound of that at all.
So... I say any program that changes the SSHD chain is basically bugged, as they should only change what they know about. To change anything more is to assume said program knows everything about your firewall, which is arrogant.
The current solution is to restart sshdfilter, which might sound like you are throwing away important blocks, but in reality you aren't. Attackers never come back, so by the time you see the block in iptables, it will probably already have done its job.
Assuming you haven't just upgraded your sshd, this almost always means you have cleared the iptables rulebase, specifically the SSHD chain, and not restarted sshdfilter. sshdfilter will not readd blocks it already thinks are in iptables. Make sure the SSHD chain is never molested by other programs, 'easy to configure' firewall scripts are known for this problem. See above, and below.
If you use ferm to create your firewall, you can use the script below to avoid flushing the SSHD, and so avoid restarting sshdfilter.
option iptables
option flushchains
option createchains
chain input policy ACCEPT {
interface (eth0) {
proto tcp {
dport 22 goto SSHD;
}
}
}
Have considered extending the sshdfilter method to SMTP and the like. But, notice how many distros are supported by sshdfilter? Each distro takes effort because each uses different logging messages, but it is doable. But, there are many MTAs, and each uses a different startup method, probably different log messages, and probably doesn't support redirecting logging. Multiply all these together and you have a big bag of trouble that will be impossible to maintain. So... it would be nice, but it isn't going to happen.
For the most part, no it isn't. The formatting of LogWatch scripts varies across versions, so your version of LogWatch needs to be compatble with the sshdfilter LogWatch script. Currently that means using version 7.1.x.
This sort of customisation is included in V1.5.0, where each user can have a specific number of chances. This is mainly aimed at making some user accounts more tolerant of failures. I don't consider making a trap of root a real advantage. sshdfilter counts the consecutive failures per ip, not per name+ip. So the first few attempts at root will probably trigger sshdfilter into action, and if not, chances are the next guess at a non-root account will. Once they try for non-root accounts, there is also a high chance of trying a non-existent account and leading to an instant block.
Compare this to the number of times I've tried to ssh as root to an sshdfilter protected machine, not noticing I was root until it asks for a password. With a low number of chances, I could easily lock myself out.
I did like the quote on some security forum, it went something along the lines of 'security doesn't exist in a vacuum, it is always a balance of security and convenience'. Which sums up my approach, to not over tune the blocking rules. A brute forcer will try hundreds/thousands of un/pw pairs, sshfilter just needs the first 3 or less failures. So it could be less than 3, but compared to hundres/thousands there is really no point.
Written by Greg: greg at csc liv ac uk. Would welcome any comments.
LogWatch script written by Tommo: sshdfilter at gmail com.
This software is released under the terms of the GNU GPL.