Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bmeeks

Pages: [1] 2 3 4 5 ... 222
IDS/IPS / Re: Suricata Really Annoying, Blocking Everything
« on: Yesterday at 08:03:05 am »

if you use the Inline IPS mode there won't be any blocking by default only alerts. This way you have time to configure blocking on specific categories or rules in the SID mgmt menu using dropsid.conf file.
So far I use these in my dropsid.conf and I'm satisfied with the results. Feel free to modify for your needs:

Code: [Select]

1:2016149       # ET INFO Session Traversal Utilities for NAT (STUN Binding Request)
1:2016150       # ET INFO Session Traversal Utilities for NAT (STUN Binding Response)
1:2012247  # ET P2P BTWebClient UA uTorrent in use
1:2221002  # SURICATA HTTP request field missing colon
1:2221013  # SURICATA HTTP request header invalid
1:2016777  # ET INFO HTTP Request to a *.pw domain
#1:2013031       # ET POLICY Python-urllib/ Suspicious User Agent
1:2014701  # ET DNS Non-DNS or Non-Compliant DNS traffic on DNS port Opcode 6 or 7 set
1:2014703  # ET DNS Non-DNS or Non-Compliant DNS traffic on DNS port Reserved Bit Set

I just copied your setup into my suricata setup. Have you found for this to be sufficient at start up or have you added more since then. Where u at now as far as rules go. I just setup suricata and disabled hardware notification rule which was pretty much flooding the log. I googled it before i did that.

been trying to find more info regardin dropsid.conf or how to copy a setup like this. But i havnt found anything. Could anyone please point me in the right direction how you use above setup to copy it into your own suricata setup

Very easy.  In @mind12's post click the small red "Select" link to select everything in the code box and then copy that to the clipboard using CTRL+c or whatever other shortcut your computer uses.  Now go over to Suricata and open the SID MGMT tab.  Click the ADD button to create a new dropsid.conf file.  In the modal dialog that opens, type the list name on the top line (I suggest something like "dropsid-LAN.conf" or "dropsid-WAN.conf" depending on the interface you intend to use it with).  Then paste the clipboard contents into the textarea control in the middle of the dialog using the appropriate keyboard shortcut for your computer (CTRL+v) for Windows.  Click SAVE to create the new list.  It will now show up along side the other sample lists on the page.

Go down to the interfaces list at the bottom of the SID MGMT page and in the row for the interface you want to assign the new dropsid.conf file to, go across to the dropsid drop-down selector and choose the just-created list.  If you want to immediately apply the list to the running Suricata interface, then tick the checkbox over on the far left end of the row and then click SAVE.  That's it.

You can view the result of the automatic SID MGMT operation by going to the LOGS VIEW tab, choosing the interface where you assigned the new list, and then selecting the "sid_changes.log" in the drop-down for selecting which log to view.  The contents of the log will appear in the window.


Packages / Re: What is Snort Blocking Right Now?
« on: Yesterday at 07:56:26 am »
My wife has an app on her phone. Its doesn't work properly on our pfSense w/Snort network. But it does work fine over Cell Data and our friends Wifi. So I'm thinking Snort has blocked something.
But I can't figure out how to determine what IP Address is being block 'right now' (ie: when she's trying to use her app). The Snort alerts are over an hour old.
I know this should be painfully obvious, but I just can't find it. And Googling hasn't turned up any clues.
Thanks, in advance, for your help!

There is a tab called BLOCKS.  That tab shows the list of IP addresses that are currently being blocked along with the rule (or rules) that triggered the block.  You should also configure the "Clear Blocked Hosts" setting on the GLOBAL SETTINGS tab to something like 15 minutes or maybe up to an hour.  This will automatically remove blocked hosts after the specified period if those hosts have not seen traffic during the period.

You can manually remove blocks on the BLOCKS tab as well by clicking the icon next to the block.


Hi OsrRon,

I have upgraded rules already and working like a charm

Code: [Select]
Mar 14 12:08:43 pf php: /usr/local/pkg/suricata/suricata_check_for_rule_updates.php: [Suricata] There is a new set of Snort VRT rules posted. Downloading snortrules-snapshot-3000.tar.gz...
Mar 14 12:08:48 pf php: /usr/local/pkg/suricata/suricata_check_for_rule_updates.php: [Suricata] Snort VRT rules file update downloaded successfully.

rules 3 same as rule 2.990 and they only removed "snort_blacklist.rules" and "snort_local.rules"

This is good to know. I had not tested Suricata with the Snort-3.0 rules.  I have been waiting on Snort-3.0 to get closer to RELEASE status before investigating creating a GUI package to support it.


IDS/IPS / Important Info About Passlists with Suricata Inline IPS Mode
« on: March 15, 2018, 04:50:36 pm »
If you use Suricata and have a network card that fully supports Inline IPS Mode, then this notice is important to you so read on.  If you use Legacy Mode blocking,  then none of what is said below applies to you and you can skip it if you desire.

History of Passlists
The idea of passlists sprang from the old Legacy Mode Blocking used in Snort and later in Suricata when that package was created.  Legacy Mode uses a custom plugin that runs within the Suricata binary.  This plugin intercepts every ALERT triggered by the rules.  The plugin extracts the IP addresses from the ALERT (source and destination) and then inserts one or both of them into the snort2c table that lives in the pf (packet filter) firewall engine in pfSense.  Any IP address inserted into that pf table will be subsequently blocked by the firewall.  So that is how Legacy Mode blocking really works.  IP addresses extracted from ALERTS are put into that snort2c table and the pf firewall takes it from there.  Some options were added to the Legacy Mode plugin that allow the user to specify which IP address from the alerting packet to block (SRC, DST or BOTH).  Another requested feature was the abilty to exempt certain IP addresses from ever being blocked even if they triggered an ALERT.  Thus was born the idea of the Passlist.  The Passlist is simply a list of IP addresses or IP network subnets that should never be blocked.  The Legacy Mode plugin consults this list of Passlist IP addresses before sending the IP from an alert packet over to the pf firewall's snort2c table.  If the IP is on the Passlist, then it is not sent over to pf and thus is not blocked.

A passlist was needed in Legacy Mode because once an IP address gets into the snort2c table, all further traffic coming from or going to that IP address is blocked.  This includes even non-malicious traffic.  So "blocked" really means blocked until the address is physically removed from the snort2c table.  This can be done by the user manually, by rebooting the firewall or by means of a cron task that periodically removes addresses from that table.

Why Inline IPS Mode Generally Negates the Need for a Passlist
Inline IPS Mode is a different animal when it comes to blocking traffic.  It does not use the firewall at all.  Instead, it creates a netmap pipe between the NIC driver and the pfSense kernel and pf firewall.  You can visualize this as literally a pipeline that connects these two endpoints.  All network traffic to and from the network interface must go through that pipe.  Suricata sits in the middle of that pipe and acts like a gatekeeper.  If a Suricata rule with the DROP action is triggered, the packet that triggered the rule is literally just dropped by Suricata and not passed on to the other end of the pipe.  So assume a packet was coming from the NIC on the way to the kernel and pf firewall for processing and that packet triggered a Suricata DROP rule; then that packet is just ignored by Suricata and never forwarded on to the kernel and pf firewall for futher processing.  However, if the packet triggers just an ALERT rule or no rule at all; then it is passed on to the kernel and pf firewall for futher processing.

One key point to note here is that this inspection and passing/dropping is done on a packet-by-packet basis.  So since no IP address gets put into the firewall table, you don't have to worry about subsequent non-malicious traffic to or from the same IP host being blocked.  This is an important point!  Bad packets are dropped for an IP address, but good packets pass for that same IP address.  Compare this to the old Legacy Mode where once an IP address was put into the snort2c table all traffic with that IP address in it was blocked (both malicious and non-malicious).  So this difference in the way blocks are handled minimizes the need for a Passlist with Inline IPS Mode.  In fact, in most instances, you should never need or want a Passlist with Inline IPS Mode.

Suricata 4.0.3 Inline IPS Mode and Default Automatic Passlists
Okay, this is the section where I admit making a mistake by allowing myself to be talked into including a default Passlist option when using Suricata Inline IPS Mode.  I added that capability a while back (I think it was when 4.0.1 came out).  Anyway, you have the option at the moment on the INTERFACE SETTINGS tab of choosing "none", "default" or any other user-created Passlist for the Passlist Setting on the interface when using Inline IPS Mode.  The help text associated with the Passlist control recommends you choose "none", and so do I!  Here's why.  If you choose "default", then a potentially bad thing happens.  Some PASS rules get automatically created that effectively whitelist your entire LAN.  By "whitelist" I mean no alerts or drops from anything whose IP address is in your LAN or any other locally-attached firewall networks.  And what's worse, this whitelist extends to traffic flow in both directions:  (1) FROM a device on your LAN to elsewhere; and (2) from elsewhere TO a device on your LAN.  This is not good as bad stuff can flow to/from your LAN hosts and other locally-attached firewall networks and Suricata won't care!  This bad situation came courtesy of the existing default passlist code used for Legacy Mode operation.

Here are some examples of how the automatic default Passlist rules can be bad --

The current "default" passlist includes locally-attached networks if you select that option when creating a pass list (and it is checked by default).  So assume your LAN is the subnet  So Suricata will create this pass rule for the default Passlist when the option to include locally-attached networks is checked:

Code: [Select]
pass ip any <-> any any (msg: "Pass List Entry - allow all traffic to/from"; sid:1000006;
This rule says when the SRC or DST is an IP address in the subnet, then let it pass with no inspection.  Pass rules in Suricata mean just that -- pass the traffic unconditionally with no further inspection.  And pass rules are the very first rules the Suricata engine evaluates.  So this default pass rule is bad (very bad actually).  Some of the other automatic default passlist rules are more restrictive and specify only a single IP address instead of the whole subnet, but even then it still is generally not a good idea to totally whitelist most hosts.

So unless you are totally convinced you need a Passlist with Inline IPS Mode, go right now and set your PassList entry on the INTERFACE SETTINGS tab to "none", save the change and then restart Suricata.  Choosing "none" turns off the automatic passlist.  In the next Suricata GUI package update, the ability to assign and use a passlist will be removed from Inline IPS Mode operation to prevent users from inadvertently neutering their IPS when running Inline IPS Mode.

What If I Really Need a Passlist with Inline IPS Mode?
If you truly do need to whitelist a specific host for some reason (or perhaps more rarely an entire subnet), then you should probably create your own Custom Rules for this and forget about using a passlist.  Custom rules allow you to be more specific.  For example, you could specify an IP, a flow direction and even a port or port range to limit the traffic that bypasses normal Suricata inspection (remember that a passlist when using Inline IPS Mode means passlist addresses get evaluated by no rules; any host or network on the passlist bypasses all Suricata inspection).  The very first test in the Suricata engine is to check if the SRC or DST addresses, ports and protocol match any PASS rules.  If there is a match, the packet is passed on to the netmap pipe endpoint and bypasses all of the other Suricata rules.

So a rule like this is much more limited than the earlier rule:

Code: [Select]
pass ip 80 <- any any (msg: "Pass List Entry - allow all traffic to/from"; sid:1000006;
This rule only passes traffic where the destination is IP address and the port is 80.  Only traffic matching that specific criteria bypasses further Suricata inspection.

To create custom passlist rules like this, go to the RULES tab for the interface, choose CUSTOM RULES in the Category drop-down and then type in the rules you need.  There are plenty of examples on the web.  You can add restrictions by protocol, port and source or destination IP address.  Just really think about what your rule is allowing when creating it.  It's easy to bypass your Suricata protection with a Passlist!  That's why I intend to remove that capability for Inline IPS Mode operation in the next update.  Folks needing to whitelist a host or network can do so with custom PASS rules instead.

Realistically, about the only application I can imagine for a Passlist is if you are running a honeypot host and you actually want bad stuff to find its way to that host.  In that situation, a passlist makes sense.  For about any other case, it does not.  So get ready to see Pass Lists disappear from Suricata in the next version when using Inline IPS Mode, and get prepared to use custom PASS rules instead if you really need passlist functionality.


IDS/IPS / Re: Suricata Really Annoying, Blocking Everything
« on: March 15, 2018, 03:27:35 pm »
Thanks Bill. Most of my knowledge on this stuff is thanks to you. You laid out the information for the rest of us. Below is the dropsid.conf I'm using to add ET categories. The code uses the syntax with commas. I forget who's list this was based on so I can't give credit. For all I know, this could be based on yours Bill.

Code: [Select]
# This is the full list of ET open rules in case I want to add more of them ==> emerging-activex.rules,emerging-attack_response.rules,emerging-botcc.portgrouped.rules,emerging-botcc.rules,emerging-chat.rules,emerging-ciarmy.rules,emerging-compromised.rules,emerging-current_events.rules,emerging-deleted.rules,emerging-dns.rules,emerging-dos.rules,emerging-drop.rules,emerging-dshield.rules,emerging-exploit.rules,emerging-ftp.rules,emerging-games.rules,emerging-icmp.rules,emerging-icmp_info.rules,emerging-imap.rules,emerging-inappropriate.rules,emerging-info.rules,emerging-malware.rules,emerging-misc.rules,emerging-mobile_malware.rules,emerging-netbios.rules,emerging-p2p.rules,emerging-policy.rules,emerging-pop3.rules,emerging-rbn-malvertisers.rules,emerging-rbn.rules,emerging-rpc.rules,emerging-scada.rules,emerging-scan.rules,emerging-shellcode.rules,emerging-smtp.rules,emerging-snmp.rules,emerging-sql.rules,emerging-telnet.rules,emerging-tftp.rules,emerging-tor.rules,emerging-trojan.rules,emerging-user_agents.rules,emerging-voip.rules,emerging-web_client.rules,emerging-web_server.rules,emerging-web_specific_apps.rules,emerging-worm.rules
# Emerging Threat categories shown below will have all rules changed from "alert" to "drop"

No, that's not a list I created but it is a good one.  There have been several contributions submitted to the forum here by Suricata users.


IDS/IPS / Re: Snort exited on signal 11
« on: March 15, 2018, 03:25:43 pm »
Thanks for the tip, I had missed that I was not running the latest package.  I'm running an Intel CPU:
Intel(R) Xeon(R) CPU E3-1270 v5 @ 3.60GHz
4 CPUs: 1 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (active)

I've installed the latest snort package, hopefully that will take care of it.

A Signal 10 would be very unexpected on an Intel CPU with Snort.  On an Intel platform that may indicate a possibly failing memory chip or other memory component.  Signal 11 is not unheard of, but Signal 10 is rare.


IDS/IPS / Re: Snort exited on signal 11
« on: March 14, 2018, 06:37:19 pm »
Signal 10 is a bus error and usually indicates the program binary attempted some type of unaligned memory access.  What hardware are you running on?  Is it perhaps an ARM CPU?  If so, you most definitely need to update to the latest Snort package.  That package has some fixes for ARM hardware.  From your log post, you are running version, which is not the latest.


IDS/IPS / Re: Suricata Really Annoying, Blocking Everything
« on: March 14, 2018, 06:33:16 pm »
I had similar issues when I first started using the IPS. As other stated, don't enable all categories. mind12's list seems like a good starting point for a dropsid.config file. I could be wrong, but I thought the categories in the dropsid file had to be separated with commas. I found a similar list which I copied from these forums. Also, under the WAN Categories I have the Snort IPS Policy Selection set to Balanced with the IPS Policy Mode set to Policy. Based on my understanding, doing this will set certain snort rules to drop automatically so the snort rules don't have to be specified in a dropsid file if you go that route.

All of the above statements by @Raffi are correct.  The best starting point for a complete newbie to an IDS/IPS is to use the Snort rules and set the CATEGORIES tab to "IPS Policy Connectivity" and the Policy Mode to "Policy".  This will set up a good starter rule set with expert-recommended rules set to DROP and some others set to just ALERT.  Later, if you want to, you can up the Policy to "Balanced" to get a bit more security, but with the possibility of a few false positives now and then.


IDS/IPS / Re: Snort Passlist for Cpanel access
« on: March 11, 2018, 10:39:13 pm »
If you are seeing no alert, then Snort is not likely to be the cause of the "no connection" problem.  Snort won't block without logging a corresponding alert on the ALERTS tab.  Now if you don't have the "Clear Blocked Hosts" interval set to some reasonable value (I recommend one hour), then a block implemented even days ago could still be in place so long as the firewall has not been rebooted.  Rebooting the firewall will always clear all blocks implemented by Snort.

You should be sure the "Clear Blocked Hosts" interval on the GLOBAL SETTINGS tab is set for something sort of short like 1 hour.  You can also manually clear blocks at any time by using the button on the BLOCKED tab.  Again, though, Snort will print an alert for every block it implements.  If blocked hosts are not being cleared on a resonable interval, and you get lots of alerts that cause the alert log to get rotated frequently, then the ALERTS tab may not be showing the older alerts that caused the long-lived block.  That's because the ALERTS tab shows only the alerts from the currently active log.  It does not show older alerts from alert log files that have been rotated.  Some people get a false sense of security by thinking it is a good idea to set the "Clear Blocked Hosts" interval to NEVER.  I disagree with that.  If Snort blocked the traffic once, it will block again later, so why worry about persisting the old block?  If will reset anyway if you ever reboot the firewall.


IDS/IPS / Re: Snort: What POP3 Decoder Setting do?
« on: March 10, 2018, 05:01:46 pm »
No, the POP3 preprocessor most definitely does not communicate with any mail server.  It is simply looking at the commands flowing back and forth between email clients on your network and whatever mail servers they are connecting to (assuming that traffic passes through Snort).  The line you underlined from the Snort manual is simply saying you need to tell the POP3 preprocessor what ports to be looking at within the incoming/outgoing datastream.  It does not imply that Snort is talking to the mail server, though.  Telling the POP3 decoder what port is in use lets it filter the traffic and only inspect data coming or going from the active POP3 port.

You define the POP3 ports on the VARIABLES tab for the interface in Snort.  There are settings on that page for servers and ports.  Leaving boxes blank will use the default values which are shown in the help text under each box.


Thank you Bill for the detail explanation. Well, one cannot just add the has to create an alias; so, I created two firewall aliases, inmail and outmail and added firewall...see pic. Then, I added the aliases to Snort's variables tab > SMTP >outmail and POP3 >inmail. But, I cannot send or receive mails...should I have added anything in the server section? I got this Snort alert and have since changed the source port. Had to hide destination IP for privacy on Snort alert pic. Outmail port is 465 and inmail port is 995.

Port 995 is typically for POP3S (encrypted POP3), so Snort is going to have trouble seeing everything correctly on that port.  That rule is a "false positive" in your case because it is looking at an SSL encrypted datastream, so the byte patterns are not going to match the "standards" that Snort would see on a port 110 plain-text POP3 connection.  That's why the rule is triggering.

So short answer is just disable that rule as it is going to fire on you a bunch and means nothing on an encrypted session.


IDS/IPS / Re: Suricata Inline dropping some HTTPS
« on: March 09, 2018, 08:42:43 pm »

No problem. The documentation for 1:1 comparison of snort.conf to suricata.yaml ( says it is always automatically at "full snaplen" for suricata but I think this only applies to Inline or if no MTU is detected using ioctl for pcap mode. This is where I got started looking at how it gets it and found out it adds 16 to the interface MTU. Basically it looks for the MTU of the interface and, if it cannot find one using ioctl, it automatically sets to 1518 or "full length" which would work. That being said, it CAN find the MTU of 1500 on most interfaces and so defaults to 1500+16. I see where they added the ability for you to configure it in pcap mode here:

As a side note, Snort should probably be defaulted to 1518 snaplen regardless in pfsense to mitigate any issues with VLAN users on the snort side (won't hurt anything but will definitely help. It will just make sure it works properly and, if they aren't using any VLANs, will just use slightly more resources but should be a negligible amount). You could then also make it configurable in the GUI in case someone has different needs or needs to adjust it (jumbo frames scenarios, etc.) as you mentioned.

On the suricata side, maybe the GUI should only give you the option to set snaplen for pcap mode and hide it otherwise with a note about the MTU and VLANs because I don't see it anywhere being able to do it in the suricata.yaml for Inline mode either and it might confuse those who don't know it won't work in that mode.

Here is a discussion from when security onion distro was talking about the issue and they describe it pretty well. In the end, if you look at github, they decided to go ahead and make it the default about 2 years ago to resolve this issue. You probably can't do what they did and force all interfaces to use MTU 1502 when switching suricata to inline mode but a warning in the GUI would probably suffice.!topic/security-onion/94s7beFDMU0

Thanks for always being so responsive on the forums.

We are on the same page ...  :D.  I found those same links in my quick searching.  Good tip about hiding the SNAPLEN setting when using Inline IPS Mode in Suricata.  I will also add the parameter to Snort as well.  It defaults to using the MTU when snap length is not specified.  I'm working on some common updates to both packages (Snort and Suricata).


IDS/IPS / Re: Snort: What POP3 Decoder Setting do?
« on: March 09, 2018, 08:02:45 pm »
No, the POP3 preprocessor most definitely does not communicate with any mail server.  It is simply looking at the commands flowing back and forth between email clients on your network and whatever mail servers they are connecting to (assuming that traffic passes through Snort).  The line you underlined from the Snort manual is simply saying you need to tell the POP3 preprocessor what ports to be looking at within the incoming/outgoing datastream.  It does not imply that Snort is talking to the mail server, though.  Telling the POP3 decoder what port is in use lets it filter the traffic and only inspect data coming or going from the active POP3 port.

You define the POP3 ports on the VARIABLES tab for the interface in Snort.  There are settings on that page for servers and ports.  Leaving boxes blank will use the default values which are shown in the help text under each box.


IDS/IPS / Re: I need opinion if I really need Suricata
« on: March 09, 2018, 07:56:59 pm »
Your hardware is capable of running Suricata or Snort for a home network application.

Whether you need it or not is really up to you.  One of the things to consider is what type of risk is your network exposed to via the VPN.  What I mean by that is if you simply access mainline streaming services like Roku and AppleTV and avoid other more "wild and wooly" sites, then you don't need an IDS/IPS package.  If you have guests with laptops, or other household members that might visit more risky sites (such as torrent hosting sites, some gamer sites, etc.), then an IDS/IPS like Suricata or Snort can help protect users from themselves by blocking some known exploits.

Just be aware that it is NOT as simple as just installing the Suricata or Snort package and turning on blocking.  Doing it that way will most certainly result in lots of spurious blocks from false positives.  You have to understand the rules and enable only the ones that are appropriate for your network usage.  There are examples of good setups in the threads of this IDS/IPS sub-forum.  Just search through using the search tool on the forum.


IDS/IPS / Re: Suricata Inline dropping some HTTPS
« on: March 09, 2018, 07:49:12 pm »
@onyxfire, thank you for the heads-up about the snaplen parameter and its impact on VLAN traffic detection.  It is in fact a configurable parameter for Legacy Mode (the mode that uses PCAP), so I will add a GUI item for setting that in the next Suricata update that I am working on.  That will let the user configure their own custom Snap Length for situations involving VLAN-tagged traffic on an interface using Legacy Mode blocking.

I don't currently see a similar configuration item for the Netmap mode used for Inline IPS in the Suricata documentation or source code.


IDS/IPS / Re: Suricata Inline dropping some HTTPS
« on: March 08, 2018, 03:15:01 pm »
If you look on the ALERTS tab do you see any entries in red text?  Those would indicate DROPPED connections which is the way blocks work with Inline IPS mode.  The BLOCKS tab is only relevant when using Legacy Mode blocking.  If HTTPS Google is indeed getting dropped, then you should be seeing red text lines on the ALERTS tab showing what rule triggered.


Pages: [1] 2 3 4 5 ... 222