Saturday, September 22, 2007

My little Bag of Tricks: 'scli' -- SNMP Queries made very easy (Commandline Utility)

Some common daily problems you as an IT guy or gal are facing regularly....

  • You are tasked to install a Linux driver for the brandnew Infotec printer your boss bought without consulting with you. Now you do not know, and he couldn't tell you: was the darn thing shipped with a PostScript module installed? Or does it understand PCL only?
  • You are wondering, what the LCD display on the printer down the hall currently indicates, but you're too busy to get up and walk down?
  • You are bothered by a user who phones "My big HP jammed; though I removed the paper, this red light keeps blinking all the time!"?

Use scli.

scli is the command to invoke the "SNMP Command Line Interface". A little known console utility, it is of great use to me on many occasions.

Executive summary:

scli connects to any SNMP-enabled network node and lets you interactively "browse" through the values stored in the device's SNMP database ("MIB", Management Information Base). My own personal usage is mainly for network printers (yeah, that's why I picked these examples), but scli can work with many more device types: bridges, routers, gateways, switches, computers and more. And it also has a scriptable, non-interactive mode...

Target users:

  • users who want to learn what kind of (possibly sensitive) info the devices owned by them do reveal to their network neighbourhood
  • users who are wielding a kind of "remote helpdesk" function (in their job, for their friends, or within their own family)
  • users who are just curious about SNMP functions, and want to learn about that resource and about the network nodes in their proximity
  • users who are somewhat familiar with "snmpwalk", but not familiar enough to run it without consulting the manpage every time again)

Links:

Glorious details for the more curious readers:

scli does not only give you a more user friendly way than snmpwalk to run SNMP queries. It also formats the results it returns in a more user friendly way. You can run scli interactively. This gives you its own shell+prompt to run different commands. Or you can invoke it in a way that just executes one command, displays the result and returns to your standard shell (this mode is also good for scripting SNMP-related tasks you want to achieve in your network).

By default, scli returns plain ASCII text messages. You can also tell it to return XML-formatted messages by using the "–xml" parameter. XML may be very useful if you want the return to be processed by software, instead of being read by a human. Or if you want to pick it up and display the result in a fully-fledged GUI.... (you are a software developer who can do that, right? Actually, this may be a good exercise to get up to speed with Qt4 programming :-)     .)

Assuming the network node you are interested in poking at has the IP address 192.168.23.45. Start the tool by typing

  scli 192.168.23.45

SNMP-enabled devices by default use "public" as their "community name". So if scli does not see a community name on the commandline, it tries to silently use "public".

You wonder what that "community name" thingie means? It is a very weak way of authorization; in essence, a password common to all users, but with no separate user names. SNMP in version 1 will not even encrypt the community name on the wire! Yes, that's very bad security for most devices, but that's how the real life SNMP world around us currently is. (SNMP v2 and v4 are better, but not yet as common in devices used out there, though adoption is slowly gaining traction...).

If you have a node that is a bit less open, and you happen to know the used "community name", use it as an additional argument:

  scli 10.162.11.8 "community-name"

If it succeeds connecting, scli will present you its prompt:

  scli > 

(if you run scli verison 0.2.12)

  (10.162.11.8) scli > 

(if you run scli verison 0.3.1)

The utility is running in interactive mode now. Type "help" (without the quotes) to see the available commands. Type "show system info" to find out who the vendor of the device was, what the model name is, and more:

  (10.162.11.8) scli  > show system info
Name: Aficio 2027
Agent: snmp://public@10.162.11.8:161//
Description: RICOH Aficio 2027 1.01.5 / RICOH Network Printer C model /
RICOH Network Scanner C model / RICOH Network Facsimile C
model
Contact: Kurt Pfeifle
Location: Digital Product Development Office, Stuttgart, Infotec Europe B.V.
Vendor: unknown (enterprises.367)
Services: network transport application
Current-Time: 2007-09-21 22:28:10 +01:00
Agent-Boot-Time: 2007-09-03 18:43:42 +02:00
System-Boot-Time: 2007-09-03 18:43:42 +02:00
System-Boot-Dev: RICOH Aficio 2027
System-Boot-Args:
Users: 3
Processes: 5
Memory: 192M
Interfaces: 3

I'm sure you will find more interesting queries of your own quickly.

scli has a good commandline auto-completion (using the [TAB] key) built in. Type "show system [TAB] [TAB]" to get a list of subcommands other than the "info" we used. You'll see possible completions "devices info mounts processes storage". That means "show system storage" is another valid scli sub-command. Try it.

Of course, you can even try "show system" on its own [without any of the available sub commands]. That makes scli execute all of the possible subcommands, and it will return all results at once; to not overwhelm you, any too long output will automatically go piped through a pager.

The same is true for "show [TAB] [TAB]" or "show" all on its own. Run it and see all SNMP info about the device you are currently accessing.

Remember these (very few) tips to help you get up to speed with scli:

  1. Your most important command to remember with scli is "show scli command [TAB] [TAB]".
  2. Your most frequently used initial command with scli will probably be "show scli command tree".
  3. scli ships with a very good man page; make sure to look at it at least one time.
  4. scli can return its query results XML-formated, if called with the "–xml" parameter.

scli is available in Debian (stable, testing and unstable all have 0.2.12-2, while experimental has 0.3.1-0.1). If you happen to use 0.3.1, don't miss to try a scan for SNMP enabled devices in your neighbourhood. At the interactive scli command prompt (scli > -- but make sure you aren't currently connected to a specific SNMP node), type "run scli scan <a-network-IP-address-in-your-reach>". Or run scli in command mode from the shell, and type: "scli -c 'run scli scan <a-network-IP-address-in-your-reach>'" (that network address may be something like 192.168.0.0/24 or 10.162.4.0/22 or whatever your network environment dictates). This scan command is one of the new ones in 0.3; it will present you a list of all SNMP-enabled nodes that respond to the (unsafe) community name "public" (which we didn't explicitely need to type here). You may want to fix that hole…

scli was created by Prof. Jürgen Schönwälder, who also is one of the people who created the SNMP standard and wrote the RFCs describing it.


P.S.: Oh, you *really* wanted to know the answers to these initial questions? Ok, here we go:

Is my new Laserjet PostScript-enabled?

  kurt:~> scli 10.162.11.8 -c "show printer interpreters" | grep Description
Description: Automatic Language Switching
Description: Customized PJL
Description: RPCS
Description: PostScript
Description: PCL 5e Emulation
Description: PCL XL Emulation
Description: Adobe PostScript 3

So, whatever "RPCS" is — PostScript is supported as well. It will be easy to print to it from CUPS…
 

What's on the LCD display on that remote printer right now?
  kurt:~> scli 192.168.23.45 -c "show printer display"
PRINTER LINE TEXT
1 1 No Paper: Tray 4

Uuhh, and you wondered why that thing didn't give any noise since 2 hours…
 

Why doesn't that red light stop flashing on that printer?
  kurt:~> scli 192.168.23.48 -c "show printer covers"
Printer: 1
Cover: 1
Description: Rear Door
Status: coverOpen

Printer: 1
Cover: 2
Description: Top Door
Status: coverClosed

So, that's easy. Tell your user: "Please shut that darn Rear Door again and the flashing red light will go away."

2 comments:

pipitas said...

(This blog post is a slightly updated version of a little article I published almost a year ago on the "debaday.debian.net" website...)

Anonymous said...

Excellent article! This was very useful during my pentest. Thanks a lot.