Firewall Blacklist/Whitelist

[wardmundy]

If you have external phones that are activated using Travelin' Man, you'll need to make a few changes to accommodate the White List application. See this thread.

 

[Lost Trunk]

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

The problem with that is that if you have external extensions, particularly users with softphones, PAP2's, SPA-2000's, Grandstream adapters, etc., you have no way of knowing what address these folks will be coming in from. Even if they never move their device, ISPs often change the IP addresses associated with residential/small business accounts. I've personally seen the same IP address persist for a couple of years and then one day it just suddenly changes (I was online at the time and actually lost connectivity for a minute or two, so the ISP must have rebooted the modem remotely).

Ward's "Travelin' Man" approach is probably workable for certain softphone users (e.g. you personally, if you're that security conscious). But just try and get others to use it. Think of your typical Windows user, who will sometimes freak out if they are required to type in a password! Many will just use the cell phone and burn minutes rather than fiddle with the extra complexity. And a user of a hardware ATA? Forget about it. If it won't connect by itself, they won't use it.

I do like the blacklist approach and I do like the SunshineNetworks Knock approach. I also wish there was a module (either FreePBX or Webmin, or maybe a standalone GUI program) that would just let us go through and check boxes for entire countries, or regions within countries that we want to allow traffic from, and ban everything else outright. But the "block everything and only whitelist the IP addresses you want" approach only works until the first time someone can't get in. Then you have to disable the entire firewall to try and figure out where they are coming from, and during that period (however brief) your system is wide open.

 

[ou812]

Thanks for the reply Joe.
I went ahead with the test and Ward's script worked perfect.
IAX trunk works in and out and my openVPN connection with an interoffice IAX trunk also works fine. Once again it seems you you have kept PIAF ahead of the pack.

Gary.

 

[wardmundy]

My real problem with the Blacklist approach is that someone has to constantly monitor and update the list. If someone wants to do that as a fee-based job where they take it seriously and take financial responsibility for missing entries that cause problems for your paying customers, I think that would be great. But... I'm not looking for any more work (especially high risk, low income ventures) so the Blacklist isn't going to be viable at least from my vantage point. I tried it for 5 days. Trust me. It was grunt work of the worst sort. :sweatdropb:

The Whitelist, on the other hand, is something that each user can take charge of and deal with personally. You keep it current, and your phones will work. Otherwise, the phones won't work. Providers rarely if ever change IP addresses. End users are responsible for keeping the IP address of their individual phone current. Pretty simple. And that's about the best we can do. :innocentb:

As for end users not using Travelin' Man, I disagree. They will learn to use it or their phone will stop working. All it takes is the boss saying... first thing every morning when you turn on your computer, run Travelin' Man or you're fired.

And, from a customer service standpoint, it's simple enough to identify if an extension is off-line in the FreePBX GUI. Yes, you may get a few support calls. But the script is pretty simple: "Have you run Travelin' Man lately?"

 

[The Deacon]

The Whitelist, on the other hand, is something that each user can take charge of and deal with personally. You keep it current, and your phones will work. Otherwise, the phones won't work. Providers rarely if ever change IP addresses. End users are responsible for keeping the IP address of their individual phone current. Pretty simple. And that's about the best we can do. :innocentb:

I agree. The easiest way to manage this is to explicitly deny all allow only what is necessary. It's just so much easier in the long run.

I went in and purged all my blacklist entries out of iptables and re-ran the script. It works flawlessly.

Thanks again, Ward!!!

-Rick

 

[bmore]

I do like the blacklist approach and I do like the SunshineNetworks Knock approach. I also wish there was a module (either FreePBX or Webmin, or maybe a standalone GUI program) that would just let us go through and check boxes for entire countries, or regions within countries that we want to allow traffic from, and ban everything else outright. But the "block everything and only whitelist the IP addresses you want" approach only works until the first time someone can't get in. Then you have to disable the entire firewall to try and figure out where they are coming from, and during that period (however brief) your system is wide open.

Apart from the problems of maintaining a Blacklist as Ward described... An allow all then deny bad guys type of security provides a false sense of comfort. The bad guys are always adapting. Look at how they adapted to fail2ban which then requires the good guys to adapt.

Ban a country they will use a proxy or infected bot pcs.... They will check the blacklist and find ips not blocked and so on. Much better approach while providing security is to develop a whitelist approach... They cannot get in unless they are at an ip you allow.

A module or standalone app is not hard to develop. The concept of combining a knock type approach and a hosts list can be implemented without a lot of complication.

 

[Lost Trunk]

Originally Posted by wardmundy My real problem with the Blacklist approach is that someone has to constantly monitor and update the list. If someone wants to do that as a fee-based job where they take it seriously and take financial responsibility for missing entries that cause problems for your paying customers, I think that would be great. But... I'm not looking for any more work (especially high risk, low income ventures) so the Blacklist isn't going to be viable at least from my vantage point. I tried it for 5 days. Trust me. It was grunt work of the worst sort. :sweatdropb:

I understand you not wanting to do that. Personally, I think that fail2ban and the SunshineNetworks Knock is probably good enough security. If you come from the standpoint that you can never have too much security, and you are extremely paranoid because you read a story maybe once a year about someone getting a huge phone bill (someone who probably never did a single thing to harden their system), then you can lock down your system however you want. I just think the whitelist approach is a bit much, though I would probably use it if there were a way to whitelist entire networks or entire geographic areas (for example, all Bresnan Communications users in Montana), because if I know what ISP my users are at and where they are generally located, I can effectively blacklist most of the world while still not having my users' phones go dead if their ISP changes their IP address.



Originally Posted by wardmundy The Whitelist, on the other hand, is something that each user can take charge of and deal with personally. You keep it current, and your phones will work. Otherwise, the phones won't work. Providers rarely if ever change IP addresses. End users are responsible for keeping the IP address of their individual phone current. Pretty simple. And that's about the best we can do. :innocentb:

Maybe your end-users are a whole lot smarter and/or more motivated than most users I've encountered. Personally, I think you're living in a bit of fantasy world where user expectations are concerned, but oh well.



Originally Posted by wardmundy As for end users not using Travelin' Man, I disagree. They will learn to use it or their phone will stop working. All it takes is the boss saying... first thing every morning when you turn on your computer, run Travelin' Man or you're fired.

Well, Ward, maybe that would work in some organizations. But are you going to threaten your mother, or one of your siblings in that manner? And also, I'm sure employees would wonder what sort of rinky-dink phone system the boss had installed, that forced them to jump through extra hoops to keep their phones working. If I were an employee and the boss said that to me, it would probably be one of the things I mentioned often when telling friends what an idiotic boss I had (also, all else being equal, I'd probably try not to work for that kind of boss any longer than absolutely necessary).

But, I guess I shouldn't say no one will do it - there are, after all, people who will put up with devices like Magic Jack. In my opinion about all a Magic Jack device is good for is running over with a steamroller. In my opinion, phones should work like they do on regular phone-company provided service - you pick up the phone and it just works. You shouldn't have to touch a computer to make your phone work.

Oh, and heaven help you if the phone stops working because you implemented overly-aggressive security and someone is not able to make an emergency call (assuming you are providing a service where they would have any realistic expectation of being able to do that). If you think the $50,000 phone bill is bad, wait 'til your company gets the $1 million+ judgment (you of all people should realize that's not impossible, given the crap-shoot nature of our legal system). Just sayin'.



Originally Posted by wardmundy And, from a customer service standpoint, it's simple enough to identify if an extension is off-line in the FreePBX GUI. Yes, you may get a few support calls. But the script is pretty simple: "Have you run Travelin' Man lately?"

And again, Ward, I think we should be looking for realistic, user-friendly solutions and while you may not think that Travelin' Man is intrusive, no disrespect intended but it's not something I'd want to be forced to use (of course since it's your baby, I know I'm beating a dead horse here). But then too, I'm thinking of the hardware adapter users. If you have to fire up a computer or smart phone to use a softphone client, then an extra click is not a big deal. But personally I hate softphones - I think they sound like crap and usually create horrible echo if the user is not wearing a headset.

But having said all that, I fully understand your desire to not want to continue the blacklist. I personally don't think either the blacklist or the whitelist are necessary if you use fail2ban (and the knock for extra security), but for those that don't have roaming extensions, the whitelist is probably a very good solution also. I just think it's a bigger risk to have phones stop working unexpectedly because of something you did than to not use every single available security measure, and have the extremely remote risk that you will get a huge phone bill that could have been prevented by implementing that tight lockdown (note it doesn't count if someone hacks into system in a way that all your security measures would not have prevented anyway). But, others may feel differently.

The question we should be asking is, how do the major commercial VoIP providers manage to secure their systems without causing unnecessary inconvenience for users? That's what we should be doing. I'm all in favor of a belt-and-suspenders approach, but I'm not going to wear a suit of armor, even if it would offer the maximum protection!

 

[jroper]

Hi

Lost trunk,

... if there were a way to whitelist entire networks or entire geographic areas (for example, all Bresnan Communications users in Montana)

You can certainly whitelist an entire ISP, just ask them for their IP address space.

Although there would be a number of of people who would be entitled, you have limited the hacker population to a few thousand, rather than several billion.

Coupled with Fail2ban, or OSSEC, and secure passwords, plus a prepaid telco provider, then I would say that for most cases the security is sufficient, and still usable.

Joe

 

[wardmundy]

The question we should be asking is, how do the major commercial VoIP providers manage to secure their systems without causing unnecessary inconvenience for users? That's what we should be doing.

Commercial VoIP providers have customers who sign up for accounts. If you don't have an account, you don't have access and can't make any calls. It's called a WhiteList.

As for grandma not being able to deal with Travelin' Man, nothing precludes your adding a WhiteList entry for the entire range of IP addresses being doled out by your grandmother's ISP. That still reduces your exposure by more than 99%.

 

[Astrosmurfer]

While this is true, having an account means userID and password and therefore a "whitelist". I think his question was meant to ask, how to the large ITSPs mitigate against brute force attacks and password guessing. They do not appear to restrict access base on IP address, in most cases.

Are they relying solely on complex userID/passwords? I doubt it. Are they using Fail2Ban? I really doubt it but, I'd expect them to use something similar.

I do know that many large providers use Session Border Controllers that do VoIP firewalling and IPS functions as well as other things. These systems are typically complex and very expensive. But, having said that, it would not surprise me in the least to find that popular session border controllers are built on Linux or FreeBSD.

 

[wardmundy]

Keep in mind that it is your nickel at risk, not the provider's, if someone guesses your username and password. So the provider has limited financial exposure from brute force attacks. Joe would be quick to tell you that credit card fraud is an entirely different can of worms for most providers.

 

[kh40s]

I hopefully should have a working solution that allows use of the iptables geoip extension and database in a few days. This way entire countries can be blocked at the iptables level. There's been some discussion of it on the forum as a desirable solution, but there are technical difficulties with respect to implementing it on a Centos platform as Ward discovered and noted in a post I read dating back from 2009.

The solution is non-trivial, since xtables-addons requires a minimum 2.6.18.5 kernel and so requires installation of a newer kernel, upgrades to iptables and the installation of kernel modules for the xtables-addons extensions. I will have a fully rpm based solution ready that will give all necessary functionality with the installation of a few rpms.

I'll post the solution so that the PIAF team can have a look over and evaluate it. Obviously, it will need to be packaged with some scripts to set it up and integrate it with PIAF in order for it to be of any use.

It won't be suitable for all environments as it uses a very new 2.6.36 kernel, although this is the elrepo mainline kernel built and packaged by the Centos team, so more reliable on Centos than just building a kernel from vanilla sources oneself. I've been running this kernel for a while now and have not noticed any issues with PIAF (I'm on Freepbx 2.8 and Asterisk 1.6).

 

[jack]

Hi,
I have run and test joe's iptables script + SunshineNetworks Knock + Firewall Whitelist for SIP by wardmundy + Fail2ban on a debian base asterisk system and it's working perfectly as I wish.

My iptables file looks like:

# Generated by iptables-save v1.4.8 on Wed Dec 1 20:50:11 2010
*nat
REROUTING ACCEPT [2:154]
OSTROUTING ACCEPT [99:6919]
:OUTPUT ACCEPT [99:6919]
COMMIT
# Completed on Wed Dec 1 20:50:11 2010
# Generated by iptables-save v1.4.8 on Wed Dec 1 20:50:11 2010
*mangle
REROUTING ACCEPT [2061:325088]
:INPUT ACCEPT [2061:325088]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1930:508313]
OSTROUTING ACCEPT [1934:509267]
COMMIT
# Completed on Wed Dec 1 20:50:11 2010
# Generated by iptables-save v1.4.8 on Wed Dec 1 20:50:11 2010
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:door - [0:0]
#-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 2 --name DEFAULT --rsource -j DROP
#-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource

# Filter 1- Whitelist for SIP & IAX (my voip service provider & google voice)
-A INPUT -s 64.27.1.153/32 -p udp -m udp --dport 4569 -j ACCEPT
-A INPUT -s 66.54.140.46/32 -p udp -m udp --dport 4569 -j ACCEPT
-A INPUT -s 66.54.140.47/32 -p udp -m udp --dport 4569 -j ACCEPT
-A INPUT -s 64.154.41.100/32 -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 10.0.0.0/8 -p tcp -m multiport --dports 22,80,139,443,445,4445,5038,9001,9022,9080,10000 -j ACCEPT
-A INPUT -s 172.16.0.0/12 -p tcp -m multiport --dports 22,80,139,443,445,4445,5038,9001,9022,9080,10000 -j ACCEPT
-A INPUT -s 192.168.0.0/16 -p tcp -m multiport --dports 22,80,139,443,445,4445,5038,9001,9022,9080,10000 -j ACCEPT
-A INPUT -s 10.0.0.0/8 -p udp -m multiport --dports 53,69,123,137:138,1514,4520,4569,5060,10000:20000,32852,50000:50100 -j ACCEPT
-A INPUT -s 172.16.0.0/12 -p udp -m multiport --dports 53,69,123,137:138,1514,4520,4569,5060,10000:20000,32852,50000:50100 -j ACCEPT
-A INPUT -s 192.168.0.0/16 -p udp -m multiport --dports 53,69,123,137:138,1514,4520,4569,5060,10000:20000,32852,50000:50100 -j ACCEPT
#-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -s 127.0.0.1/32 -i eth0 -j DROP
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

# Filter 2- SunshineNetworks Knock
-A INPUT -p udp -m udp --dport 5060 -m recent --rcheck --seconds 4000 --name portisnowopen --rsource -j ACCEPT
-A INPUT -p udp -m udp --dport 5060 -j door
-A INPUT -p udp -m udp --dport 5060 -j DROP
-A door -p udp -m udp --dport 5060 -m string --string "mysecretpassphrase" --algo bm --to 65535 -m recent --set --name portisnowopen --rsource
COMMIT
# Completed on Wed Dec 1 20:50:11 2010

Here is my simple Asterisk Security safety net flowchart:

Firewall_Portmapping(4569, 5060) -> Firewall_Whitelist(Filter 1) -> SunshineNetworks_Knock(Filter 2) -> Fail2ban(Filter 3) -> Asterisk_Server

Correct me if there is anything wrong.

 

[kh40s]

You should move the following rule to be the first rule. It's much more efficient. A large percentage of all traffic will be caught by this rule

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Why do you have FORWARD rules? Is your box multihomed and acting as a router? If not, you should remove the FORWARD rules and set policy to DENY.

The Sunshine Networks rules will never be reached as the following rule will reject packets before processing reaches these rules

-A INPUT -j REJECT --reject-with icmp-port-unreachable

You should move this rule to the end.

In your flowchart, fail2ban will be first as the chains get added at the top.

 

[bmore]

You should move the following rule to be the first rule. It's much more efficient. A large percentage of all traffic will be caught by this rule

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

It is probably there because the whitelist script added the whitelist above it. If you are adding whitelist rules via a script the script probably needs to add it to the top since you do not know what rules the user has that may cause the list to never be reached... sort of what happened when you add the knock at bottom.

 

[jack]

To kh40s and bmore:
Thanks for correction, much appreciated.

 

[kh40s]

It is probably there because the whitelist script added the whitelist above it. If you are adding whitelist rules via a script the script probably needs to add it to the top since you do not know what rules the user has that may cause the list to never be reached... sort of what happened when you add the knock at bottom.

It's definitely there because of that. It's the disadvantage of using scripts to add rules to the main tables. I use a similar whitelist type of mechanism, and the way I avoid this problem is to have the whitelist script add rules to a user-defined table, say WHITELIST.

So, in the main INPUT table, there is a single static rule along the lines of

-p udp -m multiport --dports 4569,5060 -j WHITELIST

And the WHITELIST table would then have a series of rules that look like

-s <whitelisted-ip-address>  -j ACCEPT

 

[wardmundy]

It's the disadvantage of using scripts to add rules to the main tables.

Very true. The WhiteList scripts ASS-U-ME you are using a stock version of PBX in a Flash or Incredible PBX. If you've made "improvements" to IPtables, then you'll probably also need to improve the scripts a bit before using them. Once you have a bunch of DROP rules in IPtables (which we don't use), then placement of the WhiteList would require a much more careful placement strategy... or a separate table.

 

[bmore]

Very true. The WhiteList scripts ASS-U-ME you are using a stock version of PBX in a Flash or Incredible PBX. If you've made "improvements" to IPtables, then you'll probably also need to improve the scripts a bit before using them. Once you have a bunch of DROP rules in IPtables (which we don't use), then placement of the WhiteList would require a much more careful placement strategy... or a separate table.

Does iptables have some kind of Include directive, where a file can be imported at run time? If so then it may be better to have something like this placed at the top:

Include Whitelist
Include Remotelist

You would manipulate the file and then restart iptables. For custom mods by an expert user, they could move the directive to wherever they wish.

 

[wardmundy]

Thanks, kh40s. Nice to learn something... every day!

I've reworked the scripts to implement the WHITELIST user-defined table. For those already using the existing scripts, just do the following to install and then implement the new system:

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

If you are using Travelin' Man, you will need to again adjust the entries to match the new syntax. See this revised thread for how to do that.

P.S. Once we get everyone migrated over to the new way of doing things, I'll revise the scripts to remove some of the error-checking. This will allow us to preserve the order of the entries in the main iptables file. For the short term (a week or so), whenever you run firewall-whitelist.sh, it will put all of the entries in iptables (these are the non-routable IP addresses as well as the rule that triggers WHITELIST review) at the bottom of the list.