Passive OS/App Identification

From Jeremy at sudosecure:

Network intelligence through passive identification. What I mean by this is like Snorts RNA, NMAP, and p0s fingerprinting to dynamically update inventory data for correlation engine usage. I think we all know how great it would be to have this data which could dynamically or auto magically configure/reconfigure signatures and correlation engines to align with applications and operating systems to truly substantiate the risk of attacks and/or threats. Having the availability of correlated network intelligence could make tremendous headway in the world of anomaly detection i.e. a windows xp home computer correlated with network flow data and port data could easily be alerted on for any outgoing port 25 connections, as they are most likely the newest member of a spam bot network. Obviously this is just a trivial example but it still is not a trivial task to pull off even with the most advanced SIM. This would also allow for operational performance enhancements by providing context regarding the network they operate in. The dynamic configuration and reconfiguration of network devices to ignore threats that are not applicable would definitely enhance performance by reducing overhead caused by signatures and other security measures.

We have to be very careful of patent issues here.


More from David Dagon:

Since this thread is "for the whiteboard", I'll describe the pony I'd like for xmas:

-- your tool should allow me to hook a p0f module, or my own DSO that performs immediate classifications. (These classifications could then trigger more than logging; e.g., firewall-like match rules, e.g., "drop if win95", etc.)

The callback is immediate.

-- the tool should also allow me to hook a DSO that does active probing. p0f does not catch them all, and so I might want to initiate some active probes of an IP witnessed in flows (e.g., some pen testers jiggle 137/139/445 to get a version string).

Let's put aside the dos-enabling potential for a moment, for purposes of this example. Say instead I might want to consult a database about the flow pairs, and wait out a SELECT, or a dnsbl rtt. Whatever; after my probes/additional inquiry complete, I may have further classifications to report, and more firewall behaviors to trigger.

Here, the callback is not immediate, but assync.

I.e., there are quick-and-dirty OS fingerprinting techniques that one can use via a pluggable module. There are also some active measurements or correlations that can do a better job of fingerprinting--allow these as well. These would be invoked at the operator's own risk.

But if you permit an async update on flow classifications, you will create the API that permits new innovations, instead of merely integrating existing opensource technologies.


We ought to also consider comparing these to the user-agents captured. If a user agent changes, or doesn't match the host OS an alert would be of interest.

-- MattJonkman - 17 Oct 2008

Topic revision: r3 - 2008-12-22 - MattJonkman
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © Emerging Threats