Skip to main content
B1B3tt3r
B1B3tt3r
Explorer
January 7, 2022
Solved

BUG research: SNMP OID system.sysDescr .1.3.6.1.2.1.1.1.0 returning null?

  • January 7, 2022
  • 2 replies
  • 8669 views

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

Best answer by AlexC-FTNT

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

2 replies

AlexC-FTNT
Staff
AlexC-FTNT
Staff
January 10, 2022

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

 

AlexC-FTNT
Staff
AlexC-FTNT
Staff
January 10, 2022

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

B1B3tt3r
B1B3tt3rAuthor
Explorer
January 10, 2022

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.....

B1B3tt3r
B1B3tt3rAuthor
Explorer
January 10, 2022

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"?


AlexC-FTNT
Staff
AlexC-FTNT
Staff
January 10, 2022

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

Terms & ConditionsAccessibility statement