On Sun, 18 May 2008, Joel Jaeggli wrote: > Dragos Ruiu wrote: > >> First of all about prevention, I'm not at all sure about this being >> covered by existing router security planning / BCP. >> I don't believe most operators reflash their routers periodically, nor >> check existing images (particularly because the tools for this >> integrity verification don't even exist). If I'm wrong about this I >> would love to be corrected with pointers to the tools. > > I have 6 years worth of rancid logs for every time the reported number > of blocks in use on my flash changes, I imagine others do as well. > That's hardly the silver bullet however. > > We as I imagine others do expended a fair amount of cycles monitoring > who it is that our routers are talking to and protecting the integrity > of the communications channels that they use (bgp, ospf, ssh, tftp etc), > If a router has a tcp connection to someplace it shouldn't we'll > probably know about it. If it's announcing a prefix it shouldn't be, > we'll probably know about it, those are the easy ones though.
I am very happy to hear you do these... very useful and will catch quite a bit. > There are some things one might consider adding in terms of auditing, > comparing the running image more closely to the one in flash for > example, peroidic checksum of the on onflash image, after downloading to > another host would be another. I'm not sure that I'd trust the later > given the rooted box can I suppose hand you an unmodified version of the > subverted image. The result from your check can easily be modified, first thing I would have changed is the checker. Say you did this from a usb stick--I'd just hide the rootkit in memory. > In the end if you subvert a router, presumably you're doing it for a > purpose and given what the device does, that purpose is probably > detectable in a well instrumented network. Subversion may not be the goal. A router is perfect for faking outgoing traffic. This traffic can contain stolen sniffed or relayed data. > It is desirable I expect to insure that any locally stored security > credentials that might be subverted not be usable when connecting to > another router, that applies in a absence of root kits however. _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog