|
|||||||||||
|
RE: Intrusion Prevention
From: Chris Petersen <chris(at)idsroi.com>
Date: Wed Dec 11 2002 - 14:57:14 EST
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.)
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:
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." 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
> -----Original Message-----
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:01:04 EDT |
||||||||||
|
|||||||||||