[11161] in bugtraq
Re: Antisniff thoughts
daemon@ATHENA.MIT.EDU (David Dyer-Bennet)
Wed Jul 28 03:02:42 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <14237.4931.400855.281403@gw.dd-b.net>
Date: Mon, 26 Jul 1999 21:02:43 -0500
Reply-To: David Dyer-Bennet <dd-b@DD-B.NET>
From: David Dyer-Bennet <dd-b@DD-B.NET>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: *Hobbit*'s message <199907260200.WAA00812@narq.avian.org> of 25
July 1999
*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
> 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!
