1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
# $OpenBSD: README,v 1.5 2008/01/09 12:16:58 reyk Exp $
SNMP daemon
-----------
(Scary Network Management Protocol Daemon)
This is the very experimental implementation of a simple SNMP daemon.
Even if SNMP is not our favorite protocol, it is a very important
key requirement in many corporate networks; sync to reality. And
we don't want to rely on horrid SNMP implementations in this case.
DESIGN
The main amazingly new thing is that this daemon will use the imsg
privsep approach using several different processes ("engines") to
separate privileges when handling the requests.
It uses a new ASN.1/BER implementation to parse and create the SNMP
messages. It is a simple implementation which does what we need.
I may change the layout to look a bit more like RFC 2271. But
the proposed design in RFC 2271 is a bad joke; it uses too many
subsystems with the requirement to communicate with ASN.1/BER
messages.
The following picture is based on section 3.1 of RFC 2271 describing
the proposed design of SNMPv3 entities and the current mapping in
snmpd:
+-------------------------------------------------------------------+
| SNMP entity (snmpd(8)) |
| snmpd(8) |
| +-------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | snmpe.c | |
| | +------------+ +------------+ +-----------+-+-----------+ | |
| | | | | | | |\ | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | IMSG, | | Subsystem | | | | Subsystem | | |
| | | event(3) | | mps.c | | TODO \| | | |
| | +------------+ +------------+ +-----------+-+-----------+ | |
| | || || | | |
| +--------||-----------||---|----------------------------------+ |
| || || | |
| || || | --> application |
| || || | (unpriv, functions calls) |
| || || | |
| || || ------> application |
| || || | (priv, IMSGs to snmpd.c) |
| || || | |
. ||--------------------> external application .
. || || | (IMSGs via /var/run/snmpd.sock) .
. || || | .
. +--------||-----------||---|----------------------------------+ .
| | Application(s) | |
| | snmpd.c, snmpctl(8), possible: ospfd, bgpd, relayd, ... | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
FUZZ
There is at least one SNMP fuzzer. Of course, it will not crash snmpd.
http://www.hackingciscoexposed.com/tools/snmp-fuzzer-0.1.1.tar.gz
TODO
snmpd:
- Implement the advanced SNMPv2 features like INFORM
- Implement USM (User-based Security Model)
- Implement some MIBs (SNMPv2/3 standard MIBs)
- MIB-2 (mostly done)
- IF-MIB (mostly done)
- IP-MIB (mostly done, at least the old version)
- TCP-MIB
- UDP-MIB
- BRIDGE-MIB
- OPENBSD-MIB (sensors done, etc.)
- ...
- Review review review
- More tests on other platforms like sparc64, hppa, etc.
- Add trap receiver/logger
- Add an interface to send traps via imsg from snmpctl and daemons
- There is a SNMP over SSH draft, interesting reading:
http://tools.ietf.org/html/draft-ietf-isms-secshell-09
http://tools.ietf.org/wg/isms/
snmpctl:
- Add commands to query the SNMP mibtree via imsg
- Add commands to query/set remote SNMP daemons (instead snmpwalk etc.)
- Internal status, lalala, ...
ber:
- Should we replace all the long longs with u_int64_t and so on?
NOT TO DO
- Do not implement all the zillions of MIBs from ucdavis/net-snmp
- Do not provide a complex API for plugins, modules, and pimp-my-SNMP
- ...
THANKS
To .vantronix for supporting this work - it is time to get a
nice(r) SNMP implementation for OpenBSD.
Thanks to claudio@ and mbalmer@ for starting the implementation
of ASN.1/BER encoding.
reyk
|
