Assessing your Linux Server against industry recognised security standards ensures it is security-hardened and resilient to attack.
The aim of server hardening is to reduce the attack surface of the server. The attack surface is all the different points where an attacker can attempt to access or damage the server and the information stored on it. This includes all network interfaces and installed software. By removing software that is not needed and by configuring the remaining software to maximise security, the attack surface can be reduced. As a result, an attacker has fewer opportunities to compromise the server.
Our Linux Server Build Review is a ‘white-box’ assessment that will provide a rigorous benchmark of the operating system configuration and then compare the results against industry-recognised security hardening standards giving you a clear action plan to improve your server security.
Methodology
Using a combination of automated compliance tools and manual inspection our consultant will perform an in-depth review to assess your server’s resilience to attack.
We start with the hardening guidance from the Center for Internet Security (CIS) and any security frameworks that apply (such as PCI-DSS or ISO 27001). We also include additional configuration checks during the build review that have been derived from our own experience of Linux-based server environments and specific attack vectors that have been identified by our consultants during recent penetration tests. This ensures you can not only demonstrate compliance with relevant standards but also benefit from our real world experience at the leading edge of security testing to protect your systems from new and emerging threats.
Specifically, the following areas of the Linux server are covered by this review:
Anti-Virus Protection
If anti-virus/anti-malware software is installed, we will confirm it is running correctly and automatically applying updates. Some security frameworks, such as PCI-DSS, require anti-virus software to be installed and operational on all in-scope systems. We will also check the anti-virus software cannot be disabled by unauthorised users and that any errors or warnings are logged correctly.
Password Policy
We will confirm that the password policy enforced by the operating system configuration (and any Pluggable Authentication Modules) matches your Information Security Policy. This includes password complexity, history and length.
We will also recommend any changes based on the risk profile of the server. We will check the password policy when logging into shell sessions and password policies used with tools such as SSH and SUDO.
Account Lockout Policy
Repeated failed login attempts should result in a user account becoming locked in order to protect the server from brute-force attacks, where many passwords are tested using an automated script. We will confirm that the account lockout policy defined in your Information Security Policy is correctly implemented on the server, that it is fit for purpose and compliant with any security frameworks or standards that apply.
SSH Configuration
SSH is a secure, encrypted replacement for common login services such as telnet, ftp, rlogin, rsh, and rcp. Using SSH prevents session hijacking and sniffing of sensitive data off the network. If remote login is not required on the server, the SSH daemon should be removed. We will validate the SSH configuration and SSH public and private key security to ensure it is secure and provides the required functionality so that only authorised team members are able to connect to the server.
User Accounts
We will validate that the configuration for user accounts on the system and account creation policies align with best practice. This includes the default settings for the security of user created files, automatic locking of idle shell sessions and the display of warning banners.
We will validate that default user accounts supplied with the operating system have been disabled or had their default passwords changed. We will also confirm that system accounts used for managing applications and system services are not enabled for interactive shell login. Accounts that have not been used for some time should be locked automatically and accounts for staff that have left should be disabled.
Services
One of the best ways to protect the system against undiscovered vulnerabilities is to disable all services that are not required for normal system operation. This prevents the exploitation of vulnerabilities discovered in the future. A service cannot be exploited if it is not enabled. We will check that all required services (such as NTP and Mail Transfer Agents) are securely configured to prevent them being leveraged in an attack.
Accurate, time synchronised system logs are vital for intrusion detection and forensic analysis after a suspected breach. The logging service (rsyslog or equivalent) must be correctly configured to ensure security logs are captured and forwarded to any central logging repository.
Permitted User Logins
Server systems are not general use computers, so there is usually a small group of people who have a valid reason to login to the server in order to perform specific tasks. We will confirm the list of permitted user logins is up to date and appropriate.
SUID File Configuration
SUID is a special file setting which means an executable runs as the user which owns the file – not the user who started the process. A program or script which is owned by the root user will always execute with the permissions of the root user regardless of who runs the program. This is a powerful ability that can be abused to compromise the system if not correctly secured. We will identify the files on the server with the SUID permission and check who has permission to execute them. We will also validate who has permission to use the setuid utility which is used to grant SUID status to new files.
World-Writeable Files
The contents of world-writable files can be changed by any user on the system. The existence of a world-writable file usually indicates a mistake has been made in the design or implementation of a script – which could be leveraged in an attack to change the behaviour of the script to compromise the server. We will locate any world-writable files on the system and present them to you in the final report.
World-writable directories are a place where any user or process on the system can create a file – for example temporary files placed in the /TMP folder. Setting the sticky bit on world writable directories prevents users from deleting or renaming files in that directory that are not owned by them. We will confirm that the sticky bit is set on all world-writable directories.
World-Readable Files
The contents of world-readable files can be viewed by any user on the system. Where this has happened by accident (perhaps because the umask for the user account has not be correctly set) information can leak which is useful to an attacker. We will identify any world-readable files on the system in order to check if that setting is correct for each file.
Vulnerability Assessment
We will perform a detailed scan of the server to detect any vulnerabilities present due to missing software security patches or the misconfiguration of services running on the system.
We will confirm that kernel level security settings, such as activating Address Space Layout Randomisation, are turned on and configured correctly.
Firewall
The firewall controls the ability of processes on the server to receive traffic from the network and to transmit data to external systems on the local network or the internet. We will confirm the firewall is active with appropriate Deny-All default rules. We will then list all active rules on the firewall to confirm that each rule is still required and provides the minimum level of access in order for the associated processes to function correctly. Correctly configured local firewalls on each server are important to prevent lateral movement of attackers and malware within your network should they manage to gain a foothold on another device.
Network Port Scan
A network port scan will identify which network ports have processes actively waiting for a connection from the network. This can identify any services which are running but are not actually needed as well as firewall rules that may need to be adjusted in order to restrict access to certain ports and services.
Software Updates
It is important that software updates and security patches are applied promptly to resolve vulnerabilities and to comply with your Patch Management Policy. We will confirm that the server is correctly configured to obtain and install security updates.
File systems
If a user or group is deleted from the system this can orphan any files that were owned by that user and left on the server. A new user which is later created with the same UserID or GroupID could inherit permissions to access those files and have more access than was intended. We will identify any files on the system which are unowned in order to prevent this happening.
We will check the security of key systems files used to store user and password information.
Several uncommon filesystem types are supported by Linux. Removing support for these unneeded filesystem types reduces the local attack surface of the system. If a filesystem type is not needed it should be disabled.
We will check that standard system partitions (such as /tmp, /var, /var/log/audit, /home etc) are correctly configured and secured to prevent their being leveraged in an attack.
If removable storage drives and USB storage are not permitted in your environment, the associated system services should be disabled to prevent them being accessible if they are plugged into the server by unauthorised users.
Bootloaders
The Linux boot loader (such as grub or LILO) and its configuration files must be correctly secured to prevent unauthorised users changing the operating system at load time or obtaining information which would be helpful to attack a running server. A bootloader password should be set to prevent someone from changing the system settings from a command line at boot time.
If the system is booted into single user mode (rescue mode) a password must still be required in order to prevent an attacker obtaining root access without needing any credentials.
Prerequisites
- Wired network connection
- Local (root) Administrator credentials
- The SSH service enabled on all hosts to be reviewed
- List of IP addresses or hostnames to be assessed
Deliverables
Engaging with SecureTeam for your Linux Build Review will provide you with the following:
In-flight Support
Reporting
Once the build review has been completed, you will be provided with the following:
Comprehensive Technical Report
Our clear & concise reporting format contains an Executive Summary that can be understood by all members of your organisation – including individuals who may be in management or non-technical roles. All vulnerabilities contain a sufficient level of technical detail, so that your development team and systems administrators can quickly pinpoint the root cause of the vulnerability and apply the recommended course of action.
Technical References
Where applicable, we provide additional reference URLs for each vulnerability, so that further information on the vulnerabilities can be obtained from reputable sources of technical information.
Risk-Based Approach with CVSS Scoring
A risk-based approach is used throughout the report and all vulnerabilities are scored in line with CVSS (Common Vulnerability Scoring System). This allows the contents of the report to be fed into your own internal risk assessments and allows a plan to be developed to address the vulnerabilities which present the highest risk to your organisation.
Secure & Encrypted Report Delivery
Due to the sensitive content which may be contained in our test reports, all test reports are delivered to our customers through a secure file delivery mechanism. All test reports are encrypted using AES-256 encryption and are secured with a strong, randomly-generated password which is delivered ‘out-of-band’ to you via SMS. The encrypted file is then delivered to you through an encrypted & expiring URL link – allowing you to download the test report securely to your workstation.
After Care
Once our consultancy engagement is complete and our final report has been delivered to you, our consultancy team remain available to you indefinitely for any questions you may have surrounding the report’s findings or our consultancy engagement with you.
We pride ourselves in partnering with our customers to provide adhoc security advice and to ensure that our engagement with you doesn’t simply end once the final report has been delivered.
We are committed to ensuring, that as our customer, you receive the utmost value out of our consultancy services and look forward to developing a long-lasting business relationship with you.
Conference Call
Once you have received our final report, you have the option of attending a conference call between the consultant(s) involved in delivering your project and individuals within your organisation who you feel would benefit from a more in-depth discussion of the report’s findings.
A conference call is suitable for both management and technical staff and provides you with the perfect opportunity to ensure that all vulnerabilities and their recommended course of action are fully understood by stakeholders and technical staff who may be tasked with applying the recommended course of action.
Find out more
If you'd like to find out more about our services or would like us to provide you with a quotation, please fill out the following form and one of our team will get in touch with you.