How to Secure SNMP for Transmitter Control
With modern transmitters opting for Internet-based control
and monitoring in a graphical user interface (GUI) environment, the protocol
employed to enable and secure this operation is critical. A popular non-proprietary, easy, effective protocol is SNMP, or Simple
Network Management Protocol.
However, a known weakness of SNMP Versions
1 and 2 is security. Version 3 addresses this, according to Brian Lindemann, vice
president for RF engineering at Broadcast Electronics, who will speak on the
topic during the NAB Show.
“If the SNMP connection is not properly
secured, the ease of access can allow accidental and/or malicious modification
of the operating parameters at the transmitter site. For instance, modifiable
parameters include power level, operational frequency, audio source, etc.”
SNMP prior to Version 3 uses a
“community string” for security, sent in plain text. Anyone can read its value.
In Version 2 of SNMP, if the browser
has the “write” community string specified, write access is granted. It is
possible for a person who is hoping to just monitor the status may
inadvertently modify an operating parameter. In Version 3 of SNMP, it is
possible to connect as a user with “read-only” permissions. With read-only
permissions, the user cannot modify parameters inadvertently.
“Version 3 of SNMP has been around for a while,” Lindemann
said. “In 2004 the Internet Engineering Task Force recognized SNMPv3 (STD0062)
as the standard for SNMP, having made the two prior versions obsolete. However,
in the broadcast world, the prior versions of SNMP appear to be quite prevalent.
“Some attempts to secure earlier
versions include port blocking, community strings and (if possible) the setup
on a switch or the device to limit which device IP is allowed to talk to it. SNMP
communications does not usually contain secure data, so it is not looked at as
needing encryption. That is, the frequency of a particular transmitter is not
necessarily something that is to be kept confidential. So there is a tendency
not to worry about securing the data.”
SNMP is a popular protocol.
It is easy to use; there are browsers readily available. Because it is a
standard, writing custom user interfaces over it is relatively simple. Inexpensive
MIB browsers are available.
Other non-proprietary protocols include
Common Management Information Protocol, or CMIP. This is also defined in the
Request for Comments documents used in computer network engineering, and has
been standardized by the International
Telecommunication Union. However, it is not commonly used in TCP/IP environments
because of the complexity and resource requirements of its agents and
Other protocols require some amount of
proprietary information. For example, a straight HTTP Web-based interface, as
can be found on many transmitters, displays a lot of information and has the
ability to change various parameters through the interface. However, it doesn’t
support breaking out one or two individual items in which a particular engineer
is interested. With a custom-developed SNMP browser, the engineer can have a
single screen showing alarm status for every piece of equipment at the
transmitter site. If the transmitter supports only HTTP, the engineer would need
a separate Web browser window opened for that piece of equipment.
misconception about SNMP, Lindemann said, is that community
strings provide security. “Just because I can’t think of a way to break it
doesn’t mean someone else can’t, even without really trying.” In looking toward
the future Lindemann expects more equipment to adopt SNMPv3.
The presentation “Securing SNMP for
Transmitter Control” is part of the Tuesday session “Network Security for
Broadcast.” Lindemann will discuss uses
of SNMP as a control protocol and offers techniques and methods for protecting
SNMP-enabled equipment from hackers and virus attacks.