Still doing testing, but it looks like this rule has been causing issues:

2003315 udp 1024:65535 $HOME_NET 1024:65535 ET P2P Edonkey Search Reply

Any history of change on this rule?

I'll post more later if I narrow down any other rules.

@mikekoke

Hello!

I am not a suricata user, but looking at the default log format from a test install, the following might be a crude starting point...

grep ^`date -v-1d +"%m/%d/%Y"` /var/log/suricata/suricata_igb0*/alerts.log | awk -F "\\[\\*\\*\\]" '{a[$2]++;} END {for(i in a) print a[i]" "i}' | sed 's/"//g' | sort -r ; echo

The delimiters are not great, so there is some noise in the report.
This has not been tested.

John

@crunch-0 said in blocking p2p traffic:

@bmeeks

Hi thanks for the snort rule. Yeah my test machine can catch it. So it proves that snort works and i have no alternate path to the internet. I see drop alerts in the alert tab and i cannot ping (Request timeout).

Then that indicates the p2p rules you are using are insufficient to stop all of the Bit Torrent stuff. It is catching part of the conversation between client and peer, but not everything, so the client is still able to make the connection and download. It's not a problem with Snort itself. Instead, it is a problem with the rule or rules attempting to detect the traffic. The rules are apparently not picking up everything.

The PUA rules are really designed to detect the presence of the target application and not necessarily to block it totally. You may need other rules to completely block the traffic. Try a Google search for "blocking p2p with snort" to get some links. I found a few. Several are old, but some are newer. Here is a newer one: https://www.researchgate.net/publication/334213518_Interception_of_P2P_Traffic_in_a_Campus_Network.

Here is a SANS Institute paper from 2009 about detecting Bit Torrent with Snort: https://www.sans.edu/student-files/presentations/Pres_R_Wanner_Torrents_Snort_V2.pdf.

Blocking stuff like this is a whack-a-mole game. The developers of the torrent clients strive to make their traffic indistinguishable from regular network traffic (and thus unblockable). And the IDS/IPS rules creators strive to create new detection rules that trigger on the latest evasion techniques - and around and around it goes .... 🙂.

@bmeeks said in Snort Pass Lists + pfBlockerNG ingestion:

Something pretty much like you said you needed is coming soon. Look for the update in the pfSense DEVEL snapshots in the near future. Here is a post I made describing the new feature: https://forum.netgate.com/topic/160771/new-often-requested-snort-feature-coming-soon.

Thank you so much! That looks amazing.

@n8rfe said in Netgate XG-7100 SFP+ ports inline mode compatibility:

@bmeeks Thanks for the information. The SG-7100 is using the ix nics for its 10GB SFP+. Once configured both WAN and LAN to use these inline mode worked correctly with the obvious hardware checksum options enabled.

Thanks for the feedback. It will help others who might have the same question in the future.

@mxczxakm said in Ubuntu failing to update with Suricata enabled.:

apt-get doesn't work with Suricata enabled. It's in my firewall logs. It places the server IP's needed in the snort2c table.

Hi,

Delete the entry (es) from snort2c and disable the rule or rules which causes...this 😉

[https://doc.emergingthreats.net/bin/view/Main/2013504](link url)

as an example:

2021-02-08_19h10_17.jpg

@bmeeks Thanks for clarifying. Was hoping to find some resolution on these boards. Planning to delete Suricata plugin for now, will try it again in future probably next update!!

@stauraum said in Is OpenAppID dead?:

@nogamer @bmeeks Ok, I've found my services in "odp/appMapping.data" which was updated in november 2020. So i can create custom rules to block these services in my network.

I hope so that this file is updated in the future.

I think there is some interest in updating the file from another party, but I can't say who for now. Perhaps they will choose to takeover maintaining the OpenAppID text rules going forward.

In the meantime, you can certainly create your own custom OpenAppID rules to supplement those available in the standard archive. You found the proper location for identifying application names (in /usr/local/etc/snort/appid/odp/appMapping.data).

@nogbadthebad said in A funny thing about IDS/IPS.... /DNS related:

@bmeeks Yup it had me baffled for ages as I couldn't see any lookups from my LAN interface to the offending FQDNS.

Yes, the firewall itself sources the connection for the DNS lookup, and that traffic will exit the WAN on the way to either the DNS root servers or whatever DNS forwarder might be configured. So the IDS rules on the WAN see the traffic and alert. Since it's on the WAN, and the IDS sits beyond the firewall, the IDS sees your firewall's public WAN IP as the "source". The natural inclination is to assume the traffic originated on your LAN, but it actually did not.

@terminalhit said in Suricata SIGHUP every 5 minutes:

@bmeeks, If I had to guess it's the EVE.JSON file which i'm ingesting into ELK for dashboards. In the Log Size and Retention Limits configuration the max size is 10MB, but I currently have a file in there "eve.json" that is 1.2GB

The idea is for the log to rotate and get a new name with a UNIX timestamp appended to it. Then a new empty log file is opened for Suricata. The SIGHUP is supposed to tell Suricata to reopen log files. Unfortunately, the Suricata binary can only rotate certain logs natively. So without the GUI attempting to rotate the others, they will grow to impossibly large sizes.

Do you have any eve.json logs that have a UNIX timestamp on the end? If not, the log rotation is not actually working. That would be why it keeps trying each time the cron task runs (every 5 minutes).

You might have a duplicate Suricata zombie process attempting to use the log file. If you can, stop Suricata on the interface for more than 5 minutes. This will allow the cron task to run and hopefully rotate that huge file. Then restart Suricata on the interface. If stopping Suricata for more than 5 minutes does not result in the file rotating, then manually rename it yourself (the big 1.2 GB file) to something else and then restart Suricata.

@bmeeks Impressive, Thanks.

@bmeeks You gotta teach me :)

@volnodumcev said in Suricata failed to setup thread module:

SC_ERR_LUA_ERROR(212)] - failed to setup thread module
I'm getting this error in suricata.log but didn't find anything neither about this error nor about how to fix it. Can anyone help?

Never seen that error before.

Please share some information about your installation such as:

Version of pfSense you are running

Version of the Suricata package you are running

Is this a fatal error? Does Suricata start and run, or is it failing to start?

List of any other installed packages (including any you may have installed from a non-pfSense repository)

@pfsense7515 said in Snort blocking pass list:

@bmeeks

Hello thank you for your reply. About your questions

did you restart Snort on that interface? yes, I tried several times but without success. Do you need to restart services SNORT ?

-How did you even install that version of Snort ? We setup integrated packages includes on pfsense

We are aware that it is necessary to update. Do you have any idea other suggestions please ?

Thanks a lot

No, I have no other suggestions if you have done all of the following:

Open the INTERFACE SETTINGS tab for the affected Snort interface and select the desired Pass List by name in the drop-down selector for Pass List assignment.

SAVE that change and return to the INTERFACES tab in Snort.

Click the icon on the affected interface to restart Snort.

If Snort has already previously blocked a particular IP address, then you must manually remove that block by going to the BLOCKED tab and deleting the address from the list (or just clear all blocks). Snort hands off blocking to pfSense, so restarting Snort or stopping Snort will not unblock a previoulsy blocked IP address. Just pointing that out because some folks think otherwise. Snort is not dynamic. It only reads a Pass List when starting, and it can't "unblock" anything. When a Snort alert triggers, Snort extracts the IP from the triggering packet and sends it to the firewall for blocking. After that, pfSense itself holds the block, not Snort.

You really need to update your firewall. Running out of date software on a critical component such as a network firewall is not wise.

@nogbadthebad

Yes sorry. I replied to good person on correct channel

@volnodumcev said in Matching data between different packets:

Please give me a hand with one task. I need to compare Timestamp field between Goose protocol packets to prevent a MITM attack. Can I solve it using Suricata rules?

I do not believe that is possible with either Suricata or Snort rules syntax. But I confess to not being a rule writing guru. You might consider posting your question on the mailing lists for Suricata.

Here are the Suricata Mailing Lists: https://lists.openinfosecfoundation.org/mailman/listinfo.

Hello!

Thanks for looking into this so quickly!

The manual restart did the job.

John

The IDS packages sit out in front of the pfSense firewall engine. So they see traffic before any firewall rules or NAT is applied. For Legacy Mode Blocking operation, the IDS engine is getting copies of packets as they traverse from the NIC to the firewall engine in the kernel. For Inline IPS Mode operation, the IDS sits between the NIC and the firewall engine by way of a netmap kernel device network pipe. See the two diagrams below that show the traffic flow for both Legacy Mode Blocking and Inline IPS Mode blocking.

ids-ips-network-flow-legacy-mode.png

ids-ips-network-flow-ips-mode.png