Hands-on lab – scanning kernel parameters with Lynis

Lynis is in the normal repositories for Ubuntu and in the EPEL repository for CentOS. It's always a few versions behind what you can get directly from the author's website, but for now, that's okay. When we get to Chapter 13, Vulnerability Scanning and Intrusion Detection, I'll show you how to get the newest version. Let's get started:

  1. Install Lynis from the repository by doing the following for Ubuntu:
sudo apt update
sudo apt install lynis

Do the following for CentOS 07:

sudo yum install lynis

Do the following for CentOS 08:

sudo dnf install lynis
  1. Scan the system by using the following command:
sudo lynis audit system
  1. When the scan completes, scroll back up to the [+] Kernel Hardening section of the output. Copy and paste the sysctl key pairs into a text file. Save it as secure_values.conf in your own home directory. The contents of the file should look something like this:
 - fs.protected_hardlinks (exp: 1) [ OK ]
- fs.protected_symlinks (exp: 1) [ OK ]
- fs.suid_dumpable (exp: 0) [ OK ]
- kernel.core_uses_pid (exp: 1) [ OK ]
- kernel.ctrl-alt-del (exp: 0) [ OK ]
- kernel.dmesg_restrict (exp: 1) [ DIFFERENT ]
- kernel.kptr_restrict (exp: 2) [ DIFFERENT ]
- kernel.randomize_va_space (exp: 2) [ OK ]
- kernel.sysrq (exp: 0) [ DIFFERENT ]
- kernel.yama.ptrace_scope (exp: 1 2 3) [ DIFFERENT ]
- net.ipv4.conf.all.accept_redirects (exp: 0) [ DIFFERENT ]
- net.ipv4.conf.all.accept_source_route (exp: 0) [ OK ]
. . .
. . .
  1. Use grep to send all of the DIFFERENT lines to a new file. Name it 60-secure_values.conf:
grep 'DIFFERENT' secure_values.conf > 60-secure_values.conf
  1. Edit the 60-secure_values.conf file to convert it into the sysctl configuration format. Set each parameter to the exp value that's currently within the pairs of parentheses. The finished product should look something like this:
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
kernel.yama.ptrace_scope = 1 2 3
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.log_martians = 1
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
  1. Copy the file to the /etc/sysctl.d directory:
sudo cp 60-secure_values.conf /etc/sysctl.d/
  1. Reboot the machine to read in the values from the new file:
sudo shutdown -r now
  1. Repeat step 2. Most items should now show up with their most secure values. However, you might see a few DIFFERENT lines come up. That's okay; just move the lines for those parameters into the main /etc/sysctl.conf file and reboot the machine again.
This trick didn't completely work with CentOS 8. No matter what I did, the net.ipv4.conf.all.forwarding item remained enabled. However, the other items came out okay.

That's the end of the lab—congratulations!

We've already talked about some of the items that we changed in this procedure. Here's a breakdown of the rest of them:

  • kernel.dmesg_restrict = 1: By default, any non-privileged user can run the dmesg command, which allows the user to view different types of kernel information. Some of this information could be sensitive, so we want to set this parameter to 1 so that only someone with root privileges can use dmesg.
  • kernel.kptr_restrict = 2: This setting prevents /proc from exposing kernel addresses in memory. Setting this to 0 completely disables it, while setting it to 1 prevents non-privileged users from seeing the address information. Setting it to 2, as we have here, prevents anyone from seeing address information, regardless of the person's privilege level. Note, though, that setting this to either 1 or 2 could prevent certain performance monitor programs, such as perf, from running. If you absolutely have to do performance monitoring, you might have to set this to 0. (That's not as bad as it might sound, because having the kernel.dmesg_restrict = 1 setting in place can help mitigate this issue.)
  • kernel.yama.ptrace_scope = 1 2 3: This places restrictions on the ptrace utility, which is a debugging program that the bad guys can also use. 1 restricts ptrace to only debugging parent processes. 2 means that only someone with root privileges can use ptrace, while 3 prevents anyone from tracing processes with ptrace.

In this section, you learned how to configure various kernel parameters to help lock down your system. Next, we'll lock things down even more by restricting who can view process information.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.221.85.33