7 ms·

There's a reason guides like this are a dime a dozen - there is no way to generalize server configuration this broadly. But as long as we're doing it anyway -

by gazby 3y ago

There's a reason guides like this are a dime a dozen - there is no way to generalize server configuration this broadly. But as long as we're doing it anyway - the only thing that locking the root account gets you is assurance that if you ever bork the user you created in this guide (or sudo functionality as a whole) you'll have no way to recover without booting into another environment. Perhaps one ought not take sysadmin advice from a blog post with a first sentence that reads "I’m not a sysadmin, and I don’t want to be".

usr1106 3y ago
> the only thing that locking the root account gets you is assurance that if you ever bork the user you created in this guide (or sudo functionality as a whole) you'll have no way to recover without booting into another environment. That's not a unique or novel insight. For the case your system gets borked (either by yourself, your hardware or your cloud provider) you need a plan in advance: 1. How can I access the data the server has or how much of it can I afford to lose? 2. How do I get a replacement running within a time window acceptable for my usage? The answers will be very different depending on your use case. But how you locked the root user has very little impact on them. Booting into another environment is always one option in my plan so locking the root user doesn't frighten me.
backendanon 3y ago
"the only thing that locking the root account gets you is assurance that if you ever bork the user you created in this guide (or sudo functionality as a whole) you'll have no way to recover without booting into another environment." As a dev, I say that's a good thing. I've administered my own systems for decades and helped in small startups where we had no full time admin so definitely not new to administering Linux.
Sparkyte 3y ago
The biggest rules about securing things is don't be in security. Just do your diligence to put your hosts several layers away from public access and make all images and containers hardened with no elevated permissions. Sure vulnerabilities will still exist... if the only thing that can access the container is through a narrowed proxy you are not going get some dumb levels of attacks on your systems. AWS allows you to ssh into your hosts from within AWS. You just manage that security. NO ONE needs public ssh access, no one needs vpn ssh access just AWS ssh access. DON'T OVER COMPLICATE THINGS! I agree with you. I am not gonna say don't follow a system engineers advice. I say follow everyone's advice but pick out the things that seem most reasonable. If it is extra work then you're doing it wrong, simplify everything so that the time spent on resolving issues is faster. Faster resolution means faster security fixes.
- gettodachoppa 3y ago
  I'm also a "non-sysadmin" like the OP. I'm much more casual than you are: 1. Install LTS server with a sudo admin user and complex password (yes, password, not key. I still end up using keys for backup automation because it's easier.) 2. apt install fail2ban. Don't even need to configure it: its default configuration will auto-ban any IPs trying to brute-force SSH. 3. apt install unattended-upgrades (nowadays installed by default) I'd like to see anyone hack that. You mention running containers with no elevated permissions. I've taken a liking to Docker because, in addition to its many benefits, it lets me separate MY processes from those of the OS. It's just so simple when I can identify the server's running services with "docker ps". I'm curious, when was the last time a Docker exploit could escape the container and modify the host? I read it happened in the early days of Docker but is that still a risk? They would need to: a) exploit a bug in a service you're relying on (eg nginx), b) use the former bug to exploit a bug in Docker, c) defeat the Linux kernel's namespace/cgroup isolation. Is that a realistic threat in 2023?
  - Sparkyte 3y ago
    Always a threat if the a host container is on the same HV. You get all sorts of bleed bugs identified every other year. Literally the last one was a few months ago I think. None as large scale as when it first happened.
- fmitga 3y ago
  When you say "no one needs vpn ssh access" vs "AWS ssh access", what is the difference between the two ?
  - mrkstu 3y ago
    As mentioned you then just need to lock down AWS, rather than AWS AND outside access to servers via VPN. Lessen the attack surface.
  - Sparkyte 3y ago
    The console in AWS allows access within its system. There is no point increasing the access area to the hosts. More surface area the easier it is to be penetrated by ssh vulnerabilities. You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. What you want to do is avoid fault, improve tolerance, but extend liability to the provider.
yjftsjthsd-h 3y ago
> the only thing that locking the root account gets you is assurance that if you ever bork the user you created in this guide (or sudo functionality as a whole) you'll have no way to recover without booting into another environment. As opposed to borking the root user and being equally locked out? Assuming your sudo config is a "configure it once and then leave it forever" deal - which seems common IME - I can't see any way it would be different. (Mind, this cuts both ways - once you force only key-based SSH, I generally don't see a problem with direct root access either.)
- vbezhenar 3y ago
  Just don't set root:toor and you'll be alright. Keys are good, but passwords are good as well.
alsobrsp 3y ago
> Perhaps one ought not take sysadmin advice from a blog post with a first sentence that reads "I’m not a sysadmin, and I don’t want to be". That's just perfect.
- at_a_remove 3y ago
  That sounds reasonable, from a "passion" angle. However, I would like to hear what someone who dislikes sysadmining but must anyway has to say. Why? A different perspective. I know some sysadmins who "left the car up on blocks," as in, they couldn't stop tweaking and fixing and so on, and they love that, and that's great. Someone who is forced into the job, however, is communicating to me what I would expect to be the most necessary tasks. Maybe I also am in a similar place and would like to get on with the rest of my job. And in an Agile world, programmers get pushed into sysadmining ... at least, in some versions of Agile to which I have been subjected.
  - AdieuToLogic 3y ago
    > However, I would like to hear what someone who dislikes sysadmining but must anyway has to say. ... Someone who is forced into the job ... The only way a job is done consistently well is by those whom want to do that job well consistently. HTH EDIT: added missing "do" verb.
    - Zarathustra30 3y ago
      Too bad. Sometimes a business can't or won't hire a real sysadmin. The people forced into the job need guides just as much.
      - AdieuToLogic 3y ago
        > Too bad. > Sometimes a business can't or won't hire a real sysadmin. The people forced into the job need guides just as much. I was making a more general statement regarding people having to do tasks they don't want to do, even if they have the skills to do them. Which makes resources helpful to "people forced into the job" rather difficult to produce. How can one make a guide to assist people to be successful in something they don't want to do in the first place?
ozim 3y ago
You shouldn’t need root, you should have another person with admin rights as a backup plan. It is a vm so if you do something that would break sudo or all your users you should have a vm snapshot at your fingertips ready to restore from AWS interface. Even if you are running bare metal you should setup snapshots first but nowadays no one runs bare metal web servers it is still som hyper visor with bunch of vm-s that are easy to backup restore or just delete and create fresh.
- windexh8er 3y ago
  > You shouldn’t need root, you should have another person with admin rights as a backup plan. What? I am the only admin on about a dozen machines. I'm not outsourcing that to a friend. That trust model is much more flawed than separation of duties and permissions segmentation as part of my administration routine.
  - ozim 3y ago
    Your manager or company owner should have admin account then, he should not use it for anything besides disaster recovery. If you are single person shop that is your choice, have a root account or whatever you feel like having.
  - vladvasiliu 3y ago
    What happens if you get hit by a bus, or become otherwise incapacitated?
    - windexh8er 3y ago
      That's what a dead man's switch is for. All of my credentials will be shared after a specified period of time.
strzibny 3y ago
That's not true. It's not obvious what user you have that could do sudo. Thus it does improve security. I advice the same in my book (Deployment from Scratch) and I suggest that for both the host system and containers. There is little cost to not primarily using root.
- AdieuToLogic 3y ago
  >> But as long as we're doing it anyway - the only thing that locking the root account gets you is assurance that if you ever bork the user you created in this guide (or sudo functionality as a whole) you'll have no way to recover without booting into another environment. > That's not true. It's not obvious what user you have that could do sudo. Thus it does improve security. I advice the same in my book (Deployment from Scratch) and I suggest that for both the host system and containers. There is little cost to not primarily using root. It is true. To ensure root cannot be used when ssh'ing into a server, set "PermitRootLogin" to "no" in sshd_config (as mentioned in the OP). Locking out root entirely, as further mentioned in the OP and suggested by your comment, does nothing to increase security regarding remote penetration attacks. Furthermore, should a non-root account which has sudo privileges be compromised, an argument could be made that having a functional root account with its own password accessible only locally and not enabling sudo is a more secure approach. Either way, having a root account which can only be used locally ensures there is a recovery workflow should one be needed, as the GP enumerates.
  - deleted 3y ago
    [deleted]

by gazby 3y ago

usr1106 3y ago

> the only thing that locking the root account gets you is assurance that if you ever bork the user you created in this guide (or sudo functionality as a whole) you'll have no way to recover without booting into another environment. That's not a unique or novel insight. For the case your system gets borked (either by yourself, your hardware or your cloud provider) you need a plan in advance: 1. How can I access the data the server has or how much of it can I afford to lose? 2. How do I get a replacement running within a time window acceptable for my usage? The answers will be very different depending on your use case. But how you locked the root user has very little impact on them. Booting into another environment is always one option in my plan so locking the root user doesn't frighten me.

backendanon 3y ago

"the only thing that locking the root account gets you is assurance that if you ever bork the user you created in this guide (or sudo functionality as a whole) you'll have no way to recover without booting into another environment." As a dev, I say that's a good thing. I've administered my own systems for decades and helped in small startups where we had no full time admin so definitely not new to administering Linux.

Sparkyte 3y ago

The biggest rules about securing things is don't be in security. Just do your diligence to put your hosts several layers away from public access and make all images and containers hardened with no elevated permissions. Sure vulnerabilities will still exist... if the only thing that can access the container is through a narrowed proxy you are not going get some dumb levels of attacks on your systems. AWS allows you to ssh into your hosts from within AWS. You just manage that security. NO ONE needs public ssh access, no one needs vpn ssh access just AWS ssh access. DON'T OVER COMPLICATE THINGS! I agree with you. I am not gonna say don't follow a system engineers advice. I say follow everyone's advice but pick out the things that seem most reasonable. If it is extra work then you're doing it wrong, simplify everything so that the time spent on resolving issues is faster. Faster resolution means faster security fixes.

gettodachoppa 3y ago
I'm also a "non-sysadmin" like the OP. I'm much more casual than you are: 1. Install LTS server with a sudo admin user and complex password (yes, password, not key. I still end up using keys for backup automation because it's easier.) 2. apt install fail2ban. Don't even need to configure it: its default configuration will auto-ban any IPs trying to brute-force SSH. 3. apt install unattended-upgrades (nowadays installed by default) I'd like to see anyone hack that. You mention running containers with no elevated permissions. I've taken a liking to Docker because, in addition to its many benefits, it lets me separate MY processes from those of the OS. It's just so simple when I can identify the server's running services with "docker ps". I'm curious, when was the last time a Docker exploit could escape the container and modify the host? I read it happened in the early days of Docker but is that still a risk? They would need to: a) exploit a bug in a service you're relying on (eg nginx), b) use the former bug to exploit a bug in Docker, c) defeat the Linux kernel's namespace/cgroup isolation. Is that a realistic threat in 2023?
- Sparkyte 3y ago
  Always a threat if the a host container is on the same HV. You get all sorts of bleed bugs identified every other year. Literally the last one was a few months ago I think. None as large scale as when it first happened.
fmitga 3y ago
When you say "no one needs vpn ssh access" vs "AWS ssh access", what is the difference between the two ?
- mrkstu 3y ago
  As mentioned you then just need to lock down AWS, rather than AWS AND outside access to servers via VPN. Lessen the attack surface.
- Sparkyte 3y ago
  The console in AWS allows access within its system. There is no point increasing the access area to the hosts. More surface area the easier it is to be penetrated by ssh vulnerabilities. You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. What you want to do is avoid fault, improve tolerance, but extend liability to the provider.

yjftsjthsd-h 3y ago

> the only thing that locking the root account gets you is assurance that if you ever bork the user you created in this guide (or sudo functionality as a whole) you'll have no way to recover without booting into another environment. As opposed to borking the root user and being equally locked out? Assuming your sudo config is a "configure it once and then leave it forever" deal - which seems common IME - I can't see any way it would be different. (Mind, this cuts both ways - once you force only key-based SSH, I generally don't see a problem with direct root access either.)

vbezhenar 3y ago
Just don't set root:toor and you'll be alright. Keys are good, but passwords are good as well.

alsobrsp 3y ago

> Perhaps one ought not take sysadmin advice from a blog post with a first sentence that reads "I’m not a sysadmin, and I don’t want to be". That's just perfect.

at_a_remove 3y ago
That sounds reasonable, from a "passion" angle. However, I would like to hear what someone who dislikes sysadmining but must anyway has to say. Why? A different perspective. I know some sysadmins who "left the car up on blocks," as in, they couldn't stop tweaking and fixing and so on, and they love that, and that's great. Someone who is forced into the job, however, is communicating to me what I would expect to be the most necessary tasks. Maybe I also am in a similar place and would like to get on with the rest of my job. And in an Agile world, programmers get pushed into sysadmining ... at least, in some versions of Agile to which I have been subjected.
- AdieuToLogic 3y ago
  > However, I would like to hear what someone who dislikes sysadmining but must anyway has to say. ... Someone who is forced into the job ... The only way a job is done consistently well is by those whom want to do that job well consistently. HTH EDIT: added missing "do" verb.
  - Zarathustra30 3y ago
    Too bad. Sometimes a business can't or won't hire a real sysadmin. The people forced into the job need guides just as much.
    - AdieuToLogic 3y ago
      > Too bad. > Sometimes a business can't or won't hire a real sysadmin. The people forced into the job need guides just as much. I was making a more general statement regarding people having to do tasks they don't want to do, even if they have the skills to do them. Which makes resources helpful to "people forced into the job" rather difficult to produce. How can one make a guide to assist people to be successful in something they don't want to do in the first place?

ozim 3y ago

You shouldn’t need root, you should have another person with admin rights as a backup plan. It is a vm so if you do something that would break sudo or all your users you should have a vm snapshot at your fingertips ready to restore from AWS interface. Even if you are running bare metal you should setup snapshots first but nowadays no one runs bare metal web servers it is still som hyper visor with bunch of vm-s that are easy to backup restore or just delete and create fresh.

windexh8er 3y ago
> You shouldn’t need root, you should have another person with admin rights as a backup plan. What? I am the only admin on about a dozen machines. I'm not outsourcing that to a friend. That trust model is much more flawed than separation of duties and permissions segmentation as part of my administration routine.
- ozim 3y ago
  Your manager or company owner should have admin account then, he should not use it for anything besides disaster recovery. If you are single person shop that is your choice, have a root account or whatever you feel like having.
- vladvasiliu 3y ago
  What happens if you get hit by a bus, or become otherwise incapacitated?
  - windexh8er 3y ago
    That's what a dead man's switch is for. All of my credentials will be shared after a specified period of time.

strzibny 3y ago

That's not true. It's not obvious what user you have that could do sudo. Thus it does improve security. I advice the same in my book (Deployment from Scratch) and I suggest that for both the host system and containers. There is little cost to not primarily using root.

AdieuToLogic 3y ago
>> But as long as we're doing it anyway - the only thing that locking the root account gets you is assurance that if you ever bork the user you created in this guide (or sudo functionality as a whole) you'll have no way to recover without booting into another environment. > That's not true. It's not obvious what user you have that could do sudo. Thus it does improve security. I advice the same in my book (Deployment from Scratch) and I suggest that for both the host system and containers. There is little cost to not primarily using root. It is true. To ensure root cannot be used when ssh'ing into a server, set "PermitRootLogin" to "no" in sshd_config (as mentioned in the OP). Locking out root entirely, as further mentioned in the OP and suggested by your comment, does nothing to increase security regarding remote penetration attacks. Furthermore, should a non-root account which has sudo privileges be compromised, an argument could be made that having a functional root account with its own password accessible only locally and not enabling sudo is a more secure approach. Either way, having a root account which can only be used locally ensures there is a recovery workflow should one be needed, as the GP enumerates.
- deleted 3y ago
  [deleted]