Uninett / nav

Network Administration Visualized
GNU General Public License v3.0
178 stars 37 forks source link

Implement SNMPv3 support #1177

Open jmbredal opened 7 years ago

jmbredal commented 7 years ago

The underlying NET-SNMP backend supports SNMPv3. Implement support for this in NAV.

An attempt to break down this feature into multiple parts (which individually might need to be broken down, as well)

jmbredal commented 7 years ago

(by bzed) Is anybody working on this? If not I'll see if I can implement it.

jmbredal commented 7 years ago

(by mbrekkevold) Hi Bernd, not currently, no, but I'm delighted to hear someone is interested in working on it :)

We are planning to look at NETCONF support in 2015, which will also necessitate some of the same changes to NAV's data model for storing management credentials.

I'm not sure where or if we have documented our ideas for this, but we are thinking along the lines of a separate "management credentials" table or store, where named sets of unique credentials are stored. Each IP Device/Netbox would then have a relation to this table, so that adding a Netbox in SeedDB entails selecting a pre-stored set of credentials from a dropdown list.

We'll gladly answer any questions you might have (and I would recommend the nav-dev mailing list, or our #nav IRC channel on freenode).

jmbredal commented 7 years ago

(by bzed) Unfortunately I did not yet find the time to look into snmp v3 and I doubt I will find the time soonish. Is the some plan when v3 will arive?

jmbredal commented 7 years ago

(by mbrekkevold)

Unfortunately I did not yet find the time to look into snmp v3 and I doubt I will find the time soonish. Is the some plan when v3 will arive?

I'd forgotten all about this since I last heard from you.

We've already begun implementation of a "management credentials" store, and the University of Linköping seems to be willing to pay us to fix SNMPv3 support, so we may actually get there in 2016.

b2cc commented 6 years ago

@jmbredal @lunkwill42 : any news on SNMPv3 support? We would really appreciate if this could be implemented as some of our devices are exposed to the internet and we want to avoid sending plaintext credentials over unsecured lines. thanks for providing such awesome product!

lunkwill42 commented 6 years ago

Hi, @b2cc . SNMPv3 has been on the backburner for a while now, because we want to prioritize NETCONF et.al. But, any initial support for NETCONF will be mainly for configuration purposes (such as PortAdmin) - though it will also require the same initial changes as for SNMPv3 support: A different way of storing management credentials for devices.

We will, however, not be able to complete any kind of support for NETCONF until we have relicensed NAV to either GPLv3 or Apache 2.0, which is a big upcoming task for us (since there are multiple copyright holders).

You're now subscribed to this issue, so we'll keep you posted.

b2cc commented 6 years ago

@lunkwill42 : ok I understand, thanks for the heads up!

trantor commented 2 years ago

Hello @lunkwill42 Any news on this? I still do not see SNMP v3 in the Management Profile section...

lunkwill42 commented 2 years ago

Hello @lunkwill42 Any news on this? I still do not see SNMP v3 in the Management Profile section...

Indeed. No news, unfortunately. This is still not a priority for our customers, so it's still on the backburner. I've also never heard back from @pstolpe whether the University of Linköping is interested in pursuing this...

So as it stands: We have management profiles now, but no SNMP v3 support. A new profile type for SNMP v3 would be relatively easy to create. Then, the work would remain to update the two adapter modules (synchronous and asynchronous) NAV uses to adapt to NET-SNMP to be able to initialize SNMP v3 sessions using the config from such a profile.

oddkl commented 2 years ago

If it helps, we're a customer, and we want this feature! So upvoted!

thomases commented 1 year ago

We're also a customer, and would very much like to see this implemented. Upvoted!

pstolpe commented 1 year ago

We still would like to see ANMP v3 implemented fully at Linköping University, but we have not currently got any budget to fund this. What is most interesting for us is SNMP v3 contexts to get arp etc from within VRF's in our vendor Alcatel Lucent Enterprise OmniSwitch platform. We have other platforms right now i.e. Fortinet that has a problematic SNMP implementation so part from this I'd like to see an API where we could feed ARP/ IPv6-neighbor data etc from other sources home-brew or other solutions to NAV. But that's another feature request.

raskallen commented 1 year ago

We are also a customer (although posting from my private git accout) and would like, or actually need, snmpv3 support. This is what stops us from using NAV. So hereby upvote from us. :)

lunkwill42 commented 1 year ago

If you're a customer with Sikt, it helps to identify which institution you represent :)

SNMPv3 has previously been discussed, but not upvoted, by the NAV reference committee (UiO, UiA, NTNU, UiT and HiVolda). I'll make sure to add this issue to the agenda of our next scheduled meeting.

eriksornes commented 10 months ago

Hi, we would also like snmpv3 implemented. We have som remote equipment we would very much like to access more secure with snmpv3, if its possible. Also I think we are customers of Sikt of some sort.

xloto commented 10 months ago

Recomendation from an alert message on justiscert.no (The Norwegian justice sector's ICT security and response environment) today:

"Turn off all insecure/deprecated features (eg TLS v1.0 and v1.1, SMBv1, NTLMv1, FTP, Telnet, SNMP v1 and v2, POP, IMAP, NetBIOS, LLMNR, HTTP)"

Link to alert (in norwegian): https://justiscert.no/[justiscert-varsel]-[074-2023]-[tlpclear]-microsoft-adobe-og-sap-sarbarheter-for-oktober-2023

lunkwill42 commented 9 months ago

Good news for everyone following this issue: Our team has now been told this is our highest priority for the upcoming sprint, as we have signed a deal to deliver network management services to a customer that has an absolute requirement for SNMPv3.

pstolpe commented 9 months ago

Great news indeed.

Hope you will implement multiple snmpv3 context names per device to poll vrf data from the vendors that uses that.

/P

Den mån 30 okt. 2023 09:52Morten Brekkevold @.***> skrev:

Good news for everyone following this issue: Our team has now been told this is our highest priority for the upcoming sprint, as we have signed a deal to deliver network management services to a customer that has an absolute requirement for SNMPv3.

— Reply to this email directly, view it on GitHub https://github.com/Uninett/nav/issues/1177#issuecomment-1784740331, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIGIETQUHVNNE7G7LBR3CC3YB5TD3AVCNFSM4C4WTWMKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGQ3TIMBTGMYQ . You are receiving this because you were mentioned.Message ID: @.***>