_Quick install instructions for sshdfilter_

For the brave (as this is not so tested), run:
$ ./install.pl
and read below, steps 5 onwards.

Or manually install with:
0.
Apply any user contribed patches from contrib/.

1.
run 
$ ./regen.sh
to recreate distribution specific filters from sshdfilter.base

2.
copy etc/sshdfilterrc to /etc
and edit to suit you

3.
copy sshdfilter.<your distro> to /usr/sbin/sshdfilter, or maybe /usr/local/sbin/
sshdfilter
 rh7390 - RedHat 7.3, RedHat 9.0 or Fedora Core 2.0
 rhFC30 - RedHat Fedora Core 3.0, Fedora Core 4.0, Red Hat Enterprise Linux ES release 4, or CentOS
  deb31 - Debian 3.1 (sarge) or Debian (sid, but see README.debian)
su10rc1 - SuSe 10.0 RC 1 and gentoo
   db47 - Debian 3.1 running dropbear, the light weight sshd server (and see README.dropbear)

4.
Modify the startup script /etc/init.d/sshd to run sshdfilter instead of sshd, 
examples are in etc/init.d/. Basically, any reference to running the sshd 
executable should be replaced by sshdfilter.

5.
Copy the man pages sshdfilter.1 and sshdfilter.5 to /usr/share/man/man{1,5} 
respecively.

6.
If your system uses LogWatch, you can find parsing scripts in etc/log.d/. Note
they are setup for a RedHat system that logs sshd (and so sshdfilter) output 
to /var/log/secure, your distro probably sends the output to another file, 
such as /var/log/auth.log for Debian. You need a recent (6.1.x) version of 
LogWatch to use these LogWatch scripts. sshd logging works as it used to, 
sshdfilter always logs sshd output regardless of it triggering sshdfilter to 
do some action. The LogWatch scripts consist of two files, you will also need
to add 'sshdfilt' to /etc/log.d/conf/services/secure.conf (or similar, try 
'grep -r "sshd " /etc/log.d/conf' to find mentions of sshd, sshdfilt should be 
there too), to tell the other scripts about sshdfilter. The line in 
secure.conf is normally: 
$ignore_services = sshd Pluto stunnel proftpd saslauthd imapd
and needs to be:
$ignore_services = sshd sshdfilt Pluto stunnel proftpd saslauthd imapd
But what it needs to be for you depends on your distribution.

7.
Add the SSHD chain to your firewall setup, typically (/etc/sysconfig/iptables
style):
:SSHD - [0:0]
or bash:
$ iptables -N SSHD

Add a jump to SSHD rule with something like (/etc/sysconfig/iptables style):
-A INPUT -p tcp -m tcp --dport 22 -j SSHD
or bash:
$ iptables -I INPUT -p tcp -m tcp --dport 22 -j SSHD

This is only an example, I've no idea how you set up your iptables. Generally
you'll have a line that ACCEPTS ssh(port 22), and the above should go on the 
line before. Notice I've used -I on the second example, which adds to the 
start of the chain instead of the end. The -I has more chance of working when
added to a running system. The command:
iptables -L INPUT -vn
should show something like:
----
Chain INPUT (policy ACCEPT 22M packets, 1901M bytes)
 pkts bytes target     prot opt in     out     source               destination
.... various site specific rules deleted
  366 22424 SSHD       tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:22
  138  9940 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:22
.... various site specific rules deleted
47996 3742K DROP       all  --  eth1   *       0.0.0.0/0            0.0.0.0/0          state INVALID,NEW
---
Where the last rule blocks all new connections that haven't been ACCEPTed in 
the past, ie, a statefull rule.

8.
Restart sshd via sshdfilter, normally with:
$ /etc/init.d/sshd restart
and check the process tree with:
$ pstree -pul | less -S
(use the cursor keys to move about, q quits)
This should show sshdfilter, with two children, sshdfilter and sshd. Now ssh 
logins will appear as children of this sshd - which is how sshd has always 
worked.

9.
Exceptions to the usual sshdfilter blocking rules can be made with iptables.
If triggered, sshdfilter will say that a given IP is blocked, but an iptables
rule before the SSHD jump rule will avoid any blocks. This will be useful if
you have trusted IP addresses that will never attack your system.  

10.
If you need to run multiple instances of sshdfilter, say on multiple ports, it
might be necessary to use multiple sshdfilterrc config files. If the 
environment variable SSHDFILTERRC exists, it is read at startup instead of 
/etc/sshdfilterc.

This means you can start sshdfilter with different interfaceoptions, such as 
the port number, and have it block IPs independently from other sshdfilter 
instances.  Note the jump-to-SSHD-chain rule will need to be duplicated for 
each port, if required you can also use a different chain, such as SSHD24.

A line such as:
export SSHDFILTERRC=/etc/sshdfilterrc.p24
in the startup file will acheive this.

11.
Post Install:
Inform the users of what happens if they try to many password guesses, or 
type their login name wrongly. 

For yourself, you could install webmin and webmin-iptables, for non-ssh 
remote access. So if you lock yourself out of your machine, you have 
another route in. Of course, this opens up another way into your system for 
others, so maybe you'd be better off running another sshd on an obscure port.

12.
Testing of sshdfilter can be done by ssh'ing from the same machine. Actually 
locking yourself out is not necessary but is possible, simply:
ssh somenoneexistantuser@localhost
should lead to block messages showing up in the logs and an iptables DROP 
rule being added to the SSHD chain. If you have direct access to the machine, 
or have ssh'ed in from somewhere else, you will then be able to:
$ iptables -F SSHD
or restart sshdfilter (which will flush the chain and its state table). Other 
block triggering commands to try are:
$ ssh existsinguser@localhost
and try this a few times with the wrong password, looking at the logs each 
time. And:
$ telnet localhost 22
then press control and ], exit with q. This should trigger the 'No ssh id 
message'.


Last word.
Thats all, now you can enjoy a much better protected ssh and much less junk
in your logs, making them readable again.

