Protocol Anomaly and Issues

["Peter Baker" <peter_baker () rediffmail com>]

hi group,

Greetings, 

I have gone through some previous discussions on “Protocol Anomaly” based IDS.
Well if experts on this group remember, the discussion silently drifted away from technology to individual products and 
then to honeypots and their work towards reduction of false positives…..nice discussion ad I really enjoyed the 
different views.

If you can just read on the summary of previous discussion from different people, which were made, it would be helpful 
for issues I want to put further….

·       protocol anomaly detection seems to be the more promising than the  statistical for detecting new or 
IDS-cloaked attacks.  However the notion of "conforming to RFCs" leaves a lot of leeway for the vendors to play with.

·       One way of doing IDS is to read the RFCs and trigger an event whenever the network traffic doesn't conform to 
it. We refer to an anomaly as something that is legal (as far as the RFC is concerned), but otherwise odd.

·       The good thing about protocol-anomaly signatures is that they tend to identify the vulnerability rather than 
the exploit, which means they can do a better job of detecting things before exploits are published.

·       Note that some vendors refer to "protocol-validation" as "protocol-anomaly" detection.

There are perhaps some issues, which I would like to put forth in the group and need your views and suggestions on same

1)      I feel protocol anomaly should involve coming out with a normal protocol model based on union of a) idealistic 
behaviour given by RFCs and b) practical normalisations carried out by learning implementation of that protocol. So 
anything out of this union would be protocol anomaly

What could be the issues involved in modelling implementation….
·       will it be based on source code …if that’s the case it becomes particular to a vendor specific, version 
specific review of the protocol implementation
·       will it be based on just observing the traffic/protocol behaviour for the many test cases that have been built 
by reading RFCs

2)      When a vendor specs say they have implemented “protocol anomaly” for HTTP, is it specific to a particular 
environment like for instance Apache…., IIS etc or something “general”. Put it another way, if apart from RFC the 
protocol model is based on suppose “X” vendor’s HTTP implementation then the same model wont work for clients having 
“Y” HTTP implementation and then it would generate a lot of false positives …… But the vendors have coded something 
generically then no issues reg this will be there …..

I hope I am clear on stating my views

I sincerely welcome any comments/views on above issues. Thanks for reading through this being with me till here.

Thanks and Regards,

Peter Baker
___________________________________________________
Meet your old school or college friends from 
1 Million + database...
Click here to reunite www.batchmates.com/rediff.asp



---------------------------------------------------------------------------
Captus Networks - Integrated Intrusion Prevention and Traffic Shaping
 - Instantly Stop DoS/DDoS Attacks, Worms & Port Scans
 - Automatically Control P2P, IM and Spam Traffic
 - Ensure Reliable Performance of Mission Critical Applications
Precisely Define and Implement Network Security and Performance Policies
**FREE Vulnerability Assessment Toolkit - WhitePapers - Live Demo
Visit us at: http://www.captusnetworks.com/ads/31.htm
---------------------------------------------------------------------------