Re: Firewall Best Practices

From: Eirik Seim (eirik@peter.mi.uib.no)
Date: 02/07/02


From: eirik@peter.mi.uib.no (Eirik Seim)
Date: 7 Feb 2002 10:34:51 GMT

On Wed, 06 Feb 2002 20:09:29 GMT, Roger Marquis <not-for-mail@roble.com> wrote:
>
>Comments appreciated.

And comments you'll get. This looks like an interesting project, feel
free to contact me by email if you'd like. This NG gets awfully crowded
sometimes..

>--------------------------------------------------------------------
> Firewall Best Practices (draft)
>--------------------------------------------------------------------
>
> 1 Know what every rule does
>
> 1.1 Be sure you know exactly what every single rule does

Of cause, everyone here on this NG understands that this means "Be sure
you know exactly what each and every rule does, and how it affects the
ruleset as a whole."

I'm thinking of instances where several people with a various degree of
knowledge has mocked around in the firewall rules, making "holes" in existing
rules to get that important application available, not having the time
to document the change, the extra rules, and so on, and so on.

> 1.2 Know your TCP and UDP ports

..both inbound and outbound ports and port ranges..

> 2 If you cannot figure out what a rule does delete it (and see whether
> anyone notices)
>
> 2.1 Never violate rule #2

Problem is if this rule was important, the moment anyone notices, or should
I say "notices enough to tell anyone", the network behind the firewall might
already be compromised.

If you cannot figure out what a rules does, then study the documentation,
both the vendor's (if any) and whatever the people created that rule might
have produced (if any).

If this does not help, test the rule or preferably the complete ruleset in an
isolated environment, and if that won't give you a clue either, start
studying the documentation again.

At least, that's my opinion. Feel free to disagree :)

> 3 Know your applications and risks (active-x for example)
>
> 3.1 Get management buy-in for any controversial or potentially
> disruptive filtering
>
> 3.2 If you cannot get management buy-in be sure to CYA by
> documenting the risk (always assign dollar values)
>
> 3.3 If you have to CYA be sure the risk analysis is adequately
> distributed, beyond your direct manager
>
> 4 Know what the firewall is protecting

..and who it is that you're protecting this from.

> 5 Always log and read the syslogs frequently

..and keep those logs as long as possible.

> 5.1 Consider increased rule-specific logging (at least temporarily)
> when changing rules

And increased logging is also a good thing when optimizing rulesets.

> 5.2 Use Intrusion Detection Software (NIDS, HIDS, AIDS) wherever
> the business case permits
>
> 5.3 Configure IDS alerts and alarms carefully

..and keep those logs as well :)

> 7 Audit thoroughly and often
>
> 7.1 Have someone else perform audits periodically
>
> 7.2 Use the most experienced and knowledgeable auditors /
> consultants / engineers possible (this is not an area where
> it is typically worth considering a low bidder)

But don't take it for granted that the guy who's asking $300 an hour is
going to make your network more secure than the guy who'll do the job for
$100 an hour. I believe in using experienced and knowledgeable auditors, but
also _different_ auditors. Maybe not for each audit, but switching often
enough that you won't allow this one guy ignore the same problem month after
month.

> 8 Read several security newsgroups and mailing lists daily

Especially the security alert lists many vendors provide..

- Eirik

--
Eirik Seim                        System Administrator
eirik.seim@mi.uib.no              Math. Department
http://www.mi.uib.no/~eirik       University of Bergen



Relevant Pages

  • Re: Strange WAN Activity
    ... > firewall logs for a possible TCP FIN scan that keeps ... > company's intranet server IP and its port 80 across our ... > My firewall is a Sonicwall Pro 200 and I'm running W2K ... It's difficult to be sure without inspecting the web server for signs of ...
    (microsoft.public.win2000.security)
  • Re: Winvnc hack! [25 KB]
    ... came in from a service such as IIS that logs IP address. ... Check your IIS ... Some firewall software such as ... You can also use the NETSTAT -A command that comes with Windows to look at ...
    (microsoft.public.win2000.security)
  • RE: [fw-wiz] Log checking?
    ... tend to evaluate where and what logging is important in a different light. ... I've been happy to analyze a year's worth of firewall denied logs, ... have denied firewall traffic logs or denied logs with any relevant data. ...
    (Firewall-Wizards)
  • [HOWTO] IPFW: Vector-Based Modularity
    ... Complex Firewall ... For this purpose the local host should be considered an interface of its own in the form of the IPFW alias, ... The IPFW ruleset begins with a series of skipto rules directing matching traffic to a rule module. ... 00400 set 0 deny ip from any to any ...
    (freebsd-questions)
  • Re: false portscan alarm
    ... What is the reason of that treffic? ... and the browser and/or the "personal firewall" had decided to close those ... which each have a local source port above 1024 opened outgoing to port 80 ... I've had a dig through my own PIX logs, and while there is nothing for today ...
    (comp.security.firewalls)