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.
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.
Man that is a tough one....in that case I would configure a permit ip any any log, and capture everything. Then document the apps/protocols you see - take it to the customer and compare it with the network topology. Then decide what should be allowed and blocked.
"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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...