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

    Any plans for Snort to support FQDN aliases?

    Scheduled Pinned Locked Moved IDS/IPS
    18 Posts 7 Posters 6.4k 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.
    • F
      firewalluser
      last edited by

      Apologies if this has been asked before couldnt see anything when doing a google search on snort aliases, is there any plans for snort to support Aliases using FQDN?

      TIA

      Capitalism, currently The World's best Entertainment Control System and YOU cant buy it! But you can buy this, or some of this or some of these

      Asch Conformity, mainly the blind leading the blind.

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

        Not at the moment.  The overhead would be substantial if it did real time lookups.  Scanning through the Alias tables is perhaps a possibility, but those are only updated every 5 minutes.  Never looked into it much, though.  If it existed, it would only work with PASS LISTS.

        The blocking plugin today for Snort reads in the Pass List at startup and stores the IP addresses in memory.  It does not update them again until the next restart of Snort.

        Bill

        1 Reply Last reply Reply Quote 0
        • D
          daq
          last edited by

          Could it at least handle them more intelligently? In my experiment Snort ignores any entries in the pass list alias that are below any FQDN entries. For example if the alias contains:

          8.8.8.8/32
          google.com
          208.67.220.220/32
          

          Then 208.67.220.220 will be ignored and will continue to be blocked.

          Also, snort already takes forever to restart, and since it only reads the alias during startup, I can't imagine resolving FQDN once during startup will add any noticeable delay.

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

            @daq:

            Could it at least handle them more intelligently? In my experiment Snort ignores any entries in the pass list alias that are below any FQDN entries. For example if the alias contains:

            8.8.8.8/32
            google.com
            208.67.220.220/32
            

            Then 208.67.220.220 will be ignored and will continue to be blocked.

            Also, snort already takes forever to restart, and since it only reads the alias during startup, I can't imagine resolving FQDN once during startup will add any noticeable delay.

            The system call that Snort uses to resolve aliases returns an empty string when passed a FQDN alias (well, actually what I mean is you get an empty string back when the alias name you passed to the system function is a FQDN value type).  I think that is because FQDN aliases wind up as tables in pf that are populated in the background by the filterdns daemon.

            By the way, how did you get that "google.com" entry in there?  The code is supposed to be ignoring FQDN aliases since they return empty strings.

            True that Snort could perhaps do a DNS lookup when loading the Pass List, but what is the point?  It would be a "snapshot in time" IP address and would be meaningless for load-balanced hosts like your "google.com" example which can change IP with each DNS lookup (ignoring any local caching).

            Bill

            1 Reply Last reply Reply Quote 0
            • D
              daq
              last edited by

              @bmeeks:

              By the way, how did you get that "google.com" entry in there?  The code is supposed to be ignoring FQDN aliases since they return empty strings.

              There is nothing to prevent me from entering a FQDN into alias of type Hosts. In fact, the note in the alias edit screen specifically says:

              Enter as many hosts as you would like. Hosts must be specified by their IP address or fully qualified domain name (FQDN).

              @bmeeks:

              True that Snort could perhaps do a DNS lookup when loading the Pass List, but what is the point?  It would be a "snapshot in time" IP address and would be meaningless for load-balanced hosts like your "google.com" example which can change IP with each DNS lookup (ignoring any local caching).

              Bill

              That's true, but it would help with hosts that are balanced like AWS, for example, where address of the load balancer rarely changes. When it does, all you have to do is restart Snort and tables would get updated. Ideally even without a complete restart - just reload the in-memory tables with fresh IPs.

              It would also simplify adding FQDN that resolve to multiple IPs:

              
              $ nslookup imap.mail.yahoo.com
              Server:         172.31.0.2
              Address:        172.31.0.2#53
              
              Non-authoritative answer:
              imap.mail.yahoo.com     canonical name = imap4.mail.global.gm0.yahoodns.net.
              imap4.mail.global.gm0.yahoodns.net      canonical name = imap4.mail.any.am0.yahoodns.net.
              imap4.mail.any.am0.yahoodns.net canonical name = imap4.mail.us.am0.yahoodns.net.
              Name:   imap4.mail.us.am0.yahoodns.net
              Address: 98.138.112.231
              Name:   imap4.mail.us.am0.yahoodns.net
              Address: 98.138.227.202
              Name:   imap4.mail.us.am0.yahoodns.net
              Address: 66.196.81.222
              Name:   imap4.mail.us.am0.yahoodns.net
              Address: 66.196.118.242
              Name:   imap4.mail.us.am0.yahoodns.net
              Address: 67.195.13.49
              Name:   imap4.mail.us.am0.yahoodns.net
              Address: 69.147.116.171
              Name:   imap4.mail.us.am0.yahoodns.net
              Address: 98.138.12.49
              Name:   imap4.mail.us.am0.yahoodns.net
              Address: 98.138.112.188
              
              
              1 Reply Last reply Reply Quote 0
              • bmeeksB
                bmeeks
                last edited by

                @daq:

                There is nothing to prevent me from entering a FQDN into alias of type Hosts. In fact, the note in the alias edit screen specifically says:

                Enter as many hosts as you would like. Hosts must be specified by their IP address or fully qualified domain name (FQDN).

                I don't mean on the Firewall > Aliases menu.  I know you can use them there.  I was talking about within the PASS LIST itself.  I though I had the PHP code in the Snort GUI package checking for blank returned values and skipping them.  You get blank returned values for FQDN aliases when you call the system's expand_alias() function.  – or at least that's how it worked in 2.1.x.

                Bill

                1 Reply Last reply Reply Quote 0
                • mudmanc4M
                  mudmanc4
                  last edited by

                  Clamping pfsense down a bit adding snort rules, and attempting to find a solution to adding multi IP or range services to whitelist.

                  Take pandora for instance, hundreds if not 2048 IP's

                  Solution?

                  Thanks

                  1 Reply Last reply Reply Quote 0
                  • S
                    Supermule Banned
                    last edited by

                    If pfSense could run Layer7 inspection, you would be able to block every domain name you wanted to.

                    Why is nobody aware of this and why is it not implemented fully in pfSense?

                    1 Reply Last reply Reply Quote 0
                    • mudmanc4M
                      mudmanc4
                      last edited by

                      @Supermule:

                      If pfSense could run Layer7 inspection, you would be able to block every domain name you wanted to.

                      Why is nobody aware of this and why is it not implemented fully in pfSense?

                      I should rephrase my inquisition.

                      I am looking to avoid entering in several CIDR ranged Alias'. Considering FQDN's are not getting lookups through snort. Not blocking the service, but allowing them to be whitelisted.

                      Ths would not be an issue, if there were not so many services relying on any given number of IP subsets for their own purpose.

                      To add: PFsense is more of a wall, then punch holes through the wall to allow {?}, blocking the entire net, then opening holes for wanted / needed services, would be much more preferred.

                      Were looking at this from the wrong perspective IMO, we should be shipping PFsense completely locked down. Then accessing lists of "allowed" standard services / ports, not searching for ways to stop something from being blocked.

                      1 Reply Last reply Reply Quote 0
                      • S
                        Supermule Banned
                        last edited by

                        No but you would be able very easily, to shutdown entire domains like Google, Facebook asf.

                        Not worrying about their IP range and depending on lists from external services.

                        ISA Server 2006 had it implemented and it worked fantastic.

                        1 Reply Last reply Reply Quote 0
                        • mudmanc4M
                          mudmanc4
                          last edited by

                          @Supermule:

                          No but you would be able very easily, to shutdown entire domains like Google, Facebook asf.

                          Not worrying about their IP range and depending on lists from external services.

                          ISA Server 2006 had it implemented and it worked fantastic.

                          This is my point though.
                          Block it all, yes everything and anything nothing lives on that NIC until specifically associated.

                          I spend more time being on the defensive against guys I do not care to endure, than functionally moving forward.

                          The entire idea is the complete antithesis of what it should be.

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

                            @mudmanc4:

                            Clamping pfsense down a bit adding snort rules, and attempting to find a solution to adding multi IP or range services to whitelist.

                            Take pandora for instance, hundreds if not 2048 IP's

                            Solution?

                            Thanks

                            Well if you want to block pandora, no matter the IPs, block it with appid or with packet inspection rule, certificate rule, etc..

                            appid: pandora

                            F.

                            1 Reply Last reply Reply Quote 0
                            • mudmanc4M
                              mudmanc4
                              last edited by

                              Right, and thanks for the input.

                              whitelist, means to allow

                              Snort will toast any connection if packets fall under his domain. Hence why whitelisting an IP or range would allow said IP's to pass througe the pre-processor.

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

                                Dont forget you can negate appid…

                                appid: !pandora !http !https !ssl !aws

                                But I undestand your point.

                                F.

                                1 Reply Last reply Reply Quote 0
                                • RuddimasterR
                                  Ruddimaster
                                  last edited by

                                  Hi,

                                  I found this thread, because I have the same issue. But a little bit different. My problem are not the big guys but with the small ones:
                                  I have several costumer with dynamic IP addresses (DSL). Every 24hour online, these are forced to become a new address. To identify this costumer with his own IP, we use dynamic DNS providers like DynDNS. Bu it is not possible to use this technique in snort.

                                  even worse: if a FQDN is within the white list, the complete list will be ignored.

                                  Is there a chance to solve this?

                                  2.2.1-RELEASE
                                  2.9.7.2 pkg v3.2.4

                                  Dirk

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

                                    Supporting FQDN aliases in an IDS/IPS is a daunting task.  Here is why –

                                    The list of Whitelist (or Pass List) IP addresses is held in an in-memory table to allow rapid lookups.  You need to do extremely rapid lookups or else you bog down the system as it waits and waits for the blocking code in the IDS/IPS to figure out if the IP is in the exclusion table or not.  Today the list of IP addresses is read once during Snort or Suricata startup and lives in memory unchanged until the next restart.  So the list is fixed in size and static for a given run.  This allows for the fastest possible lookups.  It's simply looking for a matching 32-bit or 128-bit number (depending on IPv4 or IPv6).  CPUs can do that kind of number crunching lightning fast.

                                    Now think about a FQDN alias.  This is a host name.  It has to be resolved to an IP address because the header in IP packets contains only the numerical IP address and not the host name for source and destination.  So if you did a real time DNS lookup for each packet stream, things would get very slow in terms of making the block/no block decision.  You would have to wait for the DNS lookup to complete.  That could be up to 2 or 3 seconds for a really slow DNS host or if you had to wait for DNS failover.  Nobody would want their network streams held up that long.

                                    pfSense makes a little compromise when it comes to doing the DNS lookups.  They are performed once every 5 minutes.  Of course this means some period of time will elapse where the IP address for a dynamic host might be wrong.  The IP addresses resolved for FQDN aliases are stored in pf tables, one table per alias.  Unfortunately I know of no method to search the tables other than brute force.  I will continue to look for some method implementing FQDN support, but it's a tough nut to crack unless you are willing to put throughput in the toilet.

                                    Bill

                                    1 Reply Last reply Reply Quote 0
                                    • RuddimasterR
                                      Ruddimaster
                                      last edited by

                                      Hi Bill,

                                      thanks for your reply.
                                      so in that case, I'm not able to protect my web server, if my costumer (web designer) use a dynamic Internet access, because they work intensive on that machine and therefore rapidly blocked.

                                      Or is there a work around?

                                      Dirk

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

                                        @Ruddimaster:

                                        Hi Bill,

                                        thanks for your reply.
                                        so in that case, I'm not able to protect my web server, if my costumer (web designer) use a dynamic Internet access, because they work intensive on that machine and therefore rapidly blocked.

                                        Or is there a work around?

                                        Dirk

                                        Is there a specific rule that is firing?  If so, just suppress the alert or even disable the rule.  You can even do that for multiple rules if you determine they are false positives.  If the rules are firing on actual threats, then it's a good thing the customers are blocked… ;).

                                        I am going to guess that you are probably seeing alerts from the HTTP_INSPECT preprocessor since you mentioned a web server.  Many of those rules will false positive with today's web content.  They enforce a very rigid adherence to all the RFCs, and unfortunately lots of web content today does not always strictly adhere to the RFCs.

                                        Bill

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