[HN Gopher] The Reluctant Sysadmin's Guide to Securing a Linux S...
___________________________________________________________________
The Reluctant Sysadmin's Guide to Securing a Linux Server
Author : WallyFunk
Score : 115 points
Date : 2023-07-30 17:59 UTC (5 hours ago)
(HTM) web link (pboyd.io)
(TXT) w3m dump (pboyd.io)
| teddyh wrote:
| I would instead suggest the _official_ guide; the _Securing
| Debian Manual_ <https://www.debian.org/doc/manuals/securing-
| debian-manual/>
| nemo8551 wrote:
| It might be a bit corporate now but a few years back I found
| the security aspects of the redhat admin training to be decent
| enough for most folk.
| Sparkyte wrote:
| Meh, just do it like me get hardened image and container. Deploy
| stuff as a gold image without elevated permissions and or
| container. Then just make sure everything is behind a proxy or
| intelligent load balancer that restricts any crazy input.
|
| DONT OVERCOMPLICATE WORK
|
| Overcomplicating work means slower response times to solving
| problems.
| andai wrote:
| Wouldn't it be easier to use OpenBSD?
| rs_rs_rs_rs_rs wrote:
| Nice try.
| jeffbee wrote:
| It's weird to begin such an exercise without stating what the
| point of "the server" is supposed to be. Is it a ... web server?
| Interactive unix logins for developers? Mail relay? What does it
| do? This is the key point of the analysis because "securing" a
| server consists in making it incapable of doing anything not in
| the set of things it is meant to do. Notably, starting from this
| side of the problem can lead you away from "standard machine
| image". Starting with a kitchen-sink Linux distro like Ubuntu is
| _not_ the road to hardness.
| linuxdude314 wrote:
| It's really not weird, that's not how security works.
|
| What the application is doing is relevant to application
| security, but the whole point of securing the OS is to
| eliminate the necessity for "trusting" the application.
|
| When you are securing an operating system, you must assume the
| application that is exposed to the operating environment (be
| that the internet, local LAN, even simply user logged into the
| workstation in the case of a GUI or CLI app) is compromised.
|
| The primary goal of most security measures is preventing and
| detecting privilege escalation and lateral movement within the
| OS or network.
|
| There are a lot of best practices that apply in general to
| securing an operating system. If you want to dig deeper, one of
| the best resources for this information is provided by CIS
| (Center for Internet Security).
|
| CIS has hardening standards for most OS's yes even including
| Ubuntu. https://www.cisecurity.org/benchmark/ubuntu_linux
|
| These are standards that many security conscious organizations
| apply to their servers. The US government takes it a step
| further with DISA's STIGs.
|
| DISA STIG's are similar to CIS's benchmarks, but result in an
| even more locked down environment and place extreme
| restrictions on which crypto libraries are allowed to be used.
|
| In short, securing the OS is a standard best practice that all
| organizations should be doing. Unfortunately most startups lack
| engineers with the expertise in building custom linux images so
| a lot of folks are quite unfamiliar with hardening procedures.
|
| You should absolutely NOT use a non-standard OS because you
| think it will be more secure. It's a much better idea to use
| known industry standard security benchmarks on supported Linux
| distributions than trying to bake your own standard some non
| Debian/RHEL based bistro.
| doublepg23 wrote:
| IME the checklists and guides can be a useful resource but
| are mostly "cover your a$$" documentation, often time falling
| into cargo cult suggestions just to add more check-boxes.
| linuxdude314 wrote:
| You must be using the wrong 'checklists' (they aren't
| checklists, they are implementation guidelines). CIS
| benchmarks and DISA STIGs provide concrete actions that
| lead to a more secure system. Sure some of them might not
| apply specifically to your environment, but in general they
| are an excellent starting point.
|
| Some of the line items can be a bit arcane or not as
| relevant in cloud environments, etc... but that's a far cry
| from calling them CYA.
|
| Nothing cargo cult about enabling SE Linux, restricting
| access with IP tables, configuring AuditD and AIDE.
| generalizations wrote:
| > Nothing cargo cult about enabling SE Linux, restricting
| access with IP tables, configuring AuditD and AIDE.
|
| These are great ways to massively overcomplicate your
| system. Generally speaking, having encountered these
| tools, do not use them unless you're willing to dedicate
| about 2x the time you would otherwise spend administering
| the system.
| wnevets wrote:
| The second sentence
|
| > But I write software for the web
|
| I'm going to guess it's a web server but it's just a guess.
| jauntywundrkind wrote:
| Almost every server sits on the internet and has one or two
| (sometimes a couple more) ports open listening for their apps
| internet traffic.
|
| What the traffic is seems irrelevant to 99.99% of servers out
| there, imo. Yes there's some questions of what deployments look
| like and what capabilities operators have but those are details
| outside the general concern of being safely online. IMO.
| j45 wrote:
| 2nd and 3rd sentence
|
| " But I write software for the web, which means I'm never far
| from a server, and sometimes I'm the only one around.
|
| So even if I didn't want the job, I have it, and I need to take
| the security of these hosts seriously."
|
| Basic Linux server hardening is not a bad idea or skill to
| learn. Learning the basics manually help feed into
| understanding and using higher level solutions.
| linuxdude314 wrote:
| 100%
|
| As long as you are using Debian, RHEL, Ubuntu, or CentOS
| implementing a basic minimum security baseline is as simple
| as following the CIS or DISA STIG guides for your OS.
|
| There are plenty of scripts on GitHub that do this (AUDIT
| THEM FIRST), or you can even just use premade images from CIS
| in the cloud provider of your choice.
| DyslexicAtheist wrote:
| securing from what? this thing is pointless mid-90ies advise
| without a threat-model.
| thewanderer1983 wrote:
| This guy gets it. Your first question should be around your
| threat model. Are you protecting against random scans and
| script kiddies or the various APTs?
|
| Maybe then look at the MITRE ATT&CK framework, Cyber Kill Chain
| etc.
|
| I really hate to suggest them as it appears they have deviated
| in weirds ways from their original goal of protecting critical
| infrastructure from cybersecurity attacks, but CISA has many
| relevant documents.
| gazby wrote:
| 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".
| alsobrsp wrote:
| > 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.
| Sparkyte wrote:
| 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.
| fmitga wrote:
| When you say "no one needs vpn ssh access" vs "AWS ssh
| access", what is the difference between the two ?
| mrkstu wrote:
| 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 wrote:
| 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.
| ozim wrote:
| 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.
| strzibny wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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 wrote:
| Just don't set root:toor and you'll be alright. Keys are
| good, but passwords are good as well.
| jesprenj wrote:
| > You should not log in directly as root.
|
| Why not?
| mmsc wrote:
| I like the changing of the default umask, although it probably
| shouldn't be 077.
|
| Is acl needed over, say, chown?
| aesh2Xa1 wrote:
| No, there's no need to use `setfacl` over `chown/chmod` in the
| author's example.
|
| The reason that the author uses umask 077 and ACLs is, I think,
| just a mindset. By using 077, the file is restricted to only
| the owner, and the sysadmin does not need to think about group
| memberships. By extending read access using an ACL, this theme
| is continued; additional usernames will be appended as ACLs,
| but no group set of usernames needs to exist.
|
| A file named "alfred" would, presumably, only ever needed to be
| read by root and alfred, but that's just the narrow case for
| the author's scheme.
| chris_st wrote:
| Why not 077?
| [deleted]
| cutler wrote:
| If not 077 then what?
| linuxdude314 wrote:
| 077 is a bit too restrictive for a lot of workloads. 027 is
| recommended by CIS for servers and 022 for desktop.
|
| If you are sure you can use 077 without stuff breaking,
| awesome, but that's not always the case. Typically on systems
| using 077 you will find yourself using chmod a lot.
| politelemon wrote:
| > If you're on Windows, PuTTYgen should work
|
| If you're on Windows you can `wsl --install` and work with Linux
| (eg Ubuntu 2204).
|
| You can also install Git Bash which comes with ssh and ssh-
| keygen.
|
| Either way , same instructions.
| cjcampbell wrote:
| And on up-to-date versions, OpenSSH client and tools are
| available from powershell or cmd.
| pxc wrote:
| You can also install the Microsoft port of OpenSSH on older
| versions yourself.
| [deleted]
___________________________________________________________________
(page generated 2023-07-30 23:00 UTC)