Glassfish SNMP security
By Olivier Rivat on Feb 09, 2009
SNMP security for Glassfish
This glassfish SNMP release supports SNMP V1 and V2 only. Snmp Security is quite weak within SNMP V1 and V2, as only some limited security can be put in place through community string.
A much more complete SNMP security solution will be available when Glassfish SNMP V3 support will be provided.
Using Community String for Security
Hereafter is described how to configure the SNMP master agent with community string for security. Community string are supported in SNMP V1 and V2. With this approach, a minimal SNMP security support can be provided through SNMP master agent configuration.
The main idea consists of configuring SNMP security at SNMP master agent level. The SNMP master agent is using a configuration file. It is within this configuration file, that the user we will configure the SNMP community string. SNMP master agent configuration is operating system specific, and is described in the previous section. Instructions are provided for Solaris. For other platforms, the user should refer to the man page of snmp master agent of your operating system.
Before doing this, the user should configure the SNMP master agent to talk to glassfish SNMP agent (described in the previous section). It is also advised changing the GlassfishSnmp port adapter to something different from the default value 10161. The SNMP master Agent can be running on a different host, than the host on which Glassfish is running. All SNMP user's request should go to the SNMP master agent.
Using community string on Solaris 10
The user needs to create a community string within the file snmpd.conf. It is possible to add the host or subnet from which this community can be accessed. The user should refer to the man page of snmpd.conf\* for complete information.
rocommunity community [source] [OID]
Create read-only communities that can be used to access the agent. They are a quick wrapper around the more complex and powerful com2sec, group, access, and view directive lines. They are not as efficient as these, because groups are not created, so the tables are potentially larger. These directives are not recommended for complex environments. If your environment is relatively simple or you can sustain a small negative performance impact, use these directives.
Source can be a hostname, a subnet, or the word default. A subnet can be specified as IP/mask or IP/bits. The first source/community combination that matches the incoming packet is selected.
The OID token restricts access for that community to everything below that given OID.
# access granted using community string mfwk
proxy -v1 -c public <ipaddress of glassfish installation>:10161 126.96.36.199.188.8.131.52.99184.108.40.206.1 Once the System Administrator has modified the snmpd.conf file, he has to restart the snmpd daemon:
User will have to indicate a community string when connecting to the SNMP master agent. Any other request not specifying the correct community string will be rejected.
- snmpwalk -c mfwk -v 1 <hostname> J2EE-MIB::j2eeSrvMoName
---> J2EE-MIB::j2eeSrvMoName.1.1 = STRING: "name=server"
# access granted using community string mfwk on the subnet 10.10.10.255
rocommunity mfwk 10.10.10.0/24
proxy -v1 -c public <ipaddress of glassfish installation>:10161 220.127.116.11.18.104.22.168.9922.214.171.124.1
snmpwalk -c mfwk -v 1 <hostname> J2EE-MIB::j2eeSrvMoName J2EE-MIB::j2eeSrvMoName.1.1 = STRING: "name=server"
In example2, snmpwalk user request will succeed only if the user's machine belongs to the specified subnet (i.e 10.10.10.25)