Apache 不回显版本，apache 的配置文件，找到 ServerTokens 和 ServerSignature 两个 directive，修改默认属性： 

　　#ServerTokens Full 
　　ServerTokens Prod <---------- 
　　#ServerSignature On 
　　ServerSignature Off <----------
 
修改 uname，拿出 uname.c 的源码，找到如下行： 

　　print_element (PRINT_SYSNAME， name.sysname);//操作系统名如 linux 
　　print_element (PRINT_NODENAME， name.nodename);//主机名 
　　print_element (PRINT_RELEASE， name.release);//发行版本，如：2.4.20-18 
　　print_element (PRINT_VERSION， name.version);// 
　　print_element (PRINT_MACHINE， name.machine);//机器类型，如i686 
　　print_element (PRINT_PROCESSOR， processor);//处理器类型
 
可以修改为： 

　　print_element (PRINT_SYSNAME，"HP-UX"); 
　　.......
 
编译后替换 /bin/uname 
其他服务及程序的修改可以查看其配置文件或者源码不要改太多，否则会给系统管理带来太麻烦。 
6. Iptales 防火墙规则 
假设我们的服务器 server1 运行 apache，sshd (sshd 可以不运行在标准端口，配置文件中能修改)eth0 网卡接 Internet，eth1 连接 LAN，管理员在家中拨号登陆到 server2 (其私用网络 IP 为 192.168.0.12)，再登陆 server1[roor@ayazero root]# iptables -A INPUT -i eth1 -s 192.168.0.12 -p tcp --dport 22 -j ACCEPT为防止 IP spoofing 的可能，还可以绑定 server2 的网卡地址：sh-2.05b# iptables -A INPUT -i eth1 -s 192.168.0.12 --mac-source 01:68:4B:91:CC:B7 -p tcp --dport 22 -j ACCEPT不过好像也很少有入侵者能够做到这种地步，而且没什么利用的价值。 

　　[root@ayazero root]# iptables -A INPUT -i
 eth0 -p tcp --dport 80 -j ACCEPT 
　　[root@ayazero root]# iptables -A INPUT -m 
state --state ESTABLISHED，RELATED -j ACCEPT 
　　[root@ayazero root]# iptables -A INPUT -j DROP
 
　　 
对攻击有所了解的人都知道“端口重定向+反向管道”的美妙结合来穿越防火墙的例子吧这种技巧已经运用太广，而危害很大为了对抗这种难以防御的攻击，我们必须以牺牲一定的易用性为代价 [root@ayazero root]# iptables -A OUTPUT -o eth0 -p tcp --syn -j DROP以上规则将阻止由内而外的 TCP 主动连接另外，用 tftp 或其他客户端反向攫取文件的攻击行为也很普遍，由于 tftp 以及其他一些工具依赖 UDP，所以现在要把它彻底抹煞掉[root@ayazero root]# iptables -A OUTPUT -o eth0 -p udp -j DROPPS: 在更新系统和调试网络时需要把这两条规则临时去掉因为入侵的本质就是通过文本或图形界面在标准或非标准端口得到目标操作系统的 shell，所以，这不仅能阻止反向管道本身，还能免疫很多入侵技巧不过对一般的系统管理员而言，这太苛刻了！iptables 的一些攻击对策: 

　　Syn-flood protection: 
　　[root@ayazero foo]# iptables -A FORWARD -p 
tcp --syn -m limit --limit 1/s -j ACCEPT 
　　
　　Furtive port scanner: 
　　[root@ayazero foo]# iptables -A FORWARD -p 
tcp --tcp-flags SYN，ACK，FIN，RST RST -m limit --limit 1/s -j ACCEPT 
　　
　　Ping of death: 
　　[root@ayazero foo]# iptables -A FORWARD -p 
icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
 
此外，iptables 还能配置出让一些扫描行为比如 nmap 失效的规则，应当注意：防火墙不是万能的，当一个攻击者足够疯狂时，不要指望你的防火墙能抵挡得住 DDoS 的洪水。关于 iptables 得更多细节，请参阅 Rusty Russell 的 Packet Filtering HOWTO。 
7. 完整性校验 
tripwire 是一个比较有名的工具，它能帮你判断出一些重要系统文件是否被修改过现在的 Linux 发行版中一般都带有他的开源版本，在默认的校验对象配置文件中加入一些敏感文件就可以使用RPM MD5 校验: 

　　[root@ayazero rpm]# rpm -V
 
用 "man rpm" 查看命令帮助，"-V" 参数用于 MD5 校验，注意要把 rpm 校验产生的二进制数据文件作一个硬备份，以防止其本身被修改。 
 
8. 自行扫描 
普通的安全加固基本上是做完了，现在让我们来对自己做的系统做一个风险评估，推荐使用 nessus latest version [homepage:http://www.nessus.org](既然从头到尾用的都是开源的东西，这里也继续节约成本，呵呵)也许你觉得自己的系统没有问题了，但有时 nessus 还是能报告出一些问题，比如一个第三方的 webmail 有某些安全缺陷，如果没有问题最好，有问题我们再回去修补。 
9. 高级技巧 
以上的措施已经足以让大多数入侵者望而却步，接下来的部分给那些对安全极度敏感的偏执狂 缓冲区溢出对策中有: stackgurad，stackshield，formatguard，heapguard，pointguard 等编译技术，但他们需要重新编译源码，不仅麻烦而且会使系统性能有所下降.所以这里打算用防止缓冲区溢出的内核补丁。 
比较熟知的是 PaX 内核补丁，它主要通过数据区 [heap/bss/stack] 不可执行代码来防御直接覆盖返回地址后跳转到数据区执行 shellcode 的一些exploitPaX的站点好像访问不了，但用google可以找到很多对应较新内核的PaX下载http://home.hetnet.nl/~ottolander/pax/pax.html。 
眕奻硃間甜祥夔滅郘垀衄腔祛堤馴击，但却可以挡住市面上相当数量的 exploit，现在那些关于如何绕过补丁的高级 exploit 技巧已经很不神秘，但是书写那样的攻击程序通常要满足一定的条件，即使那样的程序被写出来，函数，文件指针被成功覆盖，可能在这个系统上还是无法把那“溢出成果”传递给攻击者--仍然没有办法得到 shell 或是建立一个连接。 
lids Linux 上的入侵检测和防护系统，内核补丁，通过一个比 root 更大的 ring0 权限来提供增强的访问控制，甚至连 root 都不能改变，已有现成资料，不在此讨论。站点：http://www.lids.org 
lids 和缓冲区溢出补丁可能不兼容，欢迎知道真相的朋友告诉我。 
10. 日志策略 
主要就是创建对入侵相关的重要日志的硬拷贝，不至于应急响应的时候连最后的黑匣子都没有可以把他们重定向到打印机，管理员邮件，独立的日志服务器及其热备份 
11. Snort 入侵检测系统 
对入侵响应和安全日志要求较高的系统有此必要；对于一般的系统而言，如果管理员根本不会去看一大堆日志，那么它白白占用系统资源就如同鸡肋一样 
12. 最后的建议 
关心 bugtraq 上的漏洞列表； 
订阅厂商的安全公告； 
勤打补丁； 
站在攻击者的角度去思考如何防御。 
小结 
对攻击的思考：假设有一个技术高超的入侵者，拥有自行挖掘系统底层漏洞的能力，他发现了 apache 的一个漏洞，并书写了 remote exploit，这个漏洞暂时还没有出现在 bugtraq 上，处于“未知”状态，如果入侵者试图攻击我们的系统，他必须能挖掘一个 apache 并且是 root 级的远程溢出： 
<1>在 shellcode 中植入代码杀死 httpd 进程，并且把 sh 绑定在 80 端口。 
<2>在 80 端口复用。 
<3>让 shellcode 执行 iptables -F OUTPUT/INPUT，前提是他猜到有这么回事以上均需要溢出后是 root 权限，并且是能绕过 PaX 的高级 exploit，另外 apach e杀掉后会自动重启如果想攻击 sshd，因为 iptables 将丢弃所有来自外网访问 sshd 的包，所以即使有远程溢出 (当然别忘了 PaX)，此路不通其他的方法，如果脚本攻击可以获得允许远程登录 ssh 用户的明文口令，或是利用脚本缺陷直接添加系统账号，这不仅需要系统 root 权限，而且 /etc/passwd 已经被 chattr 过，满足以上条件，并且攻破 server2，就有希望得到 shell但提升权限的机会不大!普通脚本攻击在此无效，当然如果该系统并不运行 CGI 的话，此路更是不通诚然入侵者很可能在 http 上破坏你的脚本，不过第三方的 web 安全加固暂不在本文讨论之列以上条件对大多数入侵者足够苛刻，可以说几乎不可能实现。 
但是我们为此也牺牲了不少，并且这些措施依赖一定的环境而实现安全性和易用性，需要读者站在自己的角度寻找他们的平衡点。  

上一页  [1] [2]