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 useful.
Perfect? No, of course not. A good idea? Absolutely.
Er... perhaps.
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 hypothetical.
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 DoS...
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 visit. --ra -- k. rachael treu, CISSP rara@navigo.com ..quis costodiet ipsos custodes?..
--Steve Bellovin, http://www.research.att.com/~smb
--bill (cynic)
Noting that the nanog thread of the day has changed, but not n'cessly for the better. :)