基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)

网络自适应与自发现的动机

  • 避免手动初始配置和更新网络设备发现
  • 网络基础设施数据填充数据组织过程资产
  • 通过定期数据更新保持最新状态
  • 保持对要支持的网络设备的精确描述
  • 高效的网络运营和规划
  • 资产库存管理(CMDB)
  • 准确清点所有硬件和软件资产组织
  • 网络管理系统的核心准确定位
  • 网络拓扑的自动生成和逻辑关系的清楚展现

输出的目标
安全风险与故障的及时有效的准确定位和排除
“要知道我们有什么,在哪里以及如何使用”

设备发现

  • 通过IP地址发现网络设备
  • 扫描IP地址范围(ping,snmp)
  • 发现网络设备,拓扑和IP地址空间
  • 从核心交换机开始,通过网络拓扑结构逐跳使用路由表中的下一跳
  • 扫描每个接口上的子网络并查找连接的设备
  • 使用CDP或LLDP
  • L3网络拓扑
  • 发现IP地址空间 - 每个接口上的子网
  • 通过MAC地址发现网络设备 - 每个LAN / VLAN
  • 检查每个设备接口上的ARP表
  • 配对IP和MAC地址
  • 在局域网上查找交换机
  • 查询交换机转发表
  • 了解网络中的DHCP池
  • L2网络拓扑( forwarding tables, ,STP)
    检测设备的类型
  • 路由器,交换机,UPS,主机(Linux,Windows ...)
  • 检测设备供应商
  • 检测设备型号
  • 检测设备资源(属性)
  • 系统名称,型号,序列号
  • 检测设备组件及其资源
  • 接口
  • 物理实体 - 模块,卡,CPU,内存...
  • 逻辑实体 - 存储分区,虚拟内存,路由表,连接用户,BGP对等体,QoS策略等。
  • 软件组件 - 已安装的软件,运行过程...
    ok,各位看官提纲已经列出来,大家继续往下走分享具体实现逻辑,不然肯定有大牛说都是大而虚,不切实际,那我们下面就将具体信息落实:

using SNMP - CLI
snmpwalk command
snmpwalk -v 2c -c 1qaz@WSX 100.100.32.10
基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)
Standard MIBs
System (.1.3.6.1.2.1.1)
Name, description, uptime

Response bindings:
1: sysObjectID.0 (object identifier) enterprises.9.1.516
2: sysUpTimeInstance (timeticks) 42 days 23h:23m:48s.31th (371302831)
3: sysContact.0 (octet string) (zero-length)
4: sysName.0 (octet string) WS-C3750v2-48TS [57.53.2D.43.33.37.35.30.76.32.2D.34.38.54.53 (hex)]
5: sysLocation.0 (octet string) (zero-length)
6: sysServices.0 (integer) 6
7: sysORLastChange.0 (timeticks) 0 days 00h:00m:00s.00th (0)
8: sysORID.1 (object identifier) enterprises.9.7.129
9: sysORID.2 (object identifier) enterprises.9.7.115
10: sysORID.3 (object identifier) enterprises.9.7.265
Interfaces (IF-MIB)
IfTable (.1.3.6.1.2.1.2.2), IfXTable (.1.3.6.1.2.1.31.1)
基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)
IP (IP-MIB)
ipAddrTable (.1.3.6.1.2.1.4.20) – used IP addresses
基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)
基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)

ipRouteTable (.1.3.6.1.2.1.4.21) – Routing table
基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)

部分带有路由功能的交换机会在(.1.3.6.1.2.1.4.24体现路由信息例如cisco 3750

基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)

ICMP (IP-MIB)
icmpStatsTable (.1.3.6.1.2.1.5.29) – statistics of ICMP packets

目前这部分被广泛应用在大数据分析、设备状态监测、甚至在APM也有所使用

UDP (UDP-MIB)
udpTable (.1.3.6.1.2.1.7.5)
TCP 1.3.6.1.2.1.6
基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)
基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)

基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)

如何识别设备类型?
发现测试 - 检索特定设备类型的唯一值
路由器
如何识别路由器?
路由表?主机也有一张路由表……
sysServices(.1.3.6.1.2.1.1.7)
返回值的位数确定设备所在的OSI/TCP的层数
例如:6(dec)= 0110(bin) - 第3层和第2层(L3交换机)
ipForwarding (.1.3.6.1.2.1.4.1) in IP-MIB
forwarding(1) – for routing capable devices
not-forwarding(2) – for all other devices
基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)基于snmp的网络自适应与自发现(建议开发运维自动化平台和基础架构支撑的朋友看)

上述我举例的方式已经很详细,就不一一给大家截图分析了,下面就直接给大家贴oid了:
BGP protocol (BPG4-MIB)
bgpPeerTable (.1.3.6.1.2.1.15.3)
OSPF protocol (OSPF-MIB)
ospfAreaTable (.1.3.6.1.2.1.14.2), ospfLsdbTabl (.1.3.6.1.2.1.14.4)
MPLS (MPLS-LSR-MIB, MPLS-VPN-MIB)
mplsInSegmentTable (.1.3.6.1.3.96.1.3)
mplsOutSegmentTable (.1.3.6.1.3.96.1.6)
BRIDGE-MIB
Discovery test
dot1dBaseBridgeAddress (.1.3.6.1.2.1.17.1.1)
dot1dBasePortTable (.1.3.6.1.2.1.17.1.4)
pairing switching ports with interfaces (ifTable)
HOST-RESOURCES-MIB
Discovery test
hrSystem (.1.3.6.1.2.1.25.1)
these (.1.3.6.1.2.1.25.1.1), hrSystemDate (.1.3.6.1.2.1.25.1.2)
hrStorageTable (.1.3.6.1.2.1.25.2.3)
hrDeviceTable (.1.3.6.1.2.1.25.3.2)
hrProcessorTable (.1.3.6.1.2.1.25.3.3)
private.enterprises (.1.3.6.1.4.1) subtree
cisco (.1.3.6.1.4.1.9)
apc (.1.3.6.1.4.1.318)
microsoft (.1.3.6.1.4.1.311)
juniperMIB (.1.3.6.1.4.1.2636)
vmware (.1.3.6.1.4.1.6876)
…………
详情见我之前分享的完整厂家分享,对与未知设备但凡支持SNMP需要在库中不断更新
OID sysObjectID (.1.3.6.1.2.1.1.2)
returns vendor specific OID which defines device model
Example:
sysObjectID = .1.3.6.1.4.1.9.1.283
CISCO-PRODUCTS-MIB (.1.3.6.1.4.1.9.1)
OID .1.3.6.1.4.1.9.1.283
Identifier
type: name: Cat6509
returns no date

上述是发现思科机框设备都会有不同的模块和板块

可以预期通过拓扑发现技术,可以不断识别网络地址空间,并不断探索网络的边界;可以持续地对终端设备进行普查,这种审查发生在网络核心,不需要安装终端;同时,能够不断积累设备元数据和行为数据。
这些能力能够发现未曾记录在档案的网络,发现网络中的无赖设备,甚至发现有威胁特征的设备,等等。而消除这些网络安全风险所付出的代价又较小,这也是我青睐于拓扑技术在网络安全中应用的重要原因

目前很多态势感知类设备甚至是soc都需要借助SNMP去获取一些设备状态信息、日志信息、包括进程,甚至是应用状态的监控,来掌握网络实时状态,随着SDN的发展,某些厂家通过网络虚拟化技术没通过opefew技术,对虚拟化网络设备及安全设备中的fewtable进行检测,传统的流量检测还是用了netfew技术,但是根据调研目前大部分虚拟化设备还是支持SNMP的,无论哪种技术,无非都是完成对企业内部资源的可视化:“拓扑可视化”“流量可视化”“设备配置信息可视化”“资产可视化等等。。。。”

具体还在不断的学习和实践中,还希望有这方面研究的朋友一起探讨。

猜你喜欢

转载自blog.51cto.com/13769225/2121928