Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


How do you protect SSH & RDP Ports
New on LowEndTalk? Please Register and read our Community Rules.

How do you protect SSH & RDP Ports

Hello,
I have been trying to get the best way to protect SSH & RDP services
-> Different RDP/SSH Port
-> Set up a VPN using a Cheap VPS and use the host.allow/deny rules to allow traffic from VPN IP only.
-> Use tailscale.com or Cloudflare Gateway and allow traffic(Any one using them to protect ssh)

Comments

  • DPDP Administrator, The Domain Guy

    Disable both and access from console.

    Secure! \o/

    Thanked by 2Erisa ehab
  • @DP said:
    Disable both and access from console.

    Secure! \o/

    I have almost 20 servers and a team that access servers, So access from console is not a ideal solution.

  • suutsuut Member

    Change Port.

    Thanked by 1ehab
  • taizitaizi Member
    edited October 4

    @mailcastle said: a team that access servers

    https://goteleport.com/

    Thanked by 1sergsergiu
  • libpam-google-authenticator

    Thanked by 1rcy026
  • @taizi said:

    @mailcastle said: a team that access servers

    https://goteleport.com/

    This looks cool!

  • @mailcastle said:
    Hello,
    I have been trying to get the best way to protect SSH & RDP services
    -> Different RDP/SSH Port
    -> Set up a VPN using a Cheap VPS and use the host.allow/deny rules to allow traffic from VPN IP only.
    -> Use tailscale.com or Cloudflare Gateway and allow traffic(Any one using them to protect ssh)

    Cloudflare Zero Trust

  • rcy026rcy026 Member

    Setup a jumphost locked down with 2FA and only allow connections from that to all other servers. And of course all other standard practices such as no root login etc.

    Thanked by 1Havy
  • 0xbkt0xbkt Member
    edited October 4

    I use Tailscale. And bind SSH on the IP of its interface.

  • for RDP , i am using rdp guard from few years , and its Good.

  • emgemg Member

    I documented my SSH configuration in a recent post here:
    Post:
    https://lowendtalk.com/discussion/comment/3485767#Comment_3485767
    Thread:
    https://lowendtalk.com/discussion/181565/best-practices-for-sshd-config

    Summary:

    • Change to random port
    • Disable root logins
    • Use public key authentication
    • Disable password authentication
    • Restrict remote access to a special, unprivileged, empty remote access account (AllowUsers).

    Once connected with SSH, I can use the "su" command to change to my unprivileged personal user account. If I need admin privileges, I can su to the admin account, which is the account that has sudo privileges (on the suduers list). On some systems, I maintain a backup admin account with sudo privileges, just in case.

    I do similar things with Windows Remote Desktop and other remote access scenarios. Moving the port does not enhance security much, but it lowers the logging and thus your workload. Create a separate, unprivileged account solely for remote access. (Make the hacker work to escalate privileges and break out of that account.) You get the idea.

    Thanked by 2jmaxwell yoursunny
  • HavyHavy Member

    @rcy026 said:
    Setup a jumphost locked down with 2FA and only allow connections from that to all other servers. And of course all other standard practices such as no root login etc.

    Only sure fire way, just make sure the jumphost is of course of upmost trustworthy and isn't likely gonna fails you. Else you could have bigger problems on your hands... So ya don't try putting that promo 128MB VPS you just got for $3/year as your jumphost.

  • @Havy said:

    @rcy026 said:
    Setup a jumphost locked down with 2FA and only allow connections from that to all other servers. And of course all other standard practices such as no root login etc.

    Only sure fire way, just make sure the jumphost is of course of upmost trustworthy and isn't likely gonna fails you. Else you could have bigger problems on your hands... So ya don't try putting that promo 128MB VPS you just got for $3/year as your jumphost.

    May be using 2-3 host to auth the server, So if one fail you are safe with other.

  • Most important first step: make sure you have secure credentials for all active user accounts (keys or string passwords for SSH, strong passwords for RDP) and that you keep the services fully patched as new security issues are found and fixed.

    I don't have much truck with changing ports, the main benefit of that is it reduces log bloat when the brute force attempts pass by. While it is true that most malware will just check the standard ports there are certainly some that poke elsewhere and more guided attacks will to (how likely you are to attract a more manual attack depends on your line of business and your tendency to offend/irritate people). I've had issues in the past with networks not letting connections to anything other than standard common ports (22, 80, 443, 3389, ete.) out, if you are on such a network and you need to access SHH on a non-standard port then you'd better hope your phone has usable reception so you can tether and access it that way instead.

    For one group of services I have a bastion host that I SSH through (tunnelling for other protocols such as RDP) with the hosts behind that not accepting direct connections to admin services from the outside, to reduce the direct attack service a bit. But I still think just having solid credentials and being patched up-to-date is both the best defence and the minimum defence.

  • @emg said:
    I documented my SSH configuration in a recent post here:
    Post:
    https://lowendtalk.com/discussion/comment/3485767#Comment_3485767
    Thread:
    https://lowendtalk.com/discussion/181565/best-practices-for-sshd-config

    Summary:

    • Change to random port
    • Disable root logins
    • Use public key authentication
    • Disable password authentication
    • Restrict remote access to a special, unprivileged, empty remote access account (AllowUsers).

    Once connected with SSH, I can use the "su" command to change to my unprivileged personal user account. If I need admin privileges, I can su to the admin account, which is the account that has sudo privileges (on the suduers list). On some systems, I maintain a backup admin account with sudo privileges, just in case.

    I do similar things with Windows Remote Desktop and other remote access scenarios. Moving the port does not enhance security much, but it lowers the logging and thus your workload. Create a separate, unprivileged account solely for remote access. (Make the hacker work to escalate privileges and break out of that account.) You get the idea.

    Using a VPN service and allowing login to sshd service only from VPN will easy the things i belive, As in that case you don;t need to change ports, As i have mentioned i need to use passwd auth.

  • @0xbkt said:
    I use Tailscale. And bind SSH on the IP of its interface.

    I also plan to do so, But I have a question If tailscale service crash of fails to start in your linux vm for some reason what would be the resue solution in that case? As i have seen tailscale been unstable in my windows and crash sometimes or loss connection.

  • emgemg Member

    @bikrama said:

    Using a VPN service and allowing login to sshd service only from VPN will easy the things i belive, As in that case you don;t need to change ports, As i have mentioned i need to use passwd auth.

    Sorry, I missed where you said that password authentication is a requirement.

    A VPN will provide a known fixed IP address, which enhances security if you restrict access to the SSH server from that IP address only. That would be an effective security measure as long as you have a plan for what to do if the VPN is unavailable or the IP address vanishes before you can update the SSH server.

    There is also an inherent assumption that the VPN is well-secured. Is the VPN included in your threat model? Can it be used as a jumping off point to attack the SSH server?

    Finally, as I said before, "Moving the port does not enhance security much, but it lowers the logging and thus your workload."

  • yoursunnyyoursunny Member, IPv6 Advocate
    edited October 4

    Mentally strong people keep the SSH port at its default and keep the password at 6 digits.
    PasswordAuthentication no

  • SSH: key only.
    VNC: bind to 127.0.0.1 and use SSH port forwarding to gain access.

    Now the only way to break in is to break the SSH key, which is virtually impossible now.

  • zorkerzorker Member

    zerotier.com

  • ralfralf Member

    @yoursunny said:
    Mentally strong people keep the SSH port at its default and keep the password at 6 digits.

    6 digits, all zeros.

Sign In or Register to comment.