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 to Secure a Linux Server
21–30 of 108 posts
Re: How to Secure a Linux Server
#22Is using gmail to send mails from your server a good idea?
Re: How to Secure a Linux Server
#23The CIS benchmarks are a great place to start for hardening a system ( https://www.cisecurity.org/cis-benchmarks/ ) and there's also OpenSCAP gives you a nice way to scan systems for compliance against a set of hardening rules ( https://www.open-scap.org/ ).
Thanks. What about using the hardened images they provide? https://www.cisecurity.org/cis-hardened-image-list/
Re: How to Secure a Linux Server
#24The CIS benchmarks are a great place to start for hardening a system ( https://www.cisecurity.org/cis-benchmarks/ ) and there's also OpenSCAP gives you a nice way to scan systems for compliance against a set of hardening rules ( https://www.open-scap.org/ ).
Yes! This guide is good for securing maybe a personal server, but any business systems should use a server hardening standard that has industry mindshare (CIS, STIG, etc.) I can speak from personal experience that QSAs give you a very skeptical look when you say "our security standard is homebrewed."
Meh, QSAs check boxes. In my experience they are not very technically capable. Some are, of course. Most are not.
Re: How to Secure a Linux Server
#25This 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…
setting umask 027 is mentioned by the CIS as well
Re: How to Secure a Linux Server
#26The CIS benchmarks are a great place to start for hardening a system ( https://www.cisecurity.org/cis-benchmarks/ ) and there's also OpenSCAP gives you a nice way to scan systems for compliance against a set of hardening rules ( https://www.open-scap.org/ ).
Thanks. What about using the hardened images they provide? https://www.cisecurity.org/cis-hardened-image-list/
Their hardened images are fine but there are two issues. First, you'll need to test / dev with them as full implementations of CIS can break things (though not as bad as the STIGs) and, IIRC, they charge extra for you to use their images on public clouds.
Re: How to Secure a Linux Server
#27This 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…
Arch: https://wiki.archlinux.org/index.php/Security CentOS: https://wiki.centos.org/HowTos/OS_Protection (limited) Debian: https://www.debian.org/doc/manuals/securing-debian-howto/ind... (old) Fedora: https://docs.fedoraproject.org/en-US/Fedora/19/html/Security... (old) Mageia: https://wiki.mageia.org/en/Msec (limited) Oracle Linux: https://docs.oracle.com/cd/E52668_01/E54670/html/index.html Red Hat: https://access.r…
Should there be any difference between RedHat and CentOS?
Re: How to Secure a Linux Server
#28Earlier quoted context omitted.
Arch: https://wiki.archlinux.org/index.php/Security CentOS: https://wiki.centos.org/HowTos/OS_Protection (limited) Debian: https://www.debian.org/doc/manuals/securing-debian-howto/ind... (old) Fedora: https://docs.fedoraproject.org/en-US/Fedora/19/html/Security... (old) Mageia: https://wiki.mageia.org/en/Msec (limited) Oracle Linux: https://docs.oracle.com/cd/E52668_01/E54670/html/index.html Red Hat: https://access.r…
Should there be any difference between RedHat and CentOS?
I would use the Red Hat guide because it is comprehensive.
Re: How to Secure a Linux Server
#29This 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…
> “One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though.
No, one shouldn’t. To be even more pedantic, verifying a signature under PKI is, in fact, “decrypting with the public key” something (a hash, usually) that was encrypted with the private key. When considering the complete set of PKI operations (encryption + signing), both the public and private parts of a key pair are used in both their enciphering and deciphering capacities.
Re: How to Secure a Linux Server
#30It would also be proper to disable non root access to /proc among other things. You can do that by simply mounting with hidepid=2 or adding it to fstab.
Why? Disabling access to /proc will disable a huge number of useful features, such as the ability of a process to monitor and manage its memory usage, to debug itself, and so forth.