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

    VNC Connection Hacked

    Scheduled Pinned Locked Moved General pfSense Questions
    11 Posts 5 Posters 8.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.
    • D
      dfriestedt
      last edited by

      I was connected to my work computer on Thursday through an encrypted 128b VNC connection (the enterprise version).  someone hacked the connection and came back into my home computer.  They were on it for about 1 minute until I saw what was going on.  I dropped the VNC connection and closed the port on my firewall.  I'm running a sonicwall and in the process of going over to pfsense.

      Scared the hell out of me.  I guess I should make a VPN connection to work and tunnel through that w/ VNC.  Just a heads up for others using VNC.

      1 Reply Last reply Reply Quote 0
      • Cry HavokC
        Cry Havok
        last edited by

        There are known vulnerabilities with many versions of VNC - if you haven't already then it's past time to upgrade (and check other software you have installed).

        If you're running any exposed service (including firewalls) then you should ensure you're subscribed to any -announce or -security type lists the authors provide.  That also goes for pfSense - it's always possible that a vulnerability will be discovered that allows a remote attacker access or control (see details on the Witty Worm for some malware that targeted a firewall product).

        1 Reply Last reply Reply Quote 0
        • P
          Perry
          last edited by

          I tunnel vnc through ssh using keys to login.

          To test your local windows pc for updates, you can use https://psi.secunia.com/

          /Perry
          doc.pfsense.org

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

            VNC is dead simple to brute force, encryption doesn't protect you from that. VNC should never be opened to the Internet.

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

              @cmb:

              VNC is dead simple to brute force, encryption doesn't protect you from that. VNC should never be opened to the Internet.

              By the same logic SSH should not be opened to the internet either… :)

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

                @mrsense:

                @cmb:

                VNC is dead simple to brute force, encryption doesn't protect you from that. VNC should never be opened to the Internet.

                By the same logic SSH should not be opened to the internet either… :)

                There are plenty of good ways to mitigate brute forcing with SSH, I've yet to see one way to do so with VNC.

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

                  @cmb:

                  There are plenty of good ways to mitigate brute forcing with SSH, I've yet to see one way to do so with VNC.

                  I like the port knocking solution which would work to secure both, however, there isn't one available for pfsense.

                  The only things I can think of to mitigate brute force attacks using pfsense would be to settup up max X new connections per Y seconds rule and run the services on a different port.

                  Can you suggest anything else to be done on pfsense to secure (non public key) ssh?

                  mr-s

                  1 Reply Last reply Reply Quote 1
                  • Cry HavokC
                    Cry Havok
                    last edited by

                    @mrsense:

                    By the same logic SSH should not be opened to the internet either… :)

                    Which is why you should always disable password authentication (and Keyboard Interactive) and use only public keys.  Moving to another port helps too.

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

                      @mrsense:

                      I like the port knocking solution which would work to secure both, however, there isn't one available for pfsense.

                      Port knocking isn't all that secure either, depending on the implementation. Most of the port knocking solutions leave you open to attacks from anyone that can intercept your traffic in transit.

                      @mrsense:

                      The only things I can think of to mitigate brute force attacks using pfsense would be to settup up max X new connections per Y seconds rule and run the services on a different port.

                      Can you suggest anything else to be done on pfsense to secure (non public key) ssh?

                      That's one way to limit brute forcing, but with the new coordinated via botnet SSH brute forcing attacks that are happening, it doesn't help all that much anymore. For the same reason, many of the old controls to prevent this also aren't as effective (blocking a certain IP after X failed login attempts).

                      The best controls are host based. Best of all, only allow key logins. The next best is ensuring the use of strong passwords, forcing it if your OS permits, and using cracking tools to audit your password strength. Using a non-standard port is something I do where possible to avoid the log noise annoyance, though not a security control in itself it is helpful. You can pay a lot closer attention to login failures when you eliminate that noise.

                      1 Reply Last reply Reply Quote 1
                      • D
                        dfriestedt
                        last edited by

                        @cmb:

                        @mrsense:

                        I like the port knocking solution which would work to secure both, however, there isn't one available for pfsense.

                        Port knocking isn't all that secure either, depending on the implementation. Most of the port knocking solutions leave you open to attacks from anyone that can intercept your traffic in transit.

                        @mrsense:

                        The only things I can think of to mitigate brute force attacks using pfsense would be to settup up max X new connections per Y seconds rule and run the services on a different port.

                        Can you suggest anything else to be done on pfsense to secure (non public key) ssh?

                        That's one way to limit brute forcing, but with the new coordinated via botnet SSH brute forcing attacks that are happening, it doesn't help all that much anymore. For the same reason, many of the old controls to prevent this also aren't as effective (blocking a certain IP after X failed login attempts).

                        The best controls are host based. Best of all, only allow key logins. The next best is ensuring the use of strong passwords, forcing it if your OS permits, and using cracking tools to audit your password strength. Using a non-standard port is something I do where possible to avoid the log noise annoyance, though not a security control in itself it is helpful. You can pay a lot closer attention to login failures when you eliminate that noise.

                        OK - I closed down the VNC port to the outside and now use SSH to login on non-std port.  I'll switch over to key login now.  Is there anything else I should be doing to secure VNC?  Do people use a different remote access product that is more secure?

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

                          VNC over SSH port tunneling is good as long as you can trust your LAN. Better solutions depend on your client OS. With Windows, RDP is better from a security standpoint (better yet with Vista) and drastically better performance-wise. RDP security also depends on host-based controls like account lockout. Also Windows won't let accounts with blank passwords login over the network including via RDP, so that protects you from some mistakes.

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