"Fossies" - the Fresh Open Source Software Archive

Member "sshdfilter-1.5.7/man/sshdfilter.1" (7 Jun 2010, 11673 Bytes) of package /linux/privat/old/sshdfilter-1.5.7.tar.gz:


Caution: As a special service "Fossies" has tried to format the requested manual source page into HTML format but links to other man pages may be missing or even erroneous. Alternatively you can here view or download the uninterpreted manual source code. A member file download can also be achieved by clicking within a package contents listing on the according byte size field.

sshdfilter

NAME
SYNOPSIS
DESCRIPTION
COMPATIBILITY
INSTALLATION
OPTIONS
FILES
DOWNLOAD
BUGS
SEE ALSO
AUTHOR
LICENSE

NAME

sshdfilter − sshd brute force blocker

SYNOPSIS

sshd wrapper script that generates iptables DROP rules when sshd reports any of i) no identify string sent by client ii) attempted login to a non-existant account iii) mupliple password failures for a valid account. DROP rules are added in realtime. There are two install routes, either as an sshd wrapper, in which case sshd messages are read directly by sshdfilter, or as a separate standalone program that parses sshd output via a didicated syslog named pipe.

DESCRIPTION

sshdfilter blocks the frequent brute force attacks on ssh daemons, it does this by directly reading the sshd logging output (or syslog output) and generating iptables rules, the process can be quick enough to block an attack before they get a chance to enter any password at all. The blocking policy is defined by a list of block rules largely by user name or by the type of user name.

There are two install routes, the old style sshdfilter starts sshd itself, having started sshd with the −e and −D options. The newer style uses a syslog configuration line that writes sshd messages to a dedicated named pipe, normally /var/run/sshd.fifo. Regardless, this means sshdfilter can see events as they happen and act on them as they happen. sshdfilter then looks for lines of the form:

"Did not receive identification string from x.x.x.x" "Illegal user x from x.x.x.x" "Failed password for illegal user x from x.x.x.x port x ssh2" "Failed password for x from x.x.x.x port x ssh2"

When sshd produces any of these messages, the response of sshdfilter is defined by the configuration file /etc/sshdfilterrc. The default configuration file defines the first message as in instant block event that will install an iptables rule dropping that IP . The next two lines are given one chance (ie. this chance) before an iptables dropping rule is generated. The latter message is given 3 chances before it is blocked.

These are in fact example messages, the exact wording varies between Linux distributions, so the distribution sshdfilterrc exists as a large header containing default policies, and a footer patterns/, each file containing patterns for each Linux/sshd distribution. On installation, the header and the (hopefully) correct footer are added together to create your /etc/sshdfilterrc.

All new rules are inserted into a custom iptables chain, and to prevent the chain from becoming overloaded with old rules, old rules are deleted. Rule duration is also specified in the configuration file.

Taking some statistics from my logs before sshdfilter was implemented, the longest attempt from a single IP was half an hour long, trying around 1 username/password pair per second. Over 26 days there were attacks from 42 unique IPs, none of them ever came back after the attempt. Picking the oldest 10 of these attacks, they had 347, 306, 115, 115, 127, 18, 554, 107, 9, 52 failed\(!\) password attempts. Of these 1750 attempts, 720 were for root − making a good case for blocking password authentication of the root account.

With sshdfilter installed, taking each attack on a case by case basis:
1)
347 attempts becomes 0 attempts − first attemped guess was for a non-existant user, so was instantly blocked.
2)
306 attempts becomes 0 attempts − same reason, non-existant user.
3)
115 attempts becomes 1 attempt − first guess was for root and is allowed a default of 3 chances, the second guess was for a non-existant user and so was blocked anyway.
4)
115 attempts becomes 1 attempt − same as previous.
5)
127 attempts becomes 3 attempts − many initial guesses for root account, so sshdfilter blocks after the first 3 failed attempts.
6)
18 attempts becomes 0 attempts − first attempted guess was for a non-existant user, so was blocked instantly.
7)
554 attempts becomes 3 attempts − many initial guesses for root accont, so sshdfilter blocks after the first 3 failed attempts.
8)
107 attempts becomes 1 attempt − first guess was for a valid user (nobody), second guess was for a non-existant user so was blocked.
9)
9 attempts becomes 0 attempts − first guess was for a non-existant user so was blocked instantly.
10)
52 attempts becomes 3 attempts − many initial guesses for root accont, so sshdfilter blocks after the first 3 failed attempts.

Summerising, of these 10 sample attacks, 1750 attempts, 720 were for root, 1013 were for illegal accounts, the rest were for existing accounts. Using only user name gusses alone, sshdfilter would have blocked 1729 of these. In fact, until the authors of the brute force attacks improve their code and send an ssh id string, sshdfilter would actually have blocked 1744 attempts, allowing only 6 guesses of the root account over an average of 6 days. Had password based root access been banned, even these six would have been futile.

COMPATIBILITY

Right now sshdfilter works with Debian 3.1, Redhat 7.3 to 9.0, Fedora Core 2−4, CentOS, Suse 10.0 RC 1, RedHat Enterprise Linux 4, Slackware and gentoo, and the many derivatives. It also now supports ipfw for BSD , Solaris and MacOSX support. It also works with Dropbear, the light weight sshd server. Each distribution uses different logging messages, so sshdfilter needs a pattern list for the target system. Patterns are supplied for RedHat 7.3 and 9.0 systems, RedHat Fedora Core 3 systems, Suse 10.0 RC 1 and Debian 3.1 (sarge, stable) systems, the other distributions use patterns based on these 4.

INSTALLATION

sshdfilter was written with common Linux distributions in mind, and so expects to find perl, the iptables command (or ipfw command) and support syslog style logging. For the details, see INSTALL .

OPTIONS

If your sshdfilter is installed as a wrapper to sshd, all options on the command line are passed to sshd, sshdfilter takes all its options via the configuration file /etc/sshdfilterrc. See its man page for more information on the options.

If your sshdfilter is installed standalone and reads sshd messages via a syslog fifo, sshdfilter takes the option logpid=<pid of sshd>. This will only be usful if you run multiple sshdfilters, as this allows sshdfilter identify messages from a particular sshd. sshd messages in syslog are from the children of the main sshd daemon, so sshdfilter will accept only messages from children of this pid.

FILES

/usr/sbin/sshdfilter − main sshdfilter code. /etc/sshdfilterrc − sshdfilter configuration file.

/etc/init.d/sshd − modified sshd startup script, so sshdfilter is run instead of sshd. or /etc/init.d/sshdfilter − standalone startup file. /etc/sshdfilter.ipfw − ipfw state file, see INSTALL .ipfw

DOWNLOAD

The latest sshdfilter is available from <http://www.csc.liv.ac.uk/~greg/sshdfilter/>

BUGS

None known. More likely there are features you don’t like.

SEE ALSO

sshdfilterrc(5)

AUTHOR

Written by Greg: greg at csc liv ac uk. Would welcome any comments.

LogWatch script written by Tommo: sshdfilter at gmail com.

LICENSE

This software is released under the terms of the GNU GPLv2.