IDS mailing list archives
RE: ForeScout ActiveScout (was: Re: Intrusion Prevention)
From: Omar Herrera <oherrera () prodigy net mx>
Date: Sun, 15 Dec 2002 16:10:41 -0600
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The technology sounds interesting but I have doubts regarding the thresholds: If I for example scan for port 80 (quite common), and suppose we have a web server with password authentication, ¿does that mean that legitimate users that somehow mistype their password at this service hosted at this port might be blocked because they could be classified under a potential brute force attack? I'm worried that these 1-n relationships could be used for extensive DoS, because one single scan to one service port could potentially block legitimate users (one port could provide several services under a common application framework); We know this is the case with IDS reacting with firewalls anyway, it requires a delicate fine tuning process and I'm sure that this product has configuration capabilities to reduce this. Now, one of the main problems with NIDS is that, in order to correctly identify attacks and minimize IDS evasion they should emulate as best as possible the stack of the OS in the machines they are protecting; I understand that this product is different from NIDS many aspect but I believe this capability still should be present since attacks and port scans are detected through the analysis of network traffic, right? How does this product deal with responses that are legal for one OS and illegal for the other? Does it identify the OS of each resource it protects like many NIDS do? How do you deal with real network problems that prevent legitimate packets to arrive? While there is a relatively small probability, there could possibly be incomplete TCP handshakes on ports. Do these qualify as syn scans for example? One last question, How does the product distinguishes between scans originated from the outside and scans originated from the inside of the network you want to protect?, for example, if someone from the protected network SYN scans someone on the internet they will get probably a SYN/ACK or RST packet; do these qualify as scans also and put the product in alert mode waiting for an attack? Omar Herrera
-----Original Message----- From: Oded Comay [mailto:comay-nospam () forescout com] Sent: Domingo, 15 de Diciembre de 2002 12:16 p.m. To: focus-ids () securityfocus com Subject: ForeScout ActiveScout (was: Re: Intrusion Prevention) Greetings, We have been following this thread with great interest. Sorry for jumping in late; appreciating the technical quality of this forum, we wanted to avoid anything that could be viewed as marketing pitch. I will do my best to avoid it (and sweeping generalizations) in this posting as well. That being said, some clarifications are in order. To start with, ActiveScout is not an IDS. Judging it by NIDS standards and criteria will do injustice to both technologies. ActiveScout's core technology is based on a simple observation: Most online intrusions are preceded by *some* sort of reconnaissance, which is detectable by observing network traffic. Based on information collected during the recon phase, an attacker may try to exploit the vulnerabilities that have been discovered to penetrate the network. Reconnaissance could be a simple-minded port scan, or any of its more elaborate variants (including the stealth genres). However it goes far beyond scans. A typical reconnaissance phase could consist of probing your network with NetBIOS queries (looking for user names and/or host names), It could be an SNMP GET request (or a set thereof), and so forth. For an illustration of how ActiveScout works, consider this: Someone is probing your network with NetBIOS, looking for user names, and gets some such names. A week later, from a totally different IP address, someone is using one of these user names to try and access your corporate FTP server, gets blocked immediately, and is prohibited from any further access to your corporate network. The technology has several interesting attributes. To name a few: - It is independent of the payload of the attack. This enables detection of attacks not known to the security community. - It is not sensitive to whether the attack comes from the same source (IP address) as the reconnaissance. Au contraire: this is actually where it shines. - The detection is extremely accurate, allowing for automatic blocking to be enabled without fear of blocking legitimate business. - It is not dependent on the actual probing technique (e.g. simple TCP connect, FTP bounce, sent along with decoy addresses, etc.). - Attacks are detected at an extremely early stage, when the payload usually has no impact (yet), allowing time for effective blocking (using a firewall, or tearing down TCP connection before the TCP window opens up). These attributes enabled the creation of a product which is as "low maintenance" as it gets: you just need to plug it into the network, provide minimal initial configuration and it just works. Considering that proper security design is always layered, you may very well want to complement it with other technologies (such as NIDS), provided that you have the resources required to manage those. Chris Petersen presented an interesting and well thought-out analysis based on website information. Some comments re this analysis: - Chris focuses mainly on various port-scan probes as being recon. As depicted above, this is only part (albeit large, quantity-wise) of network-based reconnaissance. ActiveScout works well with those scans (all things nmap), but this is only where the fun begins. There are quite a few other ways to get "interesting" information about a network and its resources, which ActiveScout uses. - Clearly, as Chris correctly analyzed, if ActiveScout's responses could be subject to fingerprinting, it would undermine the efficiency of this technology. Hence, the algorithms were designed in such a way that fingerprinting will be very difficult (not to say impossible). - ActiveScout blocks intrusions either by working with your firewall (inserting temporary policy lines, such as with FireWall-1 SAM), or by using TCP RSTs. None of these are ForeScout's "inventions"; however, for TCP RSTs, it turns out that ActiveScout's use of them is quite effective, more so than, for example, NIDS. The reason is that the resetting happens at a very early stage of the TCP connection (contrary to sending it after hostile payload has been detected). Therefore, the chances for the race condition Chris mentions are slim, at best. Karl Lynn asks whether there will be a problem if he "scans" from one network and attacks from another. As mentinoed above, this is actually a great feature of ActiveScout. Even if the "attacking" network address is used sparingly, just for launching the actual attack (after recon done using a different network block), ActiveScout will detect and block it from accessing to the attacked network. And we haven't said anything about the cool factor... Thanks, and seasons greetings to all! -- Oded Comay, CTO ForeScout Technologies ------------------------------------------------------- -------------------------------------------------------
-----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPfz94Kxc3R1o/elHEQL8aACgtMpiEFWZBHFfApF5T+mHfpAR3iwAoOrG QEgTTw4i99Bp7qnahpoxooQZ =eRk3 -----END PGP SIGNATURE-----
Current thread:
- ForeScout ActiveScout (was: Re: Intrusion Prevention) Oded Comay (Dec 15)
- RE: ForeScout ActiveScout (was: Re: Intrusion Prevention) Omar Herrera (Dec 15)
- Re: ForeScout ActiveScout (was: Re: Intrusion Prevention) Frank Knobbe (Dec 15)
- Re: ForeScout ActiveScout (was: Re: Intrusion Prevention) Karl Lynn (Dec 16)
- <Possible follow-ups>
- RE: ForeScout ActiveScout (was: Re: Intrusion Prevention) Adam Powers (Dec 16)
- RE: ForeScout ActiveScout (was: Re: Intrusion Prevention) Matthew L. McGuirl (Dec 16)
- RE: ForeScout ActiveScout (was: Re: Intrusion Prevention) Dudley, Brian (ISS Chicago) (Dec 16)
- RE: ForeScout ActiveScout (was: Re: Intrusion Prevention) Karl Lynn (Dec 16)
- RE: ForeScout ActiveScout (was: Re: Intrusion Prevention) Frank Knobbe (Dec 17)
- RE: ForeScout ActiveScout (was: Re: Intrusion Prevention) Omar Herrera (Dec 17)
- RE: ForeScout ActiveScout (was: Re: Intrusion Prevention) Matthew L. McGuirl (Dec 17)
- Re: ForeScout ActiveScout (was: Re: Intrusion Prevention) Dug Song (Dec 17)