Server Security Checklist

Server Security Checklist

A comprehensive security audit is crucial for any production server to protect sensitive data, maintain service availability, and prevent unauthorized access. This checklist provides a practical, hands-on approach to auditing and hardening your Linux server.

Prerequisites

Before beginning, ensure you have:

• Root or sudo access to the server.
• Basic understanding of Linux command line and networking concepts.
• SSH access to the server.
• A reliable backup of your server's data and configuration.
• A list of all running services and their purpose.

1. Secure SSH Access

SSH (Secure Shell) is the primary way to manage your server remotely. Securing it is paramount.

1. Disable Root Login:
2. * Edit the SSH configuration file:

3. sudo nano /etc/ssh/sshd_config

4. * Find the line PermitRootLogin and change it to:

5. PermitRootLogin no

6. * Why: Direct root login bypasses user privilege escalation and is a common target for brute-force attacks.
7. * Troubleshooting: If you accidentally lock yourself out, you may need console access or to reboot into single-user mode to revert the change.
9. # Use SSH Keys Instead of Passwords:
10. # * Generate an SSH key pair on your local machine:
11. #

    ssh-keygen -t rsa -b 4096

12. # * Copy your public key to the server:
13. #

    ssh-copy-id your_username@your_server_ip

14. # * Why: SSH keys are significantly more secure than passwords and are immune to brute-force attacks.
15. # * Troubleshooting: Ensure file permissions on ~/.ssh/authorized_keys on the server are correct (usually 600).
16. #
17. # # Change the Default SSH Port:
18. # # * In /etc/ssh/sshd_config, change Port 22 to a non-standard port (e.g., Port 2222).
19. # # * Why: While not a foolproof security measure, it significantly reduces automated scanning and brute-force attempts targeting the default port.
20. # # * Troubleshooting: Remember to specify the new port when connecting: ssh -p 2222 your_username@your_server_ip.
21. # #
22. # # # Limit SSH User Access:
23. # # # * In /etc/ssh/sshd_config, use AllowUsers or DenyUsers directives.
24. # # #

    AllowUsers user1 user2

25. # # # * Why: Restricts who can log in via SSH, minimizing the attack surface.
26. # # #
27. # # # # Restart SSH Service:
28. # # # #

    sudo systemctl restart sshd

29. # # # # * Why: Applies the configuration changes.
30. #
31. # == 2. Firewall Configuration ==
32. #
33. # A firewall is your server's first line of defense against unwanted network traffic.
34. #
35. # # Install and Configure UFW (Uncomplicated Firewall):
36. # # * Install UFW if not already present:
37. # #

    sudo apt update && sudo apt install ufw

38. # # * Why: UFW simplifies firewall management.
39. # #
40. # # # Set Default Policies:
41. # # #

    sudo ufw default deny incoming

42. # # #

    sudo ufw default allow outgoing

43. # # # * Why: Denies all incoming connections by default, allowing only explicitly permitted services.
44. # # #
45. # # # # Allow Necessary Services:
46. # # # # * Allow SSH (using your custom port if changed):
47. # # # #

    sudo ufw allow 2222/tcp

48. # # # # * Allow HTTP/HTTPS:
49. # # # #

    sudo ufw allow 80/tcp

50. # # # #

    sudo ufw allow 443/tcp

51. # # # * Why: Opens specific ports for essential services.
52. # # # * Troubleshooting: If you lose SSH access, you'll need console access to re-enable port 2222.
53. # # #
54. # # # # Enable the Firewall:
55. # # # #

    sudo ufw enable

56. # # # # * Why: Activates the firewall rules.
57. # # # #
58. # # # # # Check Firewall Status:
59. # # # # #

    sudo ufw status verbose

60. # # # # # * Why: Verifies that the rules are active and correctly configured.
61. # # # #
62. # # # # == 3. Regular System Updates ==
63. # # #
64. # # # Unpatched vulnerabilities are a major security risk.
65. # # #
66. # # # # Update Package Lists and Upgrade Packages:
67. # # # #

    sudo apt update && sudo apt upgrade -y

68. # # # # * Why: Ensures all installed software is up-to-date with the latest security patches. The -y flag automatically answers yes to prompts.
69. # # # * Troubleshooting: Sometimes upgrades require a reboot. Monitor for prompts or messages indicating this.
70. # # #
71. # # # # Enable Automatic Security Updates (Optional but Recommended):
72. # # # # * Install the unattended-upgrades package:
73. # # # #

    sudo apt install unattended-upgrades

74. # # # # * Configure it (e.g., /etc/apt/apt.conf.d/50unattended-upgrades).
75. # # # # * Why: Automates the patching process for critical security updates.
76. # # # * Security Implication: While convenient, ensure you have rollback plans in case an automatic update causes issues.
77. # # #
78. # # # == 4. Minimize Installed Software ==
79. # #
80. # # Every installed package is a potential entry point for attackers.
81. # #
82. # # # List Installed Packages:
83. # # #

    dpkg -l | less

    (Debian/Ubuntu)
84. # # #

    rpm -qa | less

    (CentOS/RHEL)
85. # # # * Why: Helps you identify unnecessary software.
86. # # #
87. # # # # Remove Unused Packages:
88. # # # #

    sudo apt autoremove --purge

    (Debian/Ubuntu)
89. # # # #

    sudo yum autoremove

    (CentOS/RHEL)
90. # # # * Why: Removes packages that were installed as dependencies but are no longer needed.
91. # # #
92. # # # # Uninstall Unnecessary Services:
93. # # # # * Identify running services:
94. # # # #

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

95. # # # # * Stop and disable a service if not needed:
96. # # # #

    sudo systemctl stop apache2 && sudo systemctl disable apache2

97. # # # * Why: Reduces the attack surface by disabling or removing services you don't actively use.
98. # #
99. # # == 5. Intrusion Detection & Monitoring ==
100. #
101. # Proactive monitoring can help detect and respond to security incidents quickly.
102. #
103. # # Install and Configure Fail2ban:
104. # # * Install Fail2ban:
105. # #

     sudo apt install fail2ban

106. # # * Configure it by copying the default jail.conf to jail.local:
107. # #

     sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

108. # # * Edit jail.local to customize settings, e.g., SSH port, ban time, and email notifications.
109. # # * Why: Scans log files for malicious activity (like repeated failed login attempts) and temporarily or permanently bans the offending IP addresses.
110. # # * Troubleshooting: Ensure Fail2ban is enabled and running: sudo systemctl status fail2ban. Check its logs: /var/log/fail2ban.log.
111. # #
112. # # # Monitor System Logs:
113. # # # * Regularly review logs in /var/log/, especially:
114. # # # * /var/log/auth.log (or secure on RHEL-based systems) for authentication attempts.
115. # # # * /var/log/syslog (or messages) for general system activity.
116. # # # * Application-specific logs (e.g., web server logs).
117. # # * Why: Log analysis is crucial for identifying suspicious patterns and security breaches.
118. # # * Tools: Consider tools like logwatch or centralized logging solutions (e.g., ELK stack, Graylog) for larger deployments.
119. # #
120. # # # Implement File Integrity Monitoring (Optional):
121. # # # * Install AIDE (Advanced Intrusion Detection Environment):
122. # # #

     sudo apt install aide aide-common

123. # # # * Initialize the database:
124. # # #

     sudo aideinit

125. # # # * Run a check:
126. # # #

     sudo aide.wrapper --check

127. # # * Why: Detects unauthorized modifications to critical system files.
128. # # * Security Implication: The AIDE database itself must be protected. Store a copy offline if possible.
129. #
130. # == 6. User and Permission Management ==
131. #
132. # Least privilege principle is key.
133. #
134. # # Review User Accounts:
135. # #

     cat /etc/passwd

136. # # * Why: Identify any dormant or unauthorized user accounts.
137. # #
138. # # # Remove Unused User Accounts:
139. # # #

     sudo userdel -r username

140. # # * Why: Removes accounts that are no longer needed, reducing potential entry points.
141. # #
142. # # # Use Strong Passwords and Enforce Policies:
143. # # # * Ensure users have strong, unique passwords. Consider password complexity requirements and expiration policies using PAM (Pluggable Authentication Modules).
144. # # * Why: Weak passwords are easily compromised.
145. # #
146. # # # Regularly Review File Permissions:
147. # # # * Use find to locate world-writable files or directories:
148. # # #

     sudo find / -xdev -type d -perm -0002 -print

149. # # #

     sudo find / -xdev -type f -perm -0002 -print

150. # # * Why: Prevents unauthorized modification of sensitive files.
151. #
152. # == 7. Security Hardening for Web Servers (Example: Nginx) ==
153. #
154. # If your server hosts web applications, hardening the web server is critical.
155. #
156. # # Keep Web Server Software Updated:
157. # # * Follow the instructions in Section 3.
158. # #
159. # # # Configure SSL/TLS:
160. # # # * Obtain and install an SSL certificate (e.g., Let's Encrypt).
161. # # * Why: Encrypts traffic between the client and server, protecting data in transit.
162. # # * See also: Let's Encrypt
163. # #
164. # # # Disable Unnecessary Modules:
165. # # # * Consult your web server's documentation to disable modules that are not in use.
166. # # * Why: Reduces the attack surface.
167. # #
168. # # # Implement Security Headers:
169. # # # * Configure headers like Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, and Content-Security-Policy in your web server configuration.
170. # # * Why: Mitigates various web vulnerabilities like clickjacking, XSS, and man-in-the-middle attacks.
171. # #
172. # # # Limit Request Methods and Body Sizes:
173. # # # * Configure your web server to only allow necessary HTTP methods (e.g., GET, POST) and limit the size of request bodies to prevent certain types of denial-of-service attacks.
174. # #
175. # # == 8. Regular Audits and Testing ==
176. #
177. # Security is an ongoing process.
178. #
179. # # Perform Regular Vulnerability Scans:
180. # # * Use tools like OpenVAS, Nessus, or Nmap scripts to scan your server for known vulnerabilities.
181. # # * Why: Identifies potential weaknesses before attackers do.
182. # #
183. # # # Review Security Logs Periodically:
184. # # * Dedicate time to manually review critical security logs.
185. # # * Why: Helps catch subtle or ongoing threats that automated tools might miss.
186. # #
187. # # # Test Your Backups:
188. # # * Regularly attempt to restore data from your backups to ensure they are valid and complete.
189. # # * Why: A backup is useless if it cannot be restored.
190. #
191. # == Dedicated Servers for Enhanced Security ==
192. #
193. # For critical applications requiring maximum control and security, consider dedicated servers. Dedicated servers, such as those offered at PowerVPS, provide full root access, allowing you to implement these security measures with complete freedom and without the overhead of shared environments. This level of control is essential for implementing advanced security configurations and ensuring compliance with stringent security policies.
194. #
195. # == Conclusion ==
196. #
197. # Implementing this checklist is a significant step towards a more secure server environment. Remember that security is not a one-time task but an ongoing commitment. Regularly review and update your security practices as threats evolve.
198. #
199. #
200. #
201. #