Re: Telco's write best practices for packet switching networks
In message <Pine.GSO.4.33.0203061459240.3098-100000@rampart.argfrp.us.uu.net>, "Christopher L. Morrow" writes:
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 writ
es:
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.
I was agreeing with Eric's point. I've been saying this for years. My comment about the packet filter was to deal with services that are needed for some internal purposes, but for some reason can't protect themselves. Right now, that's snmp -- you may have snmpd running on your mail server, but given the recent CERT advisory you need to keep the bad guys away from it. (Yes, you should install fixed code -- but given how many components were affected by that advisory, it's quite obvious that no one has had time to test the fixes properly.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com
On Wed, 6 Mar 2002, Steven M. Bellovin wrote:
I was agreeing with Eric's point. I've been saying this for years. My comment about the packet filter was to deal with services that are needed for some internal purposes, but for some reason can't protect themselves. Right now, that's snmp -- you may have snmpd running on your mail server, but given the recent CERT advisory you need to keep the bad guys away from it. (Yes, you should install fixed code -- but given how many components were affected by that advisory, it's quite obvious that no one has had time to test the fixes properly.)
Okey-dokey :) I missed that part (the agreement part)
My comment was originally prompted by the meeting minutes which reported on the survey data showing that 100% of carriers are implementing firewalls in their gateways. The 100% is what caught my eye. As the topic comes up in various places, large ISPs repeatedly say they are unable to implement filters or packet screening on their high-speed links such as at peering points. So the self-reported 100% implementation of screening and filtering firewalls at gateways didn't seem to jive with my understanding of the limitations faced by large ISPs. Firewalls can be a useful tool in the security engineer's toolbox. But they get misused a lot. I don't believe security engineers are better programmers. If there was a class of programmers in the world that didn't make mistakes, I would hire them to write the applications. When the firewall is more complex than the application server it is "protecting" which is likely to have more mistakes?
On Thursday, March 7, 2002, at 04:37 , Sean Donelan wrote:
My comment was originally prompted by the meeting minutes which reported on the survey data showing that 100% of carriers are implementing firewalls in their gateways. The 100% is what caught my eye. As the topic comes up in various places, large ISPs repeatedly say they are unable to implement filters or packet screening on their high-speed links such as at peering points.
How recently are ISPs repeatedly saying this? Packet filtering on high-speed optical interfaces has been possible for some time, depending on your router vendor, for some value of "packet filtering". I could understand it if the issue of how to manage packet filter definitions on routers as the network changes was a problem. But if I would be slightly surprised if there was still a universal voice saying "we absolutely cannot filter packets at the edge, because the vendors won't let us". To meet the requirements of what I understood the original quoted fragment to be saying, it's perhaps not necessary to packet filter at the edge, anyway. You can apply a firewall to just the loopback interface of a junos box and arguably consider your control element firewalled. Joe
Hurray, my favorite arguement! On Thu, 7 Mar 2002, Joe Abley wrote:
On Thursday, March 7, 2002, at 04:37 , Sean Donelan wrote:
My comment was originally prompted by the meeting minutes which reported on the survey data showing that 100% of carriers are implementing firewalls in their gateways. The 100% is what caught my eye. As the topic comes up in various places, large ISPs repeatedly say they are unable to implement filters or packet screening on their high-speed links such as at peering points.
How recently are ISPs repeatedly saying this? Packet filtering on high-speed optical interfaces has been possible for some time, depending on your router vendor, for some value of "packet filtering".
'now' would be a good starting time, but atleast 2 years we've been saying it (if not longer)
I could understand it if the issue of how to manage packet filter definitions on routers as the network changes was a problem. But if I would be slightly surprised if there was still a universal voice saying "we absolutely cannot filter packets at the edge, because the vendors won't let us".
"we absolutely cannot filter packets at the edge, because the vendors won't let us" The equipment fries, the equipment does not support acls, the acls simply don't work... I don't think I can put it any more clearly. There has got to be a push from the USERS of this equipment (not just one user, all users) to get line rate, full packet filtering capability on ALL interfaces on EVERY router, everything from the smallest foundry or 1700 to the largest 12416 or M160 or Avici. If users don't start asking for this 2 years ago it'll be another 4-5 years before its a reality. The vendors will NOT push forward on this without a significant cash incentive (like everyone saying: I need this so do it for me).
To meet the requirements of what I understood the original quoted fragment to be saying, it's perhaps not necessary to packet filter at the edge, anyway. You can apply a firewall to just the loopback interface of a junos box and arguably consider your control element firewalled.
Yes, if this is about the original discussion point, firewalling/protecting the control elements, then a loopback filter (or similar technology on a non-juniper platform) would suffice.
On Fri, Mar 08, 2002 at 04:48:49AM +0000, Christopher L. Morrow wrote:
...I don't think I can put it any more clearly. There has got to be a push from the USERS of this equipment (not just one user, all users) to get line rate, full packet filtering capability on ALL interfaces on EVERY router, everything from the smallest foundry or 1700 to the largest 12416 or M160 or Avici. If users don't start asking for this 2 years ago it'll be another 4-5 years before its a reality. The vendors will NOT push forward on this without a significant cash incentive (like everyone saying: I need this so do it for me).
So it appears that we are in agreemnet after all! :-) (And we've been saying the above for at least 4 years now...) -ron
On Friday, March 8, 2002, at 08:39 , Ron da Silva wrote:
On Fri, Mar 08, 2002 at 04:48:49AM +0000, Christopher L. Morrow wrote:
...I don't think I can put it any more clearly. There has got to be a push from the USERS of this equipment (not just one user, all users) to get line rate, full packet filtering capability on ALL interfaces on EVERY router, everything from the smallest foundry or 1700 to the largest 12416 or M160 or Avici. If users don't start asking for this 2 years ago it'll be another 4-5 years before its a reality. The vendors will NOT push forward on this without a significant cash incentive (like everyone saying: I need this so do it for me).
So it appears that we are in agreemnet after all! :-) (And we've been saying the above for at least 4 years now...)
Since at least one vendor has got the message and ships hardware that *will* do line-rate filtering on high-speed interfaces, perhaps the answer is to modulate vendor selection accordingly. There's a significant cash incentive, for you, or at least a significant non-cash disincentive. Joe
I'll step WAY OUT on this limb now :) On Fri, 8 Mar 2002, Joe Abley wrote:
On Friday, March 8, 2002, at 08:39 , Ron da Silva wrote:
On Fri, Mar 08, 2002 at 04:48:49AM +0000, Christopher L. Morrow wrote:
...I don't think I can put it any more clearly. There has got to be a push from the USERS of this equipment (not just one user, all users) to get line rate, full packet filtering capability on ALL interfaces on EVERY router, everything from the smallest foundry or 1700 to the largest 12416 or M160 or Avici. If users don't start asking for this 2 years ago it'll be another 4-5 years before its a reality. The vendors will NOT push forward on this without a significant cash incentive (like everyone saying: I need this so do it for me).
So it appears that we are in agreemnet after all! :-) (And we've been saying the above for at least 4 years now...)
Since at least one vendor has got the message and ships hardware that *will* do line-rate filtering on high-speed interfaces, perhaps the answer is to modulate vendor selection accordingly. There's a significant cash incentive, for you, or at least a significant non-cash disincentive.
Locking yourself into one vendor could be considered a bad move :( You are then locked into all their little quirky ways of doing things and you have no recourse when their 'next great technology' isn't quite so great. Additionally, perhaps the 'one good vendor' (and in my original note I listed those vendors I could think of, not nceessarily those with problems...) doesn't quite do everything you want either? Its a sticky problem, basically having everyone who uses the equipment in a big way shout the loudest possible that we need these basic filtering requirements on all platforms is a good start. :) So, anyone experienced the 3xGigE linecard filtering?? :) Talk about enjoyable... the commands aren't even in the IOS filter with!!! SUPER COOL!
On Thu, 7 Mar 2002, Sean Donelan wrote:
My comment was originally prompted by the meeting minutes which reported on the survey data showing that 100% of carriers are implementing firewalls in their gateways. The 100% is what caught my eye. As the topic comes up in various places, large ISPs repeatedly say they are unable to implement filters or packet screening on their high-speed links such as at peering points. So the self-reported 100% implementation of screening and filtering firewalls at gateways didn't seem to jive with my understanding of the limitations faced by large ISPs.
Yes... hmm, I didn't read the report/minutes BUT I'd think this might mean 2 things: 1) the filtering is on the gateways (routers) 'for the router' (vty acls, loopback filters, snmp filters, ntp filters...) 2) the filtering is on the ISP's corporate connection to the 'internet' I'd think 1 more likely the correct interpretation than 2. I'd doubt this was meant to be applied to 'all interfaces on the gateways' in the sense that all interfaces have a traffic filter on them. That really isn't a scalable/managable/workable (without melting a router) solution. (yes, I know a juniper can probably filter on all interfaces at 'line rate' but not everyone has junipers at their edge so the 100% would not apply here)
Firewalls can be a useful tool in the security engineer's toolbox. But they get misused a lot. I don't believe security engineers are better programmers. If there was a class of programmers in the world that didn't make mistakes, I would hire them to write the applications. When the firewall is more complex than the application server it is "protecting" which is likely to have more mistakes?
participants (5)
-
Christopher L. Morrow -
Joe Abley -
Ron da Silva -
Sean Donelan -
Steven M. Bellovin