On Wed, Mar 17, 2004 at 03:01:50PM -0800, bill said something to the effect of:
> "the primary purpose of a firewall is to keep the bad
> guys away from the buggy code. Firewalls are the networks' response to
> the host security problem."
a pretty good sound bite.
> Add to that that you don't really know what's
> safe or unsafe, and that you have some services that are convenient for
> insiders but don't have adequate, scalable authentication on which you
> can build an authorization mechanism, and you see why firewalls are
> Perfect? No, of course not. A good idea? Absolutely.
Who is configuring the "firewall"? What are its capabilities?
You are. Your network engineer is. The needs of your network and staff
dictate the demands and deploy a mechanism suitable enough to satisfy
them. This is not a question others can answer for you in the
How easy will it be to deploy new services? I, as an enduser,
That will depend on the services. If you ask most to stream Kazaa into
your cube at work, they'll laugh at you. If you want to route
jellybeans-over-IP, you'll likely not be considered. If you're at the
helm at the office or at home, then it's as easy as you make it and you
can do what you want within the scope of your provider's AUP..
Again...competent security engineer...comes to mind...
am abdicating most of my responsibility to or it is being hijacked
by one or more network service providers. Ken is right.
This is the job of the edge/customer/network administrator, or a 3rd party
agent contracted to provide managed security services. Most NSPs do not
do this (granular filtering) unless engaged (and paid) directly by the
customer. Is that what has your dander up? This is the
job/responsibility/whim of the subscriber, for the most part.
Firewalls, in general, seem to be a great place for blackhats
to focus on.
What? No...unprotected systems are the great places for blackhats to
focus on. Where are you getting this? I apologize for sounding
potentially antagonistic, but I am having a difficult time discerning
between devil's advocacy and counterintuition in your opinions regarding
secure network praxes.
Single points of failure are prime targets for attack, too, by the way.
As are unchecked portals and ingress vectors. Eschewing security mechansims
(physical, logical, DR, etc) contribute to both.
DoS is trivial,
Please tell me you did not just go there...
Network outage is not trivial. Not ever.
One more time...where are you getting your information? That clause is
patently incorrect. Please remember virii and node subversion when you
head in that direction, as well, as granular security is not just about
the degenerate case is encaps
of everything into stuff that passes through the firewall
(IP over port 80), and then we've just pushed the problem
What kind of firewall are you talking about? Who does this?
elsewhere, adding more complexity to the system for little
if any improvment in the overall integrity. Sounds like
the result is a system that is more fragile.
Broken record...from where did you derive this information?
And how better do you propose to restrict access to a network than
filtering/firewalling or somesuch similar level of access control? Or is
it (as you have not yet answered this) your position that a network should
remain open and unsecured? Not your service provider's network...but
networks in general. What, in no uncertain terms, do you believe belongs
keeping watch over your network perimeter? Also, what constitutes
acceptable loss and/or outage in your organization? It is entirely
possible and I am increasingly hopeful that you and I are simply talking
about 2 totally separate things.
For the record...the top 2 Achilles' heels to network security are improperly-
protected edge devices (i.e., web servers, unpatched desktops, unsecured
routers, etc), and protocol-related vulnerabilities (i.e., SNMP, DNS/BIND).
Your concern for thwarted network application development leads me to
enlist you and yours to fix inherently weak protocols (SMTP, for example)
to make networking itself again more robust before I agree to see a
security layer as superfluous. And then there are software purveyors to