Snort with PF_RING(?)
-
Hi, I'd like to know if there is a version of Snort using PF_RING for packet capturing. I've heard it really improves the performance of Snort and packet filtering.
-
Hi, I'd like to know if there is a version of Snort using PF_RING for packet capturing. I've heard it really improves the performance of Snort and packet filtering.
No, unfortunately Snort on pfSense does not utilize PF_RING. It uses the DAQ library, but not with PF_RING.
Bill
-
I just installed snort, added the WAN interface but using only custom rules, beacuse I need to mitigate just concurrrent connections, no more. But when I put this simple rule
alert tcp any any -> any 80 (msg:"HTTP Service Rule Example"; sid:2000983; rev:1;)
the snort isn't generating alerts.
Snort is UP and running, somtimes generating this alerts
119:32:1 (http_inspect) SIMPLE REQUEST
But never the one of the custom.rules
Any Idea?
-
I just installed snort, added the WAN interface but using only custom rules, beacuse I need to mitigate just concurrrent connections, no more. But when I put this simple rule
alert tcp any any -> any 80 (msg:"HTTP Service Rule Example"; sid:2000983; rev:1;)
the snort isn't generating alerts.
Snort is UP and running, somtimes generating this alerts
119:32:1 (http_inspect) SIMPLE REQUEST
But never the one of the custom.rules
Any Idea?
First, you need to add "class type" to your custom rule. Snort is very picky about rule formatting, and the class type must be present. Also, the class type you use MUST be present in the classification.config file for the interface.
Next thing is to make sure your custom rules file is present. Depending on your pfSense version (2.0.x or 2.1), look in the following directory for a custom.rules file and verify it contains your rules.
2.0.x
/usr/local/etc/snort/snort_if_xxxx_/rules2.1
/usr/pbi/snort-{arch}/etc/snort/snort_if_xxxx_/rulesIn each of the above directory paths, the if parameter will be the real interface name determined by the NIC driver you are using (for example, with Intel E1000 NICs it will likely be "em0" or "em1"). The "xxxx" parameter will be a random number (UUID).
If the custom.rules file is present in the correct directory and contains the correct content, then verify it is being loaded by backing up one directory level from where the rules file is located and look through the snort.conf file. Near the bottom you will find the rules files being loaded and used. You should see three: (1) custom.rules, (2) snort.rules and (3) flowbit-required.rules.
Bill
-
I just installed snort, added the WAN interface but using only custom rules, beacuse I need to mitigate just concurrrent connections, no more. But when I put this simple rule
alert tcp any any -> any 80 (msg:"HTTP Service Rule Example"; sid:2000983; rev:1;)
the snort isn't generating alerts.
Snort is UP and running, somtimes generating this alerts
119:32:1 (http_inspect) SIMPLE REQUEST
But never the one of the custom.rules
Any Idea?
First, you need to add "class type" to your custom rule. Snort is very picky about rule formatting, and the class type must be present. Also, the class type you use MUST be present in the classification.config file for the interface.
Next thing is to make sure your custom rules file is present. Depending on your pfSense version (2.0.x or 2.1), look in the following directory for a custom.rules file and verify it contains your rules.
2.0.x
/usr/local/etc/snort/snort_if_xxxx_/rules2.1
/usr/pbi/snort-{arch}/etc/snort/snort_if_xxxx_/rulesIn each of the above directory paths, the if parameter will be the real interface name determined by the NIC driver you are using (for example, with Intel E1000 NICs it will likely be "em0" or "em1"). The "xxxx" parameter will be a random number (UUID).
If the custom.rules file is present in the correct directory and contains the correct content, then verify it is being loaded by backing up one directory level from where the rules file is located and look through the snort.conf file. Near the bottom you will find the rules files being loaded and used. You should see three: (1) custom.rules, (2) snort.rules and (3) flowbit-required.rules.
Bill
This is the rule now:
drop tcp any any -> any 80 (msg:"HTTP Service Rule Example"; sid:2000983; rev:1; classtype:denial-of-service;)
It is Included at the bottom of snort.conf and no alerts are generated :c
-
This is the rule now:
drop tcp any any -> any 80 (msg:"HTTP Service Rule Example"; sid:2000983; rev:1; classtype:denial-of-service;)
It is Included at the bottom of snort.conf and no alerts are generated :c
One thing just caught my eye. Change "drop" to "alert", restart Snort, and see if that helps. Snort on pfSense is not actually "inline", so "drop" does not work as you might expect. All of the standard rules use "alert" for the action. Sorry I did not notice that in my earlier post.
Dropping of traffic on pfSense is actually done by "blocking" the SRC, DEST or BOTH according to how the blocking feature is configured on the Snort Interface tab for the interface. Blocking happens when an ALERT is triggered and logged. A plugin compiled into the Snort binary package on pfSense sees the alert and inserts the IP addresses into the blocking table within the firewall (after screening for HOME_NET and whitelist membership).
Bill
-
This is the rule now:
drop tcp any any -> any 80 (msg:"HTTP Service Rule Example"; sid:2000983; rev:1; classtype:denial-of-service;)
It is Included at the bottom of snort.conf and no alerts are generated :c
One thing just caught my eye. Change "drop" to "alert", restart Snort, and see if that helps. Snort on pfSense is not actually "inline", so "drop" does not work as you might expect. All of the standard rules use "alert" for the action. Sorry I did not notice that in my earlier post.
Dropping of traffic on pfSense is actually done by "blocking" the SRC, DEST or BOTH according to how the blocking feature is configured on the Snort Interface tab for the interface. Blocking happens when an ALERT is triggered and logged. A plugin compiled into the Snort binary package on pfSense sees the alert and inserts the IP addresses into the blocking table within the firewall (after screening for HOME_NET and whitelist membership).
Bill
Now it really works!!! Thank you very much, you just helped me a lot.
-
Now it really works!!! Thank you very much, you just helped me a lot.
You are welcome. Sorry I did not catch that "drop" versus "alert" change on my first post. Must have been reading while half asleep… :D
Bill
-
Now it really works!!! Thank you very much, you just helped me a lot.
You are welcome. Sorry I did not catch that "drop" versus "alert" change on my first post. Must have been reading while half asleep… :D
Bill
Look this capture http://puu.sh/2UdxH.png
Edit: When I finished writing this post I went up to 5000.
