IDS/IPS

• B

  Configuring pfSense/netmap for Suricata Inline IPS mode on em/igb interfaces
  • boobletins

  1
  4
  Votes
  1
  Posts
  664
  Views

  No one has replied

• 

  Quick Snort Setup Instructions for New Users
  • bmeeks

  147
  1
  Votes
  147
  Posts
  191967
  Views

  

  @qinn, it depends totally on which precise rules are enabled and what the traffic on your network actually consists of. The goal in IDS/IPS is to get no or very few alerts and blocks. That means your network is relatively secure and clients are following the rules ... . I don't mean that to say you should never get alerts, though. Just that you don't want to be receiving hundreds per hour. Once blocking is enabled that might drive you crazy as an admin. Within the IPS Polices, the Snort team has selected rules that provide security without a ton of false positive alerts.
• 

  How Automatic SID Management and User Rule Overrides Work in Snort and Suricata
  • bmeeks

  4
  2
  Votes
  4
  Posts
  2558
  Views

  

  @cyberzeus said in How Automatic SID Management and User Rule Overrides Work in Snort and Suricata: bmeeks - I found the following link that describes what is included in each of the 3 IPS policies.  Note there is a 4th policy - MaxDetect.  Do you know if there are any plans to implement this in the Snort package for pfSense? https://www.snort.org/documents/215 Replying to an old thread, but the answer is "yes". The new MaxDetect policy is now present and selectable in the Snort and Suricata packages. Just remember that the Snort folks recommend enabling that only for testing purposes! It is most definitely not recommended for a production network. It will generate a lot of false positives!
• 

  About Pass Lists in Suricata
  • bmeeks

  3
  0
  Votes
  3
  Posts
  3851
  Views

  

  @dcol: Great post, thanks. Using Inline Suricata 4.0.0_1. Works Great Can you, or someone, please post an example of a pass rule that would always pass an IP in Inline mode. I want to use it for my remote IP when I make changes to rules so I do not inadvertently block myself. How about this example? pass tcp 1.2.3.4 any -> any any (msg:"pass all traffic from/to 1.2.3.4"; sid:100000;) Would this rule allow IP 1.2.3.4 to not ever be dropped by Suricata using Inline mode? Yes, this would let traffic pass without blocking whenever the SOURCE IP was 1.2.3.4.  It would not prevent a block from happening if the IP 1.2.3.4 was the DESTINATION IP.  If you want to prevent IP 1.2.3.4 from getting blocked no matter the flow direction, use this rule instead: pass ip 1.2.3.4 any <> any any (msg:"pass all traffic from/to 1.2.3.4"; sid:100000;) Notice the direction symbol is "<>" which stands for "any" as opposed to "->" which signifies a specific direction (from 1.2.3.4 to any other IP).  So the version I posted using "<>" would mimic the old Legacy Mode Pass List operation whereby IP address 1.2.3.4 would never get blocked.
• 

  Important Info About Passlists with Suricata Inline IPS Mode
  • bmeeks

  2
  0
  Votes
  2
  Posts
  1033
  Views

  T

  For those looking to create their own rules, the "sid:1000006;" part of the example is NOT a reference to an existing SID. It needs to be a unique number otherwise Suricata won't load the rule. To whitelist for a rule for an IP, search for the SID in /usr/local/etc/suricata/suricata_(interface)/rules/suricata.rules. Duplicate the conditions like "flow:from_server,established; content:"403"; http_stat_code;" into the custom rule so it matches, like pass ip 192.168.1.22/32 80 <- any any (msg: "Pass List Entry - allow all traffic to/from 192.168.1.22/32"; flow:from_server,established; content:"403"; http_stat_code;sid:1000006;) Otherwise with only the IP address, port, and unique SID it will allow all traffic for that IP. Also note the directional (<-) only allows for two directions..."both" or "left."
• 

  About the New Block-on-Drops Only Option in Suricata 4.0.0
  • bmeeks

  12
  0
  Votes
  12
  Posts
  3122
  Views

  

  @JasonAU: You put a lot of effort into this forum & Pfsense thank you! Seriously a lot of people would be lost without somebody doing the answering on the forum I’m having a lot of fun toying with this after work in my lab the only thing that I don’t currently understand is can I make some rules drop rather than block when I’m configured with: *Legacy mode not inline *Block on DROP only enabled *IPS Policy Security with ‘policy’ mode Snort Subscriber + ET Let’s say I like one of the rules FILE tracking GIF (1x1 pixel) from the files.rules category sounds like a good thing to help with privacy but the blocking action causes problems as often the IP that gets blocked is hosting other legitimate images in the page, Can I use SID Management to modify this rule to drop even when I have block on drop enabled? Your question leads me to believe you are misunderstanding a key piece of the puzzle.  There is no difference between DROP and BLOCK in Legacy Mode.  They are the same thing.  Both lead to the exact same result:  traffic from the offending IP address (the one that triggered the rule) is blocked by placing the SRC, DST or BOTH IP addresses from the offending packet into the snort2c pf firewall table.  After that, all further traffic from those IP addresses is blocked until the IP addresses are removed from the snort2c table.  Legacy Mode can't do what you want. The whole reason I created the new "Block-on-drops-only" option was so you can tailor rules actions to get the results you desire.  See, all rules by default from the rule set vendors come with the action set to ALERT.  With Legacy Mode Blocking, and before the new "Block-on-drops-only" option was added, any alert also generated a corresponding block.  It was an all or nothing arrangement.  When you enabled blocking, any rule that generated an alert would also cause a block.  With the new "Block-on-drops-only" option, I added some extra intelligence within the custom blocking module so that it could look at the rule action (ALERT or DROP) of the triggered rule and take the action specified.  So if the rule says ALERT, then only an alert is generated but no block is created.  If the rule says DROP, then both an alert and a block are generated. SID MGMT has options that allow you alter rule actions from the default value of ALERT.  So now you can pick and choose which rules you want to just alert and which you want to drop (or block traffic).  This new "Block-on-drops-only" option was born out of the way the Inline IPS mode operates.  With Inline IPS Mode, you must specifically change rule actions to DROP in order to drop or block traffic.  You could also leave some rules with the default ALERT action and those rules would generate alerts but would not block or drop traffic.  That's the way most commercial proprietary Intrusion Prevention Systems operate.  So I thought it would be useful to port that same functionality (the choice of ALERT or DROP) over to Legacy Mode operation.  Hence the new "Block-on-drops-only" option. I still don't won't folks to confuse Legacy Mode's use of DROP with the way IPS Mode works, though.  In Legacy Mode, even though I'm using the term "drop", the actual blocking of traffic is done the old way using libpcap to get copies of every packet traversing the interface, and when a rule fires to create a block, the IP addresses from the offending packet are copied to the snort2c table in pf to implement a firewall block.  So when I say "drop" in the context of Legacy Mode and the new "Block-on-drops-only" option, I really mean that only rules with DROP as the action will add the offender's IP address to the snort2c table.  The "drop" is really still the old fashioned block.  With Inline IPS Mode, the snort2c table is not used at all.  There is another Sticky Post here on the forum that describes the difference between Legacy Mode and Inline IPS Mode. Read both of the Sticky Posts in this forum about Passlists and Suricata.  Each of them also contains some key points about blocks, drops and Legacy vs Inline IPS modes. Bill
• 

  Using Snort VRT Rules With Suricata and Keeping Them Updated
  • bmeeks

  6
  1
  Votes
  6
  Posts
  9852
  Views

  B

  @osrron said in Using Snort VRT Rules With Suricata and Keeping Them Updated: Question for you Bill. Can Suricata use the Snort 3.0 rules? Thanks in advance. Thank you for all of you hard work on these packages. In case someone else stumbles on this pinned post. You can enable Snort3 rules with Suricata and it may seem like they are enabled, but a look at the logs will reveal that almost none of the Snort3 rules are valid for Suricata: With Snort3 (+ET) rules file: 3/12/2018 -- 18:54:14 - <Info> -- 2 rule files processed. 16107 rules successfully loaded, 12873 rules failed With Snort2 (+ET) rules file: 3/12/2018 -- 18:59:44 - <Info> -- 2 rule files processed. 26848 rules successfully loaded, 2132 rules failed With just ET Suricata rules: 3/12/2018 -- 19:01:22 - <Info> -- 2 rule files processed. 16087 rules successfully loaded, 2077 rules failed Most of the failures come from ET's Suricata rules. Most of the failures are a result of missing references (eg "md5") which are in the ET rules but not in the reference files after processing by pfSense's Suricata package.
• M

  Suricata restart after failure
  • mind12

  7
  0
  Votes
  7
  Posts
  81
  Views

  M

  Let's see. I will post the logs here if it crashes again. Thank you.
• H

  Snort - Whitelist IP from specific rules?
  • Hossius

  8
  0
  Votes
  8
  Posts
  40
  Views

  

  You also have multiple options for using a Suppress List entry. You can suppress a rule entirely for all IP addresses, or you can selectively suppress the rule based on either SOURCE or DESTINATION IP address in the packet. Hover over the little plus sign (+) icons by each alert on the ALERTS tab to see the options (they will appear in a tooltip pop-up).
• S

  Inline IPS to block students from using VPN in educational subnet
  • swmspam

  4
  0
  Votes
  4
  Posts
  63
  Views

  

  You can obtain packet captures of the VPN traffic and then write your own OpenAppID rules to detect it. You should be able to learn what you need to do via Google searches and by using some of the existing VPN detection rules as a starting point. And no, I don't know the exact rule you need to detect this or if it is possible given they use ports such as 443. This means the VPN client creators purposefully created a client that is difficult/hard to detect. Why not install some of the same client software on a machine you own and use packet captures to see what IP addresses it favors and what the protocols look like? That would give you insight to write your own detection rules.
• A

  Finding internal IP causing block
  • andrewhancock91

  12
  0
  Votes
  12
  Posts
  140
  Views

  N

  Bingo pcap udp any any -> any 53 ( msg:"ns.hetsptt.net.cn"; flow:to_server; byte_test:1,!&,0xF8,2; \ content: "|02|ns|07|hetsptt|03|net|02|cn|00|"; nocase; sid:20000010; rev:001;classtype:string-detect; ) https://www.securityartwork.es/2013/02/21/snort-byte_test-for-dummies-2/
• K

  Snort too old for the latest rule sets, fails to run
  • KimmoJ

  1
  0
  Votes
  1
  Posts
  33
  Views

  No one has replied

• I

  disabled and suppressed alerts to not show in the log tab view
  • itsupport1212121

  6
  0
  Votes
  6
  Posts
  111
  Views

  

  @itsupport1212121 I don't currently have an open Suricata session in front of me, but from memory the settings let you select a maximum size for the packet log in megabytes and a limit on the number of captured packets. So the actual disk consumption is determined by the size of each packet (typically 1500 bytes) and how many packets you save. The log size limit is like an override that prevents the log from growing too large. All log data lives in /var/log/suricata and then in a sub-directory underneath for each configured interface. The sub-directory will be named with the physical interface name combined with a random GUID.
• Z

  WAN interface keeps dropping out of snort
  • Zermus

  6
  0
  Votes
  6
  Posts
  83
  Views

  

  @zermus said in WAN interface keeps dropping out of snort: Years of using pfSense I would normally tend to agree with you, but that's the case. Under Snort Interfaces, if I use a heavy ruleset, it just somehow deletes itself out. There is no HA/Sync in this setup, it's a standalone box. The interface doesn't PHYSICALLY DISAPPEAR of course (I'm literally imagining a ghost going in and stealing my Intel NIC out of the box here), but it's dropping out of Snort Interfaces, exactly like someone goes in and deletes the WAN interface from Snort where I have to re-set it all back up again. The only correlation I can find is using a heavy rulset, which in the past was never a problem up until recently. I'm not sure how recent because I just noticed my WAN interface was missing about a week ago when I normally never had a need to go in there and check it. I'm not sure how it would resort to a previous config, because when I set this box up about 2 years ago, setting up Snort on the WAN/LAN was one of the first things I did. I'm not disputing what you are seeing, but I see absolutely no failure mechanism of any kind within the GUI PHP code that could result in a Snort interface being deleted. Deleting an interface requires a manual action. Go to DIAGNOSTICS > BACKUP AND RESTORE in the pfSense menu and then click the Config History tab. Examine the history closely to see what you find. When Snort deletes an interface via user action, it logs a message in the config history. The only part of the PHP GUI code that can delete an interface resides within the INTERFACE SETTINGS tab, and that code will always log a config history message as well as log a message in the pfSense system log when it removes an interface.
• 

  Snort Blocking Host No Matter What
  • davetheriault

  4
  0
  Votes
  4
  Posts
  90
  Views

  

  @davetheriault said in Snort Blocking Host No Matter What: Ya. I've tried 'removing' the individual entry in Blocked Hosts. And I have also tried the 'Clear - All blocked hosts will be removed' option each time I try to fix the issue. After I clear it from the Blocked Hosts table, I am able to visit the host with one successful page load, but it immediately get's re-added to the Blocked Hosts table by snort, and I can't continue or reload the page from that host, no matter what rules I have suppressed or pass lists I have created. I know of only two ways what you describe can physically happen. You are disabling the wrong rule (i.e., you are not disabling the rule that is actually firing) or else multiple rules are firing and you still haven't found them all; There is another duplicate Snort process running on the interface that is not responding to your rule changes. That can happen in rare circumstances. To see, run this command from a shell prompt on the firewall: ps -ax |grep snort You should see only a single Snort process listed for each configured interface. If you see more than one per interface, stop Snort in the GUI and then kill any remaining Snort processes from the command line shell. As for the Pass List "Snort_Pass_List" shown in your screen capture, do you have that list assigned to the Snort interface on the INTERFACE SETTINGS tab? There is a drop-down selector on that tab where you select the Pass List you want to use for the interface. Make sure "Snort_Pass_List" is selected, save the change, and then restart Snort on the interface. Using a custom Pass List is a two step process: (1) first create the list; and then (2) go to the INTERFACES SETTINGS tab and assign the list to the desired Snort interface.
• V

  Adding Suricata custom rules from external tools
  rules suricata dfir misp the hive • • vlabmichl

  2
  0
  Votes
  2
  Posts
  73
  Views

  

  The Suricata GUI package on pfSense is designed to make the deployment of an IDS/IPS somewhat simpler for users new to such technology. If you are at an advanced level where you want to integrate with multiple other systems and construct on-the-fly rules using script tools, then you really should abandon the GUI part of the package and simply use the Suricata binary itself. You can do that by simply installing Suricata from FreeBSD ports. You are going to have to install all of the other scripting language dependencies from there anyway. I am not in favor of loading up the Suricata package with a ton of new dependencies when the vast majority of users would likely not need them for a basic IDS/IPS. I'm talking about things like Python, Go, (and heaven forbid one old suggestion even needed Java! Can you imagine the security holes your firewall would have with Java installed on it?). There is a Github site for all of the pfSense packages here. You are free to submit pull requests there. I usally am asked for my opinion, but the pfSense developers have final say in what is accepted into the package.
• L

  Numerous ET SCAN Potential SSH Scan OUTBOUND alerts. Is Pfsense infected?
  • lambro690

  24
  0
  Votes
  24
  Posts
  831
  Views

  S

  I'm having same issue with ntop .. .. seems to try ip's like 0.106.219.157... installed, reinstalled several times. ... anyone might know what is the issue?
• 

  Snort blocked hosts
  • chudak

  8
  0
  Votes
  8
  Posts
  182
  Views

  

  @chudak said in Snort blocked hosts: @bmeeks You sound fine no worries And I’m actually not disagreeing on this point Need to digest, but then to be consistent with this - why do we allow Remove Blocked Hosts Interval option? What do we need it for ? Snort blocks hosts for say 1 hour and automatically removes it and then if needed blocks again. How does that sound ? PS: I’m not advocating for this change, just underlining the point. Because Snort hands off the actual blocking to the firewall packet filter, there needs to be an option to clean up blocked IPs after some period of time. Snort can't just "drop" packets like Suricata Inline Mode can. Think of a Snort block as a temporary firewall rule that is put in place. That rule needs to expire after some interval. Generally something like 15, 30 or 60 minutes is a reasonable expiration time. That is long enough to discourage port scanners and bot scripts that are say knocking on a bunch of port doors looking for a way in. It's true that Snort could hand the IP to the snort2c table and then clear it again almost immediately, but that would take a lot of extra processing on the part of Snort. Instead, Snort creates a cron task that uses the interval selected by the Clear Blocked Hosts setting. That cron task runs the pfctl utility to scan the snort2c table and remove any IP addresses that have not seen activity within the interval set by the Clear Blocked Hosts setting. So if the interval is set for 30 minutes, then only IP addresses that have not been seen in any traffic for the last 30 minutes will be cleared from the table.
• C

  HA PROXY + Inline Snort -> Blocks HAPROXY IP
  • crester

  9
  0
  Votes
  9
  Posts
  702
  Views

  T

  Just to finish off this thread - the workaround by adding the server ip to the interface passlist works in the sense that the server ip is no longer getting blocked. The downside of course is, that this server is now completely without protection from Snort.
• M

  Suricata port enabling
  • markchen

  10
  0
  Votes
  10
  Posts
  211
  Views

  M

  @bmeeks I removed some rules and so far the process is staying on. Thank you very much for your input.
• T

  Snort 3
  • talaverde

  27
  0
  Votes
  27
  Posts
  975
  Views

  

  @siil-it said in Snort 3: What are we likely to get as a replacement for barnyard2? I manage a growing number of various models of Netgate devices, all with Snort installed. To attempt to monitor them all from one screen i'm trying to use an external SIEM setup. This has proved problematical to say the least. Probably something like this blog post talks about. Except instead of Logstash something like Filebeats might work better on a FreeBSD platform like pfSense. I have not investigated any of that in much detail, though. Here is a tutorial on converting from Logstash Forwarder to Filebeats (or Beats in FreeBSD): https://www.elastic.co/guide/en/beats/filebeat/current/migrating-from-logstash-forwarder.html.
• 

  Suricata SID Management ruleset enable: Enables the default disabled rules
  • asv345h

  3
  0
  Votes
  3
  Posts
  79
  Views

  

  Not a huge deal, more of an annoyance. Thank's for confirming.
• J

  Suricata send logs via syslog in the wrong format
  • joel.costamagna

  1
  0
  Votes
  1
  Posts
  43
  Views

  No one has replied

• T

  NOOB - Why IPv6 Alerts?
  • talaverde

  3
  0
  Votes
  3
  Posts
  113
  Views

  

  Snort puts the interface it is running on in promiscuous mode, thus all traffic types and subnets hitting the wire are seen by Snort. That does not mean any corresponding plumbing exists on the network stack to handle the traffic. So IPv6 packets are hitting your physical wire interface from some endpoint device someplace, but that does not mean your firewall will respond to it in any manner. Snort will see the traffic and alert on it, though, because of the promiscuous mode setting.
• X

  Suricata 4.1.2_3 update broke ruleset?
  • xtal

  5
  0
  Votes
  5
  Posts
  182
  Views

  X

  Great. Back up and running now. Thanks!
• H

  Snort ignoring pass lists
  • harmisist

  5
  0
  Votes
  5
  Posts
  139
  Views

  

  @harmisist said in Snort ignoring pass lists: I fixed the pass list on both interfaces. I do have several incoming services, so I need both. When I set Snort up several months ago I followed this KB article which shows them adding the pass list to the external interface. It seems to be working now, thanks for the reply. That should fix it for you, but DO NOT confuse the EXTERNAL_NET variable with the physical external interface (WAN, in your case). They are not the same thing at all. While it is true that most of the !HOME_NET addresses will come into your network via the WAN, that does not mean when you see EXTERNAL_NET to think that only applies to your physical WAN. Go read some of those Google tutorials I mentioned in my first post and learn what those two variables really mean within Snort. I don't mean to sound rude or patronizing with this statement, but your first action that caused your initial issue, and then your second reply to my post about the solution, leads me to believe you do not understand how Snort should be configured yet. Reading some of those tutorials will help you grasp the key concepts.
• T

  Snort enable_react problem
  • TheoWolf

  4
  0
  Votes
  4
  Posts
  129
  Views

  

  @theowolf said in Snort enable_react problem: okay thanks for checking! Best, Theo And to elaborate a bit more ... DAQ's netmap mode in Snort today requires that you dedicate two physical NIC interfaces to the connection: one as input and the other as output. The netmap module in DAQ then bridges those two physical interfaces, but with Snort sitting between the two operating in Inline IPS mode. So Snort then can either pass on, or drop, packets destined for the other interface. The main issue that makes this unattractive on a UTM-type firewall such as pfSense is the requirement of using two physical interfaces. So a typical minimal firewall would need four physical NIC interfaces: LAN, WAN and then another pair for the Snort-DAQ netmap bridge pair. That's a little wasteful of physical NICs in most situations. What I am looking into is patching DAQ's netmap module so that it can use the special "host stack" connection provided by native netmap on FreeBSD and other operating systems. This requires changes to DAQ's netmap module source code. If I can get this to work, then Snort Inline IPS mode can be configured the same as Suricata is done today on pfSense. That mode creates a pipe between the physical NIC interface and the host network stack, so the IPS can exist on the same interface as the LAN or WAN.
• V

  Snort ignoring passlist
  • veehexx

  4
  0
  Votes
  4
  Posts
  157
  Views

  

  @veehexx said in Snort ignoring passlist: Hopefully that's the fix... didn't have it defined in the 'pass list' dropdown from Snort interface > Wan Settings > 'Choose the Networks Snort Should Inspect and Whitelist' section. That shoud fix it. A Pass List is not automatically assigned when created because Snort does not know which interface to use it on (in the case of multiple interfaces). To keep the code simple, it just assumes there may be more than one interface in use and waits for the user to assign a given Pass List to an interface. There is a default Pass List that is used until a custom one is assigned. That default list includes the DNS server IP addresses, the WAN IP, locally-attached networks, VPNs and virtual IPs. The default list works most of the time, especially for home users.
• T

  Single User -OpenAPPI Rules
  • talaverde

  2
  0
  Votes
  2
  Posts
  88
  Views

  

  See my reply to you similar question here. To repeat the answer from there, "no, there is really no need to use the OpenAppID rules in a home network". As you surmised, those rules are primarily aimed at identifying various traffic types and are not designed to detect and stop malicious software. Mostly they are to help IT Security admins enforce corporate computing policies such as no or limited access to social media during work hours and other similar policies.
• N

  Suricata inline causing interface restart
  • nikb

  3
  0
  Votes
  3
  Posts
  143
  Views

  N

  I've tried most of that thread, but no luck. Looks like CPU just can't keep up. Thanks for the suggestions!
• 

  Suricata v4.1.2_1 -- Package Update Release Notes
  • bmeeks

  7
  2
  Votes
  7
  Posts
  425
  Views

  S

  @bmeeks Thanks. I have an old customer connection that still uses PPPoE which will hopefully be gone soon. I disabled the rules, and it is no longer flooding my syslog server. Everything else seems to be working as it should.
• 

  Suricata 4.1.2_2 Bug Fix Update -- Release Notes
  • bmeeks

  30
  0
  Votes
  30
  Posts
  596
  Views

  N

  Thanks for the info Bill. I appreciate your help and guidance.
• K

  Suricata fails to start after pfSense reboot
  • kiekar

  18
  0
  Votes
  18
  Posts
  303
  Views

  K

  @bmeeks said in Suricata fails to start after pfSense reboot: @kiekar Start with these two Sticky Posts here in the IDS/IPS sub-forum. How Automatic SID Management and User Rule Overrides Work in Snort and Suricata About the New Block-on-Drops-Only Option in Suricata To get some examples of SID MGMT, go to the SID MGMT tab and click the "enable" checkbox. That will populate the page with content. Open any of the example files and you will find comments inside each that explain the options. The internal syntax is copied from PulledPork, so you can Google the PulledPork utility used with Snort to get some examples of what you can do with the enablesid.conf, disablesid.conf and dropsid.conf files. Great, thanks so much. You've been a great help
• S

  Suricata Not logging signature matches | | Suricata 4.0.13_11 with pfsense 2.4.4-RELEASE-p1 (arm)
  • s0m3f00l

  14
  0
  Votes
  14
  Posts
  379
  Views

  

  @s0m3f00l said in Suricata Not logging signature matches | | Suricata 4.0.13_11 with pfsense 2.4.4-RELEASE-p1 (arm): @bmeeks , It appears to have worked. After deleting the package from the GUI "/usr/local/etc/suricata" was left behind. I removed the directory and its contents and then everything reinstalled correctly without intervention. I will wait for the next update and test again. @bmeeks, thanks for putting up with me sir. You are extraordinarily helpful and supremely knowledgeable about suricata and snort on PFSENSE, and the community would be lost without your input. Thanks, again. Glad you got it working. There was likely a file that had been modified and contained "bad content" being left there. When pkg removes software, it compares the md5 hash of the file being removed to the hash the file had when installed. If different, pkg assumes the user modified the file so it leaves it alone. So simply removing and re-installing the package was not removing that modified file. Manually removing the directory and file gets rid of the malformed file. My guess is that it was a different version of the references.config file that was being left behind. That file then would get used with the next installation, so the problem persisted for you.
• J

  describe alerts snort pfsense in wan interface
  • Joseph Watever J

  2
  0
  Votes
  2
  Posts
  87
  Views

  

  The alert simply describes a condition where a potential buffer overflow was observed. This could be a false positive or it could represent an actual attempt at compromise. To figure out which it was, start by doing research on Google about the rule that fired. Use the GID and SID to narrow the search. The GID is 124 and the SID is 3. GID 124 is the SMTP preprocessor. More than likely it is a false positive. If you get one or two now and then, I would chalk it up to false positives. If you get several in a row, or get them quite often, I might investigate further.
• D

  SID Management not working, rules not loading/parsed 2.4.4-2 / Suricata 4.1.2_1
  • digdug3

  7
  0
  Votes
  7
  Posts
  147
  Views

  

  The permanent fix for this issue was merged in Suricata package version 4.1.2_2 which is now posted. This issue is resolved.
• W

  Suricata failing to start interface
  suricata • • Wafflez19

  2
  0
  Votes
  2
  Posts
  118
  Views

  

  @wafflez19 Go to the FLOW/STREAM tab and start increasing the TCP Stream Flow Memcap setting. The default is 32 MB (if I recall correctly), but with high core-count processors the default value may need doubling or even quadrupling in order for Suricata to start. The default value works fine on dual and quad-core processors, but higher core counts need much more Stream Memory. In your case, witih 16 cores, I would start with 256 MB and go up from there until Suricata starts reliably. Search this sub-forum for the same error (stream memcap) and you should find posts similar to yours with the solution. One of the posts in the past included the formula to use for calculating the amount of required memory based on your CPU core count.
• J

  Snort alert description
  • Joseph Watever J

  3
  0
  Votes
  3
  Posts
  97
  Views

  J

  Generic Protocol Command Decode : ET INFO Session Traversal Utilities for NAT (STUN Binding Response)
• N

  Snort Rules Update is failing
  • nipstech

  2
  0
  Votes
  2
  Posts
  117
  Views

  

  What time of day do you have configured for your automatic update? I've found that anything around midnight US Eastern time will frequently fail as that is apparently when the file is being updated on the Amazon Web Services site. No proof of this theory, just an idea ... . The fact a manual update suceeds for you leads me to think you may have that midnight problem. Try moving the update to some other time. I use 0130 (1:30 AM US Eastern Time) and mine never fails. A long time ago, my midnight updates frequently failed. Earlier this week, late at night while testing some Snort code changes, I was uninstalling and re-installing Snort on a virtual machine over and over. Things were going great until around midnight (about 15 minutes before and after, to be exact), then the rules download would fail with the 500 error for the MD5 file just like you are getting. I continued my coding and testing anyway since I didn't need the Snort Subscriber rules for testing, and after about 12:30 AM the downloads started working again.
• M

  Suricata frequent crashes
  • msf2000

  4
  0
  Votes
  4
  Posts
  143
  Views

  

  @msf2000 said in Suricata frequent crashes: What can I do to minimize the risk of these bus errors? Any memory settings? Rule sets to enable/disable? No, nothing really unless you knew precisely which rule or rules were causing the problem. But to complicate things even more, it could be the data in a network packet that causes the issue. It will be pretty random. I know it's not the answer you want, but the only way for now to really not have the problem is to run Suricata on hardware with an Intel-based CPU. That can be an Atom, i5, i7, etc.