So, hopefully in 2008, you're not finding yourself with an Internet connection and no firewall. But it seems to have happened to this guy. Though, I have worked on 2 projects in my past life where this was exactly the case, and we had to put in a firewall and develop policy around existing traffic, and do so without documentation or clear guidance from the company. And in fairness, I don't know that there's no firewall. It may be a situation where there's a firewall that needs replacing that nobody has access to. (That's happened to me before as well, but I digress.)
So here's my response to Ruggero. It was long, so I thought I'd also post it here:
Having done pretty much exactly this twice before, I can tell you that I wouldn't use a sniffer, and I especially wouldn't use an automated rule generator of any sort. You need to make sure any traffic you allow is deliberate and important to the organization. An automated tool won't make such judgments, and you will end up allowing all of the crap that's already on your network that you should probably be blocking.
My advice on how to proceed:
Step 1. Put the firewall in place with a policy that allows all traffic to pass. Turn on logging. Use this instead of a sniffer as analyzing firewall logs will be much easier. Putting the firewall in first will also separate the physical and routing changes you make to the network from the policy changes. This will aid in troubleshooting connectivity issues down the road.
Step 2. Analyze logs. I wrote a shell script to do this with PIX logs, and basically all I did was identify each of the unique sets of srcaddr,dstaddr,dstport and then count the number of times each unique set occurred in the log file. Sort results by number of occurrences and you will find either a) common traffic or b) crappy protocols at the top of the list.
Step 3. Investigate the results of your log analysis. Find out what each set is and then compare it to your business requirements and security policy. Determine whether or not the traffic should be allowed.
Step 4. Write rules for the traffic you decide to allow in Step 3. To help with your process, you may also want to write rules for traffic you wish to block.
Step 5. This is really a GOTO for step 2. You're going to eliminate known traffic from your logs and then analyze again. It's especially cool if the firewall includes rule numbers in its logs, so when you made those rules in step 4, it's now easier to separate known and unknown traffic. Loop through steps 2-5 for as many iterations as appropriate.
Step 6. Change from 'permit all' to 'deny all.' Once you've sufficiently analyzed data and implemented rules, cut over your default policy and test your business-related apps. If you made block rules in step 4 that are superseded by this policy change, you may want to remove them now in order to keep your firewall rule set as simple as it can be.
Step 7. Wait for the phone to ring. Depending on the size of the network and the volume of traffic, it will take you anywhere from a week to a month to get through step 6. Step 7 should last another 30-90 days, and basically you want to let the organization go through a long enough business cycle that things like payroll and billing can run through to completion at least once. You probably trampled on one or two things that are seldom used so they didn't generate traffic before, and this is when you find them and write rules for them.
Good luck. This kind of work is typically a real bear.
PaulM
There, now I don't ever have to lay that out again. :)
No comments:
Post a Comment