topic Re: New Firewall Build - New Firewall Rules in Network Security

New Firewall Build - New Firewall Rules

87305 — Mon, 11 Mar 2019 15:04:17 GMT

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

Re: New Firewall Build - New Firewall Rules

andrew.prince — Fri, 13 Mar 2009 10:36:22 GMT

Chris,

Personally this is not the way to go about it. Before you install a firewall with an allow all - you should already know the topology of the network and what is required/what should be allowed.

Personally speaking.

HTH>

Re: New Firewall Build - New Firewall Rules

87305 — Fri, 13 Mar 2009 12:02:35 GMT

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

Re: New Firewall Build - New Firewall Rules

andrew.prince — Fri, 13 Mar 2009 12:05:35 GMT

Chris,

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.

HTH>

Re: New Firewall Build - New Firewall Rules

cisco24x7 — Fri, 13 Mar 2009 13:19:53 GMT

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.

Re: New Firewall Build - New Firewall Rules

lowen — Fri, 13 Mar 2009 13:51:06 GMT

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