网络安全项目实战（四）--报文检测

8. TCP/UDP 段

• 目标
  • 了解 TCP 段头的组织结构
  • 了解 UDP 段头的组织结构
  • 掌握 TCP/UDP 段的解析方式

8.1. UDP 段格式

下图是UDP的段格式（该图出自[TCPIP]）。

8.2. UDP头部

 //UDP头部，总长度8字节
 // /usr/include/linux/udp.h
struct udphdr {
    __be16    source;     //源端口号
    __be16    dest;       //目的端口号
    __be16    len;        udp数据长度
    __sum16    check;     // //16位udp检验和
};

8.3. TCP段格式

TCP的段格式如下图所示（该图出自[TCPIP]）

 

• 和UDP协议一样也有源端口号和目的端口号，通讯的双方由IP地址和端口号标识。
• 32位序号、
• 32位确认序号、
• 4位首部长度和IP协议头类似，表示TCP协议头的长度，以4字节为单位，因此TCP协议头最长可以是4x15=60字节，如果没有选项字段，TCP协议头最短20字节。
• 保留 6位， 新的版本下保留4位， 增加两位标志，介绍从略
• URG、ACK、PSH、RST、SYN、FIN是六个控制位，
• 16位窗口大小
• 16位检验和将TCP协议头和数据都计算在内。
• 紧急指针和各种选项的解释从略。

 

8.4. TCP头部

  //TCP头部，总长度20字节
  // /usr/inlcude/linux/tcp.h

struct tcphdr {
        __be16  source;         //源端口号
        __be16  dest;           //目的端口号
        __be32  seq;            //序列号
        __be32  ack_seq;        //确认号
#if defined(__LITTLE_ENDIAN_BITFIELD)
        __u16   res1:4,
                doff:4,
                fin:1,
                syn:1,
                rst:1,
                psh:1,
                ack:1,
                urg:1,
                ece:1,
                cwr:1;
#elif defined(__BIG_ENDIAN_BITFIELD)
        __u16   doff:4,     //tcp头部长度
                res1:4,     // 保留 4位
                cwr:1,
                ece:1,
                urg:1,
                ack:1,
                psh:1,
                rst:1,
                syn:1,
                fin:1;
#else
#error  "Adjust your <asm/byteorder.h> defines"
#endif  
        __be16  window;     //16位窗口大小
        __sum16 check;      //16位TCP检验和
        __be16  urg_ptr;    //16为紧急指针
};

9. SSH协议解析

• 目标
  • 了解ssh协议
  • 了解ssh协议探测方法（简洁）

9.1. ssh协议

全称为Secure Shell，即很安全的shell，主要目的是用来取代传统的telnet和r系列命令（rlogin，rsh，rexec等）远程登录和远程执行命令的工具，实现远程登录和远程执行命令加密，防止由于网络监听而出现的密码泄露，从而对系统构成威胁。（telnet协议采用明文传送密码，数据传送过程中也不加密）

　　ssh协议目前有ssh1 和ssh2，其实现在我们主要使用的也是openssh。ssh不仅在登录过程中对密码进行加密传送，而且在登录后执行的命令的数据也进行加密，这样即使别人在网络上监听并截获了你的数据包，他也看不到其中的内容。

在网络安全防护中， “信息系统具备防窃听”， 这条要求的本质就是要用密文传输的ssh替代明文传输的telnet....

9.2. ssh完整流程实例分析

通过ssh远程控制的一个完整个过程来讲，ssh的过程可分为以下3部分：

• 版本协商

• 算法协商与密钥交换

这其中第二部分是ssh最为核心的过程，该过程决定了以后通信所要使用的密钥，下面按顺序对每个部分对比着数据包进行详细的讲解并给出实现的过程。

9.2.1. 版本协商

在建立连接后，客户端与服务器分别向对方发送自己ssh的版本信息（这里的数据格式不同于其他包，只有一行版本号），以\r\n结束。版本的格式如下：

                     SSH-ssh协议版本-详细版本\r\n 

 

在图中， 橙色部分，为tcp建立链接的三次握手

9.2.2. 算法协商与密钥交换

先看图

 

算法协商：第158，Key Exchange init开始，分别为双发向对法发送的自己在不同密码需求上支持的算法。

• 加密通信（可能含有2、3部分）

9.2.3. 加密通信

上图， 从 Client: Encrypted packet 开始， 开始进行加密的通信

9.3. 拓展内容

9.3.1. 关于ssh相关的几个概念

在介绍ssh协议之前，有几个涉及到的基本概念首先需要介绍，它们对于理解ssh协议本身有非常重要和关键的作用。

加密

加密的意思是将一段数据经过处理之后，输出为一段外人无法或者很难破译的数据，除了指定的人可以解密之外。 一般来说，加密的输入还会有一个key，这个key作为加密的参数， 而在解密的时候也会用一个相关联(有可能是相同)的key作为输入。

简单的说： 密文 = 明文 + key

对称加密

所谓的对称加密，是说加密方和解密方用的都是同一个key，这个key对于加密方和解密方来说是保密的，第三方是不能知道的。在第三方不知道私钥的情况下，是很难将加密的数据解密的。一般来说是加密方先产生私钥，然后通过一个安全的途径来告知解密方这个key。

非对称加密

非对称加密，是说解密的一方首先生成一对密钥，一个私钥一个公钥，私钥不会泄漏出去，而公钥则是可以任意的对外发布的。用公钥进行加密的数据，只能用私钥才能解密。加密方首先从解密方获取公钥，然后利用这个公钥进行加密，把数据发送给解密方。解密方利用私钥进行解密。如果解密的数据在传输的过程中被第三方截获，也不用担心，因为第三方没有私钥，没有办法进行解密。

非对称加密的问题还包括获取了公钥之后，加密方如何保证公钥来自于确定的一方，而不是某个冒充的机器。假设公钥不是来自我们信任的机器，那么就算我们用非对称加密也没有用，因为加密之后的数据是发送给了冒充的机器，该机器就可以利用它产生的私钥进行解密了。所以非对称加密里面比较重要的一步是身份认证。

需要说明一下，一般的对称加密都会比非对称加密快，所以大数据量的加密一般都会使用对称加密，而非对称加密会作为身份验证和交换对称加密秘钥的一个手段。

数据一致性/完整性

数据一致性说得是如何保证一段数据在传输的过程中没有遗漏、破坏或者修改过。一般来说，目前流行的做法是对数据进行hash，得到的hash值和数据一起传输，然后在收到数据的时候也对数据进行hash，将得到的hash值和传输过来的hash值进行比对，如果是不一样的，说明数据已经被修改过；如果是一样的，则说明极有可能是完整的。

目前流行的hash算法有MD5和SHA-1算法。

9.3.2. 参考

• RFC4251