In-depth security reinforcement for Linux systems (3)

Article Title: Linux system deep security reinforcement (3 ). Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
　　 6. IPtales firewall rules
Assume that our server server1 runs Apache and sshd (sshd can be modified in the configuration file without running on the standard port ). The ethO Nic is connected to the Internet, and the ethi is connected to the LAN. The Administrator logs on to server2 at home by dialing (the private network TP is 192.168.0.12) and then logs on to server1. The command is as follows:
　　
To prevent IP spoofing, you can also bind the NIC address of Server 2:
　　 [[The No.1 Picture.]
However, few people seem to be able to do this, and there is no practical value.
　　 　
　　 　
Do people who know about attacks know the wonderful combination of "port redirection Ten reverse pipelines" to cross the firewall? This kind of technique has been used too widely and is very harmful. To defend against this difficult attack, we must sacrifice a certain degree of ease of use:
　　 　
The above rules will prevent the active TCP selection from the inside out.
In addition, it is common to use tftp or other clients to obtain files in reverse direction. Because mfv and tools such as loki depend on UDP, We need to completely erase it:
　　 　
　　 Note:These two rules need to be removed temporarily when updating the system and debugging the network.
Because the essence of intrusion is to get the shell of the target operating system through the standard or non-standard port through the text or graphic interface, this not only can prevent the reverse pipe itself, but also can be immune to many intrusion techniques, however, this is too harsh for general system administrators!
The following are some of tables's attack strategies.
　　 　
In addition, iptables can also configure scanning behaviors, such as nmap failure rules. It should be noted that the firewall is not omnipotent. When an attacker is crazy enough, do not expect your firewall to withstand DDoS attacks.
　　
　　
　　 7. Integrity Verification
　　
Tripwire is a famous tool that helps you determine whether important system files have been modified. Currently, Linux releases generally have open-source versions with the tool. You can add some sensitive files to the default validation object configuration file.
　　
Run the "man rpm" command to view help. The "-V" parameter is used for MD5 verification. Make a hard backup of the binary data file generated by rpm verification to prevent modification.
　　
　　 8. Self-Scan
　　
General security reinforcement is basically done. Now let's make a risk assessment for our own system. We recommend using nessus latest version.
Maybe you think your system is okay, but sometimes nessus can report some problems. For example, a third-party Webrnail has some security defects. If there is no problem, if there is any problem, we can fix it again.
　　
　　 9. Advanced Skills
　　
The above measures are enough to discourage most intruders, and the next part will be the paranoid about the extremely sensitive security. The buffer overflow countermeasures include stackgurad, stackshield, formatguard, heapguard, pointguard, and other compilation technologies. However, they need to re-compile the source code, which is not only troublesome but also degrades the system performance, therefore, we plan to use Kernel patches to prevent Buffer Overflow.
We are familiar with the PaX kernel patch. It uses the heap, bss, and stack unexecutable code in the Data zone to defend against exploit that directly overwrites the returned address and jumps to the data zone to execute shellcode. the PaX website cannot be accessed recently, but Google can find many PaX downloads corresponding to newer kernels. These patches cannot defend against all overflow attacks, but can block a considerable number of exploit attacks on the market.
　　
　　 10. Log Policy
　　
It is mainly to create a hard copy of important logs related to human intrusion, not even the last black box in the emergency response. You can redirect them to printers, Administrator emails, independent log servers, and their hot backups.
　　
　　 11. Snort intrusion detection system
　　
This is necessary for systems with high requirements for human intrusion response and security logs. For general systems, if the administrator simply does not read a large number of logs, it will occupy system resources in vain, just like the chicken ribs.
　　 Summary
Think about the attack. Suppose there is a highly skilled intruder who has the ability to discover the underlying vulnerabilities of the system. He discovered a vulnerability in Apache. Remote exploit has been compiled. This vulnerability has not yet appeared on the bugtraci and is in the "Last known" state. If intruders attempt to attack our system, he must be able to mine an Apache database with root-level remote overflow and perform the following work:
1) Implant code in snellcode to kill the httpd process and bind sh to port 80.
2) port 80 is reused.
3) Let shellcode execute iptables-FOUTPUT/TNPUT, provided that he guessed this was the case.
The above needs to be the root permission after the overflow, and is a difficult exploit that can bypass PaX; in addition, the Apacne will automatically restart after it is killed. If you want to attack sshd, iptables will discard all packages for accessing ssh from the Internet, so even if there is a remote overflow (of course, do not forget PaX), this will not work.
Let's look at other methods. If a script attack can obtain the plaintext password that allows remote logon to the ssn user, or directly add the system account using the script defect, this requires not only the system root permission, and/etc/passwd has been chattr, meet the above conditions, and break server2, there is hope to get shelt. However, there is little chance of Privilege Escalation! Normal script attacks are ineffective here. Of course, if the system does not run CGI, this is even worse.
It is true that intruders are likely to destroy your scripts over http. Third-party Web security reinforcement is not discussed in this article. The above conditions are harsh enough for most people, and it is almost impossible to achieve this. However, we have sacrificed a lot for this, and these measures depend on a certain environment to achieve security and ease of use. Readers need to find their balance points from their own perspective.