[sslh] fail2ban

[perini.davide@dpsoftware.org_IMAP]

Hi,
I have done this command as in the readme.

# iptables -t mangle -N SSLH
# iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 
--sport 22 --jump SSLH
# iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 
--sport 8443 --jump SSLH
# iptables -t mangle -A SSLH --jump MARK --set-mark 0x1
# iptables -t mangle -A SSLH --jump ACCEPT
# ip rule add fwmark 0x1 lookup 100
# ip route add local 0.0.0.0/0 dev lo table 100

# setcap cap_net_bind_service,cap_net_admin+pe sslh

this is the way I start SSLH:
OPTIONS="--user nobody --pidfile $PIDFILE -p  MYPUBLICIPADRESS:443 --ssl 127.0.0.1:8443 --ssh 127.0.0.1:22"

It doesn't work if I add the --transparent option.
My VPS can't ping 192.168.0.1 so I tried also by using
OPTIONS="--user nobody --pidfile $PIDFILE -p  MYPUBLICIPADRESS:443 --ssl 
MYPUBLICIPADRESS:8443 --ssh MYPUBLICIPADRESS:22"

But it doesn't work.
I get a permission denied error while trying to connect to ssh on port 443.

Can you help?

Thanks!!!

Davide

Il 04/10/2013 18.45, Yves Rutschle ha scritto:
> On Fri, Oct 04, 2013 at 05:32:23PM +0200, Davide Perini wrote:
>> Really, really thanks for the help and the answer.
>> Do you think that this will is an unsecure way to proceed?
>> Is it more secure without --transparent ???
> Supposing there is a vulnerability in sslh (which is a
> reasonnable assumption):
>
> sslh (as non-root) with --transparent requires
> cap_net_admin, which lets sslh stop or otherwise
> misconfigure the network interfaces. Arguably it's a bad
> idea for an attacker to stop the network interface from
> which you're attacking. To draw a parallel, that'd be like
> the attack you perform on a bank is glueing its doors shut.
> Sure, the bank no longer operates, but at least it's fallen
> into a secure mode.
>
> sslh (as non-root) without --transparent can't do much, but
> maybe access all local servers appearing as localhost.
> Presumably if there is a vulnerability this applies to sslh
> with --transparent as well.
>
> sslh as root: just don't.
>
> So, by using --transparent you open an additional potential
> risk of denial-of-service on your system, but you gain all
> of fail2ban's protection. I am not sure what's best, but I'd
> tend to believe having fail2ban will be more secure in the
> end, especially considering that sslh is transparent to the
> attacker: it takes the attacker knowing a vulnerability on
> sslh _and_ taking the time to try and see if there's sslh en
> route to httpd/sshd.
>
> Y.
>