Bug 683081 - net-snmp doesn't work with IPv6 addresses and hosts_acess
Summary: net-snmp doesn't work with IPv6 addresses and hosts_acess
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: net-snmp
Version: 4.9
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Jan Safranek
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-08 14:04 UTC by john.haxby@oracle.com
Modified: 2018-11-14 09:41 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-14 20:20:53 UTC
Target Upstream Version:


Attachments (Terms of Use)
Proposed patch (7.59 KB, patch)
2011-03-08 14:07 UTC, john.haxby@oracle.com
no flags Details | Diff

Description john.haxby@oracle.com 2011-03-08 14:04:42 UTC
Description of problem:
  If you set net-snmp up to use IPv6 and also use hosts_access to limit
  access to snmpd then you'll find that it is not possible to use IPv6 at all.
  Unless I am mistaken, it is not possible to use iptables to control access
  for IPv6 on RHEL4 so we need hosts_access.

Version-Release number of selected component: net-snmp-5.1.2-20.el4


How reproducible:  Always.


Steps to Reproduce:
1.  Configure net-snmp for IPv6 access.  This is in two parts:
    first, edit /etc/snmp/snmp.conf and add a com2sec6 line (copy
    the existing com2sec line and add a "6" to make it start with "com2sec6"
    instead of "com2sec").   The add "udp:161 udp6:161" to the normal snmpd
    options in /etc/sysconfig/snmpd -- I have
    OPTIONS="-Lsd -Lf /dev/null -p /var/run/snmpd.pid -a udp:161 udp6:161"

2.  Configure hosts_access I did this by adding "ALL: ALL" to /etc/hosts.deny
    and the following to /etc/hosts.allow:

       ALL EXCEPT snmpd: ALL
       snmpd: 127.0.0.1
       snmpd: 172.16.0.0/255.255.255.0
       snmpd: [::1]
       snmpd: [fd9e:90b8:4f99::]/48

    (172.16.0.0/255.255.255.0 and [fd9e:90b8:4f99::]/48 are my local IPv4
    and IPv6 networks respectively).
    
3.  Start (or restart) snmpd and run a test snmpget:

    snmpget -v1 -Cf -c public udp6:[::1] sysUpTimeInstance
  
Actual results:
        Timeout: No Response from udp6:[::1].

    and in /var/log/messages:

       snmpd[10244]: Connection from [::1]:-26628 REFUSED


Expected results:
       DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (696691) 1:56:06.91

   and in /var/log/messages:

       snmpd[7517]: Received SNMP packet(s) from UDP/IPv6: [::1]:57819


Additional info:

   Note the difference in the logged originating IP address.   The unpatched
   net-snmp uses a format from which it is essentially impossible to
   reliably extract the originating IP address.  It also treats port numbers
   as signed.

Comment 1 john.haxby@oracle.com 2011-03-08 14:07:56 UTC
Created attachment 482905 [details]
Proposed patch

Using tcp wrappers and IPv6 doesn't work beause the code to extract
the address from the formatted address connection doesn't work for
IPv6 addresses.

This was originally reported in
http://sourceforge.net/tracker/?func=detail&aid=1040431&group_id=12694&atid=112694

The corresponding original commit seems to be
svn diff -r11304:11305 https://net-snmp.svn.sourceforge.net/svnroot/net-snmp

This patch is similar to that original patch with some extra fixes
applied to make it work and to fix some formatting errors that were
later corrected upstream.

Comment 2 john.haxby@oracle.com 2011-03-08 14:11:39 UTC
The patch (above) essentially makes net-snmp behave like the RHEL5 version in regard to its use of hosts_access.  Without the changes, the sample snmpget (in the description) uses "::1]" as its hosts lookup which, needless to say, does not work.

Although RHEL4 is in its final stages it is being actively used (and will be actively used) in IPv6 environments and in these environments it is important to be able to control access to snmpd with hosts_access.   Simply allowing anyone to connect is not reasonable in these environments.

Comment 3 Jan Safranek 2011-03-10 14:40:14 UTC
RHEL 4 is in maintenance phase and only important issues with support tickets are being fixed.

I'll let it open, because it has security implications, it might get fixed with next Net-SNMP security update (if there is one), but don't take it as guaranteed.

Comment 5 Jeremy West 2012-06-14 20:20:53 UTC
This bug is being closed now that RHEL4 has entered a limited maintanence phase.  If you're a customer with ELS entitlements and need to have this fixed, please contact our support team by visiting access.redhat.com


Note You need to log in before you can comment on or make changes to this bug.