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

Snort, Variables tab, Define Ports Error

Scheduled Pinned Locked Moved pfSense Packages
4 Posts 2 Posters 1.9k 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.
  • C
    ccb056
    last edited by Mar 7, 2013, 12:49 AM

    Running:

    pfSense 2.0.2-RELEASE (amd64)
    Snort 2.9.2.3 pkg v. 2.5.4

    When I attempt to define the FTP port to 5595 in the "Variables" tab I receive the following error

    The following input errors were detected:

    Only aliases are allowed

    I understand the need for aliases when defining servers, but for ports?????

    This seems to be a bug.

    1 Reply Last reply Reply Quote 0
    • B
      bmeeks
      last edited by Mar 7, 2013, 1:32 PM Mar 7, 2013, 1:02 PM

      Not a bug.  While many disagree with the direction (and I must admit I am sort of sitting on the fence trying to decide if I agree or disagree with it in all cases), the idea of the main developers is that these things be Aliases so they can be edited in one single place and yet be "changed" everywhere.

      In this case of changing the FTP port in Snort, consider the following scenario.

      You change the FTP port variable in Snort to 5595.  I assume you are also changing it in the firewall rules ??  What if later you come back and revert the firewall rule back to the standard port 21, but you forget to change the Snort variable?  Or what if you had a typo in the Snort variable and typed 5995 instead of 5595?  In either case, you would not be getting the Snort protection you thought you were for FTP traffic.

      Using an Alias and then referencing that Alias in both the firewall rules and the Snort variable, anytime you need to change the port you just edit the Alias value and "poof", it's auto-magically changed in all the locations where it is used.  So Aliases are really better in the long run for maintenance, although maybe a bit inconvenient at first until you become accustomed to the process.

      This same general idea of Aliases is used in some other major commercial firewalls.  Check Point, for example, uses the same concept except they call them "objects" instead of "aliases".  But they are used the same way.  You can't directly specify IP addresses or ports in firewall rules under Check Point.  You must first create an Object to represent the IP address or port , and then reference that object in any rules.

      Bill

      1 Reply Last reply Reply Quote 0
      • C
        ccb056
        last edited by Mar 8, 2013, 3:20 PM

        Ah, this makes some sense now.

        Regarding the FTP, I have made the alias and everything is well in the 'Variables' tab now.
        However, when I review the emerging-ftp.rules it looks like everything is set for port 21, and not the port I am actually running my FTP server on.
        How is my FTP server being protected if all the rules only listen for port 21?

        1 Reply Last reply Reply Quote 0
        • B
          bmeeks
          last edited by Mar 8, 2013, 5:48 PM Mar 8, 2013, 5:44 PM

          Well, if the rule itself is hard-coded, then you are not protected unless you manually change the rule.  If the rule, for example, said something like $FTP_PORTS instead of "21", then you would be protected.  Unfortunately we are somewhat at the mercy of the rule writers from both Emerging Threats and Snort VRT.

          So it sounds like in your particular case, you might be better off using the default FTP port instead of an alternate one.  The only other fix I can think of would be to manually edit the affected rules, but then at the next rules update you would have to do it again.

          Bill

          1 Reply Last reply Reply Quote 0
          2 out of 4
          • First post
            2/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received