10 Linux Server Security Checks Every DevOps Engineer Should Know

A Linux server can be running perfectly and still have security problems. 

The application may be working.
The website may be online.
The CPU and memory may look normal. 

But that does not mean the server is secure. 

In a production environment, small security gaps can become serious problems if they are not noticed early. An open port, an unused user account, weak SSH settings, or outdated software can give attackers an opportunity to access the system.

At Pravux Technologies Pvt. Ltd., we believe server security should be checked regularly, not only when something goes wrong. 

Here are 10 practical Linux server security checks that every DevOps engineer should know, aligned with essential DevOps security best practices

1. Check Which Ports Are Open

One of the first things to check on a Linux server is which ports are currently listening. 

You may have services running for: 

• SSH  

• HTTP/HTTPS  

• MySQL  

• Redis  

• Docker  

• Monitoring tools  

• Application services  

But not every service needs to be publicly accessible. 

For example, if MySQL is only required internally, exposing port 3306 to the internet creates an unnecessary security risk. 

A simple check can be done with: 

sudo ss -tulpn 

The important question is not just: 

“Which ports are open?” 

It is: 

“Do these ports really need to be open?” 

Removing unnecessary exposure is one of the simplest ways to improve server security.

2. Review SSH Configuration

SSH is one of the most important entry points for managing a Linux server. 

A weak SSH configuration can make a server an easy target for automated attacks. 

Some basic checks include: 

• Is root login allowed?  

• Is password authentication required?  

• Are SSH keys being used?  

• Is SSH exposed to the entire internet?  

• Are unused SSH accounts still active?  

The SSH configuration can usually be reviewed with: 

sudo nano /etc/ssh/sshd_config

For production systems, key-based authentication is generally preferred over simple password authentication. 

You should also avoid allowing direct root login unless there is a specific reason for it. 

For detailed guidance on authentication and secure SSH settings, consult the official OpenSSH server configuration documentation.

3. Check User Accounts and Sudo Access

Over time, servers often accumulate user accounts. 

An employee may leave the company.
A developer may no longer need server access.
A temporary account may have been created for troubleshooting. 

If those accounts remain active, they become unnecessary security risks. 

You can review users with: 

cat /etc/passwd 

And check users with administrative privileges using: 

getent group sudo 

The goal is simple: 

Only the people who need access should have access. 

It is also important to regularly review who has sudo privileges. Not every server user needs full administrative access.

4. Check Firewall Rules

A firewall provides an important layer of protection between the server and the outside world, forming a key part of secure cloud infrastructure management.

On Ubuntu systems, UFW (Uncomplicated Firewall) is commonly used. 

You can check the current rules with: 

sudo ufw status

A typical production server may only need to allow specific ports such as: 

• 22 – SSH  

• 80 – HTTP  

• 443 – HTTPS  

The exact rules depend on the application’s architecture. 

For example, if an application communicates with a database internally, there may be no reason to expose the database port publicly. 

A firewall should follow the principle: 

Allow what is required. Block what is not. 

5. Keep the Operating System Updated

An outdated operating system can contain known security vulnerabilities. 

This is why regular patching should be part of normal server maintenance. 

For Ubuntu/Debian systems, you can check available updates with: 

sudo apt update  

sudo apt list --upgradable  

Depending on your maintenance process, security updates should be applied regularly and tested properly, ideally through a secure multi-environment CI/CD pipeline

This becomes especially important for production servers because updating everything blindly can sometimes create compatibility issues. 

A good approach is: 

Review → Test → Update → Verify 

Not simply: 

Update everything and hope for the best. 

6. Check Running Services

A server may have services running that are no longer required. 

For example, a server may have: 

• Old development services  

• Unused databases  

• Test applications  

• Monitoring services  

• Background processes  

You can review active services with: 

sudo systemctl --type=service --state=running

Then ask: 

What is this service doing, and does the server actually need it? 

If a service is unnecessary, disabling it can reduce the server’s attack surface. 

Fewer unnecessary services generally mean fewer things that need to be secured and maintained.

7. Monitor Login Attempts and Authentication Logs

If someone is repeatedly trying to access your server, you should know about it. 

Linux keeps authentication-related information in system logs. 

On Ubuntu, you can check authentication activity with: 

sudo tail -f /var/log/auth.log 

You may find: 

• Successful logins  

• Failed login attempts  

• SSH authentication failures  

• Sudo activity  

• Unexpected access attempts  

A few failed login attempts are not necessarily a problem. 

But repeated attempts from unknown sources, especially in large numbers, should be investigated. 

For larger environments, tools such as Fail2Ban or security monitoring platforms such as Wazuh can help automate detection and response. 

8. Check File and Directory Permissions

Linux permissions are there for a reason. 

Incorrect permissions can allow users or applications to access files they should not be able to modify or read. 

Pay special attention to: 

• Application configuration files  

• SSH keys  

• Environment files  

• Database credentials  

• Backup files  

• Log files  

For example: 

ls -la 

can help review file ownership and permissions. 

Configuration files containing passwords, API keys, or database credentials should not be unnecessarily readable by every user on the system. 

Security is not only about keeping attackers outside. 

It is also about controlling what each user and service can access inside the server.

9. Monitor Disk Usage and Logs

At first, disk usage may not look like a security issue. 

But a full disk can cause serious problems. 

For example: 

• Applications may stop writing data  

• Databases may fail  

• Logs may stop working correctly  

• Services may crash  

• Backups may fail  

You can quickly check disk usage with: 

df -h  

You can also identify which directories are consuming the most space:  

sudo du -sh /* 2>/dev/null 

Logs should also be reviewed regularly. 

Large or unusual logs can sometimes indicate application problems, repeated login attempts, or other suspicious activity. 

Disk monitoring is therefore useful for both performance and security. 

10. Check for Suspicious Processes and Unexpected Connections

Sometimes a server can appear normal while an unwanted process is running in the background. An unknown process or unexpected network connection can be a sign of a compromised application, unauthorized access, or misconfigured service. 

Regularly check which processes are consuming system resources: 

top

or: 

ps aux --sort=-%cpu | head 

You can also check active network connections: 

sudo ss -tunap 

Look for: 

• Unknown processes  

• Unexpected applications running as root  

• Unusual outbound connections  

• Processes consuming unusually high CPU or memory  

• Services communicating with unknown external addresses  

If something looks unfamiliar, don’t immediately kill the process. First identify which application or service started it and why it is running. 

Regular process and connection checks can help detect unusual activity before it becomes a bigger security problem.