SNMP Agent是什么？从配置到开发与安全加固全攻略

简介一套面向网络管理与系统集成人员的SNMP代理实现包侧重演示SNMP协议中的GET、SET与TRAP三类操作。实现基于C语言与MIB管理信息库覆盖对象查询、远程配置修改和异常主动上报场景适合需要理解SNMP协议栈、进行网络设备管理开发或实验调试的技术人员参考学习。包体信息压缩包约9.75MB共480个文件以124个h头文件、106个c源码和154个html帮助文档为主体附带编译生成的obj、exe、日志与工程配置等文件源码与构建产物并存便于对照阅读和运行验证。已有402人学习下载属于轻量实用的协议学习资料。通过完整工程目录与MIB、GET/SET处理、TRAP上报等模块划分读者可以从零搭建SNMP代理快速理解请求处理流程、OID寻址机制与主动上报逻辑同时多处示例代码清晰展示关键API调用方式为后续二次开发或网络管理平台集成提供直接参考。 今天被一个报错折腾了半天The agent execution provider did not respond in time。我下意识以为是网络设备上的SNMP Agent出了问题查来查去发现是某台数据库服务器的调度任务超时。虽然方向错了但这事提醒我一个关键点——很多人排查网络监控时根本分不清SNMP Agent和系统里的各种Agent代理。正好借这个机会把SNMP Agent这摊事从头到尾捋一遍。本文的核心是SNMP Agent也就是网络设备、服务器上那个负责被网管系统轮询和上报状态的小代理程序。我会把它是什么、怎么在CentOS 7.6上配好SNMP v3、弱口令怎么防、以及如何自己开发一个Agent一次性讲透。适合网络运维、监控平台开发、以及所有被监控折腾过的人。1. SNMP Agent到底是个啥角色先分清管理者与被管理者1.1 从一次误判说起先说那个报错。The agent execution provider did not respond in time是SQL Server Agent Job执行时后台执行宿主没在规定时间内响应——跟网络SNMP八竿子打不着。但我当时第一反应确实是某台交换机的agent挂了因为日常监控告警里SNMP Agent不响应是最常见的故障之一。这个误判本身说明一个事实SNMP Agent在网络运维里的存在感太强、太基础了基础到出了问题会下意识往它身上想。实际上SNMP Agent是网络管理架构里的被管理端角色它跑在路由器、交换机、服务器、打印机这些设备上通过UDP 161端口接收网管系统的查询请求再通过UDP 162端口主动上报告警Trap。你只有先把这个角色关系搞清楚后面配置、调优、开发才不会乱。1.2 Agent、NMS与MIB三者少一个都玩不转一套能用的SNMP监控体系至少有三个角色NMSNetwork Management Station网管系统想方设法去问设备的那个。SNMP Agent设备上的代理进程负责回答NMS的问。MIBManagement Information Base一个逻辑上的树状数据库NMS问什么、Agent答什么都由MIB定义。这里有个容易绕晕的点MIB不是Agent里存的一个个文件而是一套逻辑规则。Agent真正维护的是各种实时数据比如CPU占用、接口流量、设备温度。MIB定义了这些数据在OID树上的位置和类型。NMS拿到一串OID比如1.3.6.1.2.1.1.1.0Agent按这个OID去取对应数据返回。我习惯把Agent比作前台服务员MIB是菜单OID是菜品的编号。你报编号OID服务员Agent去后厨系统内核、硬件驱动取菜再按固定格式端上来。SNMPv1和v2c版本时菜单还分公开菜单和私有菜单公开菜单用public团体字串community string部分设备还能用private改配置——这就是后面要聊的弱口令问题的根源。1.3 常用OID速查表刚开始接触的人最头疼的是记OID。不要求全背但下面这几组必须眼熟因为配好Agent之后第一件事就是用它们验证OID名称说明1.3.6.1.2.1.1.1.0sysDescr设备型号、系统描述1.3.6.1.2.1.1.5.0sysName设备主机名1.3.6.1.2.1.1.3.0sysUpTime设备运行时长1.3.6.1.2.1.2.2.1.10ifInOctets接口入方向流量字节数1.3.6.1.2.1.2.2.1.16ifOutOctets接口出方向流量字节数1.3.6.1.4.1.2021.11.9.0memAvailRealnet-snmp扩展可用内存厂商私有MIB的OID通常在1.3.6.1.4.1下面根据不同企业编号区分。比如中某厂商的设备流量OID就可能在私有节点下面这时候你光用标准OID查不到得去厂商官网下MIB文件导入监控系统。后文排查部分我会再提。2. CentOS 7.6配置SNMP v3从安装到snmpwalk验证一条龙2.1 安装和初始配置CentOS 7.6上配置SNMP Agent用的基本是net-snmp套件。先装两个包yum install -y net-snmp net-snmp-utilsnet-snmp是Agent守护进程net-snmp-utils是客户端工具集里面的snmpwalk、snmpget、snmptrap都是后面验证要用的。装完先别急着启动我先改配置。初始配置文件在/etc/snmp/snmpd.conf你打开看一下会发现里面全是注释其实只要几行就能跑起来# 允许本机使用public只读访问 rocommunity public 127.0.0.1 # 允许监控网段使用monitor作为只读团体字串 rocommunity monitor 192.168.1.0/24 # 指定Agent监听地址和端口 agentaddress udp:161这里有个习惯问题。很多人图省事只写rocommunity public等于对所有来源IP开放了只读权限这是典型的安全隐患。我建议无论什么环境rocommunity后面一定跟一个网段或者IP限制。想改配置还不想开放写权限默认就不开写你只有显式配置rwcommunity才会有写权限尽量别配。2.2 创建SNMP v3用户v2c时代用团体字串当密码明文在网络里传输安全性很差。SNMP v3引入了用户、认证和加密能解决这个问题。创建v3用户net-snmp提供了现成脚本比手改配置省事得多systemctl stop snmpd net-snmp-create-v3-user -ro -a SHA -A AuthPass123 -x AES -X PrivPass123 snmpmon systemctl start snmpd简单解释下参数-ro是只读权限-a SHA表示认证协议用SHA-x AES表示加密协议用AES大写的-A和-X分别指定认证密码和加密密码。执行完脚本会把用户信息追加到/var/lib/net-snmp/snmpd.conf里所以要先停服务再创建否则可能被运行中的进程覆盖。密码别用我这里的示例至少要12位以上混合字符。为什么不推荐直接在/etc/snmp/snmpd.conf里写createUser因为那个文件权限通常不够严而且容易在重启时被系统重写。用官方脚本生成的用户信息单独存放出问题时排查也方便。2.3 验证是否跑通配置完一定要亲自验证别信看起来没问题。先确认服务状态和端口systemctl status snmpd netstat -tulnp | grep 161然后先用v2c验证基础通信snmpwalk -v2c -c monitor 127.0.0.1 1.3.6.1.2.1.1.1.0正常会返回类似SNMPv2-MIB::sysDescr.0 STRING: Linux centos76 3.10.0-957.el7.x86_64这样的信息。再验证v3snmpwalk -v3 -u snmpmon -l authPriv -a SHA -A AuthPass123 -x AES -X PrivPass123 127.0.0.1 1.3.6.1.2.1.1.5.0这里-l authPriv表示使用认证加加密模式这是v3最安全的组合。如果这条能返回sysName说明Agent配置成功。注意如果服务器开了防火墙记得放行UDP 161端口firewall-cmd --permanent --add-port161/udp firewall-cmd --reload3. 银河麒麟、Windows的SNMP配置差异与坑3.1 银河麒麟安装SNMP Agent这两年国产化环境越来越多银河麒麟系统上装SNMP Agent的需求也起来了。麒麟系统基于Linux内核整体思路和CentOS一致就是包管理有差异——银河麒麟V10的桌面版和服务器版有的用yum有的用apt。建议先执行cat /etc/os-release看清版本再动手。如果是yum系直接yum install -y net-snmp net-snmp-utils如果是apt系则是apt install -y snmpd snmp麒麟上配置文件的路径同样是/etc/snmp/snmpd.confv3用户创建方式也一致。我实际遇到过的一个坑是麒麟系统默认把snmpd服务做成了socket激活也就是说你不访问它它不一定常驻导致外部监控平台频繁超时。解决办法是禁用socket激活改成传统常驻服务systemctl stop snmpd.socket snmpd.service systemctl mask snmpd.socket systemctl enable --now snmpd.service3.2 Windows上启用或关闭SNMP服务Windows作为被监控端时SNMP的配置路径和Linux完全不同而且从Windows 10 1809开始微软把SNMP列为了弃用功能新系统里默认根本不装。如果想启用在设置-应用-可选功能-添加功能里找到简单网络管理协议(SNMP)安装后服务列表里会出现SIMPLE-TCP里的SNMP Service。右键服务属性可以配置团体名称和接受来自这些主机的SNMP数据包——这里只填监控服务器的IP别填任何格式的public。Windows的注册表里也能配置但说实话同一网段内用界面配置更快。至于Win10关闭SNMP这个需求本质上是卸载可选功能或停用SNMP服务。在服务管理器里把SNMP Service设为禁用通常就能挡住大部分轮询请求。如果还不放心就在Windows防火墙里禁止入站UDP 161端口再从公网角度检查确认端口不可达。关闭时要注意有些监控软件依赖SNMP做资产上报关了可能误报操作前先确认监控平台里没有绑它的终端。4. SNMP弱口令到底有多危险一次内部排查复盘4.1 public/private是怎么被盯上的热词里出现了SNMP弱口令连接这个词让我想起一次内部安全巡检。当时我们用扫描脚本扫了整个机房网段结果吓一跳——有十几台设备还开着SNMP v1community用的是出厂默认的public。原理其实很简单SNMPv1和v2c本身不支持加密也没有用户概念它靠一个明文传输的团体字串community string做身份识别。设备默认public为只读字串部分老设备甚至默认private可写。如果你的设备还保持着出厂默认那任何能到达这台设备UDP 161端口的人都能用snmpwalk把系统信息、接口流量、路由表、ARP表捞一遍等于把网络拓扑打印出来送人。更严重的是private可写。配合snmpget和snmpset攻击者可以改设备名、改接口描述、重启某些模块。虽然不能直接拿到设备shell但破坏性已经很可观。很多设备的SNMP服务还运行在管理VLAN里问题就出在管理VLAN被弱口令直接暴露了。4.2 加固手段对照表那次巡检之后我把加固动作沉淀成了一张清单每次新设备上线都过一遍隐患加固手段备注使用public/private默认串改为随机生成的强community串至少16位含大小写、数字、符号全局开放UDP 161限制管理网段源IP在设备ACL或防火墙层做允许写权限移除rwcommunity配置日常监控只给只读权限使用SNMPv1/v2c明文升级到SNMP v3 authPriv核心设备必须上v3开放了大量子节点使用view限制可见OID只暴露sysName、ifTable等必要节点暴露到公网在边界封锁UDP 161/162内网设备不应对公网可见有一次我甚至遇到某设备开启SNMP后管理员为了让监控方便把所有MIB节点都开放了结果连snmpCommunityTable都能远程读出来。所以光改community还不算完建议在配置里用view限定可见范围view systemonly included .1.3.6.1.2.1.1 view systemonly included .1.3.6.1.2.1.2这样Agent只对这两个子树下被请求的OID做响应其他一律返回noSuchObject数据暴露面就小多了。5. 自己开发一个SNMP Agent选型与最小实现思路5.1 为什么不要从零搓协议聊完配置再说说开发。不少人一听到Agent开发第一反应是拿起Python从零实现SNMP报文解析这就掉坑里了。SNMP消息基于ASN.1 BER编码虽然规范不算复杂但自己撸编解码光处理各种数据类型的TLV就能耗掉大量精力还容易出错。正确的做法是站在现有库的肩膀上。Linux服务端的开发框架推荐直接用net-snmp的pass_persist指令做脚本化扩展或者用pysnmp、agentx协议写子代理。如果你是给设备写嵌入式Agent那才需要考虑轻量级实现比如用lwip或一些c版本的小型SNMP栈。有一个判断标准我常用如果你需要监控的是Linux服务器上的自定义程序状态直接写pass_persist脚本最靠谱改起来快不重新编译如果你要把Agent嵌到自研硬件或路由器里那才值得引入完整的C语言SNMP框架。5.2 通过pass_persist挂到snmpd实现自定义OIDpass_persist是一种让外部程序接管某一段OID子树的机制。你把自己开发节点的命令写到snmpd.conf里然后snmpd收到针对这段OID的请求时会把请求转发给你的脚本处理。举个例子假设你的程序搞了一个自定义OID1.3.6.1.4.1.12345.1.0来表示队列长度你可以这样写pass_persist .1.3.6.1.4.1.12345 /opt/custom_agent/my_agent.py对应的Python脚本核心逻辑是#!/usr/bin/env python3 import sys BASE_OID 1.3.6.1.4.1.12345.1.0 def process_request(cmd, oid): if cmd PING: out [PONG] elif cmd in (GET, GETNEXT): # 这里实际应该根据真实队列长度取值 out [BASE_OID, integer, 42] elif cmd SET: out [not-writable] else: out [] print(\n.join(out)) sys.stdout.flush() for line in sys.stdin: parts line.strip().split() if not parts: continue process_request(parts[0], parts[1] if len(parts) 1 else )脚本交互的大致流程是snmpd启动后向脚本发PING脚本回PONG收到GET或GETNEXT请求时脚本按OID、类型、值三行格式返回。注意脚本必须在标准输出里显式刷新缓冲区否则snmpd等不到结果会超时。这个模式改起来方便多个自定义指标就往BASE_OID下面加子节点但要注意性能别在脚本里做重型计算或数据库查询snmpd轮询频率高时容易拖垮Agent。5.3 实际开发中的几个注意点开发SNMP Agent过程中我踩过的坑主要有三个。第一OID节点的返回类型必须和MIB定义严格一致。比如你MIB里定义的是Counter64返回Integer在部分NMS上会解析失败。最简单的方式是尽量用现有类型integer、string能覆盖大部分场景。第二一定要考虑并发和超时。snmpd默认超时时间很短脚本处理时间稍长上层轮询就会报Timeout。我可以把耗时操作异步化返回一个最近结果缓存值保证脚本响应在100ms以内。第三安全别忘。自定义Agent暴露在网络上至少要支持SNMP v3这样监控平台才能以认证用户连接你。不要为了调试方便在脚本里留下一个连v2c都能访问的口子。6. snmpwalk排查实录与常见报错对照6.1 排查思路最后分享一些实战排查经验。碰到监控平台无数据时我的排查路线基本固定第一步在NMS机器上直接snmpwalk目标设备排除监控平台自身问题。第二步查网络连通性telnet 主机 161连不上不代表UDP不通用nc -vnzu 主机 161配合Agent端tcpdump看有没有包到达。第三步确认Agent本身在跑systemctl status snmpd加netstat -tulnp | grep 161。第四步确认OID是否正确有些设备私有OID要加载MIB文件才能返回正确数据。有一个排查原则永远先确认Agent是好的再去怀疑监控平台或NMS配置。你在被监控设备上用snmpwalk都能拿到数据再回监控平台调模板、调OID思路就清晰多了。6.2 常见报错速查表现象可能原因处理方式Timeout: No Response from 主机Agent未启动、UDP端口被封、community错误检查snmpd状态、防火墙放行、核对community名称No Such Object available请求的OID在当前MIB子树下不存在确认设备是否支持该节点导入厂商MIB后重试Bad value for community团体字串错误检查snmpd.conf的rocommunity配置接口流量OID返回0接口索引ifIndex不匹配或设备型号私有规则先walkifDescr拿到接口索引再查对应流量OID端口占用无法启动snmpd161端口被其他程序占用netstat查占用进程或改用agentaddress指定其他端口Unknown user nameSNMP v3用户尚未创建或密码串错用net-snmp-create-v3-user重建用户核对认证加密参数那个开头提到的The agent execution provider did not respond in time如果你遇到时排查的是数据库定时任务先别怀疑网络设备。它是SQL Server Agent Job的执行宿主超时通常和SQL Agent服务异常、任务负载过大、WMI服务挂起有关。这类报错千万记得先看报错主体的完整信息别被agent两个字带偏。最后再分享一个我的个人习惯新装任何一台要接入监控的设备第一件事就是snmpwalk把整棵OID树拉一遍确认Agent本身是好的才去折腾监控平台那边的模板和MIB。这个先验证Agent再排查上层的顺序能省下大量无意义的排查时间。本文还有配套的精品资源点击获取