-----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_at_forescout.com]
> Sent: Domingo, 15 de Diciembre de 2002 12:16 p.m.
> To: focus-ids_at_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-----
Received on Dec 15 2002
Intro
