起因：上周某台网站连接异常。该机器很公网地址+端口有一一映射关系，即可以对外提供各类服务，包括网站、apk的下载地址等等。然而这台机器的管理却有是非混乱，没人能说清上面谁的服务部署在哪里，有些年头了。需要进行问题定位。
1、说点其他
在ubuntu服务器上安装tomcat也好，apache httpd也好，我的建议是尽量不通过apt-get的方式，而是直接从相关官网中下载进行安装。利用apt-get的方式，通常bin放在一个目录，log/放在一个目录，真不好找。特别是出现多版本的情况。
2、问题定位
最烦就是一堆人说连不上啊，连不上，然后问你们的网站部署在哪个位置，apache还是tomcat，就没人啃声。以开始以为是tomcat，从log中看到是AJP报错，但是关闭了AJP不解决，后来终于有人说apache，也说了project布在哪里了，但是log位置就真没找到。【有些管理，一开始混乱，最后谁都说不清，物是人非了】
1）定位是网络设置的问题，还是服务本身的问题。由于内网/公网最近也在调整，第一步需要定位位置。结果，内网连接也出现异常。
【定位：判断与服务本身有关】
2）确定了apache，后ps一下，发现很多apache2的进程，太多了，显然不正常，因为这个网站已经无法连接，而且平时就没什么人，不会有这么多的并发进程。进一步确定apache服务出现问题。然后因没人用tomcat6，关掉。
【定位：apache问题，和os阿土无关】
3）通过netstat -al查看网络情况
怎么回事，收攻击呗。通过tcpdump port 80进行一步进行了确认。有人认为可能很多人在连，我的看法很简单：你们网站很活跃吗？特别是现在都经常连不上的情况，有这么多锲而不舍的人吗？结论是：当然木有。
由于SYN_RECV已经失效后等待CLOSE_WAIT，这是TCP的keepalive机制，在网上查了一下，有专门的SYN供给，“客户端在短时间内伪造大量不存在的IP地址，向服 务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未 连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。”
【定位：受到了SYN的攻击】
4）尝试解决：情况就是大量的连接超过了apache服务器设定的上限，但是失效。在防火墙上针对该机器开启防syn flood。结果是一会好一会不行，看来防火墙也是根据阈值判断进行处理。
考虑将apache的keepAlive off掉，找配置文件就找了半天。也不知道对不对，修改了，似乎没有起不大。
具体可以查看百度百科的SYN。
防火墙上修改策略，进行了Connection Flood供给防范。似乎问题就解决了。出现很多TIME_WAIT，可以参考进一步sysctl.conf，参见http://kerry.blog.51cto.com/172631/105233/，但是能在防火墙上解决的，尽量不修改OS上的设置。
【情况：现象貌似好转，但只是拖延，隔更长的时间网站打开仍有问题，SYN只是表象】
5）峰回路转，真正是discuz的漏洞。 正当我们通过防火墙设置规则，使得网站展示恢复之际。大家终于能比较正常地爬上网站，有人发现一项冷清的论坛突然又几十万的帖子。这是个重要线索，被黑或者有漏洞被直接写数据库。通过netstate查，发现有不少mysqld.sock的连接，着说明漏洞的概率大，接着说是php的，那概率就更大了。又接着说是在discuz的基础上开发，而开发之后一直没有更新，也就是discuz的版本是两、三年前的，在网上search，discuz的php漏洞开始广为周知，存在mysql注入漏洞，符合观察的现象。
补充，判断是不是cc攻击，只要top一下，看看CPU和内存的使用情况就可以了。看起来正常，所以认为不是CC攻击，而是php网页漏洞。
因此，简单粗暴的方式是关闭discuz，让网站先恢复起来。然后更新discuz，这是后话。
【情况：问题解决】
【后话：
1、如何定位问题和解决问题很重要，问题总可能会出现。
2、安全漏洞不一定出现在我们自己的代码，很可能出现在所依赖的代码或开发环境，需要升级封堵漏洞。但是项目是时效性，而维护是长期性的，所以维护人员应该了解相关情况，提醒或进行更新】
