IP Reputation and Distributed Blocking Working Group
This group has the responsibility of making implementation recommendations for the IP Reputation and distributed blocking functionality of the OISF IDS Engine. The primary questions to make recommendations about are:
- What scoring system and scale to use (i.e. -100 to +100, 0 to 10, etc)
- What categories to rate for? (i.e. spammer, Bot CnC?, open proxy, scanner, brute forcer, Public Service (google), etc)
- How to handle whitelisting.
- How to integrate distributed blocking into this single feed.
- How to make this feature both group/open reputation and commercial reputation fed.
Matt Jonkman (email@example.com
) leads this group for the time being. This groups recommendations are due on August 12th, 2009. They should be posted here and to the OISF Discussion Mailing lists.
This group's mailing list for discussion is available here:
Initial Recommendations (subject to change)
Alright, it's time for us to make our recommendations to the coders. The framework for reputation will begin coding very soon. So here is what I think we have as a summary of the major issues:
- 1. We should use a range of 0-255 internally for reputation for ease of code, but display to the human wherever possible as a negative number, to 0, to a positive number.
- 2. 0 (or 127, the midpoint of reputation) should be construed as "no data about this host"
- 3. The engine should allow the local admin to weight each category for each sensor for each incoming feed up or down (or to disable that category)
- 4. All incoming feeds and sensors feedback would be averaged to make a global local reputation database according to the local weighting
- 5. Reputation should not be used in the ruleset for high criticality rules
- 6. Creating positive reputation may not be automatable, but will be possible for the local admin to force a very high reputation (i.e. whitelisting)
- 7. In the ip reputation config a score for an IP or netblock or range can be forced to a value and remain there (i.e. whitelisting). That data would stay local and not be fed back to any shared resources
- 8. We'll work toward making event managers able to access and consider this reputation data.
- 9. New reputation data would add to or subtract from a reputation in a category, not set the reputation to that value. It will take many good or bad indicators over time for a reputation to make a significant shift either direction.
Our initial list of categories to track reputation will be (and can be added to over time, we'll leave open channels):
- Spam (spam bot, or known spamming network)
- CnC? (known malware command and control server)
- Scanner (known to be ssh brute forcing, web exploit probing, etc)
- Hostile (hijacked networks, known RBN nets, etc)
- Dynamic (Known dial up, residential, user networks)
- Public Access (known internet cafe's open access points)
- Proxy (known tor out nodes, proxy servers, etc)
- P2P? (Heavy p2p node, torrent server, other sharing services)
- Utility (needs a better name, but for known good places like google, yahoo, msn.com, etc)
- DDoS?. Known ddos participant. Very good for automated
- Known Phishing site.
- Known Malware distribution site. (Hacked web server etc)
- Known Zombie (botnet member) (They typically are Scanner or Hostile, but if collaboration with botnet snooping, like we did back in 2005 or so, can proactively identify online zombies that joined a botnet)
- 28 Jul 2009