On Sat, 2021-08-07 at 22:47 +0100, Stuart Henderson wrote:
> On 2021/08/07 15:17, Martijn van Duren wrote:
> > Let me give one final pushback, if this doesn't convince you then feel
> > free to commit sthen's diff without my OK, but make sure it stays in
> > sync with snmp(1).
>
> I was convinced enough to try it, hence okaying your previous diff, but
> practical experience after updating some production machines got me to
> reconsider. What happened in my case: updated machine running snmpd,
> stopped getting monitoring in one place, reconfigured that to use sha256
> (which either involves click-click-click in a web interface or poking
> a database table), noticed some other stats weren't working too, spent
> quarter of an hour figuring out how to tell the collector to use sha256,
> eventually working out that it's not possible, revert the snmpd config,
> revert clicky click, ended up with the same algorithms as before but
> wasted time. Then I updated another one enough later that I'd forgotten
> about the first until partway through the cycle again...
>
> > First let me sum up what defaults have changed since 6.9:
> > - community authentication disabled (snmpv1/snmpv2c)
> > - no default community name set set
>
> So this one breaks old SNMPv2 configs unless config is changed.
> Between the widely abused and scanned-for UDP amplification vector on
> "public", the hidden default "private" RW community that I bet many
> people have enabled even if they changed public, and old snmpd still
> accepting v2 sessions when v3 was configured (as I discovered thanks
> to shadowserver after I reconfigured it to use v3 "to improve
> security"), I think that was absolutely the right thing to do.
>
> > - seclevel moved from none to enc
>
> I will honestly be very surprised if this affects anyone, you have to
> set the username/keys to configure SNMPv3 at all so you're highly likely
> to configure them into the management station too. Possibly fixes an
> amplification vector if you have a poorly chosen username but not all
> that likely.
>
> > - enc moved from des to aes
>
> Might affect some users but I find it hard to believe it will be many.
> Which OpenBSD sysadmin going to the trouble of configure SNMPv3 is going
> to voluntarily pick des when aes is on offer, shown in the example config
> file, and widely supported?
That's the problem with defaults for these non-negotiated parameters.
If someone went with the defaults was it a voluntary pick or "I have
no idea what I'm doing, but it works, or maybe even an "I had no idea
that option was there"?
>
> > - auth moved from hmac-sha1 to hmac-sha256
>
> ...whereas there are good reasons why someone would use hmac-sha1 rather
> than hmac-sha256, and auth is the only part of the usm settings not
> shown in examples/snmpd.conf,
>
> # Enable SNMPv3 USM with authentication, encryption and two defined users
> #seclevel enc
> #user "user1" authkey "password123" enc aes enckey "321drowssap"
> #user "user2" authkey "password456" enckey "654drowssap"
>
> (The thing I'm most concerned about with snmpd-provided SNMP service is
> easily guessed defaults, especially with regard to the UDP amp vector.
> It would be better to keep SNMP-provided stats more private, but that's
> further down the list, and totally off the list for anyone currently
> running with v2c and "public").
VACM is somewhere (way) down on my roadmap.
>
> ............
>
> Updated diff below. I've rearranged examples/snmpd.conf some more,
> explictly listed auth/enc algs for all usm examples
I agree
> , got rid of the oid
> settings that are specialist enough that someone wanting them can read
> the manual, and shown setting the v2c community if needed. (I pondered
> getting rid of "trap receiver" as well as it doesn't do a lot in snmpd
> yet, only coldStart, but it has potential so I showed some options
> instead).
I have a diff floating around on tech@ adding snmpv3 support to it[0],
which would require an additional user specified for v3. So that
example should probably be changed (didn't notice it, because I usually
test the example as is. I agree that it's not really useful as is, but
I'm hopefully going to focus on a new "application" layer (what snmpd(8)
currently calls mps) during k2k21, which should be fully async, which
would allow us to reintroduce agentx support and thus get more use out
of it. I also have a diff with OK floating around on tech@ for adding
notification support to libagentx, but I haven't committed it yet
because of lack of agentx support in snmpd(8) and got some second
thoughts about the API.
>
>
> (And now that I realise "the complicated services alg" is actually
> "bitwise OR of 2^(OSI layer number) for all supported layers" I am now
> going to step away from the computer and try to forget it ;)
And now you got me to remember it... :(
>
> Index: etc/examples/snmpd.conf
> ===================================================================
> RCS file: /cvs/src/etc/examples/snmpd.conf,v
> retrieving revision 1.1
> diff -u -p -r1.1 snmpd.conf
> --- etc/examples/snmpd.conf 11 Jul 2014 21:20:10 -0000 1.1
> +++ etc/examples/snmpd.conf 7 Aug 2021 21:45:44 -0000
> @@ -1,24 +1,26 @@
> # $OpenBSD: snmpd.conf,v 1.1 2014/07/11 21:20:10 deraadt Exp $
>
> -listen_addr="127.0.0.1"
> +# Default is to listen to all addresses for SNMPv3 only; "listen on"
> +# can be used multiple times. See snmpd.conf(5) for more options.
> +#listen on 0.0.0.0 snmpv2c # All IPv4 addresses with SNMPv2c
> +#listen on :: snmpv2c snmpv3 # All IPv6 addresses, both v2c + v3
> +#listen on 127.0.0.1 # IPv4 localhost only, v3
This is probably is a bad example.
Reading it like this: you're correct that we listen on all interfaces
by default, but that's not listed in snmpd.conf(5). So that should
probably be fixed (including mentioning that setting one "listen on"
disables the all interfaces default).
Second, your examples enable snmpv2c on all interfaces, while you
enable an implicit snmpv3 on 127.0.0.1. This should probably be the
other way around, or replace 127.0.0.1 with something like
"listen on 192.168.0.2 snmpv2c" to map with source-address by trap
receiver. And an additional
"listen on 0.0.0.0
listen on ::"
to make it clear that snmpv2c should only be enabled on internal
networks, but snmpv3 is less of a problem.
>
> -# Restrict daemon to listen on localhost only
> -listen on $listen_addr
> +# Define a RO community if you use SNMPv2c (there is no default)
> +#read-only community MWgp3MWbD2khaYnwy2B
>
> -# Specify a number of trap receivers
> -#trap receiver nms.localdomain.local
> +# Enable SNMPv3 USM with authentication, encryption and two defined users
This sentence feels wrong, it is enabled by default.
Also, since we only enable SNMPv3 by default, maybe also make it
clear that at least one user should be created? Something like:
# SNMPv3 USM users. At least one user should be created to use SNMPv3.
> +#seclevel enc
This is the default and if we would ever change this default back (I
can't imagine we ever will, but who knows) it still wouldn't break.
So maybe just leave seclevel out of the example, or show how to use
it for e.g. authNoPriv.
> +#user "user1" auth hmac-sha1 authkey "password123" enc aes enckey
> "321drowssap"
> +#user "user2" auth hmac-sha256 authkey "password456" enc aes enckey
> "654drowssap"
> +
> +# Specify one or more trap receivers with optional parameters
> +#trap receiver nms.localdomain.local community PAV9kpE02gDPvAi
> source-address 192.0.2.1
At this time (with future additions in mind) I think that oid would be
more useful than source-address.
One example I can think of that could be possible if I manage to get
agentx back up and running and we add agentx support to vmd (I have a
working PoC). Mischa could send traps to individual users for
OpenBSD.amsterdam. Just a random example that's top of my mind, not
claiming any realism.
>
> # Adjust the local system information
> #system contact "Charlie Root (r...@myhost.example.com)"
> #system description "Powered by OpenBSD"
> #system location "Rack A1-24, Room 13"
> -system services 74
>
> -# Provide static user-defined SNMP OIDs
> -oid 1.3.6.1.4.1.30155.42.3.1 name testStringValue read-only string "Test"
> -oid 1.3.6.1.4.1.30155.42.3.4 name testIntValue read-write integer 1
I fully agree that these should go. This whole oid keyword is just
clutch (limited data types, assuming an oid should be turned into a
scalar by appending a zero)
> -
> -# Enable SNMPv3 USM with authentication, encryption and two defined users
> -#seclevel enc
> -#user "user1" authkey "password123" enc aes enckey "321drowssap"
> -#user "user2" authkey "password456" enckey "654drowssap"
> +# Required by some management software
> +#system services 74
Maybe you can explain how admins can change the value to something
correct for their environment? :-)
Or maybe we should add something like
system services physical|datalink|internet|endtoend|applications
to parse.y and let snmpd(8) create the correct integer.
In general I do like the cleanup of this file. Thanks.
> Index: usr.sbin/snmpd/snmpd.conf.5
> ===================================================================
> RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
> retrieving revision 1.50
> diff -u -p -r1.50 snmpd.conf.5
> --- usr.sbin/snmpd/snmpd.conf.5 20 Jun 2021 19:59:42 -0000 1.50
> +++ usr.sbin/snmpd/snmpd.conf.5 7 Aug 2021 21:45:44 -0000
> @@ -207,6 +207,7 @@ system may provide.
> Refer to the
> .Ar sysServices
> description in the SNMP MIB for details.
> +The value is given in decimal.
This should be a separate commit. OK for this one.
Or, if you feel like I should implement my suggestion above let me know
and I can cook something up.
> .\"XXX describe the complicated services alg here
> .It Ic trap community Ar string
> Specify the name of the trap community.
> @@ -279,7 +280,7 @@ must be either
> or
> .Ic hmac-sha512 .
> If omitted the default is
> -.Ic hmac-sha256 .
> +.Ic hmac-sha1 .
On Sat, 2021-08-07 at 07:40 -0600, Theo de Raadt wrote:
> Yes, probably hmac-md5
> .Pp
> With
> .Ic enckey
> @@ -345,17 +346,14 @@ oid 1.3.6.1.4.1.30155.42.2 name myStatus
> .Pp
> The next example will enforce SNMPv3 with authenticated and encrypted
> communication and the user-based security model.
> -The configuration defines two users,
> -the first one is using the
> -.Ic aes
> -encryption algorithm and the second one the default
> -.Ic des
> -algorithm.
> +The configuration defines several users using varying encryption and
> +authentication algorithms.
> .Bd -literal -offset indent
> seclevel enc
>
> -user "hans" authkey "password123" enc aes enckey "321drowssap"
> -user "sophie" authkey "password456" enc des enckey "654drowssap"
> +user "mgmt" auth hmac-sha256 authkey "password123" enc aes enckey
> "321drowssap"
> +user "hans" auth hmac-sha authkey "password456" enc aes enckey "654drowssap"
hmac-sha1
> +user "sophie" auth hmac-md5 authkey "password789" enc des enckey
> "987drowssap"
> .Ed
> .Sh SEE ALSO
> .Xr snmp 1 ,
> Index: usr.sbin/snmpd/snmpd.h
> ===================================================================
> RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
> retrieving revision 1.97
> diff -u -p -r1.97 snmpd.h
> --- usr.sbin/snmpd/snmpd.h 20 Jun 2021 19:59:42 -0000 1.97
> +++ usr.sbin/snmpd/snmpd.h 7 Aug 2021 21:45:44 -0000
> @@ -529,7 +529,7 @@ enum usmauth {
> AUTH_SHA512 /* usmHMAC384SHA512AuthProtocol. RFC7860 */
> };
>
> -#define AUTH_DEFAULT AUTH_SHA256 /* Default digest */
> +#define AUTH_DEFAULT AUTH_SHA1 /* Default digest */
>
> enum usmpriv {
> PRIV_NONE = 0,
> Index: usr.bin/snmp/snmp.1
> ===================================================================
> RCS file: /cvs/src/usr.bin/snmp/snmp.1,v
> retrieving revision 1.18
> diff -u -p -r1.18 snmp.1
> --- usr.bin/snmp/snmp.1 20 Jun 2021 20:02:14 -0000 1.18
> +++ usr.bin/snmp/snmp.1 7 Aug 2021 21:45:44 -0000
> @@ -197,7 +197,7 @@ Options are
> or
> .Cm SHA-512 .
> This option defaults to
> -.Cm SHA-256 .
> +.Cm SHA .
> This option is only used by
> .Fl v Cm 3 .
> .It Fl C Ar appopt
> Index: usr.bin/snmp/snmpc.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 snmpc.c
> --- usr.bin/snmp/snmpc.c 20 Jun 2021 20:02:14 -0000 1.34
> +++ usr.bin/snmp/snmpc.c 7 Aug 2021 21:45:44 -0000
> @@ -476,7 +476,7 @@ main(int argc, char *argv[])
> err(1, "usm_init");
> if (seclevel & SNMP_MSGFLAG_AUTH) {
> if (md == NULL)
> - md = EVP_sha256();
> + md = EVP_sha1();
> if (authkey == NULL)
> errx(1, "No authKey or authPassword
> specified");
> if (usm_setauth(sec, md, authkey, authkeylen,
>
[0] https://marc.info/?l=openbsd-tech&m=162741422419165&w=2
