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
Hmm...but certainly part of the right solution for a general "appliance"
network.
-ron
>
>
> >
> >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
Filtering on the backbone is exactly what I mean. Clueful backbone
providers should know the ins and outs of their data...
-ron
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 
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.
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?
You wouldn't. Neither would I. I'll go poke fun at Chris.
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.
Absolutely. It bothers me that as an ISP, we kinda have to run mail
and dns servers. If there were two protocols I'd choose NOT to expose
to the public network, they'd be it. I'd much rather expose ssh than
bind or sendmail.
ericb
> Why would you want to expose a management protocol like ssh to the
> Internet?You wouldn't. Neither would I. I'll go poke fun at Chris.
I can think of a few reasons, it's no more/less secure than
sendmail/postfix/bind/snmpdx/...... its just another thing to monitor and
upgrade when there are problems.
In most people's example networks they PROBABLY run all their 'services'
on virtual interfaces anyway so ssh doesn't have to listen on the same ip
as bind so perhaps it's a non-issue.
> 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.Absolutely. It bothers me that as an ISP, we kinda have to run mail
and dns servers. If there were two protocols I'd choose NOT to expose
to the public network, they'd be it. I'd much rather expose ssh than
bind or sendmail.
We can be an ISP or we can not be an ISP, its a business decision... the
'be an ISP' seems to make money while the 'I got big vats of fiber in the
ground wanna use it for telephones?' seems to NOT make money.
You know, you can run mail and DNS servers without exposing either of those.
--Adam
Does anyone have a good reference for this particular solution? Most software is really badly documented when it comes to this, and without configuration the service ends up on all the interfaces (or even just localhost). Popular services like BIND and Sendmail are easy enough to configure, but, documentation wise, this topic now reminds me of trying to find decent rwx anon ftp instructions ten years ago.
Best Regards,
Simon
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.
Well, considering that Ron works for AOL, I would think he's all over "wierd
applications" and "odd protocols"
- Daniel Golding