#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\begin_preamble
\usepackage{fancyhdr}
\pagestyle{fancy}
\fancyhead[LE,RO]{\textit{FAQ guide}}
\fancyfoot[LE,RO]{last update by alex@thinkingsecure.com}
%\pagenumbering{roman}
\title{\vspace*{100pt}\Profil\normalsize}
%
% You might want to change this : 
%
\author{Alexandre Dulaunoy}
\end_preamble
\language english
\inputencoding auto
\fontscheme pslatex
\graphics default
\paperfontsize 11
\spacing single 
\papersize Default
\paperpackage a4wide
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation skip
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle plain

\layout Title

FAQ : IPFC
\layout Section

Introduction
\layout Subsection

What is IPFC ?
\layout Standard

IPFC is an 
\begin_inset Quotes eld
\end_inset 

open source
\begin_inset Quotes erd
\end_inset 

 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.
 
\layout Subsection

Which license do you use for IPFC ?
\layout Standard

We release all software and framework designs under the GNU General Public
 License (except the dr-server which is released 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.
 
\layout Subsection

What is the IPFC framework ? 
\layout Standard

IPFC is a multi-tier framework : 
\layout Enumerate

Monitored/Managed infrastructure (wrapper)
\layout Enumerate

Data Repository server (dr-server)
\layout Enumerate

Database backend (db-backend)
\layout Enumerate

Database query tools (front-ends), reporting and alerting
\layout Standard

The communication channels between the different zones are limited to the
 strict minimum.
 This is a requirement for secured and critical environments which was taken
 into account from the very first day.
 The communication between the wrappers, dr-server and db-backend for example
 consists only in SSL/TLS connections that encapsulate XML data.
\layout Standard

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 (
\begin_inset Quotes eld
\end_inset 

in the wild
\begin_inset Quotes erd
\end_inset 

, as it were) there are 
\emph on 
no
\emph default 
 listening ports necessary for the correct functioning of IPFC.
 
\layout Standard

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.
 
\layout Subsection

What are the advantages of IPFC ?
\layout Subsubsection

Security
\layout Itemize

There are no listening ports necessary on the wrapper (TCP or UDP).
\layout Itemize

Stateful protocol.
\layout Itemize

Based on standard TLS/SSL connection (encapsulating HTTP request) -> less
 security configuration issues in a firewalled environment.
\layout Itemize

Nothing is trusted and all parts of the framework are isolated as much as
 possible from the other parts.
\layout Subsubsection

Scalability 
\layout Itemize

All logging/monitoring/managing events are transaction based.
\layout Itemize

The framework can be made fully redundant on each zone independently.
\layout Subsubsection

Technology-neutral
\layout Itemize

The framework is generic (not linked to specific products) - applications
 range from packet filters to washing machine temperature monitoring ;-)
\layout Itemize

The data exchanged between different zones can be anything - as long as
 it can be encapsulated in an XML message.
\layout Subsection

Which operating systems are supported ?
\layout Enumerate

wrapper
\begin_deeper 
\layout Standard

Wrappers are generic applications for pushing/getting to/from the dr-server.
 They run on a wide range of operating systems and products.
 (
\series bold 
from WIN32 to UNIX
\series default 
).
 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 
\series bold 
CISCO IOS, SWITCHES, PABX
\series default 
,...).
 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.
 
\end_deeper 
\layout Enumerate

dr-server
\begin_deeper 
\layout Standard

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

db-backend
\begin_deeper 
\layout Standard

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 
\series bold 
Linux and SecOS
\series default 
, but this can easily be changed.
 
\end_deeper 
\layout Subsection

Why did you choose ipfcontrol (IPFC) as name ? Do you plan to change it
 ?
\layout Standard

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.
 
\layout Standard

So now the name IPFC stands for the complete framework.
 IPFC means a lot things but this could be (depending on the context) Inter
 Protocol Flexible Control.
\layout Subsection

Who is behind the IPFC software and framework ? 
\layout Standard

Alexandre Dulaunoy had the initial wisdom of finding a solution to manage
 the OpenBSD firewall.
 Today, the project is a lot more than that, it is a 
\begin_inset Quotes eld
\end_inset 

full featured Managed Security Services software
\begin_inset Quotes erd
\end_inset 

.
 The two main guys behind the software are Alexandre Dulaunoy (
\emph on 
adulau@foo.be
\emph default 
) and Tycho Fruru (
\emph on 
tycho@fruru.com
\emph default 
).
 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 :-) 
\layout Subsection

History of the design notes 
\layout Standard

2001-06-??: Alexandre Dulaunoy 
\emph on 
(AD) (alex@thinkingsecure.com)
\emph default 
 : Initial wisdom
\layout Standard

2001-06-11: Tycho Fruru 
\emph on 
(TF) (tycho@fruru.com)
\emph default 
 : 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 ;-)
\layout Standard

2001-07-06: AD : Add simple install procedure, update somepoint regarding
 the status and monitor, change licensing issue with dr-server.
\layout Standard

2001-11-01: AD : a lot of changes.
 
\layout Standard

2001-11-01: TF : more changes
\layout Standard

2001-12-16: AD & TF : Getting ready for IPFCv1.0
\layout Section

How does it work ?
\layout Subsection

Data repository
\layout Standard

The core system is working with a data repository acting as a 
\begin_inset Quotes eld
\end_inset 

proxy
\begin_inset Quotes erd
\end_inset 

, a network file server, a buffer server, ...
 (yes, you can name it as you like 8-) The repository acts as 
\begin_inset Quotes eld
\end_inset 

glue
\begin_inset Quotes erd
\end_inset 

 between the multiple security modules (wrappers) and the db-backend (management
/gui client/reporting...)
\layout Standard

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

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


\emph on 
<ID of module/engine>/log
\emph default 
 for logging information
\layout Itemize


\emph on 
<ID of module/engine>/config
\emph default 
 for configuration information
\layout Itemize


\emph on 
<ID of module/engine>/alerts
\emph default 
 for alerting information
\layout Itemize


\emph on 
<ID of module/engine>/monitor
\emph default 
 for monitoring information (add-on on status)
\layout Itemize


\emph on 
<ID of module/engine>/status
\emph default 
 for status information 
\layout Itemize


\emph on 
<ID of module/engine>/events
\emph default 
 for events information 
\layout Standard

The 
\emph on 
<ID of module/engine>
\emph default 
 is arbitrary.
\layout Standard

The
\emph on 
 <IP of module/engine>
\emph default 
 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.
 
\layout Subsection

Remote module/engine Logging
\layout Standard

In the 
\emph on 
.../log
\emph default 
 directory, the following files can be found :
\layout Itemize


\emph on 
<ID of log>.log
\emph default 
 : the actual log entries in XML format, as defined below (***but not yet!)
\layout Itemize


\emph on 
<ID of log>.ok 
\emph default 
: if this file is present, the complete log 
\emph on 
<ID of log>
\emph default 
 has been transmitted, and the log 
\emph on 
<ID of log> 
\emph default 
can be recuperated by a management module for further processing.
\layout Standard

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

Logging file format
\layout Itemize

Logging version
\layout Itemize

ID of the module/engine
\layout Itemize

Begin and End dates (YYYYMMDD-HHMMSS.cc or so) of this log segment (enables
 us to check whether we have all logs ;-)
\layout Itemize

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* !))
\layout Subsection

Remote module/engine Configuration
\layout Standard

In the 
\emph on 
.../config
\emph default 
 directory the following files can be found :
\layout Itemize


\emph on 
<ID of config>.config
\layout Itemize


\emph on 
config.go
\layout Subsubsection

Configuration file format
\layout Itemize

Config file version
\layout Itemize

ID of the module/engine
\layout Itemize

ID of the requestor of the config update (eg.
 which admin asked for the update ?)
\layout Itemize

Configuration info (to be defined per module/engine)
\layout Subsubsection

Config.go file format
\layout Itemize

Config.go file version
\layout Itemize

ID of the module/engine
\layout Itemize

Currently active 
\emph on 
<ID of config>.config
\emph default 
 file (name) (permits the module to get new config if name changes)
\layout Itemize

Last modification time of the 
\emph on 
config.go
\emph default 
 file (permits the module to check whether it has missed an update)
\layout Itemize

Refresh frequency of the 
\emph on 
config.go
\emph default 
 file (how often the module checks on the config.go file, in seconds.)
\layout Subsection

Remote module/engine Alerting
\layout Standard

Not yet here.
\layout Subsection

Remote module/engine Monitoring
\layout Standard

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.
\layout Standard

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

Installation
\layout Subsection

Software prerequisite 
\layout Subsection

Which module of apache do you use ? 
\layout Itemize

MOD_PUT
\layout Itemize

MOD_UNIQUE_ID
\layout Itemize

MOD_EACCESS
\layout Itemize

MOD_ACCESS
\layout Itemize

MOD_GZIP
\layout Section

Configuration
\layout Subsection

Simple installation and compilation of the dr-server
\layout LyX-Code

\layout Subsubsection

configuration of the dr-server
\layout LyX-Code

\layout Subsection

Simple installation and compilation of the db-backend
\layout Subsubsection

configuration of the db-backend
\layout Subsection

Simple installation of wrapper
\layout Subsubsection

configuration of the wrapper
\layout Section

Extending ipfcontrol
\layout Subsection

Writting additional client wrapper
\layout Section

Useful example 
\layout Standard

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

Managing multiple NIDS Snort
\layout Subsection

Managing a packet filtering 
\layout Subsection

Collecting logs
\layout Subsection

Fetching information from data repository to SQL
\layout Subsection

Fetching information from data repository to a monitoring console
\layout Subsection

How to write a 2 line pushing policy/config ? 
\layout LyX-Code

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

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

Authors
\layout Standard


\begin_inset LatexCommand \tableofcontents{}

\end_inset 


\the_end
