Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Possible SNORT bug, not detecting rule

    Scheduled Pinned Locked Moved IDS/IPS
    4 Posts 3 Posters 1.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • V
      vingaard
      last edited by

      Hello forum,

      I have been searching for a solution for a weird Snort behaviour, but haven't been able to find a solution - this may be a bug in the snort implementation.
      Could someone assist me in this matter? - NB: real malicious domain has been change to "evilpage.tld"

      Snort info: Snort 2.9.7.6 pkg v3.2.9.1
      Rule that fires an alarm (correctly):
      alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"NF - POLICY - malicious web page access - LAN"; content:"GET"; nocase; http_method; content:"evilpage.tld"; nocase; http_header; classtype:policy-violation; sid:56001810; rev:1;)

      Rule that does not fires an alarm at all
      alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"NF - POLICY - malicious web page access"; flow:to_server,established; detection_filter:track by_dst, count 14, seconds 15; content:"GET"; nocase; http_method; content:"evilpage.tld"; nocase; http_header; classtype:policy-violation; metadata:NF,25042015; sid:56001810; rev:1;)

      Would anyone in the forum be able to assist me, so both rules fire a alarm in Snort,  I have a gut feeling that the "flow:established" keyword are the differentiator,
      but i would expect that the PFsense Snort would be able to understand this?

      many thanks in advance.

      1 Reply Last reply Reply Quote 0
      • BBcan177B
        BBcan177 Moderator
        last edited by

        You could also add a DNS sinkhole in the Resolver… or the Fowarder...

        Example Resolver redirect rule:

        local-zone: "evilpage.tld" redirect
        local-data: "evilpage.tld A 127.0.0.1"

        "Experience is something you don't get until just after you need it."

        Website: http://pfBlockerNG.com
        Twitter: @BBcan177  #pfBlockerNG
        Reddit: https://www.reddit.com/r/pfBlockerNG/new/

        1 Reply Last reply Reply Quote 0
        • V
          vingaard
          last edited by

          Hello BBcan117,

          Many thanks for taking the time to reply,

          Yes I know that the resolver can be used, but I am wondering why the "flow:established" keyword are working in a "normal" snort installation but not in the PFsense implementation.

          Would you know that ?

          Many thanks for all assistance,

          1 Reply Last reply Reply Quote 0
          • F
            fsansfil
            last edited by

            @vingaard:

            Would anyone in the forum be able to assist me, so both rules fire a alarm in Snort,  I have a gut feeling that the "flow:established" keyword are the differentiator,
            but i would expect that the PFsense Snort would be able to understand this?

            many thanks in advance.

            Well in that case, why dont you remove the threshold and diagnose only the flow…your second rule should be

            alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"NF - POLICY - malicious web page access"; flow:to_server,established; content:"GET"; nocase; http_method; content:"evilpage.tld"; nocase; http_header; classtype:policy-violation; metadata:NF,25042015; sid:56001811; rev:1;)
            

            F.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.