$FILE
Keywords: faq

# FAQ : IPFC

Alexandre Dulaunoy

# 1 Introduction

## 1.1 What is IPFC ?

IPFC is an ``open source'' software and framework to manage and monitor multiple types of security modules across a global network. Security modules can be as diverse as packet filters (like netfilter, pf, ipfw, IP Filter, checkpoint FW1), NIDS (Snort, arpwatch...), webservers and other general devices (from servers to embedded devices). If you like marketing terms : It's a complete Managed Security Services (MSS) software infrastructure.

## 1.2 Which license do you use for ipfcontrol ?

We release all software and framework designs under the GNU General Public License (except the dr-server which is under Apache license because it's based on Apache). We strongly believe that software must be free to everyone. We want to share ideas, concepts and software with a lot of people around the world. Source availability is really important for software related to security management due to the possibility of auditing the source code. Another important issue is that opening up the source improves extensibility of the code itself.

## 1.3 What is the IPFC framework ?

IPFC is a multi-tier framework :

1. Monitored/Managed infrastructure (wrapper)
2. Data Repository server (dr-server)
3. Database backend (db-backend)
4. Database query tools / reporting / alerting

The communication channels between the different zones are limited to the strict minimum. This is a requirement for secured and critical environments. The communication between the wrappers, dr-server and db-backend for example consists only in SSL/TLS connections that encapsulate XML data.

Wrappers are small applications (or some collector devices) that connect to the Data Repository server on a regular basis. The wrappers are only initiating connections to the dr-server, which means that on the managed devices (``in the wild'', as it were) there are no listening ports necessary for the correct functioning of IPFC.

The Data Repository is acting like a proxy between the wrapper zone and the db-backend zone. The data repository contains a special file system hierarchy accessible via HTTPS connections from wrapper and from the db-backend.

## 1.4 What are the advantages of IPFC ?

### 1.4.1 Security

- There are no listening ports necessary on the wrapper (TCP or UDP).
- Stateful protocol.
- Based on standard TLS/SSL connection (encapsulating HTTP request) -> less security configuration issues in a firewalled environment.
- Nothing is trusted and all parts of the framework are isolated as much as possible from the other parts.

### 1.4.2 Scalability

- All logging/monitoring/managing events are transaction based.
- The framework can be made fully redundant on each zone independently.

### 1.4.3 Generic

- The framework is generic (not linked to specific products) - applications range from packet filters to washing machine temperature monitoring ;-)
- The data exchanged between different zones can be anything - as long as it can be encapsulated in an XML message.

## 1.5 Which operating systems are supported ?

1. wrapper

   Wrappers are generic applications for pushing/getting to/from the dr-server. They run on a wide range of operating systems and products. (from WIN32 to UNIX). Most notably, different flavors of Unix (*BSD, Solaris, Linux, AIX) and WIN32 are supported. Check out the different wrappers available in the IPFC distribution. There are also special wrappers for software or operating systems where it's not possible to directly install a wrapper (like CISCO IOS, SWITCHES, PABX,...). These wrappers use a serial line or a remote connection (from telnet/ssh session to SNMP request) to connect to these devices and convert their data to the XML based format used by IPFC.

2. dr-server

   The Dr-server is a modified Apache server. These run on Linux, FreeBSD, SecOS and Solaris. High-availability (via VRRP) is only supported on Linux and SecOS. But this could be easily ported to other operating systems.

3. db-backend

   The Db-backend is a general backend for the whole infrastructure. The Db-backend makes is possible to run reporting and alarming. It's currently running on Linux and SecOS, but this can easily be changed.

## 1.6 Why did you choose ipfcontrol (IPFC) as name ? Do you plan to change it ?

In the beginning of the project, the name was chosen because our first target was to remotely manage IP Filter (a packet filter software) for *BSD. Now, the project is more generic and more flexible so we can easily manage multiple types of security modules (like Snort, NIDS, ipfw, netfilter, checkpoint FW1,...). IP Filter (ipf) has now moved to a more restrictive license and we think is not a good thing to base our name on it because our project is 100% GNU GPL.

So now the name IPFC stands for the complete framework. IPFC means a lot things but this could be : Inter Protocol Flexible Control....

## 1.7 Who is behind the IPFC software and framework ?

The initial wisdom was done by Alexandre Dulaunoy for finding a solution to manage OpenBSD firewall. Now the project is more than that, it is a ``full featured Managed Security Services software''. The two main guys behind the software are Alexandre Dulaunoy (adulau@foo.be) and Tycho Fruru (tycho@fruru.com). They have also founded a company which implements the IPFC framework for MSS/MSM. The company is Luxembourg-based and it's called Conostix. (http://www.conostix.com/). Now there are a number of contributors around the world, check CREDITS for more information. Don't hesitate to be part of the IPFC project. It's both technical and fun...

## 1.8 History of the design notes

2001-06-??: Alexandre Dulaunoy (alex@thinkingsecure.com) : Initial wisdom

2001-06-11: Tycho Fruru (fpmip@perycles.unix.be.eu.org) : Misc changes, added 2.2, 2.3, 2.4, 2.5, elaboration, it's too early to make a formal history of the design notes ;-)

2001-07-06: Alexandre Dulaunoy (alex@thinkingsecure.com) : Add simple install procedure, update somepoint regarding the status and monitor, change licensing issue with dr-server.

2001-11-01: Alexandre Dulaunoy (alex@thinkingsecure.com) : a lot of changes.

2001-11-01: Tycho Fruru (tycho@fruru.com) : more changes

# 2 How does it work ?

## 2.1 Data repository

The core system is working with a data repository acting as a ``proxy'', a network file server, a buffer server, ... (yes, you can name it as you like 8-) The repository acts as ``glue'' between the multiple security modules (wrappers) and the db-backend (management/gui client/reporting...)

The data (logs/config/alerts/monitoring) are stored in a filesystem hierarchy, which is made accessible through the dr-server.

Every module/engine has its own set of directories, organised as follows :

- <ID of module/engine>/log for logging information
- <ID of module/engine>/config for configuration information
- <ID of module/engine>/alerts for alerting information
- <ID of module/engine>/monitor for monitoring information (add-on on status)
- <ID of module/engine>/status for status information
- <ID of module/engine>/events for events information

The <ID of module/engine> is arbitrary.

The <IP of module/engine> could be preceeded by a group ID so that means the dr-server could be use by different user or network infrastructure - arbitrary authentication groups can be made this way.

## 2.2 Remote module/engine Logging

In the .../log directory, the following files can be found :

- <ID of log>.log : the actual log entries in XML format, as defined below (***but not yet!)
- <ID of log>.ok : if this file is present, the complete log <ID of log> has been transmitted, and the log <ID of log> can be recuperated by a management module for further processing.

The <ID of log> name is arbitrary, but it is recommended to take something of the form YYYYMMDD-HHMMSS.cc or another unique identifier. The description of ID generation and his use is described in the protocol document.

### 2.2.1 Logging file format

- Logging version
- ID of the module/engine
- Begin and End dates (YYYYMMDD-HHMMSS.cc or so) of this log segment (enables us to check whether we have all logs ;-)
- Log entries (to be defined per module/engine what and how (I'd like to be able to do ACID stuff with the logs, so we need *A LOT* !))

## 2.3 Remote module/engine Configuration

In the .../config directory the following files can be found :

- <ID of config>.config
- config.go

### 2.3.1 Configuration file format

- Config file version
- ID of the module/engine
- ID of the requestor of the config update (eg. which admin asked for the update ?)
- Configuration info (to be defined per module/engine)

### 2.3.2 Config.go file format

- Config.go file version
- ID of the module/engine
- Currently active <ID of config>.config file (name) (permits the module to get new config if name changes)
- Last modification time of the config.go file (permits the module to check whether it has missed an update)
- Refresh frequency of the config.go file (how often the module checks on the config.go file, in seconds.)

## 2.4 Remote module/engine Alerting

Not yet here.

## 2.5 Remote module/engine Monitoring

Monitoring consists in pushing a file with status information regularly from the module to the webserver. The contents of this file are different monitoring parameters which might be of interest (eg. free memory, how many users are logged on, average cpu usage, network error packets etc). The file also includes the current time of the module and when the next update is due.

For a complete description of the monitoring, check the document talking about the monitoring wrapper in the wrapper directory.

# 3 Installation

## 3.1 Software prerequisite

## 3.2 Which module of apache do you use ?

- MOD_PUT
- MOD_UNIQUE_ID
- MOD_EACCESS
- MOD_ACCESS
- MOD_GZIP

# 4 Configuration

## 4.1 Simple installation and compilation of the dr-server

### 4.1.1 configuration of the dr-server

## 4.2 Simple installation and compilation of the db-backend

### 4.2.1 configuration of the db-backend

## 4.3 Simple installation of wrapper

### 4.3.1 configuration of the wrapper

# 5 Extending ipfcontrol

## 5.1 Writting additional client wrapper

# 6 Useful example

or real life is better than anything else 8-)...

## 6.1 Managing multiple NIDS Snort

## 6.2 Managing a packet filtering

## 6.3 Collecting logs

## 6.4 Fetching information from data repository to SQL

## 6.5 Fetching information from data repository to a monitoring console

## 6.6 How to write a 2 line pushing policy/config ?

  lwp-request -m PUT http://127.0.0.1/ipfc/smod/sparky/config/p-2.policy <policy-file

  lwp-request -m PUT http://127.0.0.1/ipfc/smod/sparky/conf/p-2.policy.go <1-byte-file

## 6.7 Authors

## Contents

- 1 Introduction
  - 1.1 What is IPFC ?
  - 1.2 Which license do you use for ipfcontrol ?
  - 1.3 What is the IPFC framework ?
  - 1.4 What are the advantages of IPFC ?
  - 1.5 Which operating systems are supported ?
  - 1.6 Why did you choose ipfcontrol (IPFC) as name ? Do you plan to change it ?
  - 1.7 Who is behind the IPFC software and framework ?
  - 1.8 History of the design notes
- 2 How does it work ?
  - 2.1 Data repository
  - 2.2 Remote module/engine Logging
  - 2.3 Remote module/engine Configuration
  - 2.4 Remote module/engine Alerting
  - 2.5 Remote module/engine Monitoring
- 3 Installation
  - 3.1 Software prerequisite
  - 3.2 Which module of apache do you use ?
- 4 Configuration
  - 4.1 Simple installation and compilation of the dr-server
  - 4.2 Simple installation and compilation of the db-backend
  - 4.3 Simple installation of wrapper
- 5 Extending ipfcontrol
  - 5.1 Writting additional client wrapper
- 6 Useful example
  - 6.1 Managing multiple NIDS Snort
  - 6.2 Managing a packet filtering
  - 6.3 Collecting logs
  - 6.4 Fetching information from data repository to SQL
  - 6.5 Fetching information from data repository to a monitoring console
  - 6.6 How to write a 2 line pushing policy/config ?
  - 6.7 Authors
- About this document ...

# About this document ...

FAQ : IPFC

This document was generated using the LaTeX2`HTML` translator Version 2K.1beta (1.47)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html `-no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir98376YxoNe/lyx_tmpbuf9837Om1Mzx/faq.tex`

The translation was initiated by on 2001-12-16