News for hackers. Stuff that matters.

A comment on How to secure your new VPS: a step-by-step guide.

Re:How to secure your new VPS: a step-by-step guide by bigiain on Tuesday October 22, 2024 @01:23AM (#41911439)
I'd strongly suggest adding:

  echo "sudo ufw disable" | at now +5 minutes
as an emergency recovery mechanism before you first run

  sudo ufw enable
That way, if you've screwed up and locked yourself out with your new firewall rules, you can just wait 5 minutes and log back in (instead of paying for remote hands at your datacenter, or blowing away your vps and rebuilding from scratch).

Remember to re enable the firewall or stop the at job if everything works for you.

[ Parent | on HN ]
Re:How to secure your new VPS: a step-by-step guide by LetMeLogin on Tuesday October 22, 2024 @03:20AM (#41911977)
Totally, I'd rather run it directly via root not sudo to skip one more potential problem.
[ Parent | on HN ]
Re:How to secure your new VPS: a step-by-step guide by wink on Tuesday October 22, 2024 @05:25AM (#41912611)
And check if `at` works before that. Maybe I'm still scarred from that one default install years ago where it was broken, or even left out. Unlike cron I don't see it as a given these days.
[ Parent | on HN ]
Re:How to secure your new VPS: a step-by-step guide by woleium on Tuesday October 22, 2024 @05:32AM (#41912644)
you could always

(sleep 5m && sudo ufw disable) &

[ Parent | on HN ]
Re:How to secure your new VPS: a step-by-step guide by LinuxBender on Tuesday October 22, 2024 @12:24PM (#41915925)
Alternately ensure you have console access from the VPS providers web console / terminal. Then you can safely stop/start sshd, vpn daemons, bork up firewall rules, etc...

On some VPS providers you can also instantly reboot into a rescue full blown OS that runs in memory and then mount and chroot into whatever disks that need to be fixed.

[ Parent | on HN ]
Re:How to secure your new VPS: a step-by-step guide by bigiain on Tuesday October 22, 2024 @05:50PM (#41919087)
That's true, but I prefer to ingrain habits that'll work everywhere, instead of relying on stuff like vps console access which will work fine if you're working on your ec2 instance or your DO droplet, but will not work out so well when it's your home server or colo-ed box that you're trying to remotely secure from a hotel room while traveling.

But as @wink points out, these days you also need to ensure you've actually got at available - which is not guaranteed especially with cut down distros like Alpine.

[ Parent | on HN ]