cs6255::prj

1
cs6255prj

• Adding SNMP/RMON
• Capabilities to WebWork
• A Work In Progress
• David Dagon
• dagon_at_cc.gatech.edu

2
Who Is This Man?
3
Our Own NOC
4
WebWork
5
The So-Called Customers

• 1,500 students in cs1
• 1,000 students in cs2
• A few hundred more in misc. courses
• Each day, about 22,000 secure pages served.
• During due dates, servers are pegged at 100
  capacity for 7 hours.

6
Current Configuration
Commodity x86 machines running FreeBSD
4.4-STABLE, OpenBSD 2.9, and Linux (for
non-critical work) 10 machines served by single
firewall web servers, mysql servers, back up
agents, etc.
7
Configuration
firewall
8
Configuration
An OpenBSD box performs session logging, snort
IDS, and other services.
Hint To keep your logger secure, use a sniffer
cable an ethernet cable hacked up to allow
receive only, and no send.
9
Sniffer Cable Hints
Works only with cheap hubs. For a switch, add a
15p(F) capacitor feedback to indicate on.
10
Traffic Patterns
A few trends are noted During peak use, some
clients twiddle with useless features. Others
repeatedly hit view grades to get advanced
notice of auto-graded results.
Each one of these reloads requires a database
query, a logging event, etc.--all encrypted.
11
Thus...
Because of the tremendous load on the system, a
general strategy is needed to curtail certain
features during peak times. That is, disable
features when theres limited capacity.
But first, we need to detect when loads become
critical. Monitoring will permit this sort of
dynamic adjustment.
12
Problems
The traffic with the server is all encrypted on
the client side (https).
So, how can the agents provide level 4
monitoring if the data is always encrypted?
13
Solution 1
Have the server share keys with the logger.
Drawbacks 1. Requires rewriting SSL/TSL
server (complex due to Netscape/ Microsoft war.)
2. Overhead logger must manage keys for all
servers. 3. Common sense servers already
decrypted traffic why duplicate this effort?
14
Solution 2
Have each server perform logging. Drawbacks
1. No coordination of logging efforts. 2.
Overhead of logging reduces server capacity.
15
Solution 3
Use SNMP! Theres plenty of C/Perl libraries
out there. Drawbacks 1. Yea, right.
2. Get real.
16
Reality Check
So far, weve studied the management of
objects the model was simple.
Those little lines connecting the manager to the
object represent thousands of lines of code. The
MIBs may be small enough, but writing the code to
deliver on queries is real work.
17
Solution 4
Scrap the old perl code rewrite the servers from
the ground up using appropriate APIs to support
RMON/SNMP management.
18
JDMK (v4.2)

• Suns toolkit implements the JMX specification.
• Works with standards Java APIs.

19
Architecture of JDMK
The JDMK uses Managed Beans or Mbeans to
represent objects. MBeans expose behaviors
through interfaces.
MBean
Three types
Standard Mbeans, follow JMX specified design
pattern Dynamic Mbeans, wrapper for
non-standard features (e.g, JNI) Model
MBeans, an extension of dynamic MBeans
20
Architecture of JDMK
The MBean Server works as a registry for managed
objects. The server can be local or remote
(connected).
MBean Sever
MBean
21
Architecture of JDMK
The connection between bean and server is through
a connector service. The JMX specification
allows for SNMP and HTTP/HTTPS connections.
MBean Sever
MBean
The connector has two pieces 1) A connector
server interacting with the MBean 2) A connector
client exposing management interfaces
22
Architecture of JDMK
The connection between bean and server is through
a connector service. The JMX specification
allows for SNMP and HTTP/HTTPS connections.
MBean Sever
MBean
Connectors also have a heatbeat mechanism
(required by JMX) to determine if
services/facilities are still alive.
23
Architecture of JDMK
MBeans use a notification model to broadcast
events and updates (async).
L2
L1
MBean Sever
MBean
Listeners can be added with addNotificationListen
er calls. This is similar to the event
delegation model used since JDK 1.1
24
Example
public interface TestMBeanType public String
getState() public void setState(String s)
public Integer getNbChanges() public
void reset()
The MBean begins with an interface type. This
specification exposes a read/write variable (its
state), and also a read only variable for the
number of changes.
25
Example
public class TestMBean implements TestMBeanType
private String state "initial state"
private int nbChanges 0 private int
nbResets 0 public TestMBean()
// required by JMX spec public String
getState() return state
public void setState(String s) state
s nbChanges public Integer
getNbChanges() return new
Integer(nbChanges) public void reset()
state "initial state"
nbChanges 0 nbResets //
not managed public Integer getNbResets()
return new Integer(nbResets)
The default constructor is required by the JMX
spec. (Its ok to use the default for
java.lang.Object.) The rest is a simple
implementation of the interface
26
Example
With these, were ready to create a
server MBeanServer server
MBeanServerFactory.createMBeanServer() The
MBeanServer instance is available only through a
factory pattern.
27
Example
Next, we create an ObjectName. This will be used
to register the MBean with the MBeanServer Obje
ctName mbeanObjectName null String domain
server.getDefaultDomain() String mbeanName
"SimpleStandard" try mbeanObjectName
new ObjectName(domain "type"
mbeanName) catch(MalformedObjectNameException
e) // Fatal error
28
Example
Next, we create an MBean with the server. try
server.createMBean(mbeanClassName,mbeanObjec
tName) catch(Exception e) //
fatal error handling
Note that you never have a direct reference to an
MBean instead, you have references through a
server. This step registers the MBean with the
server.
29
Example
Next, we can manage the MBean through the
server try server.invoke(mbeanObjectNam
e,"reset",null,null) catch (Exception e)
// fatal error handling
Again, note that we do not have a direct pointer
to the MBean we have a reference through an
MBeanServer (which might be remote).
30
Example
ltlt demonstration, assuming theres network
connectivity gtgt
31
Conclusion
A few reflections on SNMP 1) Use an API. Do
NOT attempt a low-level implementation (unless
youre doing hardware, or yet another SNMP
API). 2) Consider the effort needed to support
the client queries.
32
Conclusion
Self quiz 1) How does the JDMK model managed
objects? a) MTrain b) MMs c)
Hmmmm... d) MBeans
33
Conclusion
Self quiz 2) What are the two types of
connectivity supported by MBeans?
34
Conclusion
Self quiz 2) What are the two types of
connectivity supported by MBeans?
SNMP, and Web (HTTP/HTTPS)
35
Conclusion
Self quiz 3) If network traffic is encrypted,
how does this affect RMON capabilities?
36
Conclusion
Self quiz 3) If network traffic is encrypted,
how does this affect RMON capabilities?
High level monitoring (say, above level 2)
requires the ability to view the encrypted data.
Problems a) key transfer b) shared
logging c) overhead