Achieving Reproducible Network Environments with INSALATA

37
Chair of Network Architectures and Services Department of Informatics Technical University of Munich Achieving Reproducible Network Environments with INSALATA Nadine Herold, Matthias Wachs, Marko Dorfhuber, Cristoph Rudolf, Stefan Liebald , Georg Carle Tuesday 11 th July, 2017 Chair of Network Architectures and Services Department of Informatics Technical University of Munich

Transcript of Achieving Reproducible Network Environments with INSALATA

Chair of Network Architectures and ServicesDepartment of InformaticsTechnical University of Munich

Achieving Reproducible Network Environments with INSALATA

Nadine Herold, Matthias Wachs, Marko Dorfhuber, Cristoph Rudolf, Stefan Liebald, GeorgCarle

Tuesday 11th July, 2017

Chair of Network Architectures and ServicesDepartment of Informatics

Technical University of Munich

Chair of Network Architectures and ServicesDepartment of InformaticsTechnical University of Munich

Motivation

Requirements and Related Work

INSALATA Architecture

Case Study: iLab

Conclusion and Future Work

Literature

S. Liebald — INSALATA 1

Motivation

Why do we want reproducible network environments?

• Requirement for reproducible experiments• e.g. from other testbeds

• Test changes before deployment in operational network• Routing• Software updates• Firewall rules• Configuration changes• . . .

S. Liebald — INSALATA 2

Motivation

Why do we want reproducible network environments?

• Requirement for reproducible experiments• e.g. from other testbeds

• Test changes before deployment in operational network• Routing• Software updates• Firewall rules• Configuration changes• . . .

S. Liebald — INSALATA 2

Motivation

Why do we want reproducible network environments?

• Requirement for reproducible experiments• e.g. from other testbeds

• Test changes before deployment in operational network• Routing• Software updates• Firewall rules• Configuration changes• . . .

S. Liebald — INSALATA 2

Our Solution: INSALATA

Manual replication:

• Error prone, time consuming• Keeping it up-to-date is hard• Multitude of Tools/Software used manually

The goal:

• Automate complete replication process• Scan an environment and deploy it on a testbed

Our Framework: IT NetworkS AnaLysis And deploymenT Application (INSALATA)

• Network information model• Information collection component• Infrastructure deployment component

S. Liebald — INSALATA 3

Our Solution: INSALATA

Manual replication:

• Error prone, time consuming• Keeping it up-to-date is hard• Multitude of Tools/Software used manually

The goal:

• Automate complete replication process• Scan an environment and deploy it on a testbed

Our Framework: IT NetworkS AnaLysis And deploymenT Application (INSALATA)

• Network information model• Information collection component• Infrastructure deployment component

S. Liebald — INSALATA 3

Our Solution: INSALATA

Manual replication:

• Error prone, time consuming• Keeping it up-to-date is hard• Multitude of Tools/Software used manually

The goal:

• Automate complete replication process• Scan an environment and deploy it on a testbed

Our Framework: IT NetworkS AnaLysis And deploymenT Application (INSALATA)

• Network information model• Information collection component• Infrastructure deployment component

S. Liebald — INSALATA 3

Requirements and Related WorkInformation ModelRequirements and Related Work

Requirements IF-M

AP[1

, 20,

21]

IDS

Ont

olog

y[2

2]IN

DL

[18,

10, 8

]N

ML

[24,

23]

R1: Network components 3 3 3 3

R2: Connections 3 3 3 3

R3: Addressing 3 7 7 7

R4: Reachability of components 7 7 7 7

R5: Network services 3 3 3 7

R6: Hardware information 3 7 3 7

R7: Extensibility of information elements 3 3 3 3

R8: History 7 7 7 3

3 fulfilled, 7 not fulfilled

S. Liebald — INSALATA 4

Requirements and Related WorkInformation Collection ComponentRequirements and Related Work

Requirements IO-F

ram

ewor

k[4

, 12]

cNIS

[9]

Mon

ALIS

A[6

, 5]

PerfS

ON

AR[1

9]O

penV

AS[1

6]N

map

[13,

14]

R1: Configurability 7 3 3 3 3 3

R2: Collection of required topoloy information 3 7 3 7 7 7

R3: Extensible modules 3 3 3 3 3 3

R4: Periodical information collection 7 3 3 3 3 7

R5: Adaptable intervals 7 7 7 3 3 7

R6: Continuous monitoring 7 3 7 7 7 7

R7: Multiple environments 7 7 3 3 3 7

R8: Extensible export 7 3 7 7 7 7

3 fulfilled, 7 not fulfilled

S. Liebald — INSALATA 5

Requirements and Related WorkInfrastructure Deployment ComponentRequirements and Related Work

Requirements Laas

Net

Exp

[17]

vBET

[11]

Balti

kum

Test

bed

NEP

TUN

E[3

]Al

goriz

mi [

2]Em

ulab

[25]

R1: Basic network components 7 3 7 7 7 3

R2: Description language for configuration ? 3 3 3 3 3

R3: Virtual and physical components 7 7 3 7 7 3

R4: Software independent design ? ? 7 3 7 7

R5: Public availability 7 7 3 3 3 3

R6: Separated and persistent components 3 7 3 3 3 3

R7: Multiple users per testbed 3 7 7 7 3 3

R8: Common usage of central components 3 3 7 3 7 7

R9: Incremental Changes 7 7 7 7 7 7

3 fulfilled, 7 not fulfilled, ? insufficient informationS. Liebald — INSALATA 6

Architecture: Overview

Management Unit

Pre-

processor

upload

User

virtual

physical

Collector Setup

Database

loadstore

import apply

scan deploy/change

S. Liebald — INSALATA 7

Architecture: Information Model

1use0..*

1..*

in1

1..*

contains1..*

1

use

0..*

1

use

0..*

1

has

0..*0..*

in 1

0..*1

0..*

connected to 0..1

0..*0..1 0..*1

0..*hop 1

0..*

start 1

0..*

end 1

0..*

destNet1

0..*

srcNet1

0..*

interface 1

0..*

hop1

0..*

interface1

0..* 1

NetworkComponent

id : String

cpus : IntegercpuSpeed : IntegermemoryMin : IntegermemoryMax : IntegerpowerState : Stringtemplate : String

Disk

id : String

size : Integer

Interface

mac: String

rate : Integermtu : Integer

Layer2Network

id : String

Location

id : String

Layer3Address

address : String

netmask : Stringgateway : Stringstatic : Boolean

Route

genmask : Stringmetric : Integer

FirewallRule

chain : Stringaction : Stringprotocol : StringsrcPorts : listdestPorts : list

Layer3Network

address : String

netmask : String

FirewallRaw

firewall : String

data : String

Service

port : Integer

type : Stringprotocol : Stringproduct : Stringversion : String

DnsService

domain : String

DhcpService

lease : Integer

connected to configured on running on

destination

S. Liebald — INSALATA 8

Architecture: Information Collection Component

Management Unit

Pre-

processor

upload

User

virtual

physical

Collector Setup

Database

loadstore

import apply

scan deploy/change

S. Liebald — INSALATA 9

Architecture: Information Collection Component

Management Unit

.ini

Env1.ini

Mod1,2Mod1,1 Mod1,3

Net1

Env2 .ini

Mod2,1 Mod2,2

Net2

Collector

S. Liebald — INSALATA 10

Architecture: Information Collection Component

Approaches for Information Collection

Manua

l (xml)

Passiv

e scan

s (tcpd

ump)

Active

scan

s (NMAP)

proto

col b

ased

(SNMP)

Direct

acce

ss(ss

h)

Client

softw

are (Z

abbix

)

Network traffic overhead o o ++ + + +Client software o o o + + ++Direct access o + o o ++ +Reliability + ++ + ++ ++ ++Topicality o o + + + ++Information variety o + + + ++ ++Information updatability + o ++ ++ ++ ++

S. Liebald — INSALATA 11

Architecture: Infrastructure Deployment Tool

Management Unit

Pre-

processor

upload

User

virtual

physical

Collector Setup

Database

loadstore

import apply

scan deploy/change

S. Liebald — INSALATA 12

Architecture: Infrastructure Deployment Tool

Deployment Process

ConfigPre-

processor

Configuration

c1

CollectorConfiguration

c2

Change

detection

Planning

Problem

parserProblem

PlannerDomain

PlanBuilder

Builder

module n

Builder

module 1

... uses

Testbedbuilds

scans

S. Liebald — INSALATA 13

Case Study: iLabPhysical setup

Cisco-Router 1

Linux-Router

Cisco-Router 2

Switch

PC1 PC2 PC3 PC4

eth0 10.0.1.254/24eth0 10.0.2.254/24

eth0 10.0.3.254/24

eth0 10.0.1.1/24 eth0 10.0.1.2/24 eth0 10.0.2.1/24 eth0 10.0.3.1/24

eth2 10.0.6.1/24 eth2 10.0.6.2/24

eth1 10.0.4.1/24 eth1 10.0.5.2/24

eth2 10.0.4.1/24 eth1 10.0.5.1/24

S. Liebald — INSALATA 14

Case Study: iLabDeployment Phase

• Execution plan computed in <1 second• 92 steps• Contains: setup of virtual machines, networks, interfaces, routes,...

• Setup in our virtual testbed took ~42 minutes• Our builder modules utilize the XEN xapi toolstack• Most of the time required to clone the virtual machines and hard disk images

• Validation of setup in the testbed using the ping and traceroute tools

S. Liebald — INSALATA 15

Conclusion and Future Work

• Conclusion:• Automated scanning and deployment of network environments can be done• Modularisation of such a tool is beneficial

• Contribution:• Extensible framework for reproducible network setups• Applicable for virtual/physical/mixed environments• Incremental deployment process• Multiple collector/builder implementations• Case studie as prove of applicability

• Future Work:• Implement additional collector/builder modules• Parallelize the deployment process• Include experiment execution

S. Liebald — INSALATA 16

Conclusion and Future Work

• Conclusion:• Automated scanning and deployment of network environments can be done• Modularisation of such a tool is beneficial

• Contribution:• Extensible framework for reproducible network setups• Applicable for virtual/physical/mixed environments• Incremental deployment process• Multiple collector/builder implementations• Case studie as prove of applicability

• Future Work:• Implement additional collector/builder modules• Parallelize the deployment process• Include experiment execution

S. Liebald — INSALATA 16

Conclusion and Future Work

• Conclusion:• Automated scanning and deployment of network environments can be done• Modularisation of such a tool is beneficial

• Contribution:• Extensible framework for reproducible network setups• Applicable for virtual/physical/mixed environments• Incremental deployment process• Multiple collector/builder implementations• Case studie as prove of applicability

• Future Work:• Implement additional collector/builder modules• Parallelize the deployment process• Include experiment execution

S. Liebald — INSALATA 16

Literature

[1] V. Ahlers, F. Heine, B. Hellmann, C. Kleiner, L. Renners, T. Rossow, and R. Steuerwald.Integrated Visualization of Network Security Metadata from Heterogeneous Data Sources.In S. Mauw, B. Kordy, and S. Jajodia, editors, Graphical Models for Security: Second International Workshop (GraMSec),pages 18–34, 2016.

[2] K. Ali.Algorizmi: A configurable virtual testbed to generate datasets for offline evaluation of Intrusion Detection Systems.Master’s thesis, University of Waterloo, 2010.

[3] R. Bifulco, G. D. Stasi, and R. Canonico.NEPTUNE for fast and easy deployment of OMF virtual network testbeds [Poster Abstract].2010.

[4] H. Birkholz, I. Sieverdingbeck, K. Sohr, and C. Bormann.IO: An Interconnected Asset Ontology in Support of Risk Management Processes.In Availability, Reliability and Security (ARES), 7th International Conference on, pages 534–541, 2012.

[5] A. Carpen-Amarie, J. Cai, A. Costan, G. Antoniu, and L. Bougé.Bringing Introspection Into the BlobSeer Data-Management System Using the MonALISA Distributed Monitoring Frame-work.In Complex, Intelligent and Software Intensive Systems (CISIS), International Conference on, pages 508–513, 2010.

[6] C. Dobre, R. Voicu, and I. Legrand.Monitoring large scale network topologies.In Intelligent Data Acquisition and Advanced Computing Systems (IDAACS), IEEE 6th International Conference on, vol-ume 1, pages 218–222, 2011.

[7] M. Fox and D. Long.PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains.J. Artif. Int. Res., 20(1):61–124, 2003.

S. Liebald — INSALATA 17

Literature

[8] M. Ghijsen, J. van der Ham, P. Grosso, C. Dumitru, H. Zhu, Z. Zhao, and C. de Laat.A semantic-web approach for modeling computing infrastructures.Computers & Electrical Engineering, 39(8):2553 – 2565, 2013.

[9] GÉANT.GEANT2 common Network Information Service (cNIS) Schema Specification, http://www.geant2.net.

[10] Jeroen Johannes van der Ham.A Semantic Model for Complex Computer Networks: The Network Description Language.PhD thesis, University of Amsterdam, 2010.

[11] X. Jiang and D. Xu.vBET: A VM-based Emulation Testbed.In Proceedings of the ACM SIGCOMM Workshop on Models, Methods and Tools for Reproducible Network Research,pages 95–104, 2003.

[12] L. Lorenzin and N. Cam-Winget.Security Automation and Continuous Monitoring (SACM) Requirements.Internet-Draft draft-ietf-sacm-requirements-15, Internet Engineering Task Force, 2016.

[13] G. Lyon.The Offical Nmap Project Guide to Network Discovery and Securtiy Scanning.2009.

[14] G. Lyon.nmap(1) – Linux man page, 2015.

[15] D. McDermott, M. Ghallab, A. Howe, C. Knoblock, A. Ram, M. Veloso, D. Weld, and D. Wilkins.PDDL – The Planning Domain Definition Language.1998.

S. Liebald — INSALATA 18

Literature[16] OpenVAS.

Project Homepage http://www.openvas.org.

[17] P. Owezarski, P. Berthou, Y. Labit, and D. Gauchard.LaasNetExp: A Generic Polymorphic Platform for Network Emulation and Experiments.In Proceedings of the 4th International Conference on Testbeds and Research Infrastructures for the Development ofNetworks & Communities, number 24, pages 1–9, 2008.

[18] T. Taketa and Y. Hiranaka.Network Design Assistant System based on Network Description Language.In Advanced Communication Technology (ICACT), 15th International Conference on, pages 515–518, 2013.

[19] B. Tierney, J. Metzger, J. Boote, E. Boyd, A. Brown, R. Carlson, M. Zekauskas, J. Zurawski, M. Swany, and M. Grigoriev.perfSONAR: Instantiating a Global Network Measurement Framework.In In SOSP Workshop on Real Overlays and Distributed Systems (ROADS09). ACM, 2009.

[20] Trusted Network Connect Work Group.TNC IF-MAP Bindings for SOAP, Version 2.2, Revision 10, 2014.

[21] Trusted Network Connect Work Group.TNC MAP Content Authorization, Version 1.0, Revision 36, 2014.

[22] J. Undercoffer, J. Pinkston, A. Joshi, and T. Finin.A Target-Centric Ontology for Intrusion Detection.In Proceding of the 9th Workshop on Ontologies and Distributed Systems, pages 47–58, 2004.

[23] J. van der Ham, F. Dijkstra, R. Lapacz, and A. Brown.The Network Markup Language (NML): A Standardized Network Topology Abstraction for Inter-domain and Cross-layerNetwork Applications, 2013.

[24] J. van der Ham, F. Dijkstra, R. Łapacz, and J. Zurawski.Network Markup Language Base Schema version 1, 2013.

S. Liebald — INSALATA 19

Literature

[25] B. White, J. Lepreau, L. Stoller, R. Ricci, S. Guruprasad, M. Newbold, M. Hibler, C. Barb, and A. Joglekar.An Integrated Experimental Environment for Distributed Systems and Networks.pages 255–270, 2002.

S. Liebald — INSALATA 20

Change Detection

networks:I net-1I net-2

hosts:I router-1

• interfaces:– eth0: 10.10.1.254/24– eth1: 10.10.2.1/24

I host-1• interfaces:

– eth0: 10.10.1.1/24

Change

detection

networks:I net-1I net-2

hosts:I router-1

• interfaces:– eth0: 10.10.1.254/24– eth1: 10.10.2.254/24

I host-1• interfaces:

– eth0: 10.10.1.1/24I host-2

• interfaces:– eth0: 10.10.2.1/24

The change detection marks router-1.eth1.ip as changed and host-2 as new.

S. Liebald — INSALATA 21

Planning

• Based on the input, the planner creates a deployment plan• Currently the Planning Domain Definition Language (PDDL [15, 7]) is used

• Domain description: describes the problem domain, static• Describes object types, predicates, actions• Actions apply to objects, have preconditions and have an effect• Provided with INSALATA for our information model

• Problem description: describes the instance of the domain• Depends on current/desired state

• Output is given to the Builder which chooses fitting builder modules to realize the deploy-ment

S. Liebald — INSALATA 22

Planning Example

+ DNS/DHCP

+ DNS/DHCP

+ DNS/DHCP/Firewall

+ DNS/DHCP

+ DNS/DHCP

7

S. Liebald — INSALATA 23

Planning Example

+ DNS/DHCP

+ DNS/DHCP

+ DNS/DHCP/Firewall

+ DNS/DHCP

+ DNS/DHCP

7

S. Liebald — INSALATA 23

Planning example

new• router-3

changed• router-1.firewall• router-1.routing• router-2.routing• host-3.eth0

removed• host-4• host-4-hdd

1. (createhost router-3)2. (configurefirewall router-1)3. (configurerouting router-1)4. (configurerouting router-2)5. (createnetwork net-3)6. (shutdown host-4)7. (removehost host-4)8. (removedisk host-4-hdd host-4)9. (createinterface router-3.eth0)10. (createinterface router-3.eth1)11. (bootunnamed router-3)12. (configureinterface router-3.eth0)13. (configureinterface router-3.eth1)14. (configurerouting router-3)15. (name router-3)16. (rebootandnamed router-3)17. (shutdown host-3)18. (configurenetwork host-3.eth0)19. (boot host-3)20. (configuredhcp 172.16.246.1:67_udp_dhcp)21. (configuredns 172.16.246.1:53_udp_dns)

S. Liebald — INSALATA 24

Planning example

new• router-3

changed• router-1.firewall• router-1.routing• router-2.routing• host-3.eth0

removed• host-4• host-4-hdd

1. (createhost router-3)2. (configurefirewall router-1)3. (configurerouting router-1)4. (configurerouting router-2)5. (createnetwork net-3)6. (shutdown host-4)7. (removehost host-4)8. (removedisk host-4-hdd host-4)9. (createinterface router-3.eth0)10. (createinterface router-3.eth1)11. (bootunnamed router-3)12. (configureinterface router-3.eth0)13. (configureinterface router-3.eth1)14. (configurerouting router-3)15. (name router-3)16. (rebootandnamed router-3)17. (shutdown host-3)18. (configurenetwork host-3.eth0)19. (boot host-3)20. (configuredhcp 172.16.246.1:67_udp_dhcp)21. (configuredns 172.16.246.1:53_udp_dns)

S. Liebald — INSALATA 24

Planning example

new• router-3

changed• router-1.firewall• router-1.routing• router-2.routing• host-3.eth0

removed• host-4• host-4-hdd

1. (createhost router-3)2. (configurefirewall router-1)3. (configurerouting router-1)4. (configurerouting router-2)5. (createnetwork net-3)6. (shutdown host-4)7. (removehost host-4)8. (removedisk host-4-hdd host-4)9. (createinterface router-3.eth0)10. (createinterface router-3.eth1)11. (bootunnamed router-3)12. (configureinterface router-3.eth0)13. (configureinterface router-3.eth1)14. (configurerouting router-3)15. (name router-3)16. (rebootandnamed router-3)17. (shutdown host-3)18. (configurenetwork host-3.eth0)19. (boot host-3)20. (configuredhcp 172.16.246.1:67_udp_dhcp)21. (configuredns 172.16.246.1:53_udp_dns)

S. Liebald — INSALATA 24

Planning example

new• router-3

changed• router-1.firewall• router-1.routing• router-2.routing• host-3.eth0

removed• host-4• host-4-hdd

1. (createhost router-3)2. (configurefirewall router-1)3. (configurerouting router-1)4. (configurerouting router-2)5. (createnetwork net-3)6. (shutdown host-4)7. (removehost host-4)8. (removedisk host-4-hdd host-4)9. (createinterface router-3.eth0)10. (createinterface router-3.eth1)11. (bootunnamed router-3)12. (configureinterface router-3.eth0)13. (configureinterface router-3.eth1)14. (configurerouting router-3)15. (name router-3)16. (rebootandnamed router-3)17. (shutdown host-3)18. (configurenetwork host-3.eth0)19. (boot host-3)20. (configuredhcp 172.16.246.1:67_udp_dhcp)21. (configuredns 172.16.246.1:53_udp_dns)

S. Liebald — INSALATA 24

Intrusiveness of Information Collection

Manual

Passive Network Scanning

Active Network Scanning

Protocols

Direct Access

Agent-based

Intrusiveness

S. Liebald — INSALATA 25

Quality of Information Depending on Collection Method

Manual

Passive Network Scanning

Active Network Scanning

Protocols

Direct Access

Agent-based

Quality of Information

S. Liebald — INSALATA 26