Firewalls: Stop Blocking by IP and Port

Tuesday, May 08, 2012

Phil Klassen

2e541940bc9b12ea62726bb51ed8787d

There has been some pretty good discussions about the usefulness of a firewall, and it would appear that the majority of the feedback is that firewalls are still an important part of the security infrastructure and will be around for some time.

I fully concur with this sentiment. However I am surprised that the discussion revolves around legacy features and not the features that are required to meet today's needs.

Any reputable firewall can block, permit, and NAT, but is that really what we are still looking for? The reality is that due to business requirements most firewalls look like swiss cheese with the number of ports that have been opened.

Additionally, practically every firewall policy will be defined with subnets instead of host addresses, because IP addresses are fluid.

Try and track Joe User over any length of time as he moves from cubicle to cubicle or hops on a wireless network. It's nearly impossible and you certainly can't rely on Joe to keep you informed when he moves around, so most have given up and just defined subnets so it will cover most of the users without disruption.

Back to application ports, does anyone have an environment where HTTP always uses port 80, or HTTPS just uses 443, and you can throw FTP into that mix.

Bottom line is if you are still trying to block based on IP address and port then its time to stop and look at firewalls can do today. The leading firewalls can block based on user, leveraging Active Directory. You can define single user-id's or AD groups.

These same firewalls can block on protocol patterns as opposed to ports.  So you can actually control a protocol like HTTP regardless of what port it uses.

Furthermore advancements with application aware firewalls can now do as good of a job of blocking access to Internet applications as most content filtering devices.  There have also been significant advancements in onboard IPS and AV.

I fully realize there has been growing pains in these areas by the firewall vendors but the leaders are doing a much more respectable job and can now hold their own.

You must still perform a good evaluation and above all do proper sizing. But, in the end, firewalls aren't dead but blocking by IP and port should be. 

Possibly Related Articles:
7246
Firewalls
Information Security
Firewalls Access Control Network Security applications IDS/IPS Legacy Systems Open Ports IP Blocking Subnets
Post Rating I Like this!
1de705dde1cf97450678321cd77853d9
Ian Tibble Phil, yes, agree, lets not give up on the extra functions dreamed up by vendors, and thanks for raising awareness of this because it wasn't discussed much in recent articles.

I have been part of reviewing efforts for by-user firewalls and also app protocol analysers. In these cases we didn't get as far as assessing the tech to see if it did what was promised by marketeers, but I've seen some damning reviews of products in these "smart firewall" areas.

Leaving aside the argument about whether or not firewalls should get intertwined with user authentication or app protocol analysis, are you saying you've seen these functions deployed successfully in complex, 10000-node+, live production cases?

I guess we need to take a step back and ask ourselves what it is we're trying to get from our firewalls, and that is really just packet filtering, for the purpose of slowing down attack efforts, and filtering by source/destination port and address goes a very long way towards achieving this. If the network is well designed and rulebases thoughtfully configured, firewalls do a lot for us, with just our good old legacy ideas.

Users and authentication/ tying in with LDAP/AD...obviously autotragic authentication is needed (we can't users to enter a password every time they need to fire up a TCP conversation), or tickets are granted with an expiry date, but this doesn't add much, and it gives ops another headache to manage. It can work in SMEs if the tech works - and i can't testify to that.
Though clearly, authentication on firewalls...for VPN, yes, definitely, but that's VPN, it's not a firewall. Its a firewall acting as a VPN gateway.

With the current picture with malware and so on, we have to assume that user subnets are owned. The key is just knowing where users are, and what resources they need to access. Telling our firewall to block access from user subnets to our critical infrastructure subnets is as good as we're going to get realistically - and in itself this is not so bad. The key is knowing where the users are. We get problems when we don't know which subnets they're in...like as i've seen, VPN pools were omitted in some cases!

If the tech works, i'm not sure app protocol analysis does so much for us, and it adds some operational resources requirements. So many protocols look and smell like HTTP - in fact they are HTTP, and when the bad guys use it, its always tunneled anyway.

IPS/IDS and AV on firewalls...same as WAFs...theres's a limited level of functionality we can implement, as in very limited, in fact so limited, why spend the money on it? The more we try to fine-tune things to do something actually useful, the further away we get from where we want to be, which is managing IT risk in a cost effective way.


1336549091
94c7ac665bbf77879483b04272744424
Marc Quibell Excellent Ian, couldn't have said it any better myself.
1336561298
2e541940bc9b12ea62726bb51ed8787d
Phil Klassen thanks for the input Ian - I am glad it spurred conversation. My main point is that technology is changing and we should at least include that in our evaluations. There is no perfect solution but perhaps by melding old school techniques with new solutions we can better protect our networks. Thanks again
1336573469
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.