[sslh] fail2ban

[perini.davide@dpsoftware.org_IMAP]

I'm going mad but this time I get a step forward.
sslh --transparent --user MYEXISTING USER --pidfile /tmp/sslh -p 
MYIP:443 --ssl MYIP:8443 --ssh MYIP:42424
plus
iptables -t mangle -N SSLH;
iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 
42424--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;

works like a charm.

If I try to start it like a service with the
service sslh start
it doesn't work. Operation not permitted.

Have you got any suggestion on starting it as a service?

Thanks.


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