1 实验概括
-
实验目的:
学习捕获SNMP报文,通过报文分析理解SNMP协议的工作过程。 -
实验内容:
1) 使用snmputilg发送SNMP数据包; 使用wireshark抓包;使用netstat –an查看代理站TCP/UDP连接表;
2) 自行挑选MIB-2功能组中IP、ICMP、TCP、UDP等的管理对象(要有列对象),综合前面一点,抓包分析SNMP的工作过程;
3) 查找标量对象标识符.1.3.6.1.2.1.11.13是什么对象,其实例标识符是什么?若连续多次GET这个实例标识符,得到的值有什么变化?请抓包分析其PDU格式。请截图说明。
2 实验内容
2.1
使用snmputilg发送SNMP数据包; 使用wireshark抓包;使用netstat –an查看代理站TCP/UDP连接表,分析并验证SNMP协议的工作过程(在2.2进行分析验证,这里不再赘述);
- 使用snmputilg发送SNMP数据包;
- 使用wireshark抓包;
- 使用netstat –an查看代理站TCP/UDP连接表
最主要是以下图这一条条目
UDP 0.0.0.0:161
表示本地终端实时监视所有接口的UDP 161进程,也就是SNMP进程
;*:*
表示允许所有的进程(IP+端口)都可以对该进程进行访问操作,如果禁用SNMP服务,则本地就不会存在该条目,则snmp无法正常工作;
至于是否被接受访问,就需要看是否有访问权限了;
2.2
自行挑选MIB-2功能组中IP、ICMP、TCP、UDP等的管理对象(要有列对象),抓包分析其SNMP协议工作过程。
注:我们选择抓取管理对象UDP的信息来进行SNMP协议的报文分析(使用的抓包软件是MIB BROSWER)
- 首先,我们使用get-Request方法获取udpInDatagrams的信息,会出现如下的报文
- 先打开 get-request报文,开始请求报文分析
UDP Dst Port 161
从传输层可以看出SNMP协议是基于UDP的协议且SNMP的端口号是161,使用UDP而不使用TCP的主要原因有以下两点:1、SNMP协议多是在内网部署,而内网的环境相对可控(可靠性较高),所以不需要使用TCP来保证可靠性;2、SNMP协议本身就很占用CPU资源,特别对于SNMP管理站来说,大量的发送和接收SNMP报文不是一件轻松的事,如果还需要维持TCP连接,那更是雪上加霜,所以选择无连接的UDP协议作为底层协议;Version
SNMP的协议主要有三种版本,v1、v2、v3,v2是对v1的优化版本,新增了一些请求的方法,比如后面要讲的getBulkRequest,v3较v2的而言新增了加密的功能,加强了协议整体的安全性;双方版本不支持则无法进行SNMP的正常工作;community
用于身份认证,管理站和代理的community不一致,则无法进行后续的snmp操作get-request(0)
常用的snmp请求类报文有以下几种:
GetRequest-PDU
:值为0
,用于请求代理站对应OID的值;
GetNextRequest-PDU
:值为1
,用广度搜索的方法获取当前OID对应的子层的首个OID的值,如果没有子层则获取下一个同层的OID对应的值;
SetRequest-PDU
:值为2
,用于设置代理上对应OID的值。
GetBulkRequest-PDU
:值为5
(这是SNMPv2新增的报文类型,不存在于SNMPv1中),用广度搜索的方法获取当前OID对应的下层所有的OID对应的值;
Trap-PDU
:值为6
,用于请求获取代理上的日志信息;
InformRequest-PDU
:值为7
(SNMPv2c引入的报文类型),作用同Trap-PDU,只是需要代理回复一个Ack报文保证可靠性。request-id
每次管理站产生一个request类的报文,就会生产一个新的request-id,response-id值和其一致,用于确定response的对象是哪一个request;1.3.6.1.2.1.7:value(null)
是一种K/V值,OID表示Key,OID的值是Value,注意并不是请求的就是这个OID对应的值,这得取决于请求报文的类型,如果是getRequest那么就是请求对应OID的值;如果是其他的,如getNextRequest,则是在此OID的基础上获取其子层的第一个OID的值,在这里就是1.6.1.2.1.7.1.0,我们在回复报文中标注的OID也可以验证;
- 再打开get-response报文,进行回复报文分析
get-response(2)
表示回复报文的类型值为2;1.3.6.1.2.1.7.1.0:66536
表示回复的是这个OID对应的值;
- SNMP的工作过程
综上所述,SNMP协议的工作过程可以概括为,管理站发送请求类报文给代理,代理根据其中内容回复对应的信息给管理站,这需要代理开启了SNMP协议(也就是系统要监听161号UDP端口),且代理允许接收;来自对应IP的管理站的SNMP协议报文,在此基础上代理和管理站的SNMP版本号要匹配,且community两端要一致;当然,以上前提是代理和管理站的网络本身就是通畅的;
2.3
查找标量对象标识符.1.3.6.1.2.1.11.13是什么对象,其实例标识符是什么?若连续多次GET这个实例标识符,得到的值有什么变化?请抓包分析其PDU格式。请截图说明。
注——对象和实例的区别
一个对象可以有多个实例,比如对象端口号,其实例就是每个端口的端口编号,有几个端口就有几个实例,具体表示方法就是在对象的后面再加上表示事例的后缀;
1.3.6.1.2.1.11.13
的对象是snmpIntotalReqVar
,用于统计代理接收到的请求类SNMP报文的数目,其实例符号为1.3.6.1.2.1.11.13.0
;- 若连续多次GET这个实例标识符,得到的值会逐一递增
- 抓包分析
- 经过连续三次对于response的抓包,可以发现Value值递增,OID就是1.3.6.1.2.1.11.13.0,表示代理的该接口接收snmp请求类包的数量,由于向代理发送请求才能获取该值,所以每发一次请求报文,我们获取到的值就加一;其他的报文分析上面有讲,就不再赘述了;
3 实验小结
在本次的实验中,我通过对于报文的解析,初步了解了SNMP协议的工作流程,而且也明白了对象和实例的区别,受益匪浅;