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



While not a sniffer, check out Redseals product, it will generate flow based
upon your network configurations and firewall rules so you can get a good
idea what is actually allowed on your network. From there you can start
locking it down.


----- Original Message -----
From: "Paul Melson" <pmelson@xxxxxxxxx>
To: "'Firewall Wizards Security Mailing List'"
<firewall-wizards@xxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, January 30, 2008 9:08 AM
Subject: 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


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



Relevant Pages

  • Re: Identifying Internet Attacks
    ... contain the hacker to a particular machine, leave the machine on the network ... Some firewall software such as ... open ports; however, this will not identify which program is using the port. ... firewall logs, the IIS web and ftp server logs and Windows security event ...
    (microsoft.public.inetserver.iis.security)
  • Re: [fw-wiz] Firewall policy generator, capture based - Any idea?
    ... I want to capture my Data Center traffic, with a NAM or Sniffer. ... Basically a packetflow capture based firewall rules generator. ... Put the firewall in place with a policy that allows all traffic to ... Analyze logs. ...
    (Firewall-Wizards)
  • Re: Virus on PC?
    ... I have a firewall on my network with content filtering and have checked my logs and found one of my machines is sending a message over the web every 10 minutes. ... I have googled and found that this site address is for the ICQ network. ...
    (uk.comp.homebuilt)
  • Re: Virus on PC?
    ... I have a firewall on my network with content filtering and have ... checked my logs and found one of my machines is sending a message ... There is no ICQ installed on the machine. ...
    (uk.comp.homebuilt)
  • Re: FTP Serv-u
    ... This is a good reason why you need to secure every computer on your network, ... If IIS web services were used to enter the computer, ... logs were tampered with]. ... I would also check your firewall logs. ...
    (microsoft.public.win2000.security)