Considering a migration from ScreenOS to Junos? – Time to restate your assumptions

[#1]

This is a guest blog post. Views expressed in this post are original thoughts posted by Glen Kemp, Solutions Consultant at SecureData Europe. These views are his own and in no way do they represent the views of the company he works for.

Firewalls are like dairy products; they don’t stay fresh for long.  Decisions made during your last platform refresh or even initial design won’t necessarily ring true once any time has passed.  The reality of enterprise networking is that the final link in the “design – implement – operate – analyse –design” life cycle doesn’t happen anywhere near often enough. The fact is the design and implementation stages of a project are almost always hurried to get into the operational phase as soon as humanly possible.  The analysis which goes back into the design only tends to happen when there is a significant failure or an external motivating factor (such as the end of life of the NetScreen 25).  If you are going to take the leap and migrate from ScreenOS to a Junos platform; it’s worth revisiting the original design and the assumptions made insofar of the technology chosen; the capacity of the network and the level of resiliency required.  It is very likely that if you were to take your current requirements and create a design based around them, your network would look nothing like it does at the moment.  Given that for many organisations no infrastructure changes are made without a supporting project code and associated CAPEX, there are few other opportunities to fix the things which aren’t as they should be. 

So, Carpe Diem people; it’s time for some security spring cleaning (ok, autumnal) of your Internet facing infrastructure.  A firewall policy review pretty much goes without saying.  Tomes have been written and there are commercial products which will automate it, but no-one knows your network better than you.  Even when faced with a nine hundred rule monster, it’s worth spending the time and weeding out what you can.  Most firewall administrators log pretty much everything by default, so it’s not normally that hard to detect which rules are infrequently matched. 

Top candidates for removal:

1. Outbound Access for that random appliance you were asked to evaluate and didn’t purchase
2. Inbound RDP for the web-developers you used to use who couldn’t figure how to set up a VPN
3. That “Any/Any/Any Accept” rule for the parent company that you’ve always been deeply suspicious of

The physical configuration of interfaces is frequently overlooked, depending on the age of your infrastructure there is chance there are 100mb switches (or even hubs!) kicking around your Demilitarised Zones (DMZ). Given the price of switching, they need to go.  Another classic is the permeation of Virtual Hosts on physical DMZs. No-one ever seems to want to make a decision as to whether these hosts should be trunked from the core or have one-to-one mapping to a physical interface, so I usually see both.  For the sake of efficiency most just use trunked DMZs; but it’s worth revisiting every instance where you have this physical/logical dilemma and standardising the approach.

There are a probably a hundred crazy things that will be unique to your organisation which need some sort of attention. It’s worth asking some additional questions: Is an ASIC based design still vital? Do I need interface level resiliency and how many physicals should I dedicate to clustering? Once you’ve identified the answers this can be fed into the “What our network should look like” design, which then influences technology you may ultimately adopt. 

Doing a straight technology like-for-like swap may be the path of least resistance, but not doing a proper analysis is a missed opportunity to get your network into better shape and better able to cope with shifting requirements and priorities. Get it right, no-one will notice; get it wrong (or don’t even try) and be prepared to be spending more time with the office coffee machine than your kids! Now to get all interactive like a 1990’s Multimedia CD-ROM; I’d be interested in the horrors you’ve uncovered during a firewall migration; Internet Router connected to the core for “convenience”? All networks on the same Zone with “Block Intra-zone Traffic” disabled? Home Broadband IP of “sacked in disgrace firewall admin” in the “manager-ip” list? I’m sure you’ve found worse.

[#2]

Very nice blog Glen, I used the Netscreen products way back when - even before Juniper bought them. Been a trip via Checkpoint and ASA/FWSM and now finally SRX - that is once they come in - for me :-)

[#3]

Great post, man.

I agree that spring cleaning is absolutely necessary in a firewall migration. In fact, sometimes I'd go so far as to say it's almost easier to just request requirements and configure from scratch. It's amazing how many "we dont know what that rule does, so just leave it out" rules that can be eliminated. 

It's also a good time to start to enforce firewall change logging. One of my customers inserts a change request ticket number into the description of every rule that gets made.

Firewall migration is never a fun thing, but like you said, it's certainly necessary.

Chris

[#4]

Nice post Glen

I am still amazed that lots of organisations still believe that because they have a firewall they are secure. Yet when you review their rulebase you find rules like you highlighted. 

On the flip side I do find organisations that have a very tight rulebase and believe that is enough to keep them secure. When you tell them about SQL injection and DNS Tunneling their jaw drops in surprise of such means of gaining access out of a network.  

When it comes for the time to look at a replacement or upgrade of the firewall then as Chris says the requirements should be re-defined as the security landscape has changed massively from when the firewall was first implemented. Features like IPS, Application Identification, Dos Protection  etc.

As Chris says it would be ideal to start from scratch but unfortunately too many businesses want minimum downtime and therefore migrate the current setup as it is and then say they will tidy up later. 

Sometimes the best course of action is to advise on best practices and make recommendations for improvement.

Ken

[#5]

Thanks for the comments chaps, much appreciated:

Jasper, pretty much the same journey I've been on then! I do see the same mistakes repeated again and again across firewall platforms, although obviosly the there policy implemenation differences between Zone-based and Policy Firewalls, the use of "Any" seems to be a universal crime!

Chris, You are correct, in many cases it's a good idea to start again from scratch but sadly not always possbile. The biggest issue I tend to run into is rekeying the objects, I've some customers with a couple of thousand of them (!) and it's sometimes even harder to work out what's in use.  I wish more people would put in the change referencce in the comments field, or at least _something_ to describe what the rule is for, trying to intuit this after the fact is next to impossible.

Ken, you make a good point there; the worst offendors are organisaiton who throw IDP & Event log manamgement and fancy "Sandboxing" without paying any attention to any of it.  The technology needs to be fed and watered properly, it's presence doesn't automatically make your network "secure" or prevent infection / penetration. A well configured, up to date firewall will protect a network better than all the technology under the sun deployed badly or inappropiately.

Thanks for the discussion guys

Glen