客户的网站突然访问不正常了，在外部，访问时断时续，只要刷新，多刷几次，总是能够看到正常页面，当然，多数时候都是页面无法访问。
我经过观察，反复测试，发现在客户的自己的机子上通过localhost访问，一点问题也没有。一个奇怪的现象，
chrome浏览器，在页面不正常的时候，提示：
拒绝了我们的请求，请检查
网络连接
代理服务器和防火墙。
我开始判断客户的网络抽风，防火墙那里出了问题，导致连接没有到达apache。防火墙那边的技术反馈说没有问题。看到服务器上apache的负载明显很低。
花了一天的时间，观察和总结黑客的攻击行为，日志文件看了又看。始终没有思绪。从日志里面来看，没有多少用户访问，每个请求的访问都在日志里面。
到了晚上八点，网站突然正常了。
apache的错误日志、访问日志都没有异常。没有以往的攻击时的现象。检查windows日志，也没有异常。后来突然发现，apache的日志里面还是有一点不一样的。Apache 工作线程的重启时间间隔发生了变化：
[Sat Jan 05 05:30:39.283070 2019] [mpm_winnt:notice] [pid 6644:tid 208] AH00354: Child: Starting 150 worker threads.
…..
[Sat Jan 05 05:32:24.050049 2019] [mpm_winnt:notice] [pid 5668:tid 208] AH00354: Child: Starting 150 worker threads.
重启时间间隔，突然变小了，连接竟然被消耗掉了。 apache的连接确实被消耗掉了，平时1000个连接，需要10多分钟才能用完。
我将其归纳为空连接： 经过反复的对比，观察异常现象和各种日志信息，初步判断这次异常现象是一次DDOS攻击行为，与以前的DDOS有所不同，这次是黑客通过占用连接端口，建立空连接（这种连接apache没有对它做后续处理），导致网络阻塞，影响了正常用户访问。
我在网上查找空连接，还是找到了相关的信息。
例如，攻击者与被攻击目标完成三次握手后，立刻发送FIN或RST报文，释放本端连接，同时快速发起新的连接，以此来消耗被攻击目标的系统资源。
http://blog.sina.com.cn/s/blog_69c81c3e0102x9wj.html
DDoS攻击--连接耗尽-慢连接-异常报文攻击防护详解(TCP)
在三次握手完成之后，内核会为每个连接分配相应的结构，保存TCP连接相应的控制信息，接收缓冲和发送缓冲。默认情况下占用大概10K的内存。 通常的连接耗尽攻击会发起10~ 100w的连接，大致占用100M ~ 1G的内存，也许你会觉得很少。但大量的空连接占用的不只是这些，攻击者通常还会建立后立马会fin报文结束连接。每个TCP连接都需要维护状态。不断的发起和断开，系统将不断分配和释放资源，将会大大增加系统的调度负担，同时上层应用也将在建立和断开连接上消耗大量的CPU，造成服务器不可以用。
https://blog.csdn.net/qq_34777600/article/details/81948586
黑客通过建立大量的空连接，对正常用户访问网站造成了阻塞。这是我们初步的判断。
初步找到了原因，但是不是很确定。
这种空连接，由于apache没有返回，所以对于流量影响不大。它只是消耗系统的连接资源，导致正常用户服务不可用。
http://blog.51cto.com/tianshili/1640519
关于网站的SYN_RECV(SYN_RECEIVED)***的防范措施
SYN 攻击是最常见又最容易被利用的一种攻击手法。相信很多人还记得2000年YAHOO网站遭受的攻击事例，当时黑客利用的就是简单而有效的SYN攻击，有些 网络蠕虫病毒配合SYN攻击造成更大的破坏。本文介绍SYN攻击的基本原理、工具及检测方法，并全面探讨SYN攻击防范技术。
一、TCP握手协议
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
初步找到原因了，在客户的抱怨之下，晚上12点才睡觉。
第二天，一大早，客户又打电话，网站又抽风了，让我远程协助。用户的服务器为windows，我使用netstat命令查看网络连接的状态：
发现目标，同一个IP，不断端口，不断的syn_received
立马采取措施，在防火墙里面，加了一个入站规则，把这个顶风作案的IP给封掉。
封掉以后，世界平静了，网站正常了。
就这个样，临时的解决了这个问题。又过了两天，网站又不正常了，同样的现状。靠，黑客换了个IP，这次还能变换IP。
在网上找打了window下面syn攻击的防御措施，从操作系统的层面，作出防范，按照文档，修改注册表里面的参数，后续观察，确实有效。
■SynAttackProtect机制
为防范SYN攻击，win2000系统的tcp/ip协议栈内嵌了SynAttackProtect机制，Win2003系统也采用此机制。SynAttackProtect机制是通过关闭某些socket选项，增加额外的连接指示和减少超时时间，使系统能处理更多的SYN连接，以达到防范SYN攻击的目的。默认情况下，Win2000操作系统并不支持SynAttackProtect保护机制，需要在注册表以下位置增加SynAttackProtect键值：
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
当SynAttackProtect值（如无特别说明，本文提到的注册表键值都为十六进制）为0或不设置时，系统不受SynAttackProtect保护。
当SynAttackProtect值为1时，系统通过减少重传次数和延迟未连接时路由缓冲项（route cache entry）防范SYN攻击。
当SynAttackProtect值为2时（Microsoft推荐使用此值），系统不仅使用backlog队列，还使用附加的半连接指示，以此来处理更多的SYN连接，使用此键值时，tcp/ip的TCPInitialRTT、window size和可滑动窗囗将被禁止。
我们应该知道，平时，系统是不启用SynAttackProtect机制的，仅在检测到SYN攻击时，才启用，并调整tcp/ip协议栈。那么系统是如何检测SYN攻击发生的呢？事实上，系统根据TcpMaxHalfOpen,TcpMaxHalfOpenRetried 和TcpMaxPortsExhausted三个参数判断是否遭受SYN攻击。
TcpMaxHalfOpen 表示能同时处理的最大半连接数，如果超过此值，系统认为正处于SYN攻击中。Win2000 server默认值为100，Win2000 Advanced server为500。
TcpMaxHalfOpenRetried定义了保存在backlog队列且重传过的半连接数，如果超过此值，系统自动启动SynAttackProtect机制。Win2000 server默认值为80，Win2000 Advanced server为400。
TcpMaxPortsExhausted 是指系统拒绝的SYN请求包的数量，默认是5。
如果想调整以上参数的默认值，可以在注册表里修改（位置与SynAttackProtect相同）
■ SYN cookies技术
我们知道，TCP协议开辟了一个比较大的内存空间backlog队列来存储半连接条目，当SYN请求不断增加，并这个空间，致使系统丢弃SYN连接。为使半连接队列被塞满的情况下，服务器仍能处理新到的SYN请求，SYN cookies技术被设计出来。
SYN cookies应用于linux、FreeBSD等操作系统，当半连接队列满时，SYN cookies并不丢弃SYN请求，而是通过加密技术来标识半连接状态。
在TCP实现中，当收到客户端的SYN请求时，服务器需要回复SYN+ACK包给客户端，客户端也要发送确认包给服务器。通常，服务器的初始序列号由服务器按照一定的规律计算得到或采用随机数，但在SYN cookies中，服务器的初始序列号是通过对客户端IP地址、客户端端囗、服务器IP地址和服务器端囗以及其他一些安全数值等要素进行hash运算，加密得到的，称之为cookie。当服务器遭受SYN攻击使得backlog队列满时，服务器并不拒绝新的SYN请求，而是回复cookie（回复包的SYN序列号）给客户端， 如果收到客户端的ACK包，服务器将客户端的ACK序列号减去1得到cookie比较值，并将上述要素进行一次hash运算，看看是否等于此cookie。如果相等，直接完成三次握手（注意：此时并不用查看此连接是否属于backlog队列）。
在RedHat linux中，启用SYN cookies是通过在启动环境中设置以下命令来完成：
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
■ 增加最大半连接数
大量的SYN请求导致未连接队列被塞满，使正常的TCP连接无法顺利完成三次握手，通过增大未连接队列空间可以缓解这种压力。当然backlog队列需要占用大量的内存资源，不能被无限的扩大。
WIN2000：除了上面介绍的TcpMaxHalfOpen, TcpMaxHalfOpenRetried参数外，WIN2000操作系统可以通过设置动态backlog(dynamic backlog)来增大系统所能容纳的最大半连接数，配置动态backlog由AFD.SYS驱动完成，AFD.SYS是一种内核级的驱动，用于支持基于window socket的应用程序，比如ftp、telnet等。AFD.SYS在注册表的位置： HKLM\System\CurrentControlSet\Services\AFD\ParametersEnableDynamicBacklog值为1时，表示启用动态backlog，可以修改最大半连接数。
MinimumDynamicBacklog表示半连接队列为单个TCP端囗分配的最小空闲连接数，当该TCP端囗在backlog队列的空闲连接小于此临界值时，系统为此端囗自动启用扩展的空闲连接（DynamicBacklogGrowthDelta），Microsoft推荐该值为20。
MaximumDynamicBacklog是当前活动的半连接和空闲连接的和，当此和超过某个临界值时，系统拒绝SYN包，Microsoft推荐MaximumDynamicBacklog值不得超过2000。
DynamicBacklogGrowthDelta值是指扩展的空闲连接数，此连接数并不计算在MaximumDynamicBacklog内，当半连接队列为某个TCP端囗分配的空闲连接小于MinimumDynamicBacklog时，系统自动分配DynamicBacklogGrowthDelta所定义的空闲连接空间，以使该TCP端囗能处理更多的半连接。Microsoft推荐该值为10。
LINUX：Linux用变量tcp_max_syn_backlog定义backlog队列容纳的最大半连接数。在Redhat 7.3中，该变量的值默认为256，这个值是远远不够的，一次强度不大的SYN攻击就能使半连接队列占满。我们可以通过以下命令修改此变量的值：
# sysctl -w net.ipv4.tcp_max_syn_backlog="2048"
Sun Solaris Sun Solaris用变量tcp_conn_req_max_q0来定义最大半连接数，在Sun Solaris 8中，该值默认为1024，可以通过add命令改变这个值：
# ndd -set /dev/tcp tcp_conn_req_max_q0 2048
HP-UX：HP-UX用变量tcp_syn_rcvd_max来定义最大半连接数，在HP-UX 11.00中，该值默认为500，可以通过ndd命令改变默认值：
#ndd -set /dev/tcp tcp_syn_rcvd_max 2048
■缩短超时时间
上文提到，通过增大backlog队列能防范SYN攻击；另外减少超时时间也使系统能处理更多的SYN请求。我们知道，timeout超时时间，也即半连接存活时间，是系统所有重传次数等待的超时时间总和，这个值越大，半连接数占用backlog队列的时间就越长，系统能处理的SYN请求就越少。为缩短超时时间，可以通过缩短重传超时时间（一般是第一次重传超时时间）和减少重传次数来实现。
Win2000第一次重传之前等待时间默认为3秒，为改变此默认值，可以通过修改网络接囗在注册表里的TcpInitialRtt注册值来完成。重传次数由TcpMaxConnectResponseRetransmissions 来定义，注册表的位置是：HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters registry key。
当然我们也可以把重传次数设置为0次，这样服务器如果在3秒内还未收到ack确认包就自动从backlog队列中删除该连接条目。
LINUX：Redhat使用变量tcp_synack_retries定义重传次数，其默认值是5次，总超时时间需要3分钟。
Sun Solaris Solaris 默认的重传次数是3次，总超时时间为3分钟，可以通过ndd命令修改这些默认值。