Snort with CARP sync

Hello,
Is there any way to enable snort to sync the rules from the primary CARP member to the secondary? Going through the rules and clicking each and every single one needed takes a heck of a lot of time. Syncing of all of snort settings would be nice as well.

Searching on google I came up with this:
http://forum.pfsense.org/index.php?topic=42187.0;prev_next=next
which says that the sync function was removed.

Further down the google results is this:
http://www.pfsense.com/packages/config/snort/snort_xmlrpc_sync.php
which shows the code for the sync (if I understood it correctly)

Question is how do I enable it?
If there is a valid reason for the removal (such as the network will go down in a great fireball and start the apocalypse) I can understand it. If it was by mistake, please re-enable the checkbox.

bmeeks

@jflsakfja:

Hello,
Is there any way to enable snort to sync the rules from the primary CARP member to the secondary? Going through the rules and clicking each and every single one needed takes a heck of a lot of time. Syncing of all of snort settings would be nice as well.

Searching on google I came up with this:
http://forum.pfsense.org/index.php?topic=42187.0;prev_next=next
which says that the sync function was removed.

Further down the google results is this:
http://www.pfsense.com/packages/config/snort/snort_xmlrpc_sync.php
which shows the code for the sync (if I understood it correctly)

Question is how do I enable it?
If there is a valid reason for the removal (such as the network will go down in a great fireball and start the apocalypse) I can understand it. If it was by mistake, please re-enable the checkbox.

I am sort of the defacto part-time Snort package updater of late. I have added a few features over the last months to the package such as auto-flowbit resolution and fixed a few bugs. Currently there is nothing in the Snort Package related to CARP replication. I see no evidence of that ever being within the current code. I am not the original author of the package, so I don't know about its past history. From the links you provided it was apparently removed quite some time back, but I have no idea by whom or why.

It might be possible to resurrect it at some point, but I am not skilled enough in the art of CARP to say for sure when or how at this point.

Bill

marcelloc

We can work together on it. :)
I can push sync code and you test snort behavior on backup system.

I would be happy to test the functionality.
A couple of suggestions for limiting the impact of errors during sync:

First we should test if the rules get synced to the secondary system. For example if I chose to disable rule XXXXX on master, the change gets replicated to the secondary. Same goes for enabling rules. Snort does not need to restart on the secondary, it will reload the rules during the normal update procedure. For my use I have snort pretty much dialed in to the rules that do not provide false positives, but I simply need a way to get them from the master to the secondary without the days it takes to enable each and every single one of them. Sure a button to enable all rules and then disable unneeded ones would be good, but what IMHO not as useful. I could disable a rule on the master and forget about it on the secondary and it will provide false positives when the secondary takes over.

Then we should test if the suppression and whitelists get synced. I'm not near the systems now, but I think whitelists get synced since it's technically a firewall alias.

If all that works OK personally I'm quite happy with it. But why stop there? You should make it so that the settings on the master get replicated to the secondary as well (preprocessors selected, variables).

Providing a code for syncing of blocked hosts from the master to the secondary would be extremely helpful. I'm pretty sure this would be easy to implement if the code handling the blocked hosts gets changed so that it writes to an alias. As far as I can understand the current workings, it writes to a table (snort2c if I'm not mistaken) but this is not an alias in the normal pfsense way (firewall>aliases) and therefore does not get replicated to the secondary system as part of the normal CARP sync, like other aliases do.

High > low IP scans (reverse order)? This can happen if the "attacker" (more like a script kiddie running a scanner) choses to reverse the order of the scan (high IP > low IP). The current way of detecting such things is for those running redundant firewalls to select the first IP allocated to you for the master system, the second IP for the secondary system and a high IP for the CARP shared WAN IP (the same IP that you should make your ISP use as the default route for IPs allocated to the DMZ for example). It detects low IP > high IP scans since the order of the IPs matches that, and detects high IPs > low IPs scans as well (since the secondary is technically "after" the master, it will see the scan "first" (the shared IP will see the high>low scan first to be precise).

And keeping in tune with the paranoid systems admin way of thinking, what if the secondary system detects a threat the primary did not? (directed scan to the secondary system). A code replicating blocked hosts from the secondary to the primary would be helpful in such a situation, but I'm not sure it's possible. I would be extremely happy to be proven wrong.

In summary, the code needs to replicate settings from the master to the secondary but not from the secondary to the master, but it must also replicate blocked hosts both ways. If I misunderstood the way CARP works, please correct me (secondary > master replication).

Any suggestions to further fine tune the replication much appreciated.

TIA

bmeeks

Everything for Snort (selected rules categories, SID enable/disable overrides, preprocessor states, whitelists, suppression lists, etc.) lives within the config.xml file for the firewall. So as long as the sync process copies over the Snort package section from one config.xml to the other, and then Snort is given either a start or restart command, it will be synchronized on the two machines in terms of configuration.

You could even copy over the snort2c host blocking table, I guess. The entries could be inserted/removed on the secondary side using the pfctl utility. I am not familiar with the protocols or processes used for CARP, though.

If either of you need some additional Snort information during your testing, just let me know via a post or PM.

Bill

I see that snort sync has been added back in 2.5.8. Thank you, you just saved me a couple of months work.

On Sync tab I have:
Sync to configured system backup server and signal target host to refresh rules files.

After hitting save, all rules selected by me have been transfered over to the secondary system. I have verified that rules not selected have been unselected on secondary host as well. Snort interface restarted on the secondary system as expected.

I'll keep an eye on the systems and report back any errors. So far so good.

Many many many thanks! ;D

edit: did the icon next to the interface change color? (green=running, red=not running). Mouse over suggests so, which kinda confused me since it used to be the other way around (red=running, green=not running).

marcelloc

@jflsakfja:

I see that snort sync has been added back in 2.5.8. Thank you, you just saved me a couple of months work.
Many many many thanks! ;D

Donations are always welcome ;D

@jflsakfja:

edit: did the icon next to the interface change color? (green=running, red=not running). Mouse over suggests so, which kinda confused me since it used to be the other way around (red=running, green=not running).

Yes, tool tip info(mouse over) shows this info.
For a complete list of snort package changelog, take a look here

bmeeks

@jflsakfja:

I see that snort sync has been added back in 2.5.8. Thank you, you just saved me a couple of months work.

Many many many thanks! ;D

Those thanks go to Marcelloc. ;D He contributed the main Snort CARP Sync code. I will be posting a Change Log with some screen shots of new stuff this weekend for the Snort 2.5.8 package.

Bill