VNC Connection Hacked
-
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).
-
I tunnel vnc through ssh using keys to login.
To test your local windows pc for updates, you can use https://psi.secunia.com/
-
VNC is dead simple to brute force, encryption doesn't protect you from that. VNC should never be opened to the Internet.
-
@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… :)
-
@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.
-
@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
-
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.
-
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.
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.
-
@cmb:
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.
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?
-
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.
