"rds" == Ron da Silva <ron@aol.net> writes:
sd> ASN.1 is pretty cool, but I've been wondering are there that sd> many ISPs which allow external SNMP access to their equipment? sd> SNMP is a UDP management protocol, and even under the best of sd> conditions, accepting packets from out of the blue isn't a good sd> idea.
Spoofed packets?
It's not feasible to filter antispoof at OC-12 or OC-48 line rate on all customer facing interfaces.
rds> But it should be not only feasible, but standard practice. It's impossible using most high bandwidth gear that's out there. At these speeds, you can either route the bits, or look at them, but not both. Juniper is the one vendor that's given us packet inspection abilities that scale with bandwidth. We have non-Juniper routers. Please, tell your vendors you want line-rate filtering up to layer 4. We're tired of being told "But you're the only ones that ask for this". Without control plane seperation (and it's not possible with Cisco, Juniper, or most other routers out there), management services are listening on the public network, and that makes this very scary, regardless of filtering policies, etc. ericb -- Eric Brandwine | "Intel Inside" is a Government Warning requied by Law. UUNetwork Security | ericb@uu.net | +1 703 886 6038 | - Usenet Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
C'mon guys. Exchange point rate anti-spoof filtering is not necessary to solve this problem. This is why there are switches (using vlans if you choose) and router interfaces. Unless you are taking an OC3's worth of management traffic, you create a net just for your management traffic, put in on an interface and hang your entire site's snmp gear off of that. If you want it to be private, GRE and 1918 addresses are your friends, and filter to allow only traffic from those nets. None of this is new or hard. Also, most everyone now supports snmpv3 security, so you can do that as well. (I just do it the old way I know how, so I haven't played much with this.) jerry
On Wed, 13 Feb 2002, jerry scharf wrote:
This is why there are switches (using vlans if you choose) and router interfaces. Unless you are taking an OC3's worth of management traffic, you create a net just for your management traffic, put in on an interface and hang your entire site's snmp gear off of that. If you want it to be private, GRE and 1918 addresses are your friends, and filter to allow only traffic from those nets. None of this is new or hard.
Nice theory, but in practice it's a little ickier than you make it sound. Consider most people on this list deal with networks (not just single sites) spanning multiple states or countries. Not everyone can afford to build both a backbone and a separate management WAN. Putting management in 1918 space is ok at one location, but gets tricky on a large network. Do we then also buy/maintain VPN hardware to connect all the various 1918 management networks to the NOC? This actually might be an interesting use for MPLS VPN for those networks where all the core gear supports it, but a totally separate management WAN is cost prohibitive. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
jlewis@lewis.org wrote:
Do we then also buy/maintain VPN hardware to connect all the various 1918 management networks to the NOC?
Um, it isn't that hard or expensive. I just put an older box -- like a 133 or 200 MHz machine -- at each pop, running OpenBSD. Allows a simple VPN throughout, and runs ntpd, too. And sometimes running a remote copy of MRTG at a particular POP is nice for hunting down infected local DSL customers without tying up the backbone. Look, it's a lot less costly than the routers, the DSLAMs, even the managed switches. My main difficulty is they aren't rackable (just old desktop machines), so they sit in the bottom of the rack. Someday, someday. It's time we all run with better security. (As we frantically put in more filtering in the middle of the night based on the report -- no matter how proactive we try to be, the bar keeps moving and moving.) -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Wed, Feb 13, 2002 at 08:38:03AM -0800, jerry scharf wrote:
C'mon guys. Exchange point rate anti-spoof filtering is not necessary to solve this problem.
How do you filter your peers to prevent them from spoofing your infrastructure space? Not everyone filters their custoemrs because either a) they have a large and varying set of routes (and ip sources) they may send at you b) they can't manage it or c) their routers can't filter (fast enough).
This is why there are switches (using vlans if you choose) and router interfaces. Unless you are taking an OC3's worth of management traffic, you create a net just for your management traffic, put in on an interface and hang your entire site's snmp gear off of that. If you want it to be private, GRE and 1918 addresses are your friends, and filter to allow only traffic from those nets. None of this is new or hard.
No it is not but the problem is when extracing snmp data (for billing for example) one can not always use an oob network to extract this data or a vpn solution due to port-cost, etc.. IMHO router vendors should be able to do the various types of filtering at line-rate (strict rpf, loose rpf, "any rpf", rate-limit icmp, filter based on exact config to prevent DoS or track such items). Some vendors did not consider this key functionality when they designed their routers/linecards.
Also, most everyone now supports snmpv3 security, so you can do that as well. (I just do it the old way I know how, so I haven't played much with this.)
Sure this works assuming all your pollers can support snmpv3 without any complicated problems and have resources to allocate to the various projects that collect this data. I'm sure there are a few companies these days that are having a harder time getting the money and resources to perform non-critical upgrades to these systems when the current one works just fine. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Wed, Feb 13, 2002 at 03:55:25PM +0000, Eric Brandwine wrote:
Without control plane seperation (and it's not possible with Cisco, Juniper, or most other routers out there), management services are listening on the public network, and that makes this very scary, regardless of filtering policies, etc.
interfaces { lo0 { unit 0 { family inet { filter { input RE; } } } } } firewall { filter RE { term BGP { from { protocol tcp; destination-port bgp; } then accept; } term TCP-established { from { protocol tcp; tcp-established; } then accept; } /* insert other term's allowing routing protocol traffic etc. */ term only-fxp0 { from { interface-group-except fxp0; } then discard; } /* allow ssh, snmp etc. traffin only on the mngt. lan */ term allow-from-fxp0 { from { interface-group fxp0; } then accept; } } } /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
### On 13 Feb 2002 15:55:25 +0000, Eric Brandwine <ericb@UU.NET> casually ### decided to expound upon Ron da Silva <ron@aol.net> the following ### thoughts about "Re: it's here": EB> Without control plane seperation (and it's not possible with Cisco, EB> Juniper, or most other routers out there), management services are EB> listening on the public network, and that makes this very scary, EB> regardless of filtering policies, etc. Huh? Junipers have the fxp0 interface which can be used for management. You're just not supposed to route between the management fxp0 and your production interfaces. -- /*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=========================================================================*/
On Wed, Feb 13, 2002 at 09:50:16AM -0800, Jake Khuon wrote:
EB> Without control plane seperation (and it's not possible with Cisco, EB> Juniper, or most other routers out there), management services are EB> listening on the public network, and that makes this very scary, EB> regardless of filtering policies, etc.
Huh? Junipers have the fxp0 interface which can be used for management. You're just not supposed to route between the management fxp0 and your production interfaces.
As do Cisco GSR's.. on their e0 interface. Same difference. You can even enable or disable CEF on it :) -- ------------------------------------------------------------------------------- : Steven Noble / Network Janitor / Be free my soul and leave this world alone : : My views = My views != The views of any of my past or present employers : -------------------------------------------------------------------------------
participants (9)
-
Eric Brandwine -
Jake Khuon -
Jared Mauch -
jerry scharf -
Jesper Skriver -
jlewis＠lewis.org -
Steve Noble -
Tony Hain -
William Allen Simpson