Linux系统深度安全加固(3)

　　6.IPtales防火墙规则
　　假设我们的服务器server1运行Apache和sshd(sshd可以不运行在标准端口，配置文件中能修改)。ethO网卡接Internet,ethi连接LAN，管理员在家中拨号登陆到server2(其私用网络TP为192.168.0.12)，再登陆server1。其命令如下:
　　
　　为了防止IP spoofing的可能，还可以绑定server2的网卡地址:
　　[[The No.１ Picture.]]
　　不过好像也很少有人侵者能够做到这种地步，而且没什么利用的价值。
　　　
　　　
　　对攻击有所了解的人知道"端口重定向十反向管道"的美妙结合来穿越防火墙的例子吧?这种技巧已经运用太广，而危害很大。为了对抗这种难以防御的攻击，我们必须以牺牲一定的易用性为代价:
　　　
　　以上规则将阻止由内而外的TCP主动选接。
　　另外，用tftp或其他客户端反向攫取文件的攻击行为也很普遍，由于mfv以及诸如loki之类的工具依赖UDP，所以现在要把它彻底抹煞悼:
　　　
　　注:在更新系统和调试网络时需要把这两条规则临时去掉。
　　因为入侵的本质就是通过文本或图形界面在标准或非标准端口得到目标操作系统的shell，所以这不仅能阻止反向管道本身，还能免疫很多人侵技巧，不过对一般的系统管理员而言，这太苛刻了!
　　下面是的tables的一些攻击对策。
　　　
　　此外，iptables还能配置出让一些扫描行为，比如nmap失效的规则，应当注意，防火墙不是万能的，当一个攻击者足够疯狂时，不要指望你的防火墙能抵挡得住DDoS.
　　
　　
　　7.完整性校验
　　
　　tripwire是一个比较有名的工具，它能帮你判断出一些重要系统文件是否被修改过。现在的Linux发行版中一般部带有该工具的开源版本，在默认的校验对象配置文件中加入一些敏感文件就可以使用。
　　
　　用"man rpm"查看命令帮助，"-V"参数用于MD5校验，注意要把rpm校验产生的二进制数据文件作一个硬备份，以防止其本身被修改。
　　
　　8.自行扫描
　　
　　普通的安全加固基本上是做完了，现在让我们来对自己做的系统做一个风险评估，推荐使用nessus latest version.
　　也许你觉得自己的系统没有问题了，但有时nessus还是能报告出一些问题，比如一个第三方的Webrnail有某些安全缺陷，如果没有问题最好，有问题我们再回去修补。
　　
　　9.高级技巧
　　
　　以上的措施已经足以让大多数入侵者望而却步，接下来的部分给那些对安全极度敏感的偏执狂。缓冲区溢出对策中有stackgurad、stackshield、formatguard,heapguard和pointguard等编译技术，但它们需要重新编译源码，不仅麻烦而且会使系统性能有所下降，所以这里打算用防止缓冲区溢出的内核补丁。
　　比较熟知的是PaX内核补丁，它主要通过数据区heap/bss/stack不可执行代码来防御直接覆盖返回地址后跳转到数据区执行shellcode的一些exploit.PaX的站点最近访问不了，但用Google可以找到很多对应较新内核的PaX下载。这些补丁并不能防御所有的溢出攻击，但却可以挡住市面上相当数量的exploit.
　　
　　10.日志策略
　　
　　主要就是创建对人侵相关的重要日志的硬拷贝，不致于应急响应的时候连最后的黑匣子都没有。可以把它们重定向到打印机，管理员邮件，独立的日志服务器及其热备份。
　　
　　11.Snort入侵检测系统
　　
　　对人侵响应和安全日志要求较高的系统有此必要;对于一般的系统而言，如果管理员根本不会去看一大堆日志，那么它白白占用系统资源，就如同鸡肋一样。
　　小结
　　对攻击的思考假设有一个技术高超的入侵者，拥有自行挖掘系统底层漏洞的能力，他发现了Apache的一个漏洞。并编写了remote exploit，这个漏洞暂时还没有出现在bugtraci上，处于'末知'状态，如果入侵者试图攻击我们的系统，他必须能挖掘一个Apache并且是root级的远程溢出，并进行下列的工作:
　　1)在snellcode中植人代码杀死httpd进程，并且把sh绑定在80端口。
　　2)在80端口复用。
　　3)让shellcode执行iptables-FOUTPUT/TNPUT，前提是他猜到有这么回事。
　　以上均需要溢出后是root权限，并且是能绕过PaX的高难度exploit;另外，Apacne杀掉后会自动重启。如果想攻击sshd，因为iptables将丢弃所有来自外网访问ssh目的包，所以即使有远程溢出(当然别忘了PaX)，此路不通。
　　再看看其他的方法，如果脚本攻击可以获得允许远程登录ssn用户的明文口令，或是利用脚本缺陷直接添加系统账号，这不仅需要系统root权限，而且/etc/passwd已经被chattr过，满足以上条件，并且攻破server2，就有希望得到shelt。但提升权限的机会不大!普通脚本攻击在此无效，当然，如果该系统并不运行CGI的话，此路更是不通。
　　诚然，入侵者很可能在http上破坏你的脚本，第三方的Web安全加固不在本文讨论之列，以上条件对大多数人侵者足够苛刻，可以说几乎不可能实现。但是我们为此也牺牲了不少，并且这些措施依赖一定的环境而实现安全性和易用性，需要读者站在自己的角度寻找它们的平衡点