[sslh] fail2ban

[perini.davide@dpsoftware.org_IMAP]

Ok,
using
OPTIONS="--user root --pidfile $PIDFILE -p  MYPUBLICIPADRESS:443 --ssl 
MYPUBLICIPADRESS:8443 --ssh MYPUBLICIPADRESS:22"

works wonderfully.

If I run it as a normal user, it doesn't work, why?
I have done this command:
setcap cap_net_bind_service,cap_net_admin+pe sslh

Thanks!!!



Il 05/10/2013 19.20, perini.davide at dpsoftware.org_IMAP ha scritto:
> 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.
>>
>