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

    Aliases and snort… still blocking ?

    Scheduled Pinned Locked Moved pfSense Packages
    5 Posts 3 Posters 2.3k 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.
    • A
      awsiemieniec
      last edited by

      System: 2.0.3-RELEASE (amd64)
      snort: 2.9.4.6 pkg v. 2.5.9

      I'm trying to dial in settings for snort.  Current issue is that I create an alias for something that I want to whitelist.  In this example we'll use WSUS updates.  All WSUS updates should be legit…  So in the alias type I have "Host(s)" and in IP I have wsus.ds.download.windowsupdate.com which will resolve to two different IPs: 23.59.190.122, 23.59.190.136.  I really dislike IPs in an alias list but if I need to use them instead of the FQDN, so be it.  Snort still blocks both IPs even if I have wsus.ds.download.windowsupdate.com whitelisted.

      According to the info snippet on the alias page:
      Enter as many hosts as you would like. Hosts must be specified by their IP address or fully qualified domain name (FQDN). FQDN hostnames are periodically re-resolved and updated. If multiple IPs are returned by a DNS query, all are used.

      Performing an nslookup on said URL does resolve to the two IPs from within pfSense but the whitelisting isn't working.  What am I supposed to do?  Just use IPs and grow my alias lists 10 fold or should this be working as I expect?

      Thanks.

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        wsus.ds.download.windowsupdate.com uses a CDN and some DNS randomness. It never resolves to just two IPs forever/all the time.

        Every time it does a DNS query, it's likely to get different results. It may be the same for a few minutes/hours but there is no guarantee the DNS response received by the firewall is going to be any different than the DNS response the client gets when attempting a connection.

        You could put in a DNS forwarder entry to override that so it does always resolve to the same small set of IPs, but then if they change anything on the server side, you'd have to remember to update that.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • A
          awsiemieniec
          last edited by

          Thanks, jimp, for the info.  I appreciate it.  It sounds like I need to adjust snort to make it "smarter" as described in this post: http://forum.pfsense.org/index.php/topic,64674.0.html

          One more thing.  Anyone else having issues with posting to this forum?  I keep getting a snort block:
          66.219.34.171 ET SHELLCODE Common %0c%0c%0c%0c Heap Spray String - 08/16/13-10:44:54

          This just points to another reason to dial in the snort settings.

          1 Reply Last reply Reply Quote 0
          • bmeeksB
            bmeeks
            last edited by

            There is a problem in the current Snort package code with FQDN aliases.  I actually think the problem may be within the pfSense core, or maybe the Snort package code is just calling the wrong function to get a value for an Alias.

            In the Snort 2.6.0 Package update I'm working on, I have created my own experimental routine to decode Alias values.  My experimental routine correctly decodes FQDN Alias values.  The built-in routine always returns a blank value when you pass it a FQDN Alias.  The Snort 2.5.9 package uses the built-in pfSense function, and thus gets back empty strings for any FQDN Alias.  So it's not surprising that it fails to resolve those FQDN Aliases into IP addresses for the whitelist file.

            However, there is a secondary problem here in that the whitelist is only created when Snort starts up, and thus it's only updated when Snort restarts.  So during the runtime period, a changing FQDN's IP address would not be picked up anyway.  Some more work is required in this area to make the whitelist more dynamic.

            Bill

            1 Reply Last reply Reply Quote 0
            • A
              awsiemieniec
              last edited by

              Bill - thanks for your input.  I'll be watching out for the 2.6.0 snort package update as well as dialing in the snort rules.

              Thanks.  Now to whitelist via IP the forum.pfsense.org site…  ;D

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