Following your suggestion, I replaced my NIC with an Intel PRO/1000 MT. I then used the manual firmware upgrade process to update to the 2.3.1 Update image (downloaded from the pfSense site). I'm not sure if it's the new NIC or the manual update that did it (most likely the new NIC), but pfSense 2.3.1 is now running stable on my hardware. Thanks for all your help Bill.

@adam65535:

I wonder if it should just be greyed out or shunk down to 1 line to somehow say it can not be set until blocking is enable.  Maybe that doesn't fit in the context of de-cluttering though.  Not a big deal for me as I know how it works now.

There was some discussion along a similar vein back during the end stage of the Bootstrap GUI beta for pfSense (whether to hide or just gray-out controls that are not used/needed depending on other dependent option settings).  The idea behind hiding them completely is to reduce scrolling distance on the page, but there is the potential confusion factor when they are not there at all.

Bill

Thank you for the super fast reply kind Sir!

Winner winner chicken dinner post I found in your post history:
https://forum.pfsense.org/index.php?topic=108365.msg603749#msg603749

# Category DROPS - All emerging categories emerging-activex,emerging-attack_response,emerging-botcc.portgrouped,emerging-botcc,emerging-chat,emerging-ciarmy,emerging-compromised,emerging-current_events,emerging-deleted,emerging-dns,emerging-dos,emerging-drop,emerging-dshield,emerging-exploit,emerging-ftp,emerging-games,emerging-icmp,emerging-icmp_info,emerging-imap,emerging-inappropriate,emerging-info,emerging-malware,emerging-misc,emerging-mobile_malware,emerging-netbios,emerging-p2p,emerging-policy,emerging-pop3,emerging-rbn-malvertisers,emerging-rbn,emerging-rpc,emerging-scada,emerging-scan,emerging-shellcode,emerging-smtp,emerging-snmp,emerging-sql,emerging-telnet,emerging-tftp,emerging-tor,emerging-trojan,emerging-user_agents,emerging-voip,emerging-web_client,emerging-web_server,emerging-web_specific_apps,emerging-worm #try next: #emerging* #  PCRE IPS Policy DROPS  | # ----------------- pcre:pcre:security-ips\s*drop

In addition to this I missed the checkbox for "Enable Automatic SID State Management" (attached screenshot for future pfsense friends).

Screenshot of drop is attached (redtext;blotted out my public ip).

Overkill - attached screenshot of the "Interface SID Management File Assignments" block and screenshot of the whole page.

missedcheckbox.PNG
missedcheckbox.PNG_thumb
reddrop.PNG
reddrop.PNG_thumb
interfacesidmanagementfileassignments.PNG
interfacesidmanagementfileassignments.PNG_thumb
all.PNG
all.PNG_thumb

Suricata seems to allocate 1.5 detection threads per core.  So on my Firewall with 4 cores, I get 6 detection threads and a management thread making 7 for a single LAN interface.

More information in the Threading sections here: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricatayaml

@jpvonhemel:

All is well and I am only seeing alerts and no blocking now.  Any idea how I ended up with duplicate processes running?

Thanks,

Jerold

This can happen when your WAN IP address changes/updates or for whatever reason the system issues multiple "restart all packages" commands in a short period of time.  Snort can get started multiple times in this scenario.  There is logic in the shell startup script for Snort that tries to prevent this, but it does not always work.

Bill

@joemamasmac:

Hello, I am getting an error when starting snort on my pfsense home installation.  The error is as follows.

FATAL ERROR: /usr/local/etc/snort/snort_41876_re1/rules/snort.rules(9) Unknown ClassType: protocol-command-decode

I was not getting any errors until May 13th, then suddenly this started.  It appears is it failing on reading a rule when snort starts, but I have no idea how to clear this out.  Any suggestions?

Joe

The failing rule is on line #9 in the file given in the error message.  Open that file and look at line 9 for the offending rule.  Have you fiddled with any of the preprocessor settings on the PREPROCESSORS tab?  Fiddling with preprocessors (as in disabling some of them that are enabled by default) without a total and complete knowledge of what each one is for frequently results in this kind of error.  Not saying a rule vendor cannot make a mistake now and then, but the most common cause of errors like yours is when someone has turned off a required preprocessor.

Bill

This would involve quite a bit of overhead.  Currently none of the references data is recorded with alerts.  That is just the way Snort and Suricata work.  The only thing you get is the GID:SID and a handful of other parameters.  The References are not included, so the PHP code would have to work some complicated magic behind the scenes to find and link the references.

If you want this level of information, better to configure Snorby or a similar logging repository and send alerts over there.  Snorby has a process where it will automatically find the references if you configure a separate product to provide it the raw rules files.  To do this right and with decent speed would require a relational database.  You don't want that running on your firewall.

Bill

Hi Bill!

Thanks for the insights of how things work :)

If it can be modded great, it it can`t I will click trough :) Not a problem at all.

@THS:

Hello.

I noticed that my CPU was hitting 77 degrees C with my 100Mbps connection saturated.

What Search Method is ideal for this setup ? Default is AC-BNFA.  I notice that my system is only using 1.8GB out of the 4GB available.

Is one of the search methods easier on the CPU but better utlilizes the 4GB ?

Also, what about ET Open rules ? For VRT, I have IPS Policy Selection set to "Balanced"

There is no Policy for ET Open rules.  Which ones are recommended for home / home office use ? I am NOT running any servers btw.

I have a similar set-up to your system running snort and its using less than 1GB!

Try AC-BNFA-NQ for search method.

Personally I do not tick/use IPS Policy,  I pick the rules manually (untick that option to pick rules manually). I also use Snort GPLv2 Community Rules (VRT certified)

If you choose to pick the rules manually I recommend starting with the following rules below, test them for false positives and suppress the false positives there will be quite a few when your just starting to use snort. Add new rules as you go along test and suppress. Good luck!

Start with these:
emerging-malware.rules, emerging-trojan.rules, emerging-worm.rules, emerging-ciarmy.rules, emerging-current_events.rules, emerging-dshield.rules,  emerging-compromised.rules, emerging-scan.rules, emerging-info.rules, emerging-exploit.rules,  emerging-mobile_malware.rules, emerging-misc.rules.

For anyone else having this issue:  delete the file /var/run/snort_pkg_starting.lck and try again. Snort should start right up.

Very, very bad idea to use RAM disks with Snort or Suricata.  You will run out of disk space and have weird issues.  You just experienced one of them.

I suggest only running the IDS/IPS packages on systems with a relatively large hard disk (conventional or SSD) and stay away from NanoBSD installs and the use of RAM disks.

Bill

Those files reside physically on the firewall and are not part of a config.xml backup.  That's why the icons are there to download the files so you can save them offline elsewhere.

Bill

@BBcan177:

How do you quickly find out in which category that SID is, BB?

In the screenshot… it says "INDICATOR-COMPROMISE"
So short answer: "Snort-Indicator-Compromise" category…

Looking at the rule, its enabled with the "Balanced" and "Security-policy" setting:

alert udp $HOME_NET any -> any 53 (msg:"INDICATOR-COMPROMISE Suspicious .pw dns query"; flow:to_server; content:!"|01|u|02|pw"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|02|pw|00|"; distance:0; fast_pattern; metadata:policy balanced-ips alert, policy security-ips drop, service dns; classtype:trojan-activity; sid:28039; rev:5;)

You can click on the "Disable Sid" Icon in the Alerts, or Blocked Tab, to disable on the WAN… and then goto the "LAN Rules" tab in Snort/Suricata and select the Category "Snort_indicator_compromised.rules" and enable sid 28039. You might need to re-start the Interfaces for it to take effect...

If you find that its a False Positive, you could add a suppress to the LAN Interface suppress List, so the rule will only fire for other .pw domains, excluding this particular DST IP... (Once you figure out which DST IP you want to suppress that is...)

suppress gen_id 1, sig_id 28039, track by_dst, ip x.x.x.x

You know I love you with all my heart, BB  :P

But I have no'Snort-Indicator-Compromise'-category, really not ;D Pic to prove**:-*** It turns out I found it, thanks to your tip, in IPS Policy - Security.It was disabled, I enabled it now. Let's see what shows up now.
Thanks BB  :P

BB_daman_hecan.jpg
BB_daman_hecan.jpg_thumb

Just wanted to confirm that this happens even in a vm (VMware Workstation 12 Pro), so it's not a hardware/driver issue.

i have doble the rules for LAN interface performed the test

for some unknown reason…may be start/restart service i start seeing wan alerts.
i have no explanations ...still looking on to understand why it start working now

Bill, thank you for the additional information. It is helping my understanding click together. I am not interested in MITM attacks. I just want to shut down certain things not eavesdrop.

fsansfil, thank you for showing a way to achieve what I was looking for. There is so much to Suricata to take in. As with anything, time and experience is what is needed along with some outside help.

Thanks Bill your thoughts are the same as mine. It must be their web hosting service.