RE: RBL-type BGP service for known rogue networks?
But that's why we have human beings in the NOCs, no? As I'm mucking about with the Cisco Netranger/IDS on one of my networks, I've been able to winnow down the false-positives substantially, and am still working on improving its reliability further. I certainly don't think that intrusion-detection makes sense for the backbones and NAPs and so forth, but when you get closer to the traffic-orginator/requestor boundaries of the network, it becomes more feasible, does it not? -----Original Message----- From: John Kristoff [mailto:jtk@depaul.edu] Sent: Friday, July 07, 2000 1:59 PM To: nanog@merit.edu Subject: Re: RBL-type BGP service for known rogue networks? rdobbins@netmore.net wrote:
Isn't that why some sort of intrusion/exploit-detection system integrated with ACLs would perhaps be a better remedy?
Dealing with false positives and "intentional" black holing would be a difficult thing to get right. It sounds like the MAPS approach someone mentioned earlier would be workable. John
rdobbins@netmore.net wrote:
I certainly don't think that intrusion-detection makes sense for the backbones and NAPs and so forth, but when you get closer to the traffic-orginator/requestor boundaries of the network, it becomes more feasible, does it not?
Perhaps. It might be less detrimental to the entire Internet community if only a edge customer's dynamic IDS/filtering system went haywire. It then boils down to an organization's design and support philosophy. Personally, I don't like the idea of messing with packets/streams in transit unless it's route them, drop them (congestion) or mark them (IP ToS bits/DiffServ). There of course may be a few instances where you block an entire netblock (e.g. RFC 1918) or specific ports (e.g. snmp) that are widely know to be insecure or invalid. It seems easier in the long run (harder intially) to secure the end systems. Maybe I'm just getting used to vendors automatically configuring my network with the routing protocols and I'm not quite ready for automatic ACL definitions based on traffic patterns. :-) John
participants (2)
-
John Kristoff -
rdobbins＠netmore.net