mailing list archives
Re: Antisniff thoughts
From: dd-b () DD-B NET (David Dyer-Bennet)
Date: Mon, 26 Jul 1999 21:02:43 -0500
*Hobbit* <hobbit () AVIAN ORG> 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
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!