Audit of access to linux files. Hard-hardening Linux
In today's article we will introduce you to Best Linux Security Auditing Utilities or as our English-speaking colleagues say - Hardening Linux. So, the topic of the article is checking the security level of Linux systems and assessing the correctness of configs from the point of view of information security. Of course, we will not only review the programs, but also give examples of their use.
In-house Linux security audit
System administrators, and even more so information security auditors, are often faced with the task of checking the security of a large number of hosts in a very short time. And of course, to solve these problems in the Enterprise segment there are specialized tools, for example, such as. I am sure that all of them - from open sources OpenVAS engine to commercial products like Nessus or Nexpose - are known to our readers. But this software is usually used to search for outdated and therefore vulnerable software and then launch patch management. In addition, not all security scanners take into account certain specific features of the built-in security mechanisms of Linux OS and other open source products. And last but not least, the price of the issue is important, because paid products can only be afforded by companies that allocate some budgets for this matter.
That’s why today we will talk about a specialized set of free utilities that can diagnose the current level of system security, assess potential risks, for example, “extra services” sticking out on the Internet, or an insecure default config, and in certain cases offer options for correcting problems found by the audit . Another advantage of using these tools is the ability to replicate typical farm test scripts from any number of Linux systems and create a documented test base in the form of logs and individual reports.
Practical aspects of Linux security auditing
If you look through the eyes of an auditor, the testing approach can be divided into two types.
First- this is compliance with the so-called compliance requirements, here the presence of mandatory security elements prescribed in any international standard or “best practice” is checked. A classic example is PCI DSS requirements for payment IT systems, SOX404, NIST-800 series,.
Second- This is a purely rational approach based on the question “What else can be done to strengthen security?” There are no mandatory requirements - only your knowledge, a clear head and skillful hands. For example, this is updating the kernel version and/or application packages, enabling, forcing SELinux, setting up the iptables firewall.
Everything that relates to the second approach is usually called a special term Linux hardening, which can also be defined as “actions aimed at strengthening the level of initial security of the OS (or software) primarily using standard means.”
Compliance with compliance requirements is usually checked in preparation for undergoing a mandatory audit such as PCI DSS or other certification audit. We will pay more attention to the Hardening component. All major vendors offer for their products Hardening Guidelines- guides containing tips and recommendations on how to strengthen security, taking into account standard security mechanisms and software specifics. So, Red Hat, Debian, Oracle, Cisco have similar guides.
Hardening is a term from the world of information security that refers to the process of ensuring the security of a system (program) by reducing its vulnerability and, as a rule, using exclusively standard utilities or protection mechanisms.
By the way, we already had an article about setting up Hardening options, but in that article we were talking specifically about setting up. We will first check our system using specialized utilities, that is, we will conduct a security audit, evaluate the current level of protection, and then add a security option there, if necessary. Well, or another option: if the server is already configured from a security point of view, our tools will be able to check this and, perhaps, suggest what else can be done.
Linux Security Auditing Tools
Lynis - auditing system hardening testing
Installation on macOS:
Initializing tests 
Test results from the System Tool and Boot & Services group 
Test results from the Kernel and Memory & Process auditing group 
Test results from the User and Group & Authentication group
Before an audit, it is always a good idea to check if a new version of Lynis is available:
If you want to put the name of the auditor who ran the test, just add the -auditor parameter
sudo lynis audit system - c - auditor Daddy |
At any stage of the Linux security audit, the verification process can be continued (Enter) or forcibly terminated (Ctrl+C). The results of the tests performed will be written to the Lynis log in the /var/log/lynis.log directory. Please note that the log file will be overwritten each time the utility is launched.
To test on an ongoing basis in automatic mode, you can assign the appropriate job to the Cron scheduler using the -cronjob switch. In this case, Lynis will launch according to the specified template (config) and will not display any unnecessary interactive messages, questions or warnings. All results will be saved to the log. For example, here is a script for launching the utility with default settings once a month:
#!/bin/sh AUDITOR = "automated" DATE = $ (date + % Y % m % d ) HOST = $(hostname) LOG_DIR = "/var/log/lynis" REPORT = ”$LOG_DIR/report - $(HOST). $(DATE)" DATA = ”$LOG_DIR / report - data - $ ( HOST ) . $(DATE). txt" cd /usr/local/lynis . /lynis - c –auditor “$ ( AUDITOR ) ” –cronjob > $ ( REPORT ) mv / var / log / lynis - report . dat$(DATA) #End |
Save this script to the /etc/cron.monthly/lynis directory. And don’t forget to add paths for saving logs (/usr/local/lynis and /var/log/lynis), otherwise it may not work correctly.
You can see a list of all commands available for calling:
Brief instructions for working with the utility:
man lynis |
Options for possible statuses based on the results of the check are limited to the following list: NONE, WEAK, DONE, FOUND, NOT_FOUND, OK, WARNING.
Example of status output Running individual tests in Lynis
In practice, it may be necessary to carry out only a few specific tests. For example, if your server performs only Mail Server or Apache functions. For this we can use the -tests parameter. The command syntax looks like this:
In addition, the functionality of Lynis is expanded by various add-ons, which you can add yourself, or you can add new ones to the existing directory.
All Warnings will be listed after the results. Each one begins with a warning text, then the test that generated it is indicated next to it in parentheses. The next line offers a solution to the problem, if of course it exists. In fact, the last line is a URL where you can view details and find additional recommendations on how to fix the problem.
Conclusion of recommendations on how to fix the problems found Profiles
Profiles that manage auditing are defined in files with a .prf extension located in the /etc/lynis directory. The default profile is called, predictably, default.prf. The developers do not recommend editing it directly: it is better to add any changes that you want to make to the audit to the custom.prf file, located in the same directory.
Create and edit a custom profile:
touch / etc / lynis / custom . prf sudo nano /etc/lynis/custom. prf |
In this file, you can define a list of tests that need to be excluded from the Lynis audit. For example:
- FILE-6310: partition check;
- HTTP-6622: nginx installation test;
- HTTP-6702: Apache installation test.
To exclude a specific test, use the skip-test directive and specify the test ID. For example, like this:
# Is nginx installed? skip - test = HTTP - 6622 # Is Apache installed? skip - test = HTTP - 6702 |
Hardening state assessment
Based on the results of all tests, at the end of each utility audit output (just below the suggestions section) you will find a section that will look something like this:
Lynis security scan details: Hardening index: 57 [############.........] Tests performed: 216 Plugins enabled: 0 |
Final assessment of hardening state
This result, expressed as a number, shows the number of tests passed and the system security index, that is hardening index- a final number used by Lynis to evaluate the overall security level of the server. And it is very important to remember that the safety index changes depending on the number of alerts fixed and Lynis recommendations implemented. Therefore, after fixing the problems found, a repeat security audit may show a completely different number!
All manipulations with the system in superuser mode require close attention and increased responsibility. Perform only those actions that you understand and are confident in. Don't forget to make backups and snapshots.
Lunar - a UNIX security auditing tool
Examples of running commands from the CLI:
View all Lunar launch options Running Lunar in security audit mode, i.e. without making changes to the system:
List of tests:
Running in patch mode, i.e. with changes to the system:
An example of running tests for the Apache web server
Nix Auditor - a CIS Audit made easier
Nix Auditor is another script for checking whether the security of Linux systems meets the requirements of the CIS indicator. Focused on RHEL, CentOS and other RPM distributions.
The developers claim the following advantages of Nix Auditor:
- scanning speed- you can conduct a basic OS scan in less than 120 seconds and immediately receive a report;
- verification accuracy- Nix Auditor has been tested on different versions of CentOS and Red Hat distributions;
- customizability- the source code with documentation for the program is on GitHub, so the code is easily customized in accordance with the type of OS and the set of system elements that need to be checked;
- ease of use- it is enough to make the starting script executable, and it is already ready for testing.
An example of executing commands to download the utility from the GitHub repository and then run the script:
git clone https: //github.com/XalfiE/Nix-Auditor.git cd Nix - Auditor chmod + x nixauditor . /nixauditor |
Example of information output after launching Nix Auditor
Loki - Simple IOC and Incident Response Scanner
The Loki utility is not exactly a classic tool for auditing Linux, but it is great for finding traces of hacking, which is, but partly can be attributed to the practice of auditing.
According to the developers, these are the capabilities Loki - Simple IOC and Incident Response Scanner gives us:
I. Four ways to detect hacking:
- filenames (regular expression matching the full path of the file);
- checking in accordance with Yara rules (search for compliance with Yara signatures based on the contents of files and process memory);
- checking and analyzing hashes (comparing scanned files with hashes (MD5, SHA-1, SHA-256) of known malicious files);
- C2 loopback check (compares process connection endpoints to C2 IOC).
II. Additional checks:
- Regin file system check (via -reginfs);
- checking for anomalies of system and user processes;
- scanning unpacked SWF;
- SAM dump check;
- DoublePulsar check - an attempt to identify a backdoor listening on ports 445/tcp and 3389/tcp.
Let's touch a little on how the program determines the fact of hacking. Typical indicators (Indicators of Compromise), indicating that the computer has been compromised (that is, hacked), can be:
- the appearance of malware (viruses, backdoors, cryptors, etc.) on the computer, as well as hacker utilities (for example, for exploring the network, exploiting vulnerabilities, collecting credentials);
- the appearance of unknown new executable and other files, even if they are not detected by the antivirus engine as malware code;
- abnormal network activity (connecting to remote hosts, opening ports for listening by unknown programs, etc.);
- abnormal activity on disk devices (I/O) and increased consumption of system resources (CPU, RAM, Swap).
Before starting the installation, you need to install several dependent packages. These are colorama (gives the coloring of lines in the console), psutil (a process checking utility) and, if not already installed, the Yara package.
So let's get started. Installation in (you must first install the Yara package, which is already installed by default in Kali Linux):
cd Loki / python2 loki - upgrader . py python2 loki . py-h |
Installation on Ubuntu/Debian:
sudo apt - get install yara python - yara python - pip python - setuptools python - dev git sudo pip2 install -- upgrade pip sudo pip2 install - U setuptools sudo pip2 install psutil netaddr pylzma colorama git clone https: //github.com/Neo23x0/Loki cd/home/download/Loki python2 loki - upgrader . py python2 loki . py-h |
Installation in BlackArch:
sudo pacman - S yara python2 - pip python2 - yara sudo pip2 install psutil netaddr pylzma colorama git clone https: //github.com/Neo23x0/Loki cd/home/download/Loki python2 loki - upgrader . py python2 loki . py-h |
Usage example
Some launch options:
optional arguments: H, --help show this help message and exit |
In this material we will get acquainted with the main utilities for Linux hardening. In Russian, this is called something like “checking the security level of Linux systems and assessing the correctness of configs from an information security point of view.” Of course, we will not only review the programs, but also give examples of their use.
Your own auditor, or your own security
Administrators, and even more so information security auditors, are often faced with the task of checking the security of a large number of hosts in a very short time. And of course, to solve these problems in the Enterprise segment there are specialized tools, for example, such as network security scanners. I am sure that all of them - from open sources OpenVAS engine to commercial products like Nessus or Nexpose - are known to our readers. However, this software is usually used to look for outdated and therefore vulnerable software and then run patch management. In addition, not all scanners take into account some specific features of the built-in protection mechanisms of Linux and other open source products. And last but not least, the price of the issue is important, because commercial products can only be afforded by companies that allocate budgets for this business.
That is why today we will talk about a specialized set of freely distributed utilities that can diagnose the current level of system security, assess potential risks, for example, “extra services” sticking out on the Internet, or an insecure default config, and even offer options for correcting the flaws found. Another advantage of using these tools is the ability to replicate standard farm test scenarios from any number of Linux systems and create a documented test base in the form of logs and individual reports.
Practical aspects of security audit
If you look through the eyes of an auditor, the testing approach can be divided into two types.
First- this is compliance with the so-called compliance requirements, here the presence of mandatory security elements prescribed in any international standard or “best practice” is checked. A classic example is PCI DSS requirements for payment IT systems, SOX404, NIST-800 series,.
Second- This is a purely rational approach based on the question “What else can be done to strengthen security?” There are no mandatory requirements - only your knowledge, a clear head and skillful hands. For example, this is updating the kernel version and/or application packages, enabling, forcing, setting up a firewall.
Everything that relates to the second approach is usually called a special term Hardening, which can also be defined as “actions aimed at enhancing the level of initial security of the operating system (or program) primarily using standard means.”
Compliance with compliance requirements is usually checked in preparation for undergoing a mandatory audit such as PCI DSS or other certification audit. We will pay more attention to the Hardening component. All major developers offer for their products Hardening Guidelines- guides containing tips and recommendations on how to strengthen security, taking into account standard security mechanisms and the specifics of the software. So, Red Hat, Debian, Oracle, Cisco have similar guides.
INFO
Hardening is a term from the world of information security that refers to the process of ensuring the security of a system (program) by reducing its vulnerability and, as a rule, using only standard utilities or protection mechanisms.
Sudo apt-get update sudo apt-get install lynis
And for RPM-oriented distributions (after adding the appropriate repositories):
Yum install linus -y
Installation on macOS:
$ brew search lynis $ brew install lynis
To start Lynis, you only need to specify at least one key. For example, to run all available tests, you should specify the -c (check all) switch:
# Typical set of tests sudo lynis audit system # Full set of tests sudo lynis audit system -c # Scanning a remote host audit system remote 
Before an audit, it is always a good idea to check if a new version of Lynis is available:
Lynis update info && lynis update check
The Lynis utility, in addition to the standard one, has one more mode - unprivileged launch:
Lynis audit --pentest
If you want to put the name of the auditor who started the testing, just add the -auditor parameter
Sudo lynis audit system -c -auditor Daddy
At any stage of the audit, the verification process can be continued (Enter) or forcibly terminated (Ctrl+C). The results of the tests performed will be written to the Lynis log in /var/log/lynis.log . Please note that the log will be overwritten each time the utility is launched.
To test on a systematic basis in automatic mode, you can assign the appropriate job to the Cron scheduler using the -cronjob switch. In this case, the utility will be launched according to the specified template (config) and will not display any interactive messages, questions or warnings. All results will be saved in the log. For example, here is a script for launching the utility with the default config once a month:
#!/bin/sh AUDITOR="automated" DATE=$(date +%Y%m%d) HOST=$(hostname) LOG_DIR="/var/log/lynis" REPORT="$LOG_DIR/report-$( HOST).$(DATE)" DATA="$LOG_DIR/report-data-$(HOST).$(DATE).txt" cd /usr/local/lynis ./lynis -c –auditor "$(AUDITOR)" –cronjob > $(REPORT) mv /var/log/lynis-report.dat $(DATA) # End
Save this script to the /etc/cron.monthly/lynis directory. And don’t forget to add paths for saving logs (/usr/local/lynis and /var/log/lynis), otherwise it may not work correctly.
You can see a list of all commands available for calling:
Lynis show commands 
Those who are especially curious can look at the settings from the default config:
Lynis show settings
Brief instructions on how to use the utility:
Man lynis
Options for possible statuses based on the results of the check are limited to the following list: NONE, WEAK, DONE, FOUND, NOT_FOUND, OK, WARNING.
Running individual tests in Lynis
In practice, it may be necessary to carry out only a few tests. For example, if your server performs only Mail Server or Apache functions. For this we can use the -tests parameter. The command syntax is as follows:
Lynis -tests "Test-IDs"
If you find it difficult to understand due to the large number of test identifiers, then you can use the group parameter -test-category . With this option, Lynis only runs test IDs that fall into a specific category. For example, we plan to run firewall and kernel tests:
./lynis -tests-category "firewalls kernel" 
In addition, the functionality of Lynis is expanded by various plugins, which you can add yourself, or you can add new ones to the existing directory.
Suggestions for correction
All Warnings will be listed after the results. Each one begins with a warning text, then the test that generated it is indicated next to it in parentheses. The next line suggests a solution to the problem, if one exists. In fact, the last line is a URL where you can view details and find additional recommendations on how to fix the problem.
Profiles
Profiles that manage auditing are defined in files with the extension .prf, located in the /etc/lynis directory. The default profile is named predictably: default.prf . The developers do not recommend editing it directly: it is better to add any changes that you want to make to the audit to the custom.prf file, located in the same directory.
Continuation is available only to members
Option 1. Join the “site” community to read all materials on the site
Membership in the community within the specified period will give you access to ALL Hacker materials, increase your personal cumulative discount and allow you to accumulate a professional Xakep Score rating!
The issue of IT infrastructure security is of great relevance for any type of business. Be it a group of companies with an extensive branch network or an online store with 1-2 sellers.
For each server, the main purpose of which is to provide hosting for websites, there is an acute issue of ensuring the protection of user data.
Our company offers a server security audit service.
This service includes:
— Analysis of software versions installed on the server for compliance with current, up-to-date versions that are free of known security problems. As a rule, for web servers, the relevance of the following software versions is important: mail server, web server, caching web server (if present), programming language interpreter (in which sites are written, for example, PHP), ftp server, web applications (to provide simplified access to certain server settings and work with data);
— Analysis of web server settings and related software settings for compliance with basic security requirements;
— Analysis of operating system settings. At this point, we analyze the main points related to the potential for an attacker to seize control of the server. As a rule, the settings of the ssh server and options for working with hard drives are examined;
— Analysis of access rights to main files and folders of the system containing confidential information. As a rule, this item involves inspecting the main system folders, server control panel files, directories with backup copies, and rights to user folders;
— On a server that is suspected of being compromised and can be used by attackers to carry out malicious activities, our specialists will take the necessary measures to clean it of malware and prevent a recurrence of this situation;
Most of the enterprise and multi-component systems such as SAP , Oracle DB use in their platform an operating system based on Linux . In view of this, they receive such close attention from IT auditors. Today in this article we will present to your attention several free tools presented in the form of scripts and using standard OS mechanisms to provide an express audit of the security configuration.
The system commands and scripts described below that are used for express auditing of security options of Linux OS systems are based on security verification recommendations published by the ISACA community in the UNIX/LINUX Operating System Security Audit/Assurance Program manual.
1.Account verification
1.1 List all users
The list of users is stored in the /etc/passwdfile file. To get a list of users you can use the following script:
- bin/bash
- # userslistinthesystem.sh
- # count and Lists existing “real” users in the system.
- echo “[*] Existing users (sorted alphabetically):”
- grep '/bin/bash' /etc/passwd | grep -v 'root' | cut -f1
- -d':' | sort
- echo -n “[*] Number of real users found: “
- grep '/bin/bash' /etc/passwd | grep -v 'root' | wc -l
During the audit, it is necessary to check the list of blocked and unblocked users ( accountName ). The following command will work for this:
- #!/bin/bash
- # passwd –s accountName
1.3 View statistics for all users
- #!/bin/bash
- #!/bin/bash
- # ac -d
- #!/bin/bash
- # ac user
The psacct or acct system applications run in the background and monitor the activity of each user on the system, as well as the resources they consume. To check user activity in the system, run the following script:
- #!/usr/bin/envksh
- last -Fa|awk ‘
- /wtmp begins/ ( next; )
- /still logged in/ ( next; )
- $0 == reboot ( next; )
- NF > 0 (
- if(NR > 1)
- printf("
”); - printf("User:t%s
”, $1); #user - printf (“Start:t%s %s %s %s
”, $3, $4, $5, $6); - if($9 == “down”)
- printf("End:tshutdown
”); - printf (“End:t%s %s %s %s
”, $9, $10, $11, $12); - if(substr ($NF, 1, 1) == “(“)
- t = $NF;
- h = “localhost”;
- t = $(NF-1);
- h = $NF;
- gsub(“[()]”, “”, t);
- printf("Time On:t%s
”, t); - printf("Remote Host:t%s
”, h);
2. Checking the password policy
2.1 Accounts with a blank password
During the audit, it is necessary to make sure that there are no or blocked accounts in the system that allow you to log into the system without entering a password. This rule can be checked with the command:
# cat /etc/shadow | awk -F: ($2==””)(print $1)’
2.2 Checking password complexity
During the audit, it is necessary to check the password complexity settings to reduce the risk of brute force (brute force) or dictionary attacks on the password. To set this rule on your system, you must use Plug-in Authentication Modules (PAMs).
The auditor can check the corresponding setting in the configuration file:
# vi /etc/pam.d/system-auth
2.3 Checking the password expiration date
During the audit, you need to check the password expiration setting. To check the password expiration date you need to use the command change.
This command displays detailed information about the password expiration date, as well as the date it was last changed.
The following command is used to view information about the “age” of passwords:
#chage -l username
To change the password expiration period for a specific user, you can use the commands below:
#chage -M 60 username
#chage -M 60 -m 7 -W 7 userName
Options (to set the password expiration date):
-M – maximum validity period in days.
-m – minimum validity period in days.
-W – warning setting in days.
2.4 Using duplicate passwords
System authorization settings must comply with the password policy. The file containing the password history is located in /etc/security/opaswd.
To check, you must complete the following steps:
for RHEL: open the file ‘/etc/pam.d/system-auth‘:
# vi /etc/pam.d/system-auth
for Ubuntu/Debian/Linux Mint: open the file ‘/etc/pam.d/common-password‘:
# vi /etc/pam.d/common-password
Add the following line to the 'auth' section:
auth sufficient pam_unix.so likeauthnullok
To prevent the last six passwords from being used, add the following line:
Password sufficient pam_unix.so nullokuse_authtok md5 shadow remember=6
After executing the command, the system will store a history of the previous six passwords, and if any user tries to update the password using any of the last six, he will receive an error message.
3. Secure connection settings
The Telnet and Rlogin protocols for remote connection to the system are very old and vulnerable, due to the transmission of the password over the network in unencrypted form. For a remote and secure connection, a secure protocol must be used Secure Shell (SSH).
The auditor also needs to ensure that the option root login
disabled, default SSH port changed, remote access allowed only for specific authorized users. The settings being checked are in the SSH configuration file:
1. # vi /etc/ssh/sshd_config
3.1 Login as superuser (root login)
During the audit, the auditor should check the prohibition of remote login with root superuser rights.
# PermitRootLogin = yes
3.2 Checking the SSH login service account
During the audit, the auditor must check the service account with a passwordless SSH login value. Typically, system administrators use this feature for programmed backups, file transfers, and running scripts remotely.
Check your sshd_config settings (/etc/ssh/sshd_config) are correct one last time.
# PermitRootLogin without-password
# RSAAuthentication = yes
# PubkeyAuthentication = yes
3.3 Checking access lists in DenyHosts and Fail2ban
During the audit, you need to check the access list settings DenyHosts
And Fail2ban
. These are scripts used to monitor and analyze SSH access logs and protect against password brute force attacks.
Features of DenyHosts:
- saves and tracks logs from a file /var/log/secure , noting all successful and unsuccessful login attempts, and filters them.
- monitors failed login attempts
- sends email notification of blocked hosts and suspicious login attempts
- Saves and tracks logs from files /var/log/secure And /var/log/auth.log , /var/log/pwdfail
- highly customizable and multi-threaded
- monitors log files on a regular basis
4. Checking system logs
During the audit, you need to make sure that the SysLog daemon is running, and all significant events occurring in the system are recorded in the event logs. During the audit, it is also necessary to ensure that the policy for storing event logs takes into account the requirements of current legislation and security policies
4.1 Event logs in Linux:
/var/log/auth.log – log of the authorization system (logins and authentication mechanism).
/var/log/dpkg.log – log of installation/removal of packages using dpkg.
/var/log/yum.log – log of installation/removal of packages using yum.
/var/log/faillog – log of failed login attempts and their maximum number for each account.
/var/log/kern.log – kernel log (detailed log of messages from the Linux kernel).
/var/log/maillog or /var/log/mail.log – mail server log.
/var/log/wtmp – login log (registration time and duration of work of all system users).
/var/run/utmp – information about users currently registered in the system.
/var/log/lastlog – records of previous logins.
/var/log/boot – information that is logged during system boot
5. Protect system files
5.1 Protecting the GRUB bootloader
To protect the GRUB boot loader, the administrator must use password encryption in MD5 format :
# grub-md5-crypt
After executing the command, the administrator needs to open the file /boot/grub/menu.lst or /boot/grub/grub.conf and add MD5 password:
# vi /boot/grub/menu.lst
# vi /boot/grub/grub.conf
The newly created MD5 password can be added to the GRUB configuration file.
5.2 Protecting the boot directory /BOOT
During the audit, it is necessary to check the status of the directory /boot since the system kernel and related files are located in the directory /boot. You must ensure that this directory has read-only access to prevent unauthorized changes to important files on the system. To check, open the /etc/fstab file and check the configuration:
The file must contain the line:
LABEL=/boot /boot ext2 defaults,ro 1 2
5.3 Checking open ports and active connections
The following script can be used to check the services running on the system:
#!/bin/bash
if (($(ps -ef | grep -v grep | grep $service | wc -l) > 0))
then
echo “$service is running!!!”
else
/etc/init.d/$service start
Fi
View network connections
# netstat -anop
or
# lsof -i(lsof -ni)
or
# iptraf
Listening ports
Using the Netstat command, you can view all open ports and their associated commands. Example script:
#netstat–tulpn
A script for port scanning is:
scan() (
if [[ -z $1 || -z $2 ]]; then
echo “Usage: $0
return
fi
local host=$1
local ports=()
case $2 in
*-*)
IFS=- read start end<<< “$2”
for ((port=start; port<= end; port++)); do
ports+=($port)
done
;;
*,*)
IFS=, read -ra ports<<< “$2”
;; *)
ports+=($2) ;;
esac
for port in “$(ports[@])”; do
alarm 1 “echo >/dev/tcp/$host/$port” &&
echo “port $port is open” ||
echo “port $port is closed”
done
}
Firewall iptables
During the audit, you need to check the configuration of the Linux firewall to prevent unauthorized access. To control traffic, rules must be created in iptables that will filter incoming, outgoing and forwarded packets based on the IP address and TCP/UDP port number.
# iptables -n -L -v --line-numbers
ICMP/broadcast requests
During the audit, it is necessary to verify that systems are configured to ignore ping and broadcast requests. To do this, make sure that in the file “/etc/sysctl.conf” the following lines have been added:
# ignore ICMP requests:
net.ipv4.icmp_echo_ignore_all = 1
# ignore broadcast requests:
net.ipv4.icmp_echo_ignore_broadcasts = 1
5.4 Checking installed updates
The latest updates must be installed on the system:
# yum updates
# yum check-update
6. Checking automatically executed CRON jobs
The auditor must check who is allowed and not allowed to perform cron jobs. Access to cron is controlled using files /etc/cron.allow And /etc/cron.deny.
# echo ALL >>/etc/cron.deny
7. Testing SELINUX Forced Security Mode
During the audit it is important to check the status SELinux
. This mechanism must be enabled in the system.
There are three modes SELinux
:
- Enforcing: The SELinux policy is forced. SELinux denies access based on SELinux policy rules.
- Permissive: The SELinux policy is not enforced. SELinux does not deny access, but denials are logged as actions that would be denied if the policy was switched to enforcement mode.
- Disabled: SELinux is disabled. Only discrete DAC rules are used.
During an audit, you can use the following script to check the status of SELinux or use the system-configselinux, getenforce, or sestatus commands:
ENABLED=`cat /selinux/enforce`
if [ “$ENABLED” == 1 ]; then
echo “SELinux is enabled, disable? (yes/no):”
read disable
if [ $disable == “yes” ]; then
echo “disabling selinux”
setforce 0
fi
fi
LBSA script to check basic security options
LBSA (Linux Basic Security Audit script) is a basic script for auditing the security configuration of Linux systems. The script must be run from the command line with privileges root or ideally run on a regular schedule using a cron scheduler to systematically check for configuration changes.
The purpose of this script is to quickly audit security settings and upload a report describing possible parameters that can be changed to provide a higher degree of security. If there are no recommendations for any option, the script simply displays one line with processing of the check, and the final decision always remains with the administrator. Before running the scan, the developers strongly recommend that you read the manual and study the recommended sections for more information.
In the current edition (Version 1.0.49), the script scans the following options:
- vulnerabilities in account settings
- vulnerabilities in SSH settings
- vulnerabilities in temporary directories and directories of the file system loaded into RAM (for example, in /tmp, /var/tmp /dev/)
- file permissions, state of system directories
- rconfiguration of DRBD and Hearbeat services
The script is quite large, so we did not put it on the page.