Conference PaperPDF Available

MT-FWL: Multi-Target Firewall Language

Authors:
  • Park Smart s.r.l.
MT-FWL: MULTI-TARGET FIREWALL LANGUAGE
Francesco Pappalardo, Giuseppe Patanè and Giuseppe Riccardo Pistorio
University of Catania
Catania (Italy)
{francesco, patane}@dmi.unict.it, giuseppe@pistorio.net
Abstract
Security in a computer system is very critical, especially for internet servers, complex network topology and
mission critical applications. Once all services have been hardened, firewalls should be installed and well
configured to improve general system security. Here we present MT-FWL, an high level multi target platform
language for managing a Packet Filtering Box.
Keywords
Firewalls, Languages, System Security, Administration, Object Oriented Network Classification.
1. INTRODUCTION
Managing firewall rules on a local system prevents some unexpected negative events to happen. For instance,
even if the provided services are securely configured, a firewall can protect from misconfigurations or from new
installed services that have not yet been properly configured. On the other hand, inserting new common rules in
the managed network, involves their insertion in any host of the network.
Software systems which allow easy server and end side configurations, are rare and, as a consequence,
expensive. A good, not expensive firewall can be designed and implemented, using Linux and its Packet
Filtering system at the Kernel level. Such solution is, usually, not adopted by system administrators.
Indeed, even if you use the available visual tools, to check the applied policies, all generated configuration files
need to be examined manually.
Why should you use a language to manage firewalls? If you want to write rules for heterogeneous medium/large
size networks you have to consider the following problems :
no network global vision;
no definitions of host groups with similar features;
no establishing communication rules among groups, groups and single hosts, single hosts within the
same group, and single hosts in different groups;
no representing rule inheritance in a clear way;
no transparency in the firewall management process.
2. MT-FWL: A GENERAL OVERVIEW
In any GNU/Linux distribution, the main three kernel routing tables contain the firewalls rules.
To make a mapping between the main three kernel routing tables and the network / internet topology is a very
hard problem. A typical representation of Internet’s hosts is done by a general graph: early approaches to create a
medium level language for firewall rules management were too much graph topology dependent. The main
consequences of this approach are:
lack of a centralized authority;
the rules sequence: successive application of two semantic different rules on the same host will, in
general, produce the effect described by the last one;
lack of local network policy.
The Domain Name system (DNS) uses a zone division to represent the global hosts connected to Internet. Such
zones are grouped in a gerarchic tree (leaves’ tree are hosts).
The DNS approach (to represent connection links) in a firewall box allows the following facilities:
rules are locally defined (not centralized);
managing rules, discovering errors or conflicts are simple;
you can define rules for each node (is only required authorization from father node);
MT-FWL language translates your high level language firewalling rules into usable rules for IPChains, NetFilter,
IPFilter, Cisco, and many others. It allows to define several macro objects. Every macro object has its own rules.
Derived objects have their own rules and the inherited ones.
To obtain such a goal, we thought of a network as a collection of sets to which we can associate input and output
rules. MT-FWL mimic hosts’ representation by n-tree.
MT-FWL is implemented in ANSI C. Lexical analysis is performed by GNU/FLEX [4]. Syntactical analysis is
done by GNU/BISON [5]. MT-FWL was developed on GNU/Linux platform.
2.1 MT-FWL COMPONENTS
The major components of the implementation are:
Doors: language basic objects. They represent communication links between the firewall and internal
and external networks. Each door is uniquely identified by its own ID, an IP address and the device
type;
Child: it represents a subnet. Every door represents the root object of a network or subnet. Therefore,
for each door it is possible to define its children, i.e. subnets, terminals or terminal port. A child,
declared with a door, can contain other children.
Rules: represent security policies. Each rule describes the firewall policy between two children
associated to the door. Each rule can be written for three protocols: tcp, udp, icmp.
doors
child
child
Deny
firewall
doors
child
child
3. A WORKING EXAMPLE
The following example shows MT-FWL expressive power. In this example, MT-FWL basic syntax and
semantics are introduced.
The produced output rules are very effcient yet very complex and difficult to write without MT-FWL.
Example 1: Simple MT-FWL script
SCRIPT myfirewall ;
BEGINSTAT
private eth0 192.168.1.1
{
BATMAN
{
BATMAN_COMMON
{
BATMAN_HTTP 192.168.1.2/80;
BATMAN_FTP 192.168.1.2/21;
}
BATMAN_OTHER
{
BATMAN_MAIL 192.168.1.2/3000;
}
}
ROBIN
{
ROBIN_HTTP 192.168.1.3/80;
ROBIN_FTP 192.168.1.3/21;
}
}
dmz eth1 151.97.6.2
{
SIRIUS
{
SIRIUS_HTTP 151.97.6.7/80 ;
SIRIUS_FTP 151.97.6.7/21 ;
}
}
SECSTUFF ON;
ENDSTAT
BEGINRULES
allow udp,tcp from BATMAN to SIRIUS ;
ENDRULES
Example 1: Simple MT-FWL output
IPCHAINS=/sbin/ipchains
# some handy generic values to use
ANY=0.0.0.0/0
ALLONES=255.255.255.255
##
## Setup Envirement
##
# Flush all lists
$IPCHAINS F input
$IPCHAINS F output
$IPCHAINS F forward
# Plug up everything
$IPCHAINS I input 1 j DENY
# set policy to deny (Default is ACCEPT)
$IPCHAINS P input DENY
$IPCHAINS P output ACCEPT
$IPCHAINS P forward ACCEPT
# Turn on packet forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
##
## Install Modules
##
# Insert the active ftp module. This will allow nonpassive ftp to machines
# on the local network (but not to the router since it is not masq'd)
if ! ( /sbin/lsmod | /bin/grep masq_ftp > /dev/null ); then
/sbin/insmod ip_masq_ftp
fi
################################################################################
##
## Some Security Stuff
##
# turn on Source Address Verification and get spoof protection
# on all current and future interfaces.
if [ e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
else
echo
echo "PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED."
echo
fi
# deny bcasts on remaining interfaces
$IPCHAINS A input d 0.0.0.0 j DENY
$IPCHAINS A input d 255.255.255.255 j DENY
# deny these without logging 'cause there tend to be a lot...
$IPCHAINS A input p udp d $ANY 137 j DENY # NetBIOS over IP
$IPCHAINS A input p tcp d $ANY 137 j DENY # ""
$IPCHAINS A input p udp d $ANY 138 j DENY # ""
$IPCHAINS A input p tcp d $ANY 138 j DENY # ""
$IPCHAINS A input p udp d $ANY 67 j DENY # bootp
$IPCHAINS A input p udp d $ANY 68 j DENY # ""
$IPCHAINS A input s 224.0.0.0/8 j DENY # Multicast addresses
#################################################################################
# Linking the defined doors #
#################################################################################
$IPCHAINS -A forward -s 192.168.1.1 -i eth0 -d 151.97.6.2
$IPCHAINS -A forward -s 151.97.6.2 -i eth1 -d 192.168.1.1
############################## SINGLE RULE (DEFINITIONS) ########################
$IPCHAINS -A allow -p udp -s 192.168.1.2:80 -d 151.97.6.7:80
$IPCHAINS -A allow -p tcp -s 192.168.1.2:80 -d 151.97.6.7:80
$IPCHAINS -A allow -p udp -s 192.168.1.2:80 -d 151.97.6.7:21
$IPCHAINS -A allow -p tcp -s 192.168.1.2:80 -d 151.97.6.7:21
$IPCHAINS -A allow -p udp -s 192.168.1.2:21 -d 151.97.6.7:80
$IPCHAINS -A allow -p tcp -s 192.168.1.2:21 -d 151.97.6.7:80
$IPCHAINS -A allow -p udp -s 192.168.1.2:21 -d 151.97.6.7:21
$IPCHAINS -A allow -p tcp -s 192.168.1.2:21 -d 151.97.6.7:21
$IPCHAINS -A allow -p udp -s 192.168.1.2:3000 -d 151.97.6.7:80
$IPCHAINS -A allow -p tcp -s 192.168.1.2:3000 -d 151.97.6.7:80
$IPCHAINS -A allow -p udp -s 192.168.1.2:3000 -d 151.97.6.7:21
$IPCHAINS -A allow -p tcp -s 192.168.1.2:3000 d 151.97.6.7:21
4. CONCLUSION AND FUTURES WORKS .
At the moment, MT-FWL supports the following target languages:
IPChains. (Full support) [1].
NetFilter/IPTables. (Partial support) [2].
Cisco ACL. (Work In Progress) [3].
Future versions of MT-FWL will include full support for IPTables and Cisco ACL.
5. ACKNOWLEDGMENTS.
We would like to thank Prof. S. Motta (University of Catania) and Anna Marino for their valuable comments.
References
[1] Rusty Russell IPCHAINS HOWTO. http://www.netfilter.org/ipchains/
[2] Rusty Russell IPTABLES/NETFILTER HOWTO http://www.netfilter.org/
[3] CESG COMPUSEC MANUAL N. Vulnerabilities of the TCP/IP protocol suite. Cisco Security Book ISBN
1-57870-043-4 Cisco IOS Network Security ISBN 1-57870-057-4.
[4] GNU/FLEX Linux Manual Section 1
[5] GNU/BISON Linux Manual Section 1
ResearchGate has not been able to resolve any citations for this publication.
Vulnerabilities of the TCP/IP protocol suite
  • Cesg Compusec Manual N
CESG COMPUSEC MANUAL N. Vulnerabilities of the TCP/IP protocol suite. Cisco Security Book ISBN 1-57870-043-4 Cisco IOS Network Security ISBN 1-57870-057-4.