91–100 of 298 posts
There should be a single configuration file (or set of files) that declaratively describes the whole state of the machine. That way the exact situation of the server can be reviewed by just looking at files, instead of trying to poke and prod at the machine to see what commands have been run over the last X weeks.
Earlier quoted context omitted.
I didn't notice that iptables-persistent actually saves the currently configured rules periodically. That's both kinda neat and a little scary, and I'm not entirely sure I see much value in persisting dynamic rules; it seems like it'd be easy to end up with a long chain of stale rules that way. Still worth knowing about the automatic persistence, though.
Surely as rules are deleted they disappear from the saved copy? Or is the issue that fail2ban et al don't remove stale rules?
I don't mean to sound flippant but why can't these "lock down your new box" tutorials just be a bash script? Shouldn't they be?
Sure! That way it's just a matter of doing su - curl -sS https://some.random.host/trust-me.sh | bash - What could go wrong?
(Because why in the world would anyone want to type in things by hand? Laziness for any repetetive manual labor is a greatest virtue of any good sysadmin.)
I'd be more curious to see a "My first 10 minutes on an Ubuntu desktop" version of the article.
Should take less than 10 minutes and be way faster to use :)
(I actually use openbox and fbpanel, but WindowMaker is just too great to forget about)
Assuming that services which shouldn't be accessible to the outside only listen to localhost not the network (e.g. MySQL on a LAMP stack), isn't that sufficient?
(Honest question, I don't have much experience with syadmin.)
Great tactical advice, but what a sad situation to be in. "Run this command, then run this command, then run this command ..." There should be a single configuration file (or set of files) that declaratively describes the whole state of the machine. That way the exact situation of the server can be reviewed by just looking at files, instead of trying to poke and prod at the machine to see what commands have been run…
That said, a script that pokes and prods the right places and reports a machine's 'security factor' and prompts improvements would be cool (and probably already exists).
> We don't even have a password for our root user. We'll want to select something random and complex. So you're taking something secure by default -- no password means no login allowed, and making it less secure. And if you have hundreds of these servers, you'll need to rotate them whenever someone on the team leaves. This is painful. Simple solution: leave root password blank, don't forget your sudo password. If you…
I do make sure later in the article that `/etc/ssh/sshd_config` does not allow root login:
PermitRootLogin no
sudo usermod -p '!' root
> We don't even have a password for our root user. We'll want to select something random and complex. So you're taking something secure by default -- no password means no login allowed, and making it less secure. And if you have hundreds of these servers, you'll need to rotate them whenever someone on the team leaves. This is painful. Simple solution: leave root password blank, don't forget your sudo password. If you…
It depends on your VPS, but many give a root password by default. I do make sure later in the article that `/etc/ssh/sshd_config` does not allow root login: PermitRootLogin no But you make a good point that a simple solution is just having no root password at all. If your VPS does have a root login by default, then I believe you can get rid of it with: sudo usermod -p '!' root The best part about sharing things like…
sudo passwd -lWhat's the reason for using a firewall? Assuming that services which shouldn't be accessible to the outside only listen to localhost not the network (e.g. MySQL on a LAMP stack), isn't that sufficient? (Honest question, I don't have much experience with syadmin.)
1. If an attacker gets unprivileged access it can slow them down (if properly configured) in getting new tools onto the system or adding a shell.
2. If a configuration error results in a service being started on a network accessible interface by accident the firewall gives you a bit of defence in depth protection against unauthorised connections to that server.
3. you can also use it for logging activity to feed into other systems.
Earlier quoted context omitted.
It depends on your VPS, but many give a root password by default. I do make sure later in the article that `/etc/ssh/sshd_config` does not allow root login: PermitRootLogin no But you make a good point that a simple solution is just having no root password at all. If your VPS does have a root login by default, then I believe you can get rid of it with: sudo usermod -p '!' root The best part about sharing things like…
sudo passwd -l