[sslh] fail2ban

[perini.davide@dpsoftware.org_IMAP]

Some other updates.

If I run sslh as a normal user with this command:
sslh --user MYUSER --pidfile /tmp/sslh -p  MYIP:443 --ssl MYIP:8443 
--ssh MYIP:42424

it works, it works only if I put the pid file into the temp directory, 
normal user doesn't have the rights to write in /var/run.
Do you see some security problems in writing the pid file in the /tmp dir?

With that command, I finded a working configuration but how to start at 
every boot?
I'm using CentOS and sslh is installed as a RPM.
this means that I can start SSLH with
service sslh start

if I set in the /etc/rc.d/init.d/sslh this options:
OPTIONS="--user MYUSER --pidfile /tmp/sslh -p  MYIP:443 --ssl MYIP:8443 
--ssh MYIP:42424"

SSLH start but it says permission denied when I try to ssh port 443.

why? how can I start SSLH as a service using centos?

Thanks!


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