paul at vix
Feb 26, 2006, 4:27 PM
Post #28 of 34
(5573 views)
Permalink
|
i'd writ:
# > speaking of which, f-root has about 35 nodes world wide, and about a third
# > to a half of them aren't reachable by udp/161, and the blockage is not in
# > our immediate neighbors but rather on transit paths. this is due to the
# > cisco snmp vulnerability five years or so ago. filtering in the core to
# > protect vulnerable edges has to be done a LOT more carefully than that.
# > (BCP38 is an example of how to do it well, but apparently impractically?)
someone followed up anonymously:
# Filtering UDP/161 and TCP/161 directed towards -one's own infrastructure- is
# a BCP, irrespective of SNMP vulns, etc. It should of course be allowed to
# transit for folks who insist on doing SNMP across 'the Internet', but in
# reality, one ought not to be allowing this at all. A lot of folks didn't
# understand or didn't take the time to incorporate this into organized iACL,
# and so ended up blocking it for transit traffic, as well, unfortunately.
"yum." (folks who control backbone router meshes without fully understanding
the impact of changes they make or time to fully digest and incorporate BCPs.)
# Yes, filtering ports is a losing proposition (how long until all 64K of TCP
# and UDP are filtered, heh?), but in this case, there's a practical reason to
# do so, at least for traffic ingressing towards one's own devices.
i just don't agree that filtering ports on internal infrastructure access buys
anything. the boyz who run ISC's network filter by source-IP. that means if
somebody needs to SSH to one of our routers they have to be coming from some
fairly nearby/trusted place. i believe this is also what UUNET does, and it's
what we were doing at MFN as of the time i left. i thought THAT was a BCP?
after all, the combination of not letting outsiders spoof your internal IP
range, and not letting your customers spoof IP ranges not assigned to them,
ought to make IP ACL's containing internal source addresses fairly dependable?
|
