I'm new to SNMP. We have maybe 20000+ devices to listen SNMP traps. It is very hard to add to all trap receivers. Is there a way adding a trap receiver(destination) to a trap sender with SNMP-set request or something like that?
That would depend on your devices.
One of the drawbacks (and advantages) of SNMP is that as an equipment vendor, you are in charge of what your device allows users to do over SNMP.
Each of the devices implements an SNMP Agent, which publishes a MIB, whose contents vary between makes and models. If a vendor decides to include a variable in their MIB where a manager (that's you) can set the trap destination, this will be easy for you. As long as you have a current list of the addresses and community strings of all your devices, it's easy enough to loop through the list with a shell script and do snmpset.
If the MIB doesn't include a trap destination variable, you're going to have to find another way.
If your 20k devices are heterogenous (ie they implement different MIB sets), they you have fun times ahead, figuring out which ones can be managed entirely over SNMP and which will require other access to set the trap destination.
So, start by gathering the MIBs implemented by your devices, and by reading them (try a MIB browser) you should be able to answer the question yourself.
Related
Most of the examples provided for sending SNMP traps are simple ones like the one below.
snmptrap -v 1 -c public host TRAP-TEST-MIB::demotraps localhost 6 17 '' \
SNMPv2-MIB::sysLocation.0 s "Just here"
Take any MIB file, they contain many complex object groups, for example, systemGroup contains sysLocation, sysName, etc.
Could someone help in bringing out examples to show the way how to send snmp traps which includes such OBJECT-GROUPS. Adding one more question here, Does SNMPTRAPD support internationalization?
It is really bad practice to define the SNMP notification (trap or inform) the way that it contains the entire OBJECT GROUP or even worse the entire SNMP table. The reason is that you don't really need all these variables anyway. The other reason is that the packet/PDU is limited by MTU size. So it is possible that you'll not be able to send the data within single UDP packet due to its size.
The proper scenario would be to have few varbinds and you could also initiate some polling cycle to find out what happens if you need more details when you receive such trap.
SNMPTRAPD and NET-SNMP library in general do not support internationalization (UNICODE). The library is limited to ASCII charset only.
There are commercial products on the market including NetDecision TrapVision and some other that fully support UTF-8 internationalization.
As read on topic here How to find the unique serial number of a flash device? and especially here How to get manufacturer serial number of an USB flash drive? I know it is possible to get properties of hardware devices (particularly hard drives and usb drives...) using WMI Win32_PhysicalMedia and Win32_DiskDrive, which I'm getting done successfully.
However, I really want to know about the safety of these informations.
PhysicalMedia property SerialNumber returns the actual serial number of the main hard drive, while using other Win32_LogicalDisk and other calls we can map the drive letter of flash storage to actual Win32_DiskDrive device, and from there read properties like Name, Model, FirmwareRevision, SerialNumber, DeviceID, Manufacturer...
Now, DeviceID is generated by Windows / Pc itself, while SerialNumber should be the one that manufacturer added to the physical flash drive.
Manufacturer in most cases returns "Standard" something, Name is also of no use, while SerialNumber actually gets me a something that looks like unique ID, (I've read that in some cases this is not returned, so PNPDeviceID should be used instead? , Model gives the actual model of the flash drive, and FirmwareRevision just a number that could be used to add safety switch to the licensing, but is not vital.
However, the only one of these that seems / should be actually safe to use is SerialNumber, right?
So, the question here goes: Which level is Win32_DiskDrive actually reading this info from? Is it possible to fake that at all (Ok, letalone the actual lowlevel hacking stuff or driver injection etc...(??)), and if so, how hard it is?
If there's a known way / guide / example, I'd be also happy to read it. (not necessary info looking for here though.)
This is not for intention of bypassing some licensing. I'm making licensing for my SW, and am curious, whether it would be safe enough to use USB drive's SerialNumber property, and lock license against the presence of that USB flash, for which the license was bought for? Basically to use it as kind of a dongle, but not like the dongles actually work (using communication with the actual hardware inside the dongle...)
I know it may not seem as a safe solution, as flash drives dies quite often these days, or get lost etc, but this is just to add an option to my licensing from "Per PC" to "Portable - per USB device".
Thanks for any info!!!
EDIT:
I am completely aware that bypassing these kind of safety switches is very possible. Of course, even Windows itself is not licensed in a way that couldn't be hacked, nor Adobe, ProTools etc, (software that is widely used and costs a lot!).
But that wasn't a real question, and also, that's not the case for me -> the software will not be that expensive and not used by that much people, that I'd be afraid to drag interest in someone who will do extensive programming to make a patch/crack for it. Regular debugger use and workaround is pretty unlikely to be used by regular client who would need the software, ( and also, since it is something to be used in business environment, where stability is vital, I doubt they will really play around that...).
Main point here:
It is possible for sure, but: HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
Main question of the post: Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app? If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
WMI just returns what the hardware tells it. It's as unique as the hardware. Which ultimately depends on the vendor.
But...
If someone has an administrator account to the computer†, then there are very few things that can be done to keep them from just hooking up the kernel debugger to your program and overriding your checks, or recording the raw USB communication session and replaying it on an unauthorized system. The real dongles do some to mitigate this, by having the hardware generate a response to a particular challenge. The challenge/response changes for each request, so it's not as susceptible to replay attacks, but the debugger tricks still work.
This is the real problem with the serial number approach. Uniqueness is not the primary concern for dongled software. The primary concern is unpredictability.
An illustrative example-
Let's say that I'm a bouncer at an exclusive night club. We're so exclusive that you have to answer a question to get in. You really want to get in, but no one will tell you the answer to the question. One night, you hatch a plan. You hang out in the alley and listen to the conversations that I'm having with the patrons trying to enter the club. It doesn't take you long to realize that I'm asking everyone the exact same question, and you're in. (This is the serial number approach)
After a while, I notice that there are a lot of people coming into the club that I've never seen before, and begin to suspect something. The people we really want to allow in are all given a card with a formula‡ on it. Whenever they come to the door of the club, I give them a number and they apply their formula and tell me the result. Since I also know the formula, I can tell if they are really allowed in. Now, even if you hear the entire challenge and response, without the formula, you aren't getting in. (This is one common approach taken by dongles.)
But what about the debugger? The debugger just made herself the club's owner, fired me, and can come and go as she pleases.
†Or has physical access to the machine and a password reset disk.
‡Stop laughing, this could totally happen. :)
Photo credit: Guillaume Paumier, CC-BY. Found on the Wikimedia Commons 7-Oct-15
Edit to address the question edit:
HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
The question is how skilled is the 'regular person'? If you're talking about software/electrical engineers, then this is a trivial task. If you're talking about sales/marketing then it's a challenging task.
Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app?
It depends and Yes. Changing the ID on the device itself is possible with some devices, and impossible with others. Software to spoof/man-in-the-middle the USB communication, or to create a virtual USB device is possible.
If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
As I led with above, WMI reads from the hardware. This can be intercepted or bypassed.
Some ways to bypass the check:
Make a virtual USB device
Modify the USB MSD device driver to report the same serial number for all devices.
Build hardware using commercially available cheap host controllers that identifies with the same information as the authorized device. ($10 worth of raw components and a little bit of time.)
Redirect the system calls to/from USB to a compromised library.
Note also that:
Some places have restrictions on USB storage devices, ranging from discouraging their use, to outright bans. This would prevent your software from being used in sensitive computing environments processing private data, like credit cards, PII, trade secrets, classified information, etc. (In the US many governmental agencies have outright bans on USB storage devices, and block the install of any MSD.)
The Mass Storage specification doesn't require serial numbers. They are usually there, but they don't have to be, and many low-cost vendors
A USB PKI token costs a little bit more, but would probably do what you want. Here's an example from Safenet (Disclaimer: I am in no way affiliated with Safenet Inc, and you should evaluate all the possible options from all vendors. I suggested this because it was the first thing that came up through CDW, and the price was ~$30)
Can anyone tell me why NMS implementations parse and save MIB items in a database?
I know one of the reasons is when they receive a trap and want to analyze it, then they use the parsed MIB. What else they do with parsed MIB?
For example, when the NMS sends a SNMP GET request to an agent, the programmer must specify which OIDs are being requested?
Does the the parsed MIB have a another purpose or do we parse MIBs only for analyzing SNMP traps?
You are on the right track - you parse the MIB at all in order to make it human-readable. That is for both traps (informs) and polled values. But if you parse it out to a text file, that's a huge amount of data to read/grep through to find out the description, message, possible values, related OIDs, etc.
Added to this is that there isn't just one MIB. There are dozens or hundreds that an NMS may be interested in. Since, on a host, you only add the MIBs that you want that host to respond to, the NMS has to have a copy of every MIB that ever device it is monitoring may have on IT so that it can understand the response the host returns.
So you parse each MIB and store it in a db to make it faster to search and to have everything all in one place. That could be so that you can find the messages associated with varbinds, or what all the possible enumerations are, etc.
Just to be clear, parsing the MIB isn't the same as doing an SNMPWalk on a host. SNMPWalk just gives you the current response to each OID in sequence.
I need to get a list of interfaces on my local machine, along with their IP addresses, MACs and a set of QoS measurements ( Delay, Jitter, Error rate, Loss Rate, Bandwidth)...
I'm writing a kernel module to read these information from local network devices,So far I've extracted every thing mentioned above except for both Jitter and Bandwidth...
I'm using linux kernel 2.6.35
It depends what you mean by bandwidth. In most cases you only get from the PHY something that is better called bitrate. I guess you rather need some kind of information on the available bandwidth at a higher layer, which you can't get without active or passive measurements done, e.g. sending ICMP echo-like probe packets, and investigating replies. You should also make clear what the two points in the network are (both the actual endpoints and the communication layer) between which you would like to measure available bandwidth.
As for jitter you also need to do some kind of measurements, basically the same way as above.
I know this is an old post, but you could accomplish at least getting jitter by inspecting the RTCP packets if they're available. They come in on the +1 of the RTP port and come along with any RTP stream as far as I've seen. A lot of information can be gotten from RTCP, but for your purposes just the basic source description would do it:
EDIT: (didn't look at the preview)
Just check out this link for the details of the protocol, but you can get the jitter pretty easily from an RTCP packet.
Depending on what you're using the RTP stream for too there are a lot of other resources, like the VoIP Metrics Report Block in the Extended Report (https://www.rfc-editor.org/rfc/rfc3611#page-25).
EDIT:
As per Artem's request here is a basic flow of how you might do it:
An RTP stream is started on say port 16400 (the needed drivers/mechanism for this to happen are most likely already in place).
Tell the kernel to start listening on port 16401 (1 above your RTP stream's port) as well; this is where the RTCP pkts will start coming in.
As the RTCP pkts come in send them wherever you want to handle them (ie, if you're wanting to parse it in userspace or something).
Parse the pkts for the desired data. I'm not aware of a particular lib to do this, but it's pretty easy to just point some struct at it (in C) and dereference, watching out for Endianess.
I'm querying a bunch of information from cisco switches using SNMP. For instance, I'm pulling information on neighbors detected using CDP by doing an snmpwalk on .1.3.6.1.4.1.9.9.23
Can I use this OID across different cisco models? What pitfalls should I be aware of? To me, I'm a little uneasy about using numeric OIDs - it seems like I should be using a MIB database or something and using the named OIDs, in order to gain cross-device compatibility, but perhaps I'm just imagining the need for that.
Once a MIB has been published it won't move to a new OID. Doing so would break network management tools and cause support calls, which nobody wants. To continue your example, the CDP MIB has been published at Cisco's SNMP Object Navigator.
For general code cleanliness it would be good to define the OIDs in a central place, especially since you don't want to duplicate the full OID for every single table you need to access.
The place you need to be most careful is a unique MIB in a product which Cisco recently acquired. The OID will change, if nothing else to move it into their own Enterprise OID space, but the MIB may also change to conform to Cisco's SNMP practices.
It is very consistent.
Monitoring tools depend on the consistency and the MIBs produced by Cicso rarely change old values and usually only implement new ones.
Check out the Cisco OID look up tool.
Notice how it doesn't ask you what product the look up is for.
-mw
The OIDs can vary with hardware but also with firmware version for the same hardware as, over time, the architecture of the management functions can change and require new MIBs. It is worth checking whether any of the OIDs you intend to use are in deprecated MIBs, or become so in the life of the application, as this indicates not only that the MIB could one day be unsupported but also that there is likely to be improved, richer data or access to data. It is also good practice to test management apps against a sample upgraded device as part of the routine testing of firmware updates before widespread deployment.
An example of a change of OID due to a MIB being deprecated is at
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a0080094aa6.shtml
"This document shows how to copy a
configuration file to and from a Cisco
device with the CISCO-CONFIG-COPY-MIB.
If you start from Cisco IOS® software
release 12.0, or on some devices as
early as release 11.2P, Cisco has
implemented a new means of Simple
Network Management Protocol (SNMP)
configuration management with the new
CISCO-CONFIG-COPY-MIB. This MIB
replaces the deprecated configuration
section of the OLD-CISCO-SYSTEM-MIB. "
I would avoid putting in numeric OIDs and instead use 'OID names' and leave that hard work (of translating) to whatever SNMP API you are using.
If that is not possible, then it is okay to use OIDs as they should not change per the SNMP MIB guidelines. Unless the device itself changes but that requires a new MIB anyway which can't reuse old OIDs.
This is obvious, but be sure to look at the attributes of the SNMP MIB variable. Be sure not to query variables that have a status of 'obsolete'.
Jay..
In some cases, using the names instead of the numerical representations can be a serious performance hit due to the need to read and parse the MIB files to get the numerical representations of the OIDs that the lower level libraries need.
For instance, say your using a program to collect something every minute, then loading the MIBs over and over is very inefficient.
As stated by others, once published, the name to numerical mapping will never change, so the fact that you're hard-coding stuff into your programs is not really a problem.
If you have access to command line SNMP tools, check out 'snmptranslate' for a nice tool to get back and forth from text to numerical OIDs.
I think that is a common misconception (about MIB reload each time you resolve a name).
Most of the SNMP APIs (such as AdventNet, CMU) load the MIBS at startup and after that there is no 'overhead' of loading MIBs everytime you ask for a 'translation' from name to oid and vice versa. What's more, some of them cache the results and at that point, there is no difference between name lookups and directly coding the OID.
This is a bit similar to specifying an "IP Address" versus a 'hostname'.