[Spce-user] iptables issue

Wed Apr 20 13:00:28 EDT 2016

thanks Julian.

It's the ssh access that was hacked. I suddenly noticed an established 
ssh connection from Asia. since I disabled root login in ssh right after 
install, the hacker must somehow have got my login password. in a haste, 
I reverted the VM to a previous snapshot, so I can't analyze how hacking 
happened now.

I read that sipwise article regarding security before. fail2ban was 
deployed yesterday, it'll provide some protection before I master 
iptables setup on spce. better than nothing at all.

------ Original Message ------
From: "Julian Seifert" <js at dacor.de>
To: "Jonathan Yue" <jonathan.yue at turboitsolutions.com>; "Raúl Alexis 
Betancor Santana" <rabs at dimension-virtual.com>; 
"spce-user at lists.sipwise.com" <spce-user at lists.sipwise.com>
Sent: 2016-04-19 3:21:36 AM
Subject: AW: [Spce-user] iptables issue

>Hi,
>
>you shouldn't need to apply any firewalling for internal communication.
>Apply your firewall rules to your WANside interfaces. (see -i in 
>iptable rules)
>Allow everything out & allow established connections to get replies.
>Fail2ban is a good idea.
>
>You can implement fail2ban for sip-registrations (But I think there's 
>already
>something like that builtin. but maybe that's pro version only, if so 
>there is a sipwise
>blog entry regarding the implementation of fail2ban with regards to sip 
>I think)
>(this is the article I was thinking of:
>https://www.sipwise.org/news/technical/securing-your-ngcp-against-sip-attacks/ 
>)
>
>If your server was hacked you should analyse how that happened.
>There might be flaws in the services you are about to open in your 
>firewall
>or maybe your passwords are of poor choice etc.
>
>There is plenty of documentation regarding firewalling for 
>linux-systems.
>A starting point can be: 
>https://help.ubuntu.com/community/IptablesHowTo
>But any other current documentation works as good as this one.
>
>
>kind regards,
>
>   Julian
>--------------------------------------------------------------------------------
>Von: Spce-user [spce-user-bounces at lists.sipwise.com]" im Auftrag von 
>"Jonathan Yue [jonathan.yue at turboitsolutions.com]
>Gesendet: Dienstag, 19. April 2016 06:26
>An: Raúl Alexis Betancor Santana; spce-user at lists.sipwise.com
>Betreff: Re: [Spce-user] iptables issue
>
>be checking iptables log, i figured this out, adding "iptables -A INPUT 
>-s 127.0.0.1 -d 127.0.0.1 -j ACCEPT" fixes the sip issue.
>
>regarding the slow output of "iptables -L", adding "iptables -A INPUT 
>-p udp --sport 53 -j ACCEPT" fixes it. apparently iptables tries to 
>resolve the fqdn of the ip addresses in the table, so DNS should be 
>allowed.
>
>------ Original Message ------
>From: "Raúl Alexis Betancor Santana" <rabs at dimension-virtual.com>
>To: spce-user at lists.sipwise.com
>Sent: 2016-04-18 2:28:57 PM
>Subject: Re: [Spce-user] iptables issue
>
>>The proper way to setup the firewalling it's to know what you are 
>>doing.
>>
>>First, doing a -J DROP it's a non-sense ... better to change the 
>>policy of the INPUT chain.
>>
>>iptables -P INPUT DROP
>>
>>Second ... you MUST know what services are working on the system, so 
>>you let them go in and out and flow to the interfaces needed
>>
>>DNS
>>SIP
>>SIPs
>>SIP over TCP
>>XMPP
>>RTPEngine ports
>>Web
>>WebServices
>>MySQL
>>...
>>
>>By default, the services are setup to only reply local, so there is no 
>>need to been digging with the iptables to protect the system ... no 
>>more than a few rules when you want to HARD-DROP scammers.
>>
>>
>>--------------------------------------------------------------------------------
>>>De: "Jonathan Yue" <jonathan.yue at turboitsolutions.com>
>>>Para: spce-user at lists.sipwise.com
>>>Enviados: Lunes, 18 de Abril 2016 22:31:59
>>>Asunto: [Spce-user] iptables issue
>>>Hi, all,
>>>
>>>I customized iptables by allowing some ip addresses in INPUT chain, 
>>>and put "iptables -A INPUT -j DROP" at the bottom. Aftert that, the 
>>>execution of "iptables -L" is extremely slow; more importantly phones 
>>>can't register. packet captures ( i can still ssh to server) show 
>>>that spce doesn't respond to sip registration. I read handbook, which 
>>>mentions RTPENGINE, however it's there, untouched.
>>>  sudo iptables -L
>>>Chain INPUT (policy ACCEPT)
>>>target     prot opt source               destination
>>>ACCEPT     all  --  77.72.169.0/24       anywhere
>>>ACCEPT     all  --  46.19.208.0/22       anywhere
>>>............ ( a few line omitted )
>>>rtpengine  all  --  anywhere             anywhere
>>>DROP       all  --  anywhere             anywhere
>>>LOG        all  --  anywhere             anywhere             LOG 
>>>level warning
>>>
>>>Chain FORWARD (policy ACCEPT)
>>>target     prot opt source               destination
>>>
>>>Chain OUTPUT (policy ACCEPT)
>>>target     prot opt source               destination
>>>
>>>Chain rtpengine (1 references)
>>>target     prot opt source               destination
>>>RTPENGINE  udp  --  anywhere             anywhere             
>>>RTPENGINE id:0
>>>
>>>After command "iptables -D INPUT -j DROP", issue is gone right away. 
>>>I wonder what's the proper way to configure iptables on spce?
>>>
>>>thanks,
>>>
>>>J.
>>>
>>>_______________________________________________
>>>Spce-user mailing list
>>>Spce-user at lists.sipwise.com
>>>https://lists.sipwise.com/listinfo/spce-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20160420/bdd6e1fc/attachment-0001.html>