Information, OpenSourceSoftware, polman, Security

Yet another rule manager for VRT/ET/ETPRO or Suricata/Snort rules…

As I installed a new home router/firewall some months back, I installed it with an IDS (Sguil) just to have something to play with at home. I never got comfy with oinkmaster or pulledpork as I had to dig into config files too much…

Based on my idea for sidrule on how to manage rules, and also baring in mind cerdo, I quickly made a sidrule like tool in perl. I talked to some people about it and they liked my approacher on how to do rule management. I got some very positive feedback, so I decided to rewrite it and publish the code (Get polman 0.3.1 here).

To cope with not having a configuration file, you have to start polman with the –configure option to add a RuleDB (or more) and a Sensor (or more). A RuleDB is a “database” that holds rules. The idea is that you can load Sourcefire VRT rules for Snort version X.X into one RuleDB, and you can also load Emerging Threats rules for Snort X.X into the same RuleDB and have nice set of rules to play with. As I’m currently testing Suricata, I can with the same tool, and without any extra configfile or too much hassle, make a second RuleDB, but this time one with the VRT rules and with the ET suricata rules in it. I have one Sensor attached to the Snort RuleDB, and the other one to the Suricata RuleDB. One tool too rule them all…(LOTR->Lord of the Rules?).

A bit back to the –configure option. This will enter a ascii menu where you can add and edit RuleDBs and Sensors. For a RuleDB, you specify where to load the rules from (Currently just filesystem, but http/https is scheduled for next release), name, comment, etc. For a Sensor, you specify name, comment, what RuleDB to use, where to write rules to (a file, for writing all rules to a file or a dir, for writing all rules out into their original filename in that dir), where to write file, etc.

Once a RuleDB is set up, you can eater from the menu load rules into the RuleDB or from command line. Once a Sensor is setup, and the specified RuleDB has rules in it, you can start to play with the Sensor rules. If you choose to write out rules from the menu straight away, it will turn on all rules that are default turned on by vendor (VRT/ET/ETPRO etc.). When you are back at command line, you can start turning on/off rules. One way I start, is to disable categories that I normally would not enabled in my setup, example: -i SensorA -m "(dos|games|icmp_info|pop3|rpc|scada|scan|snmp|sql|voip)"

This will search through all the rules based on the filename that the rules was loaded from. So from only the “sql” entry in my regexp above, it would typically show you all rules that where in the files: emerging-sql.rules, mysql.rules and sql.rules.
You will then be faced with some questions… Disable them all? or Enable them all? (With this particular search, I disable all the rules). There is also a third option, and that is to go through the rules, rule for rule, to make a conscious decision after you read the raw rule. If you choose to enable all rules, or based on rule for rule, you can change behavior of the rules to. Most rules are set to action “alert“, but if you choose to enable rules, you will have the option to change action for rules (to alert,log,pass,drop,reject,sdrop,default or current). The option “default” and “current” may need some explanation… Default will set the rule to the default action that was set by the vendor. Current will leave the rule(s) as they are defined for the sensor (say you have set an alert rule to drop before, the rule will keep the current action for the rule, which is drop).

There are some powerful searches built into polman. You can search in field classtype, metadata and msg at the same time. You can also search in “fields” ‘default enabled/disabled’ (Vendor state of the rule) and category (which is default filename where the rule was loaded from).
Say you want to search all rules that VRT classifies in their most secure config: -i SensorA -p "policy security-ips drop"
(You can then enable them all, and set action to drop).
Say you want to limit your search, and you only want to search for Zeus/Zbot traffic… -i SensorA -p "policy security-ips drop" -s "(Zeus|Zbot)"
Now you can enable them all, and set action to drop 😉

If you have a sid, or a list of sids, you can enable (-e) or disable (-d) them rather easy… -i SensorA -e sid1,sid2,sid3,....,sidN

To load rules into a RuleDB from command line: -r RuleDB1 -u

To write out rules for a sensor to a file (or files if a dir is specified): -i SensorA -w
This also writes out the file…

There is nothing wrong about reusing the same Sensor rules across multiple sensor. Indeed that is one of the reasons that I choose the name policy manager, as they don’t need to be looked upon as Sensors that you define, but also Policies (I have thought about naming of Sensor/Policies a lot). In the future I hope to finish the implementation of Thresholding and Suppression too, so that you can edit them quickly from command line.

Thoughts and feedback are welcome on this blog or here!
Project on github here.
An example on how to use polman here.


9 thoughts on “Yet another rule manager for VRT/ET/ETPRO or Suricata/Snort rules…

    • Hi Joel,
      I don’t mind it, but the tool is fresh 🙂 So I’m a bit afraid of negative feedback if it is not ready for the masses. More testing and larger user base would be nice though to look for bugs etc 🙂 Give and take I guess. You decide 🙂


  1. Fungerer bra eneste jeg savner er hvis man har en sensor hvor trafikken er filtrert, da er det ønskelig og filterere reglene basert på brannmur policy hvor bare noen få porter er åpne det kan da være ønskelig og basere seg på bare regler som samsvarer med disse. feks bare bruke regler basert på alert tcp %internal_net any -> %external_net %http_ports


    • Hi Johannes,

      I have thought about using data from PRADS to help narrow the rules that you need, as PRADS will know what ports traffic is running on (Also Services and OS++). But anyways, I need to implement a way for PRADS and Polman to “communicate” and when that is done, it should be able to use the same functions to enable/disable rules based on type of traffic. On your suggestion, Ill move that thought of implementing the functions farther up from my internal memory (my brain) onto the TODO list on Polman 🙂 As now its just under PRADS integration. Thank you very much for your feedback.


  2. Looking forward to prads intergration this will help in rule tuning a lot for rules that dont need to run in peoples envorments. It will also take care of vendor rules if people are only running windows or linux hosts. It is certanly a blessing for people who is managing rule updating with different network envorments. Then people will have real network awarness with their sensors and rules thanks to prads and polman. Im already loving that you can use prads for host atrribute tables in tuning preprocessors. Keep up the good work!


  3. Rav says:

    Hey I am working on suricata and i was thinking is there anyway that suricata load rules directly from database rather than from files.
    I am trying to set a database of rules instead of individual files


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s