idsm v3.0 code packet filter model?

[c.alejandra]

Since we know that sensord normally operates from a Sensor working with

a packet filter that is forwarding copies of network packets to it, and

that packetd does the interpretation, I am trying to find out what the idsm v3.0 code packet filter model is (BPF,NIT, CSPF, a derivative of, utterly Cisco custom...) such that I can determine its capture performance, or based from the model, how it

interprets protocols. Based on how the packet filter interprets protocols,

that'll help me know how packetd sees the protocols for matching to

signatures.

[klwiley]

The answer to your question is utterly Cisco custom. The only real filtering is wheterh or not the packet is IPv4 type ICMP/TCP/UDP.

KLW

[c.alejandra]

OK, so it is utterly Cisco custom. In the customization, did the IDSM team burrow or mirror any libpcap code? I am trying to justify how tacacs and radius packets are intepreted, and how other protocols would be similarly intepreted in associating a bias behaviour BEFORE signature correlation. -the relation is that libpcap-based intepretors also have issues in intepreting the above mentioned protocols. This knowledge could be used to gauge what will/will not be correctly intepreted -regardless of the intrusion detection signature semantic and syntax. In addition, suppose that there were similarities in the 'utterly custom' and BPF for example, intrusion analysts could expect certain types of behaviours to better gauge the mapping to the intrusion detection signature.

This is useful when analysing a detection signature that has been determined to be incorrectly mapped to a catalyst that it was intended to capture.

[klwiley]

No the libpcap code was not used as a model. We parse the raw packet following the protocol spec. In effect our code simply replaces the host stack.

[c.alejandra]

1-Is the code available.

2-What would you therefore suggest in accounting for a bias behaviour before signature correlation to gauge the intepretation -regardless of the intrusion detection signature semantic and syntax?

Has the thought ever come around while trying to determining how and why a detection signature, while accurate with seemingly correct syntax unto itself, mis-fired because of a bias behaviour as a result of the packet intepretation at the stack. Or do you feel that this is a non-issue.

[scothrel]

1-No

2-any bias in a signature is due solely to how we wrote the signature or signature engine. As mentioned earlier, we have no stack...none, nada. We take packets raw from the ethernet MAC chip into our analysis code.

[c.alejandra]

yes I gathered that we are dealing with stakless interface, I was trying word a point in relation to "In effect our code simply replaces the host stack" so not to say ..intepretation at the code.

In all, what has been said in essence is that the packet filtering model is utterly Cisco over other types, that you basically parse raw packets following the protocol specs, that only real filtering is whether or not packet is IPv4 type ICMP/TCP/UDP, that you take packets raw from the ethernet MAC chip straight into you analysis code, and any bias is solely in the signature or signature engine semantic and syntax and not utterly cisco filter model . I was simply curious what happens from 'raw' packet intepretation into signature correlation to determine whether there existed other points of bias that may affect the correlation of a signature. I think I have a lot more questions now; but thankyou very much for you input.