Vulnerability Development mailing list archives
Re: Firewall and IDS, (the second way).
From: "Bryan Burns" <bburns () onesecure com>
Date: Fri, 15 Mar 2002 23:44:28 -0800
One trick I've heard of is sending data on the network, then waiting to see if someone does a DNS query against your IP (assuming you're in control of the DNS server, or at least within sniffing distance), the assumption being that it's a sniffer doing reverse-DNS of your IP before writing it to logs or somesuch. It's not exactly the most foolproof method, but it's better than nothing. Also, I'm not particularly convinced of the ping method. I imagine that there are so many other variables at play determining the round-trip ping time that the delay due to sniffing would be lost in the noise. Also, it relies on having a database of ping times for all your machines, which is difficult to imagine actually existing anywhere. -Bryan ----- Original Message ----- From: "Zow Terry Brugger" <zow () llnl gov> To: <sekure () hadrion com br> Cc: <vuln-dev () securityfocus com> Sent: Friday, March 15, 2002 6:27 PM Subject: Re: Firewall and IDS, (the second way).
Hi,Hello!I'm "walking" by the internet finding about paper/techniques that can be used to detect systemn with IDS installed. Try to detect snort/snort+aide/quinds/.../ somebody know something like it ??I recall Munge giving a talk at BlackHat Las Vegas in 2000 about something they were doing at @stake/l0ft for detecting sniffers. The idea was to
allow
sysadmins to detect if one of their machines had been hacked and was
acting as
a sniffer. The idea was that by putting the interface into promiscuous
mode,
the machine would take longer to respond to ping packets because there was more traffic for the kernel's IP stack to analyze (whereas usually it'll
be
filtered out by the NIC). The same should hold true for NIDS, with a
couple
caviots: 1. You'd need to know what ping time to expect if the NIC wasn't running
in
promiscuous mode in order to calculate a delta, 2. A popular technique to secure NIDS is to not allow them to respond to traffic on the network that they're listening to (that is, bring up, but
don't
configure) the interface. Doing so will pretty much eliminate the ability
to
use this technique. In other words, I wouldn't go around trying to use such a technique to
detect
NIDS - it'll probably have just the opposite effect of allowing them to
detect
you. -"Zow" from StandardDisclaimer import *
Current thread:
- Firewall and IDS, (the second way). sekure (Mar 15)
- Re: Firewall and IDS, (the second way). Zow (Mar 15)
- RE: Firewall and IDS, (the second way). Benjamin P. Grubin (Mar 16)
- Re: Firewall and IDS, (the second way). Bryan Burns (Mar 16)
- RE: Firewall and IDS, (the second way). Dom De Vitto (Mar 16)
- Re: Firewall and IDS, (the second way). Michel Arboi (Mar 16)
- Re: Firewall and IDS, (the second way). Timothy J. Miller (Mar 19)
- Re: Firewall and IDS, (the second way). Anthony Stevens (Mar 20)
- <Possible follow-ups>
- Re: Firewall and IDS, (the second way). Marco Ivaldi (Mar 18)
- RE: Firewall and IDS, (the second way). PJD (Mar 19)
- Re: Firewall and IDS, (the second way). Zow (Mar 20)
- RE: Firewall and IDS, (the second way). Pedro Quintanilha (Mar 19)
- RE: Firewall and IDS, (the second way). Bojan Zdrnja (Mar 20)
- RE: Firewall and IDS, (the second way). Pedro Quintanilha (Mar 20)
(Thread continues...)
- Re: Firewall and IDS, (the second way). Zow (Mar 15)