Re: [fw-wiz] Firewall policy generator, capture based - Any idea?



I would like to find out if you know any tool that can help me with this:

I want to capture my Data Center traffic, with a NAM or Sniffer.
Taken the capture I would like to have a tool that can interpret the
traffic flows and
automatically generate firewall rules to allow those flows.
I really don't want to waste time inspecting each single PCAP packet!

For example if there are multiple flows from the same subnet, create a
permit rule for that
subnet matching the destination range.

Basically a packetflow capture based firewall rules generator.

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. It 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.

Step 3. Investigate findings from logs. Find out what things are and then
compare them 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, they make it easier to separate the known from unknown traffic.
Loop through steps 2-5 for as many iterations as appropriate.

Step 6. Change from 'permit all' to 'deny all' policy. Once you've
sufficiently analyzed data and implemented rules, cut over your default
policy and test your business-related stuff. 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 to 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


_______________________________________________
firewall-wizards mailing list
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards



Relevant Pages

  • Re: [fw-wiz] Firewall policy generator, capture based - Any idea?
    ... idea what is actually allowed on your network. ... I want to capture my Data Center traffic, with a NAM or Sniffer. ... Basically a packetflow capture based firewall rules generator. ... Analyze logs. ...
    (Firewall-Wizards)
  • Re: Logon Failure - Where is the culprit IP.
    ... The only way to get the culprit IP is to use a firewall, sniffer or router ... logs [possibly with a free syslog client like www.kiwisyslog.com]. ...
    (microsoft.public.win2000.security)
  • Re: iptables & port redirects
    ... >> What is your default FORWARD policy? ... >> Is there any other rules before these that may match incoming http ... >> What do your logs show? ... by testing with an external (not on your LAN or firewall) ...
    (comp.security.firewalls)
  • Re: Strange WAN Activity
    ... > firewall logs for a possible TCP FIN scan that keeps ... > company's intranet server IP and its port 80 across our ... > My firewall is a Sonicwall Pro 200 and I'm running W2K ... It's difficult to be sure without inspecting the web server for signs of ...
    (microsoft.public.win2000.security)
  • Re: Winvnc hack! [25 KB]
    ... came in from a service such as IIS that logs IP address. ... Check your IIS ... Some firewall software such as ... You can also use the NETSTAT -A command that comes with Windows to look at ...
    (microsoft.public.win2000.security)