New Firewall Build - New Firewall Rules

Unanswered Question
Mar 12th, 2009
User Badges:

Hi Everyone,


I am about to build a new firewall'd infrastructure in which a significant amount of traffic will be running through it. I need to lock this firewall down as quickly as possible.


Since there are no rules in place I will enable a “permit ip any any log” until all the infrastructure is in place and logg all matches to syslog. As soon as the infrastructure is in place - deny ip any any log!


Now I know I can go through the syslog server and identify all the traffic building rule by rule, creating object groups where applicable but I am looking for a method of easily identifying the required traffic rather than going through log by log? Any recommendations? Looking forward to your responses.


Cheers,


Chris


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
christopher.clayden Fri, 03/13/2009 - 05:02
User Badges:

Hi Andrew,



Thank you for the response. I completely agree that the best way to do it is not insert a permit ip any any and I also agree that the required traffic should be identified prior to the install. Unfortunately, I am walking into a large organization and the SME's are not aware of there own applications, both commercial and in house.


Unfortunately I have no choice. I have been forewarned that I must first identify the customer's traffic.


Thanks again.


Chris


cisco24x7 Fri, 03/13/2009 - 06:19
User Badges:
  • Silver, 250 points or more

The best tool for this is NetFlow data. I don't know how good the ASA5580 netflow data is compared to IOS netflow data. Never had any experiences with Netflow on ASA.


If you're talking about non-cisco firewalls like checkpoint, then the answer is very simple.



lowen Fri, 03/13/2009 - 06:51
User Badges:

"permit ip any any log" will get you non-tcp/udp stuff that might be interesting (gre, etc.), but is really not good for analyzing your tcp and udp traffic, which will be the bulk of you traffic.


Better would be promote the tcp/udp connection build and teardown messages to whatever level your using to log:


logging message 302015 level errors

logging message 302014 level errors

logging message 302013 level errors

logging message 302016 level errors

(substitute whatever level your "logging trap" command specifies for errors)


The "permit ip any any" will probably record more hostile than legitimate traffic, and you'll have no basis to tell the good from the bad. A compromised host with a backdoor being used by lots of remote hosts will look as legitimate as smtp to your mail server based on the acl log data.


With the tcp connection teardown messages, you'll have the reason the connection was torn down. You can immediately throw out anything with a SYN timeout, and most stuff with Reset-I that has a very small byte count. Most UDP connections that timeout at *exactly* 2:00 are bogus, too (your mileage may vary).


This will, of course, generate a lot of stuff, so you'll probably need to write a script to massage the log files, extract "interesting" fields", and create a csv to stuff into a spreadsheet. You can then sort the spreadsheet in various ways, which makes certain patterns obvious (hundreds of connections to tcp/80 from hundreds of sources *probably* indicates a legitimate website; connections to the same port on every machine in your address space from the one remote machine is almost certainly a scan). After you've thrown out all the obvious crap, it's still the application/system "owners" that will have to make the call on legitimate vs illegitimate.


You should also at least beg for permission to block some stuff (very low tcp/udp ports, MS NET ports, probably SQL, etc.) right out of the gate.

Actions

This Discussion