• 12 Votes
    29 Posts
    8k Views
    JonathanLeeJ
    @bmeeks your code is epic !!
  • How to get Suricata Alert logs to display correctly in Graylog Dashboard?

    4
    0 Votes
    4 Posts
    565 Views
    bmeeksB
    I do not personally use either, although I did once, several years ago, toy with an ELK setup. It was installed on a separate VM in my case.
  • Suricata logs: Move to a new location

    3
    0 Votes
    3 Posts
    478 Views
    C
    @bmeeks That would explain it. Thank you.
  • Suricata IDP/IDS on PFsense blocking all traffic

    4
    0 Votes
    4 Posts
    602 Views
    bmeeksB
    @Dr-Monarch said in Suricata IDP/IDS on PFsense blocking all traffic: What ideally i am aiming for is all traffic is dropped until particular rule is analyzed and cleared so it can be allowed. That's not how Suricata works -- unless I am still not understanding what you want to do. You whitelist hosts (by IP address) not SIDs (rules). There is no construct I am aware of that mimics a "whitelist" SID (Signature ID). You can certainly enable or disable particular rules (SIDs), but that will apply to all hosts. With Legacy Mode Blocking, all rules do block when triggered. The only exception is IP addresses in the Pass List which are not blocked. These are by default local LAN hosts, gateways, DNS servers, and the WAN interface's single public IP address. Inline IPS Mode requires that you manually change rule actions to DROP for all rules which you wish to block traffic when triggered. You can do this via SID MGMT or manually using the provided icons on the ALERTS or RULES tabs. There is no concept of a Pass List with Inline IPS Mode because that mode does not block an IP address. It instead drops the particular offending packet (the one that triggered the rule). If you want to exclude a particular IP address from enforcement action, you can use a Suppress List or change the rule's action to PASS and edit the target IP addresses in the SID as necessary. What you can do is selectively change the action of a given SID manually. You can set the action of a given SID to ALERT, DROP, REJECT, or PASS.
  • Netgate 1100

    pfsense 2.7.2
    4
    0 Votes
    4 Posts
    650 Views
    bmeeksB
    @jwnazz said in Netgate 1100: @bmeeks Snort started without issue with just the "Connectivity" IPS Policy selected. Thanks for the suggestion. Thank you for the feedback
  • Suricata not downloading Maxmind Database

    10
    0 Votes
    10 Posts
    1k Views
    N
    @bmeeks Makes sense. Auto-updates are def working as expected now. To your point I adjusted my frequency to weekly, every Saturday at 4am. I think Maxmind pushes updates every Tuesday & Friday. [image: 1745245386774-cffaed5b-4c49-4cff-aca1-34032b216f29-image.png]
  • Can someone explain why this rule gets triggered by Snort 3:19187?

    41
    0 Votes
    41 Posts
    7k Views
    R
    @rasputinthegreatest I realized I had packet captures enabled. I found this in Wireshark: 192.168.179.1 192.168.1.73 DNS 158 Standard query response 0x6ffc HTTPS chrome.cloudflare-dns.com HTTPS Doesn't tell me much though. Still makes no sense to me how this connection could happen and be captured. I saw this IP in the packet capture with an insane AV detection rate and IDS warnings on this website: https://otx.alienvault.com/indicator/ip/172.64.41.3
  • Suricata webGUI suppress list textbox

    1
    0 Votes
    1 Posts
    164 Views
    No one has replied
  • Snort alerts

    6
    0 Votes
    6 Posts
    768 Views
    D
    @tinfoilmatt Snort is running on the LAN interface.
  • Suricata Extra Rules from the OISF Suricata Ruleset Index

    2
    0 Votes
    2 Posts
    418 Views
    bmeeksB
    I am very reluctant to add rules to the package containing a URL with "githubusercontent.com" as the repository because those can disappear as suddenly as they appeared. They are maintained by users generally, and those users could lose interest in future support.
  • 0 Votes
    9 Posts
    1k Views
    N
    @johnpoz I hear ya, and I do have that working already. I was just very curious if there were any creative ways to catch someone casually sniffing with Wireshark in promiscuous mode. To your point, as soon as they start arp poisoning or scanning internal hosts I am going to catch them in seconds with my current setup and ruleset.
  • Open Appid Signatures - Updating?

    7
    0 Votes
    7 Posts
    1k Views
    M
    @bmeeks said in Open Appid Signatures - Updating?: The real story is that perimeter IDS/IPS is on the way out unless you devote time, effort, and energy into MITM proxying. Well i would argue its all about placement. I have firewalls (IPS/IDS built in) that police traffic DC <-> DC [East-West flows]. Yes if the majority of your traffic flows are to the Internet then an IPS is less effective as that is likely to be TLS encrypted but between datacenters you can detect unusual traffic. Its all about security in depth. I would rather have an IDS than not have one.
  • ET DNS Query for .to TLD from internal IP to gateway. False Positive?

    12
    0 Votes
    12 Posts
    2k Views
    bmeeksB
    @rasputinthegreatest said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?: @bmeeks @bmeeks said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?: Don't ever do this But for a VPN like Wireguard I still need to open one port. I did that in the past but it felt unsecure so I stopped using it. On my first trials with Tailscale I saw many error messages in the log. VPN connections are secured with a key and not a password. Long 256-byte cryptographic keys are considered very secure. They are much more secure than passwords. Having the VPN port open is not a big security risk because of the certifcated-based authentication. That's much different than say opening up port 3389 for Windows RDP or port forwarding non-authenticated generic connections.
  • Suricata scheduling rules

    suricata cron
    6
    0 Votes
    6 Posts
    812 Views
    bmeeksB
    @mmarco said in Suricata scheduling rules: @bmeeks thank you for the very good explanation. Yes , it fully makes sense what you say. So my idea will not work . I don't know how to recalculate rules, so my first thought was to simply save two configuration profiles in some other folder and then swap them, but then I realized that these rules get updated, and if I do this, I will be using outdated rules. So the only way would be to "tell" frontend to rebuild rules once I change SID management configuration, but I don't know how to trigger that, except perhaps to try to simulate request on GUI. You could adapt the official Suricata rules management tool from upstream, suricata-update to potentially accomplish what you wish. Here is a link to the official documentation for that tool: https://docs.suricata.io/en/latest/rule-management/suricata-update.html. That tool is packaged and deployed within the Suricata package on pfSense. So, the code is there. It's just not normally used on pfSense. You will have to adapt and customize the usage of that tool a bit in order to have it work within the confines of the existing GUI code and the logic used with the Suricata package on pfSense. But if you point that tool to the master rules repository and to the output rules directory for a Suricata instance on pfSense, in theory it should be able to construct a suricata.rules file for you. You would just need to duplicate the dropsid.conf and any other SID management files you created in the GUI out to plaintext files in a directory that suricata-update can access and use. I've never tried this, but I believe it could be make to work with some customization. I have considered a few times in the past attempting to incorporate this upstream tool into the Suricata GUI package code, but have not yet seriously attacked the problem nor analyzed it deeply enough to identify any potential show stopper issues.
  • SID Mgmt gui issue

    15
    1 Votes
    15 Posts
    1k Views
    M
    @marcosm We're all set. Thank You !
  • GUI element issue

    1
    0 Votes
    1 Posts
    201 Views
    No one has replied
  • Suricata seems to function but not showing blocks/alerts reliably

    5
    0 Votes
    5 Posts
    530 Views
    S
    @skogs Sometimes, it takes a village. :)
  • 0 Votes
    4 Posts
    729 Views
    jpgpi250J
    @stanwij1 https://chatgpt.com/ what is suricata rule 2013075 Suricata rule 2013075 is a rule designed to detect network traffic associated with the C&C (Command and Control) communication of malware. Specifically, this rule is meant to detect possible communications from a malware sample to a command and control server using HTTP as the communication protocol. The rule is part of Suricata’s signature-based detection for potential malicious activity. In this case, it focuses on identifying unusual or suspicious HTTP traffic patterns, often tied to botnets or other forms of malware that rely on HTTP-based C&C communications. what is suricata rule "ET MALWARE Large DNS Query possible covert channel" The Suricata rule "ET MALWARE Large DNS Query possible covert channel" is a rule designed to detect potential malware activity that uses DNS queries as a covert communication channel. Explanation: ET MALWARE: This indicates that the rule is part of the "Emerging Threats" (ET) signature set, which focuses on detecting malware-related traffic or behavior. Large DNS Query: This suggests that the DNS query in question is unusually large. DNS queries typically contain small amounts of data (like domain names), but in some cases, malware might use DNS queries with larger payloads, which can be a sign of malicious activity. Possible Covert Channel: A covert channel refers to a method used by malware to bypass security mechanisms by hiding data inside legitimate traffic. DNS, being a commonly used protocol for legitimate purposes, can sometimes be exploited by attackers to transmit data or control commands stealthily. Why It’s Important: Malware can use DNS queries to communicate with a command-and-control (C&C) server, exfiltrate data, or receive instructions. By embedding large or unusual data in DNS queries, attackers can avoid detection by blending in with normal DNS traffic. This rule is designed to catch those suspicious large DNS queries, which could indicate that such covert communication is taking place. How It Works: The rule triggers when a DNS query exceeds a certain size threshold, as large queries are unusual and could signal that the DNS protocol is being used for non-standard, potentially malicious purposes. It is part of a broader effort to detect "DNS tunneling," a technique where attackers use DNS to bypass network filters or firewalls. In summary, the "ET MALWARE Large DNS Query possible covert channel" rule is meant to flag large DNS queries, which could be indicative of malware trying to communicate or exfiltrate data in a covert manner using DNS.
  • Uknown VLAN Traffic with Suricata IPS Inline Mode

    16
    0 Votes
    16 Posts
    2k Views
    bmeeksB
    @Alessiottero said in Uknown VLAN Traffic with Suricata IPS Inline Mode: I guess SID mgmt is better for applying global filters or exclusions, like for silencing stream rules that are not useful except for troubleshooting, and suppression lists for excluding/including specific hosts or subnets in the inspections, correct? That is correct. The two serve different functions. SID MGMT is for rules management on a global scale (or actually per configured interface). Suppress Lists allow the suppression of individual SIDs for chosen IP addresses or networks. You can also suppress a given SID for all hosts, but that feature is also easily done by simply listing that SID in a "disable SID list" in the SID MGMT tab. But you can't filter SID MGMT selections by IP address or subnet like you can do with Suppress Lists.
  • Block VPN connection with Snort

    2
    0 Votes
    2 Posts
    386 Views
    GertjanG
    @AAS said in Block VPN connection with Snort: These programs are installed on the computer and I want to block their connection. The KIS solution : negotiate with the owner of that computer to de install them ? If snort 'looks' (analyses) a VPN IP packet header, it can't detect if the originating program was a VPN app, as this app could use any IP addresses as a destination, any port as a destination, and the data payload is "TLS encrypted" so it will be recognized as "noise". True, if the app was using the default UDP, and port 1194, then that could mean that the traffic is VPN traffic. It still is just a possibility, not a fact. The VPN app could even use port 443, protocol TCP as a destination, so the traffic is now identical ordinary "https" web traffic. Good luck blocking that.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.