CC攻击的网页源码.. 我需要一份[是本机发包]

般cc攻击都是针对网站的域名进行攻击，比如网站域名是“xxx”，那么攻击者就在攻击工具中设定攻击对象为该域名然后实施攻击。

对于这样的攻击措施是在ⅡS上取消这个域名的绑定，让CC攻击失去目标。具体操作步骤是：打开“ⅡS管理器”定位到具体站点右键“属性”打开该站点的属性面板，点击IP地址右侧的“高级”按钮，选择该域名项进行编辑，将“主机头值”删除或者改为其它的值（域名）。

实例模拟测试，取消域名绑定后Web服务器的CPU马上恢复正常状态，通过IP进行访问连接一切正常。但是不足之处也很明显，取消或者更改域名对于别人的访问带来了不便，另外，对于针对IP的CC攻击它是无效的，就算更换域名攻击者发现之后，他也会对新域名实施攻击。

域名欺骗解析

如果发现针对域名的CC攻击，可以把被攻击的域名解析到127001这个地址上。知道127001是本地回环IP是用来进行网络测试的，如果把被攻击的域名解析到这个IP上，就可以实现攻击者自己攻击自己的目的，这样他再多的肉鸡或者代理也会宕机，让其自作自受。另外，当Web服务器遭受CC攻击时把被攻击的域名解析到国家有权威的政府网站或者是网警的网站，让其网警来收拾他们。现在一般的Web站点都是利用类似“新网”这样的服务商提供的动态域名解析服务，大家可以登录进去之后进行设置。

更改Web端口

一般情况下Web服务器通过80端口对外提供服务，因此攻击者实施攻击就以默认的80端口进行攻击，所以，我们可以修改Web端口达到防CC攻击的目的。运行ⅡS管理器，定位到相应站点，打开站点“属性”面板，在“网站标识”下有个TCP端口默认为80，我们修改为其他的端口就可以了。

ⅡS屏蔽IP

我们通过命令或在查看日志发现了CC攻击的源IP，就可以在ⅡS中设置屏蔽该IP对Web站点的访问，从而达到防范ⅡS攻击的目的。在相应站点的“属性”面板中，点击“目录安全性”选项卡，点击“IP地址和域名现在”下的“编辑”按钮打开设置对话框。在此窗口中我们可以设置“授权访问”也就是“白名单”，也可以设置“拒绝访问”即“黑名单”。比如我们可以将攻击者的IP添加到“拒绝访问”列表中，就屏蔽了该IP对于Web的访问。

IPSec封锁

IPSec是优秀的系统防火墙，在排除其他还有别的类型的DDOS攻击时，针对CC攻击可以用设置IP策略来对付攻击。以21912843这个IP为例子，笔者实际操作对该IP的访问封锁。

第一步：“开始→管理工具”，打开“本地安全设置”，右键点击“IP安全策略，在本地机器”选择“创建IP安全策略”，然后点击“下一步”，输入策略“名称”和“描述”。然后默认一路“下一步”创建了一个名为“封CC攻击”的IPSec策略。

第二步：右键点击“IP安全策略，在本地机器”选择“管理IP筛选器表和筛选器操作”，在打开的窗口中点“添加”，在“IP 筛选器列表”窗口添人同第一步的名称和描述信息。取消“使用添加向导”的勾选，然后点击“添加”。在“IP 筛选器 属性”窗口的“地址”选项下设置“源地址”为“19216816”，目标地址为“我的IP地址”，取消对“镜像”的勾选；点击“协议”选项卡，设置“协议类型”为“TCP”，设置“协议端口”为“从任意端口”到“此端口80”最后确定退出。

第三步：在“新规则 属性”窗口中点选刚才创建的“封CC攻击”规则，点击“筛选器操作”选项卡下的“添加”，点选“安全措施”下的“阻止”，在“常规”选项卡下为该筛选器命名为“阻止CC攻击”然后确定退出。

第四步：点选刚才创建的“阻止CC攻击”筛选器，一路“确定”退出IP策略编辑器，可以看到在组策略窗口的中创建成功一个名为“封CC攻击”的策略，然后右键点击该策略选择“指派”。这样就实现了对该IP的封锁。

防火墙

除了利用上述方法外，还可以通过第三方的防火墙进行防范，打开防护墙防火墙可以了，笔者以天鹰ddos防火墙为例进行演示。安装好天鹰ddos防火墙即可开启防护，傻瓜式配置界面，默认参数即可防护网站，误封较少，智能识别蜘蛛。

防CC攻击

使用加速乐云防火墙，若遇到CC攻击时，将自动启动，可以在2分钟内快速确定攻击IP，并封锁IP，完全拦截CC攻击。

我用过水星的路由,也出现过这类问题,就是在测试网络的时候,ping路由ping不通的希望你换一个路由,如TP-Link的,我上次就是换了一个,就可以了。水星的接在二级网络里面好象是可以用的。老兄试一下再接一次水晶头，如果网线做的没有问题的话，换一下路由的好。试一下ping 19216811能不能拼通。

只有发送没有接收，也就是路由器没有反应了，一是网线问题，二就是路由问题啦。

简单来说，TTL全程Time to Live，意思就是生存周期。

首先要说明ping命令是使用的网络层协议ICMP，所以TTL指的是一个网络层的网络数据包（package）的生存周期，这句话不懂的先回去复习OSI7层协议去。

第一个问题，为什么要有生存周期这个概念。

很显然，一个package从一台机器到另一台机器中间需要经过很长的路径，显然这个路径不是单一的，是很复杂的，并且很可能存在环路。如果一个数据包在传输过程中进入了环路，如果不终止它的话，它会一直循环下去，如果很多个数据包都这样循环的话，那对于网络来说这就是灾难了。所以需要在包中设置这样一个值，包在每经过一个节点，将这个值减1，反复这样操作，最终可能造成2个结果：包在这个值还为正数的时候到达了目的地，或者是在经过一定数量的节点后，这个值减为了0。前者代表完成了一次正常的传输，后者代表包可能选择了一条非常长的路径甚至是进入了环路，这显然不是我们期望的，所以在这个值为0的时候，网络设备将不会再传递这个包而是直接将他抛弃，并发送一个通知给包的源地址，说这个包已死。

其实TTL值这个东西本身并代表不了什么，对于使用者来说，关心的问题应该是包是否到达了目的地而不是经过了几个节点后到达。但是TTL值还是可以得到有意思的信息的。

每个操作系统对TTL值得定义都不同，这个值甚至可以通过修改某些系统的网络参数来修改，例如Win2000默认为128，通过注册表也可以修改。而Linux大多定义为64。不过一般来说，很少有人会去修改自己机器的这个值的，这就给了我们机会可以通过ping的回显TTL来大体判断一台机器是什么操作系统。

以我公司2台机器为例

看如下命令

D:\Documents and Settings\hx>ping 6115293131

Pinging 6115293131 with 32 bytes of data:

Reply from 6115293131: bytes=32 time=21ms TTL=118

Reply from 6115293131: bytes=32 time=19ms TTL=118

Reply from 6115293131: bytes=32 time=18ms TTL=118

Reply from 6115293131: bytes=32 time=22ms TTL=118

Ping statistics for 6115293131:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss

Approximate round trip times in milli-seconds:

Minimum = 18ms, Maximum = 22ms, Average = 20ms

D:\Documents and Settings\hx>ping 6115210440

Pinging 6115210440 with 32 bytes of data:

Reply from 6115210440: bytes=32 time=28ms TTL=54

Reply from 6115210440: bytes=32 time=18ms TTL=54

Reply from 6115210440: bytes=32 time=18ms TTL=54

Reply from 6115210440: bytes=32 time=13ms TTL=54

Ping statistics for 6115210440:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss

Approximate round trip times in milli-seconds:

Minimum = 13ms, Maximum = 28ms, Average = 19ms

第一台TTL为118，则基本可以判断这是一台Windows机器，从我的机器到这台机器经过了10个节点，因为128-118=10。而第二台应该是台Linux，理由一样64-54=10。

了解了上面的东西，可能有人会有一些疑问，例如以下：

1，不是说包可能走很多路径吗，为什么我看到的4个包TTL都是一样的，没有出现不同？

这是由于包经过的路径是经过了一些最优选择算法来定下来的，在网络拓扑稳定一段时间后，包的路由路径也会相对稳定在一个最短路径上。具体怎么算出来的要去研究路由算法了，不在讨论之列。

2，对于上面例子第二台机器，为什么不认为它是经过了74个节点的Windows机器？因为128-74=54。

对于这个问题，我们要引入另外一个很好的ICMP协议工具。不过首先要声明的是，一个包经过74个节点这个有些恐怖，这样的路径还是不用为好。

要介绍的这个工具是tracert（nix下为traceroute），让我们来看对上面的第二台机器用这个命令的结果

D:\Documents and Settings\hx>tracert 6115210440

Tracing route to 6115210440 over a maximum of 30 hops

1 13 ms 16 ms 9 ms 10120321

2 9 ms 9 ms 11 ms 219233244105

3 12 ms 10 ms 10 ms 219233238173

4 15 ms 15 ms 17 ms 21923323813

5 14 ms 19 ms 19 ms 2029622273

6 14 ms 17 ms 13 ms 20296222121

7 14 ms 15 ms 14 ms 611528186

8 15 ms 14 ms 13 ms 6115287162

9 16 ms 16 ms 28 ms 611529926

10 12 ms 13 ms 18 ms 611529994

11 14 ms 18 ms 16 ms 6115210440

Trace complete

从这个命令的结果能够看到从我的机器到服务器所走的路由，确实是11个节点（上面说10个好像是我犯了忘了算0的错误了，应该是64-54+1，嘿嘿），而不是128的TTL经过了70多个节点。

既然已经说到这里了，不妨顺便说说关于这两个ICMP命令的高级一点的东西。

首先是ping命令，其实ping有这样一个参数，可以无视操作系统默认TTL值而使用自己定义的值来发送ICMP Request包。

例如还是用那台Linux机器，用以下命令：

D:\Documents and Settings\hx>ping 6115210440 -i 11

Pinging 6115210440 with 32 bytes of data:

Reply from 6115210440: bytes=32 time=10ms TTL=54

Reply from 6115210440: bytes=32 time=13ms TTL=54

Reply from 6115210440: bytes=32 time=10ms TTL=54

Reply from 6115210440: bytes=32 time=13ms TTL=54

Ping statistics for 6115210440:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 10ms, Maximum = 13ms, Average = 11ms

D:\Documents and Settings\hx>

这个命令我们定义了发包的TTL为11，而前面我们知道，我到这台服务器是要经过11个节点的，所以这个输出和以前没什么不同。现在再用这个试试看：

D:\Documents and Settings\hx>ping 6115210440 -i 10

Pinging 6115210440 with 32 bytes of data:

Reply from 611529994: TTL expired in transit

Reply from 611529994: TTL expired in transit

Reply from 611529994: TTL expired in transit

Reply from 611529994: TTL expired in transit

Ping statistics for 6115210440:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

D:\Documents and Settings\hx>

可以看到，结果不一样了，我定义了TTL为10来发包，结果是TTL expired in transit就是说在到达服务器之前这个包的生命周期就结束了。注意看这句话前面的ip，这个ip恰好是我们前面tracert结果到服务器之前的最后1个ip，包的TTL就是在这里减少到0了，根据我们前面的讨论，当TTL减为0时设备会丢弃包并发送一个TTL过期的ICMP反馈给源地址，这里的结果就是最好的证明。

通过这里再次又证明了从我机器到服务器是经过了11个节点而不是70多个，呵呵。

最后再巩固一下知识，有人可能觉得tracer这个命令很神奇，可以发现一个包所经过的路由路径。其实这个命令的原理就在我们上面的讨论中。

想象一下，如果我给目的服务器发送一个TTL为1的包，结果会怎样？

根据前面的讨论，在包港出发的第一个节点，TTL就会减少为0，这时这个节点就会回应TTL失效的反馈，这个回应包含了设备本身的ip地址，这样我们就得到了路由路径的第一个节点的地址。

因此，我们继续发送TTL=2的包，也就受到第二个节点的TTL失效回应

依次类推，我们一个一个的发现，当最终返回的结果不是TTL失效而是ICMP Response的时候，我们的tracert也就结束了，就是这么简单。

顺便补一句ping命令还有个-n的参数指定要发包的数量，指定了这个数字就会按照你的要求来发包了而不是默认的4个包。如果使用-t参数的话，命令会一直发包直到你强行中止它。

Ping是个使用频率极高的网络诊断程序，用于确定本地主机是否能与另一台主机交换（发送与接收）数据报。根据返回的信息，你就可以推断TCP/IP参数是否设置得正确以及运行是否正常。需要注意的是：成功地与另一台主机进行一次或两次数据报交换并不表示TCP/IP配置就是正确的，你必须执行大量的本地主机与远程主机的数据报交换，才能确信TCP/IP的正确性。

您现在的位置是： 上海IT外包服务网 ->服务器架设 ->http服务器 ->

本文关键字: 熟练掌握ping的用法

如何用好网管小工具

在进行网络管理和排除故障时，最方便的是使用操作系统配备的工具。Windows和Unix都配备有一些工具，用这些工具可以探察网络状态，查明故障原因。即使不能查明故障原因，至少也可以弄清问题的性质，以便进一步处理。

表1列出了Windows和Unix中附带的典型命令。操作系统不同使用的命令不同，即使同样功能的命令，在不同操作系统中，名称也不一样。在Unix和Windows中，命令所备有的命令选择参数的种类以及使用方法也不同。下面我们以Windows 、TCP/IP通信协议为例，加以说明。

确认TCP/IP设定 ifconfig ipconfig ipconfig，winipcfg

检查路由 traceroute tracert tracert

显示、编辑路由表 route route route

显示收/发包的统计信息 netstat netstat netstat

确认DNS机构 nslookup nslookup －

确认NBT的功能 nmblookup nbtstat nbtstat

首先要正确掌握命令的执行顺序，以便能迅速确定问题的性质。

首先，用ping查明问题性质，而后使用其他合适的工具。ping是用于确认是否能与目标计算机进行通信的命令。这是大家最熟悉的一个命令。遗憾的是，即使通过执行ping，确认了不能正常进行通信，但这还不能解决问题。如果有效活用ping命令所备有的功能，可以将问题分成两类(参见图1）：不能进行TCP/IP通信和名字解析过程有问题。

不能进行TCP/IP通信时，使用ipconfig、tracert、route、netstat等工具；而当名字解析机构有问题时，nslookup、nbtstat等命令将发挥作用。

熟练掌握ping的用法

ping是对TCP/IP网络上的任意一台计算机发送一个请求ICMP(Internet Control Message Protocol)应答的小信息包程序。接收这个信息包的计算机，要返回个“应答”包。收到了“应答”包，就可确认可进行通信。ping除了确认通信外，还可以确认名字解析，测定通信所需的时间等。

验证与远程计算机的连接。该命令只有在安装了 TCP/IP 协议后才可以使用。

ping [-t] [-a] [-n count] [-l length] [-f] [-i ttl] [-v tos] [-r count] [-s count] [[-j computer-list] | [-k computer-list]] [-w timeout] destination-list

参数

-t

Ping 指定的计算机直到中断。

-a

将地址解析为计算机名。

-n count

发送 count 指定的 ECHO 数据包数。默认值为 4。

-l length

发送包含由 length 指定的数据量的 ECHO 数据包。默认为 32 字节；最大值是 65,527。

-f

在数据包中发送“不要分段”标志。数据包就不会被路由上的网关分段。

-i ttl

将“生存时间”字段设置为 ttl 指定的值。

-v tos

将“服务类型”字段设置为 tos 指定的值。

-r count

在“记录路由”字段中记录传出和返回数据包的路由。count 可以指定最少 1 台，最多 9 台计算机。

-s count

指定 count 指定的跃点数的时间戳。

-j computer-list

利用 computer-list 指定的计算机列表路由数据包。连续计算机可以被中间网关分隔（路由稀疏源）IP 允许的最大数量为 9。

-k computer-list

利用 computer-list 指定的计算机列表路由数据包。连续计算机不能被中间网关分隔（路由严格源）IP 允许的最大数量为 9。

-w timeout

指定超时间隔，单位为毫秒。

destination-list

指定要 ping 的远程计算机

时间：2018-07-26

Q: 什么是网络连接？

A: 网络连接是传输层定义的概念，在传输层以下只存在网络数据包的相互交换。

所谓连接，其实也不是在网络上有一条真实存在的数据通道。只要通信双方在一段时间内持续保持数据包交换，就可以视为双方建立的连接并没有断开。

连接的建立是依托于TCP协议的三次握手，一旦连接已经建立完毕，通信双方就可以复用这条虚拟通道进行数据交换。如果连接保持长时间工作一直没有被中断，那么这样的TCP连接就俗称为长连接。

Message Queue Telemetry Transport ，中文直译： 消息队列遥测传输协议 。

在MQTT协议被设计出来的年代，还没有物联网这么时髦的词汇，当年叫做 遥测设备 。

MQTT协议真正开始声名鹊起的原因，是其正好恰恰踩中移动互联网发展的节拍，为消息推送场景提供了一个既简便又具有良好扩展性的现成解决方案。

http://docsoasis-openorg/mqtt/mqtt/v311/os/mqtt-v311-oshtml

可以看出，MQTT对消息头的规定十分精简， 固定头部占用空间大小仅为1个字节 ，一个最小的报文占用的空间也 只有两个字节 （带一字节的长度标识位）。

这也是MQTT协议针对不稳定及带宽低下的网络环境做出的特定设计 - - - - 尽可能地节省一切不必要的网络开销 。

Q：为什么MQTT协议需要心跳报文(PINGREQ, PINGRESP)来维护连接状态，只监控该TCP的连接状态是否可以实现目的？

A: TCP数据传输默认的超时时间过长，不符合应用层上细粒度的要求。

TCP数据传输超时的情况可分成三种： 服务端断开 、 客户端断开 、 中间网络断开 。

在前两种场景下，若断开操作是一方主动发起的，即表示为TCP连接正常结束，双方走四次挥手流程；若程序异常结束，则会触发被动断开事件，通信另一方也能立刻感知到本次连接所打开的 Socket 出现中断异常。

唯独中间网络的状态是通信双方不能掌握的。 在Linux系统下 ，TCP的连接超时由内核参数来控制，如果通信中的一方没有得到及时回复，默认会主动再尝试 6次 。如果还没有得到及时回应，那么其才会认定本次数据超时。

连带首次发包与六次重试，Linux系统下这7次发包的超时时间分别为 2的0次方 至 2的6次方 ，即1秒、2秒、4秒、8秒、16秒、32秒、64秒，一共127秒。MQTT协议认为如此长的超时时间对应用层而言粒度太大，因此其在应用层上还单独设计属于自身的心跳响应控制。常见的MQTT连接超时多被设定为 60秒 。

扩展知识 - TCP的KeepAlive机制： http://hengyunabcgithubio/why-we-need-heartbeat/

由通信中的 报文标识符 ( Packet Identifier )传达。

Q：仅Publish与Pubrec能保证消息只被投递一次吗？

A： 业务上可以实现，但MQTT协议并没有如此设计，原因如下：

每个消息都会拥有属于自己的报文标识符，但如果需要两次数据交换就实现消息仅只收到一次，就需要通信双方记录下每次使用的报文标识符，并且在处理每一条消息时都需要去重处理，以防消息被重复消费。

但MQTT协议最初被设计的工作对象是轻量级物联设备，为此在协议的设计中报文标识符被约定为 可重用 ，以减少对设备性能的消耗，换回的代价不得不使用四次网络数据交换，才能确保消息正好被消费一次。

Q：两个不同客户端在发布与订阅同一Topic下的消息时，都可以提出通信Qos要求，此时以哪项为基准？

A： 伪命题，故意在分享时埋下坑，等人来踩。

两个不同客户端的通信是需要 Broker 进行中转，而不是直连。因此，通信中存在两个不同的会话，双方的Qos要求仅仅作用于它们与 Broker 之间的会话，最终的Qos基准只会向最低要求方看齐。

例：遗嘱消息的正确使用方式可参考此篇文章： https://wwwhivemqcom/blog/mqtt-essentials-part-9-last-will-and-testament

虽然可以借助 Retain Message 实现绑定一条消息至某个Topic，以达到消息的暂时保留目的。

但首先 Retain Message 并不是为存储场景而设计的，再次MQTT协议并没有对消息的持久化作出规定，也就是说Broker重启后，现有保留消息也将丢失。

Q：两种特殊消息的使用场景？

A： 遗嘱消息，多用于客户端间获取互相之间异常断线的消息通知；

保留消息，可保存 最近一条 广播通知，多用于公告栏信息的发布。

Eclipse Mosquitto ：MQTT协议的最小集实现

有 EMQ , HiveMQ , RabbitMQ MQTT Adapter 等。

Qos=2 消息保障的网络I/O次数过多，如果不是必需，尽少在程序里使用此类消息。

毕竟当初其设计的目的是为了减少设备的性能占用，但若应用场景并不是物联网，而是用于手机、电脑或浏览器端等现在已不缺性能的设备上，最好在报文体中，使用UUID生成全局唯一的消息ID，然后自行在业务解析中判断此报文是否被消费过。

或者，业务方在处理消息时保证其被消费的幂等性，也可消除重复消息对系统带来的影响。

正如MQTT协议并没有依赖TCP连接状态，自己在应用层协议上实现心跳报文来控制连接状态，业务方作为MQTT协议的使用者，也不要完全依赖协议的工作状态，而是依托MQTT协议建立属于业务本身的信息汇报机制，以加强系统的稳健性。

Retain Message 可视为客户端主动拉取的行为。如果业务系统采用 HTTP+MQTT 双协议描述业务过程，主动拉取的操作也可使用 HTTP 请求替代。

作为一个长连接型的应用，上线前需要根据业务量级，评估对操作系统 端口数 与 文件描述符 的占用要求，以防服务器资源被打满。

在服务端的配置文件和客户端的连接参数中，都拥有 max_inflight_messages 此项配置，来维护 Qos=1 or 2 消息是否被成功消费的状态。

MQTT 最初被设计为物联网级的通信协议，因此此参数的默认配额较小（大多数情况下被限制到10至20）。

但如果将MQTT协议应用至手机、PC或Web端的推送场景时，硬件性能已不在是瓶颈，在实际使用中推荐把此参数调大。

Mosquitto提供Bridge功能，需要我们自己配置。

Bridge 意为桥接，当我们把两台Broker桥接在一起时，只需要修改一台Broker的配置，填上另一台Broker的运行地址。前一台Broker将作为客户端发布与订阅后一台Broker的所有Topic，实现消息互通的目的。

桥接带来的问题有以下几点：

我的建议：

Websockets协议被设计的目的是为浏览器提供一个全双工的通信协议，方便实现消息推送功能。

在Websockets协议被设计出来前，受限于HTTP协议的一问一答模型，消息的推送只能靠轮询来实现，在资源消耗与时效性保障上，均难以达到令人满意的效果。

Websockets协议复用了HTTP协议的头部信息，告知浏览器接下来的操作将触发协议升级，然后通信双方继续复用HTTP的Header，但报文内容已转变为双方均接受的新协议的格式。

Websockets协议改进了网页浏览中的消息推送的方式，因此被广泛应用在聊天、支付通知等实时性要求比较高的场合下。

MQTT协议重点在于 消息队列的实现，其对消息投递的方式作出约定，并提供一些额外的通信保障 。

MQTT可采取原生的TCP实现，也有基于Websockets的实现版本。当然后者在网络字节的利用率上，不如前者那么精简。但浏览器端无法直接使用TCP协议，所以就只能基于Websockets协议开发。

不过基于Websockets的应用也有方便之处：一是证书不需要额外配置，直接与网站共用一套基础设施；二是可使用 Nginx 等工具管理流量，与普通HTTP流量可共用一套配置方法。

MQTT非常适合入门，原因如下：

实际的应用场景远比理想中的复杂，无法一招走遍天下，必须做好取舍。

MQTT协议在这方面做得很优秀，以后工作中可以作为参考，设计好自己负责的业务系统。