Navigation

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

    Security issues

    2.0-RC Snapshot Feedback and Problems - RETIRED
    5
    9
    2049
    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.
    • M
      mrguitar last edited by

      I'm running the snapshot: pfSense-2.0-BETA4-1g-20101202-0339-nanobsd.img and I just had a scare after looking at the system logs. Apparently ports 22 & 53 were open on the WAN interface, yet there was no rule on the WAN interface to open ANYTHING. Pretty scary stuff. I'm going to try one of the snapshots from today and see how it goes.

      I just wanted to let everyone know that it's a good idea to port scan your self when testing these builds.

      1 Reply Last reply Reply Quote 0
      • M
        mrguitar last edited by

        I just upgraded to the latest snapshot and both 22 & 53 are open on the WAN port. Disabling SSH is an easy but an annoying fix, because I'd like to run it on the lan. I can make DNS requests against my firewall from the outside. This is crazy. I am running dnsmasq and setting a rule to block 53 on WAN has no effect. Maybe I should add that my WAN is tied to a PPPoE DSL line. Could that be part of the problem?

        Any help would be appreciated.

        1 Reply Last reply Reply Quote 0
        • C
          clarknova last edited by

          I recently made a similar realization and it turned out one of my floating rules was the cause of the problem. If you want to post your /tmp/rules.debug here we can have a look, particularly the section beginning "# User-defined rules follow".

          db

          1 Reply Last reply Reply Quote 0
          • E
            Efonnes last edited by

            You could also check whether there are any pass quick rules above that section that are allowing those ports.

            1 Reply Last reply Reply Quote 0
            • C
              cmb last edited by

              By default nothing is allowed in WAN, but if you add floating rules or WAN rules you can allow that traffic. It's not a security issue (well, it's a user-created one), just doing what you configure it to do.

              1 Reply Last reply Reply Quote 0
              • M
                mrguitar last edited by

                I understand how to write firewall rules (most of the time). I have two rules on my WAN port.
                1. tcp/80 –> web server
                2. tcp/1194 --> openvpn

                The only firewall rule that mentions port 22 is the anti-lockout rule on the LAN interface. However when SSHD is enabled in pfSense it's available to the outside. I'm glad I was reading the logs last night and that I have a strong password. Sure enough I could SSH in from my phone, until I stopped the daemon. I've never seen behavior like this from pfsense (or any other firewall).

                While using nmap to see if anything else was open 53 showed up as open, and dig @myip was resolving addresses. This really freaked me out until I ran another port scan from the office this morning. I can say confidently that this port was never open and the false positive was a result of tethering through sprint's network. Any IP I scan through sprint 53 shows as open. I guess they always high-jack dns.

                The good news is that 53 was never open; dnsmasq was not open. The bad news is that SSH was open. I'm not familiar w/ floating rules. I'll have to look into that tonight. Also I'll get the output of the tmp dir when I have a minute.

                Can anyone replicate this issue w/ SSH? I'm running an Alix 2d3 w/ nanobsd 1g img.

                Thanks for the feedback.

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

                  I just scanned my firewall using GRC.com's shields up page.  Ports 22 & 53 were not available on my WAN interface.
                  I have both dnsmasq and sshd enabled on my box.

                  running i386 full built on Sat Dec 4 01:05:18 EST 2010

                  1 Reply Last reply Reply Quote 0
                  • M
                    mrguitar last edited by

                    I wouldn't expect 53 to be open as that was a nmap/Sprint false positive.

                    …but that's good to know that 22 is working properly. I assume you have SSH running, correct?

                    I'm sure I have something foobared in my config, but I really haven't done much to it. :| I'll troubleshoot more tonight when I'm home.

                    1 Reply Last reply Reply Quote 0
                    • M
                      mrguitar last edited by

                      Clarknova, here's the output from /tmp/rules.debug
                      rules.debug: unmodified: line 1
                      WAN = "{ pppoe0 }"
                      LAN = "{ vr0 }"
                      DMZ = "{ vr2 }"
                      #SSH Lockout Tablepn }"
                      table <sshlockout>persist
                      table <webconfiguratorlockout>persist
                      #Snort2C table

                      Gatewaysasesot>

                      set loginterface pppoe0poe0 XX.XX.XX.XX ) "
                      set loginterface vr0

                      I tried enabling SSH on the snapshot from last night, and the behavior is normal. Nothing is exposed. This whole thing was strange. Sorry for over-reacting last night; I was kind-of freaked out.

                      PJ2, good call on using grc.com for scanning. That proves much more reliable that using a mobile network.

                      …I imagine this was user error like everything else. ;)
                      cheers,</webconfiguratorlockout></sshlockout>

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post