Snort rules triggering on incorrect OS version

[DannyDulin]

Our Firepower Threat Defense SNORT engine is triggering rules that don't match the actual traffic.

For example, rule 1:16540:18 references CVE-2010-0477 which has the description: The SMB client in Microsoft Windows Server 2008 R2 and Windows 7 does not properly handle (1) SMBv1 and (2) SMBv2 response packets, which allows remote SMB servers and man-in-the-middle attackers to execute arbitrary code via a crafted packet that causes the client to read the entirety of the response, and then improperly interact with the Winsock Kernel (WSK), aka "SMB Client Message Size Vulnerability."

However, the source device is Windows 10 and the destination is Windows Server 2019.

Can anyone tell me why this is happening?

Firepower says it is an Impact 1 event, but it is not an affected OS version.

Even the Microsoft Security bulletin does not include these OS as affected versions.
https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2010/ms10-020?redirectedfrom=MSDN

Any help will be greatly appreciated.

[Octavian Szolga]

Hi,

Snort actually uses a process called network discovery in order to identity operating systems and apps used throughout the network. It does this by using 'signatures' (part of the VDB package) that are applied to traffic that it 'sees'. Thus this is a passive way of discovering hosts. It's just its best guess.

You know that the source and destination are not win7 or 2008R2 because you can logon to that resource and manually check the OS version and all the details.

Snort has to means of doing that.

You can go to Analysis > Hosts > Hosts > Table View and search for your specific IPs and check that Snort thinks of them.

If needed you can manually edit the operating system for those particular hosts.

If OS fingerprinting is wrong, it's normal for that IPS signature to have an Impact 1 attached, because the system considers the host to have the protocol running and the respective vulnerability mapped.

BR,

Octavian

[DannyDulin]

Octavian,

This is EXTREMELY helpful. Thank you!

I guess this is why we would use NMAP scan as an initial remediation for a Snort Rule trigger.