Abstracted XML Network Management

1. 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

2. 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

3. 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

4. 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

5. Overall Process – The Big Picture • 1. Establish the node, service • and network descriptions. • Apply element behaviour. • System state, in generic, • portable descriptions. • Key centre of system. • Evaluate performance and • security of configurations. • Provide feedback to • initial configurations. • Identify possible problems in translation to implementation level configurations. • Locate problems, indicate to user, propose possible solutions. • Generate implementation level configuration files for required nodes/services. • Description of whole system. Employ change management and version control.

6. 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

7. Describing the Nodes and Services (2) - Example • Example firewall rule <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 DNS forward start of authority <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>

8. Describing the Nodes and Services (3) - Variables • Variable mappings Firewall scope <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 Service Construct scope

9. 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

10. Describing the Nodes and Services (5) - Constructs • Create IPSec (VPN) tunnel between two hosts Customise behaviour <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> Unique name • 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

11. 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

12. Describing the Nodes and Services (7) - Functions • DNS reverse (address to name) mapping generation <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> Operate on this construct Pass parameters to function

13. Describing the Nodes and Services (8) - Functions • DNS function result Whole construct substituted into source XML <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> Produces a valid reverse mapping element for the forward mappings we fed in • 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

14. 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.

15. Network Dependencies Example - Functions

16. 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

17. 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

18. System Simulation (3) – Conceptual Example Trace

19. 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

20. 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

21. 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> No element present No attribute present Attribute with different value Counting number of elements • 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

22. Restriction Analysis (5) – Restriction Output • Generated output Details on the restriction <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> The matched configuration Indicates that we need to make changes to our specification • Produces details on the restrictions found in XML format • Includes the element from the source configuration with the restriction

23. 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

24. 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 output add 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

25. 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> Expanded configurations fed into translator • DNS configuration toons.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.net localhost IN A 127.0.0.1 sooty IN A 192.168.15.95 sly IN A 192.168.15.90 ben IN A 192.168.15.101 roadrunner IN A 192.168.15.254 Can be directly loaded into service implementation

26. 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

27. 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

28. 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.