Lab Network Management: SNMP Configuration, Troubleshooting, and Capture - derek-hash/SYS-265-02 GitHub Wiki

1. Introduction

This week’s focus was on setting up and configuring SNMP (Simple Network Management Protocol) on various systems, ensuring proper functionality and security. Additionally, I faced some networking challenges, including DNS configuration issues and firewall settings. With the help of troubleshooting tools like snmpwalk and tcpdump, I was able to successfully verify SNMP connections and monitor network traffic.

2. Troubleshooting and Resolving DNS Issues

One of the first issues I encountered was a DNS misconfiguration that was preventing communication between my systems. Initially, I had set the nameservers in the /etc/resolv.conf file to the WAN nameservers (8.8.8.8) instead of the correct internal nameserver (10.0.5.5).

I realized this error when I was unable to query the DNS successfully from my management system (nmon01) to the target servers. After changing the nameserver in the configuration file, I verified the DNS resolution with nslookup, and the system began resolving addresses correctly. This issue was a simple mistake but took some time to identify. It's a good reminder to always double-check the basic configurations before diving into more complex troubleshooting.

3. SNMP Configuration and Testing

Once the DNS issue was resolved, I proceeded to configure SNMP on my systems, including web01, fw01-derek, and ad01-derek. Here are the key steps I followed:

Editing snmpd.conf: I replaced the default SNMP community string settings with my custom configuration, ensuring that SNMP was properly set up to allow access from my management system (nmon01). This included specifying community strings like SYS265 and setting the access control based on IP ranges.

Using snmpwalk for SNMP Queries: After configuring SNMP, I ran the snmpwalk command from my management system (nmon01) to query the remote devices. I performed these queries to check the SNMP responses and verify that the correct community string and location information were being returned.

Successful Queries: I successfully queried fw01-derek, web01, and ad01-derek using snmpwalk and confirmed that each machine returned the correct system information, including the community string (SYS265), the system name, and location.

4. Using tcpdump to Capture SNMP Traffic

One of the most interesting parts of the lab was using tcpdump to capture SNMP traffic and observe how SNMP data is transmitted. Since SNMP v2c uses plaintext community strings, I wanted to see if the community string was visible during communication.

Starting the tcpdump session: On web01, I initiated a tcpdump session to capture SNMP traffic on UDP port 161. The command I used was:

bash Copy Edit sudo tcpdump -i any -n -vvv udp port 161 This command captures all UDP traffic on port 161, which is used for SNMP.

Capturing and Analyzing the Output: After initiating snmpwalk from nmon01, I observed the tcpdump output, which showed the clear-text community string (SYS265) being transmitted in the SNMP queries. This was a crucial moment, as it demonstrated the security risk of using SNMP v2c—anyone who has access to the network traffic can easily view the community string.

Conclusion on SNMP v2c Security: This further reinforced why SNMPv3 should be used whenever possible, as it offers authentication and encryption to protect sensitive information.

5. Firewall Configuration

Another challenge I faced was ensuring that the firewall rules allowed proper communication for SNMP. Initially, some of the systems were not able to respond to SNMP queries because the firewall was blocking traffic on UDP port 161.

I configured the firewall rules to allow SNMP traffic: On the affected systems, I ensured that UDP port 161 was open for inbound and outbound traffic. I used ufw (for Ubuntu systems) and firewalld (for CentOS systems) to modify the firewall settings, allowing SNMP traffic without errors. This step ensured that SNMP was able to function across the systems without interference from the firewall.

6. Key Learnings and Takeaways

DNS Configuration: Ensuring that the /etc/resolv.conf file contains the correct nameserver is essential for network communication. Small configuration errors, like using public DNS servers instead of internal ones, can lead to connectivity issues. SNMP Configuration: SNMP is a powerful tool for monitoring network devices, but it comes with security risks. Using SNMP v2c exposes clear-text community strings, which can be intercepted. SNMPv3 should be used for encryption and authentication. Network Monitoring with tcpdump: Using tcpdump to capture and analyze SNMP traffic gave me valuable insight into how SNMP works and why it is vulnerable to packet sniffing attacks.

Links: