Discussion:
5.4.2.1: IP address filtering for SNMPv3
P***@schneider-electric.com
2011-03-16 20:24:42 UTC
Permalink
Q:
Is it possible to configure Net-SNMP 5.4.2.1 to filter IP address(es) when
using SNMPv3 the way com2sec directive does it for SNMPv1/2c ?

Thus far:
Using SNMPv1, multiple clients on the 14 seg can read & write
appropriately. as expected. we've even tuned this down to single machines
using /32. that all works fine. We just can't get SNMPv3 to block on the
same IP/mask settings that SNMPv1 blocks, but instead SNMPv3 connections
read and write our agent regardless of the client's source IP address and
regardless of how we massage the IPaddress/mask. Scubbing the on-line
docs (Net-SNMP and Linux), we've tried mostly to "associate" the com2sec
entries with our v3 profile using the notion of CONTEXT specifiers, but
I'm not understanding what those actually do or don't do and how they
resolve to agent behavior.

My latest attempt below, the rwuser and rouser keywords as the context,
which does not do it. Nor does group names, community names, sec.names,
etc. I'm sure I'm just missing a key point in the docs. I've also tried
various combos of context-names matching in the client configuration
(shown with blank context name this time), but none of that seems to
matter either.

The client config (MGSoft client) is set like this:



thanks for looking, any insights appreciated.

regards,
- pete

# snmpd configuration file
#
#com2sec sec.name source community
com2sec -Cn rouser readonly 192.168.14.0/24 devpublic
com2sec -Cn rwuser readwrite 191.168.14.0/24 devprivate
# group sec.model sec.name
group ROGroup v1 readonly
group ROGroup v2c readonly
group ROGroupV3 usm readonly
group RWGroup v1 readwrite
group RWGroup v2c readwrite
group RWGroup usm readwrite
# view name included/excluded subtree [mask]
view all included .1 80
# Load MIB
dlmod libnbMib /opt/snmp/libnbMib.so
# access group context sec.model sec.level match read write notif
access ROGroup "" v1 noauth exact all none none
access ROGroup "" v2c noauth exact all none none
access ROGroup "" usm auth exact all none none
access RWGroup "" v1 noauth exact all all none
access RWGroup "" v2c noauth exact all all none
access RWGroup "" usm auth exact all all none
# agentaddress [(udp|tcp):]port[@address][,...]
agentaddress udp:161
psyslocation unknown
psyscontact unknown
psysname arch4B37F5
sysObjectID 1.3.6.1.4.1.318.100.20.10.2013
rouser snmpuser
rwuser snmpuser
P***@schneider-electric.com
2011-03-17 20:50:41 UTC
Permalink
attaching the client config shot that didn't come across correctly.
-pupczak
Post by P***@schneider-electric.com
Is it possible to configure Net-SNMP 5.4.2.1 to filter IP
address(es) when using SNMPv3 the way com2sec directive does it for
SNMPv1/2c ?
Using SNMPv1, multiple clients on the 14 seg can read & write
appropriately. as expected. we've even tuned this down to single
machines using /32. that all works fine. We just can't get SNMPv3 to
block on the same IP/mask settings that SNMPv1 blocks, but instead
SNMPv3 connections read and write our agent regardless of the
client's source IP address and regardless of how we massage the
IPaddress/mask. Scubbing the on-line docs (Net-SNMP and Linux),
we've tried mostly to "associate" the com2sec entries with our v3
profile using the notion of CONTEXT specifiers, but I'm not
understanding what those actually do or don't do and how they
resolve to agent behavior.
My latest attempt below, the rwuser and rouser keywords as the
context, which does not do it. Nor does group names, community
names, sec.names, etc. I'm sure I'm just missing a key point in the
docs. I've also tried various combos of context-names matching in
the client configuration (shown with blank context name this time),
but none of that seems to matter either.
[image removed]
thanks for looking, any insights appreciated.
regards,
- pete
# snmpd configuration file
#
#com2sec sec.name source community
com2sec -Cn rouser readonly 192.168.14.0/24 devpublic
com2sec -Cn rwuser readwrite 191.168.14.0/24 devprivate
# group sec.model sec.name
group ROGroup v1 readonly
group ROGroup v2c readonly
group ROGroupV3 usm readonly
group RWGroup v1 readwrite
group RWGroup v2c readwrite
group RWGroup usm readwrite
# view name included/excluded subtree [mask]
view all included .1 80
# Load MIB
dlmod libnbMib /opt/snmp/libnbMib.so
# access group context sec.model sec.level match read write notif
access ROGroup "" v1 noauth exact all none none
access ROGroup "" v2c noauth exact all none none
access ROGroup "" usm auth exact all none none
access RWGroup "" v1 noauth exact all all none
access RWGroup "" v2c noauth exact all all none
access RWGroup "" usm auth exact all all none
agentaddress udp:161
psyslocation unknown
psyscontact unknown
psysname arch4B37F5
sysObjectID 1.3.6.1.4.1.318.100.20.10.2013
rouser snmpuser
rwuser snmpuser
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________
------------------------------------------------------------------------------
Post by P***@schneider-electric.com
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Net-snmp-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Bill Fenner
2011-03-19 02:11:42 UTC
Permalink
Post by P***@schneider-electric.com
Is it possible to configure Net-SNMP 5.4.2.1 to filter IP address(es) when
using SNMPv3 the way com2sec directive does it for SNMPv1/2c ?
No. I think the assumption is that you need to be able to limit v1/2c
because of the weakness of the community string, and there is no need to
limit access using v3 because of its strength.

I don't think it's an unreasonable feature request, though.

Bill
Dave Shield
2011-03-19 10:06:03 UTC
Permalink
Post by P***@schneider-electric.com
Is it possible to configure Net-SNMP 5.4.2.1 to filter IP address(es) when
using SNMPv3 the way com2sec directive does it for SNMPv1/2c ?
No.  I think the assumption is that you need to be able to limit v1/2c
because of the weakness of the community string, and there is no need to
limit access using v3 because of its strength.
I don't think it's an unreasonable feature request, though.
Two comments:
- the IP filtering of community-based SNMP is actually a
by-product of the non-standard way that we handle community-to-group
mapping. The official mechanism (SNMP-COMMNITY-MIB) doesn't include
this element, which is one of the reason's we've never really
supported this MIB.
We didn't need to define our own v3user-to-group mapping, as we
used the SNMPv3 mechanism right from the start. Which is why there's
no equivalent source-based filtering for such requests.


- there *is* a source-filter mechanism available via the TCP
wrappers functionality. So you can restrict access to solely from
known addresses (or block known problem hosts), via
/etc/hosts.{allow,deny}. And of course, local firewalls can do
something similar. But all of this works on an all-or-nothing basis.
It's not possible to restrict certain SNMPv3 users to come from
selected addresses, and allow other SNMPv3 users more widely.

Dave
P***@schneider-electric.com
2011-03-23 12:50:08 UTC
Permalink
ok, thank you.
-pete
Post by P***@schneider-electric.com
Is it possible to configure Net-SNMP 5.4.2.1 to filter IP
address(es) when using SNMPv3 the way com2sec directive does it for
SNMPv1/2c ?
No. I think the assumption is that you need to be able to limit
v1/2c because of the weakness of the community string, and there is
no need to limit access using v3 because of its strength.
I don't think it's an unreasonable feature request, though.
Bill
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________
------------------------------------------------------------------------------
Post by P***@schneider-electric.com
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Net-snmp-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
P***@schneider-electric.com
2011-03-23 12:50:38 UTC
Permalink
ok, thank you.
-pete
Post by Dave Shield
Post by Bill Fenner
Post by P***@schneider-electric.com
Is it possible to configure Net-SNMP 5.4.2.1 to filter IP address(es)
when
Post by Dave Shield
Post by Bill Fenner
Post by P***@schneider-electric.com
using SNMPv3 the way com2sec directive does it for SNMPv1/2c ?
No. I think the assumption is that you need to be able to limit v1/2c
because of the weakness of the community string, and there is no need
to
Post by Dave Shield
Post by Bill Fenner
limit access using v3 because of its strength.
I don't think it's an unreasonable feature request, though.
- the IP filtering of community-based SNMP is actually a
by-product of the non-standard way that we handle community-to-group
mapping. The official mechanism (SNMP-COMMNITY-MIB) doesn't include
this element, which is one of the reason's we've never really
supported this MIB.
We didn't need to define our own v3user-to-group mapping, as we
used the SNMPv3 mechanism right from the start. Which is why there's
no equivalent source-based filtering for such requests.
- there *is* a source-filter mechanism available via the TCP
wrappers functionality. So you can restrict access to solely from
known addresses (or block known problem hosts), via
/etc/hosts.{allow,deny}. And of course, local firewalls can do
something similar. But all of this works on an all-or-nothing basis.
It's not possible to restrict certain SNMPv3 users to come from
selected addresses, and allow other SNMPv3 users more widely.
Dave
------------------------------------------------------------------------------
Post by Dave Shield
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Net-snmp-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________
Loading...