Before You Deploy Anything: My 7 Step VPS Setup Checklist

six · August 8

@insivimu said:
one-character passwords because bots are unlikely to try that and now I'm considering it.

Remove the password entirely - the bots wait for the password prompt and never get in!

JoshR · August 8

Personally. I think locking SSH down to a VPN Static IP is better than just leaving it wide open to all. Granted it does help changing off port 22 but will not stop if a bot is doing a port scan on ya.
Maybe @forest can chime in on some good practices

Edit: And the VPN machine has NO SSH access. Only Provider KVM to access the machine.

forest · August 8

@JoshR said: Maybe @forest can chime in on some good practices

I like using port-knocking to reduce attack surface area (pre-auth RCE against sshd is not an everyday occurrence for sure, but it's better to be safe than sorry). Wrote a guide about that: https://lowendtalk.com/discussion/219280/actually-effective-port-knocking-with-nftables-a-simple-guide#latest

MagdAlmuntaser · August 8

@forest said:

@JoshR said: Maybe @forest can chime in on some good practices

I like using port-knocking to reduce attack surface area (pre-auth RCE against sshd is not an everyday occurrence for sure, but it's better to be safe than sorry). Wrote a guide about that: https://lowendtalk.com/discussion/219280/actually-effective-port-knocking-with-nftables-a-simple-guide#latest

in my experience simply moving SSH away from port 22 has been surprisingly effective..
I've never had an attacker get past it or even get close.
Maybe I've just been lucky 🙂

forest · August 8

@MagdAlmuntaser said:

@forest said:

@JoshR said: Maybe @forest can chime in on some good practices

I like using port-knocking to reduce attack surface area (pre-auth RCE against sshd is not an everyday occurrence for sure, but it's better to be safe than sorry). Wrote a guide about that: https://lowendtalk.com/discussion/219280/actually-effective-port-knocking-with-nftables-a-simple-guide#latest

in my experience simply moving SSH away from port 22 has been surprisingly effective..
I've never had an attacker get past it or even get close.
Maybe I've just been lucky 🙂

I hope you keep it out of the ephemeral port range, and ideally don't use a high-port at all!

Mainfrezzer · August 8

@JoshR said:
Personally. I think locking SSH down to a VPN Static IP is better than just leaving it wide open to all. Granted it does help changing off port 22 but will not stop if a bot is doing a port scan on ya.
Maybe @forest can chime in on some good practices

Edit: And the VPN machine has NO SSH access. Only Provider KVM to access the machine.

You can also just drop traffic for it except for a specific IP or range. Just in case something might break and you get still access

Mainfrezzer · August 8

@MagdAlmuntaser said:

@forest said:

@JoshR said: Maybe @forest can chime in on some good practices

I like using port-knocking to reduce attack surface area (pre-auth RCE against sshd is not an everyday occurrence for sure, but it's better to be safe than sorry). Wrote a guide about that: https://lowendtalk.com/discussion/219280/actually-effective-port-knocking-with-nftables-a-simple-guide#latest

in my experience simply moving SSH away from port 22 has been surprisingly effective..
I've never had an attacker get past it or even get close.
Maybe I've just been lucky 🙂

It depends. If you move ssh away, censys for example get very upset and scan until they find SSH again. So running a tarpit or something usually does the trick to stopping them

forest · August 8

@Mainfrezzer said:

@MagdAlmuntaser said:

@forest said:

@JoshR said: Maybe @forest can chime in on some good practices

I like using port-knocking to reduce attack surface area (pre-auth RCE against sshd is not an everyday occurrence for sure, but it's better to be safe than sorry). Wrote a guide about that: https://lowendtalk.com/discussion/219280/actually-effective-port-knocking-with-nftables-a-simple-guide#latest

in my experience simply moving SSH away from port 22 has been surprisingly effective..
I've never had an attacker get past it or even get close.
Maybe I've just been lucky 🙂

It depends. If you move ssh away, censys for example get very upset and scan until they find SSH again. So running a tarpit or something usually does the trick to stopping them

I'd run endlessh if I wasn't concerned about using up even more sockets.

Tandoor · August 8

Im using this script mostly.

Debian & Ubuntu Server Setup & Hardening Script
https://github.com/buildplan/du_setup

atkl · August 8

@Mainfrezzer said:
Step 1:

Remove whatever horror template you got and install your own image(by any means necessary )with encryption.

How do you do this?

Any risk hosting company not happy about installing own image, against TOs, etc.?
Or as long as you keep same OS as in template it is fine (or they won't see it)?

mhpteam · August 8

actual step 1: turn off password authentication

Mainfrezzer · August 8

@atkl said:

@Mainfrezzer said:
Step 1:

Remove whatever horror template you got and install your own image(by any means necessary )with encryption.

How do you do this?

Any risk hosting company not happy about installing own image, against TOs, etc.?
Or as long as you keep same OS as in template it is fine (or they won't see it)?

Highly depends what kind of option you have available to you. If they dont offer custom images, you can install debian for example and then use netboot.xyz alongside grub-image boot to get it going. For uefi only, you can just plop their .efi in and make a boot menu entry.

No why would it be? i would question them why they would even know^^ They might not offer support for os related things but eh. who cares.

The only exception might be windows, if you try to get that on there. But i have never tried or had the desire to do so.

I also dont have any provider where i could check if they would care as all of them do allow custom iso

elliotc · August 8

hey, hermes, this is my ip and root password.

EvoSteven · August 8

@Mainfrezzer said:

@atkl said:

@Mainfrezzer said:
Step 1:

Remove whatever horror template you got and install your own image(by any means necessary )with encryption.

How do you do this?

Any risk hosting company not happy about installing own image, against TOs, etc.?
Or as long as you keep same OS as in template it is fine (or they won't see it)?

Highly depends what kind of option you have available to you. If they dont offer custom images, you can install debian for example and then use netboot.xyz alongside grub-image boot to get it going. For uefi only, you can just plop their .efi in and make a boot menu entry.

No why would it be? i would question them why they would even know^^ They might not offer support for os related things but eh. who cares.

The only exception might be windows, if you try to get that on there. But i have never tried or had the desire to do so.

I also dont have any provider where i could check if they would care as all of them do allow custom iso

If they partake in RAM ballooning, they probably aren't too happy with custom ISOs lol

Mainfrezzer · August 8

@EvoSteven said:

@Mainfrezzer said:

@atkl said:

@Mainfrezzer said:
Step 1:

Remove whatever horror template you got and install your own image(by any means necessary )with encryption.

How do you do this?

Any risk hosting company not happy about installing own image, against TOs, etc.?
Or as long as you keep same OS as in template it is fine (or they won't see it)?

Highly depends what kind of option you have available to you. If they dont offer custom images, you can install debian for example and then use netboot.xyz alongside grub-image boot to get it going. For uefi only, you can just plop their .efi in and make a boot menu entry.

No why would it be? i would question them why they would even know^^ They might not offer support for os related things but eh. who cares.

The only exception might be windows, if you try to get that on there. But i have never tried or had the desire to do so.

I also dont have any provider where i could check if they would care as all of them do allow custom iso

If they partake in RAM ballooning, they probably aren't too happy with custom ISOs lol

you can just blacklist the driver in the templates anyway. I think @forest is basically the "saleperson" for disabling it xD ive seen a load of posts

Edit: whats worth mentioning is disabling the guests agent abilities to execute code as well. Just dont install it.

forest · August 9

@Mainfrezzer said:

@EvoSteven said:

@Mainfrezzer said:

@atkl said:

@Mainfrezzer said:
Step 1:

Remove whatever horror template you got and install your own image(by any means necessary )with encryption.

How do you do this?

Any risk hosting company not happy about installing own image, against TOs, etc.?
Or as long as you keep same OS as in template it is fine (or they won't see it)?

Highly depends what kind of option you have available to you. If they dont offer custom images, you can install debian for example and then use netboot.xyz alongside grub-image boot to get it going. For uefi only, you can just plop their .efi in and make a boot menu entry.

No why would it be? i would question them why they would even know^^ They might not offer support for os related things but eh. who cares.

The only exception might be windows, if you try to get that on there. But i have never tried or had the desire to do so.

I also dont have any provider where i could check if they would care as all of them do allow custom iso

If they partake in RAM ballooning, they probably aren't too happy with custom ISOs lol

you can just blacklist the driver in the templates anyway. I think @forest is basically the "saleperson" for disabling it xD ive seen a load of posts

Edit: whats worth mentioning is disabling the guests agent abilities to execute code as well. Just dont install it.

Yep, among the first things I do on any server:

echo "install virtio_balloon /bin/false" > /etc/modprobe.d/stop-stealing-ram.conf
apt -y autopurge qemu-guest-agent
systemctl mask qemu-guest-agent # just in case it comes back

You can also restrict the guest agent's capabilities by adding allow-rpcs (for a whitelist) or block-rpcs (for a blacklist) to the config file. See here for a description of the RPC commands. Create /etc/qemu/qemu-ga.conf with something like:

[general]
block-rpcs=guest-file-open,guest-file-close,guest-file-read,guest-file-write,guest-file-seek,guest-file-flush,guest-set-user-password,guest-exec-status,guest-exec,guest-ssh-add-authorized-keys,guest-ssh-remove-authorized-keys

Then restart the agent. That will prevent the host from using the agent to access or modify your files, changing your login credentials, and executing commands. And you can make it even more secure by only whitelisting the commands you explicitly know you'll need. I guess I'll write a tutorials post about this since so many people just disable it.

TimboJones · August 9

@mhpteam said:
actual step 1: turn off password authentication

You should probably add your ssh keys first, eh?

querbeet · August 9

@forest said:
I hope you keep it out of the ephemeral port range, and ideally don't use a high-port at all!

@forest
You mean - privileged ports only up to 1024, because only they can be started by root, higher ones could be used to start a fake ssh service to harvest credentials?
Or what are your thoughts behind it?

forest · 12:38AM

@querbeet said:

@forest said:
I hope you keep it out of the ephemeral port range, and ideally don't use a high-port at all!

@forest
You mean - privileged ports only up to 1024, because only they can be started by root, higher ones could be used to start a fake ssh service to harvest credentials?
Or what are your thoughts behind it?

Not necessarily to harvest credentials (they couldn't do that without reading the mode 600, root:root-owned hosts key file), but exploiting the client is a possibility. And, of course, a lot of people will just click through the big scary "host key has changed!" warning, which would allow credential harvesting.

The other issue is if it's in the ephemeral port range net.ipv4.ip_local_port_range. If you set it in there, then any outgoing connection might happen to randomly use the port you chose for SSH as its source port, which would prevent SSH from starting up at all because it can't bind to the in-use port.

iamstrangemind · 7:01AM

Honestly I'm really amazed by the things I read here 🥺🥺🥺

Astro · 11:01AM

I reinstall using this script - https://github.com/bin456789/reinstall/blob/main/README.en.md

Plain vanilla images

Howdy, Stranger!

Categories

In this Discussion

Before You Deploy Anything: My 7 Step VPS Setup Checklist

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Before You Deploy Anything: My 7 Step VPS Setup Checklist

Comments