On Fri, 28 May 1999, Mark Wallace wrote:
> I believe that the firewall provides significant additional security
> by providing a tool which assists the network (security) administrator
> to do her job.
That used to be true. Now it's not so true, and becomming increasingly
less so. First of all- you make a *major* assumption that you have a
"network (security) administrator." Large companies have them, most
companies don't. If small companies have them, they don't generally have
sufficient clue to do an in-depth protocol risk analysis. That means
they turn on some of the silliest things. At that point, perhaps you can
explain what you mean by "do her job." That's an important distinction,
because if the job is to provide _network_security_, then it's not
happening in most cases. If it's to provide a single point of failure
chokepoint so that all the simple attacks can go though the same set of
NICs, then yeah - hands down. Note there's a substantial difference
between "go through" and "are stopped at."
> Wallace's first law of firewalls "The value of the firewall is not
> in the hardware or the software, but in the genius and professionalism
> of the firewall administrator."
Wallace obviously lives in a dream world where firewall administrators
can actually *do* something about firewalls. I've had times when I've
needed to pass protocols between internal segments which were firewalled
and I've had to go in and do source code modification on things to make
it work. Look at what's being sold in the market today and who it's
being sold to. You can't get there from here.
> I can't imagine recommending to any client that they deploy the
> level of resources appropriate to firewall administration to every node
> in the network. The laughter which drove me from the room would cause
> permanent damage to my ears. In the real world, my clients can only
> afford limited resources for security.
There's a *major* difference between spending limited resources on
security and spending them on a placebo.
> The firewall creates a checkpoint where security is emphasized over
> functionality. In that sense, it is a fortified platform from which the
No longer. We've given ground to enough braindead protocols that
functionality is now built into application layer transport protocols
such as HTTP. Look at the HTTP spec and then look me in the eye and say
it's a good protocol.
> security administrator can control traffic into and out of the network.
Can and does are completely different issues. Look if you will at the
Melissa virus problem and tell me what good firewalls did. Now
extrapolate that out to trojans over HTTP, stacks that don't need SYN
with no ACK to have a TCP conversation, entire ranges of UDP ports open
to hosts to allow RPC for "business critical" services... I'm *often*
asked to open RPC to NT machines by vendors who are shocked at my
flat-out denial.
> Marcus's arguments, apart from being idealistic, omit the administrator
> from the firewall. He is an integral portion of the firewall system.
> The firewall is a line in the sand. If the network is to be attacked,
> it should be attacked here. And I deploy my best network administrator
"Should be attacked here?" Sorry, but I think you're missing a great deal
if you're putting all your eggs in the "attacker does what they're
supposed to" basket. Apart from that, the entire base argument is about
what gets *passed through the firewall these days*.
> at that point, to carefully monitor the behavior and security of the
> firewall. If I believe that I'm under attack, I can quickly shift to
> a higher security posture, shutting down some services, negotiating
> some compromises with operations for the duration of the crisis.
In the next 5 years when those services *are* the business you're going
to mandate shutting down the business during an attack? The phrase
"infrastructure for electronic commerce" *should* scare the hell out of
all of us. *If* it's the type of attack that you can figure out and shut
down, (a) you're probably lucky and (b) the proverbial screening router
could serve the same function at a lower cost (since you most probably
already have one in place.) Now, care to enumerate the value of a
traditional bastion host again? Fred's hit it on the head IMO -
authentication and audit trails for the internal users. Security is
increasingly less of a service provided by a firewall.
> [Aside: I'm aware that I'm giving inappropriate short shrift to
> both insider attacks, and to modem policy/compliance defects. Those
> are, IMHO, intrinsically attacks which are not solved by a firewall.]
Nor are an increasing rang of attacks that are allowed to pass through
the firewall. Meet the issue - we're passing enough crap through bad
enough protocols that there are an increasing number of attacks which are
"intrinsically attacks which are not solved by a firewall." Discounting
attacks not solved by a firewall is ... um... well... let's just say not the
best predicate when discussing network security.
> Moreover, network administration must involve not only security control,
> but configuration control, user management, fault management,
> performance management, etc. I don't believe you're doing security
> management if you neglect these things. The firewall, and the associated
But you do believe you're doing it if you omit serious levels of host
security?
> logs give me insight into the behavior of my network.
Funnily enough, the firewall logs are the last things I'd look at for
insight into the behaviour of my network. Behaviour of my users, but not
the network.
> The negotiations over which protocols should be allowed provide two
> invaluable benefits. First, they give me insight into the real business
> needs of my customers. Second, they tell me how senior management
> views me. If they don't value the service I'm providing, it is time
> to drop back to a lower security posture.
If "lower security posture" means opening the business to significant
potential compromise, I think that's a complete disservice to everyone in
99.9999% of the cases it happens in. In fact, I can think of a lot
better words than "lower security posture." If you don't have the real
business needs of an entity mapped out prior to talking about passing
protocols you're way behind.
> Summary - if you consider that the firewall is a system, including
> hardware, software, policy, and professional administration, then
> I'd argue that firewalls are very much part of the solution. Indeed
> I argue that they're a necessary part, early in the solution.
Let's look at the state of the world. Attack vectors that bypass,
compromise, or tunnel through firewalls are becoming increasingly popular
in the segment of the attacker community that isn't interested in
breaking into Web and mail servers or trojaning dial-ups. The ammount of
data being passed through the typical firewall these days is so huge that
analysis is pretty much moot.
I think you'd be insanely surprised at what most firewall administrators are
told to pass through their firewalls. "Told to pass" because they *aren't*
security officers, they're the computer resource in a small business who gets
stuck with any information system. In a lot of cases, those businesses
are being led to insecurity by vendors with proprietary protocols that
don't work well in a hostile environment. Those vendors' margins are
huge if they dump leased lines and force their customers to open up
gaping holes in their firewalls. For a small business where that service
is a lifeblood service, the answer is almost always that they're forced
to accept the new risk to survive. In those cases, and they're becomming
increasingly common, the firewall isn't providing any value that a
screening router couldn't provide.
If the router vendors get to authentication and logging, firewalls are
mostly useless unless we see a culture change in protocols, applications and
services.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
