Simple Network Management Protocol (SNMP) is an ancient and virtually ubiquitous protocol for monitoring the status, viewing and setting the configuration of networked hosts and devices like servers, switches, access points, routers and more. This is accomplished by GETting or SETting variables organized into Management Information Bases (MIBs). Some MIBs are standardized which provides monitoring and management software (an SNMP Agent) a consistent interface to perform common functions (e.g. collect network traffic statistics regardless of target operating system and SNMP implementation) and may be included by default or easily activated with a particular implementation or agent. Other MIBs are proprietary and allow custom functionality to be implemented (e.g. collect environmental data from or send a sophisticated configuration profile to a specialty enterprise device) and definitions of such MIBs may be provided by a hardware vendor or a community effort to extend the functionality of their existing SNMP agent or provide support to third-party agents. General-purpose monitoring/graphing software like Cacti for example often ship with support for several MIBs and both corporate vendors and community members generously release their own definitions which unlock special functionality and support features not otherwise available.

Generally one of the first things you will do on a new server is configure the SNMP daemon (SNMPD) from the net-snmp package (Microsoft Windows has its own implementation which can be installed via Add/Remove Windows Components (https://kb.paessler.com/en/topic/663-how-do-i-install-the-snmp-service-on-windows-systems) so you can:

• Track resource consumption and perform diagnostics and troubleshooting from a centralized location
• Make decisions about resource allocation, deployments and hardware purchases
• Establish a baseline so when things go awry you can use clues about changes in resources to help make determinations

Although it's good to set up proactive alerts for expected scenarios not every scenario can be foreseen and not every alert is successfully triggered, received, properly interpreted or acknowledged. A centralized statistics aggregator is an invaluable tool in emergency diagnostics - not just for seeing things that are obvious on their face. It is invaluable to be able to "go back in time" and compare observations to past, expected behaviour. Some real world examples of things SNMP in conjunction with a simple statistics aggregator like Cacti have helped me detect are:

• Various forms of DoS attack
• Malicious and malfunction instigated broadcast storms
• Pending storage exhaustion
• New and unexpected sources of radio interference
• Misconfigured or unconfigured traffic shaping and QoS
• Impending and actual link saturation
• Unthrottled website scraping
• Spam/phishing/webshell and/or backdoored website pages
• Various ISP customer and corporate user use policy violations

to name just a few.

This tutorial will help you install and configure a basic working SNMP daemon that can be queried by agents supporting versions 1 and 2c of the protocol with simple IP-whitelisting security and read-only access. SNMP version 3 introduces numerous security enhancements and is more difficult to configure, however version 2c is still (c. 2024) the most broadly supported protocol for hosts and agents; it is sufficient for statistics gathering in most environments.

It should be noted that security may be improved (specifically regarding automated scans and attacks) by changing the community name from public to anything else, as this is universally used as the default read-only community name. Community names are not shared secrets; they are intended to be used for grouping together and organizing large deployments. If you require strong authentication or encryption for dealing with sensitive data it is necessary to use version 3 or to implement a transparent layer of encryption, such as a VPN or SSH tunnel.

As always, I recommend only exposing this type of service on a restricted or, ideally, fully out-of-band (OOB) management and/or monitoring network - physical, virtual or otherwise. Simply restricting the address and/or ranges that your SNMP daemon will respond to does not preclude attacks that may take advantage of flaws in the software or implementation (i.e.: buffer underruns), unless complemented by the same rules implemented in the local firewall. I think that alone is good incentive to put the effort into a secluded management/monitoring subnet for the sake of avoiding unnecessary complexity and increasing security writ large.

To install snmpd on Debian and its derivatives (Ubuntu) run:
apt-get install snmp snmpd libsnmp-dev

The default configuration file provided by the package has snmpd listening only on the local ipv4 and ipv6 interfaces. If you would like to open up network access edit /etc/snmp/snmpd.conf to reflect:
... # agentaddress: The IP address and port number that the agent will listen on. # By default the agent listens to any and all traffic from any # interface on the default SNMP port (161). This allows you to # specify which address, interface, transport type and port(s) that you # want the agent to listen on. Multiple definitions of this token # are concatenated together (using ':'s). # arguments: [transport:]port[@interface/address],... # agentaddress 127.0.0.1,[::1] agentAddress udp:161 ...
By not specifying an IP address snmpd is instructed to listen on all available interfaces (i.e. 0.0.0.0).

Also open up access to the full dataset:
... # rocommunity: a SNMPv1/SNMPv2c read-only access community name # arguments: community [default|hostname|network/bits] [oid | -V view] # Read-only access to everyone to the systemonly view # rocommunity public default -V systemonly rocommunity public 192.168.0.0/24 rocommunity6 public default -V systemonly ...
Specify an IP address, list of addresses or a subnet in CIDR format as shown above to allow queries from authorized clients only.

Now enable the service and punch a hole in the firewall:
systemctl enable snmpd systemctl start snmpd ufw allow from 192.168.0.0/24 to any port snmp ufw enable

To install the SNMP daemon and associated utilities on a modern flavour of Redhat and derivatives (Fedora, RHEL, CentOS Stream, Alpine, Rocky, etc...) run:
dnf install net-snmp net-snmp-utils systemctl enable snmpd systemctl start snmpd

To install them on a legacy iteration (i.e. CentOS 7 and earlier) run:
yum install net-snmp net-snmp-utils chkconfig snmpd on service snmpd start

If you are using firewalld punch a hole in the firewall thus:
firewall-cmd --zone=public --add-port=161/udp --permanent firewall-cmd --zone=public --add-port=161/tcp --permanent

If you are using the iptables service to load rules via iptables-restore instead edit /etc/sysconfig/iptables to include:
... -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.0.0/24 -p udp -m udp --dport 161 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 161 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT ...

Then reload the firewall ruleset:
systemctl restart iptables

On Oracle Solaris 10 SNMP is installed and enabled as part of the standard distribution. It runs under the service name sma. Configuration is stored in /etc/sma/snmp/snmpd.conf and follows the same scheme as the Linux variant as covered previously.

After making any configuration change restart the agent:
svcadm restart sma

If you are running an installation of Communications Messaging Server and would like to enable interoperability it is necessary to configure the AgentX protocol:
cat >> /etc/sma/snmp/snmpd.conf # Messaging Server's subagent requires the AgentX protocol master agentx ^D # Control-D exits the iunterface, appending the above to the flatfile

On Oracle Solaris 11 net-snmp should roll out with a standard installation; if this is not the case for you it can be installed after the fact thus:
pkg install net-snmp

Solaris' SNMP package is sourced from the same codebase as Linux, therefore configuration is identical as demonstrated for linux per the above examples. You will find the configuration flatfile located at /etc/net-snmp/snmp/snmpd.conf

To launch the service and enable it to start at next boot run:
svcadm enable net-snmp

Restart the daemon after any change to the configuration:
svcadm restart net-snmp

Bonus points: I use a quick-and-dirty abbreviated snmpd.conf where I want to give public read-only access to vital statistics (i.e. traffic statistics for cacti, storage consumption for nagios/icinga) and limit access to a private management subnet, you may find it has some utility versus wading through the reams of comments and particularly obtuse syntax used in these flatfiles:
com2sec local 127.0.0.1/32 public com2sec local 192.168.0.0/24 public group MyROGroup v1 local group MyROGroup v2c local group MyROGroup usm local view all included .1 80 access MyROGroup "" any noauth exact all none none syslocation Physical/Virtual Location syscontact Administrator's Name <[email protected]>

Further reading...

• An excellent deeper dive into the fundamental workings of SNMP can be found at DPS Telecom > What's the Default SNMP Port Number? Is SNMP TCP or UDP? (https://www.dpstele.com/snmp/transport-requirements-udp-tcp.php).
• The Wikipedia > Simple Network Management Protocol (https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol) article also provides a highly detailed breakdown of SNMP concepts, especially in regard to the security implications and differences between each version of the protocol.