Abstracted XML Network Management

Simon Chudley

Ulrich Ultes-Nitsche

University of Southampton

src299@ecs.soton.ac.uk

uun@ecs.soton.ac.uk

http://www.slyware.com/projects_xmlnetman.shtml

Overview

 

• Introduction & proposed ideas- “Methods and supporting architecture to enable configuration and simulation of nodes within an enterprise environment.”- Management of common services within networks- New configuration management ideas & techniques

• Processes & concepts- Specification, simulation, validation, translation

• Example configuration environment- Implemented network example

• Future development- Detailed simulation & wider service coverage

Project Introduction – The Problem

• Enterprise networks- Contain many nodes running a wide range of services- Configuration files differ greatly- Solutions chosen on performance/security issues

• Implying- Large management overheads- Version control hard to enforce- No central management policy- Simulation & validation of behaviour difficult

• But…- Typically providing standardised services/protocols- Functional requirements static, implementation flexible

Project Introduction – Aim to Provide

• Major aim- Investigate the addition of an extra layer of abstraction- Separate implementation specifics from behaviour

• Components- Abstracted service descriptions- Dynamic configuration of nodes/services- Translation methods through to implementation level- Restriction analysis

- Generic architecture, supporting the transparent addition of new services/translations.- Leading to simulation of behaviour of services, nodes and the whole systems

Overall Process – The Big Picture

1. Establish the node, serviceand network descriptions.

Apply element behaviour.

2. System state, in generic,portable descriptions.Key centre of system.

3. Evaluate performance andsecurity of configurations.Provide feedback to initial configurations.

4. Identify possible problems in translation to implementation level configurations.Locate problems, indicate to user, propose possible solutions.

5. Generate implementation level configuration files for required nodes/services.

6. Description of whole system. Employ change management and version control.

Describing the Nodes and Services (1) – Initial Specs

• Create abstracted descriptions- Networks, nodes, services- Described using XML files, validated by service schemas- Currently implemented firewall and DNS services

• Requiring- Generic elements to cover various implementations- Cover major aspects of such services

• Process- Reverse engineer descriptions from know implementations- Integrate functionality from varying platforms- Highlight major elements

Describing the Nodes and Services (2) - Example

• Example DNS forward start of authority

<fw:Rule Desc="Deny ICMP echo queries" RuleID="1000"> <fw:action perform="deny"/> <fw:protocol name="icmp" type="other"/> <fw:src type="any"/> <fw:dst type="ip" address="192.168.2.254" mask="255.255.255.255"/> <fw:options> <fw:icmptype type="echo-request"/> </fw:options></fw:Rule>

• Example firewall rule

<dns:ForwardSOA match="toons.foo.net">

<dns:A match="localhost" target="127.0.0.1"/> <dns:A match="sooty" target="192.168.15.95"/> <dns:A match="ben" target="192.168.15.101"/> <dns:CNAME match="www" target="ben"/>

</dns:ForwardSOA>

Describing the Nodes and Services (3) - Variables

• Variable mappings <fw:Firewall> <Mappings> <Variable name="rule_base" value="1000"/> <Variable name="upstream_dns" value="192.168.2.100"/> <Variable name="dns_port" value="53"/> <Variable name="net_mask" value="255.255.255.255"/> </Mappings>

<fw:FirewallConstruct> <Mappings> <Variable name="block_rule_base" value="$rule_base+1000"/> </Mappings>

<fw:Rule Desc="Allow comms" RuleID="$block_rule_base+50"> <fw:action perform="pass"/> <fw:protocol type="all"/> <fw:src type="any"/> <fw:dst type="ip" address="$upstream_dns" mask="$net_mask"> <fw:port-num port="$dns_port"/> </fw:dst> </fw:Rule>

</fw:FirewallConstruct></fw:Firewall>

Variable arithmetic

Firewall scope

Service Construct scope

Describing the Nodes and Services (4) - Constructs

• External service constructs - Encapsulate common service functionality- Stored within central library, available throughout system

- Set of firewall rules- DNS configuration for loop-back device..

• Enable- Component based construction of services- Re-use previously tested configuration elements- Construct whole services out of manageable, logical chunks- Improves reliability, share functionality between nodes- Enables centralised management

Describing the Nodes and Services (5) - Constructs

<fw:FirewallConstruct name="IPSec between two hosts">

<Mappings> <Variable name="trusted_net" value="192.168.2.0"/> <Variable name="remote_net" value="192.168.1.0"/> <Variable name="locPubIP" value="152.68.1.2"/> <Variable name="remPubIP" value="152.68.3.4"/> </Mappings>

<ExternalConstruct name="Firewall::ExternalConstruct:IPSec Tunnel"/>

</fw:FirewallConstruct>

• Create IPSec (VPN) tunnel between two hosts

- Imports behaviour from external construct library- Variable mappings used to customise resulting rules- External declaration pulled in prior to service translation/simulation- Modify behaviour of many nodes from single library description- Build service templates

Customise behaviour

Unique name

Describing the Nodes and Services (6) - Functions

• Requirement- To add processing functionality to the configuration stages- Build service description based on the specification of others- No node/service boundaries, can use input from any node- Leads to dynamic configuration of services- Processing performed using XSLT

• Process – on evaluation- XML descriptions of selected service elements passed into function evaluator, with addition parameters- Function generates XML abstracted descriptions- Substituted into the original service specification

Describing the Nodes and Services (7) - Functions

<Mappings> <Variable name="network" value="192.168.15"/> <Variable name="root_domain" value="toons.foo.net"/></Mappings>

<!-– Our defined forward name to address mappings --><dns:DNSConstruct name="Forward"> <dns:ForwardSOA match="$root_domain"> <dns:A match="sooty" target="$network.95"/> <dns:A match="sly" target="$network.90"/> <dns:A match="ben" target="$network.101"/> <dns:A match="roadrunner" target="$network.254"/> </dns:ForwardSOA></dns:DNSConstruct>

<!-– Automatically generate the equivalent reverse mappings --><dns:DNSConstruct name="Reverse">

<CallFunction name="DNS::Functions:GenReverseSOA" onConstruct="DNS::ServiceConstruct:$this/forward">

<Parameter name="with_net" value="$network"/> </CallFunction>

</dns:DNSConstruct>

• DNS reverse (address to name) mapping generation

Operate on this construct

Pass parameters to function

Describing the Nodes and Services (8) - Functions

<dns:DNSConstruct name=“Reverse”>

<dns:ReverseSOA match="15.168.192.in-addr.arpa">

<dns:PTR match="95" target="sooty.toons.foo.net"/> <dns:PTR match="90" target="sly.toons.foo.net"/> <dns:PTR match="101" target="ben.toons.foo.net"/> <dns:PTR match="254" target="roadrunner.toons.foo.net"/>

</dns:ReverseSOA>

</dns:DNSConstruct>

• DNS function result

• Specifying function input- Construct name:- Identify node name, service, construct name DNS::ServiceConstruct:nodeName/forward

- XML Path:- Locate the element explicitly using its position Sooty/Firewall(1)/FirewallConstruct(3)/Rule(15)

- XML Filter:- Select all elements that match some defined rules

Produces a valid reverse mapping elementfor the forward mappings we fed in

Whole construct substituted into source XML

Describing the Nodes and Services (9) - Functions

• Advanced uses- Function to evaluate a service description, and generate the required firewall rules for that service to operate.

- Creating an edge firewall configuration based on the definition of every node within the protected network.

- Build dependencies between services, reducing the need for duplicated configuration.

- Can use duplication function to configure redundant or load balanced services with the same specifications.

- Functions are externally defined XSL sheets, no need to recompile or restart main processing package.

Network Dependencies Example - Functions

System Simulation (1)

• Requirement- To be able to evaluate the behaviour of the abstracted description prior to implementation.- Provide possible performance and security improvements.- Modify original descriptions to reflect these findings.

• Simple case- Firing scripted DNS queries at the system, analysing results.

• Firewall example- Fire single packets at virtual firewall- Obtain pass/deny information, and the rule that matched- Initially stateless approach, moving onto stateful

System Simulation (2)

• Complete simulation- Network of nodes and varying services- Initial DNS query from host…- Track packet, processing at each host, evaluating firewalls- Indicate exact position within the system that such a request gets denied

- Could simulate common network threats to evaluate security of proposed system configuration

- For example, packet may be shown as being refused by the firewall on the node Sooty

System Simulation (3) – Conceptual Example Trace

Restriction Analysis (1)

• Can we ensure behaviour?- Abstracted description of our system behaves as expected- Need to ensure that no undesired behaviour will be introduced during the service translation process.

- Some implementation level services may not support all the functionality within the abstracted description.

- Provide additional feedback to allow the original descriptions to be altered.

- Can also be used to notify user of badly configured services.- Pick out common configuration mistakes- Deprecated options

Restriction Analysis (2) – The Processor

• The process- XML pre-processor filter.- Full service description generated and fed in- Translation specifies a set of restrictions rules, mapping combinations of elements and attributes to some text reason.- XML processed and matching elements picked out.

• The result- Restricted sections of configuration highlighted.- Details as to why they are restricted.- Processed by higher level user application, i.e. GUI

Restriction Analysis (4) – Example Restriction

• Example restriction<RestrictionGroup type="AND" matchOn="Firewall::Filter:FirewallConstruct/Rule" reason="Rules without set directions using ICMP">

<RestrictionGroup type="OR" matchOn="Firewall::Filter:FirewallConstruct/Rule“>

<RestrictionElement name="/interface[!]"/> <RestrictionElement name="/interface@!direction"/>  <RestrictionGroup type="AND" matchOn="Firewall::Filter:FirewallConstruct/Rule/interface"> <RestrictionElement name="@!direction=in"/> <RestrictionElement name="@!direction=out"/> </RestrictionGroup> </RestrictionGroup>

<RestrictionElement name="/options/icmptype[m3]"/> </RestrictionGroup>

- Matches Rule elements that either- Have no interface element- Have an interface element with no direction attribute- Have an interface element with direction not in or out

- The Rule must have more than 3 icmptype sub-elements

No element present

No attribute present

Attribute with different value

Counting number of elements

Restriction Analysis (5) – Restriction Output

• Generated output<Restriction line="57" col="18" path="/Firewall(1)/FirewallConstruct(1)/Rule(7)" reason="Rules without set directions using ICMP">

<fw:Rule RuleID="5002"> <fw:action perform="pass"/> <fw:protocol type="other" name="icmp"/> <fw:src type="ip" mask="255.255.255.0" address="192.168.30.0"/> <fw:dst type="ip" mask="255.255.255.0" address="192.168.15.0"/> <fw:options> <fw:icmptype type="echo-reply"/> <fw:icmptype type="ts-reply"/> <fw:icmptype type="info-reply"/> <fw:icmptype type="add-mask-reply"/> </fw:options> <fw:interface recv="rl0"/> </fw:Rule>

</Restriction>

- Produces details on the restrictions found in XML format- Includes the element from the source configuration with the restriction

Details on the restriction

The matched configuration

Indicates that we need to makechanges to our specification

Service Translation (1) - Overview

• Final process- Now have description of desired system- Aware of any limitations in the translation process

- Convert the abstracted descriptions to implementation level configuration files.- Can then be directly applied to intended service application

• Operation- XSL style-sheet describes the actual translation process- XML for service passed in, configuration files produced- XSL translations can be added with no alteration to package code

- Need sufficient coverage of abstracted configurations

Service Translation (2) – Worked Example - Firewall

• Input firewall rule<fw:Rule Desc="Test Rule" RuleID="100"> <fw:action perform="pass"/> <fw:protocol type="other" name="tcp"/> <fw:src type="any"/> <fw:dst type="any"/> <fw:options setup="true" established="no" gid="200"> <fw:ipoption spec="lsrr" absent="true"/> </fw:options></fw:Rule>

• IPFW outputadd 100 pass tcp from any to any setup ipoptions !lsrr gid 200

• IPFilter output@100 pass in quick proto tcp all flags S/AUPRFS with no opt lsrr@101 pass out quick proto tcp all flags S/AUPRFS with no opt lsrr

- Can toggle between the two service implementations easily

Service Translation (3) – Worked Example - DNS

• Input DNS forward SOA<dns:ForwardSOA match="toons.foo.net" primaryns="sooty.toons.foo.net" adminmail="root.Sooty.toons.foo.net" file="db.toons.foo.net“>

<dns:NS match="@" target="Sooty.toons.foo.net"/> <dns:A match="localhost" target="127.0.0.1"/> <dns:A match="sooty" target="192.168.15.95"/> <dns:A match="sly" target="192.168.15.90"/> <dns:A match="ben" target="192.168.15.101"/> <dns:A match="roadrunner" target="192.168.15.254"/></dns:ForwardSOA>

• DNS configurationtoons.foo.net. IN SOA sooty.toons.foo.net. root.Sooty.toons.foo.net. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expires 86400) ; Minumum Time to live

@ IN NS Sooty.toons.foo.netlocalhost IN A 127.0.0.1sooty IN A 192.168.15.95sly IN A 192.168.15.90ben IN A 192.168.15.101roadrunner IN A 192.168.15.254

Can be directly loaded intoservice implementation

Expanded configurationsfed into translator

Enterprise Description

• Configuration goals- Should now have a validated abstracted description of system- Store in central database, enforce revision control

- Merge system easily- Add new rules/configuration- One click to generate all new configurations for system- Switch between service implementation easily, whilst maintaining same end-user functionality

• Big picture- Fully dynamic nodes. - System responds to changing environment- Generates new abstracted descriptions to improve performance- Automatically translates and applies these to required nodes

Future Developments

• Simulation- Work currently underway- Aim to implement firewall querying, and tracking of packets throughout the system.- Initially state-less, planned expansion into stateful firewalls- Model whole life of a TCP connection

• Service descriptions- Fully complete current service translations- Addition of non-rule based services such as Apache- New translations

• GUI Editor- Processing architecture in place- Development on GUI editor to enable ease of configuration

Conclusion

• Presented- Abstracted descriptions of firewall & DNS services- Architecture for dynamic configuration

- Variables, functions, construct libraries- Translation & restriction analysis techniques- Leading onto simulation possibilities

Simon Chudley: (src299@ecs.soton.ac.uk)

Ulrich Ultes-Nitsche: (uun@ecs.soton.ac.uk)

University of Southampton: (http://www.ecs.soton.ac.uk)

Project details: (http://www.slyware.com)

See projects section. Features additional online documentation, process descriptions and downloads. Will include information on

simulation project findings and editor.