[c-nsp] Blocking SNMPv3 engine-id discovery [was: Re: How to disable ILMI/SNMP CSCvs33325]

Simon Leinen via cisco-nsp <[email protected]> Wed, 21 Sep 2022 12:51:22 +0200
Newsgroups	gmane.network.nsp.cisco
Message-ID	<[email protected]>
Gert Doering writes:
> On Wed, Sep 21, 2022 at 08:14:30AM +0300, Hank Nussbacher wrote:
>> Indeed the SNMP leaks appear to be exactly CSCtw74132 which we did
>> not know about nor did Cisco TAC :-(

> The more I dive into this, the more I want to return to my bed and
> pull the blanket over my head...

> So, the Cisco bug ID claims "this has been fixed in some versions",
> but none of those are "ASR920 IOS trains" (except 03.9(00)E, which is
> sort of weird).

> The bug also claims "CVE ID CVE-2012-5719 has been assigned", but
> MITRE says "** RESERVED ** This candidate has been reserved by an
> organization or individual that will use it when announcing a new
> security problem", so it got never published...

> That said, I then went to test our Junipers and Aristas, and they all
> do the same silly shit - no SNMPv3 configured, strict ACLs for all
> configured SNMP communities, and *still* SNMP engine discovery works
> from arbitrary sources out there.  On the switches it's not that
> annoying (management interface is in a well-isolated network segment)
> but on the routers, customer-facing IPs are reachable "from the
> world".

> Sounds like a nice reflection attack in the coming...

I wonder what is a reasonable way to address this.  Personally I'm not
too worried about this risk (our routers even respond indiscriminately
to ICMP Echo Request!), but obviously some are.  So it's probably
reasonable for Cisco to disable the SNMPv3 engine-id discovery mechanism
when no USM users are configured.  On the other hand, I would like to be
able to use SNMPv3, and configure users, without having to worry about
the exposure of the engine-id discovery mechanism.

One way to address this would be to extend the SNMP application (agent)
-level protections from the community-based model to SNMPv3/USM, and in
particular engine-ID discovery.  For the community-based "security"
model used in SNMPv1 and SNMPv2(c), we have:

  snmp-server community <community-name> (RO|RW) <acl>

IOS(-XE) and IOS-XR have similar mechanisms for USM users:

  snmp-server user <user-name> <group-name> (v1|v2|v3) access (ipv6)? <acl>

and

  snmp-server user <user-name> <group-name> (v1|v2|v3) (IPv4|IPv6)? <acl>

respectively.  One could argue that there should also be something like

  snmp-server discovery engine-id restrict (IPv4|IPv6)? <acl>

But this doesn't seem to exist(?).

Personally, I'd prefer if this could be handled by generic control-plane
protection mechanisms; maybe that can even be done today?

I.e. in your CoPP policy, couldn't you just drop (rate-limit to zero)
all packets to UDP port 161 (SNMP) that don't come from trusted sources?

That would solve all the perceived problems (e.g. your routers showing
up in Shodan) and provide even better protection for your control plane,
because the packets won't even reach the SNMP agent logic...

If CoPP allowed you to block SNMP like this, then I'd think it is not
super urgent to also address this on SNMP level.  But I'm starting to
have doubts that CoPP is practical for doing this.  It would require
users to be able to specify specific ACLs to define/refine CoPP
"classes".  Is that possible at all?
-- 
Simon.

_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
signature.asc (application/pgp-signature, 905 B)