[sslh] fail2ban

[perini.davide@dpsoftware.org_IMAP]

every time I add the --transparent option I get
setsockopt: operation not permitted error,
no way to run --transparent as a normal user



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