[sslh] sslh Transparent Proxy and Fail2Ban

[Sean Warner]

Hello,

I just wanted to feedback my experience with setting up Fail2Ban and sslh.
I'm sure some will find this information obvious but in any case this may
help others who are struggling a bit.

It is not at all necessary to have sslh working as a transparent proxy so
you can get Fail2Ban to work with it. In my set up I get log entries in
/var/log/daemon.log that look like this:
Apr 22 20:48:47 raspberrypi sslh[11497]: ssh:connection from
192.168.1.101:53034 to 192.168.1.124:4433 forwarded from 192.168.1.101:53034
to 127.0.0.2:1022

If sslh was not functioning as a transparent proxy then the "forwarded from"
and "to" ip addresses would be the same and probably be "localhost" or
127.0.0.1. With the "connection from <ip addr>" the same as the "forwarded
from <ip addr>" it's clear that transparent support is working.

But either way the ip address of the originating request will be available
in "ssh:connection from <ip address>". We can make a Fail2Ban regex match
this and test it using the fail2ban-regex command line tool as follows:
# fail2ban-regex -v /home/pi/f2bString "^.+ssh:connection from <HOST>:.+ to
.+ forwarded from .+ to .+$"

Where /home/pi/f2bString is a file containing one or more log lines from
/var/log/daemon.log

I added this....

[sslh-ssh]
enabled = true
port = 4433
filter = sslh-ssh
action = iptables-multiport[name=sslh,port="4433"]
logpath = /var/log/daemon.log
Findtime = 600
Bantime = 600
maxretry = 6

... to # nano /etc/fail2ban/jail.local

I then added these lines to a file # nano
/etc/fail2ban/filter.d/sslh-ssh.conf

[INCLUDES]

# much credit to 2014-03-28 Author: Evert Mouw <post at evert.net>
# no includes

[Definition]

failregex = ^.+ssh:connection from <HOST>:.+ to .+ forwarded from .+ to .+$

# Evert Mouw version, doesn't work
# failregex = ^.+ sslh\[.+\]: connection from <HOST>:.+ to .+ forwarded from
.+ to .+:ssh\s*$

ignoreregex =

Then issued these commands to restart and test Fail2Ban
# systemctl restart fail2ban
# systemctl status fail2ban

-- Fail2Ban uses iptables firewall. view the rules added:
# iptables -n -L -v --line-numbers

-- List out all the activated Jails:
# fail2ban-client status

-- Verify fail2ban banning status on the [sslh-ssh] jail:
# fail2ban-client status sslh-ssh
# tail -25 /var/log/fail2ban.log
# grep -i 'ssl' /var/log/daemon.log

-- Unban an ip address:
# fail2ban-client set ssh unbanip 192.168.15.196

Using this set up I monitor incoming connections from my routers internal
port 4433 and the [sslh-ssh] jail regex matches on connections to the ssh
server only. An ip is banned for 10minutes if it made more than five
connection attempts to the ssh server within a 10 minute period. In this
example the machine with the banned ip will be unable to access the SSH
server AND web server for 10 minutes since sslh multiplexes both through the
same port.

The usefulness of this setup is limited.. it may help stop a denial of
service attack on the ssh server but it offers no protection to any other
services available through the shared port.. e.g  to the web server. It may
be more sensible to direct the sslh port at a different filter for each
service it multiplexes so the right log file and regex can be used to match
anything suspicious directed at each service. Worth remembering that
Fail2Ban will stop a banned machine from accessing all services delivered
through the multiplex port so if it is you then you are locked out of your
server until the ban is lifted and this is why in the end I went with a
short Bantime.

Any comments or feedback gladly accepted !

Flex