Linux security policy record

Today, network security is surging, and two days ago, we found that servers in our departments were intruded and used to attack others. So I spent some time researching my VPS security. The following is the configuration record. Well, because there are many Linux releases and many different releases have different settings, it is necessary to first talk about my Linode VPS environment: CentOS + LAMP + phpMyAdmin.Use strong passwords ¶No matter how many other security measures are taken, if the password is not strong enough, I am afraid everything is useless. Therefore, you must first set a strong enough password. Including the logon password of the System user, especially the root account, the password of the MySQL user, and all other passwords that can obtain the permission to read any content of the system. In short, all the passwords are good. Do not use the same password. Don't be afraid to remember it. Write a strong password, write it down in your notebook, and find a place on your computer to save it (Windows 7 notes are a good choice ). You only need to copy and paste it when logging on through a webpage or using SSH (right-click the Putty window to paste it ). Strong passwords are used for all VPS passwords, which are unrelated to each other. This prevents other passwords from being leaked. Clean out unwanted system users and groups. Although the CentOS system provided by Linode VPS has been well optimized, there are still many built-in users and groups in the system that are not needed. Clearing these users and groups also helps system security. Of course, to ensure security, you still need to back up the data first. User Information in CentOS is stored in the/etc/passwd file. The following command shows all users. Cat/etc/passwd run the following command in the root account to clear unwanted users and groups:

cp /etc/passwd /etc/passwd.savcp /etc/group /etc/group.savfor a in adm lp sync news uucp operator games gopher mailnull nscd rpc;do /usr/sbin/userdel $a -f; donefor a in lp news uucp games gopher users floopy nscd rpc rpcuser nfsnobody;do /usr/sbin/groupdel $a -f; done

 

For methods to clean up users and groups, refer to optimizing CentOS 5 on 128 m vps. Users and groups are completely cleaned up according to this document. Other users and groups may also be disabled for future tests. To enhance SSH security, modify the SSH configuration file. vim/etc/ssh/sshd_config focuses on the following three items. All several key configurations are listed behind this section for reference. 1. Prohibit the root account from remotely logging on to the Linux system. The most well-known user name is root, which is the most vulnerable to brute force cracking attacks. Preventing root users from logging on via SSH can avoid this tragedy. In addition, you can add a user name that you use to make it a little more complex, making it difficult for others to guess. This increases the difficulty. I'm afraid I won't make any effort to guess your username if I am not a target person. Therefore, the attack through SSH does not exist. PermitRootLogin no 2. limits the username that can log on to SSH. In addition to the root account, there are other default accounts in Linux, and some cannot be deleted easily. Therefore, it is recommended that you disable SSH logon for the root account. 3. Change the default SSH port to 22. Now there are countless machines on the Internet scanning port 22 to find attack opportunities. In the last few days when my VPS was launched, I received a large number of scans for port 22, that is, I had to crack the SSH password. The attack username is mainly root, and some other common simple usernames, such as test123. Some of the default accounts mentioned above are also in the attacker list. Change the SSH Port to an uncommon one, such as Port 1234. You can also use the certificate to log on to SSH to reduce the number of times the password is used. I will not discuss it here. No configuration is successful. 5. after the configuration is complete, restart the SSH service to make it take effect: service sshd restart reference: 1. centOS Wiki: Securing OpenSSH2.Preventing brute force attacks using iptables recent matching attachment: sample of the SSH configuration file (some rows marked with # annotations have no columns)

Port 1234Protocol 2SyslogFacility AUTHPRIVPermitRootLogin noAllowUsers user1 user2/etc/ssh/ssh_known_hostsPermitEmptyPasswords noPasswordAuthentication yesChallengeResponseAuthentication noGSSAPIAuthentication yesGSSAPICleanupCredentials yesUsePAM no# Accept locale-related environment variablesAcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGESAcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENTAcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGEAcceptEnv XMODIFIERSX11Forwarding no# override default of no subsystemsSubsystem   sftp /usr/libexec/openssh/sftp-serverUseDNS noBanner /etc/issue

 

Use iptables to restrict connections. Because the rules in iptables are sensitive to order, the following describes several aspects and then provides all the configuration file content (which is described by # annotations ). 1. limit the number of SSH port connection errors (see Preventing brute force attacks using iptables recent matching); 2. limit the number of concurrent connections of a single IP address to port 80; 3. limit the connection rate of port 80 and other ports such as mail and SMTP (refer to: Prevent DOS with iptables); 4. all other non-conforming items are dropped. I found that you do not need to use the following command line to edit iptables entries. iptables-A INPUT ......... instead, you can download the iptables file and edit it using an editor such as NotePad (of course, you must refer to the existing rules), and then upload the file to overwrite the original one, use the following command line to load the new rule. service iptables restart contains the iptables file I currently use:

# Generated by iptables-save v1.4.7 on Fri Mar 9 23:08:51 2012 * filter: input accept [0: 0]: forward accept [0: 0]: output accept [1301: 2201856] # The following two chains are used to record the number of ssh logon attempts: blacklist-[0: 0]: sshscan-[0: 0] #2012.03.16 Add a chain: syn_flood-[0: 0] # rule 1 allows all local communications-a input-s 127.0.0.1/32-j ACCEPT # rule 2 limits RELATED, the connection rate of the ESTABLISHED Class is 50 per second and the peak value is 50. If the limit is exceeded, it is not accepted # It does not seem necessary to do so, clear this part of 2012.03.16 #-a input-m state -- state RELATED, ESTABLISHED-m limit -- limit 50/sec -- limit-burst 50-j ACCEPT-A INPUT-m state -- state RELATED, ESTABLISHED-j ACCEPT # Jump to syn_flood CHAIN to determine whether there is A "Flood" attack, 2012.03.16-a input-p tcp-m tcp -- tcp-flags FIN, SYN, RST, ack syn-j syn_flood # limited acceptance of icmp packets, 2012.03.16-a input-p icmp-m limit -- limit 10/sec-j ACCEPT-a input-p icmp-m limit -- limit 10/sec-j LOG -- log-prefix" PING-DROP: "-- log-level 6 # rule 3 limits the speed of creating a new connection on port 80 to 50 per minute, with the peak value of 200; -a input-p tcp-m tcp -- dport 80-m state -- state NEW-m limit -- limit 50/min -- limit-burst 200-j ACCEPT # basically all email services are completed by Google Enterprise post office, delete the following entries related to ports 465 and 25, disable the two ports 2012.03.16 # rule 4, similar to rule 3, to limit port 465 #-a input-p tcp-m tcp -- dport 465-m state -- state NEW-m limit -- limit 30/min -- limit-burst 100-j ACCEPT # rule 5 is similar to rule 3 to limit port 25 #-a input-p tcp-m tcp -- dport 25-m state -- state NEW -m limit -- limit 30/min -- limit-burst 100-j ACCEPT # rule 6 is similar to rule 3 to limit port 5678 (this is a special port I use) -a input-p tcp-m tcp -- dport 5678-m state -- state NEW-m limit -- limit 10/min -- limit-burst 20-j ACCEPT # rule 7 limit port 80 the number of concurrent connections cannot exceed 20, otherwise, tcp reset is sent to reject connection-a input-p tcp-m tcp -- dport 80 -- tcp-flags FIN, SYN, RST, ack syn-m connlimit -- connlimit-abve 20 -- connlimit-mask 32-j REJECT -- reject-with tcp-reset # rule 8, 9 open port 53 (DNS Service) # It seems that this port is not open and there is no problem, disable 2012.03.16 #-a input-p tcp-m tcp -- sport 53-j ACCEPT #-a input-p udp-m udp -- sport 53-j ACCEPT # rule 10 two chains mentioned to restrict ssh connection creation, and the specified time for blocking connections that exceed the number of attempts-a input-p tcp-m tcp -- dport 1234-m state -- state NEW-j sshscan # rule 11 discards others that do not meet the aforementioned rules -a input-j DROP # The following are the two chains used to check ssh connections, blacklist and sshscan-A blacklist-m recent -- set -- name blacklist -- rsource-A blacklist-j DROP-A sshscan-m recent -- update -- seconds 600 -- hitcount 1 -- name blacklist -- rsource- j DROP-A sshscan-m recent -- set -- name counter1 -- rsource-A sshscan-m recent -- set -- name counter2 -- rsource-A sshscan-m recent -- set -- name counter3 -- rsource- A sshscan-m recent -- update -- seconds 20 -- hitcount 3 -- name counter1 -- rsource-j blacklist-A sshscan-m recent -- update -- seconds 200 -- hitcount 15 -- name counter2 -- rsource -j blacklist-A sshscan-m recent -- update -- seconds 2000 -- hitcount 20 -- name counter3 -- rsource-j blacklist-A sshscan-j ACCEPT # determine whether the syn_flood attack is successful, if not, RETURN (RETURN). Otherwise, DROP 3012.03.16-A syn_flood-m limit -- limit 10/sec-j RETURN-A syn_flood-j drop commit # Completed on Fri Mar 9 23:08:51 2012

 

In addition, there are also restrictions on ICMP connections in iptables, And I discard all of them. If you need please refer to: http://serverfault.com/questions/287998/is-my-linux-firewall-secure other references: 1. shoreWall Iptables Firewall2.Using iptables to Block Brute Force Attacks3.25 Most Frequently Used Linux IPTables Rules Examples4.Arno's iptables firewall5.iptables official website 6. iptables guide 1.1.197.Using iptables to Enhance Security of your VPS8.iptables syntax key 9. the revision record of the basic application tutorial of iptables firewall is 2012.03.161. add unnecessary system users and groups for cleanup. 2. modify some iptables settings (The rule number in this article is not modified):. because the mail service only uses its sending function and does not receive it, port 465 and port 25 are not open; port B .53 is disabled, and VPS query DNS is not affected. adds SYN flood attack determination. D. added limited acceptance for ICMP (now you can ping cnzhx.net ).