Firewall Audit program

Because running a program that some guy sent you on Usenet is thorough investigation?

Anyway, have a look at nmap, hping, the docs, and the archives of groups such as these. There's sure to be plenty of information. But without a more specific query, it would be hard to find any.

Joachim

Am Sun, 27 Nov 2005 04:08:58 -0800 schrieb Amit Gupta:

If you do not know yourself how to do that you are definitely the wrong person to do an firewall audit.

Wolfgang

Doing a review of a firewall policy, especially one of any size, is a useless attempt by mis-management to fix what they've broken and screwed up in the past, repeatedly.

Every entry to a firewall must be scrutinized when it is being made, and only open that which you need and nothing more. I have never worked in any organization that was willing to take measures to review policy. ONE--it is dangerous to review poilicy cause it means documenting out to many parties what they firewall rules are. TWO you are documenting screwups which managers will seek to hide. THREE most app developers and operations people DON'T know what ports they use so they will never tell you shut things down out of fear of causing an outage. FOUR--it can be a huge task.

If you've got few enough servers you can make some scans from speciifc networks, but every source network can have different accessiblity, so the larger the network the more implausible it becomes. Especially with various hosts.

An alternative it to focus on specific hosts and use extensive syslogging and reporting to examine what the servers actually do.

Review best practices and check if you follow them. DO you permit NetBIOS calls to traverse an internet firewall. Do you allow ALL outbound ports? This encourages worms, trojans, p2p, and more. DO you stop all inbound traffic. Do you filter out all bogon sources. DO you block all private IP addresses in and out.

When a server is retired, mark the retiring rules for deletion and craft new rules fresh. Lock things down appropriately. Organize a change in rules for a specific app by using traffic in syslog to define a tighter set of rules. Monitor DENY and NO TRANSLATION errors for hosts that you've changed rules for to detect missed traffic and be prepared to create rules on the fly to amend permission.

I've inherited several misconfigured firewalls and this is the only way I can see to clean things up. One has over 4,000 lines in the config. Getting people to redefine the port needs for a hundred+ different servers is just not gonna happen.

I am using the following one which is by no means comprehensive. I am sharing it with the group and any input is much appreciated.

1) The placement or location of the firewall 2) Vulnerability scanning the firewall from outside, e.g., Internet 3) The rulebase or security policy according to its vendor recommendation 4) I will also check the access control (ID, password and priviledges) to the system. 5) physical security of the system 6) Monitoring of the firewall log, to find out if any port scanning or hacking activities 7) Rulebase Change Control 8) Documentation 9) Backup 10) Please generously point out the missing pieces as you see it.

Any input/comments are greatly appreciated.

Thanks,

Doug

Pretty good list, Doug. Thanks for sharing it.

a. Control of outbound traffic - all allowed or all blocked except where specifically allowed?

b. Patch level of the firewall and OS, if applicable.

c. Number of administrators versus the number of administrators who actually log into the system to do something on a regular basis.

d. Is there a support (maintenance) agreement in place?

e. For Check Point, are the active implied rules correct for the company?

Ray

This list is starting to look most useful.

I'll toss in:

- log analysis that looks for obsolete rules and misconfigured internal hosts (in addition to malicious activity as previously mentioned)

- appropriateness of alert vs. log configuration

- incident response process: documented, tested?

Fundamentally, a firewall audit is about determining if it was built in accordance with policy and best practice, and whether maintenance processes effectively maintain security posture over time.

Triffid

Check Point's SmartView Reporter (now Eventia Reporter) has a built-in report listing which rules are used the most. It's very useful for this.

previously mentioned)

Gees, most of my "not allowed outbound traffic" drops comes from misconfigured hosts. Add a printer to a print server and typo the IP address, multi-homed hosts routing traffic out the wrong interfaces, network monitoring system trying to connect via SNMP to subnets that were removed years ago, etc. Network admins are one of my biggest problem areas.

Another good check is to assure that anti-spoofing is enabled on every interface and that the anti-spoof drops are being monitored. If everyone did this, DDoS would not be possible.

Ray

IMHO an audit should dig deeper, using flow analysis - i.e. identifying all unique source ip/destination ip/protocol triples permitted over some reasonable time period.

One often finds the flows in actual use represent a small subset of the flows permitted by the corresponding rule - i.e. the rule is in use, but is considerably more permissive than required.

Where I work, policy requires anti-spoofing to be enabled and generating alerts on all interfaces. I typically configure it to the host level (as opposed to simply reachable subnets), which often has pleasant side effects - sloppy network admins get harassed for generating 'spurious' alerts :-)

Triffid