Forgive my ignorance if this is a trivial question. I am writing some code to support communication over SNMPv3; our application only supports SNMPv2c currently.
The response object when communicating using SNMPv3 is blank unless I match community strings. I was under the impression that community strings were an "SNMPv2/1 thing" and that "the new way" was to use a username/authentical protocol/privacy protocol.
Wikipedia states that:
Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, it looks much different due to new textual conventions, concepts, and terminology.[1]
This statement leads me to believe that I do, in fact, need to supply community strings, too.
I just wanted to confirm this because it is difficult for me to tell whether I am getting data back because I fulfilled the SNMPv2 requirement or because I successfully fulfilled all the SNMPv3 requirements.
I'm using Dart's SNMP library to communicate with the other device and I have specified that my request should user SNMP version three -- but perhaps it falls back to SNMPv2 behind-the-scenes when given valid SNMP communities?
No, you don't. The internal packet structure changes to a number of new concepts, like the above quote tries to indicate. The protocol side that the above is stating is the same has to do with PDU operations, etc. IE, technically there are 3 versions of SNMP:
version 1: community string based authentication with SMNPv1 PDUs
version 2c: community string based authentication with SNMPv2 PDUs
(the SNMPv2 PDUs add GETBULK, INFORM, and REPORT PDUs)
version 3: modular security with SNMPv2 PDUs
IE, version 3 didn't touch how the actual operations work (it's still using the PDU types from version 2), but merely adds other header-stuff around them (like better and more modular security; in fact we now have 3 different security types to pick from at this point: USM, SSH, and (D)TLS).
Related
What is the Major difference in SNMP over DTLS and SNMPv3 USM model, which one to prefer.
TLS and DTLS make use of the Transport Security Model (TSM) security model, defined in RFC5591 which was created as an alternative to the USM security model
The difference is what is the problem each of them wants to resolve.
SNMP v3 USM enhances the SNMP message format itself to add proper integrity check and encryption, so that it can be transferred on probably unsafe wires.
SNMP over DTLS uses another approach that it tries to build safe channels on unsafe wires, and allows the messages to be transferred safely.
You can prefer either of them to achieve significant security improvements over the original SNMP, but please analyze your scenarios carefully and put the following into consideration,
What are the devices in your whole solution?
Whether they support both models? Which one of them only supports one of the model?
Then you can make a decision on which model to choose. As far as I know SNMP v3 USM is more widely supported, but I might be wrong.
I've implemented an SNMP agent using SNMP4J. I've read in various places (including in SNMP4J javadoc) that there is support for a 'getSubtree' operation, but it always seems to be done from the client side, using getNext and/or getBulk. What I'm trying to do, though, is define a new PDU for 'getSubtree', and implement the server-side agent support for it.
Has anyone successfully (a) implemented a new PDU type (beyond the 7 standard ones) using SNMP4J, and/or (b) implemented 'getSubtree' support within an agent (I already know how to simulate it from a client.) Is either (a) or (b) even possible? Any pointers on how to do either would be GREATLY appreciated!
SNMP is not an extensible protocol that allows you to add new operations to it. So legally, you can't actually do that. The RFCs restrict the PDUs to the existing ones. GETBULK is the most efficient way to gather a bunch of information from an agent, even though it has its own issues with using it (data overrun for example).
I am working on a project about SNMP.
I know that between SNMPv1 and SNMPv2, SNMPv2 has GetBulk and Inform commands in addition. I would like to know that for the commands that are supported in the three versions like Get GetNext Set etc.., is there a difference in terms of compatibility or is there any difference that I should know?
SNMPv1 is missing GetBulk and the TRAP2 and INFORM commands (and REPORT, but you probably don't ever need to know that it exists). Other than that, SNMPv2c is a minor change to SNMPv1 that only adds these three commands. SNMPv3 uses the SNMPv2 PDU format so the command list is identical. SNMPv3 only wraps security and other processing around the SNMPv2 PDU set.
REPORT is almost v3 only.
GET BULK, TRAP v2 and INFORM are v2c/v3 only.
TRAP v1 is almost v1 only.
Other commands are available in all three versions.
Note that the message format is almost identical in v1 and v2c, while v3 uses a more complex format.
http://www.tcpipguide.com/free/t_SNMPVersion1SNMPv1MessageFormat-3.htm
http://www.tcpipguide.com/free/t_SNMPVersion2SNMPv2MessageFormats.htm
http://www.tcpipguide.com/free/t_SNMPVersion3SNMPv3MessageFormat.htm
The SNMP RFC documents listed in this Wikipedia page provide you more details on them,
http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol
There might be other issues during your exploration, and once you hit anything, you can post here again as a new question.
Where would I go to learn write code that had to be very, very secure and that DOES expose external services (running on a standard Windows or Linux OS). Knowing what services can and cannot be safely exposed would be part of the issue. Note that I am not looking for a favorite choice between Linux and Windows, as the choice is not likely to be mine to make in any given case. However the level of security needs to be military grade.
I almost feel embarressed giving this as a for instance, but how would I know whether or not I could use, say, WCF, in such a setting.
High security is a difficult concept as it generally involves way more than just the code you wrote.
Basically every layer of the OSI model has to be taken into consideration. Things like, preventing capture of the data stream (or it being rerouted) between the end points (quantum cryptography).
At the higher levels, you have things like various things like
Physical security of the devices (all endpoints if possible).
Hardening the OS (e.g: closing ports, turning off unused services, using kerberos, VPN tunnels, and leveraging white lists of machines allowed to connect, etc);
Encrypting the data at rest (file encryption), in transmission (SSL), and in memory (column/table encryption).
Ensuring and enforcing proper authentication and authorization at every level (in app, in sql, etc).
Log EVERYTHING. At a minimal it should answer "who/what/when/where/how"
Along with the logging, Actively Monitor it. aka: intrusion detection.
Then we can move on to other things like looking at other attack vectors like sql injection, xss, internal / disgruntled employees, etc.
And once you've done all of that be prepared when a hacker gets away with everything they want simply by social engineering.
In short, the best tact to take in order to secure any computer related application is to listen to the ethos of Fox Mulder, and Trust No One. Another favorite of mine that applies is: It's only paranoia if they aren't after you.
You could use formal methods to (sort-of) prove the critical parts of your software. A tool like Frama-C (free, LGPL license, targetting embedded systems) could be relevant (at least if your software is critical, embedded, written in C).
But military grade don't mean much. Your client will (and should) define exactly the standards to respect. For instance, critical [civilian] aircraft software needs to follow something like DO-178C (or its predecessor, DO-178B). Different industries have different standards similar to that. (both railways and medical industries have their own standards, which might be different in North America than in Europe).
If your system (& client) is less demanding (i.e. no billion dollars or hundreds lives threatened by bugs) you could consider customizing your compiler or using some other tool. For example, GCC is customizable thru plugins or thru MELT extensions.
Don't forget that software reliability has a big price (that means a big cost for you, hence for your client).
Well, the question of where can be answered simply. Not in school. I suggest to create a learning path for yourself. Pick a technology that you like and learn it inside out. A basic book to get you started should suffice, however the rest of the stuff you learn as you go, or via the documentation of that technology.
For instance - learning under .NET (Microsoft) involves a basic A-Press text-book (i suggest Pro C# and The .NET 4.0 Platform). Thereafter searching through the .NET Framework Reference on MSDN will give you the rest.
If you are looking for WCF reference, I suggest the (MCTS Exam 70-503, Microsoft .NET Framework 3.5 Windows Communication Foundation) and MSDN.
Just keep in mind that not a single technology will achieve what you are looking for. For example: WCF co-mingles with WF (Windows Workflow Foundation), as well as SQL Data Services and Entity Framework. Being exposed to multiple technologies will definitely broaden your vision.
===============================================================================
WCF is a beast in this regard. Here are the advantages over some other means of communication:
Messages (data) passed between end points can be secured via message-level security (encryption). The transport channel chosen can also be secured at protocol level via transport layer security (encryption).
End points themselves can authorize and impersonate clients (client level security). You can implement end-to-end service tracing, health monitoring & performance counters, message logging, as well as forward and backward compatibility with newer/older clients (via graceful degradation of the message format, provided in WCF). If you chose to do so, you can even implement routing as fail-safe for your communications channel. WCF also supports transactions (ACID), concurrency, as well as a per-instance throttling, giving you the most flexibility in writing secure/robust military grade code.
In retrospect the security and flexibility of WCF are astonishing. A similiar technology (if not the same) is the WS-Security spec. It is part of the WS-* specifications for web services and deals with Xml signature and Xml encryption to provide secure communications channel between two end points.
The disadvantages of WS-* however is that it is a one-way means of communication. WCF can facilitate 2 way communication. A client can send a request to a server, but also a server can send requests to the client. WS-* dictates that a client can only send and receive responses to the server, but not vice versa.
I am not a WCF developer so i thought the highlights might provoke you into doing your own research. "There are hundreds of ways to skin an animal, neither of them is wrong..."
Reading the FTP RFC (RFC959), I notice some modes that I've never seen used, and indeed don't seem to be implemented by popular FTP software (vsftpd for example). In particular, for the STRU command, only file mode "STRU F" is commonly used, and for the MODE command, only stream mode "MODE S" is commonly used.
So the question is, when following best practice for developing interoperable FTP client and server software:
Is it useful to support the other STRU options (record and page)? These seem like something very old fashioned.
Is it useful to support the other MODE options (block and compressed)? I can see the point in compressed, but I'm particularly wondering whether any clients/servers will expect block to be there.
Are there any surveys of which existing FTP implementations support which options?
(On the MODE one, I can see why compressed is useful, I'm more wondering about whether any clients/servers will expect block mode to be there).
I maintain a custom FTP server and regularly refer to http://cr.yp.to/ftp.html for these sort of questions. Specificly, I followed the suggestions for TYPE/MODE/STRU at http://cr.yp.to/ftp/type.html and so far have had no issues.
No client I've seen connect has sent an STRU request besides "STRU F". Similarly, I've only ever seen "MODE S".
I would suggest to search for open source FTP clients and servers (especially those still being actively updated) and look at how many of them implement these "obsolete" transfer modes.
I made once (about seven years ago) a FTP client and implemented just the most basic transfer modes (ASCII and binary, if I remember correctly). Never had a problem with any server when using it.
It sounds like you are mostly concerned with interoperability. The answer is a bit different between client and server.
For server, you want to implement the basic modes that clients use. For every client, you need to support a minimum of one configuration, so the number of combinations should be relatively low. Beyond the minimum, supporting active -and- passive mode would probably the major addition (the mozilla community has wanted passive support for a long time, and it is probably never going to happen).
If you are a client, providing good URL support and date/time handling is probably the biggest barrier.