Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

RE: Intrusion Prevention

From: Chris Petersen <chris(at)idsroi.com>
Date: Wed Dec 11 2002 - 14:57:14 EST


Not understanding how "attack traffic fingerprinting" could work in the following 3 scenarios, I dug into what literature I could find on Forescout. Initial scenarios:

1 - Attack occurs in separate TCP session than initial reconnaissance 2 - IP used in attack is different than IP used to scan (e.g., FTP bounce scan, zombie idle scan, etc.)
3 - Scanning takes place over long period of time from many different systems

Upon reading the lit, Forescout "marks" an attacker when it detects reconnaissance activity and responds with deception packets. The lit. is very grey about what the "mark" actually is. What I suppose the mark to be is the following:
- if an IP probe - deceptive responses sent with known to be invalid, "marked" IP address
- if a port probe against single IP - deceptive responses sent with known to be invalid, "marked" open ports.

  • I would imagine Forescout also sends fake responses indicating actual open ports are closed.

Assuming this is the way it works, Forescout then waits for an attack against marked IP or port. Given Forescout is analyzing the destination IP or port, it doesn't matter where the attack originates - dismissing my 3 initial issues. However, it opens up many others.

The literature is grey about whether or not the real responses are also sent. I believe the real response along with the deceptive response are sent back to the attacker. I say this because it appears Forescout's blocking mechanism is TCP Reset - more on this later. It does not appear to sit in-line where it could actually drop the response as would a firewall. If this is true, a race condition exists where the Deceptor needs to respond to the attacker before the probed system does - what happens when this fails? Also, if both real and deceptive responses are sent back to attacker, it would seem very possible to fingerprint Forescout by analyzing response traffic looking for overlapping packets.

Back to TCP Resets. This appears to be the mechanism by which Forescout will block subsequent attacks assuming the attacker targets a "marked" IP or port. I draw this conclusion based on it being the only blocking mechanism described besides integration with Checkpoint firewall. 100% prevention assumes 100% TCP reset effectiveness. I have trouble with this.

I also have difficulty with the following statement taken directly from their data sheet which also professes "Full" protection of known and unknown attacks.

"As long as the attacker performed a scan beforehand - which they invariably do - ActiveScout will protect the network."

Do you need help?X

So what happens if the attack is blind? Or when the scan is a single port probe against an authorized service such as SSH or HTTP. I don't see how any technology can separate an attacker typing www.yourdomain.com into a browser from a customer doing the same.

As for 0% False Alarms, I think this is actually true because I don't think Forescout detects anything - I think it just waits for traffic destined for marked IP addresses or Ports and begins issuing TCP resets. There is nothing I could find on detection methods - no pattern matching, protocol analysis, etc. It seems entirely predicated on being able to identify and then mark reconnaissance activity and correlate that with follow-on attacks. This is likely very possible in wide, sweeping reconnassiance activities, but if the reconnassiance is distributed, slow, and targeted against likely authorized services, how is 100% accurate reconnassaince detection possible?

My analysis is based solely on what I was able to grock from Forescout's web site and is attributed to me alone. I encourage someone to please spell it out for me or fill in the gaps if I'm off base.

No doubt Forescout has it's merits and the cool factor is very high - however, not sure the marketing is as 100% as it's purported preventive capabilities.

Chris Petersen
Entrepreneur and consultant

> -----Original Message-----
> From: Vern Paxson [mailto:vern@icir.org]
> Sent: Tuesday, December 10, 2002 2:13 AM
> To: intrusi0n@cox.net
> Cc: focus-ids@securityfocus.com
> Subject: Re: Intrusion Prevention
>
>
> FYI, the way it works is by responding to scans with bogus
Received on Wed Dec 11 16:21:31 2002

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:01:04 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library