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 ... 223
Packages / Re: What is Snort Blocking Right Now?
« on: Today at 02:32:20 pm »
Maybe I'm using the wrong terminology. What I mean by 'being blocked this instant' is when her apps tries to run, its trying to connect to an IP address and Snort is blocking it. I don't know what that IP address as the App doesn't list what servers it connects to. I don't know what IP Address Snort is blocking the response from because there is nothing in Snort, or the Diagnostics tab that shows remote IP addresses that are sending (or trying to send) packets to my router. Even on the Status/Traffic Graphs tab, none of the IP addresses popping up on the WAN adapter match anything in the Snort Blocked sites list - all done while I'm using her app and watching it fail.
So its all smoke and mirrors to me.
There is apparently no tool or function to list all incoming packet's source IP address (blocked or not). Personally, I don't understand this (maybe I'm being naive and stupid). I don't get why a enterprise level router, like pfSense, doesn't have this ability. 
If the Alerts in Snort don't show an Alert of incoming traffic that is being being blocked, only random old data, then what use is it?
None of the Snort alerts correspond to any of the times I tried her app and watched it fail.
So, how do I know Snort is blocking her app? I KILLED all the Snort block and magically her app started working least until Snort starts blocking it again because at some point it will do something Snort doesn't like, again.
What is the app doing that Snort doesn't like? I have no fracken clue.
What IP address is Snort blocking? I have no facken clue.
IMO, is Snort user friendly? Heck No
It's a black box.

The IP that Snort blocked will be shown in two places.  One is on the ALERTS tab and the other is on the BLOCKS tab.  They are as plain as day to see there if you go look.  Both tabs show you the blocked address, and the ALERTS tab shows you both the source and destination IP addresses (if you are running Snort on the LAN interface as I recommend).  If you are running Snort on the WAN, then the only local IP address you will see is your WAN IP.

Snort and Suricata are not like an anti-virus client.  You can't just install the package, download all the rules and call it done.  Both packages are designed for security admins with training on IDS/IPS operation, rule selection and tuning.  If you don't want to take the time to do all the research to learn how to do these things, running either of those packages is not going to be fun for you.  You are going to get lots of blocks from false positives.  These packages are really not intended for use on home networks unless your day job is an IDS/IPS admin.


IDS/IPS / Re: Suricata Blocking WAN IP Address
« on: Yesterday at 08:18:44 pm »
Follow up test results --

I configured a test scenario in a VMware lab environment to test if the automatic Pass List feature that prevents blocking the WAN IP address of the firewall works.  I could not reproduce your issue of blocking the WAN IP.  I had a pfSense firewall running Suricata configured for Legacy Mode blocking with no passlist defined (meaning there was no automatic pass list being generated).  Suricata was configured to block BOTH alert IP addresses (SRC and DST).

I then scanned the WAN IP of this virtual machine from a Kali Linux host in the same subnet as the WAN IP.  I got immediate blocks on the IP address of the Kali Linux host, but no blocks on the WAN IP of the firewall being scanned.  There were no blocks on the firewall being scanned because the automatic WAN IP pass list feature of Suricata prevented it.

So Suricata will not block your currently active WAN IP (at least when used in the default configuration).  If it would allow the WAN IP to be blocked, then my test would have resulted in an immediate block of both the Kali Linux box IP and the WAN IP of my test firewall victim.  I only got blocks on the Kali Linux host's IP address.


IDS/IPS / Re: Suricata Blocking WAN IP Address
« on: Yesterday at 07:45:44 pm »
What was the time stamp on those log entries?  How does the time stamp on those entries match up with the time of the alert and block?  Does your WAN IP address change frequently?

As a side note, that set of rules has very limited usefullness on a Home Internet connection.  In your case it is almost certainly a false positive.  Unless you are running a public NTP server, then you don't need that rule at all.


What you want to do is not currently possible with either Suricata or Snort on pfSense.  The firewall and the IDS/IPS do not cooperate with other at that level.


IDS/IPS / Re: Suricata Inline dropping some HTTPS
« on: Yesterday at 07:34:05 pm »

*@bmeeks, unchecking the Block Offenders checkbox if inline mode was previously selected, results in [ERRCODE: SC_ERR_INITIALIZATION(45)] - No interface found in config for netmap, I had to switch back to legacy mode then uncheck the box.

Thanks for the heads up on that issue.  I'm working on a Suricata GUI package update now, so I will test this out and fix any logic issues.  What it should do, when selecting no blocking, is switch over to PCAP mode and not use Netmap.  Your error indicates the code may not be doing what I intended.


IDS/IPS / Re: Suricata Really Annoying, Blocking Everything
« on: Yesterday at 07:30:33 pm »
In that case, you don't really need a dropsid.conf file. The dropsid is mainly needed for inline mode, at least that's the only reason I'm using it. Legacy mode is a matter of enabling categories from the WAN categories list. In legacy mode, an alert will automatically block/drop that traffic anyway so there is no need to specify which traffic should be dropped in a dropsid file.

Well... the new 4.x Suricata versions do have a feature for Legacy Mode users that mimics IPS Inline Mode in terms of DROPS versus ALERTS.  There is an option on the INTERFACE SETTINGS tab, when you enable Legacy Mode blocking, to only block traffic for DROP rules.  So if you enable that, then you do need to set rules to DROP using a dropsid.conf file.  This option is off by default, but can be enabled if desired.  With the option enabled, then Legacy Mode behaves more like IPS Mode where you can have alerts that don't block, but drops that do block.


Packages / Re: What is Snort Blocking Right Now?
« on: Yesterday at 07:26:09 pm »
Thanks. But I already know about the block tab. I don't want to remove all of them.
My question was how can I see which is address is being blocked this instant. Then I can unblock just that one... because I don't know which one is required for her app to run properly.
Plus, if I just unblock all of them, instead of whitelisting just the one, then it'll just get blocked again.

With Snort there is no such thing as "... address being blocked this instant.".  All of the IP addresses shown are being blocked continuously until they are removed.  If you want to see the most recent one, then look on the ALERTS tab.  Alerts are shown with most recent first.

I don't mean to sound rude or condescending, but from your explanation of your problem I don't think you are ready to use Snort in blocking mode yet.  You need to run it in IDS, or non-blocking mode, for several weeks and study the various alerts you receive.  You can use Google searches to help you decide which alerts are potential false-positives for your environment.  That will help you tune your rule set properly.  One you understand how your rule set interacts with your network environment and have suppressed rules prone to false positive on your network, then you can enable blocking mode.


IDS/IPS / Re: Suricata Really Annoying, Blocking Everything
« on: March 16, 2018, 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: March 16, 2018, 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.


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