sshdfilter
sshdfilter automatically blocks ssh brute force attacks by reading sshd log output in real time and adding iptables rules based on authentication failures. Block rules are created by logging on with an invalid user name, or wrongly guessing the password for an existing account. Block rules are removed after a week to maintain a small list of blocks. It also comes with a LogWatch filter.
| Tags | Networking Firewalls |
|---|---|
| Licenses | GPL |
| Operating Systems | POSIX Linux |
| Implementation | Perl |
| Translations | English |
Recent releases
- 19 Apr 2007 03:20
Changes: The configuration parser and the pattern matching engine were rewritten to provide all the flexibility you could ever want. sshdfilter can now read sshd messages from either sshd -eD (as with previous versions of sshdfilter) or via a named pipe maintained by syslog. Hostname lookup for messages was added for PAM-based systems that show hostnames and never a source IP. ipfw support was added.
- 17 Jun 2006 00:47
Changes: Support for CentOS 4.3, Slackware, and Debian Sid was added. A config loading bug where SSHDFILTERRC was ignored was fixed. Man page installation was fixed in install.pl. Typos in the documentation were corrected.
- 12 Feb 2006 00:45
Changes: Custom ports and options such as -j REJECT are a configuration option. A hanging email command no longer delays sshdfilter. The result code from system() calls is checked when adding block rules. The SSHD chain name is now a config option, so multiple instances of sshdfilter can have their own chains. Support for multiple configuration files was added. Support for Gentoo and Debian sid was added. The LogWatch installer for Fedora Core 4 was improved. The LogWatch script's compatibility with other versions of LogWatch was improved. Man pages were added for sshdfilter and sshdfilterrc.
- 15 Nov 2005 06:35
Changes: Support was added for Suse 10.0 RC 1, CentOS, and Red Hat Enterprise Linux ES release 4. The program now daemonizes like sshd, so it makes a better replacement for sshd in the startup scripts. select() is now used to read sshd output, making repurgetime much more responsive when a small value is given. Email can be sent to someone optionally on block events. More support was added for IPv6 and conversion to IPv4. A typographical bug in IPv6 to IPv4 conversion of 1.4.0 was fixed.
- 24 Sep 2005 13:16
Changes: Support for IPv6 addressing was added, which is needed for some recent distributions, such as Debian 3.1 Sarge.
- All comments
Recent commentsOpenSuSE 9.2
I've been sick of seeing this crud in my logs on my OpenSuSE system (it's an old P133 system).
So to install it I had to make the following changes:
1. Update /etc/rc.d/sshd with the supplied sshd.suR10rc1 version.
2. Update /etc/sysconfig/SuSEfirewall2 to set
FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"
3. Update /etc/sysconfig/scripts/SuSEfirewall-custom with
fw_custom_before_port_handling() {
# these rules will be loaded after the anti-spoofing and icmp handling
# and after the input has been redirected to the input_XXX and
# forward_XXX chains and some basic chain-specific anti-circumvention
# rules have been set,
# but before any IP protocol or TCP/UDP port allow/protection rules
# will be set.
# You can use this hook to allow/deny certain IP protocols or TCP/UDP
# ports before the SuSEfirewall2 generated rules are hit.
iptables -N SSHD
iptables -I INPUT -p tcp -m tcp --dport 22 -j SSHD
true
}
4. I dont have Logwatch installed.
I'm now just waiting for the next attempt from a ssh1 compromised machine.
Re: I can't tell if sshdfilter is working...
> I'm suspicious of your
> sshdfilter program.
You are a boob Dave.
The app works great.
If you don't trust it then just read the friggin code man -- sheesh.
Re: Actually...I'm REAL suspicious too
Are you still using sshdfilter, and which version? I assume you aren't. In which case I'd suspect the sshd startup script is still running sshdfilter instead of sshd. If you have unstalled all trace of sshdfilter by undoing all steps in the INSTALL file, and you're logging is still going missing, then sshdfilter can't be the reason.
> Yeah, that's understandable. But, ever
> since I tried using the sshdfilter
> program, I have been having syslog
> problems. Syslog occasionally stops
> logging. I have to restart syslog to
> get the logging going again. That is
> something that NEVER happened before I
> tried using sshdfilter. Do you have an
> explanation for that?
Re: Actually...I'm REAL suspicious too
> Hardly surprising, sshdfilter clears the
> SSHD chain of rules whenever it starts,
> to stop the rules going stale in the
> long term. You have created your problem
> by blindly changing the sshdfilter
> source code.
>
>
> % In hindsight...I was wondering why
> all
> % my iptables rules for my existing
> chain
> % got deleted as soon as I ran the
> % sshdfilter program for the first time.
>
> % Is there a reasonable explanation for
> % that? Maybe I shouldn't have
> modified
> % the sshdfilter program by replacing
> all
> % instances of the chain name 'SSHD'
> with
> % the name of the chain I had in place
> % before. It's still peculiar how all
> the
> % rules associated with that chain got
> % deleted.
>
>
>
Yeah, that's understandable. But, ever since I tried using the sshdfilter program, I have been having syslog problems. Syslog occasionally stops logging. I have to restart syslog to get the logging going again. That is something that NEVER happened before I tried using sshdfilter. Do you have an explanation for that?
Re: Actually...I'm REAL suspicious too
Hardly surprising, sshdfilter clears the SSHD chain of rules whenever it starts, to stop the rules going stale in the long term. You have created your problem by blindly changing the sshdfilter source code.
> In hindsight...I was wondering why all
> my iptables rules for my existing chain
> got deleted as soon as I ran the
> sshdfilter program for the first time.
> Is there a reasonable explanation for
> that? Maybe I shouldn't have modified
> the sshdfilter program by replacing all
> instances of the chain name 'SSHD' with
> the name of the chain I had in place
> before. It's still peculiar how all the
> rules associated with that chain got
> deleted.