*Hobbit* <hobbitat_private> writes on 25 July 1999 at 22:00:01 -0400 > 1. For a completely passive box, we set the interface to some bogus IP addr, > or 0.0.0.0 if that works, ifconfig -arp, and hoover away. Antisniff would > never see the machine because the machine would never answer anything unless > someone could guess the IP address. Drawback: hard to retrieve logs remotely. > > Workaround: one interface as a normal address on a normal reachable net, and a > second interface configured as above sniffing a *different* net. Useful > setup for remotely-administerable IDS boxes; real address lives on a protected > inside net, sniffing interface plugs in to watch the dirty one but is not > addressable. > > Workaround for a single interface: As the sniffer starts, reset the interface > to bogus-IP/noarp, sniff for a while, quit sniffing, reset to the old > parameters. Or perhaps dynamically flop modes back and forth depending on > whether we saw traffic for the machine's real address arrive. A sniffer with > an open nit/dlpi/bpf should be able to go *non*promiscuous and still see if > there's traffic to its own host, and lay low accordingly. Lots of the ideas presented seem likely to work adequately to avoid detection by anti-sniff; but an awful lot of them depend on very special conditions like two interfaces on different nets, or custom hardware inserted into the net to be sniffed, or such. While I'm sure such attacks happen or are at least attempted in government high-security environments, and maybe with students playing around at colleges too, they're not what most of us are mostly worried about with sniffer attacks. We're worried about somebody compromising an existing system on our net and sniffing from it. (The "workaround for single interface" above depends on the system not being monitored for response at its normal IP address during the sniffing periods, either by automatic monitoring software, or by users trying to access services.) So, yes, anti-sniff isn't perfect (and l0pht made no claim it was perfect), but it seems like it might be quite useful against the sort of sniffer attacks most sysadmins actually face. > 2. Antisniff evasion possibility: enhancement to detect the first couple of > Antisniff probes, and immediately un-promiscuize the card for a while until > we think it's safe to peek out again. Possibly in a dynamic mode; see #1. This, on the other hand, is something that could be implemented in a software-only sniffer to be loaded into a compromised box, so it's more immediately relevant. The probe is a ping during a flood of bad packets, right? And it measures response time? The ping itself can't be recognized, but the flood of packets could. > Just a coupla ideas to kick around.. And I should add that it's perfectly appropriate for people to discuss and investigate the boundaries of anti-sniff effectiveness. I'm just starting to feel that a lot of the ways around it suggested, while they would probably work, are largely not feasible in the environments where sniffing is really a problem. They don't constitute major holes in the utility of anti-sniff. -- David Dyer-Bennet ***NOTE ADDRESS CHANGES*** dd-b@dd-b.net http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms Join the 20th century before it's too late!
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:53:53 PDT