Firewall Blacklist/Whitelist

[jroper]

Hi

One of my concerns is if this blacklist gets abused and someone intentionally blacklists sites that shouldn't be blacklisted. This could result in a denial of service non-attack...

http://pbxinaflash.com/forum/showpost.php?p=53577&postcount=17

This has already happened unintentionally, see previous posts. The key to this is accurate data, and reduced attack origins.

Joe

 

[wardmundy]

Both DOS issues were addressed within less than 5 minutes, and both were resolved. I've been posting Asterisk tweets seeking additional people that have been blocked from visiting pbxinaflash.com (which also uses the list) and have received zero complaints in the past 3 days. So... I think we have a fairly stable list at this juncture.

 

[blanchae]

I know with fail2ban that there has been problems with IPs being banned and not realizing it. Then the subsequent difficulty in determining why the IPs were not working. It would be nice if there was a method of quickly checking to see if a specific IP was blacklisted through Webmin or FreePBX status page. If not possible then a quick command line status check search.

Also, is there a log that can be checked to determine if an IP address was banned? i.e. when a blacklisted IP attempts to connect, it is recorded? /var/log/asterisk/full ?

 

[The Deacon]

Also, is there a log that can be checked to determine if an IP address was banned? i.e. when a blacklisted IP attempts to connect, it is recorded? /var/log/asterisk/full ?

The attempt is logged in /var/log/asterisk/full and the fail2ban banning entry is in /var/log/fail2ban.log

Here's an example:

/var/log/asterisk/full:

/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"2523416501"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"1409753650"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"noauth"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"user1"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"pc1"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"manager"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"administrator"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"dave"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"gary"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"john"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"pual"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"albert"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"sasha"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"phone"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"100"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"101"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"102"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found
/var/log/asterisk/full.2:[2010-11-22 09:08:31] NOTICE[5789] chan_sip.c: Registration from '"103"<sip:[email protected]>' failed for '221.195.4.13' - No matching peer found

And the fail2ban entry is here:

/var/log/fail2ban.log:

2010-11-22 09:08:34,549 fail2ban.actions: WARNING [asterisk-iptables] Ban 221.195.4.13
2010-11-22 09:38:34,825 fail2ban.actions: WARNING [asterisk-iptables] Unban 221.195.4.13

 

[blanchae]

Personally, I have no problem scanning the logs. My concern is for the multitudes of new users who install the blacklist because Numero Uno says its a good idea (which it is) and then flooding the forums with questions as to why they can't access their PiaF server or their trunks fail, etc.. when they are accidentally blacklisted.

My suggestion is before the blacklist becomes mainline, is to have an easy and in your face method for Joe User to determine if and when an IP on the blacklist attempts to access his server. This could be a webmin or FreePBX gui module or a simple script. This way, in case an error occurs and an IP address is blacklisted that shouldn't be then he would know. A simple method of unblacklisting should be included.

My comments shouldn't be taken as criticism but as suggesting ways to reduce the amount of reported problems down the road.

 

[wardmundy]

Blacklist vs. Whitelist

Appreciate the suggestion. This was only a trial balloon and probably will never be incorporated into the main builds of either PIAF or Incredible PBX although it will be available here for those that want to try it.

We're now leaning more towards a whitelist methodology which permits the SIP and IAX connections you actually need rather than the blacklist mechanism. We've actually used an IAX whitelist in Incredible PBX for many months with zero problems. It's just too hard to maintain a blacklist unless it were to become a fee-based system... which doesn't sound like much fun either.

And all sorts of red flags go up in thinking about how to educate new users on unscrambling IPtables.

 

[Astrosmurfer]

While unfamiliar with your specific whitelist implementation, it is my opinion that whitelists are always superior to blacklists. Allow specific and then deny ALL.

This method becomes daunting and sometimes unwieldy when you have remote extensions or roaming users. And the answer to that problem is VPN or port knocking, if you must.

 

[dad311]

This guy has been very busy.

'195.80.239.206' - No matching peer found
[2010-11-28 10:38:56] NOTICE[11885] chan_sip.c: Registration from '"143"<sip:[email protected]>' failed for '195.80.239.206' - No matching peer found
[2010-11-28 10:38:56] NOTICE[11885] chan_sip.c: Registration from '"388"<sip:[email protected]>' failed for '195.80.239.206' - No matching peer found
[2010-11-28 10:38:56] NOTICE[11885] chan_sip.c: Registration from '"389"<sip:[email protected]>' failed for '195.80.239.206' - No matching peer found
[2010-11-28 10:38:56] NOTICE[11885] chan_sip.c: Registration from '"144"<sip:[email protected]>' failed for '195.80.239.206' - No matching peer found
[2010-11-28 10:38:56] NOTICE[11885] chan_sip.c: Registration from '"390"<sip:[email protected]>' failed for '195.80.239.206' - No matching peer found
[2010-11-28 10:38:56] NOTICE[11885] chan_sip.c: Registration from '"391"<sip:[email protected]>' failed for '195.80.239.206' - No matching peer found
[2010-11-28 10:38:56] NOTICE[11885] chan_sip.c: Registration from '"145"<sip:[email protected]>' failed for '195.80.239.206' - No matching peer found

 

[dad311]

Wouldn't be a good idea to just setup iptables to block all incoming SIP connections except those from known SIP providers and your VPN addresses?

 

[wardmundy]

PIAF Whitelist

We've been working on locking down SIP at least for Incredible PBX. IAX already is locked down. It may be next week before it's soup. But it's coming. Trying hard to automate the entire process based upon your existing trunk setups in FreePBX. Here's the main piece:

#!/bin/bash
CMD='SELECT data FROM asterisk.sip WHERE `id` >9999 AND `keyword` = "host"'
TRUNKS=`mysql -u root -ppassw0rd -e "$CMD" -s -N`
for host in $TRUNKS
do
resolveip $host
done
exit 0

Finally we'll use SED or iptables commands to stuff the answers into /etc/sysconfig/iptables, and we'll have a very secure server with no hardware firewall. And, with a couple of little hacks, we can even make Travelin' Man work for remote phones so that individual IP addresses can be activated on the fly with both Asterisk AND iptables.

 

[wardmundy]

Firewall Whitelist Beta

If you'd like to experiment with the Firewall Whitelist for SIP, download the tarball into your root folder and do the following:

cd /root
wget http://incrediblepbx.com/firewall-whitelist.tar.gz
tar zxvf firewall-whitelist.tar.gz
rm firewall-whitelist.tar.gz
./firewall-whitelist-gen.sh
./firewall-whitelist.sh

Check your firewall entries with this command:

iptables -nL

If everything is not OK, edit /etc/firewall.whitelist.sip and then rerun /root/firewall-whitelist.sh.


A backup copy of /etc/sysconfig/iptables is always saved to /etc/sysconfig/iptables.timestamp. All non-routable IP addresses are automatically allowed full access plus every host entry specified in your SIP trunks. The whitelist is saved in /etc/firewall.whitelist.sip.

If you also use external phones and activate them with Travelin' Man, see this thread for some necessary changes to support this White List.

Please post comments/suggestions here. Thanks.

 

[dad311]

I ran the whitelist script and have a question.

My iptables -L shows the following for my Vitelity trunks:

ACCEPT udp -- 64.2.142.13 0.0.0.0/0 udp dpts:5000:5082
ACCEPT udp -- 64.2.142.29 0.0.0.0/0 udp dpts:5000:5082

FreePBX SIP status shows the following for my Vitelity trunks:

vitel-inbound 64.2.142.13
vitel-outbound 64.2.142.18

The 64.2.142.13 matches, but why does my iptables show 64.2.142.29 and FreePBX show 64.2.142.18?

 

[wardmundy]

Not my strong suit, but it appears Vitelity is rerouting traffic internally, or you're connecting to a different host. Here are my results of resolving the actual FQDN. This is exactly what the script does...

root@pbx:~ $ resolveip -s outbound1.vitelity.net
64.2.142.18

And here is the traceroute:

1 192.168.0.1 (192.168.0.1) 0.374 ms 0.401 ms 0.482 ms
2 73.30.103.1 (73.30.103.1) 12.480 ms 17.511 ms 12.482 ms
3 te-9-4-ur01.mtpleasant.sc.chrlstn.comcast.net (68.86.145.221) 47.143 ms 47.215 ms 47.343 ms
4 te-8-2-ar01.charleston.sc.chrlstn.comcast.net (68.86.144.89) 47.455 ms 47.559 ms 47.674 ms
5 pos-1-1-ar01.savannah.ga.savannah.comcast.net (68.86.250.113) 61.668 ms 102.471 ms 107.384 ms
6 te-7-3-ar02.augusta.ga.augusta.comcast.net (68.85.229.238) 109.914 ms 110.032 ms 110.138 ms
7 pos-0-10-0-0-cr01.charlotte.nc.ibone.comcast.net (68.86.90.189) 118.265 ms 118.373 ms 118.499 ms
8 pos-3-13-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.86.225) 119.374 ms 29.233 ms 46.196 ms
9 pos-1-10-0-0-cr01.dallas.tx.ibone.comcast.net (68.86.86.129) 55.262 ms 59.473 ms 64.561 ms
10 pos-2-14-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.177) 81.234 ms 84.995 ms 109.011 ms
11 as14929.denver.co.ibone.comcast.net (75.149.230.122) 149.284 ms 153.030 ms 153.414 ms
12 66.241.96.171 (66.241.96.171) 151.397 ms 151.142 ms 151.424 ms
13 64.2.142.215.GIGe-net.vitel.net (64.2.142.215) 151.514 ms 151.628 ms 151.910 ms

I guess the bottom line is whether you can still get an outbound connection with the firewall rules that were generated. If so, it's fine. If not, we've got a problem.

 

[frontline]

Dns lookup for tht fqdn:
;; QUESTION SECTION:
;outbound1.vitelity.net. IN A

;; ANSWER SECTION:
outbound1.vitelity.net. 832 IN A 64.2.142.214
outbound1.vitelity.net. 832 IN A 64.2.142.29
outbound1.vitelity.net. 832 IN A 64.2.142.18
outbound1.vitelity.net. 832 IN A 64.2.142.17
outbound1.vitelity.net. 832 IN A 64.2.142.216
outbound1.vitelity.net. 832 IN A 64.2.142.215

 

[dad311]

Not my strong suit, but it appears Vitelity is rerouting traffic internally, or you're connecting to a different host. Here are my results of resolving the actual FQDN. This is exactly what the script does...




And here is the traceroute:




I guess the bottom line is whether you can still get an outbound connection with the firewall rules that were generated. If so, it's fine. If not, we've got a problem.

No problems placing or receiving calls and all my local/vpn connections are still working. thx

 

[jroper]

In respect of the whitelist script Great minds think alike

I would strongly agree with the approach of locking down iptables to the private IP address range, and explicitly opening those you need.

Joe

 

[bmore]

In respect of the whitelist script Great minds think alike

I would strongly agree with the approach of locking down iptables to the private IP address range, and explicitly opening those you need.

Joe

Joe,

Yes, this is the basic well established concept behind firewalls. As you know, your firewall/gateway router works like this... First, Deny All Traffic... And then Only let through traffic that should be ok (the whitelist) such as traffic originating from behind the firewall on the LAN segment.

The Blacklist concept for a firewall effectively means... Allow all Traffic... Only block what we think is bad (the Blacklist). Obviously a much harder concept to implement in a secure way.

The Blacklist concept on a pbx means, open port 5060... effectively allow all traffic in... Depend on the Blacklist to block the bad guys and if that is not sufficient... I hope my secondary protections (passwords) are strong enough to stop them... And I hope and pray they don't come up with some Zero day hack I don't know about or if there is an exploit I hope I am monitoring the news sites and notifications and have patched my box before they get me.

Ward's move to a whitelist is probably well advised and a better approach

 

[bmore]

Iptables only firewall security

Ward,

A combination of your whitelist and sunshinenetworks method would create a no external firewall very tight box.

as you know, recall sunshinenetworks method:

iptables -N door
iptables -I door 1 -p udp --dport 5060 -m string --string "mysecretpass" --algo bm -m recent --set --name portisnowopen
iptables -I door 1 -p udp --dport 5060 -m string --string "anothersecret" --algo bm -m recent --set --name portisnowopen
iptables -I door 1 -p udp --dport 5060 -m string --string "yetanothersecret" --algo bm -m recent --set --name portisnowopen
iptables -A INPUT -p udp --dport 5060 --source 202.169.178.10/32 -j ACCEPT
iptables -A INPUT -p udp --dport 5060 --source 203.2.134.1/32 -j ACCEPT
iptables -A INPUT -p udp --dport 5060 --source 10.10.1.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 5060 -m recent --rcheck --seconds 4000 --name portisnowopen -j ACCEPT
iptables -A INPUT -p udp --dport 5060 -j door
iptables -A INPUT -p udp --dport 5060 -j DROP
service iptables save

Your whitelist could automatically add the known hosts (voip hosts etc). Either a script or preferably a web page (like a freepbx module) to add/remove the "Display Name" for offsite user agents (ip phones, ata's etc).

It would parse iptables for any lines with a "Display Name" secret... Add or remove those lines as necessary... then use your whitelist method to add allowed hosts... then save the file and use 'service iptables' to save and restart.

I am not a linux guy (yet) but it is the kind of string manipulation I could do in VB if this was windows. Seems like this would create a really neat and secure solution.

 

[ou812]

I would like to give this a try, but before I do will this pickup my settings in freepbx for IAX2 trunks. It only mentions sip trunks and I am also NOT running the incredible version of PIAF.

Gary

 

[jroper]

Hi

You can block all ports for IAX2 as well, the trunks will not be affected, as you will note an allow "established" and "related" traffic setting in the rules.

So your IAX trunk has endeavoured to make contact with your provider, and from that point on, the traffic is all related and established, and therefore not blocked by any firewall rule between you and your carrier.

However, an IAX call uninvited to your box on port 4569 coming in from the outside is "New" and is therefore blocked and dropped.

I trust that this clarifies.

Joe