Vulnerability Development mailing list archives
RE: Firewall and IDS, (the second way).
From: "Pedro Quintanilha" <PQuintanilha () abril com br>
Date: Mon, 18 Mar 2002 17:41:19 -0300
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 pquintanilha () abril com br +55-11-3037-4297 -----Original Message----- From: Marco Ivaldi [mailto:raptor () mediaservice net] Sent: Monday, March 18, 2002 8:59 AM To: vuln-dev () securityfocus com 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: mi () mediaservice net |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
Current thread:
- Re: Firewall and IDS, (the second way)., (continued)
- 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)
- 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)
- RE: Firewall and IDS, (the second way). Bojan Zdrnja (Mar 20)
- Re: Firewall and IDS, (the second way). Zow (Mar 15)