Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Secure a Linux Server

github.com

Post reply on HN
Print view View original

91–100 of 108 posts

Re: How to Secure a Linux Server

#91

Post by imthenachoman »

ThePhysicist wrote: post #21

I would not recommend using “ufw” for configuring the firewall on a production server (as it’s not easily composable and lacks configurability for more complex rules). I can recommend “ferm” instead as it allows you to compose multiple config files (important for automation e.g. when using Ansible) and allows describing more complex rules that e.g. involve policies.

How would you define a production server? Do you mean in the context of a home server or a server used by a large company? The guide is intended for a server for home use. I hope anyone securing a large corporate server is not using information on GitHub. If they are then the company has far bigger problems than security.

I think for home use, ufw is probably good enough. I've been using it for 3+ years and it's worked out okay for me okay.

I have not heard of ferm but I will check it out. Thanks!

Re: How to Secure a Linux Server

#93

Post by imthenachoman »

Fnoord wrote: post #12
pettycashstash2 wrote: post #2

I didn’t know you could add google Authenticator to your server. Thank you for this write up.

You don't have to use a closed source TOTP client such as Google's. There's RedHat's FreeOTP and there's another open source one called antOTP. You can find them on F-Droid as well. There have been TOTP PAM modules for ages (these work on a Linux client and Linux server via e.g. SSH). You can even add YubiKey to PAM. Same for BSD Auth and macOS.

When I was researching, literally every article I read mentioned Google'S TOTP PAM module. I can't even find any other ones that have active development. Do you know of any? Would love to use another one if it works with my iOS authenticator app.

Re: How to Secure a Linux Server

#94

Post by imthenachoman »

tyingq wrote: post #3
pettycashstash2 wrote: post #2

I didn’t know you could add google Authenticator to your server. Thank you for this write up.

I'm surprised Authy doesn't have a pam module: https://github.com/authy/authy-ssh/issues/53

Authy's mobile app should work with Google's TOTP PAM module.

Re: How to Secure a Linux Server

#96

Post by imthenachoman »

peterwwillis wrote: post #19
snuxoll wrote: post #11

Nothing about SELinux or AppArmor? While these are enabled by default on some of the big distros I think a basic guide on managing and troubleshooting would be beneficial.

Yeah, the best impact would come from using SELinux, AppArmor, and GRSec. Everything else is just tweaking defaults, which for up-to-date software probably isn't going to impact your security much at all.

I don't disagree but you gotta start with the basics. SELinux can be rather advanced/complex and probably warrants its own guide. I still have to learn it better before I try to write a guide on it.

Re: How to Secure a Linux Server

#97

Post by imthenachoman »

supakeen wrote: post #8

No mention of shipping off logs to another place? It's probably good to assume someone will gain access and make after-the-fact forensics a primary concern as well. Something a lot of hardening guides seem to skip!

Good idea. I need to figure out how to work that in into the guide. I added to the to-do list. Thanks!

Re: How to Secure a Linux Server

#98

Post by imthenachoman »

wodny wrote: post #17

This guide contains (at least) inaccurate statements. It's oversimplifying and omitting important things while putting emphasis on some exotic details where defaults would be sane enough. "One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though. "Identity is verified by encrypting and decrypting data that both the client and server kno…

This is great feedback! Thank you so much.

I simplified things that would be too heavy to get into. The guide is not intended to teach everything about security -- that would be too much. The goal is to cover enough to give the reader a high level understanding. Once they have a basic understanding they can research more if they desire.

Can you tell me some of the "exotic details where defaults would be sane enough"? I can amend the guide.

Are you saying a public key can be used to decrypt data it encrypted? Or are you saying a public key could also be used to decrypt data that the private key encrypted?

You mention "server room". This guide is intended for a person running a simple server in their home. Hopefully SAs securing a large scale environment are not using information from GitHub. :/

I made some other updates to the guides that I hope address your other concerns?

Regarding your distribution agnostic comment, I do not see value in distribution specific guides on hardening. Sans a few edge distributions, most distributions are similar enough that the hardening steps are the same. It is okay to look for distribution specific documentation on how to install the distribution but it hurts the cause having distribution specific hardening guides.

Also, I want more folks to use Linux. Most distributions are so similar there is no value in having so many distribution specific guides -- all it does is create unnecessary confusion and steer potential prospective users away from Linux.

Re: How to Secure a Linux Server

#99

Post by wodny »

imthenachoman wrote: post #98
wodny wrote: post #17

This guide contains (at least) inaccurate statements. It's oversimplifying and omitting important things while putting emphasis on some exotic details where defaults would be sane enough. "One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though. "Identity is verified by encrypting and decrypting data that both the client and server kno…

This is great feedback! Thank you so much. I simplified things that would be too heavy to get into. The guide is not intended to teach everything about security -- that would be too much. The goal is to cover enough to give the reader a high level understanding. Once they have a basic understanding they can research more if they desire. Can you tell me some of the "exotic details where defaults would be sane enough"?…

> The guide is not intended to teach everything about security -- that would be too much.

On the other hand, the objectives list contains: "this guide will attempt to cover as many of them as possible". Despite that, it still misses basic security rules.

"A desktop class computer [...] That I want to be able to SSH to remotely from unknown computers and unknown locations (i.e. a friend's house)."

SSH from an unknown computer? Also see my original comment about what is missing in description of a situation when connecting to your server from a new system.

> Are you saying a public key can be used to decrypt data it encrypted? Or are you saying a public key could also be used to decrypt data that the private key encrypted?

See my discussion with derefr in this thread.

> You mention "server room". This guide is intended for a person running a simple server in their home.

The "server room" here means you are sitting next to your server and can connect point-to-point. It doesn't mean you need a backup diesel generator.

And if it is really about a home server, concerns like "make sure nobody is listening" don't make sense.

> I made some other updates to the guides that I hope address your other concerns?

I've seen you accepted pull requests of some contributors that fixed the basics for you. Because they were generated right after discussion in this thread they concern things discussed here.

> Also, I want more folks to use Linux. Most distributions are so similar there is no value in having so many distribution specific guides -- all it does is create unnecessary confusion and steer potential prospective users away from Linux.

How many (which) distros have you managed as a professional sysadmin to state that with high confidence?

I'm quite sure that a beginner will just choose Ubuntu and proceed to something like https://linuxjourney.com/. If someone becomes more than a hobbyist one will hopefully go and read something from a trusted source, written by sysadmins with a good grasp of contemporary cryptography involved.

Re: How to Secure a Linux Server

#100

Post by z3t4 »

imthenachoman wrote: post #82
z3t4 wrote: post #15

Dont forget about namespaces which lets you isolate apps. and Apparmor to restrict file and network access. And also chroot and setuid to drop privileges and change the root path. And unix sockets / named pipes. Instead of letting your daemons access the whole network have them listen on a unix socket. And scan your own network, both from the outside and inside.

I am not familiar with namespaces in this context? Can you please point me in the right direction? I have added AppArmor to my to-do list. I know what chroot and setuid are, not sure what to mention about them in the guide? And I will look into unix sockets. Can you recommend any good network scanning tools? I've been on the hunt for a good one.

I think the most useful for sysadmins are the network namespace that lets you put an app into it's own network, so it can not see the rest of the network. Container technology makes use of namespaces to create lightweight VM/containers. See man namespaces, lxc

nmap is a popular tool for network scanning. I've also found tcpdump to be useful for looking at network traffic.

setuid and chroot are useful for programmers, so once the app is up and running, it can chroot into a data-dir and drop root privileges using setuid to a unprivileged user. As a sysadmin you can also start the app from within a chroot and run it as a unprivileged user which is preferably. Most (free)BSD tutorials go though setting up a chroot jail, it's not as common in Linux.

Containers, VM's, and chroot will not stop a very determined attacker, but the more restrictions the harder it will get.

Security is applied in layers: First you want to prevent people from the outside. Access is most often gained through exploiting some service/daemon/app running on the server. So the app should have as little privileges as possible. System access is often then gained by exploiting another app (so you want all apps to be locked down, not just the network facing ones), like getting Apache to run curl, that sends a internal request to another app that has a known vulnerability and happens to run as root. (nobody thought that app not accessible from the outside needed to get patched). Once the attacker is inside the server, you also want to prevent access to other computers in the network.

Post reply on HN