Before
After
Bernard Bou <bbou@ac-toulouse.fr>
MutFi stands for mutable firewall and implements the concept of a firewall that mutates in time, depending on the settings that some authorized users may modify to suit their needs.
|
project |
download |
web |
|---|---|---|
|
http://sourceforge.net/project/showfiles.php?group_id=172773 |
CONCEPT
A firewall is used to control access to a server host's services : the firewall accepts or drops the inbound packets. While doing so, it bases its decisions on the following parameters:
-time of day (and day)
-source of the requesting host (IP address)
-optionally protocol (TCP,UDP,ICMP) and port number matching a requested service (http, smtp, ...)
It was built bearing in mind the needs of a school or university where access to a server (typically a proxy server) may be allowed or disallowed depending on the time of day and the day of week and the set of hosts the requests come from (various classrooms or departments). This overall scheme has been extended to encompass (or provision for) more versatile uses.
|
Before |
After |
|
|
|
This illustrates a server before and after setting up MutFi.
The Netfilter firewall works with chains that IP packets traverse on their way to their destination. Chains consist of a number of rules that apply if a given condition is satisfied. Basically, if the rule's condition is satisfied by the packet, then the rule's target determine the packet's fate: it can either be ACCEPTed or DROPped or even transferred to another chain for further processing.
The rules are set up by the administrator and are meant to apply to a specific IP range (which may boil down to just one host) but some authorized users may determine whether the rule applies or not at given time slots, for the set of hosts they are responsible for.
Technically MutFi awakes at given intervals and checks if it has to perform some changes to the firewall settings. If so, it flushes the administrator-defined chains and rebuilds them with the data that currently apply.
Time slices are defined to be one hour but a time offset can be set so that changes are triggered at a number of minutes past the hour.
IP ranges (which are more versatile than IP subnets in that they don't have the same constraints of power-of-2 boundaries and extents) define ranges of hosts that requests may come from. An added advantage is that you may restrict rules to actually-allocated addresses, not subnets with unallocated stretches.
The rules are stored in a MySQL database, which also stores the users' data for authentication purposes and access control lists for authorization purposes.
A web interface is provided for easy-to-use management or rules, users, time slots...
As a case study, let's examine the following scheme. In a school, we wish to restrict access to a proxy web server. Every packet that reaches the server enters the Netfilter-defined INPUT chain where, after some sanity checks, it is transferred to the any-me chain (meaning from any source to me) that Mutfi defines. A rule may be set up by the administrator to the effect that the firewall will turn down connections to the proxy services from hosts in the electronics department. The parameters we need to specify are
-the rule belongs to the any-me chain (chain=any-me)
-the rule consists in dropping the packets (target=DROP)
-the rule applies to TCP packets (protocol=tcp)
-the rule applies to packets having port 8080, the proxy's port (port=8080)
-the rules applies to packets from hosts in the 10.3.20.0-10.3.79.255 range, matching the addresses allotted to the electronics department (range-from 10.3.20.0, range-to=10.3.79.255). At this point you may note that if you want to get finer-grained management you may further divide the range into subranges that that have their own rule.
By default the rule will not be active and the packets will eventually be accepted thus allowing access to the proxy server. If the rule is enabled, the packets will be dropped, effectively barring access to the proxy.
Now, the decision whether the rule applies or not may not be the administrator's. In some contexts it is more relevant to delegate this to some authorized users, typically head of departments, teachers... In our case study the administrator wishes the head of the electronics department to take care of this, To do this he or she builds an access control list on the rule, specifying user eo-head as authorized to modify the time settings on the rule and whether the rule is activated at these time-slots. User eo-head can then connect to a web interface where a time slots for the rule is displayed. The time table is defined on a weekly basis and defines the habitual settings for weeks and the current week's settings which, if defined, override the habitual settings. Note that the current settings are reset every week (and are thus temporary). The head of department then decides that the electronics department access to the proxy server will be down for hosts in the electronics department on monday and thursday mornings but granted the rest of the time, with the provision that this week, due to exams, no access will be allowed on wednesday afternoon. The MutFi engine, awakened at given intervals, will enforce this.
Mutfi takes care of configuring the apache and MySQL servers.
The following are dependencies for MutFi to work (these can be sorted out by rpm or deb packages):
|
|
Fedora |
Debian |
Ubuntu |
Mandriva |
|---|---|---|---|---|
|
iptables |
iptables |
iptables |
iptables |
iptables |
|
MySQL server |
mysql-server |
mysql-server |
mysql-server |
MySQL |
|
MySQL client |
mysql |
mysql-client |
mysql-client |
MySQL-client |
|
python |
python |
python |
python |
python |
|
python::ConfigParser |
(comes standard) |
(comes standard) |
(comes standard) |
(comes standard) |
|
python::MySQLdb |
MySQL-python |
python-mysqldb |
python-mysqldb |
MySQL-python |
|
apache |
httpd |
apache2 |
apache2 |
apache-base |
|
apache::php-mod |
|
libapache2-mod-php4 |
libapache2-mod-php5 |
apache-mod_php |
|
php |
php |
php4 |
php5 |
libphp5_common5 |
|
Php::mysql |
php-mysql |
php4-mysql |
php5-mysql |
php-mysql |
|
pear |
php-pear |
php4-pear |
php-pear |
php-pear |
|
pear::Auth |
(pear- installed) |
php-auth |
php-auth |
(pear- installed) |
|
pear::DB |
php-pear-DB |
(pear- installed) |
php-db |
(pear- installed) |
|
pear::Config |
(pear- installed) |
(pear- installed) |
(pear- installed) |
(pear- installed) |
Particular care has been taken to make configuration easy. Basically
#make install start
will suffice though at some points the following prompts will appear, requesting :
|
mysql root password> |
the MySQL administrator's password. This is needed to initially create the database. |
|
mysql querier> |
the non-interactive user on whose behalf the queries to the database will be performed. It will be created and granted permissions on the database. This is a MySQL user and is not to be confused with a system user (nor does it have to match a system user). |
|
mysql querier password> |
the mysql querier password for scripts to authenticate against the database. Please note that this is also the admin user's initial password, which can be later set to a different value. |
|
how often> |
determines how often rules will be enforced. Use the following shortcuts: M=every mn M5=every 5mn Mx=every x mn H=hourly H5=hourly at 5 past Hx=hourly at x past |
Three tasks are then to be performed by the administrator (through the web interface at http://localhost/mutfi and after logging as admin with the second password mentioned above):
import the users from a file having lines with the following format:
login;password;lastname;firstname;description
import the rules from a file having lines with the following format:
name;from;to;description;chain;target;protocol;port
Note that chain,target,protocol,port are optional and can be configured globally on importing. Chain is any name that is defined for a chain in the Netfilter iptables (only one is provided in the Netfilter basic scheme provided: any-me). Target is usually DROP. Protocol is one of tcp,udp,icmp but may refer to any of these if undefined. Port refers to all ports if undefined.
define the rules' access control lists for the users by simply selecting the rules whose time slots a user is allowed to modify
It may not be handy for rules to apply at 08:00, 09:00, ... sharp and you may want them to be enforced at 08:15, 09:15 ... Specify a time offset of 15 in the /etc/mutfi.conf file
|
|
|---|
|
|
|
|
|
|
|
|
|---|
|
|
|
|
|
|
