I'll await further responses, but some things inline.
On Tue, 2021-06-15 at 17:39 +0100, Stuart Henderson wrote:
> > > > - if the concern is amplification attacks then setting the minlevel to
> > > > authpriv is too high, since you'll silently break logins for users
> > > > that miss the enckey parameter.
> > > > I changed this to always default to seclevel auth.
> > >
> > > I do still think enc is the safer default (i.e. "the user has to do
> > > something to weaken things") though I don't strongly object to auth
> > > instead of enc.
> >
> > I agree that it's safer, but do we want to break the config of more
> > people than needed for the goal of preventing simple amplification
> > attacks?
>
> Can we take a straw poll of readers of this email who are using SNMPv3
> (if any ;-) -- are you using auth+enc, just auth, or no authentication?
> I'm thinking that somebody who went to the trouble of using v3
> probably uses auth+enc though I could be wrong..
>
> > Then again, I don't get the feeling many people use snmpd at this time
> > and maybe it's a good moment to bite the bullet and go for safest
> > defaults possible at this time. But if that's the case I would like to
> > follow up with a diff to changes the default auth to hmac-sha512,
> > because snmp drops trailing bytes of the result and enc to aes instead
> > of des.
>
> This is the change that feels most likely to affect existing SNMPv3 users.
> Support in management software beyond aes/sha1 is a bit lacking and prone
> to incompatibility (I had issues with net-snmp and snmpd using hmac-sha256
> though it seems it will work with hmac-sha512..)
I tried to make sure they're compatible and hmac-sha2 suites are properly
defined in RFC 7860:
martijn$ doas grep -v -e '^#' -e '^$' /etc/snmpd.conf
listen_addr="localhost"
listen on $listen_addr
listen on tcp $listen_addr
listen on 127.0.0.1 notify
listen on tcp 127.0.0.1 notify
trap handle 1.3 "/etc/snmpd_traphandler.sh"
system contact "Martijn van Duren"
user test authkey test1234 auth hmac-sha256 enckey test1234
user test2 authkey test1234 auth hmac-sha256 enckey test1234 enc aes
martijn$ doas snmpd -dvv
startup
snmpe: listening on udp 127.0.0.1:161
snmpe: listening on udp ::1:161
snmpe: listening on tcp 127.0.0.1:161
snmpe: listening on tcp ::1:161
snmpe: listening on udp 127.0.0.1:162
snmpe: listening on tcp 127.0.0.1:162
ktable_new: new ktable for rtableid 0
USM: engineid '', engine boots 0, engine time 0, user ''
snmpe_parse: 127.0.0.1:161: unknown engine id
USM: engineid '800075cb804ce9c2c760c8eed4', engine boots 0, engine time
1623781167, user 'test'
snmpe_parse: 127.0.0.1:161: SNMPv3 pdutype GetRequest, flags 0x7, secmodel 3,
user 'test', ctx-engine f09bf133c40500000000000000, ctx-name '', request
874884768
snmpe_parsevarbinds: 127.0.0.1:161: oid
iso.org.dod.internet.mgmt.mib_2.system.sysContact.0
USM: engineid '', engine boots 0, engine time 0, user ''
snmpe_parse: 127.0.0.1:161: unknown engine id
USM: engineid '800075cb804ce9c2c760c8eed4', engine boots 0, engine time
1623781169, user 'test2'
snmpe_parse: 127.0.0.1:161: SNMPv3 pdutype GetRequest, flags 0x7, secmodel 3,
user 'test2', ctx-engine 40eff233c40500000000000000, ctx-name '', request
1903188166
snmpe_parsevarbinds: 127.0.0.1:161: oid
iso.org.dod.internet.mgmt.mib_2.system.sysContact.0
martijn$ snmpget -v3 -lauthpriv -u test -a SHA-256 -A test1234 -x des -X
test1234 127.0.0.1 sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: Martijn van Duren
martijn$ snmpget -v3 -lauthpriv -u test2 -a SHA-256 -A test1234 -x aes -X
test1234 127.0.0.1 sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: Martijn van Duren
Do you still have the PoC of the issue you faced?
And if other software doesn't support it... it's been 5 years, it's
about time they implement it. And until then: It's only a default,
people can set all the insecure features they want.
> > > and i'll try to have another read through and actually test it
> > > in the morning :)
> > >
> > Hopefully you haven't spend too much on a second read.
>
> didn't get there yet, i have spent the best part of 8 hours on 2 emails
> so far today ;)
>
> > | READWRITE DISABLED {
> > - conf->sc_readonly = 1;
> > + /* XXX Remove after 7.0 */
> > + conf->sc_rwcommunity[0] = '\0';
> > + log_warnx("'read-write disabled' is deprecated");
>
> if it's going, might as well just disable it? almost nobody will react
> to that warning unless it refuses to start, it's not like this will
> lock someone out of their machine if it doesn't run.
I'm fine with that as well... I'll remove it in the next iteration if we
know which direction we want to take this.
>
> > +.It Ic write
> > +Specifies if the listen address accepts set requests.
> > +.It Ic notify
> > +Specifies if the listen address accepts trapv1 and trapv2 requests.
> > +.It Ic snmpv1
> > +Enables SNMPv1 subsystem on the listen address.
> > +.It Ic snmpv2c
> > +Enables SNMPv2c subsystem on the listen address.
> > +.It Ic snmpv3
> > +Enables SNMPv3 subsystem on the listen address.
>
> I like this! I guess we could also do
>
> listen on 127.0.0.1 snmpv2c read
This should probably read:
listen on 127.0.0.1 snmpv2c snmpv3 read
No need to disable snmpv3, just because it's localhost :-)
> listen on 0.0.0.0 read
> listen on :: read
> read-only community public
>
> to allow localhost requests with v2c for quick lookups and require
> something better on the network.
>
> I'll do some testing and get back to you.
>
