All,
Most folks I have spoken with have trouble figuring out what they should
allow in or out of your network, especially if it is a "retrofit" i.e.
installing a security perimeter enforcement point where there was none
before. This difficulty stems partly from the profusion of TCP ports used
by some modern operating systems, as well as FUD created by users demanding
simultaneously to be protected from "bad guys" while losing absolutely no
flexibility over their Internet connection.
** I want to say unequivocally that working from the "default-drop" policy
is certainly the safest. **
However, installing a retrofit firewall in default-drop configuration can
result in hordes of annoyed users, some of whom may have direct control of
the security budget. :)
Even if your firewall rules are an absolutely-perfect instantiation of the
corporate security policy, a default-drop policy can miss many
"low-percentage" connections, some of which may be critical to business for
your organization (a good example is a nightly FTP batch session to or from
a service provider, like a printshop or fabrication house).
Even though well-intentioned, your security policy may _not_ provide for
these business-critical connections to be allowed through the firewall.
And more generally, some firewall implementers may simply not _know_ what
they should allow out or in to their network.
Here's a suggestion I have heard from several security professionals in the
field who install firewalls frequently into environments where there were
none before:
**
1) Install the firewall in "pass-all" configuration, with full logging
turned on -- FOR ONE WEEK only. This assumes that there was no firewall
before, so security is no _worse_ than it already was.
2) After that one week (or month or ...), review the logs for two types of
traffic: a) persistent and high-volume traffic (both incoming and
outgoing), and b) sporadic but repetitive traffic
3) Compare both (a) and (b) types of traffic with the corporate security
policy to determine acceptable-use connections
4) Create a new security policy on the firewall to "default-DROP-ALL", and
then add exceptions, both for incoming and outgoing traffic -- but only
that subset which meets corporate security guidelines
5) Be prepared to answer calls (or be proactive and make calls) regarding
services that will be cutoff as a result of outbound sessions which do not
meet security policy
6) Carefully monitor inbound sessions which were allowed and are now
denied for signs of systematic probing or scanning. These should be traced
back to their service provider, if possible.
**
The key here is that the firewall is installed in "monitor" mode for some
small period of time, to gauge the type and amount of traffic that passes
across your perimeter. Then, go back and install the default-drop rule, and
add exceptions -- not blindly, but armed with the knowledge of exactly who
you will be cutting off, and why.
(Of course, if you already have a firewall -- install the new one in front
(or behind) of it for a week. Again - no worse than before. Don't just
replace it willy-nilly with a pass-all firewall!)
This procedure makes it much less socially-painful to add a firewall to an
environment where folks are accustomed to having free reign on the public
Internet.
Your alternative is to simply fabricate a security policy which you, or
someone else, believe to represent all the traffic which should pass across
your security perimeter:
("Well, let's see now. We should allow outbound HTTP to anywhere, unless we
want to force folks to use our caching proxy server. And we want to allow
inbound SMTP, but only to our gateway mail servers. And we need to block
mail from known spammers. I guess we should allow outbound SMTP too, that
makes sense...but which machines are mail servers? Oh yeah, we have to
allow inbound DNS to the split-horizon name servers in the DMZ. What about
outbound DNS? I can't forget about the public web servers owned by the
Customer Care people -- what were those addresses again? And that reminds
me, the folks in Marketing want to use NetMeeting, so I have to allow H.323
outbound... but what about inbound calls -- how will that work with NAT?
Should I even allow inbound calls? And what about RealAudio anyway? ..... !!)
So.
Once more, to be absolutely clear: INSTALL A PASS+LOG FIREWALL POLICY FOR
SOME SMALL PERIOD OF TIME ONLY!!!
Then, analyze the logs, and INSTALL A DROP-ALL FIREWALL POLICY, and add
exceptions ONLY when they conform to your corporate security policy
(i.e. DON'T allow connections to ports 137-139 -- even if someone wants to
mount their shared NT disk across the Internet! Tell them no.)
This procedure has always made sense to me. But I'd love any comments.
Good Luck,
-David J. Cavuto
Lucent Security Products
At 02:14 PM 3/6/2000 , Ryan Reynolds wrote:
>Steven:
>
>Most firewalls have an 'implicit denial' feature that states that anything
>not specifically allowed is disallowed. Your average everyday
>overly-paranoid security admin will usually throw in a rule at the end of
>the ruleset that denies everything. Firewalls tend to read the
>rules in numerical order, so if a packet comes in and gets a match on rule
>5, the firewall will not look any further, it will simply
>perform the action specified by rule 5. There are exceptions to this, but
>in general it holds true. This means that you can explicitly
>allow all the services you want to pass through your firewall, then put a
>rule at the end that basically says "deny everything".
>
>Denying ports is essentially the same thing as denying services. Services
>are defined by the ports they run on. For example, standard
>http runs on port 80, so if you want to deny all http on a packet-filtering
>firewall, you would deny all traffic to port 80. Proxy based
>firewalls and stateful inspection firewalls do not work exactly the same,
>but the idea is similar.
>
>Your general approach to developing a security policy should go something
>like this:
>
>1> Sit down with whomever you need to and figure out what
>programs/services/etc you want to work from the inside out and from the
>outside in.
>
>2> Research each of these programs/services and find out what ports it uses.
>
>3> Write your firewall policy to allow only those programs/services, then
>put the deny all rule at the end.
>
>Doing this should give you a very good start.
>
>-Ryan
>
>Steven Pierce wrote:
>
>> Jon,
>>
>> I am new to all of this. What is needed to deny all the ports? I know
>about dening the specifc IP or user base. Is that the same??
>>
>> Steven
>>
>> *********** REPLY SEPARATOR ***********
>>
>> On 3/6/2000 at 11:14 AM Jon Earle wrote:
>>
>> >I normally block all _inbound_ access, except to ports I expressly allow:
>> >tcp/25, udp/53 + tcp/53 (with BIND config. restrictions on who can initiate
>> >zone transfers), tcp/80, and maybe one or two others, depending on our
>> >requirements. Source ports on packets destined for these services are
>> >restricted to unpriviledged ports (1024:65535), except in the case of
>> >udp/53, in which I allow unrestricted (remote) source ports. Inbound
>> >packets are restricted to the access granted above, plus response packets
>> >destined for unprivileged ports, coming from services expressly allowed in
>> >the outbound rules.
>> >
>> >I typically restrict outbound access to specific services (tcp/80, tcp/21
>> >and a few others for clients, tcp/25, tcp/udp/53 for the firewall), and
>> >block source ports which are less than 1024, thus only allowing
>> >unpriviledged source ports for outbound access. This is good to control
>> >exactly what is leaving your network, but depending on your requirement
>> >(home LAN vs client LAN) you may or may not want to allow all outbound
>access.
>> >
>> >So, yes, it sounds like you're on a good start: deny everything, then open
>> >up only what you need.
>> >
>> >
>> >At 03:34 PM 3/6/00 +0000, you wrote:
>> >>Hi,
>> >>We are going to using altavista firewall and proxy on a NT box. I know
>> >>that I sould
>> >>close all other services on NT,
>> >>change administration account name,
>> >>block 6665-7000 for chat
>> >>block all tcp/udp except 80.
>> >>What else sould I do, for example what is BO trojan ports?
>> >>Can somebody send port numbers and/or other things that sould I write to
>> >>my firewall.
>> >>thanks.
>> >>______________________________________________________
>> >>Get Your Private, Free Email at http://www.hotmail.com
>> >>
>> >>-
>> >>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>> >>"unsubscribe firewalls" in the body of the message.]
>> >
>> >-----------------------------------------------------------------
>> >Jon Earle (613) 612-0946 (Cell)
>> >HUB Computer Consulting Inc. (613) 830-1499 (Office)
>> >http://www.hubcc.ca 1-888-353-7272 (Within Canada/US)
>> >
-------------------------
David J. Cavuto, Systems Engineer
Lucent Security Products - http://www.lucent.com/security
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
