Has anyone else seen this?
I am running a regex match against the word Fortinet, the OID response to .1.3.6.1.2.1.1.1.0 comes back with the Description entered, which is against most of the SNMP standards I have ever seen.
I am running 6.0.9 on the hardware in question.
Models tested:
500D, 2201E, 60F, 100F
Can anyone confirm this?
It would appear to be a bug?
Thanks for the assist
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Created on 01-10-2022 07:56 AM Edited on 01-10-2022 07:57 AM
Could be, and I am not excluding a bug, but
1. no RFC notes this data as mandatory (RFC 1156, RFC3416) RFC1213 notes: "It is mandatory that this only contain printable ASCII characters."
2. more data about device = more vulnerable towards attacks
These are the main reasons why I personally don't see this as a bug.
For the data you want to check via SNMP, you can use ".1.3.6.1.4.1.12356.101.4.1.1.0" - fgSysVersion - for software
".1.3.6.1.4.1.12356.100.1.1.1.0" - fnSysSerial for model from SN
Did you configure the system description?
By default is blank, so it makes sense to return null:
config system snmp sysinfo
set description ''
set contact-info ''
set location ''
end
https://oidref.com/1.3.6.1.2.1.1.1
"A textual description of the entity. This value should include..."
Can you reference the paragraph/page in RFC that claims the value "MUST" be something (specific)? Or how this breaks an existing RFC? In terms of security, may be better not to have so many details about the system, so that's probably why this is not a compulsory field
Testing on a device in my lab help show the consistency of other manufacturers:
.1.3.6.1.2.1.1.1.0
Cisco NX-OS(tm) n5000, Software (n5000-uk9), Version 7.3(1)N1(1), RELEASE SOFTWARE Copyright (c) 2002-2012 by Cisco Systems, Inc. Device Manager Version 6.0(2)N1(1),Compiled 10/5/2016 19:00:00
.1.3.6.1.2.1.1.1.0
Linux q-odbvm05-de 3.10.0-1160.45.1.el7.x86_64 #1 SMP Fri Sep 24 10:17:16 UTC 2021 x86_64
Fortigate Nada.....
I guess the expectation is that this OID is set by the Manufacturer, and is separate from the user-defined Description.
Created on 01-10-2022 07:56 AM Edited on 01-10-2022 07:57 AM
Could be, and I am not excluding a bug, but
1. no RFC notes this data as mandatory (RFC 1156, RFC3416) RFC1213 notes: "It is mandatory that this only contain printable ASCII characters."
2. more data about device = more vulnerable towards attacks
These are the main reasons why I personally don't see this as a bug.
For the data you want to check via SNMP, you can use ".1.3.6.1.4.1.12356.101.4.1.1.0" - fgSysVersion - for software
".1.3.6.1.4.1.12356.100.1.1.1.0" - fnSysSerial for model from SN
There is nothing in suggested Table that refer to it being a Fortigate, Fortiswitch, FortiAP, Fortisandbox, etc... which takes discovery tools off the table.
There is reference to the NPU's.....
So do we catalog this as a "feature" or "bug"?
Personal assessment whether is a bug or not:
- As long as it doesn't break RFCs, it is by design. To change it, a New Feature Request can be filed with your local Sales Engineer. There is no warranty that the NFR will be accepted or implemented
- If it was working before and stopped working, could be either a bug or design change (usually documented)
- If there is substantial impact in operation of the device, most likely a bug
This 'problem' you mention likely falls in the first category
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1547 | |
1030 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.