IRON - Project Structure and Current Status

IRON (Intelligent Reaction on Network Events) is a research project that is carried out by students of the Fachhochschule Hannover within their 5th and 6th bachelor studies term. The overall goal is to implement prototype security solutions for modern networks that are based upon the TCG’s IF-MAP specification. IRON is subdivided in seven subprojects. Each of them focuses on a specific building block of the entire project.

Each of the green boxes represents one specific subproject. The two central ones focus on the development of the MAP Server, whereas the five surrounding subprojects aim to extend existing security solutions with MAP Client functionalities.

MAP Server Connection Management

Scope

Generally the subproject Connection Management realizes the interface of the IRON MAP Server according to the IF-MAP specification of the TCG. The key functionality includes to accept and manage connections from arbitrary IF-MAP clients. All IF-MAp functions for publishing, searching and subscribing for metadata will be supported. According to incoming client requests, publisher-ids are derived and valid SOAP requests are transformed in Java objects. These objects are forwarded to the datamodel interface (see corresponding sub project description). If necessary, data retrieved from the datamodel interface is transformed from Java objects to valid SOAP responses and send back to the requesting clients. Thus, the Connection Management component acts as a translator between the SOAP and the Java world.

Architecture

The Connection Management subproject is based on the servlet-container Apache Tomcat with an Apache Axis2 engine. The server is able to accept TCP with TLS and HTTPS connections and is divided in two subprojects: the non-persistent Datamodel and the Connection Management. The MAP-Server will only accept secure connections. Hence, the server has to implement the credential base authentification and the basic authentification accross a SSL connection. An IF-MAP client MUST establish one connection for the synchronous communication named SSRC and can establish one for the asynchronous communication named ARC. The asynchronous communication is only needed for poll requests and responses. With a poll request the client is ready to receive metadata according to existing subscriptions from the MAP Server. Which metadate is received depends on the corresponding subscribtions. All other requests and responses use the synchronous communication channel. Over the established connections, the MAP Server is able to receive synchronous and asynchronous requests from the MAP Clients.

Current Status and Future Work

Apache Tomcat and Apache Axis2 are installed. It is possible to send a newSession request to the MAP Server. The server gets the client credential out of the request and response with a publisher-id which is associated to the credential. Other request types must be implemented and java objects created from the SOAP messages must forwarded to the datamodel.

MAP Server Datamodel

Scope

The scope of the subproject Datamodel is to develop the components of the IRON MAP Server implementation which are responsible to store and look-up published metadata. Additionally active subscriptions are managed in this part of the MAP Server. The main task is to implement the logic of the Publish, Search, Subscribe and Poll functions according to the IF-MAP specification. The implementation will be done using the programming language Java.

Architecture

To be mostly decoupled from SOAP message and XML processing, which is done by the subproject Connection Management, we offer a defined interface based upon plain Java objects. This way the SOAP messages have to be transformed into Java objects before calling the operations. For example, there is a Class PublishRequest which encapsulates all information which are contained in a SOAP PublishRequestType.

Furthermore, identifiers and links will be transformed into Java objects. Identifiers and links have bidirectional relationships to each other. This way every identifier “knows about” its links and vice versa. This design is benefitial when processing SearchRequests. One can traverse the aroused graph by simply asking about an identifiers or links partners. Both, links and identifier can carry metadata. In respect to operations with metadata they are treated the same way.

What is not converted into Java Objects, however encapsulated in one, are the metadata information. The reason for this is, that we want to use current XPath implementations to match metadata against a specific filter. As those libraries require XML data as input we will store small XML documents in the graph. Using appropriate interfaces to work with the Metadata Class, it should be easy to change the implementation, shouldn’t it work out as expected. While the server is running, a graph consisting of identifiers and links is built up in the memory. Identifiers can be seen as nodes in the graph with links between them. Nodes and links have metadata objects attached to them.

Current Status and Future Work

The implementation is planned to be done in two iterations. After the first part of the project we want to be able to process “local” test cases for Publish, Search and PurgePublish operations. This requires some fundamental work to be done. For example, we need a working data structure. Additionally to implement the search function we need to be able to match metadata against a given filter. In the second iteration the main task is to design and implement the subscribe/poll functionality.

ISC DHCP

Scope

The purpose of the subproject ISC DHCP is to collect Leases-Information from a given ISC DHCP Server and publish them as metadata to the IRON MAP Server. This metadata includes MAC/IP-Relationships and the date when the lease starts and expires. The goal is that the MAP Server knows which IPs are assigned to which specific MAC Addresses.

Architecture

The mapdhcp is a standalone solution written in Java. The dhcpd-daemon is not modified. The information is derived directly from the configuration files (dhcpd.leases and dhcpd.conf). The application is divided into three components: parser, translator and SOAP-messenger. The parser reads the contents in regular intervalls and does a lexical analysis. The result is passed to the translator, which will convert it to internal data structures. When changes are recognized the data is handed over to the SOAP-messenger. Afterwards the messenger creates a SOAP message and sends it to the MAP Server. The parser component is realized with JAVACC, a parser generator for java. Axis, a free SOAP library, is used for the soap processing and the secure communication with the MAP Server.

Current Status and Future Work

The development is in an early stage. A first prototype is estimated for January 2010. The first milestone only implements features to publish the metadata to a MAP Server. The metadata includes IP, MAC-Address and Lease times. For future releases we expect more metadata to be published (e.g. associated domains and routers). It could be possible not only to publish information, but also to search on the MAP-Sever for required data. It is conceivable that a dhcp-server only lease IPs, when a MAP-Server allows it for a specific MAC-Address.

Snort

Scope

The scope of the Snort subproject is to observe the network traffic and publish potentially suspicious and dangerous network activities to the Map Server. For this reason we use and extend the IDS Snort in such a way that it is acting as MAP Client according to the IF-MAP specification. The additional MAP functionality is realized by a stand alone java application. This application will be used as bridge between Snort and MAP-Server. The application supports to send alerts to the MAP-Server based upon malicious traffic that was observed by Snort. The IDS acts only as a publisher. It does not receive any metadata from the MAP Server.

Architecture

The architecture consists of the IDS Snort and a stand alone java application that is developed from scratch. The IDS monitors the network and saves for each event an alert message locally in the “alert” file. The java application checks the alert file in regular intervals. If changes are noticed, new alert messages will be parsed. Finally the parsed information will be encapsulated into SOAP-Messages and published via an encrypted connection to the MAP Server. All communication takes place via the SSRC.

Current Status and Future Work

At the moment the subproject is in an early implementation phase. The first prototype will be finished in January 2010. A basic installation of latest Snort version (2.8.5.1) is configured and running in a test environment. The development of the Java application is in progress. The parser is implemented completely and tested. The communication (SOAP) part is not implemented yet. The first milestone only implements features to publish the metadata to a MAP Server. The metadata includes all information which Snort provides. For future releases it could be possible to analyse the alerts, and only publish the really critical ones. This must be configurable by the user.

Nagios

Scope

The Subproject NAGIOS will extend the network monitoring tool NAGIOS with MAP Client functionality. The primary scope is to visualize the structure of the network and provide status information about the hosts on the network. To visualize the network structure the Nagios MAP Client obtains the parent and child information of an host from IF-MAP Server and writes them into the NAGIOS configuration. The status information about a host will be gained via NAGIOS, processed by the NagiosIFMapConnector and handed over to the MAP Server. Optionally, the Connector changes information about the host in the MAP depending on the gathered host status.

Architecture

This subproject will build a network deamon which communicates the host status information from NAGIOS to the MAP Server and the network structure data from the MAP Server to NAGIOS. As programming language Java will be used. This way, given AXIS libraries can be used to communicate with the MAP Server. The network information will be directly written into the NAGIOS configuration files. There is no need to change the NAGIOS code itself. In order to obtain the host status information from NAGIOS, an addon will be written which hands the information via JAVA RMI to the NagiosIFMapConnector daemon, which then can forward it to the MAP Server. Primarily the connector requests the IP address, the host name and the host device for each connected endpoint from the MAP Server. By using this data, it can add a new host entry to the NAGIOS configuration file.

Current Status and Future Work

The final version of the connector will collect any metadata about the hosts on the MAP-Server and forward it to NAGIOS. In addition, the host reachability will be obtained from NAGIOS and forwarded to the MAP Server. The communication of obtional metadata about the host, e.g. the OS running on the host or the Anti-Virus programm and date of the virus signatures, is a subject of future work.

tnc@fhh

Scope

The scope of the tnc@fhh subproject is to extend the existing tnc@fhh PDP with MAP client functionality. It is expected that the PDP publishes new metadata to the MAP that is obtained during the TNC handshake. Furthermore, it is planned to add subscriber functionalty to the PDP by adding specific IMVs that are responsible for retrieving (and processing) metadata from the MAP Server. The general approac to add basic MAP client functionality is to develop new FreeRADIUS modules for the PDP. The published metadata may be useful for other MAP Clients (e.g. Nagios - to complete the big picture of the Network).

Architecture

There are two major building blocks within this subproject. The first one is the enhancement of the tnc@fhh’s PDP. In addition to the currently implemented functions, AR specific data (like MAC-Address, RADIUS Username, Integrity Measurements, derived TNC Recommendation, PEP-Information (IP and Port) will be collected by a new FreeRADIUS post-auth module and published to the MAP Server. The second building block is a shared library (map communication module), which offers functions to communicate with the MAP Server via SOAP. This is implemented by using gSOAP (a library for soap communication), that makes IF-MAP functions (publish, search, poll, …) available for C/C++ programs.

Current Status and Future Work

Currently there is an implementation of the libary which can communicate (only newSession Request) with the MAP without SSL and authentication. The next step is to secure the communication and to actually publish the collected metadata.

iptables

Scope

The main task of this subproject is to develop an IF-MAP extension for the iptables firewall. This extension will analyze log messages created by iptables and, if necessary, publish new metadata to the MAP server. Furthermore, the extension will be able to receive metadata from the MAP server and create, change or delete firewall rules accordingly. For the first prototype, simple publish requests to the MAP Server when the firewall drops packets will be realized. Furthermore, the iptables extension will subscribe for metadata that was pubslihed by other tools like Snort (in order to mitigate an ongoing malicious flow).

Architecture

The basic architecture consists of the iptables firewall and a new Java application that is developed from scratch. ULOG, an extension for iptables, is used to create the log files that will be processed by the Java application. This Java application checks the firewall log files in regular intervalls. If changes are noticed, the log messages are analyzed. Based on the results of this analysis requests to the MAP Server can be issued. For the communication with the MAP Server, both the SSRC and the ARC are used. The processing of SOAP is done by using Axis.

Current Status and Future Work

At the moment the subproject is still in an early implementation phase. The first prototype is finished. The parsing of the log file is completely implemented and tested. The communication with the MAP Server is not finished yet. Currently, it is just supported to create a new connection, obtain a valid session id and to issue simple publish requests (containing metadata about packets dropped by iptables). Future work includes especially to receive metadata from the MAP Server, process this metadata and adjust the iptables rules accordingly.