Howdy, Stranger!

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


VPS Security?
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?

StacyStacy Member
edited August 2014 in General

I was browsing this site and tried using the search feature but couldn't find a guide/tutorial on some good VPS security, I've seen quite a few threads here about peoples VPS's getting infected with malware that sends DDOS attacks (example IpTableX).

Some of those people have claimed they use SSH Key based authentication and still got infected.

Would be great if someone could share how to prevent being infected.

«13

Comments

  • KihiKihi Member

    Anti-DDOS:
    iptables & DDoS Deflate

    SSH:
    fail2ban.

    I would also suggest removing password authentication and just using public/private keys to authenticate via SSH.

    IPTables is very important too! Block everything and only open up the ports you really need.

  • Move SSH out from the default port (22)

    Thanked by 1aglodek
  • linuxthefishlinuxthefish Member
    edited August 2014

    Kihi said: IPTables is very important too! Block everything and only open up the ports you really need.

    Can't stress this enough, incoming AND outgoing.

  • Kihi said: Anti-DDOS: iptables & DDoS Deflate

    No.

    There's no such thing as software anti-DDoS.

    Thanked by 1Mark_R
  • @Ishaq said:
    There's no such thing as software anti-DDoS.

    Good to defend some kid's CC attack. But for some real DDOS, get ready to move to OVH and/or use Cloudflare.

    Change SSH to some random port, and shut login via password. Keep hackers (and yourself if you do not carry the key with yourself) away.

  • Try CloudFare :)

  • @alexpole said:
    Try CloudFare :)

    Only works for websites, what if OP has a game server and or team speak or some other service

  • @nexmark said:
    Only works for websites, what if OP has a game server and or team speak or some other service

    I am currently running a OpenVPN on a Ramnode DDOS protected vps for gaming.

  • @Stacy said:
    I am currently running a OpenVPN on a Ramnode DDOS protected vps for gaming.

    Yeah, That won't work for Cloudflare.
    I'm assuming console gaming

  • said: Some of those people have claimed they use SSH Key based authentication and still got infected.

    That's called an exploit and if your system isn't updated none of these recommendations will help. That said, using SSH keys while denying password access will efficiently prevent attacks.

    You goal here should be to make hacking your system as time consuming as possible and not to make your system impenetrable.

  • @nexmark said:
    Move SSH out from the default port (22)

    No. Do not. This is not security.

  • StacyStacy Member
    edited August 2014

    Here are the IPTables I am currently using.

    Can it be improved?

    Yes I also have fail2ban installed.

    http://pastebin.com/441DY50g

    Running:

    Fail2Ban
    SSH on non default port
    OpenVPN on 1194 and 2 public ips

  • @MCHPhil said:

    Erm, Yes it is?

    Most brute force tools usually scan at port 22, However they're some disadvantages like here


    The most securest way is to change the SSH Port, Allow SSH through only IP Addresses you trust


    SSH Key's work also.

  • SilvengaSilvenga Member
    edited August 2014

    nexmark said: Most brute force tools usually scan at port 22

    If you only allow from IP address you trust then why is changing the port helpful?

    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.

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

    My bad on that part

  • Changing SSH port to over 1024 creates a whole slew of other fun problems, security wise.

    Thanked by 1linuxthefish
  • @Stacy said:
    I was browsing this site and tried using the search feature but couldn't find a guide/tutorial on some good VPS security, I've seen quite a few threads here about peoples VPS's getting infected with malware that sends DDOS attacks (example IpTableX).

    Some of those people have claimed they use SSH Key based authentication and still got infected.

    Would be great if someone could share how to prevent being infected.

    You're fine if you're just using that VPS as a VPN

  • howardsl2howardsl2 Member
    edited August 2014

    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.

    Thanked by 2nexmark slashmpw
  • MCHPhilMCHPhil Member
    edited August 2014

    hwdsl2 said: 1 - First, be sure to move SSH out from the default port (22) to any port below 1024.

    See above, no. This is not security. Security through obscurity is not security.

    For SSH, fail2ban and disable password auth. If you are extremely paranoid limit by IP or two factor auth.

    Best bit I can give on the topic would be make sure you keep things updated. Security is tailored to each VM/etc.

  • howardsl2howardsl2 Member
    edited August 2014

    @MCHPhil said:

    I understand that this is security through obscurity. However, there are two additional measures as mentioned:

    1. Anyone scanning port 22 will be immediately blacklisted for X seconds.
    2. Port scanning is recognized and blocked with the IPTables "psd" module.

    This is analogous to: I have a house, I block off the front door and open a concealed "side door" for entry. Anyone knocking on the front door will immediately trigger an "alarm" and be denied access. Any attempt to search for that concealed "side door" will also be discovered and blocked. Am I secure with these measures?

    Thanked by 1nexmark
  • SilvengaSilvenga Member
    edited August 2014

    hwdsl2 said: Am I secure with these measures?

    No, you will never be secure with even those measures. For total security disable the eth0 interface.

    Really, our primary goal here is to prevent brute force attacks from succeeding. Just using SSH keys fixes that. Hell, using a strong password fixes this. We don't need these elaborate measures. The more complexity we add, the more of an attack surface we create (Murphy's law).

    Thanked by 2howardsl2 infected
  • Like everything in life, there is no "one" thing that will fix all security woes.
    And like most things in life, things are always layered.

    Yes, changing the ssh port as the one and only security measure is a big fail.
    However, changing the ssh port as part of a larger security system is a win.

  • hostnoobhostnoob Member
    edited August 2014

    What is the point closing ports with IPTables if nothing is listening on those ports anyway?

    Anyway I move SSH from port 22 to a high port too (as well as fail2ban), it stops a lot of brute force SSH attempts compared to running on port 22.

    It's not like changing ports automatically disables key-based auth or changes the password to "1234"

  • MCHPhilMCHPhil Member
    edited August 2014

    And this is why topics like this are useless lol. SECURITY THROUGH OBSCURITY IS NOT SECURITY.

    Use port knocking if you really are that paranoid.

    Changing SSH port causes more harm than good. If you are suggesting that, you know nothing about real security. Sorry it's harsh but needs to be said.

  • @MCHPhil said:

    Changing SSH port causes more harm than good. If you are suggesting that, you know nothing about real security. Sorry it's harsh but needs to be said.

    Alrighty then...

  • MCHPhilMCHPhil Member
    edited August 2014

    @globalRegisters said:
    Alrighty then...

    A simple google shows experts around the web say the same thing. No need to take my word on it. I'm just someone on a forum.

    https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

    Simple truth, use ssh keys and leave ssh on 22 is the best answer.

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

    Ok, thank you.

    Thanked by 1MCHPhil
  • apt-get update && apt-get upgrade

    If that doesn't work reinstall with latest debian

  • LeoLeo Member

    As long as you keep the ssh port bellow 1024, changing the sshd port will not impact your security. And it will reduce the chance for being targeted by a 0day sshd expoit, as most will go for the obvious targets.

  • MCHPhilMCHPhil Member
    edited August 2014

    @Leo said:
    As long as you keep the ssh port bellow 1024, changing the sshd port will not impact your security. And it will reduce the chance for being targeted by a 0day sshd expoit, as most will go for the obvious targets.

    Once again, this is not security. Not security by far. Use SSH keys and be done with the bs. Please read the link I pasted above to see why this is still a bad idea. (Multiple reasons, at that!)

    Doing BS like that leads to a false sense of security. That is also a bad thing.

Sign In or Register to comment.