Re: Telco's write best practices for packet switching networks
In message <gu9ofi1rcwe.fsf@rampart.argfrp.us.uu.net>, Eric Brandwine writes:
Firewalls are good things for general purpose networks. When you've got a bunch of clueless employees, all using Windows shares, NFS, and all sorts of nasty protocols, a firewall is best practice. Rather than educate every single one of them as to the security implications of their actions, just insulate them, and do what you can behind the firewall.
When you've got a deployed server, run by clueful people, dedicated to a single task, firewalls are not the way to go. You've got a DNS server. What are you going to do with a firewall? Permit tcp/53 and udp/53 from the appropriate net blocks. Where's the protection? Turn off unneeded services, chose a resilient and flame tested daemon, and watch the patchlist for it.
Precisely. You *may* need a packet filter to block things like SNMP (to name a recent case in point), but a general-purpose firewall is generally the wrong solution for appliance computers. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com
On Wed, Mar 06, 2002 at 09:41:55AM -0500, Steven M. Bellovin wrote:
In message <gu9ofi1rcwe.fsf@rampart.argfrp.us.uu.net>, Eric Brandwine writes:
Firewalls are good things for general purpose networks. When you've got a bunch of clueless employees, all using Windows shares, NFS, and all sorts of nasty protocols, a firewall is best practice. Rather than educate every single one of them as to the security implications of their actions, just insulate them, and do what you can behind the firewall.
When you've got a deployed server, run by clueful people, dedicated to a single task, firewalls are not the way to go. You've got a DNS server. What are you going to do with a firewall? Permit tcp/53 and udp/53 from the appropriate net blocks. Where's the protection? Turn off unneeded services, chose a resilient and flame tested daemon, and watch the patchlist for it.
Precisely. You *may* need a packet filter to block things like SNMP (to name a recent case in point), but a general-purpose firewall is generally the wrong solution for appliance computers.
Hmm...but certainly part of the right solution for a general "appliance" network. -ron
On Wed, 6 Mar 2002, Ron da Silva wrote:
On Wed, Mar 06, 2002 at 09:41:55AM -0500, Steven M. Bellovin wrote:
In message <gu9ofi1rcwe.fsf@rampart.argfrp.us.uu.net>, Eric Brandwine writes:
Firewalls are good things for general purpose networks. When you've got a bunch of clueless employees, all using Windows shares, NFS, and all sorts of nasty protocols, a firewall is best practice. Rather than educate every single one of them as to the security implications of their actions, just insulate them, and do what you can behind the firewall.
When you've got a deployed server, run by clueful people, dedicated to a single task, firewalls are not the way to go. You've got a DNS server. What are you going to do with a firewall? Permit tcp/53 and udp/53 from the appropriate net blocks. Where's the protection? Turn off unneeded services, chose a resilient and flame tested daemon, and watch the patchlist for it.
Precisely. You *may* need a packet filter to block things like SNMP (to name a recent case in point), but a general-purpose firewall is generally the wrong solution for appliance computers.
There is no need to drop traffic for things that aren't listening. Eric's point was you deploy your fancy-dan mail server with ONLY 22 and 25 listening, you know that's all that's listening and your daily/hourly/weekly/monthly automated audits tell you this continually and alert when there are problems/deviations. So, why filter anything in this case? It's wasted bandwidth/processing power.
Hmm...but certainly part of the right solution for a general "appliance" network.
If you run a little network where you know 'precisely' the ins and outs there isn't any reason NOT to have a firewall, IMHO. At the very least for logging/auditting info it's a must. For a backbone filtering is another story entirely. Filtering backbone equipment for it's protection is also a completely different topic... -Chris
On Wed, Mar 06, 2002 at 03:04:00PM +0000, Christopher L. Morrow wrote:
...For a backbone filtering is another story entirely. Filtering backbone equipment for it's protection is also a completely different topic...
Filtering on the backbone is exactly what I mean. Clueful backbone providers should know the ins and outs of their data... -ron
On Wed, 6 Mar 2002, Ron da Silva wrote:
On Wed, Mar 06, 2002 at 03:04:00PM +0000, Christopher L. Morrow wrote:
...For a backbone filtering is another story entirely. Filtering backbone equipment for it's protection is also a completely different topic...
Filtering on the backbone is exactly what I mean. Clueful backbone providers should know the ins and outs of their data...
Wow, this is a bold statement... do you deal at all with asymetrically routed customers? odd protocols? wierd applications? for any 'large' sized provider knowledge of the traffic beyond "its ip" is going to be a very difficult task. Even knowledge of address ranges crossing the network is a tough task give some customers default all traffic via one provider OUT and in through an alternate provider (assymetrical routing). Really, filtering anything but point incidents isn't a simple task, and at times point incidents are a challenge :)
Well, considering that Ron works for AOL, I would think he's all over "wierd applications" and "odd protocols" :) - Daniel Golding
On Wed, 6 Mar 2002, Ron da Silva wrote:
On Wed, Mar 06, 2002 at 03:04:00PM +0000, Christopher L. Morrow wrote:
...For a backbone filtering is another story entirely. Filtering backbone equipment for it's protection is also a completely different topic...
Filtering on the backbone is exactly what I mean. Clueful backbone providers should know the ins and outs of their data...
Wow, this is a bold statement... do you deal at all with asymetrically routed customers? odd protocols? wierd applications? for any 'large' sized provider knowledge of the traffic beyond "its ip" is going to be a very difficult task. Even knowledge of address ranges crossing the network is a tough task give some customers default all traffic via one provider OUT and in through an alternate provider (assymetrical routing).
Really, filtering anything but point incidents isn't a simple task, and at times point incidents are a challenge :)
--On 06 March 2002 15:04 +0000 "Christopher L. Morrow" <chris@UU.NET> wrote:
Eric's point was you deploy your fancy-dan mail server with ONLY 22 and 25 listening,
Um, that would be "ONLY port 25 listening" on it's public network facing interface wouldn't it. Why would you want to expose a management protocol like ssh to the Internet? OK so leaving ssh open is convenient, but if we are talking best practice surely having your remote management protocols running on a separate network, or at the very least filtering on a host basis so that it's only listening to connects from your NOC has to be the way to do this. -- Rob.
On Wed, 6 Mar 2002, Rob Pickering wrote:
Why would you want to expose a management protocol like ssh to the Internet?
I do it so my customers with shell accounts don't have to telnet in. Of course, if you're talking about ssh on something like a router, that's different, and you should assess the need for people to have access to that device over the public Internet. -- Steve Sobol, Proud Native of the Great Frozen City of Cleveland, Ohio http://www.Cleveland.OH.US/ http://www.TravelCleveland.com/ http://www.LakeCountyOhio.org/ (Where the Snow is Cold but our Hearts Aren't!) CTO, JustThe.net LLC, Mentor On The Lake, Lake County, OH http://JustThe.net/
participants (6)
-
Christopher L. Morrow
-
Daniel Golding
-
Rob Pickering
-
Ron da Silva
-
Steven J. Sobol
-
Steven M. Bellovin