Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
B1B3tt3r
New Contributor II

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

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

1 Solution
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


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -

View solution in original post

7 REPLIES 7
AlexC-FTNT
Staff
Staff

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

 


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
AlexC-FTNT

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


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
B1B3tt3r
New Contributor II

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
New Contributor II

I guess the expectation is that this OID is set by the Manufacturer, and is separate from the user-defined Description.

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


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
B1B3tt3r
New Contributor II

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

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


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
Labels
Top Kudoed Authors