| Network Management Page 4 |
Service Translation Specification
The next stage in the system is to convert the abstracted service descriptions to configurations that can be applied directly to a service implementation. The process used to achieve this is XSLT using XSL stylesheets. For each implementation, such as IPFilter or IPFW for firewalls, an XSL sheet is created to perform the transformation to the end level rules. An XML file of the
The aim is to create a rich enough translation between the abstracted description and the final configurations, so that the behaviour directly reflects that of the original XML specification. If this could be achieved, a node could in fact be swapped with one running a different implementation of a given service. Generating the configurations for this new node should give the same functionality as before, enabling services to be swapped for performance, security and testing reasons.
Current Translations
To date I have implemented the abstracted descriptions for the firewall and DNS services. Translations for IPFW and IPFilter are currently used for firewall, and a single translation for Bind8 with DNS. I am still tweaking the translations to establish a suitable generic description, as obviously each implementation differs in functionality.
By the end of the project I hope to have the two firewall translations pretty much complete, as with the DNS Bind8 conversion. Both the firewall and DNS services are based around either rules or segments of repeated configuration. I would like to investigate into a service that differs from this, to establish whether the current architecture will expand easily.
As I develop the translations I will post them onto this site. However, they are all still under development, and work is currently underway to establish a testing procedure.
See the examples page for details on these. Also, within the package is a complete test network, contains various nodes, running DNS and firewall services. This is a fully implemented example, along with diagrams and descriptions. As I add new elements to the system, I will update this example network, gradually making it more complex. When the simulator is implemented I will use this as a test bed.
Goto Top| Global Variables |
Variables defined at this level will have scope over the whole Node. Within the package there are various pre-defined system variables. An example is $this which is mapped to the name of the current node. |
| Funky Stuff |
To the right are examples of external service construct references and functions calls. See page 2 for more details on how these work. |
| DNS Configs |
The Zone section of the DNS configuration should be the only implementation specific detail of the final output. The reason for this is because the zone files themselves, represented by ForwardSOA and ReverseSOA are produced in a standardized format. The following are useful links for DNS configuration and reference. Setting up DNS Data Domain Names - Implementation and specification Domain Administrators Operations Guide |
| IPFW Coverage |
I originally developed the firewall abstracted description from the IPFW specification. Therefore most of the functionality is included. The plan is attempt to test both an IPFW and IPFilter configuration sets against each other, to try to prove that both the generated configurations in fact behave the same. |
| IPFilter Coverage |
Development of the IPFilter translation is still going on. I hope to have it fully functional by the end of the project. The main problem is related to the need to generate duplicate rules within the translation, but with minor differences to provide the required functionality of the abstracted description. An example of this problem is that IPFilter requires you to specify the direction of travel of the packet. Therefore, if not provided within the original description, two rules need to be generated, one for in and one for out |
| DNS Output |
The output from the DNS translation will go into multiple files. The main Zone information goes into the implementation specific DNS configuration file named.conf. The rest goes into standardised zone files, such as db.ADDR and db.DOMAIN. Please note that DNS translation is still being developed... as with everything else! |
Translation Implementation and Execution
Following is a working example of an input XML description of a single node, and generating the service
configurations for its service from this.
The Node XML Description
IPFW Firewall Configurations
IPFilter Firewall Configurations
BIND v8 DNS Configurations
Standard XML Configuration of a Node with Firewall and DNS Services
The following node description has some basic firewall and DNS functionality. It uses the main concepts of my project that have been discussed so far, such as service constructs, variables, functions and external constructs. This configuration is in the un-expanded form, hence variable mappings and function/external references have not been resolved. Prior to being fed into the final translator, these are all resolved automatically by the package itself.
<Node xmlns="http://www.ecs.soton.ac.uk/~src299/xmlnetman"
xmlns:fw="http://www.ecs.soton.ac.uk/~src299/xmlnetman/firewall"
xmlns:dns="http://www.ecs.soton.ac.uk/~src299/xmlnetman/dns"
xsi:schemaLocation="http://www.ecs.soton.ac.uk/~src299/xmlnetman Node.xsd">
<!-- These will be global over the whole node, define network interfaces etc -->
<Mappings>
<Variable name="interface_1_ip" value="192.168.2.100"/>
<Variable name="interface_1" value="rl0"/>
<Variable name="interface_2" value="tun0"/>
<Variable name="interface_2_ip" value="217.1.2.3"/>
<Variable name="untrusted_if" value="$interface_2"/>
<Variable name="me" value="$interface_2_ip"/>
<Variable name="node_name" value="bill"/>
</Mappings>
<fw:Firewall>
<!-- Variables in the scope of the firewall. Also define rule_base, the ID -->
<!-- number to start rules from -->
<Mappings>
<Variable name="ben" value="192.168.2.101"/>
<Variable name="rule_base" value="100"/>
</Mappings>
<!-- Standard loopback processing -->
<fw:FirewallConstruct name="Loopback Handeling"
description="Does stuff with the loopback device">
<Mappings>
<Variable name="block_rule_base" value="$rule_base"/>
</Mappings>
<fw:Rule Desc="Allow loopback" RuleID="$block_rule_base">
<fw:action perform="pass"/>
<fw:protocol type="all"/>
<fw:src type="any"/>
<fw:dst type="any"/>
<fw:interface via="lo0"/>
</fw:Rule>
<fw:Rule Desc="Prevent spoofing of loopback" RuleID="$block_rule_base+1">
<fw:action perform="deny"/>
<fw:log logamount="0" value="true"/>
<fw:protocol type="all"/>
<fw:src type="any"/>
<fw:dst mask="255.0.0.0" address="127.0.0.1" type="ip"/>
<fw:interface/>
</fw:Rule>
<fw:Rule Desc="Prevent spoofing of internal private ip range"
RuleID="$block_rule_base+2">
<fw:action perform="deny"/>
<fw:protocol type="all"/>
<fw:src type="ip" negate="true" address="$net_num" mask="$net_mask"/>
<fw:dst type="any"/>
<fw:interface direction="in" recv="$interface_1"/>
</fw:Rule>
</fw:FirewallConstruct>
<!-- Just some standard protection. Externally defined. -->
<fw:FirewallConstruct name="Standard Protection"
description="External">
<!-- Redefine the local rule base for this block -->
<Mappings>
<Variable name="block_rule_base" value="$rule_base+200"/>
</Mappings>
<ExternalConstruct name="Firewall::ExternalConstruct:Protection"/>
</fw:FirewallConstruct>
<!-- Define that we want to include the spoof protection serice construct -->
<!-- Sucks in a construct from the ConstructManager -->
<fw:FirewallConstruct name="Do Spoof Prevention" description="">
<Mappings>
<Variable name="block_rule_base" value="$rule_base+900"/>
</Mappings>
<ExternalConstruct name="Firewall::ExternalConstruct:Spoof Prevention"/>
</fw:FirewallConstruct>
<!-- Stop stuff from private networks comming in our trusted interface -->
<!-- Externally defined within the construct library -->
<fw:FirewallConstruct name="Draft manning stuff" description="">
<Mappings>
<Variable name="block_rule_base" value="$rule_base+1000"/>
</Mappings>
<ExternalConstruct name="Firewall::ExternalConstruct:draft-manning-dsua-04.txt"/>
</fw:FirewallConstruct>
<!-- Just let everything else through -->
<fw:FirewallConstruct name="Open Up" description="Let it all flow">
<fw:Rule Desc="Let all traffic through" RuleID="$rule_base+10000">
<fw:action perform="pass"/>
<fw:protocol type="all"/>
<fw:src type="any"/>
<fw:dst type="any"/>
</fw:Rule>
</fw:FirewallConstruct>
</fw:Firewall>
<!-- DNS service configuration follows -->
<dns:DNS>
<!-- DNS wide global variable mappings -->
<Mappings>
<Variable name="root_domain" value="foo.net"/>
<Variable name="NS" value="bill.$root_domain"/>
<Variable name="network" value="192.168.2"/>
</Mappings>
<!-- Options - i.e. named.conf in BIND8 : Defines all our zones -->
<dns:Bindings>
<dns:Zone name="$root_domain" type="master" file="db.$root_domain"/>
<dns:Zone name="2.168.192.in-addr.arpa" type="master" file="db.$network"/>
<dns:Zone name="0.0.127.in-addr.arpa" type="master" file="db.127.0.0"/>
</dns:Bindings>
<!-- All the forward resolution files -->
<dns:DNSConstruct name="Forward" description="Standard forward resolution">
<Mappings>
<Variable name="file" value="db.$root_domain"/>
</Mappings>
<!-- Standard forward lookup -->
<dns:ForwardSOA match="$root_domain"
primaryns="$NS"
adminmail="admin.$this.$root_domain"
file="$file"
serial="5"
refresh="10800"
retry="3600"
expire="604800"
min_ttl="86400">
<dns:NS match="@" target="$this.$root_domain"/>
<dns:A match="localhost" target="127.0.0.1"/>
<dns:A match="bill" target="$network.100"/>
<dns:A match="ben" target="$network.101"/>
<dns:A match="sly" target="$network.90"/>
<dns:A match="weed" target="$network.92"/>
<dns:CNAME match="www" target="bill"/>
<dns:CNAME match="www2" target="ben"/>
<dns:CNAME match="ftp" target="ben"/>
<dns:MX match="@" target="mail.$root_domain" priority="10"/>
</dns:ForwardSOA>
</dns:DNSConstruct>
<!-- Use a function to generate the reverse resolution file (SOA) -->
<dns:DNSConstruct name="Reverse" description="Standard reverse resolution">
<!-- Execute the function call on the forward SOA defined above -->
<CallFunction name="DNS::Functions:GenReverseSOA"
onConstruct="DNS::ServiceConstruct:$this/forward">
<Parameter name="dbfile" value="db.$network"/>
<Parameter name="with_net" value="$network"/>
</CallFunction>
</dns:DNSConstruct>
<!-- Use externally defined loopback feature -->
<dns:DNSConstruct name="Loopback" description="Pull in external loopback definitions">
<Mappings>
<Variable name="primaryns" value="$NS"/>
<Variable name="adminmail" value="admin.$this.$root_domain"/>
<Variable name="domain" value="$root_domain"/>
</Mappings>
<!-- Pull in loopback definition. Use variables to define behaviour -->
<ExternalConstruct name="DNS::ExternalConstruct:Loopback"/>
</dns:DNSConstruct>
</dns:DNS>
</Node>
IPFW Firewall Rules
The following rules were generated using the Firewall::Translator:IPFW service translation, with the aim to be applied to the IPFW package typically used with FreeBSD.
###############
# Loopback Handeling
# Does stuff with the loopback device
# Allow loopback
add 100 pass all from any to any via lo0
# Prevent spoofing of loopback
add 101 deny all from any to 127.0.0.1:255.0.0.0
# Prevent spoofing of internal private ip range
add 102 deny all from 192.168.2.0:255.255.255.0 to any in recv rl0
###############
# Library_Protection
# Protect from common basic attacks
# Prevent OS finger printing
add 300 deny tcp from any to any tcpflags syn,fin in via tun0
###############
# Library_Spoof Prevention
# Prevents spoofing over untrusted interface
add 1000 deny all from 192.168.0.0:255.255.0.0 to any in via tun0
add 1001 deny all from 172.16.0.0:255.255.0.0 to any in via tun0
add 1002 deny all from 10.0.0.0:255.0.0.0 to any in via tun0
add 1003 deny all from any to 192.168.0.0:255.255.255.0 in via tun0
add 1004 deny all from any to 172.16.0.0:255.255.255.0 in via tun0
add 1005 deny all from any to 10.0.0.0:255.0.0.0 in via tun0
###############
# Library_draft-manning-dsua-04.txt
# Prevents IPv4 unroutable nets from entering via untrusted interface
add 1100 deny all from 0.0.0.0:255.0.0.0 to any in via tun0
add 1101 deny all from 169.254.0.0:255.255.0.0 to any in via tun0
add 1102 deny all from 192.0.2.0:255.255.255.0 to any in via tun0
add 1103 deny all from 224.0.0.0:255.0.0.0 to any in via tun0
add 1104 deny all from 240.0.0.0:255.0.0.0 to any in via tun0
add 1105 deny all from any to 0.0.0.0:255.0.0.0 in via tun0
add 1106 deny all from any to 169.254.0.0:255.255.0.0 in via tun0
add 1107 deny all from any to 192.254.2.0:255.255.255.0 in via tun0
add 1108 deny all from any to 224.0.0.0:255.0.0.0 in via tun0
add 1109 deny all from any to 240.0.0.0:255.0.0.0 in via tun0
###############
# Open Up
# Let it all flow
# Let all traffic through
add 10100 pass all from any to any
IPFilter Firewall Rules
The following rules were generated using the Firewall::Translator:IPFilter service translation, with the aim to be applied to the IPFlter package. This translation is still under development.
###############
# Loopback Handeling
# Does stuff with the loopback device
# Allow loopback
@100 pass in quick on lo0 all
# Prevent spoofing of loopback
@101 block in log quick from any to 127.0.0.1 mask 255.0.0.0
# Prevent spoofing of internal private ip range
@102 block in quick from ! 192.168.2.0 mask 255.255.255.0 to any
###############
# Library_Protection
# Protect from common basic attacks
# Prevent OS finger printing
@300 block in quick on tun0 proto tcp all flags /SF
###############
# Library_Spoof Prevention
# Prevents spoofing over untrusted interface
@1000 block in log quick on tun0 from 192.168.0.0 mask 255.255.0.0 to any
@1001 block in log quick on tun0 from 172.16.0.0 mask 255.255.0.0 to any
@1002 block in log quick on tun0 from 10.0.0.0 mask 255.0.0.0 to any
@1003 block in log quick on tun0 from any to 192.168.0.0 mask 255.255.255.0
@1004 block in log quick on tun0 from any to 172.16.0.0 mask 255.255.255.0
@1005 block in log quick on tun0 from any to 10.0.0.0 mask 255.0.0.0
###############
# Library_draft-manning-dsua-04.txt
# Prevents IPv4 unroutable nets from entering via untrusted interface
@1100 block in log quick on tun0 from 0.0.0.0 mask 255.0.0.0 to any
@1101 block in log quick on tun0 from 169.254.0.0 mask 255.255.0.0 to any
@1102 block in log quick on tun0 from 192.0.2.0 mask 255.255.255.0 to any
@1103 block in log quick on tun0 from 224.0.0.0 mask 255.0.0.0 to any
@1104 block in log quick on tun0 from 240.0.0.0 mask 255.0.0.0 to any
@1105 block in log quick on tun0 from any to 0.0.0.0 mask 255.0.0.0
@1106 block in log quick on tun0 from any to 169.254.0.0 mask 255.255.0.0
@1107 block in log quick on tun0 from any to 192.254.2.0 mask 255.255.255.0
@1108 block in log quick on tun0 from any to 224.0.0.0 mask 255.0.0.0
@1109 block in log quick on tun0 from any to 240.0.0.0 mask 255.0.0.0
###############
# Open Up
# Let it all flow
# Let all traffic through
@10100 pass in quick all
@10101 pass out quick all
DNS Configuration and Bind 8
The following rules were generated using the DNS::Translator:BIND8 service translation, with the aim to be applied to Bind version 8. This translation is still under development, and is yet to be fully tested. Each segment of this output would be placed into a separate file before being applied.
<!--BIND 8 service configuration (named.conf) -->
zone "foo.net" in {
type master;
file "db.foo.net";
};
zone "2.168.192.in-addr.arpa" in {
type master;
file "db.192.168.2";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
};
<!--Address Resolution Files Follow -->
# Forward - Standard forward resolution
# File (db.foo.net)
$TTL 3600
foo.net. IN SOA bill.foo.net. admin.bill.foo.net (
5 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expires
86400) ; Minumum Time to live
@ IN NS bill.foo.net
localhost IN A 127.0.0.1
bill IN A 192.168.2.100
ben IN A 192.168.2.101
sly IN A 192.168.2.90
weed IN A 192.168.2.92
www IN CNAME bill
www2 IN CNAME ben
ftp IN CNAME ben
@ IN MX 10 mail.foo.net
# Reverse SOA - Generated by DNS::Functions:ReverseSOAGen
# File (db.192.168.2)
$TTL 3600
2.168.192.in-addr.arpa. IN SOA bill.foo.net. admin.bill.foo.net (
5 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expires
86400) ; Minumum Time to live
@ IN NS bill.foo.net.
100 IN PTR bill.foo.net.
101 IN PTR ben.foo.net.
90 IN PTR sly.foo.net.
92 IN PTR weed.foo.net.
# Library_Loopback - Lookback DNS reverse resolution
# File (db.127.0.0)
$TTL 3600
0.0.127.in-addr.arpa IN SOA bill.foo.net. admin.bill.foo.net (
1 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expires
86400) ; Minumum Time to live
IN NS bill.foo.net.
1 IN PTR localhost.foo.net.
Goto Top
Limitation Detection and Reporting
I identified early in this project that there were obviously going to be differences between each implementation of certain services. Even though they were performing a similar task, some may provide more functionality than others, or require different information to be supplied. A large amount of these differences can be dealt with whilst processing the XSL stylesheet, such as duplicating rules to match in and outgoing packets within firewalls, when no explicit direction was specified.
Each XSL translation has an XML wrapper presenting it to the rest of the system. This file specifies sets of restriction rules to match possible problem XML elements. Refer to this page for more details.
Goto Top |
| For product and general support mail me support@slyware.com | Comments on the overall design to webmaster@slyware.com |
|