• TCP 包类型


    标志位  

      在TCP层,有个FLAGS字段,这个字段有以下几个标识:SYN(synchronous建立联机),ACK(acknowledgement 确认),PSH(push传送),FIN(finish结束),RST(reset重置),URG(urgent紧急)。其中,对于我们日常的分析有用的就是前面的五个字段。它们的含义是:

    • SYN:建立连接
    • FIN:关闭连接
    • ACK:响应
    • PSH:有DATA数据传输
    • RST:连接重置

      ACK是可能与SYN,FIN等同时使用的,比如SYN和ACK可能同时为1,它表示的就是建立连接之后的响应,如果只是单个的一个SYN,它表示的只是建立连接。TCP的几次握手就是通过这样的ACK表现出来的。

      但SYN与FIN是不会同时为1的,因为前者表示的是建立连接,而后者表示的是断开连接。

      RST一般是在FIN之后才会出现为1的情况,表示的是连接重置。

      一般地,当出现FIN包或RST包时,我们便认为客户端与服务器端断开了连接;而当出现SYN和SYN+ACK包时,我们认为客户端与服务器建立了一个连接。

      PSH为1的情况,一般只出现在 DATA内容不为0的包中,也就是说PSH为1表示的是有真正的TCP数据包内容被传递。

    RST

      TCP的异常终止是相对于正常释放TCP连接的过程而言的,我们都知道,TCP连接的建立是通过三次握手完成的,而TCP正常释放连接是通过四次挥手来完成,但是有些情况下,TCP在交互的过程中会出现一些意想不到的情况,导致TCP无法按照正常的四次挥手来释放连接。如果此时不通过其他的方式来释放TCP连接的话,这个TCP连接将会一直存在,占用系统的部分资源。在这种情况下,我们就需要有一种能够释放TCP连接的机制,这种机制就是TCP的reset报文。

    场景:

    • 客户端尝试与服务器未对外提供服务的端口建立TCP连接,服务器将会直接向客户端发送reset报文。
    • 客户端建立连接时,接收到服务器的syn超时,客户端发送reset报文。
    • 客户端和服务器的某一方在交互的过程中发生异常(如程序崩溃等),该方系统将向对端发送reset报文,告之对方释放相关的TCP连接。
    • 接收端收到TCP报文,但是发现该TCP的报文,并不在其已建立的TCP连接列表内,则其直接向对端发送reset报文。
    • 在交互的双方中的某一方长期未收到来自对方的确认报文,则其在超出一定的重传次数或时间后,会主动向对端发送reset报文释放该TCP连接。
    • 有些应用开发者在设计应用系统时,会利用reset报文快速释放已经完成数据交互的TCP连接,以提高业务交互的效率。

    利用:

    • 安全设备利用reset报文阻断异常连接:安全设备(如防火墙、入侵检测系统等)在发现某些可疑的TCP连接时,会构造交互双方的reset报文发给对端,让对端释放该TCP连接。比如入侵检测检测到黑客攻击的TCP连接,其构造成被攻击端给黑客主机发送reset报文,让黑客主机释放攻击连接。
    • 利用reset报文实施攻击:安全设备可以利用reset报文达到安全防护的效果,黑客和攻击者也可以利用reset报文实现对某些主机的入侵和攻击,最常见的就是TCP会话劫持攻击。

    SYN Flood

      SYN Flood是指利用TCP协议缺陷,发送大量伪造的TCP连接请求(SYN包),从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式。

      解决方法:

    • 增加积压队列:在内核里有个队列用来存放还没有确认ACK的客户端请求,当等待的请求数大于tcp_max_syn_backlog时,后面的会被丢弃。所以,适当增大这个值,可以在压力大的时候提高握手的成功率。推荐大于1024。
    • 回收最早的半开TCP连接:一旦积压已被填补,另一个缓解策略就是覆盖最早的半开式连接。这种策略要求合法连接可以在比可以填充恶意SYN数据包的积压时间更短的时间内完全建立。当攻击量增加时,或者如果积压量太小而不实际,这种特定的防御就会失败。
    • 减少ack重试:这个是三次握手中,服务器回应ACK给客户端里,重试的次数。默认是5。显然攻击者是不会完成整个三次握手的,因此服务器在发出的ACK包在没有回应的情况下,会重试发送。当发送者是伪造IP时,服务器的ACK回应自然是无效的。为了防止服务器做这种无用功,可以把tcp_synack_retries设置为0或者1。因为对于正常的客户端,如果它接收不到服务器回应的ACK包,它会再次发送SYN包,客户端还是能正常连接的,只是可能在某些情况下建立连接的速度变慢了一点。
    • SYN cookie:当半连接的请求数量超过了 tcp_max_syn_backlog 时,内核就会启用SYN cookie机制,不再把半连接请求放到队列里,而是用SYN cookie来检验。SYN cookie是非常巧妙地利用了TCP规范来绕过了TCP连接建立过程的验证过程,从而让服务器的负载可以大大降低。在三次握手中,当服务器回应(SYN + ACK)包后,客户端要回应一个n + 1的ACK到服务器,其中n是服务器自己指定的。当启用tcp_syncookies时,backlog满了后,linux内核生成一个特定的n值,并不把客户端的连接放到半连接的队列里(即没有存储任何关于这个连接的信息,不浪费内存)。当客户端提交第三次握手的ACK包时,linux内核取出n值,进行校验,如果通过,则认为这个是一个合法的连接。(backlog表示全连接队列长度)

      https://www.cnblogs.com/sunsky303/p/11811097.html

      https://blog.51cto.com/u_15169172/2710119

    • 限制SYN并发数

     

    you are the best!
  • 相关阅读:
    Rabbit简单测试实例
    RabbitMQ-2 工作队列
    RabbitMQ-1 Helloword
    utmp
    导入wordpress数据库到mysql报错
    Tengine 反向代理状态检测
    阿里云服务器挖矿wipefs处理
    JbossMiner 挖矿蠕虫分析 (转载)
    centos6+nginx+php+mysql+memcached+wordpress
    php安装ZendGuardLoader扩展问题
  • 原文地址:https://www.cnblogs.com/linguoguo/p/15631417.html
Copyright © 2020-2023  润新知