Validation of Security Design by Modeling and Simulation

University of Southern Queensland
Faculty of Health, Engineering and Sciences
Validation of security design by modeling and simulation
A dissertation submitted by
Ankit Patel
in fulfilment of the requirements of
MSC8002 Research Project Dissertation
towards the degree of
Master of Computing Technology
Submitted: November, 2018

ii
Abstract
The main purpose of this project is to model and simulate a network security model.
Three main network security problems such as a firewall filtering rules validation, an
application-based filtering, and an SSL/TLS surveillance have been taken as an example
to solve by modeling and simulation. Literature about three example problems have
been reviewed. Literature about stateful inspection has also been reviewed in a separate
chapter. As a solution of first example problem(firewall filtering rules validation), tools
to validate filtering rules been identified and methods to validate filtering rules have
been discussed. Second example problem(Application-based filtering) has been solved
taking Google’s BeyondCorp concept as a reference. New SSL/TLS surveillance model
has been proposed as a solution to the third example problem. Each example problems
have been solved by modeling and simulation.
University of Southern Queensland
School of Agricultural, Computational and Environmental Sciences
MSC8001/2 Research Project
Limitations of Use
The Council of the University of Southern Queensland, its Faculty of Health, Engineer-
ing and Sciences, and the staff of the University of Southern Queensland, do not accept
any responsibility for the truth, accuracy or completeness of material contained within
or associated with this dissertation.
Persons using all or any part of this material do so at their own risk, and not at the
risk of the Council of the University of Southern Queensland, its Faculty of Health,
Engineering and Sciences or the staff of the University of Southern Queensland.
This dissertation reports an educational exercise and has no purpose or validity beyond
this exercise. The sole purpose of the course pair entitled “Research Project” is to
contribute to the overall education within the student’s chosen degree program. This
document, the associated hardware, software, drawings, and other material set out in
the associated appendices should not be used for any other purpose: if they are so used,
it is entirely at the risk of the user.
Dean
Faculty of Health, Engineering and Sciences
iv
Acknowledgement
I am grateful to Dr. Ron Addie for providing technical support in the whole project,
without him I might not able to make this project. I like to thank Mr. Toran Matherson
for providing technical detail of a real network of a university.
I like to thank Dr. Xiaohui Tao for providing professional formatting tips for this
project. He has a major contribution for formatting, without him, I would not able to
make this document professionally. I also like the contribution of Dr. Ron Addie for
technical error-free writing tips.
I am also grateful to my family members and friends for their mental support through-
out whole project and special thank to my fellow student friends for their feedback,
cooperation and of course friendship.
I also like to thank www.stakexchange.com platform which provides an answer to any

technical question recorded in their database which I am not able to refer in this
document.
Contents
List of Figures x
List of Tables xiv
Chapter 1 Introduction 1
1.1 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Firewall filtering rules validation . . . . . . . . . . . . . . . . . . 1
1.1.2 Application-based filtering . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 SSL/TLS surveillance . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2 Background and literature 4
2.1 History of network security . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Rise of Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Types of firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

CONTENTS vi
2.2.3 Packet filtering firewalls . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Need for validation of filtering rules . . . . . . . . . . . . . . . . . . . . . 6
2.4 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Tools to validate security rules . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.1 Netml/Ns3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.2 IP tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.3 Packet Tracer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5.4 Gns3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.5 Comparison between Packet Tracer and Gns3 . . . . . . . . . . . 10
2.6 Other tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 Access control engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 SSL/TLS filtration/surveillance . . . . . . . . . . . . . . . . . . . . . . . 12
2.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 3 Modeling of filtering rules by Netml 14
3.1 Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Connect nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Edit parameters of links . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3 Link labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.4 Add filtering rules on node . . . . . . . . . . . . . . . . . . . . . 17
3.1.5 Add traffic streams . . . . . . . . . . . . . . . . . . . . . . . . . . 24

CONTENTS vii
3.1.6 Traffic stream parameters . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Limitations of Netml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Reason for limitations in Netml . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapter 4 Stateful inspection in firewalls 31
4.1 Statefulness by Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1 Established keyword . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2 Reflexive ACL(Access control list) . . . . . . . . . . . . . . . . . 33
4.1.3 CBAC(Context-Based Access Controls) . . . . . . . . . . . . . . 34
4.2 Zone-based firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 5 Modeling of filtering rules in Gns3 39
5.1 Filtering rules validation experiment . . . . . . . . . . . . . . . . . . . . 39
5.1.1 Router configuration . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1.2 Apply access-list on the interface . . . . . . . . . . . . . . . . . . 41
5.1.3 PC-1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.4 PC-2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.5 Traffic generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.6 Verification of rules . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
CONTENTS viii
Chapter 6 Toward BeyondCorp: a new network security model 46
6.1 Adopt BeyondCorp concept in traditional network . . . . . . . . . . . . 48
6.1.1 Make all applications publicly available . . . . . . . . . . . . . . 48
6.1.2 Access-control engine . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 New network security models . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3 Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Chapter 7 A new SSL/TLS surveillance model 56
7.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2.1 Components of the new model . . . . . . . . . . . . . . . . . . . 57
7.2.2 Proposed model . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2.3 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3 Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Chapter 8 Conclusion 61
References 63
Appendix A Setup Gns3 70
A.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.2 Linking Gns3 VM to Gns3 . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.3 Add Cisco routers in Gns3 . . . . . . . . . . . . . . . . . . . . . . . . . . 71

CONTENTS ix
Appendix B Connect host PC to Gns3 73
B.1 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
List of Figures
2.1 Gns3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Advanced ping command in VPCS . . . . . . . . . . . . . . . . . . . . . 9
3.1 control panel in Netml . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Drag and drop nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Add duplex links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 ns3 parameters for all selected links . . . . . . . . . . . . . . . . . . . . . 16
3.5 Set unique BaseAddress for all selected links by checking CheckBox next
to BaseAddress field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6 Set links label as BaseAddress . . . . . . . . . . . . . . . . . . . . . . . . 18
3.7 Link label set to BaseAddress . . . . . . . . . . . . . . . . . . . . . . . . 18
3.8 Choose to Create/edit firewall/Click router . . . . . . . . . . . . . . . . 19
3.9 Firewall IPTables Rulesets window . . . . . . . . . . . . . . . . . . . . . 20
3.10 Specify IP Table window . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.11 IP table created in Firewall IPTables Rulesets window. . . . . . . . . . . 21

LIST OF FIGURES xi
3.12 Specify IP Chain window . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.13 IP rule chain added to the Firewall IPTables Rulesets . . . . . . . . . . 22
3.14 IP Table Rule window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.15 IP rules moved around in large space . . . . . . . . . . . . . . . . . . . . 24
3.16 Traffic streams added . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.17 Traffic stream parameters edited . . . . . . . . . . . . . . . . . . . . . . 26
3.18 Simulate network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.19 ns3 simulation window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.20 Traffic analysis after applying rules according to Table 3.1 . . . . . . . . 27
3.21 Output traces without filtering rules . . . . . . . . . . . . . . . . . . . . 28
4.1 Stateful inspection process . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 CBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Stateful inspection commands on Cisco router . . . . . . . . . . . . . . . 35
4.4 Filtering rule to deny all traffic . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Apply access-list on interface s0 . . . . . . . . . . . . . . . . . . . . . . . 35
4.6 Apply stateful inspection on interface Ethernet0 . . . . . . . . . . . . . 36
4.7 Zone based firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8 Option 1: Configuration without stateful inspection . . . . . . . . . . . 37
4.9 Option 2: Configuration with stateful inspection . . . . . . . . . . . . . 38

LIST OF FIGURES xii
5.1 Topology in Gns3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Router configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 Commands to configure sample filtering rules . . . . . . . . . . . . . . . 41
5.4 Apply access-list on the particular interface in a particular direction . . 41
5.5 PC1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.6 PC1 configuration command . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.7 PC2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.8 PC2 configuration command . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.9 Advance ping command format . . . . . . . . . . . . . . . . . . . . . . . 43
5.10 Command to validate rule 1 from Table 3.1 . . . . . . . . . . . . . . . . 43
5.13 Command to see log buffer on the router . . . . . . . . . . . . . . . . . . 44
5.14 Command to validate rule 1 . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.15 Router console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.16 Command to view log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.17 Log buffer for rule 1 from Table 3.1 . . . . . . . . . . . . . . . . . . . . . 45
6.1 BeyondCorp Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2 Traditional Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3 Model A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
LIST OF FIGURES xiii
6.4 Model B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.5 Model C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.6 Access-control engine in DMZ used to filter all traffic . . . . . . . . . . 53
6.7 Separate Access-control engine in DMZ for filtering connection from “in-
side zone to outside zone” and from “outside zone to DMZ” . . . . . . 54
6.8 Access-control engine in inside zone with placement Model B . . . . . . 54
6.9 Access-control engine placement Model C in inside zone . . . . . . . . . 55
7.1 New model for SSL/TLS Surveillance . . . . . . . . . . . . . . . . . . . 58
7.2 SSL/TLS Surveillance model in action . . . . . . . . . . . . . . . . . . . 60
A.1 Link Gns3 VM to Gns3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.1 Host PC connected to a router . . . . . . . . . . . . . . . . . . . . . . . 74
B.2 Host PC connected to a router . . . . . . . . . . . . . . . . . . . . . . . 74

List of Tables
2.1 Comparision between Packet Tracer and Gns3 . . . . . . . . . . . . . . . 11
3.1 Filtering Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Rule to allow reverse traffic . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Traffic stream parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Firewall with stateful inspection by the different vendors . . . . . . . . . 32

Chapter 1
Introduction
Currently, cyber-attacks are increasing rapidly. Information theft and security breaches
continue to feature in news reports regularly. More than 75% of Australians have been
a victim of information theft[20]. From 2000, cyber-crime started to be treated as a
crime[37]. The most networks have security weaknesses.
1.1 Problems
A network security can be designed by modeling and simulation. Modeling and simula-
tion could help to validate the network security as well. In this project, three network
security problems have been taken as examples such as a firewall filtering rules valida-
tion, an application-based filtering, and an SSL/TLS surveillance. All these example
problems have been solved by modeling and simulation.
1.1.1 Firewall filtering rules validation
Validation of firewall filtering rules is a very important. If firewall filtering rules are not
validated then access which should be blocked may be allowed and access which should
be allowed may be blocked. Simulation tools such as Netml, Gns3, Packet Tracer can
validate filtering rules. Different vendors have a different implementation of access
1.1 Problems 2
management. Some vendor supports stateful inspection in firewall and some do not.
Understanding of Stateful inspection is necessary which is discussed in Chapter 4 as
part of a literature review. Literature about different simulation has been reviewed in
Chapter 2. Netml and Gns3 have been chosen as a validation tool for firewall filtering
rules and methods for validating firewall filtering rules by both of them have been
discussed in separate Chapters 3 and 5. As an outcome, firewall filtering rules have
been validated by Netml and Gns3.
1.1.2 Application-based filtering
Traditional firewalls in networks do not support application-based filtering[54]. They

support IP and port based filtering. In this type of scenario, if certain IP is allowed to
access certain service then an attacker can compromise that device and gain access to
particular service which is accessible by that device IP. To solve this problem, Google
has adopted a new network security model called BeyomdCorp. BeyondCorp model
uses application level filtering using access-proxy. In this document, the transition
model for the traditional network to new secure model using application level filtering
has been proposed. A new model uses the Access-control engine for application level
filtering. Different placement model of the Access-control engine and services provided
by the Access-control engine have been discussed in Chapter 6. Chapter 6 also dis-
cusses how we can make our traditional network same as BeyondCorp network without
removing any device but instead adding an Access-control engine in the different zone
in different location. As an outcome, different network models have been proposed for
different requirements to support application-based filtering in the traditional network
in Chapter 6.
1.1.3 SSL/TLS surveillance
SSL/TLS has been invented to provide security in communication. A user gets con-
fidentiality using SSL/TLS. But services provided by SSL/TLS does not differenciate
legitimate user and attacker. Attacker can send malicious code using SSL/TLS which
cannot be surveilled by anyone, or people can do communication over SSL/TLS which
1.2 Summary 3
is related to terrorism, cannot be read by surveillant. SSL/TLS proxy [6][47] exists to
do content filtering of SSL/TLS encrypted traffic. But there does not exist protocol
to surveil SSL/TLS traffic. In surveillance, the main goal is to read, manipulate and
monitor traffic rather than block traffic if it contains predefined keywords. In this doc-
ument, in Chapter 7, model to surveil SSL/TLS traffic has been proposed which can
solve the problem of SSL/TLS traffic surveillance.
1.2 Summary
Chapter 1, discusses the overall goal of this document in detail. Chapter 2, discusses
literature regarding this project. Chapter 4, discusses Stateful inspection which is just
informative rather than creative where cisco’s products and features toward stateful
inspection have been described. Different vendors who make the firewall with state-
ful inspection have been listed with vendor names and their firewall product name.
Chapter 3, describes methods to validate firewall filtering rules by Netml. All steps
with diagrammatic presentation have been presented. Chapter 5, describes methods
to validate firewall filtering rules by Gns3. In this chapter, Gns3 setup is required.
Appendix A and B describe how we can setup Gns3 and how we can connect host
device to Gns3 topology. A new application-based network security model has been
proposed in Chapter 6. Finally, in Chapter 7, a new model and protocol for SSL/TLS
surveillance have been proposed.
Chapter 2
Background and literature
2.1 History of network security
Network security caught concern a long time ago after first digital Telegram network[?].
ARPA(Advanced Research Projects Agency) funded ARPANET in the 1960s which
was the network to connect computers of research institutes funded by the US Dept
of Defence over telephone lines[22]. The network was initially small in terms of the
number of switches and the number of connected nodes, and people able to use it. So,
security was ignored at that time[46]. By the late 80s, more organizations connected
to ARPANET such as military, government, universities, etc. ARPANET was further
developed, including changes to the protocols, and evolved to become the Internet. A
student from Cornell University developed the first virus called Morris Worm which
spread to all computers connected to ARPANET and infected all computers and it was
self-replicating, i.e. making its own copy when it infects any computer and propagates
to another node. This made clear the need for network security in ARPANET[11]. In
response to attacks on ARPANET, CERT (Computer Emergency Response Team) was
developed in 1988[46]. CERT was the first or one of the first organizations to address
network security in the Internet.
2.2 Firewall 5
2.2 Firewall
2.2.1 Rise of Firewall
Before 1988, the word firewall was used to refer to a wall designed to inhibit the
development of the fire in a building. But in 1988, NASA also experienced a virus
attack and that lead a team at NASA to develop the firewall concept to secure their
computers[46]. Anti-virus software was also invented at approximately that time to find
and eradicate malicious software[11]. The principal function of a firewall is to protect
the interior of a network from external threats[44].
2.2.2 Types of firewall
There are different types of firewalls in networks such as Packet Filtering Firewalls, Cir-
cuit Level Gateway Firewalls, Application level Gateway Firewalls, Stateful Multilayer
Inspection Firewalls[51], [44], [32], [45], [43].
2.2.3 Packet filtering firewalls
These firewalls filter traffic on the basis of:
• Source address,
• Destination address
• Type of protocol
• Port number
of the client that has placed the request. Packets that match in the filtering rule to
be permitted, will be permitted, other packets will be denied, if the default action of
filtering rule chain is set to deny but if default action is set to accept then it will be
accepted[45].
2.3 Need for validation of filtering rules 6
2.3 Need for validation of filtering rules
If there are many filtering rules in Packet Filtering firewall then it will be hard to
evaluate the output of those rules. Those rules should be tested by some simulation
tool before implementing them on real firewall. Otherwise, access which should be
blocked might be allowed and access which should be allowed will be blocked[27].
2.4 Solution
Physical laboratories[38] and simulation tools[28] can help to validate filtering rules.
But at some point, the physical laboratories will not be chosen by considering the
setup and maintenance cost[38].
2.5 Tools to validate security rules
2.5.1 Netml/Ns3
Netml is a simulation tool for networking[4] developed by Dr. Ron Addie. It differs
from different networking tools such as OPNET, NPAT, NS2, and OMNeT++. A key
advantage of Netml is the ability to display, edit, and apply tools to networks in a
browser[4]. The report[2] explains different tools which are used in Netml system to
create networks. In Netml, XML is used to represent the design of a network, and this
is then used to generate any other representation which is useful, including diagrams,
and simulation code[4].
2.5.2 IP tables
IP Tables is open source software for implementing firewalls under Unix[10]. The
report[10] is a manual for how to use IP Tables including basic commands and exam-
ples. The Netml system includes a facility modeled on IP Tables[3]. This feature is
2.5 Tools to validate security rules 7
implemented by means of Click and ns3, rather than IP Tables itself, and it enables
networks which include a subset of IP Tables features, in a node, to be simulated.
The report[3] has simulated network in Netml with Firewall having filtering rules and
they have shown how fitering rules can be validated by Netml by generating traces.
We can visually see which traffic stream has been blocked and which traffic stream has
been passed through by simulating networks with firewall in Netml/Ns3[3]. A product
should be tested by more than one testing methods for a better accurate analysis[30].
Information collected from the different literature regarding Netml is used in Chapter
5 to show the whole method to validate filtering rules by Netml.
2.5.3 Packet Tracer
Packet Tracer can be used to simulate networking devices such as routers, switches,
hosts, servers, firewalls, etc. It is also used to test combinations of network protocols.
Many institutes use this tool for teaching students networking protocols. It can simulate
a variety of devices, but it supports Cisco IOS only[29].
How to use
The report[29] has described the different feature of Packet Tracer with detailed infor-
mation. They have described the packet tracing feature of Packet Tracer where the
user can trace the packet in simulation mode which is very important to validate any
protocol. The report[1] has described all feature provided by Packet Tracer in his book
named Packet Tracer Network Simulator which is good for the new user to start with
Packet Tracer.
Configure access rules in Packet Tracer
The report[13] describes what access list is and how to configure it in Cisco networking
devices. It also describes different types of command to configure access list. The
report[40] is manual for configuring both types of access list such as standard and
extended on Cisco IOS.
Validate filtering rules
Access rules can be validated in Packet Tracer by using complex PDU feature of Packet
Tracer which can generate custom traffic according to our requirements and another
way is to read log messages in firewall[21]. But if traffic is generated using custom
traffic generator provided in default host then filtering rules can be validated by tracing
packets in simulation mode[1][7]. Packet tracer has some limitations as general which
do not affect validation of filtering rules[16][24]. Custom packet generator in Packet
Tracer generates many types of traffic such as PING, FINGER, FTP, etc[1][7].
2.5.4 Gns3
Purpose of Gns3 is same as Packet Tracer. But, Gns3 supports 20 different vendors
and it can connect existing physical device to virtual topology created in Gns3. It runs
the original IOS of network devices[49]. Figure 2.1 is how Gns3 looks like.
Figure 2.1: Gns3
The report[8] describes different toolbars of Gns3 and how to start making topologies in
Gns3 by downloading the original IOS of the Cisco router. The report[26] describes the
VPCS[1]\> ping
ping address [options], Ping the network host,

Ctrl+C to stop the command
-1 ICMP mode, default
-2 UDP mode
-3 TCP mode
-P [protocol] Same as above, setting ip protocol
1 - icmp, 17 - udp, 6 - tcp
-c count packet count
-l size data size
-T ttl set TTL, default 64
-p port source and destination port
-f flag tcp head flag, |C|E|U|A|P|R|S|F|
bits |7 6 5 4 3 2 1 0|
-t send packet until interrupt by Ctrl+C
-i ms wait ’ms’ milliseconds between sending each packet
-w ms wait ’ms’ milliseconds to receive the response
Figure 2.2: Advanced ping command in VPCS
list of Cisco IOS supported by Gns3. The report[25] has described methods to imple-
ment ACL(Access control list)in Gns3 with example and described the basic validation
of filtering rules. Gns3 has VPCS(Virtual PC Simulator) as a device in host devices
which is a program written by Paul Meng which acts as a virtual PC[19] which has some
advanced commands which real PC does not have. One of the examples is advanced
ping command. Ping in real PC is used to send ICMP packets but ping command
can send TCP and UDP packets in VPCS developed by Paul Meng. The report[55]
described how to use advanced Ping command of VPCS for different purposes. The
advanced ping command is shown in Figure 2.2[55].
According to the report[55], if we want to send traffic on 10.100.60.10 with port 10 with
2.6 Other tools 10
TCP stream then ping command should be like below where -P stands for protocol and
6 stands for TCP and -p stands for the port to which we want to send traffic.
Ping 10.100.60.10 -P 6 -p 10
If we want to send UDP traffic on 10.100.60.10 on port 10 then the command would
be like below where 17 stands for UDP traffic and 10 after -p is the destination port.
Ping 10.100.60.10 -P 17 -p 10
Information collected from the different literature regarding Gns3 is used in Chapter 5
to show the whole method to validate filtering rules using Gns3.
2.5.5 Comparison between Packet Tracer and Gns3
Comparison between Gns3 and Packet tracer has been derived in Table 3.3[38].
2.6 Other tools
Major tools such as Netml/Ns3, Packet Tracer, and Gns3 have been reviewed, but in
real world there are more tools which can validate filtering rules. Different tools use
different methods to validate. We have to have some programming knowledge as well
if we are working with some tools such as[50]:
• Ns2 (Network Simulator 2)
• Ns3 (Network Simulator 3)
• OPNET
• OMNeT++
• NetSim
2.6 Other tools 11
Criteria Packet Tracer Gns3

Proprietary Cisco Support Cisco IOS
and Juniper IOS
Legal issue No Should have a license
of IOS to use
Simulation level Simulation Emulate the
behavior of devices
Configuration command Support limited commands Support all commands
Pre-defined learning Create pre-defined Cannot
situation learning situation
Connection to No Yes
real equipment
Different types Support different Virtualise only copper
of cabling types of cabling straight through
and serial cable
Resource consumption Low High
Animation of traffic Yes No
Connect to VM No Yes
Supported OS Windows, Linux Windows, MacOS X
Table 2.1: Comparision between Packet Tracer and Gns3

2.7 Access control engine 12
• REAL
• QualNet
• J-Sim
Firewall filtering rules have been validated by Netml using example network in Chapter
3, and by Gns3 in Chapter 5.
2.7 Access control engine
Google[54] has adopted Access-proxy instead of perimeter firewall which does Authenti-
cation, Authorisation, and Accounting(AAA) for a user access to enterprise applications
where traffic is filtered per user basis rather than IP basis. The Access-proxy is the
product which is following the concept of different patents described in [35] and [17].
Different authors[23][42] have proposed models for access control by using different
methods but the outcome of all models is to provide access control mechanism to an
existing network.
We need a new model which uses application-based filtering concept same as Google’s
BeyoundCorp model, because packet based filtering is not enough to make network
secure from attacks. Access-control engine has been proposed to do application level
filtering in new model which provides all services of BeyondCorp’s access-proxy plus
content filtration. Network models similar to Google’s BeyondCorp model have been
proposed using Access-control engine with different placements in Chapter 6.
2.8 SSL/TLS filtration/surveillance
The content of SSL/TLS traffic is very hard to filter by firewall[27]. SSL/TLS proxy[6]
came into place to solve this problem. Different algorithms[47] have been proposed to
filter content of SSL/TLS in SSL/TLS proxy[6]. SSL/TLS proxy does content filtration
rather than surveillance of encrypted data. In surveillance, surveillant has the main
2.9 Summary 13
purpose of surveilling rather than blocking conversation. We need SSL/TLS surveil-
lance model. A new SSL/TLS surveillance model has been proposed and discussed in
Chapter 7.
2.9 Summary
Literature regarding simulation tools and methods to validate firewall filtering rules has
been reviewed to validate firewall filtering rules by Netml in Chapter 3, and by Gns3 in
Chapter 5. Literature regarding application-based filtering has also been reviewed to
propose a new application-based filtering network model similar to Google’s Beyond-
Corp model in Chapter 6. Literature regarding SSL/TLS filtration has been reviewed
to propose a new SSL/TLS surveillance model in Chapter 7.
Chapter 3
Modeling of filtering rules by

Netml
In this chapter, a sample network is created and filtering rules are applied in a firewall
node using Netml as a tool. Methods to validate the filtering rules are described
as well using the Netml as a simulation tool. As an outcome, in the end, filtering
rules are validated using Netml which shows how systematic validation of filtering
rules in a firewall may be undertaken. During this experiment, some limitations in
the use of Netml for this purpose have also been identified. The URL for Netml is
www.netml.usq.edu.au. The registration on www.netml.usq.edu.au is required to use
Netml.
3.1 Experiment
NetML 4.64 is being used for this experiment. At the moment 4.64 is the latest version
of Netml. Figure 3.1 shows the control panel used, in Netml, to select the tool in use,
which allows the mouse to be used to create nodes, links, or traffic streams, and to
either select or move objects.
First, we will take three nodes and we will arrange them as shown in Figure 3.2. To
3.1 Experiment 15
Figure 3.1: control panel in Netml
place node in the workspace of Netml, we have to select a node in the control panel and
double click in a Netml workspace, as result a node will be created at clicked location
as shown in Figure 3.2.
Figure 3.2: Drag and drop nodes
3.1.1 Connect nodes
We will choose a duplex link from the control panel and draw according to Figure 3.3.
Figure 3.3: Add duplex links

3.1 Experiment 16
3.1.2 Edit parameters of links
To edit the parameters of links which we have just added, we can select an individual
link and then choose ns3 parameters in right-click menu and edit it accordingly or all
links ns3 parameters can be opened in one dialog by pressing CTL + ALT in keyboard
and selecting any link which will select all links, but make sure an Arrow is selected in
the control panel. After all links selected, we can open right-click menu and select ns3
parameters to open all links’ ns3 parameters in one dialog. That will display the ns3
parameters dialog for all links as shown in Figure 3.4.
Figure 3.4: ns3 parameters for all selected links
We will implement filtering rules on node0 which is the middle node in the experimental
network shown in Figure ??. So we have to select ns3 element type as pttoptether to
all links which are connecting to the node0. At the moment, it is a limitation of
Netml that it does not apply filtering rules on traffic coming from link type Point to
Point(pttopt). As result, we have to choose ns3 element type as pttoptether for both
links and we have to change base address and leave another parameter as it is. We can
manually give a different base address to both links or just check the Checkbox left to
3.1 Experiment 17
BaseAddress parameter which will give a unique BaseAddress to all selected links. In
this experiment, we will check that checkbox as shown in Figure 3.5, as result we will
get unique BaseAddress for all links.
Figure 3.5: Set unique BaseAddress for all selected links by checking CheckBox next
to BaseAddress field
3.1.3 Link labels
Now we have to set the label of links to show BaseAddress as link label to make network
easy to understand. We will follow Figure 3.6 to set links label as BaseAddress. Figure
3.7 shows the example network after BaseAddress has been chosen as the label for links.
3.1.4 Add filtering rules on node
Now we will implement filtering rules in middle node, i.e node 0. We will set up rules
described in Table 3.1. To implement rules on node0, right click on node0 and select
3.1 Experiment 18
Figure 3.6: Set links label as BaseAddress
Figure 3.7: Link label set to BaseAddress
Source Destination Protocol Port Action

10.0.0.0 10.0.1.0 TCP 11 Accept
10.0.0.0 10.0.1.0 TCP 12 Drop
10.0.0.0 10.0.1.0 UDP 13 Accept
Table 3.1: Filtering Rules

3.1 Experiment 19
Create/edit firewall/Click router as shown in Figure 3.8.
Figure 3.8: Choose to Create/edit firewall/Click router
That will open Firewall IPTables Rulesets dialog as shown in Figure 3.9.
Now we have to choose the Node in the control panel of a Firewall IPTables Rulesets
dialog. After selecting Node in the control panel, we have to double-click in the center
of Firewall IPTables Rulesets dialog. That will cause a dialog to appear called Specify
IP Table which is shown in Figure 3.10.
We will give a sensible name to IP table. We have given Access-Table as name and left
other parameters as it is or we can set other parameters according to Figure 3.10. After
submitting the Specify IP Table window, it will create a node called filter as shown in
Figure 3.11 in Firewall IPTables Rulesets window.
Now we have to double-click filter node which was just created to create a chain of
rules. We will get Specify IP Chain window after double-clicking filter node as shown
in Figure 3.12.
3.1 Experiment 20
Figure 3.9: Firewall IPTables Rulesets window
Figure 3.10: Specify IP Table window

3.1 Experiment 21
Figure 3.11: IP table created in Firewall IPTables Rulesets window.
Figure 3.12: Specify IP Chain window

3.1 Experiment 22
We will give Level1 as name and we will select IP Chain in the first drop-down list,
FORWARD in the second drop-down list and then deny in last drop-down list and
then click on submit. In the second drop-down list, deny is selected which sets default
action of IP chain to deny. We can set it to accept but deny is the most preferable
default action. If we select any other value except FORWARD in the second drop-down
list, then IP rules won’t apply on the node, because other types are not implemented
yet. Netml applies filtering rules globally on a node. i.e the rule applies to traffic from
all incoming links to all outgoing links. But in real life, every vendor have a different
flavour of it. If we talk about Cisco then we can apply filtering rules globally or on the
interface in a particular direction such as incoming or outgoing.
Figure 3.13 represents the window after adding IP chain in Firewall IPTables Rulesets
window. Now we have to add rules in the rule chain. So we will click on the IP chain
Figure 3.13: IP rule chain added to the Firewall IPTables Rulesets
node and it will ask for a filtering rule to insert. But we have to make sure Node
symbol is selected in the control panel. Figure 3.14 represents IP Table Rule window
which we will get after clicking IP chain node. We can give any sensible name to rule
that can help us to understand what rule does. For first rule from Table 3.1, we will
3.1 Experiment 23
Figure 3.14: IP Table Rule window
give the name as 10 in IP Table rule window, TCP as protocol, 10.0.0.0/24 as source
address, 10.0.1.0/24 as a destination address, 11 as a port, accept as action then finally,
click on submit, this way the fisrt rule is inserted. We will follow the same process for
second and third rule specified in Table 3.1 to be inserted. We have specified rule name
10, 20 and 30 for the first, second and third rule. We have to add extra rules for the
reply-traffic from destination to source to be allowed which is allowed through to node0
because Netml does not support Stateful inspection which is discussed in Chapter 4.
As result, we will add one rule with name reverse with source IP as 10.0.1.0/24, desti-
nation IP as IP 10.0.0.0/24, port as *, protocol as * and action as accept which is listed
in Table 3.2. This rule is allowing all traffic initiated from 10.0.1.0/24 to 10.0.0.0/24.
This rule will create a hole in firewall if it is not properly configured. This problem can
be solved by stateful inspection feature in firewall but it is not supported in Netml.
Source Destination Protocol Port Action

10.0.1.0 10.0.0.0 * * Accept
Table 3.2: Rule to allow reverse traffic
After adding rules in Firewall IPTables Rulesets window, we can move around them
to look chain in better view. Rules are moved around to look in better view which is
shown in Figure 3.15. We have added filtering rules in node0. Now we have to test those
rules. To test those rules we have to generate traffic according to all rules implemented.
To generate traffic, we can add a traffic stream from one node to another with having
some parameters set such as the type of stream, destination port etc. Traffic stream
is the Netml feature for generating packets from one node to another having different
parameters such as protocol type, number of bytes to send, start time, end time etc.
3.1 Experiment 24
Figure 3.15: IP rules moved around in large space
3.1.5 Add traffic streams
We will put traffic stream between node1 and node2 shown in Figure ?? for different
port and for different transport protocol type according to Table 3.3 for validating
filtering rules shown in Table 3.1.
Source Destination Protocol Port

10.0.0.0 10.0.1.0 TCP 11
10.0.0.0 10.0.1.0 TCP 12
10.0.0.0 10.0.1.0 UDP 13
Table 3.3: Traffic stream parameters
To draw traffic stream from source to destination, first we will select Traffic-Stream
from the control panel and then click on the source node and drag to another node to
create a traffic stream. Figure 3.16 represents a network with traffic streams applied
according to Table 3.3.
3.1 Experiment 25
Figure 3.16: Traffic streams added
3.1.6 Traffic stream parameters
Now we have to edit parameters of traffic streams according to Table 3.3 to validate
filtering rules applied to node0. We can select all traffic streams and then open ns3
parameters window for all streams and then we can edit parameters for all streams at
the same time in one window as shown in Figure 3.17. To set the transport protocol
to TCP, we will select bulkftp as ns3 element type and we will select udpping for UDP
traffic. We have chosen byte count as tracing for all three streams. We have to choose
TraceSource as Rx for TCP stream and Tx for UDP traffic. We will give TraceName
same as stream name and then increase MaxPackets to 10000000, so streams can have
many bytes to send and we can receive good interpretable trace results. Leave the other
parameters as it is and click submit.
Now follow Figure 3.18 to simulate the network. It saves network automatically when
we simulate the network.
After clicking on NS3 simulation, it will open the window shown in Figure 3.19. We
will leave all fields at it is.
3.1 Experiment 26
Figure 3.17: Traffic stream parameters edited
Figure 3.18: Simulate network

3.1 Experiment 27
Figure 3.19: ns3 simulation window
After clicking submit on ns3 simulation window, it will send Netml file of the network
to a server which will process file and generate output file and send it back. We will
get output on the browser. Figure 3.20 is an output graph received from Netml server
where we have received expected result according to Table 3.1 where stream 1 and
stream 5 passed through and stream 3 blocked.
Figure 3.20: Traffic analysis after applying rules according to Table 3.1
After removing filtering rules from node0, we have received output graph shown in
Figure 3.21 where none of the traffic streams is blocked.
3.2 Limitations of Netml 28
Figure 3.21: Output traces without filtering rules
Figure 3.21 shows the result without filtering rules on node0, while Figure 3.20 shows
result after filtering rules applied to node0. From both figures, Figure 3.21 and 3.20,
we can conclude that we are getting expected result after applying filtering rules on
node0. This way, Netml can validate filtring rules. Netml is an evolving system. It has
some limitations as well.
3.2 Limitations of Netml
Below are the limitations of Netml version 4.64 unstable version. Some of them could
be solved in the upcoming version.
1. Unique destination port: Netml allows only to use unique destination port in
traffic stream destined to a particular node. But in real life, we can have many
traffic streams to the same destination node with the same port number.
2. Source port field is missing in IP Table rule Window: In Figure 3.14 of

the IPTable rule, we can see that there is no source port in IP table rules. Some
3.3 Reason for limitations in Netml 29
rules require source port as well in filtering rules.
3. Filtering rules do not apply on Point to Point link: There is no implemen-

tation which could apply filtering rules on traffic came through Point to Point link
connected to Node having filtering rules applied. It only applies filtering rules
on traffic came from Point to Point Ethernet link connected to a node having
filtering rules applied.
4. No implementation of NAT: Netml has currently no implementation of NAT(Network

Address Translation). It is said by Dr. Ron Addie(main contributor of NetML)
about NAT to be the future implementation of the future version.
5. No implementation of VPN: Netml has currently no implementation of VPN(Virtual

private Network). It is said by Dr. Ron Addie(main contributor of NetML) about
VPN to be the future implementation of the future version.
6. UDP traffic tracing at the receiver end: In filtering rules, there could be
many rules regarding UDP traffic. We can trace TCP traffic at receiver end but
we can not trace UDP traffic on the receiver end. Due to this limitation, we can
not figure out in traces of traffic streams that UDP traffic has been blocked or
not as action by filering rules on firewall. There are ways to tell, but they are
not as convenient as in the case of TCP streams. For example, a pcap trace on
all traffic through any link can be recorded and checked. The relevant data is
available, but it is not easy to plot from this data.
7. Network mask selection: We can create a link between nodes in Netml and
we can assign an IP address to it, but problem is that we don’t have control to
set network mask. By default, the mask is set to 24. So we can not simulate real
sophisticated network which can have a subnet with mask range between 1 to 32.
3.3 Reason for limitations in Netml
Netml is an evolving system. Its main purpose is to help to design and test new
protocols rather than simulate the whole network having all features.
3.4 Outcome 30
3.4 Outcome
Methods to validate filtering rules on firewall by Netml have been identified and ex-
plained in this chapter. Limitations of Netml have also been identified and listed at the
end of the chapter which gives a better idea in the selection of Netml as a simulation
to validate filtering rules in firewall.
Chapter 4
Stateful inspection in firewalls
This chapter is about a stateful inspection feature of firewall. In this chapter, we discuss
how stateful inspection works and which vendors support it. Cisco’s stateful inspection
is also discussed at the end of the chapter. This chapter undertakes a literature review
on stateful inspection. In this chapter, the word zone is used to refer to a part of an
organization’s network.
Networks normally have three zones: Inside zone, Outside zone and DMZ(Demilitarised
Zone). In particular, the Internal(Inside) zone is the collection of nodes (computers and
devices) including all clients in the organization, the Internet zone is the whole of the
Internet outside the organization, and the DMZ is a zone where some organizational
servers reside. In Firewall, when we allow certain requests from one zone to another zone
then we have to manually provide a filtering rule to enable packets to be successfully
routed back through the firewall. If we are allowing return traffic by manual rules in
firewall then we are creating a hole in firewall which attacker can use to send packets
that will match parameters set for return traffic rules and cause DoS attack by SYN
flooding [41] in the network. Here manual rule means, we have configured rules on
firewall to allow packets to route back. But if stateful inspection is ON on firewall then
it will create dynamic rules in firewall which will tell firewall what traffic on what port
and what type of connection(TCP/UDP) and what type of flag i.e SYN, ACK. RST,
FIN is expected in return traffic. Dynamic inspection rules will be checked before the
actual filtering rules checked to (return) traffic on firewall.
4.1 Statefulness by Cisco 32
Many firewall vendors support stateful inspection. Vendor and their product is listed
in Table 4.1 with stateful inspection feature [41] [36].
Vendor Product
Cisco PIX
3COM Secure Gateway
Juniper Firewall
Checkpoint FW-1
Cycon Cycons Labyrinth Firewall
Cyber Guard Technology Cyber Guard Firewall
Table 4.1: Firewall with stateful inspection by the different vendors
Figure 4.1 describes the operation for checking return traffic for a request made on
firewall which supports stateful inspection. When a packet enters firewall having state-
ful inspection feature on firewall will check whether it is SYN packet or not. If it is
SYN packet then filtering rules configured on firewall will be applied on it to make a
decision. If it is permitted after applying filtering rules then the entry in state table
will be made regarding its parameters. When reply packet comes to firewall, it will not
have SYN flag set, so state table will be checked and it will find matching an existing
connection, as result it will be allowed. But if it does not find existing matching con-
nections from state table then filtering rules will be applied to filter traffic. This way
only the legitimate response traffic will be passed through firewall.
4.1 Statefulness by Cisco
Cisco is a popular vendor in networking devices. It has a different variant of statefulness

feature. They have started with keyword established in filtring rule.
4.1.1 Established keyword
We can add established keyword at the end of the TCP filtering rule. That will allow
only TCP packets having ACK or RST flag set from the device(Router/Firewall). For
Figure 4.1: Stateful inspection process
example, if we have added a rule with an established keyword on outside interface in

inside direction then it will not allow outside host to initiate a connection to inside host
through firewall but it will allow TCP reply packets to pass through. This was the first
step by cisco towards statefulness [9].
4.1.2 Reflexive ACL(Access control list)
Reflexive ACL is the next step to stateful inspection. Established keyword only does
a stateful inspection for TCP traffic, but reflexive ACL provide stateful inspection for
UDP and ICMP traffic as well. In reflexive ACL setup, we have to add keyword reflect
at the end of access rule, an arbitrary name for a temporary access list, the time until
entry will stay in the temporary access list. So whenever packet enters in the router and
matches any rules specified with the reflect keyword then it will create a temporary
access list for that request to return. We have to manually append that temporary
access list to filtering rules on return interface.
In this feature, Cisco has added statefulness for more protocols and added time for
statefulness as well. We have to manually append the temporary access list generated
by reflexive rule match at the end of filtering rules[15].
4.1.3 CBAC(Context-Based Access Controls)
In reflexive ACL, we have to append temporary access list generated by a reflexive

module at the returning interface’s access list while in CBAC we have to specify in-
spection for the protocols such as HTTP, FTP, RPC, TFTP, UDP, VDOLIVE, Stream-
works, SQLNET, SMTP, RealAudio, RCMD, H323, CUSEEME only without append-
ing any temporary created access list to main access list which will be checked for
return traffic[14]. We don’t need to specify return interface about allowing return traf-
fic initiated from inside zone, but we have to specify stateful inspection at the interface
to which inside zone traffic enters router. We have to just add Inspect keyword at the
interface from which traffic enters to the device. Temporary created access list will
be checked for all returning traffic irrespective of any returning traffic interface. For
example, let’s suppose we have network shown in Figure 4.2.
Figure 4.2: CBAC
And we want to enable stateful inspection for FTP, SMTP, and TCP, as result, we will
configure it with an arbitrary name on the router as shown in Figure 4.3.
Suppose, we have access list as shown in Figure 4.4 which is supposed to deny all IP
packets. Now we will configure, access-list which is shown in Figure 4.4 on interface S0
with the command which is shown in Figure 4.5.
4.2 Zone-based firewall 35
ip inspect name example ftp

ip inspect name example smtp
ip inspect name example tcp
Figure 4.3: Stateful inspection commands on Cisco router
access-list 102 deny ip any any
Figure 4.4: Filtering rule to deny all traffic
Now if any server from inside zone try to communicate outside then their return traffic
(response) will be blocked. But if we specify inspection list which we have created in
Figure 4.3 to interface Ethernet0 in inside direction, then it will allow any communi-
cation from a server residing in inside zone to go outside and back. Outside users will
not be able to initiate a connection to inside. Commands to attach stateful inspection
on interface Ethertnet0 is shown in Figure 4.6.
4.2 Zone-based firewall
This is the latest concept of Cisco. In CBAC, we have to implement filtering rules on
all interfaces if we have multiple interfaces. We have to specify rules for the traffic
initiated or destined to the device itself as well. But in Zone-based firewall, by default
traffic initiated or destined to the device itself is allowed. That makes easy for routing
protocol such as OSPF, BGP, EIGRP etc to communicate without adding any rules for
permitting them. We can add a bunch of interfaces in a zone and then we can specify
an access policy between zones. Device’s IP belongs to the self-zone by default. So
interface Serial0 ip access-group 102 in
Figure 4.5: Apply access-list on interface s0

interface Ethernet0
ip inspect example in
Figure 4.6: Apply stateful inspection on interface Ethernet0
we can specify a policy for the self-zone to other zone communication. That way we
can filter traffic from the device itself to another device or from another device to that
device. The zone can have security-level from 0-100. Zone having higher security-level
can talk to the zone having lower security-level but the reverse is not possible by default
but we can allow by applying an access policy to do so. Even zone having the same
security level cannot talk to each other. But from any zone to self-zone communication
is by default permitted if access policy is even not configured for that zone pair.
In figure 4.7, there are different zones named A1 to A4 with different security-level.
Each zone has a number of interfaces as a member. Right now we haven’t configured any
access policy for any zone-pair. So it will follow basic rules such as allow communication
from any device to the device itself or allow any communication from the device itself to
any device. So if PC1 makes a request to PC9 which belongs to zone A4 which has lower
security-level than the zone of PC1 then request will be passed to PC9. But when PC9
responses, the source is PC9 and the destination is PC 1, as result, the response will
not pass through because PC9’s zone has lower security-level than PC1’s zone security-
level. To allow this response to go through, we have to specify a policy for zone pair
A4 to A1 to allow traffic from zone A4 to A1. Configuration for this option is shown
in Figure 4.8. Or the second option is, we will enable stateful inspection from zone A1
to A4 which will implicitly allow return traffic from zone A4 to A1. Configuration for
this option is shown in Figure 4.9
If we follow Option 2, then we don’t need to specify a policy for zone A4 to A1, because
inspection for ICMP traffic is ON from zone A1 to A4 which will create a dynamic policy
for return traffic from zone A4 to A1.
Figure 4.7: Zone based firewall
class-map type inspect match-all ICMP-Policy

match protocol icmp
policy-map type inspect A4-to-A1

class type inspect ICMP
pass
zone-pair security A4-to-A1-Zone-pair source A4 destination A1

service-policy type inspect A4-to-A1
Figure 4.8: Option 1: Configuration without stateful inspection

class-map type inspect match-all ICMP-Policy

match protocol icmp
policy-map type inspect A4-to-A1

class type inspect ICMP
inspect
Figure 4.9: Option 2: Configuration with stateful inspection

Chapter 5
Modeling of filtering rules in

Gns3
In this chapter, we are using Gns3 as a simulation tool. Same network as Chapter
3 has been created using Cisco router and VPCS(Virtual PC Simulator). In Netml,
nodes which are used, are independent of a vendor. Same filtering rules as Chapter 3
have been implemented on the middle node. Method to validate those filtering rules is
identified and explained in this chapter. As an outcome of this chapter, filtering rules
have been validated by using Gns3 as a simulation tool.
Gns3 uses Gns3 VM to virtualize different OS. Gns3 VM is ubuntu VM(Virtual Ma-
chine) that is used to virtualize OS of different networking devices in Gns3 which runs
on VirtualBox or VMware. How to link Gns3 VM to Gns3 and how to add Cisco router
IOS in Gns3 is explained in Appendix A.
5.1 Filtering rules validation experiment
In this experiment, we will make three node network same as Chapter 3. We will
create a topology shown in Figure 5.1 where the middle device is a Cisco router and
two devices connected to it are VPCS(Virtual PC Simulators).
5.1 Filtering rules validation experiment 40
Figure 5.1: Topology in Gns3
5.1.1 Router configuration
Router interfaces configuration is shown in Figure 5.2
Access-list named access-list which is a chain of rules is configured on the router using
commands shown in Figure 5.3. Filtering rules are taken from Table 3.1 from Chapter
3. “log-input” keyword is appended to all rules at the end which will log the information
of traffic which matches particular rules. Default action at the end of access-list is deny.
So if traffic does not match any filering rules to permit then it would be denied.
interface GigabitEthernet1
ip address 10.0.0.1 255.255.255.0
ip address 10.0.1.1 255.255.255.0
Figure 5.2: Router configuration

ip access-list extended access-list

permit tcp 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255 eq 11 log-input
deny tcp 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255 eq 12 log-input
permit udp 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255 eq 13 log-input
Figure 5.3: Commands to configure sample filtering rules
ip access-group access-list in
Figure 5.4: Apply access-list on the particular interface in a particular direction
5.1.2 Apply access-list on the interface
We have to now apply access-list which we have just created shown in Figure 5.3 to
interface Gi1(Gigabitethernet 1) in an inbound direction which will filter traffic from
network 10.0.0.0/24 to 10.0.1.0/24. Command to apply access-list on the interface in
particular direction in middle Cisco router is shown in Figure 5.4.
5.1.3 PC-1 configuration
PC1 is configuration is shown in Figure 5.5 which can be configured by using a command
on VPCS PC1 shown in Figure 5.6.
IP 10.0.0.2
Mask 255.255.255.0
Gateway 10.0.0.1
Figure 5.5: PC1 configuration

IP 10.0.0.2 255.255.255.0 gateway 10.0.0.1
Figure 5.6: PC1 configuration command
IP 10.0.1.2
Mask 255.255.255.0
Gateway 10.0.1.1
Figure 5.7: PC2 configuration
5.1.4 PC-2 configuration
PC1 is configuration is shown in Figure 5.7 which can be configured by using a command
on VPCS PC1 shown in Figure 5.8.
5.1.5 Traffic generation
We have applied access-list on an interface on the router. To validate filtering rules,

we will generate traffic according to Table 3.3. To generate ICMP traffic, we can use
ping on PC-1. To generate TCP/UDP traffic, we will use advanced ping command
which is only part of VPCS[55] which was discussed in literature review in Chapter 2.
Advanced ping command format is shown in Figure 5.9 which is supported in VPCS.
In command shown in Figure 5.9, we will choose 6 for TCP traffic and we will choose
17 for UDP traffic and port number according to destination port to generate relevant
traffic. For testing rule 1, from Table 3.1, we will use the command shown in Figure
5.10. For testing rule 2, from Table 3.1, we will use the command shown in Figure 5.11.
IP 10.0.1.2 255.255.255.0 gateway 10.0.1.1
Figure 5.8: PC2 configuration command

Ping <Ip address> -P {6 or 17} -p <port number>
Figure 5.9: Advance ping command format
ping 10.0.1.2 -P 6 -p 11
Figure 5.10: Command to validate rule 1 from Table 3.1
For testing rule 3, from Table 3.1, we will use the command shown in Figure 5.12.
5.1.6 Verification of rules
To verify whether a rule has been matched, we will see the log message on the router.
Whenever any rule will be matched on the router, the log message will be generated on
the router console screen and saved in log buffer as well on the router. We can check
log messages from log buffer on the router by command shown in Figure 5.13. For
validation of rule number 1, we have issued command shown in Figure 5.14, as result,
we are getting log message on a console of the router shown in Figure 5.15. Result for
command shown in Figure 5.16 for testing rule 1 is shown in Figure 5.17. This way we
can validate other filtering rules as well. We have used VPCS client to generate TCP
and UDP traffic. But in real life, there could be many types of filtering rules which use
different protocols in filtering rules other than TCP, UDP. To validate those rules, we
require different types of traffic generating capability. To generate all types of traffic
such as HTTP, IGMP, MLD, RTSP, SIP etc, we can use packet generator tool such as
Ostinato, Cat Karat Packet Builder[39][56].
We can install packet generator software on the host computer, then connect a host
computer to the Gns3 topology as a node, then generate the desired traffic. Host
ping 10.0.1.2 -P 6 -p 12

ping 10.0.1.2 -P 17 -p 13
show log | include <access list name>
Figure 5.13: Command to see log buffer on the router
ping 10.0.1.2 -P 6 -p 11
Figure 5.14: Command to validate rule 1
Figure 5.15: Router console
show log | include access-list
Figure 5.16: Command to view log

5.2 Outcome 45
Figure 5.17: Log buffer for rule 1 from Table 3.1
computer refers to the computer on which Gns3 is running. Appendix B describes, how
to connect a host computer to Gns3 topology, as result, we can run packet generator
software on a host computer to generate the desired traffic.
5.2 Outcome
Method to validate firewall filtering rules using Gns3 as simulation tool has been iden-
tified. As result, traffic which should be blocked would be blocked rather than blocking
legitimate traffic.
Chapter 6
Toward BeyondCorp: a new

network security model
IP based traffic filtering is not enough to make network secure. Suppose particular
device is permitted to access the network as a result of the packet-based filtering rule
on firewall. If that device gets compromised by an attacker then the attacker can
initiate attacks on a network using that device. To solve this problem application based
filtering introduced[34][54][52][5][48]. The main goal of application based filtering is to
protect application servers. Application-based filtering can be included in the server
as a module[12] or as a separate device in network close to servers which are called
reverse proxy as well. Google has taken action toward this concept and created a new
network security model called BeyondCorp where they have removed traditional firewall
with access-proxy which does authorization, accounting and authentication[54]. Access-
proxy is implemented using a combination of devices. BeyondCorp model is shown in
Figure 6.1.
In traditional network design model, we have three zones in the firewall: DMZ(Demilitarized
Zone), inside zone, outside zone as shown in Figure 6.2. Organizational clients reside
in inside zone, servers reside in DMZ and internet resides in outside zone. Internal
users normally don’t have many restrictions on DMZ and outside zone access. But for
outside users, there are more restrictions to use corporate network. VPN is helpful
47
Figure 6.1: BeyondCorp Model
for a remote corporate user to join corporate network remotely and gain all access to
network same as on-site users. This can lead to many attacks in firewall if remote
user’s device is compromised and firewall is using only packet based filtering. On-site
devices also can generate attacks if they are compromised. Normally onsite devices
are secured with anti-virus program provided by organizations. So chances of onsite
devices compromised are very rare.
In this chapter, Access-control engine has been proposed with having all capabilities of
access-proxy plus content filtering. Traditional network with firewall shown in Figure
6.2 has been secured with a new proposed Access-control engine. Different placement
locations of an Access-control engine in a network with advantages and disadvantages
have been explained. Using different placements of an Access-control engine, four
different network security models are proposed as an outcome of this chapter with
different advantages and disadvantages.
6.1 Adopt BeyondCorp concept in traditional network 48
Figure 6.2: Traditional Firewall
6.1 Adopt BeyondCorp concept in traditional network
Transition to BeyondCorp model is not easy. We can not replace firewall from tradi-
tional network to Access-control engine instantly. A firewall could have many services
running which may be not supported by the Access-control engine. In new security
models which we are proposing, Access-control engine would be added without remov-
ing firewall. So we can provide packet filtering and application level filtering in the
network. (Note: We are referring traditional network to the network which has firewall
at Gateway position on the network with having three zones: DMZ, Inside, Outside).
Figure 6.2 refers to traditional network topology.
6.1.1 Make all applications publicly available
We have to make all applications publicly accessible using public address using NAT
on firewall. Once all applications are publicly accessible then we can control access by
Access-control engine.
6.1.2 Access-control engine
We are proposing Access-control engine which will provide following services.
• Authentication
• Authorisation
• Accounting
• URL Filtering
• Content Filtering
• Cache
An Access-control engine could be one device or multiple devices arranged together to

provide services. Some vendors provide all services in one device and some provide a
different number of devices which can be joined together to provide full service. We will
refer Access-control engine as one device in the whole document. An Access-control
engine could have different types of placement in a zone. We have proposed three
different models of Access-control engine placement such as Model A, Model B and
Model C with their advantages and disadvantages which would help us to create final
new network security models.
Model A
In this model, Access-control engine is not in a separate device. It is coded in the server.
For example, we can install ModSecurity (an open source application filtering module)
in Apache to take full advantage of web security[12]. Each server can have their own
coded Access-control engine service. This model is useful in an only organization having
only one server. If an organization having multiple servers then it is not recommended
because a user has to be authenticated and authorized to access individual servers. Cost
effectiveness is the advantage because we don’t require a separate device for Access-
control engine’s services. figure 6.3, represents Model A placement of Access-control
engine which is coded in the server or module is installed in the server.
Figure 6.3: Model A

Model B
In this model, Access-control engine is connected to LAN(Local area network) segment.

We have to configure firewall to use this Access-control engine to filter traffic. This
model is recommended for a medium sized network. This model is recommended over
Model A, but it should be only used if there is a specific requirement to use it. If we make
mistake in firewall configuration then an attacker will have chances to bypass services
provided by the Access-control engine. Figure 6.4 represents Model B placement of the
Access-control engine.
Figure 6.4: Model B
Model C
In this model, we will put Access-control engine in between firewall and devices to
which we want to protect. In this model, all access-requests have to pass through
Access-control engine. We don’t need to configure firewall to use this Access-control
engine as a filtering device. It is automatically used because it is only the path to go
6.2 New network security models 52
protected servers. So, chances of bypassing Access-control engine due to firewall mis-
configuration is zero. This model is highly recommended over other models. But we
have to be careful in Access-control engine devices selection. If Access-control engine
devices are having lower computing power then it can lead to performance issue. Figure
6.5 represents Model C placement.
Figure 6.5: Model C
6.2 New network security models
We can create new network security models, having different Access-control engine
placement. We can use one Access-control engine for the whole network or we can use
separate Access-control engines for different zones. If we use the same Access-control
engine for all zones then network model will look like model shown in 6.6 where Access-
control engine residing in DMZ will provide filtration services for all traffic such as from
inside zone to outside zone, outside zone to inside zone, inside zone to DMZ, DMZ to
inside zone, DMZ to outside and from outside zone to DMZ. This network model would
be efficient where performance is not a problem and budget is low. To come up with
the performance issue, we can use two Access-control engine. Both will reside in DMZ.
One will do access filtration for inside zone to outside zone and outside zone to inside
zone while other will do filtration for traffic destined to DMZ or initiated from DMZ.
This network model is shown in Figure 6.7. We can put Access-control engine which
is doing filtration from inside zone to outside zone and outside zone to inside zone in
6.3 Outcome 53
Figure 6.6: Access-control engine in DMZ used to filter all traffic
inside zone as well which is represented in Figure 6.8.
The network explained in Figure 6.7 and 6.8, both are using the Access-control engine
placement model B where an Access-control engine can be bypassed by an attacker
if firewall is not configured properly. To come up with this problem, the network
model shown in Figure 6.9 is proposed where we don’t need to configure firewall to
use Access-control engine. Bypassing access-control engine is very hard in this model
by an attacker. So the model presented in Figure 6.9 is highly recommended network
security model.
6.3 Outcome
New network security models shown in Figure 6.6, 6.7, 6.8, 6.9 have been proposed
which are similar to Google’s BeyondCorp model. Network models proposed here will
provide packet filtering by firewall and application level filtering by Access-control
engine to make the network more and more secure.
6.3 Outcome 54
Figure 6.7: Separate Access-control engine in DMZ for filtering connection from “inside
zone to outside zone” and from “outside zone to DMZ”
Figure 6.8: Access-control engine in inside zone with placement Model B

6.3 Outcome 55
Figure 6.9: Access-control engine placement Model C in inside zone

Chapter 7
A new SSL/TLS surveillance

model
7.1 Problem
SSL/TLS is providing security over the transport layer. Attackers can misuse the
privacy provided by SSL/TLS to send malicious data to a recipient and it will not
be surveilled. SSL/TLS proxy exists to do content filtering in SSL/TLS traffic but it
does not provide surveillance of SSL/TLS traffic[6]. Surveillance protocol for SSL/TLS
traffic does not exist. It is proposed in this chapter using modeling.
7.2 Solution
In this chapter protocol and model to do SSL/TLS surveillance have been proposed by
proposing different services and devices in the existing network, as result surveillance
of SSL/TLS traffic would be possible. It requires different components.
7.2 Solution 57
7.2.1 Components of the new model
• Surveillant: Surveillant would be the person who wants to do surveillance. It

could be a network administrator or Government officer who has right/permission
to surveil.
• Applications which are using SSL/TLS: These are the applications who are
using SSL/TLS protocol for communication. We have proposed responsibility
to these applications to share session keys which they are using in SSL/TLS
communication to Session service. Session service is explained next.
• Session service: This is an application which is proposed in this model which

would run on all client PC as part of OS. Its main responsibility is to store session
keys shared with it by applications which are using SSL/TLS for communication.
• Session Server: This is an application which is proposed in this model. Its main
duty is to listen to a surveillant request for a particular session key and further
ask for session key from session service of a destined host. After getting session
key from Session service, Session server will send that session key to Surveillant.
• Destination server: This is the SSL/TLS enabled server to whom the client is
doing SSL/TLS communication.
7.2.2 Proposed model
The SSL/TLS model with all proposed components is joined together to make a new
model for SSL/TLS surveillance which is represented in Figure 7.1.
7.2.3 How it works
A sequence diagram is shown in Figure 7.2 which would help to understand how this
protocol will work. Let’s suppose, the client browser and server are doing communi-
cation over SSL/TLS and network admin came to know about malicious data being
transferred or Government officer came to network admin and they want to surveil that
communication. In this model, we have proposed Session service which would run on
7.2 Solution 58
Figure 7.1: New model for SSL/TLS Surveillance

7.2 Solution 59
all hosts as part of OS. We have added responsibility to applications which are using
SSL/TLS to share their session key agreed at the end of SSL/TLS handshake to Session
service running on the same host. So in our case, browser who is doing communica-
tion with SSL/TLS enabled server might have shared session key agreed at the end of
SSL/TLS handshake to the Session service running on the same host on which browser
is running.
Network admin would make a request to get session key from Session server by speci-
fying the source and destination IP of a session to which he/she want to surveil. After
getting a surveillant request for the particular session key, Session server will create a
new request to Session service running on the identified host. Host IP will be identi-
fied from a payload of surveillant’s request. Surveillant’s request payload will contain
source and destination IP of a session to be surveilled. Source IP from this payload
would be the host IP which is the target host on which our targeted browser is doing
SSL/TLS communication. Destination IP from the payload of surveillant’s request will
also be copied to a new request from Session server to session service on the targeted
host. Session service will authenticate a request from Session server. We have proposed
new field in the DHCP server. New field will be Session server IP. So every host on the
network when boots up, they will receive Session server IP. Session service will compare
this IP to the IP of session key requestor. If both are matched then particular session
key will be returned. Otherwise request will be dropped.
Now suppose both IPs are matched, then the session key is returned to the Ses-
sion server. Session server would send that key to Surveillant who has requested it.
Surveillant can use this key to decrypt communication between the Client browser and
SSL/TLS server. Communication between Surveillant and Session server, Session server
and Session service would be protected by SSL/TLS, so session key will be transferred
to surveillant securely.
7.3 Outcome 60
Figure 7.2: SSL/TLS Surveillance model in action
7.3 Outcome
A new model for SSL/TLS surveillance has been proposed in this chapter. Secure
communication in this model can be achieved by using SSL/TLS. This model is a new
proposal which could have many security vulnerabilities which are not identified here
but it could be solved as a separate research project.
Chapter 8
Conclusion
This project was about modeling and validation of network security. A filtering rules
in a firewall was the main solution to network security up till recently. So validation
of filtering rules is important. The features of different tools such as Netml, Packet
Tracer and Gns3 to validate filtering rules have been discussed. Experiment to validate
filtering rules by Netml and Gns3 has been discussed in separate Chapters 3 and 5.
Gns3 and Packet Tracer were also compared in Chapter 2.
Stateful inspection is crucial in a firewall which was discussed thoroughly in Chapter

4. Nowadays, filtering rules are not enough to provide network security.
In Chapter 6, a new model having better application level security had been proposed by
using the Access-control engine. An Access-control engine had also been proposed with
a list of services in Chapter 6 which does not exist but can be created by joining different
devices. There were four different network security models proposed using the different
Access-control engine placement models. Each Access-control engine placement model
had been explained with advantages and disadvantages to use them in new network
security models.
SSL/TLS surveillance is very crucial currently. There does not exist any specific pro-
tocol to do it. A new model to do SSL/TLS surveillance had been proposed in Chapter
7 which had used different components. All components with their services were ex-
62
plained in Chapter 7.
In nutshell, the goal of this document was to solve the network security problem by
modeling and simulation where the three main example network security problems such
as a validation of filtering rules, a new model of network security by using application
level security and a new SSL/TLS surveillance model have been solved using modeling
and simulating.
This project can be further developed to propose a standalone device to provide all
listed services for an Access-control engine. There does not exist a standalone device
which can provide all listed services for proposed Access-control engine. Model and
protocol for SSL/TLS surveillance had been proposed in this document which further
can be analyzed and improved to make it physible in existing system by removing
identifying unidentified vulnerabilities.
References
[1] Jasin A. Packet Tracer Network Simulator. Packt Publishing, Birmingham, UK,
second edition, Jan 2017.
[2] Ron Addie, Stephen Braithwaite, and Abdulla Zareer. Netml a language and
website for collaborative work on networks and their algorithms. In ATNAC 2006,
Melbourne, Australia, December 2006. Australian Telecommunications Networks
and Applications.
[3] Ronald Addie and Joshua Natarajan. Netml-ns3-click: Modeling of routers in

netml/ns3 by means of the click modular router. EAI Endorsed Transactions on
Mobile Communications and Applications, 16(8), 8 2015.
[4] Ronald G. Addie, Yu Peng, and Moshe Zukerman. Netml: Networking networks.
In DASC 2011, pages 1055–1061, Sydney, Australia, Dec 2011. IEEE, IEEE Com-
puter Society.
[5] D. Appelt, C. D. Nguyen, and L. Briand. Behind an application firewall, are we

safe from sql injection attacks? In 2015 IEEE 8th International Conference on
Software Testing, Verification and Validation (ICST), pages 1–10, April 2015.
[6] Michael Edward Baskey, Timothy James Hahn, Dilip Dinkar Kandlur, and
David Gerard Kuehr-McLaren. Methods, systems and computer program prod-
ucts for enhanced security identity utilizing an ssl proxy, May 4 2004. US Patent
6,732,269.
[7] Luhur Bayuaji. Simulation mode. https://www.youtube.com/watch?v=

roeXl90jVLs, Sep 2016. [Online; Accessed 7 June. 2018].
REFERENCES 64
[8] David Bombal, Julien Duponchelle, and Ricar Ganan-
cial. Your first gns3 topology. Document, Gns3,
https://docs.gns3.com/1wr2j2jEfX6ihyzpXzC23wQ8ymHzID4K3Hn99-qqshfg/,
Jan 2018.
[9] James Boney. Cisco IOS in a Nutshell: A Desktop Quick Reference for IOS on
IP Networks, chapter Access Lists. Cisco IOS in a Nutshell. O’Reilly Media, Inc,
Sebastopol, CA 95472, second edition, aug 2005.
[10] Korbin Brown. The beginners guide to iptables, the

linux firewall. https://www.howtogeek.com/177621/
the-beginners-guide-to-iptables-the-linux-firewall/, Feb 2014. [Online;
Accessed 4 Jun. 2018].
[11] Information Security Buzz. Essay on history of network security — informa-

tion security buzz. https://www.informationsecuritybuzz.com/articles/
essay-history-network-security/, Jan 2018. [Online; Accessed 4 Jun. 2018].
[12] Brad Causey. Introduction to web application firewalls in the enterprise. Online,
feb 2015.
[13] Cisco. Configuring ip access lists. Technical Report 23602, Cisco, Dec 2007.
[14] Cisco. Context-based access control (cbac): Introduction and configuration. Tech-
nical Report 13814, Cisco, jun 2008.
[15] Cisco. Cisco IOS Security Configuration Guide, Release 12.2, chapter Configuring
IP Session Filtering (Reflexive Access Lists). Cisco IOS Security Configuration
Guide. Cisco, feb 2014.
[16] ciscolinux0. Cisco packet tracer limitations of the network

simulator. https://ciscolinux0.wordpress.com/2014/01/15/
cisco-packet-tracer-limitations-of-the-network-simulator/, Jan 2014.
[Online; Accessed 7 June. 2018].
[17] Blair Brewster Dillaway, John L Manferdelli, and Shawn Martin Woods. Access
control policy engine controlling access to resource based on any of multiple re-
ceived types of security tokens, August 10 2010. US Patent 7,774,830.
REFERENCES 65
[18] Naranker Dulay, Emil Constantin Lupu, and Morris Sloman. A language for spec-
ifying security and management policies for distributed systems. Research Report
2000/1, Imperial College, London, Oct 2000.
[19] Julien Duponchelle. Vpcs. https://docs.gns3.com/

1ALk8HxK9qPCjhNL2OzFtW64Z7b2kBwEnEe5xbPG2gJ0/index.html, Dec 2017.
[Online; Accessed 7 June. 2018].
[20] Michael Edwards. 770,000 australians fall victim to identity theft. http://www.
abc.net.au/news/2015-04-14/identity-theft-hits-australians-veda/
6390570, Apr 2015. [Online; Accessed 29 Apr. 2018].
[21] Katherine Ellis. Configure, implement & test acls. https://www.youtube.com/

watch?v=lmV9kTQcAAg, May 2012. [Online; Accessed 4 Jun. 2018].
[22] Kevin Featherly. Arpanet. https://www.britannica.com/topic/ARPANET, Nov

2016. [Online; Accessed 4 Jun. 2018].
[23] Kathi Fisler, Shriram Krishnamurthi, Leo A Meyerovich, and Michael Carl
Tschantz. Verification and change-impact analysis of access-control policies. In
Proceedings of the 27th international conference on Software engineering, pages
196–205. ACM, 2005.
[24] Stuart Fordham. 5 things cisco packet tracer wont teach you
(but you should know). http://www.ccnaandbeyond.com/2016/05/
5-things-cisco-packet-tracer-wont-teach.html, May 2016. [Online;
Accessed 7 June. 2018].
[25] Muhammad Furqan. Gns3 labs for ccna: Advanced ac-

cess control lists. http://resources.intenseschool.com/
gns3-labs-for-ccna-advanced-access-control-lists, May 2014. [On-
line; Accessed 7 June. 2018].
[26] Gns3. Cisco ios images for dynamips. http://docs.gns3.com/

1-kBrTplBltp9P3P-AigoMzlDO-ISyL1h3bYpOl5Q8mQ/, Jun 2018. [Online;
[27] Nabeel Hadaad, Leigh Brookshaw, and Ron Addie. Validation of security rules by
simulation. Technical report.
REFERENCES 66
[28] Nabeel Hadaad, Luke Drury, and Ronald G. Addie. Protecting services from se-
curity mis-configuration. In Telecommunication Networks and Applications Con-
ference (ITNAC), 2015 International,, pages 120 – 125, Sydney, NSW, Nov 2015.
IEEE, IEEE.
[29] Jozef Janitor, Frantiek Jakab, and Karol Kniewald. Visual Learning Tools for
Teaching/Learning Computer Networks: Cisco Networking Academy and Packet
Tracer. IEEE, Cancun, Mexico, mar 2010.
[30] Murugiah Souppaya John Wack, Miles Tracy. Guideline on Network Security Test-
ing. National Institute of Standards and Technology, Gaithersburg, MD 20899-
8930, 1 edition, Sep 2008.
[31] Alan Jones. Netfilter and iptables a structural examination. Technical Report
1.4b, SANS Institute, Feb 2004.
[32] Joseph Migga Kizza. Guide to Computer Network Security, Second Edition, e-
book Firewalls. Centre for Forensic Computing Cranfield University, Shrivenham
campus, Swindon, UK, second edition, Jan 2013.
[33] Eddie Kohler, Robert Morris, Benjie Chen, John Jannotti, and M. Frans Kaashoek.
The click modular router. ACM Trans. Comput. Syst., 18(3):263–297, August
2000.
[34] Tammo Krueger, Christian Gehl, Konrad Rieck, and Pavel Laskov. Tokdoc: A
self-healing web application firewall. In Proceedings of the 2010 ACM Symposium
on Applied Computing, SAC ’10, pages 1846–1853, New York, NY, USA, 2010.
ACM.
[35] Thomas Mark Levergood, Lawrence C Stewart, Stephen Jeffrey Morris, Andrew C
Payne, and George Winfield Treese. Internet server access control and monitoring
systems, January 13 1998. US Patent 5,708,780.
[36] Xin Li, Zheng-Zhou Ji, and Ming-Zeng Hu. Stateful inspection firewall session
table processing. In International Conference on Information Technology: Coding
and Computing (ITCC’05) - Volume II, volume 2, pages 615–620 Vol. 2, April
2005.
REFERENCES 67
[37] Mike Lynett. A history of information secu-
rity from past to present. https://blog.mesltd.ca/
a-history-of-information-security-from-past-to-present, Nov 2015.
[Online; Accessed 29 Apr. 2018].
[38] Woratat Makasiranondh, S Paul Maj, and David Veal. Pedagogical evaluation of
simulation tools usage in network technology education. World transactions on
engineering and technology education, 8(3):321–326, 2010.
[39] Sudhakar Mishra, Shefali Sonavane, and Anil Gupta. Study of traffic generation
tools. International Journal of Advanced Research in Computer and Communica-
tion Engineering, 4(6):4–7, 2015.
[40] Computer Networking Notes. Configure standard access control list step by
step guide. https://www.computernetworkingnotes.com/ccna-study-guide/
configure-standard-access-control-list-step-by-step-guide.html, Jan
2018. [Online; Accessed 4 Jun. 2018].
[41] N. A. Noureldien and I. M. Osman. A stateful inspection module architecture.

In 2000 TENCON Proceedings. Intelligent Systems and Technologies for the New
Millennium (Cat. No.00CH37119), volume 2, pages 259–265 vol.2, Sept 2000.
[42] Sejong Oh and Seog Park. Task–role-based access control model. Information
systems, 28(6):533–562, 2003.
[43] Catherine Paquet. Implementing Cisco IOS Network Security (IINS): (CCNA
Security exam 640-553) (Authorized Self-Study Guide), e-book Network Security
Using Cisco IOS Firewalls. Cisco Press, Indianapolis, Indiana, first edition, 2009.
[44] Andre Perez. Network Security, e-book 9: Firewalls. Wiley, Hoboken,USA, first
edition, Sep 2014.
[45] V. V. Preetham. Internet Security and Firewalls, e-book Firewalls for Network
Security. Premier Press, Cincinnati , Ohio, first edition, 2002.
[46] Radware.com. History of network security methods — radware security. https:

//www.radware.com/resources/network_security_history.aspx, Jan 2018.
[Online; Accessed 4 Jun. 2018].
REFERENCES 68
[47] N Kannaiya Raja, K Arulanandam, and B Raja Rajeswari. Two-level packet
inspection using sequential differentiate method. In Advances in Computing and
Communications (ICACC), 2012 International Conference on, pages 42–45. IEEE,
2012.
[48] A. Razzaq, A. Hur, S. Shahbaz, M. Masood, and H. F. Ahmad. Critical analysis

on web application firewall solutions. In 2013 IEEE Eleventh International Sym-
posium on Autonomous Decentralized Systems (ISADS), pages 1–6, March 2013.
[49] SolarWinds. Gns3 network emulator. https://www.solarwinds.com/

free-tools/gns3-network-emulator, Jun 2018. [Online; Accessed 7 June. 2018].
[50] Ns3 Simulation Project Team. List of network simulators. http://

ns3simulation.com/list-of-network-simulators/, Jun 2018. [Online; Ac-
cessed 7 June. 2018].
[51] ITA Terms. Firewall and types. https://supportforums.cisco.com/t5/

security-documents/firewall-and-types/ta-p/311203, Aug 2009. [Online;
[52] Carmen Torrano-Gimenez, Alejandro Perez-Villegas, and Gonzalo Alvarez. A

self-learning anomaly-based web application firewall. In Álvaro Herrero, Paolo
Gastaldo, Rodolfo Zunino, and Emilio Corchado, editors, Computational Intelli-
gence in Security for Information Systems, pages 85–92, Berlin, Heidelberg, 2009.
Springer Berlin Heidelberg.
[53] Joe Touch, Eliot Lear, Allison Mankin, Markku Kojo, Kumiko Ono, Martin
Stiemerling, Lars Eggert, Alexey Melnikov, Wes Eddy, Alexander Zimmermann,
Brian Trammell, Jana Iyengar, Allison Mankin, Michael Tuexen, Eddie Kohler,
and Yoshifumi Nishida. Service name and transport protocol port number reg-
istry. Public report, Internet Assigned Numbers Authority, oct 2018.
[54] Rory Ward and Betsy Beyer. Beyondcorp: A new approach to enterprise security.
;login:, Vol. 39, No. 6:6–11, 2014.
[55] Chris Welsh. Vpcs tutorial. https://rednectar.net/archives/

vpcs-tutorial/, Aug 2014. [Online; Accessed 7 June. 2018].
REFERENCES 69
[56] Petr Zach, Martin Pokorny, and Arnost Motycka. Design of software network
traffic generator. 2013.
Appendix A
Setup Gns3
Gns3 version 2.1.9, Gns3 VM version 2.1.11 for VMware Workstation and VMware
workstation version 15.0.0 are used to setup Gns3 as simulation experiment which can
be downloaded from the Internet.
A.1 Installation
We have to install Gns3 first and then VMware Workstation. Next step is to open
Gns3 VM which we have downloaded. It will be prompted to be added in VMware
workstation where we will leave all default values as it is. Next step is linking Gns3
VM to Gns3 software.
A.2 Linking Gns3 VM to Gns3
Linking Gns3 VM to Gns3 is important to run some devices’ OS. Some devices’ OS
does not run locally on the computer, they require Gns3 VM to run. To link Gns3 VM
to Gns3, settings can be found under preferences window under Edit menu in Gns3.
In that preferences window, we have to select Gns3 VM in the left panel and then in
the right panel we have to select parameters shown in Figure A.1 where Gns3 VM(2)
A.3 Add Cisco routers in Gns3 71
is the Gns3 VM name which needs to be linked.
Figure A.1: Link Gns3 VM to Gns3
A user can select more RAM if he/she wants to simulate many devices in Gns3. After
selection of all settings, a user has to click Apply button and close that window. To
make sure Gns3 VM is linked to Gns3 or not, a user has to restart Gns3 and it should
start Gns3 VM in VMware workstation parallel to Gns3.
Now we have to add devices which we want to use in topology. We are using a Cisco
router in topology, so the next section would describe how to add a Cisco router in
Gns3.
A.3 Add Cisco routers in Gns3
Gns3 have only Etherswitch and Host device added by default. There are templates
of supported devices available in Gns3. So we can drag and drop any device template
which we want to use as a device in topology which displays the window which will
specify supported OS which we can download from the Internet and use it in that device
template. Sometimes device template has a download button which can redirect us to
download page from where we can download required OS file. After downloading that
A.3 Add Cisco routers in Gns3 72
OS file we have to select that OS file to use in the device template. If adding OS to
the device is successful then the device will be added in installed devices list in the left
panel of the Gns3. We can drag and drop that device in Gns3 workspace panel and use
it as a device.
Appendix B
Connect host PC to Gns3
Host PC is the PC in which Gns3 is running. Cloud node is used to connect host PC to
Gns3. We have to drag and drop Cloud node from installed devices list from left panel
in Gns3. When we drop it in Gns3 workspace, it will ask to choose to run either on
local PC or Gns3 VM. We will choose Gns3 VM. If we have not changed any settings
in Gns3 VM then eth0 would be the port on the cloud which connects Host PC. Figure
B.1 shows the topology in which we have connected cloud node to the router. Cloud
node is connected on Gi0 interface of the Cisco router. We have setup Gi0 interface
of the router to get IP from DHCP server. An IP set to Gi0 interface of the router is
192.168.245.130 and mask is 255.255.255.0.
B.1 Verification
From our host PC, we will ping the IP of Gi0 interface of Router. Figure B.2 shows
that we have successfully pinged router interface IP. That means, we have achieved
connectivity between the virtual device in Gns3 and host PC.
If someone wants to setup different subnet between Host PC and the virtual device
then go to VMware workstation application and then go to Edit > Virtual Network
Editor and then change the subnet of the Host-Only network interface to the desired
subnet. If there are multiple Host-Only network interface types available then select
B.1 Verification 74
Figure B.1: Host PC connected to a router
Figure B.2: Host PC connected to a router

B.1 Verification 75
the one which is used in Gns3 VM. To find out which Host-Only network interface is
used, just make topology shown in Figure B.1. Gi0 interface will get IP from DHCP
server then compare that IP to which subnet it belongs in the list of all Host-Only
network interface type in Virtual Network Editor window in VMware Workstation.

Validation of Security Design by Modeling and Simulation

Uploaded by

Copyright:

Validation of Security Design by Modeling and Simulation

Uploaded by

Document Information

Original Title

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Validation of Security Design by Modeling and Simulation

Uploaded by

Copyright:

University of Southern Queensland

Faculty of Health, Engineering and Sciences

Validation of security design by modeling and simulation

in fulfilment of the requirements of

MSC8002 Research Project Dissertation

towards the degree of

Master of Computing Technology

Submitted: November, 2018

MSC8001/2 Research Project

I also like to thank www.stakexchange.com platform which provides an answer to any

List of Tables xiv

1.1.1 Firewall filtering rules validation . . . . . . . . . . . . . . . . . . 1

1.1.2 Application-based filtering . . . . . . . . . . . . . . . . . . . . . . 2

1.1.3 SSL/TLS surveillance . . . . . . . . . . . . . . . . . . . . . . . . 2

Chapter 2 Background and literature 4

2.1 History of network security . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Rise of Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 Types of firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Need for validation of filtering rules . . . . . . . . . . . . . . . . . . . . . 6

2.5 Tools to validate security rules . . . . . . . . . . . . . . . . . . . . . . . 6

2.5.3 Packet Tracer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5.5 Comparison between Packet Tracer and Gns3 . . . . . . . . . . . 10

2.6 Other tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 Access control engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.8 SSL/TLS filtration/surveillance . . . . . . . . . . . . . . . . . . . . . . . 12

Chapter 3 Modeling of filtering rules by Netml 14

3.1.1 Connect nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.2 Edit parameters of links . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3 Link labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.4 Add filtering rules on node . . . . . . . . . . . . . . . . . . . . . 17

3.1.5 Add traffic streams . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Limitations of Netml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Reason for limitations in Netml . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 4 Stateful inspection in firewalls 31

4.1 Statefulness by Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.1 Established keyword . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.2 Reflexive ACL(Access control list) . . . . . . . . . . . . . . . . . 33

4.1.3 CBAC(Context-Based Access Controls) . . . . . . . . . . . . . . 34

4.2 Zone-based firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 5 Modeling of filtering rules in Gns3 39

5.1 Filtering rules validation experiment . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Router configuration . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1.2 Apply access-list on the interface . . . . . . . . . . . . . . . . . . 41

5.1.3 PC-1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.4 PC-2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.5 Traffic generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.6 Verification of rules . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1 Adopt BeyondCorp concept in traditional network . . . . . . . . . . . . 48

6.1.1 Make all applications publicly available . . . . . . . . . . . . . . 48

6.1.2 Access-control engine . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2 New network security models . . . . . . . . . . . . . . . . . . . . . . . . 52

Chapter 7 A new SSL/TLS surveillance model 56

7.2.1 Components of the new model . . . . . . . . . . . . . . . . . . . 57

7.2.2 Proposed model . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2.3 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Appendix A Setup Gns3 70

A.2 Linking Gns3 VM to Gns3 . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.3 Add Cisco routers in Gns3 . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2.2 Advanced ping command in VPCS . . . . . . . . . . . . . . . . . . . . . 9

3.1 control panel in Netml . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Drag and drop nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Add duplex links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 ns3 parameters for all selected links . . . . . . . . . . . . . . . . . . . . . 16