next_inactive up previous


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

1.4.2 Scalability

1.4.3 Generic

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 :

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 :

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

2.3 Remote module/engine Configuration

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

2.3.1 Configuration file format

2.3.2 Config.go file format

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 ?

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

About this document ...

FAQ : IPFC

This document was generated using the LaTeX2HTML 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


next_inactive up previous
2001-12-16