[SOLVED] Using snmpd with default config

andrixnet · 11-07-2017, 04:28 AM

I was attempting to fiddle with mrtg when I got stuck with problems related to snmpd.

I have enabled /etc/rc.d/rc.snmpd
I am using the installation default config un /etc/snmp/snmpd.conf

The command

Code:

snmpwalk -v 1 localhost -c public system

fails.
/var/log/snmpd.log shows "REFUSED".

Then on 3 different machines I get different results.

On machine 1, a NAT router with 2 interfaces, I can only see snmp data by

Code:

snmpwalk -v 1 internal_IP -c public system

If I try localhost or external_IP, timeout.

On machine 2, a NAT router with 2 interfaces, I cannot see snmp data at all.

On machine 3, a server with one public IP, I cannot see snmp data at all.

Can anyone help me, please?

One more question: does snmpd rotate it's own log file, or should I add it to logrotate?

TenTenths · 11-07-2017, 08:41 AM

On each of the machines try this:

Code:

sudo netstat -lnp | grep snmpd

and that'll tell you what IP it's listening on.

Check any firewalls between devices to ensure they are allowing traffic (udp port 161).

Check the snmpd.conf file to see if the "community name" public has been re-mapped to a different string.

andrixnet · 11-07-2017, 09:26 AM

I've checked again.
First, the configuration is exactly the default configuration. Checked /etc/snmp/snmpd.conf against the contents of the corresponding binary package from the distro.

Code:

####
# First, map the community name "public" into a "security name"

#       sec.name  source          community
com2sec notConfigUser  default       public

####
# Second, map the security name into a group name:

#       groupName      securityModel securityName
group   notConfigGroup v1           notConfigUser
group   notConfigGroup v2c           notConfigUser

####
# Third, create a view for us to let the group have rights to:

# Make at least  snmpwalk -v 1 localhost -c public system fast again.
#       name           incl/excl     subtree         mask(optional)
view    systemview    included   .1.3.6.1.2.1.1
view    systemview    included   .1.3.6.1.2.1.25.1.1

####
# Finally, grant the group read-only access to the systemview view.

#       group          context sec.model sec.level prefix read   write  notif
access  notConfigGroup ""      any       noauth    exact  systemview none none

There is no firewall rule restricting access to UDP port 161.
To confirm it, I temporarily deleted all the rules (iptables -F) and tried again with same result.

Also, snmpd listens to all interfaces:

Code:

udp        0      0 0.0.0.0:161             0.0.0.0:*

TenTenths · 11-07-2017, 09:40 AM

Try adding

Code:

rocommunity public

at the start of your snmpd config file and restart the service.

andrixnet · 11-07-2017, 12:04 PM

I've added the suggested setting in snmpd.conf and restarted the service.
Situation remains the same.

Code:

NET-SNMP version 5.7.2
Connection from UDP: [127.0.0.1]:54812->[127.0.0.1]:161 REFUSED

TenTenths · 11-08-2017, 05:18 AM

That's rather odd to be honest, I've pretty much the same config and can walk the localhost no problem.

andrixnet · 11-09-2017, 01:57 AM

That's true. Last time I used snmpd on Slackware was on an old Slackware-12.2 server.

What is stranger even, is that I can reproduce this non-working state on any Slackware-14.1 installation. (for the moment 14.1 is of main interest because a migration of our servers to 14.2 is scheduled sometime in the spring 2018)

Richard Cranium · 11-09-2017, 08:43 PM

Try

Code:

rocommunity  public localhost

andrixnet · 11-10-2017, 03:07 AM

I've added it as top line in snmpd.conf
Restarded the daemon.

Code:

snmpwalk -v 2c  localhost  -c public system
Timeout: No Response from localhost

 snmpwalk -v 1  localhost  -c public system
Timeout: No Response from localhost

Richard Cranium · 11-10-2017, 11:13 AM

Are you certain snmpd is running?

abga · 11-10-2017, 03:31 PM

While I believe you've checked the network&firewall configuration, just to make sure you're ok can you please recheck it:

Code:

ifconfig lo
#result - something like:
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 4114378  bytes 9782966485 (9.1 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4114378  bytes 9782966485 (9.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ip link show dev lo
#result:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

ip route show
#result - look for:
127.0.0.0/8 dev lo scope link

iptables -vnL | grep lo
#result (without grep these lines shoud be part of the INPUT & OUTPUT chain):
4121K 9786M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4121K 9786M ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0

# you can also try this as some people use some complex firewalling and are under the false impression that issuing only iptables -F is flushing all rules
iptables -vnL -t mangle

#check if the snmpd is loaded and listening (the "standard" netstat should work too but I much prefer lsof -i)
lsof -i udp:161
#result:
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
snmpd   19881 root    7u  IPv4 172545      0t0  UDP *:snmp

I have no x86 test system ATM and tried to replicate your reported problem on an ARM device running Slack ARM 14.2 - current with NET-SNMP version 5.7.3
Started the snmpd daemon, didn't touch the default /etc/snmp/snmpd.conf file and was able to connect and walk with both v1 / v2:

Code:

snmpwalk -V
NET-SNMP version: 5.7.3

snmpwalk -v 1 -c public localhost:161
snmpwalk -v 2c  localhost:161  -c public system

For comparison, here you can find the default snmpd.conf that comes with NET-SNMP version 5.7.3 - Slack ARM 14.2 - current (only the lines that are uncommented):

Code:

grep -v "^#" /etc/snmp/snmpd.conf | grep -v "^$"
com2sec notConfigUser  default       public
group   notConfigGroup v1           notConfigUser
group   notConfigGroup v2c           notConfigUser
view    systemview    included   .1.3.6.1.2.1.1
view    systemview    included   .1.3.6.1.2.1.25.1.1
access  notConfigGroup ""      any       noauth    exact  systemview none none
syslocation Unknown (edit /etc/snmp/snmpd.conf)
syscontact Root <root@localhost> (configure /etc/snmp/snmp.local.conf)
pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat

Your error message:

Quote:

NET-SNMP version 5.7.2
Connection from UDP: [127.0.0.1]:54812->[127.0.0.1]:161 REFUSED

could suggest that snmpd doesn't want to talk on localhost and some advise to add a rule in /etc/hosts.allow for the tcp wrapper

Code:

snmpd: 127.0.0.1

I also hope your /etc/hosts contains this:

Code:

# For loopbacking.
127.0.0.1               localhost

While I'm butchering myself a Linux system, not even using the default rc.inet* (removing the exec bit) in Slack, and defining manually all my networking/firewalling needs, I do respect some "old" networking configuration standards in the related /etc/inetd.conf & hosts files.

andrixnet · 11-10-2017, 04:37 PM

@abga: I've tested each suggested point in order:

Code:

# ifconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 13279824  bytes 1416747709 (1.3 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13279824  bytes 1416747709 (1.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Code:

# ip link show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

Code:

# ip route show | grep lo
127.0.0.0/8 dev lo  scope link

Empty output here, but INPUT and OUTPUT chains have policy=ACCEPT:

Code:

# iptables -vnL | grep lo

All chains are empty and with policy=ACCEPT:

Code:

# iptables -vnL -t mangle

Code:

# lsof -i udp:161
COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
snmpd   21566 root    7u  IPv4 12725032      0t0  UDP *:snmp

Code:

# snmpwalk -V
NET-SNMP version: 5.7.2

Configuration file:

Code:

# grep -v "^#" /etc/snmp/snmpd.conf | grep -v "^$"
com2sec notConfigUser  default       public
group   notConfigGroup v1           notConfigUser
group   notConfigGroup v2c           notConfigUser
view    systemview    included   .1.3.6.1.2.1.1
view    systemview    included   .1.3.6.1.2.1.25.1.1
access  notConfigGroup ""      any       noauth    exact  systemview none none
syslocation Unknown (edit /etc/snmp/snmpd.conf)
syscontact Root <root@localhost> (configure /etc/snmp/snmp.local.conf)
pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat

And finally, yes, adding snmpd to /etc/hosts.allow did the trick!

Code:

snmpd: 127.0.0.1

Indeed, snmpd is a standalone daemon, but I totally forgot that there are such daemons that run as standalone, yet still apply the rules from hosts.allow / hosts.deny, not just those started by inetd.
Now that I realised it, I feel stupid to have overlooked that... My bad... No matter, it can happen.

Thank you very much for pointing it out.

andrixnet · 11-10-2017, 04:39 PM

The lesson learned here is:

snmpd will also takes into account access control rules via the tcpwrappers library and the configuration files /etc/hosts.allow and /etc/hosts.deny.

abga · 11-10-2017, 05:19 PM

@andrixnet

Always happy to help!
I'm a little bit frustrated myself that I didn't help earlier. I was reluctant because the last time I was using snmp was almost a decade ago

And I do remember having some issues with the rather heterogeneous HW landscape that I needed to monitor. I was literally dreaming about MIBs, OIDs, Traps (etc) and tunneling the - at that time - insecure SNMP protocol/traffic. I'm fine now with Monitorix on standalone systems.
http://www.monitorix.org/

My /etc/hosts.allow is empty and I was still able to talk with the snmpd. However, as stated above, I was careful to define my networks in:
/etc/hosts

Code:

# For loopbacking.
127.0.0.1               localhost
# etc ... other networks

Either the definition of the networks (localhost) in /etc/hosts would suffice, or they might have changed the /etc/hosts.allow requirements/checking in NET-SNMP version 5.7.3

Richard Cranium · 11-10-2017, 09:21 PM

Quote:

Originally Posted by abga

Either the definition of the networks (localhost) in /etc/hosts would suffice, or they might have changed the /etc/hosts.allow requirements/checking in NET-SNMP version 5.7.3

I can tell you that I have localhost defined in /etc/hosts and my /etc/hosts.allow file is empty.

I actually defined rocommunity as...

Code:

# rocommunity: a SNMPv1/SNMPv2c read-only access community name
#   arguments:  community [default|hostname|network/bits] [oid]

rocommunity  public 172.16.0.0/16

...and I am able to walk that snmpd instance from a different machine that resides in that subnet.

EDIT: I've had to deal with SNMP for telecom alarm reporting as late as 2012. I'll just say that the Simple part applies to the protocol itself and not to any of the underlying models. Ugh.