Protect your Ubuntu Server

Security is relative. Using the methods described in this article cannot guarantee that your server is "safe", but it is certainly safer than before, it is also more secure than most servers. At least cainiao-level hackers cannot break the attack. Security is a continuous process and it is not achieved overnight. We believe that, the security field requires a bit of paranoia.

The protection measures listed in this article have been tested in Ubuntu Server 10.04 (Lucid) and 10.10 (Maverick). If you want to make your new Ubuntu Server indestructible, you should read this article carefully.

 

 

Ubuntu servers are well designed and regularly updated, which is relatively safe. the Ubuntu security team said they will continue to work hard to protect Ubuntu's security and will provide regular security updates.

· Do not open the port

· Role-Based Management

· No x Server

· Security Update

· Kernel and compiler Protection

In this article, we will deal with security challenges from different parties, including system analysis, modification settings, firewall installation, rootkit scanning, and periodic maintenance system.

· Modify settings to enhance security

· Implement UFW and Simple Firewall

· Using denyhosts to automatically blacklist attackers

· Use Tiger to scan system vulnerabilities

· Use psad to detect intrusion attempts

· Install nmap and scan the ports opened by the System

· Use chkrootkit to check the system rootkit

· Monitoring logs

Modify settings to enhance security

Protect shared memory

When attacking a running service (such as httpd), you often need to use/dev/shm to modify/etc/fstab to make it safer.
Sudo vi/etc/fstab

Add the following line:
Tmpfs/dev/shm tmpfs ults, noexec, nosuid 0 0

Prohibit root login through SSH

The Root account is disabled by default in Ubuntu. If you install Ubuntu on Slicehost or Linode, root is enabled, it is a good idea to prevent root users from logging on to the system through SSH.
Sudo vi/etc/ssh/sshd_config

Set PermitRootLogin to no:
PermitRootLogin no

Of course, if you access your server through SSH, make sure that other users can use sudo normally before you disable SSH for root users.

Only allow users to use su

This will help prevent Elevation of Privilege. By default, Ubuntu does not provide a management group, so you need to create a management group first.
Sudo groupadd admin

Add yourself to the Management Group:
Sudo usermod-a-G admin andrew

Restrict/bin/su access, and only grant permissions to members of the Management Group:
Sudo dpkg-statoverride -- update -- add root admin 4750/bin/su

Check/bin/su permissions:
Ls-lh/bin/su

The following output is displayed:
-Rwsr-x --- 1 root admin 31 K 2010-01-26 17:09/bin/su

The source route of inbound data packets cannot be tracked.
Sudo sysctl-w net. ipv4.conf. all. accept_source_route = 0
Sudo sysctl w net. ipv4.conf. default. accept_source_route = 0

System users are not allowed to access the FTP server.

This is only required when ftpd is installed. As long as no warning is reported in the tiger scan report, SFTP is more secure than FTP. If possible, try to use SFTP.

Edit/etc/ftpusers:
Sudo vi/etc/ftpusers

Add a system user to reject ftpd:

Backup
Bin
Daemon
Games
Gnats
Irc
Libuuid
List
Lp
Mail
Man
Mysql
News
Ntp
Postfix
Proxy
Sshd
Sync
Sys
Syslog
Uucp
Www-data
UFW: Simple Firewall

UFW (Uncomplicated Firewall, Simple Firewall) provides an easy-to-understand interface to control iptable (iptable controls Netfilter and Netfilter is built in the kernel). Only a few simple commands are required, your server can control the access and the Creation status is easy.

UFW is a simple interface for configuring iptable.

Install and enable Uncomplicated Firewall:
Sudo aptitude install-y ufw
Sudo ufw enable

Display available UFW commands:
Sudo ufw show

Display UFW Configuration:
Sudo ufw status

Allow SSH and HTTP access to the Apache server:
Sudo ufw allow ssh
Sudo ufw allow http

In the preceding example, the ports of OpenSSH and Apache are opened through the service name (ssh and http). You can use the port number to replace the service name (for example, use 80 to replace http ).

View the service running status:

Check the running service to know which ports should be opened:
Sudo ufw app list

View the services used by UFW:
Less/etc/services
Denyhosts: prevents SSH attacks

Project home: http://denyhosts.sourceforge.net/

Check/var/log/auth. log on the server. I found that there are a series of SSH attacks. There are many methods to deal with such attacks, first of all denyhosts.

Denyhosts periodically scans/var/log/auth. log to find out the behavior and source of repeated access to the System through SSH, and then adds them to/etc/hosts. deny. For details, visit the project homepage.

 

Sudo aptitude-y install denyhosts

All you need to do is automatically. You can use the following command to view the IP addresses added to/etc/hosts. deny:

Sudo less/etc/hosts. deny

Tiger: System Security Scanner

Project home: http://www.nongnu.org/tiger/

By analyzing the files and settings on the system, Tiger creates an automatic security audit, and finally lists the analysis content, warnings, alarms, and faults in the form of reports.

The Tiger Command records potential security issues in/var/log/tiger. You can use the tigexp command to find the result encoding for detailed explanations and security reinforcement suggestions, all serious problems identified by tiger are marked as Fail.

Install tiger:
Sudo aptitude-y install tiger

Run tiger to create a security issue report:
Sudo tiger

Use less to view the latest tiger report:
Sudo-I
Less/var/log/tiger/'LS-t1/var/log/tiger | head-1'
Exit

Use tigexp to list the explanation of the Fail code:
Tigexp dev002f

Of course, you can search by Google.

Ignore these:
-- FAIL -- [dev002f]/dev/fuse has world permissions

-- FAIL -- [logf005f] Log file/var/log/btmp permission shocould be 660

Modifying their permissions may cause other problems.
Use psad to detect intrusion

Project home: http://www.cipherdyne.org/psad/

Psad can record intrusion behaviors and monitor iptable.

Install psad:
Sudo aptitude-y install psad

The background process runs automatically.

Check the current status:

Sudo psad-S

You can modify the psad settings and send an email to the Administrator when detecting intrusion.

Nmap: Port Scanning

Project home: http://nmap.org/

Nmap allows you to view opened ports and verify that UFW/iptable works properly.

Install nmap:
Sudo aptitude install-y nmap

Port Scan:
Nmap-v-sT localhost

SYN scan:
Sudo nmap-v-sS localhost

Scan type explanation: html> http://nmap.org/book/man-port-scanning-techniques.html

Chkrootkit: Check rootkit

Project home: http://www.chkrootkit.org/

Check whether rootkit exists in the Chkrootkit scan system.

Ideally, you do not need to perform this scan, but in reality it is best to run it regularly.

Install chkrootkit:
Sudo aptitude install-y chkrootkit

Run chkrootkit:
Sudo chkrootkit

LogWatch

Ubuntu community Documentation: https://help.ubuntu.com/community/Logwatch

Logs are further detailed. Without a good Log Viewer, the log function is very limited. Logwatch can select the most useful information from a large number of logs to form a readable report, it is a good habit to open Logwatch every day and check the logs generated by the system.

Installation:
Sudo aptitude-y install logwatch

Usage:
Sudo logwatch | less

Continuous maintenance

Your server is safer now, but don't stop it. Regular Maintenance every week is a good habit.

Update Software:
Sudo aptitude update
Sudo aptitude safe-upgrade

I like to use safe-upgrade because it performs security updates.

See: http://wiki.debian.org/Aptitude

Alternatively, you can set security updates to automatic. If you cannot maintain security updates once a week, this is not a perfect solution because the Administrator has not monitored the updates, no tests were executed after the update. See: https://help.Ubuntu.com/10.04/serverguide/C/automatic-updates.html

Check intrusion behavior:
Sudo psad-S

Use tiger to analyze the system first, because the report of tiger in/var/log/tiger belongs to the root user, and these commands are run every time to solve some user permission problems.
Sudo-I
Tiger
Grep FAIL/var/log/tiger/'LS-t1/var/log/tiger | head-1'
Exit

In the preceding command, use grep to extract the Fail mark from the latest report file, and the ls clause sends the latest file to the grep directory, the sudo-I command allows you to run multiple commands as the root user and end the command using exit.

Use tigexp to list the explanation of the Fail code:
Tigexp dev002f

Use nmap to scan ports:
Sudo nmap-v-sS localhost

Check rootkit:
Sudo chkrootkit

View logs:
Sudo logwatch | less