V3 Informs

[Joan Landry]

All,
I have searched for documentation on net-snmp to find out how to
configure net-snmp so that I can send v3 informs from a subagent by
calling snmpinform().

Specifically I want to be able to configure via the etc/snmp/snmpd.conf
the following:
1. create an snmpNotifyTable entry that has traptype = inform
2. create a snmpTargetAddress row in the snmpTargetAddressTable with a
tag-list
3. create a snmpTargetAddressParams row where I can specify the
authentication/privacy for the inform to be sent
4. create a snmpNotifyFilterProfileTable row
5. create a snmpNotifyFilter row

Does net-snmp support sending informs from the subagent and if so
how/where is the documentation on how to configure it to do so.
Thanks so much for any help in this area.
Joan Landry

[Joan Landry]

I would like to know how to add a new vacmContextName to netsnmpd.

I added the following user
com2sec -Cn context1 v3user1 default v3user1
access groupd context1 usm authPriv exact readview writeview
notifyview

This does not work as acces is denied when I do snmpwalk. If I remove
the context1 name from the 2 entries above and I also remove it from the
mib browser context then I can gain access via the v3user1 entry.

I have determined that when I walk the vacmContextTable - it only
contains the default empty row.
So I think this is the reason why the access is denied. Yet I have found
no documentation on how to add a new row to the vacmContextTable via the
snmpd.conf file.

Does net-snmp support the ability to configure a context name via
snmpd.conf other then the default "" empty row?
Is there a list of what net-snmp supports and what it does not support?
Joan

[Dave Shield]

Post by Joan Landry
I would like to know how to add a new vacmContextName to netsnmpd.
I added the following user
com2sec -Cn context1 v3user1 default v3user1
access groupd context1 usm authPriv exact readview writeview notifyview

If you are using "com2sec", then this relates to SNMPv1/2.
So your "access" lines should be something like

access {group} context1 v1 noauth exact {rview} {wview} {nview}
access {group} context1 v2c noauth exact {rview} {wview} {nview}
or
access {group} context1 any noauth exact {rview} {wview} {nview}

Post by Joan Landry
This does not work as acces is denied when I do snmpwalk.

What is the exact "snmpwalk" command you are using?
Also, what MIB information have you registered in "context1",
and how have you done this?


Dave

[Joan Landry]

Does net-snmp support the ability to add entries to the
snmpTargetAddress for means of limiting v2 access to a v3 box.
If so how would this be configured via snmpd.conf?

According to snmpv3 the tag-list specified in the snmpCommunityEntry
could be used to reference a list of ip addresses contained in an
snmpTargetAddress row in the snmpTargetAddressTable. Only the ip
address's in the snmpTargetaddress row would have access via snmpV2.

Thanks for any info on being able to configure snmpTargetAddress and
snmpTaregetAddrParms from the snmpd.config file
Joan Landry

[Mike Ayers]

Behalf Of Joan Landry
Sent: Tuesday, April 08, 2008 1:48 PM
Does net-snmp support the ability to add entries to the
snmpTargetAddress for means of limiting v2 access to a v3 box.
If so how would this be configured via snmpd.conf?

It does not, as that would be contrary to the intent of the snmpTargetAddrTable. It's for target configuration, not source configuration. There is no standard way to restrict by source address - please consider v3/USM/VACM for this. The net-snmp specific com2sec directive of snmpd.conf can be used to restrict access of a v2c user by IP address.


HTH,

Mike

[Dave Shield]

I have searched for documentation on net-snmp to find out how to configure
net-snmp so that I can send v3 informs
Specifically I want to be able to configure via the etc/snmp/snmpd.conf the
1. create an snmpNotifyTable entry that has traptype = inform
2. create a snmpTargetAddress row in the snmpTargetAddressTable with a
tag-list
3. create a snmpTargetAddressParams row where I can specify the
authentication/privacy for the inform to be sent

Put the following entry (untested) in the snmpd.conf:

trapsess -Ci -v 3 -u {user} -l {level} -a {MD5|SHA} -A {authpass} {host}

Plus -x/-X flags if you need encryption.

4. create a snmpNotifyFilterProfileTable row
5. create a snmpNotifyFilter row

Ummm... I'm not sure there's snmpd.conf support for the filter tables.

Does net-snmp support sending informs from the subagent

Yes - just call 'send_v2trap()' or 'send_easy_trap()' or 'send_trap_vars()'

The subagent will pass the notification to the master agent.
It's the master agent that decides how to format the trap
(trap vs inform, SNMP version, user/community/etc),
and where to send it.


Dave

[Joan Landry]

Post by Joan Landry

Post by Dave Shield
If you are using "com2sec", then this relates to SNMPv1/2.

What should I use for SNMPv3?

I created the following 2 users one has a context name defined the other
one does not. The one that uses a context name does not work, the other
one works fine.

The one that works:
com2sec userc default userc
group groupc usm userc
view readview included .1
view writeview included .1
access groupc "" usm authPriv exact readview writeview none
createUser userc MD5 abcdefgh DES abcdefgh

snmpget -v 3 -l priv -u userc -a MD5 -A abcdefgh -x DES -X abcdefgh
localhost SNMPv2-MIB::sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: LocalHost <<-- get worked

The one that does not work:
com2sec -Cn context1 v3user default v3user
group groupd usm v3user
view readview included .1
view writeview included .1
access groupd context1 usm authPriv exact readview writeview
notifyview
createUser v3user MD5 abcdefgh DES abcdefgh

snmpget -v 3 -n context1 -l priv -u v3user -a MD5 -A abcdefgh -x DES -X
abcdefgh localhost SNMPv2-MIB::sysContact.0
Timeout: No Response from localhost.
Also when I try to do a get via Mgsoft mib browser tool with the same
v3user entry (spcecifying context1) I do not get access to the object.
If I remove the context1 from the setup - the same entry works fine and
I am able to get sysContact.

Post by Joan Landry

Post by Dave Shield
What is the exact "snmpwalk" command you are using?

snmpget -v 3 -n context1 -l priv -u v3user -a MD5 -A abcdefgh -x DES -X
abcdefgh localhost SNMPv2-MIB::sysContact.0

Post by Joan Landry

Post by Dave Shield
Also, what MIB information have you registered in "context1", and how

have you done this?
I do not know what this means, so can you tell me what I have to do to
register mibs into context1? Also, How do I add a vacmContextEntry to
the vacmContextTable?
My context1 entry does not show up when I walk the vacmContexTable.
So what am I doing wrong?
Thanks
Joan



-----Original Message-----
From: ***@googlemail.com [mailto:***@googlemail.com] On
Behalf Of Dave Shield
Sent: Wednesday, April 09, 2008 4:22 AM
To: Joan Landry
Cc: net-snmp-***@lists.sourceforge.net
Subject: Re: Configuring a new vacmContextName

Post by Joan Landry
I would like to know how to add a new vacmContextName to netsnmpd.
I added the following user
com2sec -Cn context1 v3user1 default v3user1
access groupd context1 usm authPriv exact readview writeview

notifyview

If you are using "com2sec", then this relates to SNMPv1/2.
So your "access" lines should be something like

access {group} context1 v1 noauth exact {rview} {wview}
{nview}
access {group} context1 v2c noauth exact {rview} {wview}
{nview}
or
access {group} context1 any noauth exact {rview} {wview}
{nview}

Post by Joan Landry
This does not work as acces is denied when I do snmpwalk.

What is the exact "snmpwalk" command you are using?
Also, what MIB information have you registered in "context1", and how
have you done this?


Dave

[Mike Ayers]

Behalf Of Joan Landry
Sent: Wednesday, April 09, 2008 1:17 PM

Post by Dave Shield
If you are using "com2sec", then this relates to SNMPv1/2.

What should I use for SNMPv3?
I created the following 2 users one has a context name
defined the other
one does not. The one that uses a context name does not work,
the other
one works fine.

Users don't "have" contexts so much as they "exist in" them. What are you trying to accomplish here?


Thanks,

Mike

[Dave Shield]

Post by Joan Landry

Post by Dave Shield
If you are using "com2sec", then this relates to SNMPv1/2.

What should I use for SNMPv3?

Take a step back.
Think about what the "com2sec" directive is doing.

It's taking the only administrative information that is available
in SNMPv1/2c (the community string), and mapping it into a
security name and an (optional) context.

Now think about the admin information that is available
with SNMPv3. There's a username (which isn't strictly the
same as a security name, but is close enough), and an
(optional) context. So the same information is there
already, as part of the SNMPv3 protocol.

The basic purpose of "com2sec" is precisely to bring
SNMPv1/2c up into line with SNMPv3.

[Joan Landry]

Yes that worked - thanks.
Is there a place where I could find these kind of commands documented?
Thanks,
Jlandry

-----Original Message-----
From: net-snmp-users-***@lists.sourceforge.net
[mailto:net-snmp-users-***@lists.sourceforge.net] On Behalf Of Dave
Shield
Sent: Wednesday, April 09, 2008 4:16 AM
To: Joan Landry
Cc: net-snmp-***@lists.sourceforge.net
Subject: Re: V3 Informs

Post by Joan Landry
I have searched for documentation on net-snmp to find out how to
configure net-snmp so that I can send v3 informs
Specifically I want to be able to configure via the
etc/snmp/snmpd.conf the
1. create an snmpNotifyTable entry that has traptype = inform 2.
create a snmpTargetAddress row in the snmpTargetAddressTable with a
tag-list 3. create a snmpTargetAddressParams row where I can specify
the authentication/privacy for the inform to be sent

Put the following entry (untested) in the snmpd.conf:

trapsess -Ci -v 3 -u {user} -l {level} -a {MD5|SHA} -A {authpass}
{host}

Plus -x/-X flags if you need encryption.

Post by Joan Landry
4. create a snmpNotifyFilterProfileTable row 5. create a
snmpNotifyFilter row

Ummm... I'm not sure there's snmpd.conf support for the filter tables.

Post by Joan Landry
Does net-snmp support sending informs from the subagent

Yes - just call 'send_v2trap()' or 'send_easy_trap()' or
'send_trap_vars()'

The subagent will pass the notification to the master agent.
It's the master agent that decides how to format the trap (trap vs
inform, SNMP version, user/community/etc), and where to send it.


Dave

------------------------------------------------------------------------
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't
miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
avaone

[Mike Ayers]

Behalf Of Joan Landry
Sent: Wednesday, April 09, 2008 1:33 PM
Is there a place where I could find these kind of commands documented?

http://www.net-snmp.org/docs/man/snmpd.conf.html


HTH,

Mike

[Dave Shield]

Post by Joan Landry
Yes that worked - thanks.
Is there a place where I could find these kind of commands documented?

snmptrap(1) and snmpcmd(1)

"trapsess" is basically the admin/destination aspects of the snmptrap command,
embedded within the agent.

Dave

[Joan Landry]

Post by Joan Landry

Post by Mike Ayers
Users don't "have" contexts so much as they "exist in" them. What are

you trying to accomplish here?

My two goals are:
1. I would like to be able to configure a CONTEXT in the snmpd.conf file
and have it show up in the vacmContextTable, when I walk this table.
2. I would like to be able to use this CONTEXT in the following:
com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
access GROUP CONTEXT {any|v1|v2c|usm} LEVEL PREFX READ WRITE NOTIFY
And have this configuration work so that when I specify the same CONTEXT
on the mibBrowser or when doing a snmpget or snmpset with the same
CONTEXT - it works.
Such as:
snmpget -v 3 -n context1 -l priv -u user3 -a MD5 -A abcdefgh -x DES -X
abcdefgh localhost SNMPv2-MIB::sysContact.0

Currently the only CONTEXT that I am able to get working is the "" empty
default one.
So the difference is that the following configuration works:
(I can access the mib2 objects):
com2sec userc default userc
group groupc usm userc
access groupc "" usm authPriv exact readview writeview none
createUser userc MD5 abcdefgh DES abcdefgh

And this configuration does not work (I can not access the mib2
objects):
com2sec -Cn context1 userc default userc
group groupc usm userc
access groupc context1 usm authPriv exact readview writeview none
createUser userc MD5 abcdefgh DES abcdefgh

The only difference between the two configuration is that I added a
context name of "context1" to the 2nd configuration. Also, the 2nd
configuration did not result in a new vacmContextName being added to the
vacmContextTable.

Thanks,
Joan


-----Original Message-----
From: Mike Ayers [mailto:***@tvworks.com]
Sent: Wednesday, April 09, 2008 8:34 PM
To: Joan Landry; net-snmp-***@lists.sourceforge.net
Subject: RE: Configuring a new vacmContextName

Post by Joan Landry
Joan Landry
Sent: Wednesday, April 09, 2008 1:17 PM

Post by Mike Ayers

Post by Dave Shield
If you are using "com2sec", then this relates to SNMPv1/2.

What should I use for SNMPv3?
I created the following 2 users one has a context name defined the
other one does not. The one that uses a context name does not work,
the other one works fine.

Users don't "have" contexts so much as they "exist in" them.
What are you trying to accomplish here?


Thanks,

Mike

[Jelena Savic]

What is the difference between obsolete and deprecated status in the Mib?
Which do you use when?

Also what if you want to delete some of the valuse of objects, is there a method of making them obsolete,
or do you just remove them?

Thanks

[Mike Ayers]

Behalf Of Jelena Savic
Sent: Thursday, April 10, 2008 9:05 AM
What is the difference between obsolete and deprecated status
in the Mib?
Which do you use when?

In a nutshell, "deprecated" means "It still works, but you shouldn't use it if possible. Change your systems to stop using it before it is obsolete," and "obsolete" means "It doesn't work at all anymore". I believe for MIBs, "obsolete" also means "do not implement".

Also what if you want to delete some of the valuse of
objects, is there a method of making them obsolete,
or do you just remove them?

Pedantically, we are talking about the objects, not their values. The path to nonexistence will be decided by the MIB owner, generally based on support considerations. If she has customers that she likes who use the object in question, deprecation, along with an upgrade path to the newer, better object structure is the path she will take. If he doesn't know of any userbase, and/or if the cost of losing the object is low enough, he may just obsolete the object. There are cases, especially in the development cycle, where obsolescence can be used to make a "brick wall", ensuring all systems are upgraded (this trick only tends to work well when all parties agree to it in advance).


HTH,

Mike

[Joan Landry]

Post by Joan Landry

Post by Mike Ayers
It does not, as that would be contrary to the intent of the

snmpTargetAddrTable.

I think that this is not true. The snmpTargetAddrTable defines a tagList
that can be used to limit the outgoing notifications and also can be
used to limit the incoming requests.
I attached the v3 specifications for this below - please let me know if
this aspect of v3 is supported via net-snmp.
The basic idea is that you can set up a list of target address's in the
snmpTargetAddress table that can be used to define a list of ip address
that you will accept SNMPv2 access request from. This is much different
from globally denying access based on an ip address, which would result
in also denying v3 access from the same ip address. This is meant to
allow for v2 co-existance in a v3 environment.

V3 Specifications where this is defined:
snmpCommunityTransportTag OBJECT-TYPE
DESCRIPTION
"This object specifies a set of transport endpoints
which are used in two ways:
- to specify the transport endpoints from which an
SNMP entity will accept management requests, and
- to specify the transport endpoints to which a
notification may be sent using the community
string matching the corresponding instance of
snmpCommunityName.
In either case, if the value of this object has
zero-length, transport endpoints are not checked when
either authenticating messages containing this community
string, nor when generating notifications.

The transports identified by this object are specified
in the snmpTargetAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value
are identified.

If a management request containing a community string
that matches the corresponding instance of
snmpCommunityName is received on a transport endpoint
other than the transport endpoints identified by this
object the request is deemed unauthentic.

When a notification is to be sent using an entry in
this table, if the destination transport endpoint of
the notification does not match one of the transport
endpoints selected by this object, the notification
is not sent."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 }

Joan Landry

-----Original Message-----
From: Mike Ayers [mailto:***@tvworks.com]
Sent: Thursday, April 10, 2008 12:57 PM
To: Joan Landry; net-snmp-***@lists.sourceforge.net
Subject: RE: SnmpTargetAddress

Post by Joan Landry
Joan Landry
Sent: Tuesday, April 08, 2008 1:48 PM
Does net-snmp support the ability to add entries to the
snmpTargetAddress for means of limiting v2 access to a v3 box.
If so how would this be configured via snmpd.conf?

It does not, as that would be contrary to the intent of the
snmpTargetAddrTable. It's for target configuration, not source
configuration. There is no standard way to restrict by source address -
please consider v3/USM/VACM for this. The net-snmp specific com2sec
directive of snmpd.conf can be used to restrict access of a v2c user by
IP address.


HTH,

Mike

[Mike Ayers]

Behalf Of Joan Landry
Sent: Thursday, April 10, 2008 10:40 AM

Post by Mike Ayers
It does not, as that would be contrary to the intent of the

snmpTargetAddrTable.
I think that this is not true. The snmpTargetAddrTable
defines a tagList
that can be used to limit the outgoing notifications and also can be
used to limit the incoming requests.

<SNIP>
snmpTargetAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTargetAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of transport addresses to be used in the generation
of SNMP messages."
::= { snmpTargetObjects 2 }
</SNIP>

The words "generation" and "target" imply "not incoming".

snmpCommunityTransportTag OBJECT-TYPE

Ah! So this is not about the snmpTargetAddrTable at all, really. The question you wanted to ask was, "Does net-snmp support the community MIBs?" The answer is, "Net-snmp does not support the community MIBs." If you want to restrict the source address of v1 or v2c requests, I direct your attention again to the com2sec directive of the snmpd.conf file. If you want actual security, I direct your attention again to v3/USM/VACM.


HTH,

Mike

[Joan Landry]

Post by Joan Landry

Post by Mike Ayers
Ah! So this is not about the snmpTargetAddrTable at all,

really. The question you >>wanted to ask was, "Does net-snmp support
the community MIBs?" The answer is, "Net-snmp does not support the
community MIBs." If you want to restrict the source address of v1 or
v2c requests, I direct your attention again to the com2sec directive of
the snmpd.conf file. If you want actual security, I direct your
attention again to v3/USM/VACM.

Actually I am really looking to solve one problem.

I want to have a V3 secure box, where v2 access is allowed to only a
select group of stations.

I would use v3/usm/vacm config to define v3 access to the box.
If I add a com2sec configuration for v2 access to the same box - then in
essence I no longer have a v3 secure box. Anyone can get in just using
the v2 setup. In so doing I have obliterated the notion my box being v3
secure. It is only secure to the stations playing by the v3 rules,
however anyone can just use the v2 rules and get into the same box.

At the same time I have users that I know are legitimate and they only
have v2 ability so I need to give only these users access to my box via
v2.

It is I think referred to a v2/v3co-existence in a v3 secure
environment.

So if you have a way to solve this problem in net-snmp that is what I am
looking for.

The reason I asked about the snmpCommunityTransportTag is because it
provides the mechanism to solve the above problem by using the
snmpTargetAddressTable as defined in the snmpCommunityTable.

Thanks for your time,
Joan

-----Original Message-----
From: Mike Ayers [mailto:***@tvworks.com]
Sent: Thursday, April 10, 2008 2:31 PM
To: Joan Landry; net-snmp-***@lists.sourceforge.net
Subject: RE: SnmpTargetAddress

Post by Joan Landry
Joan Landry
Sent: Thursday, April 10, 2008 10:40 AM

Post by Mike Ayers

Post by Mike Ayers
It does not, as that would be contrary to the intent of the

snmpTargetAddrTable.
I think that this is not true. The snmpTargetAddrTable defines a
tagList that can be used to limit the outgoing notifications and also
can be used to limit the incoming requests.

<SNIP>
snmpTargetAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTargetAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of transport addresses to be used in the generation
of SNMP messages."
::= { snmpTargetObjects 2 }
</SNIP>

The words "generation" and "target" imply "not incoming".

Post by Joan Landry
snmpCommunityTransportTag OBJECT-TYPE

Ah! So this is not about the snmpTargetAddrTable at all,
really. The question you wanted to ask was, "Does net-snmp support the
community MIBs?" The answer is, "Net-snmp does not support the
community MIBs." If you want to restrict the source address of v1 or
v2c requests, I direct your attention again to the com2sec directive of
the snmpd.conf file. If you want actual security, I direct your
attention again to v3/USM/VACM.


HTH,

Mike

[Glenn McAllister]

Post by Joan Landry

Post by Mike Ayers
Ah! So this is not about the snmpTargetAddrTable at all,

really. The question you >>wanted to ask was, "Does net-snmp support
the community MIBs?" The answer is, "Net-snmp does not support the
community MIBs." If you want to restrict the source address of v1 or
v2c requests, I direct your attention again to the com2sec directive of
the snmpd.conf file. If you want actual security, I direct your
attention again to v3/USM/VACM.
Actually I am really looking to solve one problem.
I want to have a V3 secure box, where v2 access is allowed to only a
select group of stations.

Is there any reason why you can't use the SOURCE field of com2sec? I've
seen setups that need to access the agent for a command line interface,
where the community name is restricted to 'localhost'. It gets us most
of the required information (MIBs we need for these commands are in the
default context) using the insecure v2c community string, but that
string is only accessible via localhost.

If you know the IP addresses or hostnames of the stations, you can set
them up in your snmpd.conf. If you want those stations to use a v3 user
to set it up, and after that they use v2c, I think you are out of luck.

com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
com2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
map an SNMPv1 or SNMPv2c community string to a security name -
either from a particular range of source addresses, or globally
("default"). A restricted source can either be a specific hostname (or
address), or a subnet - represented as IP/MASK (e.g.
10.10.10.0/255.255.255.0), or IP/BITS (e.g. 10.10.10.0/24), or the IPv6
equivalents.
The same community string can be specified in several separate
directives (presumably with different source tokens), and the first
source/community combination that matches the incoming request will be
selected. Various source/community combinations can also map to the same
security name.
If a CONTEXT is specified (using -Cn), the community string will be
mapped to a security name in the named SNMPv3 context. Otherwise the
default context ("") will be used.

[Dave Shield]

Post by Joan Landry
The reason I asked about the snmpCommunityTransportTag is because it
provides the mechanism to solve the above problem by using the
snmpTargetAddressTable as defined in the snmpCommunityTable.

Unfortunately, as Mike has already said, the Net-SNMP agent
does not support the snmpCommunityTable. The "com2sec"
directive (which was implemented before the Community MIB
took shape) provides an equivalent mechanism.

Post by Joan Landry
I want to have a V3 secure box, where v2 access is allowed to only a
select group of stations.
I would use v3/usm/vacm config to define v3 access to the box.
If I add a com2sec configuration for v2 access to the same box - then in
essence I no longer have a v3 secure box. Anyone can get in just using
the v2 setup.

Glenn's given the answer here.
Use directives of the form

com2sec v2user trustedBox community

That will only configure access from the specified source ('trustedBox'),
and be ignored for SNMPv2 requests from elsewhere (even if the
community string is correct).
This is the com2sec equivalent of the snmpCommunityTransportTag
functionality.

Dave

[Joan Landry]

Thanks,
I did not realize you could specify the ip address in the com2sec cmd.
Joan

-----Original Message-----
From: ***@googlemail.com [mailto:***@googlemail.com] On
Behalf Of Dave Shield
Sent: Friday, April 11, 2008 5:35 AM
To: Joan Landry
Cc: net-snmp-***@lists.sourceforge.net
Subject: Re: SnmpTargetAddress

Post by Joan Landry
The reason I asked about the snmpCommunityTransportTag is because it
provides the mechanism to solve the above problem by using the
snmpTargetAddressTable as defined in the snmpCommunityTable.

Unfortunately, as Mike has already said, the Net-SNMP agent
does not support the snmpCommunityTable. The "com2sec"
directive (which was implemented before the Community MIB took shape)
provides an equivalent mechanism.

Post by Joan Landry
I want to have a V3 secure box, where v2 access is allowed to only a
select group of stations.
I would use v3/usm/vacm config to define v3 access to the box.
If I add a com2sec configuration for v2 access to the same box - then
in essence I no longer have a v3 secure box. Anyone can get in just
using the v2 setup.

Glenn's given the answer here.
Use directives of the form

com2sec v2user trustedBox community

That will only configure access from the specified source
('trustedBox'), and be ignored for SNMPv2 requests from elsewhere (even
if the community string is correct).
This is the com2sec equivalent of the snmpCommunityTransportTag
functionality.

Dave