IPS6.0(3)E1: POSFP and ARR questions (Bugs?)

Unanswered Question

1. It seems that in my test network passive OS fingerprinting isn't working at all. The sensor is unable to fingerprint IOS 12.4, Windows 2000 Pro, Solaris 8 and most of Internet sites including www.cisco.com :)

S1# sh statistics os-identification

Statistics for Virtual Sensor vs0

OS Identification




IP = (bsd)

IP = (bsd)

The sensor learned the above 2 mappings after Internet browsing. Does anybody have success with this feature? Should some specific requirements be met for this feature to work?

2. It is documented that if an attack is not relevant the ARR=10 should be subtracted from the RR. This doesn't hold true. Am I missing something here? (If an attack is relevant the ARR=10 is added -- this works well.)

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
didyap Wed, 01/16/2008 - 09:05

For passive/active fingerprinting the contextual endpoint profiling based on passive OS fingerprinting and/or static mapping is added to the values within the Risk Rating algorithm to determine block action thresholds. Following links may help you



marcabal Wed, 01/16/2008 - 11:35

The Passive OS Fingerprinting is a best guess based on what the sensor can passively detect in the packets being monitored.

Create a service account on your sensor and login to the service account.

You can then look at the file /usr/cids/idsRoot/etc/osfp.conf to see specifically what the sensor is looking for when doing passive OS fingerprinting as well as seeing for what OSs the sensor is able to passively detect.

There are things that can prevent the sensor from properly fingerprinting the OS. If the packets go through a firewall then in many cases the firewall will alter the packets as they pass through the firewall.

The firewall may modify 1 or many of the different options that the sensor is looking for when trying to fingerprint the OS.

The end result is that trying to fingerprint the OS on any packets passing through a firewall or other device that alters the packets could lead to incorrect results.

Trying to passively fingerprint anything going through the internet is difficult because the web server generally sits behind a firewall.

The passive OS fingerprinting is generally not for fingerprinting addresses on the internet, but instead figerprinting of OSs for machines within your own network. The sensor sits inside the firewall right next to your own machines. This way there is no device modifying the packet between your machines and when the sensor sees the packet.

There is also a configuration setting so you can limit the passive OS to just your internal network addresses.

As for the calculation of the Risk Rating. I am not positive, but if I remember correctly there is a difference between promiscuous and inline. In Promiscuous the ARR of 10 is subtracted from the Risk Rating if it is not relevant. But with InLine I believe the decision was to not subtract from the Risk Rating is it is not relevant. So the Risk Rating never gets lowered in InLine, and can only be increased if it Is relevant. While Promiscuous can be increased and lowered based on relevance.

The reason behind this is the difference in expected uses of the Risk Rating when running Promiscuous and InLine.

In Promisucous the Risk Rating is primarily just for prioritizing which alerts are most important to look into for further analysis. So an irrelevant alert should have a lower priority and a lower Risk Rating.

In InLine the Risk Rating is, however, more for use with Event Action Overrides to add Deny actions in order to deny the attack.

In this situation we would want the attack to be denied regardless of whether or not it is relevant. For example, a windows attack against a Linux box should still be denied even though it is not relevant. So with inLine we don't subtract from the Risk Rating so we can try to ensure the most protective action takes place.

If I remember right these discussions happened later in our development cycles. It is possible that the decision to not subtract in inline may have happened after initial drafts of end user documentation and may not have been caught during documentation reviews prior to posting.

I am not positive that this change went in. It was still being discussed last I was involved. But I am assuming the change went in since it would explain the reason you are not seeing the decrease in Risk Rating.

Great explanation, however, I cannot agree...

1. I have W2k, Solaris and IOS boxes right behind my sensor. There is no firewall in between (they're in the same VLAN). I'm opening http sessions from W2k to Internet and telnet sessions between Solaris and IOS, but POSFP isn't working. Also, dynamic mappings disappear after some period of inactivity (not documented).

2. I believe that prioritizing alerts for IEV by lowering RR is equally important in both IPS and IDS modes. Otherwise, why did you introduce Threat Ratings in 6.0? And they work uniformly in both IPS and IDS modes, right?. So, the current behaviour (not subtracting 10) should be considered as design Bug. Of course, 10 should be added/subtracted to/from Threat Rating, NOT Risk Rating. And you're correct, the current behaviour for promisc. mode is not documented.

Marcoa, could you please take a look at other forum topic that we've discussed earlier? It's about anomaly detection.

Also, I'm going to post another important question to the forum shortly :)


This Discussion