HLFL(1) User Manuals HLFL(1)NAMEhlfl - High Level Firewall Language
SYNOPSIShlfl-t or --type=
[ipchains | ipfw | ipfw4 | ipfwadm | ipfilter | netfilter |
cisco ] RULEFILE
-o or --output=
FILE (stdout is the default)
-h or --help
prints help
-V or --version
prints version
-c or --check
check netmasks before computing
-v or --verbose
be verbose, print comments
DESCRIPTIONhlfl is a tool which can produce several types of firewalls from a
given set of rules written in a special language also called hlfl (how‐
ever awkward it is).
hlfl attempts to make the best use of the features of the underlying
firewall, so that the conversion of a stateless to a stateful requires
no modification to the original script
HLFL - THE 'LANGUAGE'
A complete description of the hlfl syntax is in
/usr/local/share/doc/hlfl/syntax.txt Each order must fit on one line.
The syntax is :
protocol (local) operator (remote) [interface] keywords
Where :
protocol
must be one of tcp , udp , icmp or all
(local) and (remote)
contain the IP addresses (and tcp and udp ports) of both side.
Multiple IPs may be specified. For instance :
(192.168.1.1 21 | 192.168.2.1 80)
Means 'port 21 of 192.168.1.1 or port 80 of 192.168.2.1'. The port
range syntax is the same as, say, nmap(1). The next statements are
valid :
tcp (192.168.1.1 21,22,1024-3128,4000-) -> (any)
tcp ((192.168.1.1|192.168.2.1) 21,22,1024-) -> (any)
Note : it is very important to understand that local and remote can not
be exchanged. local is the thing you want to protect, and remote is
the other party. Be sure to understand that or your rules will not work
and you won't like hlfl.
operator
must be one of the defined operators. The following list of
operators has been defined :
-> : accept outgoing
<- : accept incoming
<-> : accept outgoing and incoming
<=>> : accept outgoing and incoming if the communication was
established by the local side first
<<=> : same as above except that the communication must be
established by the remote side first
X-> : deny outgoing
X!-> : reject outgoing
<-X : deny incoming
<-X! : reject incoming
X : deny outgoing and incoming
X! : reject outgoing and incoming
Full text operators are allowed. The syntax is :
operator ::= "accept" | "deny" | "reject" [ "from" | "to" |
"and" | "established" | "log" ]
It is possible to combine full text operators with symbolic
ones. This can be done for logging support.
[interface]
interface is the name of the interface to apply the rule to
keyword
additional keyword. At this time, only the keyword nomix has
been defined. Imagine you write the rule:
tcp (192.168.1.1 | 192.168.2.1) <-> (172.22.0.1 | 172.22.0.2)
If the keyword nomix is not added at the end of the rule, then this
rule means :
- accept tcp traffic between 192.168.1.1 and 172.22.0.1
- accept tcp traffic between 192.168.1.1 and 172.22.0.2
- accept tcp traffic between 192.168.2.1 and 172.22.0.1
- accept tcp traffic between 192.168.2.1 and 172.22.0.2
Now, if nomix is added at the end of the rule, then it means :
- accept tcp traffic between 192.168.1.1 and 172.22.0.1
- accept tcp traffic between 192.168.2.1 and 172.22.0.2
It is possible to define words using the define instruction :
define my_net 192.168.1.0/24
define ssh 22
define my_interface ne1
tcp (my_net 22) <<=> (any 1020-) [my_interface]
The include keyword allows you to include other files.
include /path/to/my/file.hlfl
include file.hlfl
The second include statement will include the file hflf.fl which is in
the current working directory.
It is also possible to include 'systems' file, using brackets :
include <services.hlfl>
This statement includes the file /usr/local/share/doc/hlfl/ser‐
vices.hlfl, which contains the definition of common tcp and udp ser‐
vices.
Lines starting with '#' or '%' are treated as comments. '#' comments
will be integrated in the final file, whereas '%' comments will be
dropped :
% include myfile.hlfl which contains useful defintions
include myfile.hlfl
# deny tcp
tcp (any) X (any)
Will give, in ipfw :
# deny tcp
ipfw -f add deny tcp from any to any
Lines starting with a '!' will be included as commands in the generated
file. This reduces portability, but this allow you to have all your
firewall configuration stored in one .hlfl file. For instance, I use at
home :
!ipchains -s 192.168.1.0 -d 0/0 -i eth1 -j MASQ
tcp (any) -> (any) [eth1]
I use ipchains, so I included my ipchains masquerading policy in my
configuration file. If I wanted to change my firewall to something else
(top-notch ipfilter because ipfilter is _the_ way to go), then I'll
have to change (remove actually) the line starting by '!'.
It is possible to define conditional inclusion. For instance, this rule
makes no sense if I am generating an ipf firewall, so the 'if( type )'
statement exists :
% only include the following in the case we are generating an
% ipchains firewall. Generate a warning if we are not using
% ipchains
!if(ipchains) ipchains -s 192.168.1.0 -d 0/0 -i eth1 -j MASQ
! else echo "Warning - NAT is not handled in this configuration"
EXAMPLE
see /usr/local/share/doc/hlfl/ for real-life examples.
NOTE
By default, the rules are permissives, everything is allowed to pass to
anywhere. If you want to change that default, add
all (any) X (any)
at the end of your rules.
OTHER INFOS
If you find some bug, please mail it to hlfl's mailing list,
<hlfl@hlfl.org>. More details at http://www.hlfl.org/
AUTHORShlfl was written by Renaud Deraison <deraison@hlfl.org> because the day
he had to convert his ipfw firewall to ipfilter, he sweared he'd never
do that again.
Arnaud Launay <launay@hlfl.org> joined later on, and took actively part
in the project.
June 8, 2003 HLFL(1)
