Howdy, Stranger!

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


VPS Security? - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

VPS Security?

2

Comments

  • LeoLeo Member

    @MCHPhil said: Once again, this is not security.

    I never said it was security. I said it will not impact you security as long as you kept the port bellow 1024.

    I agree that against targeted attacks is obscurity not much help.

  • @ MCHPhil if the ssh port at the default location works for you, then great!

    For me, changing the default port works best.

    No need to be an a** and insult people over it.

    Thanked by 1NanoG6
  • i did several things including changing the default port and to be honest , it doesn't help much. now i'm running fail2ban, using ssh keys and only allow ssh login from trusted ip zone.

    cheers

  • SilvengaSilvenga Member
    edited August 2014

    globalRegisters said: No need to be an a** and insult people over it.

    MCHPhil hasn't insulted anyone. He is trying to provide that we should not change our SSH port and call it "securing". We are trying the debate logically. You say that changing the port works for you. Why?

    How does changing a port make you server "certain to remain... safe and unharmed" (Webster's definition of security)?

  • edited August 2014

    .

  • Sorry if you feel I have insulted you, I am a firm believer in knowledge. Knowledge is power and spreading uncertain knowledge is not right. What I say is highlighted in many security publications, once again, don't take my word. Look it up.

    If you have locked SSH by IP (iptables) and are using SSH keys instead of password, what's the point of using a different port? Once again, as I suggested if you still feel the need. Use port knocking. Then 22 is not listening unless you hit 1029 and then 1543 and then 54003, then 22 is open for 3 seconds.

    Once you are using keys, who cares about the bruteforces? Install fail2ban if you're paranoid.

    You should never need to change SSH's port.

  • wat? y u edit post???

    :P

  • ^^ Because this was going nowhere.

  • I would never change my ssh port. SSH keys ftw.

  • Personally I change my SSH port to 143 ;)

  • Some v useful stuff here. Thanks

    @hwdsl2 said:
    The "best" approach is to use IPTables/Firewall to whitelist only those IPs and/or subnets that need access to your server, while rejecting all others.

    If the above is not possible, create a VPN to your server as nexmark mentioned, and whitelist only those IPs within the VPN subnet, rejecting all others.

    If the above is still not possible, you can first set up public-key authentication and then disallow password login for SSH (e.g. PermitRootLogin without-password). Also, set very strong passwords for root and other users. Use the AllowUsers directive to restrict who can login via SSH.

    An additional layer to "enhance" your VPS security can be done with:

    1 - First, move SSH out from the default port (22) to any port below 1024.

    2 - Using the IPTables "recent" module, if any host scans port 22 on your server (or other commonly attacked ports not in use, such as 23, 25, etc.), immediately add that IP to a blacklist, e.g. SSHSCAN.

    > -A INPUT -p tcp --dport 22 -m recent --set --name SSHSCAN -j DROP
    > 

    3 - On TOP of your IPTables INPUT chain, add a rule to drop ALL packets from blacklisted IPs for X seconds. Tweak X to your needs.

    > -A INPUT -m recent --update --name SSHSCAN --seconds X --hitcount 1 -j DROP
    > 

    4 - Each "recent" list will hold only 100 IPs by default. You can increase this limit (except for OpenVZ) by creating a file at /etc/modprobe.d/xt_recent.conf and reboot your server:

    > options xt_recent ip_pkt_list_tot=100 ip_list_tot=2000
    > 

    5 - If necessary, use the IPTables "psd" module to block port scan attempts (... except for OpenVZ).

    Disclaimer: All content in this post is for informational purposes only. I will not be liable for any errors or omissions, nor will I be liable for any losses or damages from the use of this information.

  • @MCHPhil said:
    Simple truth, use ssh keys and leave ssh on 22 is the best answer.

    Using keys moves the issue to your own local system. If someone else get (physically) access to the storage media where the keys are stored, you could assume the VPS is compromised.

    Keep also in mind that storage media have an ended life. It could be dead at tomorrow already.

  • KuJoeKuJoe Member, Host Rep
    edited September 2014

    What if you cannot use SSH keys, cannot whitelist IPs, and do not know who and from where users are logging in (such as a shared environment)? I still think that changing your SSH port is the number one method of preventing automated attacks where you are not specifically targeted.

    What is one possible negative impact that can happen when changing your SSH port?

    Changing your SSH port is not like changing all the doors in your house with walls, it's like changing all of the doors in your house to look like walls from the outside.

    Thanked by 2NanoG6 GreenHostBox
  • KuJoeKuJoe Member, Host Rep

    I just noticed this thread is for VPS security so my post is a little less valid. But I'll continue using a non-default port for SSH and sleep better at night because of it. :)

  • GreenHostBoxGreenHostBox Member
    edited September 2014

    @KuJoe said:
    I just noticed this thread is for VPS security so my post is a little less valid. But I'll continue using a non-default port for SSH and sleep better at night because of it. :)

    Amen. I have been using a non-default port for years now and haven't had a single issue. The first thing I do when receiving a new server is to change the default port. Of course changing your default port shouldn't be the only security measures you should take.

  • KuJoe said: What is one possible negative impact that can happen when changing your SSH port?

    If your Git client does not allow non-standard ports. Happened to a friend, he had to switch his server to use defaults.

  • RoestVrijStaal said: Keep also in mind that storage media have an ended life. It could be dead at tomorrow already.

    Most people backup their keys on something like a flash drive than can be readily purchased at most stores for under $10. I personally back them up onto my laptop and an external hard drive.

    GreenHostBox said: Amen. I have been using a non-default port for years now and haven't had a single issue. The first thing I do when receiving a new server is to change the default port. Of course changing your default port shouldn't be the only security measures you should take.

    Security by obscurity isn't something anybody should be following. I don't know why people keep repeating this, but it's not security, and it doesn't secure anything. Yes, I know it's not "the only step," but if you're going to post, please post the other steps.

    Personally, take Phil's recommendation. It takes 1 second to find your new SSH port using nmap, it takes even less time to telnet to it and find out that it's an SSH daemon.

    Thanked by 2Silvenga MCHPhil
  • I always protect my SSH private keys with a strong passphrase, and back them up in multiple places (but not in the cloud!).

    For advanced users, port scanning can be blocked using IPTables. Here are some other IPTables rules that I use (ignore the Asterisk section).

    Thanked by 1aglodek
  • @alexh said:
    It takes 1 second to find your new SSH port using nmap, it takes even less time to telnet to it and find out that it's an SSH daemon.

    Not if iptables are configured properly.

    Thanked by 1aglodek
  • Any words of wisdom on the maximum length of passwords

  • GreenHostBoxGreenHostBox Member
    edited September 2014

    @solarman said:
    Any words of wisdom on the maximum length of passwords

    http://www.passwordmeter.com/

    https://howsecureismypassword.net/

  • @MCHPhil said:
    ...what's the point of using a different port? Once again, as I suggested if you still feel the need. Use port knocking. Then 22 is not listening unless you hit 1029 and then 1543 and then 54003, then 22 is open for 3 seconds.

    Sorry if this is naive, but I don't understand your suggestion to use a series of different ports after repetitively telling people not to use a single different port. Isn't port knocking a more complex and extended way of using different ports? How is using three obscure ports rather than one not an example of "security by obscurity"?

    I also don't understand your fixation on '22'. If you've set out to use port knocking, why invariably end up on that number?

  • Actually actively scanning your logs is a must.

  • I think ppl changing the port number gives them a warm fuzzy feeling!

  • alexhalexh Member
    edited September 2014

    HostNun said: Sorry if this is naive, but I don't understand your suggestion to use a series of different ports after repetitively telling people not to use a single different port. Isn't port knocking a more complex and extended way of using different ports? How is using three obscure ports rather than one not an example of "security by obscurity"?

    Because all 3 ports appear to be closed, and the default SSH and SFTP port (22) would appear to be closed as well. It's not security by obscurity because from an external point of view, there aren't any open ports to attempt to connect to / brute force. In addition, the combination of 3 ports (1-65535) would be very difficult to brute force in correct sequence. The 3 ports configured appear closed, and must have connection attempts done in the correct sequence. This makes for a massive list of combinations (roughly 65535^3 = ~281 trillion) and makes BF attempts impractical. Even if this combination of ports were to be guessed/brute-forced, other security measures are still in place (key auth) and it'll still be very hard for an attacker to successfully guess log-in credentials.

    It's an extra layer of security, not obscurity.

    Thanked by 2MCHPhil aglodek
  • rskrsk Member, Patron Provider

    Silvenga said: Changing the default port is like replacing all the doors in your house with a wall. Doesn't improve security, just annoys you and other people when they try to enter.

    Then we have to go inside through the window? :O

    Thanked by 20xdragon Silvenga
  • ricardoricardo Member
    edited September 2014

    extra layer of security

    Indeed, that's pretty much what defines all security, various layers of complexity that reduce the chance of someone unauthorised gaining access. SSH key and whitelisting IP is enough for me, seems like there's enough complexity there in itself. 2^160 at least. Over a network, pretty damn hard to brute force.

  • HostNunHostNun Member
    edited September 2014

    @alexh said:

    Yeah, I understand that. Wasn't looking for an expository/technical answer, I was saying I didn't understand (conceptually) how port knocking is not a form of 'security by obscurity'.

    @alexh said:
    It's an extra layer of security, not obscurity.

    In what sense is an extra layer of security not an extra layer of obscurity? Requiring three different/unpredictable ports prior to 22 is exactly an extra layer of obscurity.

    @alexh said:
    It's not security by obscurity because from an external point of view, there aren't any open ports to attempt to connect to / brute force.

    Right, and that's because they are obscured from external points of view...

  • SilvengaSilvenga Member
    edited September 2014

    HostNun said: When is 'security' not reliant on obscurity

    Wikipedia has a rather good, unbiased page on the differences.

    Security through obscurity is discouraged... by standards bodies. A system relying on security through obscurity may have... actual security vulnerabilities, but its owners... believe that if the flaws are not known, then attackers will be unlikely to find them

    Security through obscurity has never achieved engineering acceptance as an approach to securing a system, as it contradicts the principle of simplicity.

    The United States National Institute of Standards and Technology (NIST) specifically recommends against security through obscurity in more than one document. Quoting from one, "System security should not depend on the secrecy of the implementation or its components."

    It is analogous to a homeowner leaving the rear door open, because it cannot be seen by a would-be burglar.

    Ironically this is what many Linux users do when they don't scan their systems for viruses - saying that there is a rarity of viruses for Linux and that only Windows need worry.

    Thanked by 3MCHPhil HostNun Pwner
  • alexhalexh Member
    edited September 2014

    HostNun said: Right, and that's because they are obscured from external points of view...

    You can change SSH to whatever port you like, but the port will still have to be open in the firewall. With Phil's suggestion, all ports appear closed from an external point of view. While I understand that you think this is simply obscuring the ports, the phrase, "Security through obscurity," actually implies, in my opinion, "Security solely through obscurity." Port knocking does not solely rely on obscurity, while changing the SSH port does, because that layer is easily vulnerable to becoming discovered (attacker discovers port number). As mentioned by another poster, security is about adding layers, and if you want to generalize, yes these layers consist of obscurity.

Sign In or Register to comment.