My 2 cents about nIDS remote detection: There are some methods... What I remember is: - Session Reset (RSTs) This is the most simple way to detect a nIDS presence. By this way, you can also detect what kind of connections (ports/application negotiation) will cause nIDS to send RST to close your sessions. Other possible scenario is, capturing RST packets, discover the nIDS position on the access topology. This is possible by generating some traffic to target host, looking by TTL variations, and, if it not occurs, presenting "the" behavior that cause nIDS to send the RST and looking what TTL is in this packet. Then you can guess "where" the nIDS is on the packets path. Plus, you can guess what OS nIDS is running, by guessing its initial TTL. - IP Ban (drops, ICMP unreachables) Another good method to detect the presence of a nIDS. Some administrators configure nIDSs to act on Firewalls (f.e. OPSEC) to block any traffic from a IP that is source of a flood of many kinds of packets, like ICMP flood, port-scans, etc. So, if you want to detect it, you just need to generate a flood, and capture the return packets. If you suddenly start to receive ICMP port/host/net unreachabes, or stop to receive target hostīs responses (ACKs, ICMP Echo-Replies, etc), then you probably hit a nIDS. - Reverse Lookups In this method you need to take "control" of DNSs that is Authority for the reverse of your IP block. So, just send some packets whith common signatures (like CodeRed probes) and wait for the reverse lookups comming from the targetīs network (*or not*). You will realize three things: 1-That is a nIDS!! 2-The valid IP of nIDS!! 3-The nIDS TTL. - Active scans This is a rare "proffessional" nIDS behavior, but can be made if programed by a curious administrator. Once again, just send some common signatures, and capture the return. If it starts to scan you, you have now, and again, the above 3 information, with another great plus: You have SYN packets sent by the nIDS and your OS guessing will be mutch more accurate. - Promiscuous-Mode Device Detection Technically possible, but rarely usefull. I think that itīs possible in a local network, where you know what is the bandwidth behavior. Any other use, like using it on the very instable and non-guaranteed Internet connections is, in my opinion, a great fantasy. - Log Format in Adminīs e-mails to Security Lists One of the most "passive" and elegant methods. Some administrators LOVE to publish attack reports and/or comments about attacks that they have detected. It can be a good thing, informing and helping each other, but it can be very dangerous if the log format isnīt changed. Why? Well, each nIDS software has its own log format. Then, if you know some formats, and know what lists the targetīs network administrator subscribes, then you immediately know what nIDS he has. The rest of detections can be made using the above (or other) methods. Pedro Quintanilha Seguranįa da Informaįão Editora Abril s/a pquintanilhaat_private +55-11-3037-4297 -----Original Message----- From: Marco Ivaldi [mailto:raptorat_private] Sent: Monday, March 18, 2002 8:59 AM To: vuln-devat_private Subject: Re: Firewall and IDS, (the second way). > Some commercial IDS use special a special Ethernet device that is > supposed to be invisible. If you want your sensor to be non-invasive and undetectable, it's highly suggested that you use a special device, like the Shomiti (now Finisar) Century TAP: http://www.finisar.com/product/product.php?product_id=69&product_category_id=41 PROS: full duplex support, fault tolerant, non-invasive network monitoring, undetectable, useful for switched environments (there's no longer need for a span port). CONS: it's expensive for small environments. Hope that helps, +------------------------------------------------------------+ |Marco Ivaldi Email: miat_private |Security Manager Phone: (+39)-011-32.72.100 |D.S.D. Data Security Division Fax: (+39)-011-32.46.497 |@ Mediaservice.net Srl http://www.0xdeadbeef.eu.org |Get my PGP pubkey at http://www.0xdeadbeef.eu.org/raptor.asc
This archive was generated by hypermail 2b30 : Tue Mar 19 2002 - 16:39:07 PST