conﬁguration and implementation issues for a firewall...

Configuration and Implementation Issuesfor a Firewall System Running on a

Mobile Handset

by

Pal-Erik Martinsen

A thesis submitted in partial fulfilmentof the requirements for the degree of

Master of Information Technology(Research)

Area of StudyInformation Security Research Centre

Faculty of Information TechnologyQueensland University of Technology

Abstract

Any device connected to the Internet needs to be protected. Using a firewall as afirst line of defence is a very common way to provide protection. A firewall can beset up to protect an entire network or just a single host. As it is becoming moreand more popular to connect mobile phones and other hand held devices to theInternet, the big question is;”how to protect those devices from the perils of theInternet?” This work investigates issues with the implementation of a firewallsystem for protecting mobile devices. Firewall administration is an error proneand difficult task. Setting up a correctly configured firewall in a network settingis a difficult task for a network administrator. To enable an ordinary mobilephone user to set up a firewall configuration to protect his mobile phone it isimportant to have a system that is easy to understand and warns the user ofpossible mistakes. Generic algorithms for firewall rule-set sorting and anomalydiscovery are presented. This ensures that the rule-set is error free and safe touse. This is a vital part of any firewall system. The prototype developed canbe used to find errors in existing firewall rule-sets. The rule-set can be in eithera native firewall configuration format (currently only IPF is supported) or in ageneric XML format. This generic XML format was developed as a part of thisresearch project. Further a new graphical visualization concept that allows theend user to configure an advanced firewall configuration from a device with asmall screen and limited input possibilities is presented.

iii

iv ABSTRACT

Keywords

Firewall, rule-set, sorting, anomaly detection, visualization, mobile handset,XML, FreeBSD, Symbian, IPF, PF, Firewall System, configuration.

v

vi KEYWORDS

Acknowledgements

Without the positive and helpful environment students enjoy at the ISRC Iam sure my time here would have been quite different. It is the people associ-ated with the ISRC that makes the place special. My supervisors Dr AndrewClark and Assoc. Prof. Mark Looi are testimony to that. I especially wantto thank Andrew for being patient, helpful and providing accurate and to thepoint feedback.

Conducting research is one thing. Trying to commercialize the outcome of thatresearch is a completely different thing. The Symbian prototype described laterin the thesis is developed by Oddbjørn Sjøgren and Stale Haugnes. Thankyou for turning ideas into reality. Lars Henrik Rolstad wrote the first businessplan. Thank you for making me realize the business potential. Furthermore AgeLinde Eriksen and Harald Schytz played a vital role in starting up the companyAgile:Insight. By believing in my ideas you have helped me more than you canimagine.

My parents also deserve to be mentioned here. They are always supportive ofwhat I do, even if I am located on the other side of the world.

At last to Martine; thank you for being there.

vii

viii ACKNOWLEDGEMENTS

Statement of OriginalAuthorship

The work contained in this thesis has not been previously submitted for a de-gree or diploma at any other higher education institution. To the best of myknowledge and belief, the thesis contains no material previously published orwritten by another person except where due reference is made.

Signature:

Date:

ix

x STATEMENT OF ORIGINAL AUTHORSHIP

Contents

Abstract iii

Keywords v

Acknowledgements vii

Statement of Original Authorship ix

Contents xi

List of Figures xv

Acronyms xvii

1 Introduction 11.1 Protecting the Mobile Platform . . . . . . . . . . . . . . . . . . . 21.2 Goals and Contributions . . . . . . . . . . . . . . . . . . . . . . . 31.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Firewall Technology Overview 52.1 Firewalls on a Mobile Platform . . . . . . . . . . . . . . . . . . . 62.2 Packet Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Existing Packet Filter Implementations . . . . . . . . . . . . . . 10

2.3.1 Netfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 IPFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Packet Filter (PF) . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Rule-set Management Issues . . . . . . . . . . . . . . . . . . . . . 122.5 Firewall Configuration Approaches . . . . . . . . . . . . . . . . . 132.6 Firewall System Components . . . . . . . . . . . . . . . . . . . . 15

2.6.1 Graphical User Interface . . . . . . . . . . . . . . . . . . . 152.6.2 Logic Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6.3 Packet Filter . . . . . . . . . . . . . . . . . . . . . . . . . 162.6.4 Communication Interface . . . . . . . . . . . . . . . . . . 17

3 Mobile Firewall GUI Implementation 193.1 The Mobile Platform . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Example Threat Scenario . . . . . . . . . . . . . . . . . . . . . . 213.3 Existing Firewall Configuration Approaches . . . . . . . . . . . . 24

3.3.1 The Matrix Approach . . . . . . . . . . . . . . . . . . . . 25

xi

xii CONTENTS

3.3.2 Zone Policies . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.3 Application Approach . . . . . . . . . . . . . . . . . . . . 273.3.4 Summary of existing visualization concepts . . . . . . . . 28

3.4 Graphical Firewall Configuration Tool . . . . . . . . . . . . . . . 283.5 Visualization Concept . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.1 Surrounding Tiles . . . . . . . . . . . . . . . . . . . . . . 303.5.2 Centre Tile . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.3 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.4 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.6 “Slide the Tiles” Implementation . . . . . . . . . . . . . . . . . . 323.6.1 Case 1 - Presentation on TV . . . . . . . . . . . . . . . . 333.6.2 Case 2 - Giving Workshop access . . . . . . . . . . . . . . 353.6.3 Case 3 - Restricting services . . . . . . . . . . . . . . . . . 38

3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Sorting And Validation Engine 414.1 Packet Traversal of a Firewall . . . . . . . . . . . . . . . . . . . . 414.2 Existing Sorting and Prioritizing Approaches . . . . . . . . . . . 43

4.2.1 Binary Decision Diagrams . . . . . . . . . . . . . . . . . . 434.2.2 Policy Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Prototype Implementation . . . . . . . . . . . . . . . . . . . . . . 474.4 Anatomy of an IPF Filtering Rule . . . . . . . . . . . . . . . . . 484.5 Anomaly Avoidance and Detection . . . . . . . . . . . . . . . . . 50

4.5.1 Sorting the Rule-set . . . . . . . . . . . . . . . . . . . . . 514.5.2 Building Blocks for Error Detection . . . . . . . . . . . . 584.5.3 Detecting Redundant Rules . . . . . . . . . . . . . . . . . 604.5.4 Detecting Shadowed Rules . . . . . . . . . . . . . . . . . . 624.5.5 Detecting Correlations . . . . . . . . . . . . . . . . . . . . 63

4.6 Last Hit Rule-sets and Quick Rules . . . . . . . . . . . . . . . . . 654.7 Testing the Algorithms and the Implementation . . . . . . . . . . 674.8 Prototype Functionality . . . . . . . . . . . . . . . . . . . . . . . 694.9 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.10 Use of Research Outcomes . . . . . . . . . . . . . . . . . . . . . . 71

4.10.1 Connection Security Controller . . . . . . . . . . . . . . . 714.10.2 Mobile Connection Security Controller (mSCS) . . . . . . 724.10.3 Stationary Connection Security Controller (sCSC) . . . . 74

4.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5 XML Firewall Interface 755.1 XML Validation Schema . . . . . . . . . . . . . . . . . . . . . . . 755.2 Rule-set Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 775.3 Rule Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.4 IPv4 Address Validation . . . . . . . . . . . . . . . . . . . . . . . 805.5 Action Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.6 Basic IP validation . . . . . . . . . . . . . . . . . . . . . . . . . . 825.7 Protocol Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 825.8 Service Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 835.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

CONTENTS xiii

6 Conclusion and Future Work 856.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

References 93

A Firewall XML Schema 95

B XML Stream 97

C UML Diagrams 99

D Source Code 101D.1 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101D.2 IPv4 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102D.3 IPv4 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103D.4 IPv4 Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103D.5 IPv4 Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103D.6 FwRuleSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

E IPF BNF Configuration Format 111

xiv CONTENTS

List of Figures

2.1 A traditional firewall . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 The mobile phone as a router/bridge . . . . . . . . . . . . . . . . 82.3 A traditional firewall with a DMZ. . . . . . . . . . . . . . . . . . 92.4 Firewall Configuration Possibilities . . . . . . . . . . . . . . . . . 132.5 Firewall System Components . . . . . . . . . . . . . . . . . . . . 15

3.1 Iptables Example Shell Script . . . . . . . . . . . . . . . . . . . . 253.2 Screen shot from Innertek fBuilder . . . . . . . . . . . . . . . . . 263.3 Screen shot from Trustix Firewall . . . . . . . . . . . . . . . . . . 273.4 Screen shot from ZoneAlarm . . . . . . . . . . . . . . . . . . . . 283.5 Slide the Tiles Overview . . . . . . . . . . . . . . . . . . . . . . . 293.6 User in the centre . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.7 Fine-grained control . . . . . . . . . . . . . . . . . . . . . . . . . 323.8 Example Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.9 Case1 (part1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.10 Case1 (part2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.11 Case1 (part3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.12 Case2 (part1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.13 Case2 (part2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.14 Case2 (part3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.15 Case3 (part1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.16 Case3 (part2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.17 Case3 (part3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 TCP/IP Packet Traversal of a Firewall . . . . . . . . . . . . . . . 424.2 Simplified IPF BNF Tree . . . . . . . . . . . . . . . . . . . . . . 494.3 Error Detection Flow . . . . . . . . . . . . . . . . . . . . . . . . . 504.4 Rule comparison algorithm flow. . . . . . . . . . . . . . . . . . . 524.5 Compare Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.6 Visualization of Rule-set (Address example) . . . . . . . . . . . . 544.7 Visualization of Rule-set (Protocol example) . . . . . . . . . . . . 564.8 Visualization of Rule-set (Service example) . . . . . . . . . . . . 564.9 Visualization of Rule-set (Action example) . . . . . . . . . . . . . 574.10 Network Addresses coveredBy . . . . . . . . . . . . . . . . . . . . 594.11 Protocol coveredBy . . . . . . . . . . . . . . . . . . . . . . . . . . 604.12 Port (service) coveredBy . . . . . . . . . . . . . . . . . . . . . . . 614.13 IPv4 Rule Building Blocks . . . . . . . . . . . . . . . . . . . . . . 684.14 Ipfcheck Prototype Screen shot . . . . . . . . . . . . . . . . . . . 70

xv

xvi LIST OF FIGURES

4.15 Ipf(pf) and Netfilter . . . . . . . . . . . . . . . . . . . . . . . . . 714.16 Connection Security Controller Overview . . . . . . . . . . . . . 724.17 Network Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 734.18 Connection Security Controller . . . . . . . . . . . . . . . . . . . 73

5.1 Vertical and horizontal integration. . . . . . . . . . . . . . . . . . 765.2 UML Diagram; Rules in a Rule-set . . . . . . . . . . . . . . . . . 775.3 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.4 UML Diagram; IPv4 Address . . . . . . . . . . . . . . . . . . . . 805.5 UML Diagram; FilterAction . . . . . . . . . . . . . . . . . . . . . 815.6 UML Diagram; IPv4 Protocol . . . . . . . . . . . . . . . . . . . . 825.7 UML Diagram; IPv4 Service . . . . . . . . . . . . . . . . . . . . . 83

C.1 Prototype Design Overview . . . . . . . . . . . . . . . . . . . . . 99C.2 IPv4 Rule Subsystem Design . . . . . . . . . . . . . . . . . . . . 100

Acronyms

3G Third Generation3GPP 3rd Generation Partnership ProjectBDD Binary Decision DiagramBNF Backus Naur FormBSD Berkeley Software DistributionCORBA Common Object Request Broker ArchitectureDDoS Distributed Denial of ServiceDMZ Demilitarized ZoneDNS Domain Name SystemEDGE Enhanced Data GSM EnvironmentGPRS General Packet Radio ServiceGUI Graphical User InterfaceHTTP HyperText Transfer ProtocolICMP Internet Control Message ProtocolIMAP Internet Message Access ProtocolIP Internet ProtocolIPF IP Filter (TCP/IP Packet originally developed for FreeBSD)IPv4 Internet Protocol version 4LAN Local Area NetworkmSCS Mobile Security ControllerNAT Network Address TranslationPDA Personal Digital AssistantPF Packet Filter (TCP/IP Packet originally developed for OpenBSD)RPC Remote Procedure CallsCSC Stationary Connection ControllerSSH Secure ShellTCP Transmission Control ProtocolTDD Test Driven DevelopmentUDP User Datagram ProtocolUML Unified Modeling Language

xvii

xviii ACRONYMS

UMTS Universal Mobile Telecommunications SystemVPN Virtual Private NetworkW3C World Wide Web ConsortiumXML eXtensible Markup Language

Chapter 1

Introduction

During April 2004 the Internet watchdog SANS reported 1933465 possible at-tacks on port 801(Webservers run on this port). That is close to two millionspossible attacks on web servers alone. Looking at port 135 we see that 4779301reports have been filed during the same time period. These are attacks on theWindows Directory Service port. Some programs in Windows are dependent onthis service to work correctly. Not all of the attacks are dangerous, but many ofthem are. The msblaster worm used a security hole in the service that runs onport 135. Once a computer is compromised it poses a security risk. It can beused to send spam, infect other computers or be part of a DDoS (DistributedDenial of Service) attack.

The goals of the attackers differ [30]. Some do it for fun and to gain credibility,others do it to steal information or obtain access to resources for economicgain. Other attackers just want to have control over the computer, which againenables them to use the compromised computer to send spam email or attackother targets without revealing themselves.

Numbers from the RIPE DNS Host count2 indicate that there are 18723900connected computers with a DNS entry in December 2004. The real number ofcomputers connected to the Internet is many times higher - due to the fact thatit is impossible to count connected computers behind firewalls and computersusing dialup connections. The actual number is not important here - whatmatters is that the more computers that are connected, the more attacks occurs.To make things worse a lot of the people connecting to the Internet today areunaware of how to protect themselves. Some security mechanisms exist, but afirewall is the simplest and most effective way to make it more difficult for theintruders.

1http://www.incidents.org/2ftp://ftp.ripe.net/ripe/hostcount/RIPE-Hostcount

1

2 CHAPTER 1. INTRODUCTION

However, there is a new problem emerging - new mobile phones are able todirectly access the Internet with GPRS [25], EDGE [41], UMTS [56] or otheralways connected standards. This means that turning on a mobile phone isessentially the same as turning on a computer connected to the Internet. Withthe estimated number of mobile phones in the world as high as 1.325 billion3,suddenly many new totally unprotected targets connected to the Internet exist.

1.1 Protecting the Mobile Platform

There are some differences between a computer and a mobile device, and be-tween a LAN (Local Area Network) and mobile networks. Let us take a look atthe major differences:

• Small screen

• Limited input possibilities

• Less technical users

• Mobility

• Wireless communication

• Complicated network, with partial control.

These differences make it difficult to use existing technology and methods devel-oped for stationary PC networks to protect mobile networks and devices. Newtechnologies and methodologies must be developed to provide security in themobile operator network.Both end users and network operators are at risk. The end users want to protecttheir mobile phones from attackers trying to steal information, use the phone asa base for other attacks, steal bandwidth, or just make the phone inoperable.The network operators want to protect their infrastructure and their end users.If the end user does not have a functional phone the user is not able to placeany calls or use any bandwidth. This is lost revenue for the network operator.An even worse scenario is if a large number of end user phones are compromisedand used to DDoS vital network components in the network operator’s network.This will cause a disruption to the provided services, and again loss of revenuedue to the fact that none of the subscribers are able to use the services underattack.The new network connection possibilities, like Bluetooth, and the “always onscheme” of the next generation of mobile phones (3GPP), increases the number

3http://www.cellular.co.za/stats/stats-main.htm

1.2. GOALS AND CONTRIBUTIONS 3

of possible ways for an attacker to gain access to these devices and the dataor resources associated with them. The security hazards are the same as whenconnecting an unprotected PC to the Internet. The problem increases as theavailability of services involving banking, payment, health information and so ongrows. How will ordinary users protect themselves when they start to use thesemobile phones? This is a challenge the commercial vendors and the researchcommunity should investigate further.

1.2 Goals and Contributions

To narrow the scope of the research project three specific goals were set. Thesegoals were:

• Create a firewall system suited for a hand-held device.

• Focus on management; policy to rule-set translation and communicationinterface.

• Contribute to the Open-Source community by releasing a prototype run-ning on a UNIX like operating systems under the BSD license.

The first goal is very ambitious and was not completely solved. The mainreason for this was lack of a packet filter running on the targeted platform(Symbian). Developing such a packet filter would have limited research value asthe implementation issues would be similar to those on a stationary platform.Because of this the second goal narrows the scope of the research to focusingon management issues. This meant that the main focus of the research was ondeveloping a graphical user interface concept for firewall administration suitablefor a mobile handset, and to develop logic that is able to optimize and produceanomaly free firewall configurations. The third goal is for testing purposes. Asthe mobile platform lacks an implemented packet filter it was decided to use analready implemented packet filter running on a BSD platform.

The main contribution is a set of object oriented rule-set sorting and anomalydiscovery algorithms. A prototype that implements those algorithms was devel-oped. This prototype was developed in C++ and should be able to run on mostof the UNIX like operating systems (Tested on FreeBSD, OpenBSD, Linux, andSolaris). This prototype is able to read a native IPFilter firewall configurationfile and check it for errors. IPFilter is a last hit match rule-set. No other re-search papers on firewall management issues focusing on last hit match rule-setswere found.

4 CHAPTER 1. INTRODUCTION

The second contribution of this project is a graphical user interface firewallmanagement concept suited to hand-held devices. A prototype was developedon the Symbian platform (Sony-Ericsson P800 and P900 smart phones).Finally, a generic firewall XML Schema for rule-set validation was developed.This enables the rule-set sorting and anomaly discovery prototype to store therule-set in a generic XML format. For future work this XML stream can be usedto translate the firewall configuration to different packet filter implementations(IPFilter, PF, Netfilter).

1.3 Thesis Outline

This thesis discusses the need for user-friendly security solutions in the 3Gmobile phone networks, and a possible solution to some of the current problems.The solution requires a combination of a firewall (a security feature that specifiesrules of data traffic in and out of a system) and a Graphical User Interface (GUI)(provision of easy configuration for the novice user) to operate successfully.In Chapter 2 an overview of existing firewall technologies is presented. Discussedfirst are the differences between the mobile platform and the existing platformsthat a firewall protects. The chapter also takes a closer look at why a firewallis needed on a mobile platform. How packet filtering is achieved in a firewallis explained before examining different packet filter implementations. Manage-ment issues, firewall configuration approaches and firewall system componentsare also examined.Chapter 3 takes a closer look at existing configuration and visualization con-cepts. A new concept called “Slide the Tiles” is presented. This concept issuited to firewall configuration on devices with a small screen and limited inputpossibilities.A sorting and validation engine is presented in Chapter 4. This chapter dealswith sorting of and anomaly discovery in firewall rule-sets. A set of algorithmsare proposed. A UML diagram describing the design of the basic classes of thealgorithm can be found in Appendix C. C++ source code of the essential partof the algorithm is presented in Appendix D.Chapter 5 proposes a possible XML interface to be used by the sorting andvalidation engine presented in Chapter 4. This XML interface can also be usedas a generic description of any firewall rule-sets. The complete XML Schemaand example XML streams can be found in Appendix A and B.The conclusions and future work are presented in Chapter 6.

Chapter 2

Firewall Technology

Overview

The evolution of firewalls seems to be driven by commercial interests. Thereare surprisingly few research papers regarding firewall technology and how toimprove existing implementations. However there are many papers describinghow to manage and configure firewalls [58][24][51]. This indicates that firewallsare needed, the core technology is reasonably secure and that a firewall is difficultto use and configure correctly.

The first generation of firewalls were pure packet filters. They have probablybeen around as long as the first routers. The first appearance seems to comefrom the Cisco’s IOS division in 1985 [29].

The packet filter evolved slowly as result of experience and tinkering [44]. Itreceived little attention in the research community. The biggest practical valuewas its ability to insulate applications from substantial changes in the underlyingoperating system.

The initial development of firewalls or packet filters received funding by theUnited States Department of Defense. The private sector quickly became thedriving force in the development of new firewall technology, probably becauseof the growing public interest in the Internet, and the possibility to take com-mercial advantage of that [3].

Packet filters have evolved from being a practical way for developers debuggingtheir code to one of the most important security entities on the Internet today.This trend will continue into the future, and the strongest driving force willprobably still be commercial interests. Therefore it is important that someof the development of new firewall or packet filter ideas have some roots inacademic research. This thesis discusses the need for a firewall solution running

5

6 CHAPTER 2. FIREWALL TECHNOLOGY OVERVIEW

on a mobile handset.The focus of this thesis is on packet filtering firewalls. The more advanced andcomplex proxy based firewalls are not yet needed on the mobile platform. Aproxy firewall works as a proxy between the client and the server. The clientis never able to talk directly to the server. All communications are handled bythe proxy server.Packet filters are relatively simple to configure compared to a proxy firewall, ifthe desired effect is to prevent a service like HTTP from being used by any-one, just block traffic going to port 80. A packet filtering firewall listens to thecommunications between the client and the server. If one of its filters matchesa packet part of the traffic, appropriate action is taken dependent on what ac-tion is set on that filter. A problem with packet filtering firewalls is that it ispossible to run services on a non standard port, and it is possible to tunnel aprotocol within another protocol. A proxy firewall is capable of solving thoseproblems, but with the cost of higher complexity of both the technology and theconfiguration [2]. How should an ordinary end user define a valid IMAP or SSHprotocol? Should the proxy firewall be able to understand all the subtle differ-ences between different protocol implementations? If the proxy just copies thecontent of the protocol without doing anything else, it would be the equivalentof a slow packet filter.

2.1 Firewalls on a Mobile Platform

The next generation of mobile handsets has many similarities with the PC plat-form. They both run advanced operating systems, have a processor, use sharedmemory, have Java and C++ available as development languages and both canbe connected to a network. Unfortunately this means that they also share manyof the same security problems.However there are still some major differences that make the mobile platformunique, such as; small screen size, limited user input possibilities and non-technical users. These differences make it harder to solve security related issueson a mobile platform. A configuration tool will only have a small screen to showdata on and the user must employ the often awkward input methods providedby the phone. At least they are awkward for users that are used to a mouse anda keyboard. It is also reasonable to assume that users of mobile handsets havelittle knowledge of the underlying technology due to little training and the factthat the technology is newer. This makes a mobile handset user more exposedto security threats.When connecting to the Internet the three most important assets to protect are[58]: data, resources and reputation. A firewall, as shown in Figure 2.1, will help

2.1. FIREWALLS ON A MOBILE PLATFORM 7

to protect them. A firewall is intended to be a first line of defense protecting thelocal network from possible attackers. A packet filtering firewall is a simple buteffective mechanism for filtering out malicious packets going into or out of theinternal network. It filters packet by discriminating traffic by source address,destination address, protocol, port number and flags in the headers. A proxyfirewall works as a relay agent. This may introduce performance bottlenecks,however it provides high security and granularity [57].

Figure 2.1: A traditional firewall

The new network connection possibilities, like Bluetooth [19], and the “alwayson scheme” of the next generation of mobile phones, 3GPP [1], increases thenumber of possible ways for an attacker to gain access to these devices and thedata or resources associated with them. The security hazards are the same aswhen connecting an unprotected PC to the Internet. The problem increases asthe availability of services involving banking, payment, health information, forexample, grows. How will ordinary users protect themselves when they start touse these mobile phones? This is a challenge the commercial vendors and theresearch community should investigate further. The versatile 20/80 rule [53]can be applied here; security is 20% technology, and 80% configuration. Thismeans that the highest gain in security can be made by concentrating on howwe actually configure the security [17].The “Routing problem” shown in Figure 2.2 is one of the security issues thatshould be addressed. All the different connection possibilities a mobile phonehas today makes it possible for the mobile phone to act as a router, sendingdata from one connection to another. Sometimes this is desirable, sometimes itis not. This shows that a firewall as shown in Figure 2.1 is also needed on themobile platform.


Figure 2.2: The mobile phone as a router/bridge

The phone in Figure 2.2 should be protected by firewall like technology. Thiswill protect the phone and any devices connected to it from hackers and othermalicious users operating either from the 3G network or the Internet itself.

A firewall often is the only thing that protects networks from intruders. Thismakes firewall technology a vital part of today’s network infrastructure. It istherefore logical to assume that this technology will be a vital part of the nextgenerations of mobile networks like 3G.

Members of the Panasonic Mobile Communications Development Center, in-volved with the UMTS Security Architecture project (USECA) have arguedthat until security is dealt with in a way that offers consumers some guaranteeof safety, 3G will not take off1. Security is also a major concern for the networkoperators, and they will not introduce anything until it is secure. Once 3G mo-bile phones become commonplace their broadband access will enable connectionto a variety of devices, more than normal use of our computers. These devicescan be TV, fridge, PDA, doors, security alarms, our in house PC or network, ourbusiness network and so on. Therefore once the phone is online it is susceptibleto all the risk that a normal computer faces, with the added burden that once

1http://www.btinternet.com/ stephen.wilde/secure.htm

2.2. PACKET FILTERS 9

infected it can comprise multiple sets of networks.

2.2 Packet Filters

A firewall is intended to be a first line of defense protecting the local networkfrom possible attackers. A packet filtering firewall uses simple packet matchingbased on the packets source, destination, protocol, port number or flags headervalues to discriminate network traffic going to and from different networks (seeFigure 2.3). Please refer to Chapter 4 for a more detailed description of thepacket filtering process.

Internet

Firewall

LAN

DMZ

Figure 2.3: A traditional firewall with a DMZ.

A packet filtering firewall is a device with two or more network interfaces. Eachinterface is connected to a different network. What kind of networks and howthey are segmented will differ from what the firewall is set up to protect. Acommon setup is a firewall with three network interfaces installed, where oneis connected to the Internet, the second may be connected to a subnet whereall the company’s servers are located (Often referred to as a demilitarized zone,DMZ) and the third is connected to the local network where all the user clientsreside.

Since traffic from the local network has to pass through the firewall to reach aserver on the Internet, the firewall is able to filter out undesired traffic. Suchfiltering is typically based on the criteria mentioned earlier in this section.


Filtering on source and destination address lets the firewall control who speaksto who. (As long as the packet has to pass through the firewall. If two hostsare on the same network the firewall can not intervene because the packets aresent directly between the hosts.)

Filtering based on protocol gives control over what kind of transport protocolis allowed to or from different parts of the network. It is possible to allow TCPand UDP, but deny ICMP, for example.

Filtering on the destination protocol gives the firewall the ability to allow ordeny traffic to specific services [54]. If the clients on the local network shouldbe able to surf the web, the firewall must let packets with destination port 80through.

With filtering on flags it is possible to deny packets with the SYN, ACK or anyother flags in the TCP/IP protocol [8] [6]. This can be used to gain tightercontrol of the handshake that occurs when a new connection is set up.

All the above filtering options can be combined into different filtering rules.These rules are again part of a rule-set that will enforce the desired securitypolicy. However writing and maintaining such a rule-set is a difficult job. Thisis described in greater detail in Section 2.4.

2.3 Existing Packet Filter Implementations

All the different implementations have their strengths and weaknesses. Thereare some performance differences as well [43]. Investigating different imple-mentations is important so it is possible to capture as many features and con-figuration possibilities into the generic XML packet filter configuration formatdescribed in Chapter 5.

A rule-set can either be first hit or last hit match. A first hit rule-set is traversedfrom the top until a match occurs. Then the matching packet is dealt withaccording to the associated rule action. In a last hit match rule-set the wholerule-set is traversed from top to bottom. The action taken is according to theaction field of the latest matching packet in the rule-set [54].

The following sections take a closer look at the three most common Open-Source(free software) packet filter implementations, Netfilter/Iptables, IPF and PF.

2.3.1 Netfilter

Netfilter [7] development was initially started by Rusty Russel. A core team isnow in place and is responsible for the development. Netfilter or iptables are thefirewall framework introduced the Linux 2.4.x kernel. This framework is capableof packet filtering, network address translation (NAT) and packet manipulation

2.3. EXISTING PACKET FILTER IMPLEMENTATIONS 11

such as changing different flags or fields in the IP header. It is the re-designedand heavily improved successor of the previous 2.2.x ipchains and 2.0.x ipfwadmsystems.Netfilter is configured with the user space command “iptables”. To set up afirewall usually a shell script containing the desired commands is created. Thecommands insert the packet filtering rules into the operating system kernel. Therule-set is based on first match hit. That means that the packet jumps out ofthe chain if it hits a rule that matches.The listing below shows a simple firewall setup script using the iptables com-mand.

iptables -Fiptables -A INPUT -i lo -p all -j ACCEPTiptables -A OUTPUT -o lo -p all -j ACCEPTiptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPTiptables -A INPUT -p tcp --tcp-option ! 2 -j REJECT --reject-with tcp-resetiptables -A INPUT -p tcp -i eth0 --dport 21 -j ACCEPTiptables -A INPUT -p udp -i eth0 --dport 21 -j ACCEPTiptables -A INPUT -p tcp -i eth0 --dport 22 -j ACCEPTiptables -A INPUT -p udp -i eth0 --dport 22 -j ACCEPTiptables -A INPUT -p tcp -i eth0 --dport 80 -j ACCEPTiptables -A INPUT -p udp -i eth0 --dport 80 -j ACCEPTiptables -A INPUT -p tcp --syn -s 192.168.10.0/24 --destination-port 139 -j ACCEPTiptables -A INPUT -p tcp --syn -s trancas --destination-port 139 -j ACCEPTiptables -P INPUT DROP

The Netfilter project gives a lot of insights on what is expected of a packet filtertoday.

2.3.2 IPFilter

IPfilter [5] is written by Darren Reed. However there have been many othershelping him along the way. It is under active development and new features areadded on a regular basis. IPFilter is considered by the *BSD community to beone of the most stable and reliable packet filters available.IPFilter runs on many different platforms. That may indicate that it is easy toport to a new platform. However all the supported platforms are *NIX based,so this may not be the case when porting to a non *NIX platform.The packet filter setup is stored in a config file and the rules are inserted into thekernel with the user space command “ipf”. The config file is based on last matchhit (can be bypassed with the ‘quick’ keyword). That means that a packet musttravel the whole rule-set, the last matching rule decides the fate of the packet.The listing below shows a simple configuration file for a ipf firewall.

block in on tun0


block in quick on tun0 from 192.168.0.0/16 to anyblock in quick on tun0 from 172.16.0.0/12 to anyblock in quick on tun0 from 10.0.0.0/8 to anyblock in quick on tun0 from 127.0.0.0/8 to anyblock in quick on tun0 from 0.0.0.0/8 to anyblock in quick on tun0 from 169.254.0.0/16 to anyblock in quick on tun0 from 192.0.2.0/24 to anyblock in quick on tun0 from 204.152.64.0/23 to anyblock in quick on tun0 from 224.0.0.0/3 to anyblock in log quick on tun0 from 20.20.20.0/24 to anyblock in log quick on tun0 from any to 20.20.20.0/32block in log quick on tun0 from any to 20.20.20.255/32pass out quick on tun0 proto tcp/udp from 20.20.20.1/32 to any keep statepass out quick on tun0 proto icmp from 20.20.20.1/32 to any keep statepass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 80 flags S keep state

2.3.3 Packet Filter (PF)

OpenBSD’s packet filter implementation, PF [9], was started by Daniel Harte-meier. OpenBSD originaly used IPFilter as the firewall solution for their distri-bution. However due to some licensing problems with IPFilter it was decidedthat the OpenBSD team would start develop their own firewall solution.

PF is a relatively new firewall implementation and it is somewhat unclear whichplatforms it runs on. A quick search on the Internet reports success running iton FreeBSD and NetBSD, in addition to OpenBSD.

PF is very similar to IPFilter in both configuration file syntax and behavior. Itis not so well tested and does not have the same large user group as IPFilter,nevertheless PF seems to work flawlessly in most circumstances. The OpenBSDteam has a good reputation of creating secure source code.

Having access to a relatively new and fresh implementation that has learnedsome lessons from the older implementations helped this research project byproviding high quality and well documented source code. The config file formatis similar to IPF. (Some differences like the ‘scrub’ directive are not importantin the context of this research project.)

2.4 Rule-set Management Issues

This research addresses the problem that there is no formalized way to sortor discover anomalies among packet filter rules. A detailed description of thisproblem is provided in Chapter 4. Section 4.5 proposes a set of algorithms to beused for sorting and anomaly detection in a packet filter rule-set. As a proof ofconcept the proposed algorithm was implemented in C++. The implementationis capable of validating an IPF ruleset. The results of various tests using the

2.5. FIREWALL CONFIGURATION APPROACHES 13

implementation are also presented in Section 4.5. The source code compiles inmost *NIX systems and is released under a BSD license.The idea behind the rule-sorter described in Chapter 4 is to provide the firewallcommunity with a simple and unified set of sorting and anomaly discoveryalgorithms. This would encourage greater vertical integration. One client canmanage different types of firewalls, and a firewall can be managed by differenttypes of configuration tools. To simplify this XML was used as described inChapter 5.

2.5 Firewall Configuration Approaches

Configuring a firewall can either be done manually by the user, or it can bedone more or less automatically. A quick overview of the different approachesis shown if Figure 2.4. A firewall implementation is usually a mix of severaldifferent approaches.

FirewallConfiguration

Automatic

Topology Based

Manual

TrafficBased

GUIBased

CMDBased

MatrixBased

ZoneBased

Application Based

TileBased

External Input Based

Figure 2.4: Firewall Configuration Possibilities

Automatic firewall configuration can be divided into three more specific ap-proaches; topology based, traffic based and external input based.


Topology based configurations are based on the network topology. The userspecifies the network topology including web servers, mail servers, routers andother network entities. The system then configures the firewall to protect thenetwork topology based on a defined security policy. Configuration scripts likeLutel Firewall2 and Narc3 can serve as examples of a topology based firewallconfiguration. Commercial tools like Firewall-14 from Check Point also havesupport for viewing the topology, but the configuration is not entirely dependenton the topology.

Traffic based configurations are based on what kind of traffic normally existsin a network. To configure such a firewall it is possible to put the firewall intolearning mode. When running in learning mode the firewall inspects the networktraffic to see what kind and protocols and which hosts and servers are sendingand receiving traffic. Based on that information the firewall configures itself toallow that traffic and deny everything else. Mason5 is a good example of sucha configuration approach.

External configuration based firewalls are firewalls that accept configurationdata from an external source. A firewall that only acts on behalf of an intrusiondetection system would be a example of such a firewall.

Manual firewall configuration can be divided into three types, command linebased, configuration file based and GUI based.

A command line based configuration is able to insert rules straight into thepacket filter. This can be a very powerful feature for the experienced firewalladministrator. However it can also be a very dangerous feature, as it is easyto make mistakes that will leave a security hole in the firewall configuration.Netfilter/Iptables [7] is a command line based firewall.

A file based configuration firewall reads a configuration file, parses it, and insertthe rules into the packet filter. This configuration file is usually verbose and givesthe user a more natural description of the rule-set than a command line basedinterface. However the configuration must be carefully crafted to avoid config-uration security holes in the firewall. OpenBSD/PF [9] and FreeBSD/IPF [5]are examples of configuration file based firewalls.

The GUI based firewall configuration approaches can be roughly divided into:matrix based, zone based, application based and tile based. In Section 3.3 theexisting GUI approaches will be described in greater detail. The tile basedconfiguration based approach was developed during this research project and isdescribed in Section 3.5.

2http://firewall.lutel.pl/index.php3http://www.knowplace.org/netfilter/narc.html4http://www.checkpoint.com/products/firewall-1/5http://mason.stearns.org/

2.6. FIREWALL SYSTEM COMPONENTS 15

2.6 Firewall System Components

Building a complete firewall system is a difficult task and involves a lot of difficultdesign choices. How will the finished system be used by the end user? Whatkind of packet filtering techniques should be used in the underlying layers? Howwill the system handle invalid or logically incorrect requests from the end user?In today’s object and component based development methodologies it is usefuland time saving to develop reusable components. The logical parts or com-ponents of a complete modern firewall system are; a Graphical User Interface(GUI), some logic to create a correct rule-set from the input policy (Policy Im-plementator), and the packet filter itself (Figure 2.5). Future firewall systemswould benefit if those components and their communication interfaces had beenformalized.

Figure 2.5: Firewall System Components

This would enable greater interoperability between different future solutions.This is valid both in the commercial market, and in the open source community.

2.6.1 Graphical User Interface

Keeping complicated things simple for the end user may be the most importantfactor in tomorrow’s security solutions. Security is usually a complicated issueto manage and it is easy to make mistakes. Misconfiguration of a device caneasily happen if the security is too complicated to configure correctly. Theseproblems have not yet reached the mobile platform because there are very few


security mechanisms in place for the end user to manage. The mobile phonemanufacturers are focusing on features like cameras, games and advanced calen-dars. Focusing on security will not help them sell more mobile phone in today’smarket. This does not mean that security is not needed. When the numberof users and services grow, the need for security also grows. The present de-velopment of the Internet illustrates this fact. In the late 1980s there were fewcomputers connected to the Internet and the number of services was limited.The number of users and services on the Internet has exploded, and so hasthe number of security vulnerabilities. It is natural to assume that the mobileplatform will follow a similar development.Introducing a simple graphical configuration tool reveals some problems thatneed to be addressed. Most notably there must be some logic that translatesthe graphical visualization into real firewall rules. In addition to that a higherlevel description language that describes the firewall and its rule-set would beuseful.

2.6.2 Logic Layer

To avoid configuration mistakes it is important to formalize and identify howpacket filter rules should be organized. In today’s commercial products likeFireWall-1 from Checkpoint, Trustix firewall, Watchguard, Sonicwall and othersthere is usually some logic to either automatically sort the rules, or at least tellthe user if he is doing something dangerous. However it is hard to obtainaccess to how they actually do that sorting or checking. The sorting order andalgorithms are often treated as a commercial secret, and companies are afraid torelease them because they fear that they may lose revenue. Even Open Sourceproject firewalls like Mason and fwBuilder6 seem to lack a clear policy on howthe rule-set should be sorted. In general network security applications, such aspacket filters, would benefit security wise by using a published and acceptedsorting algorithm. Chapter 4 describes a set of proposed sorting and anomalydetection algorithms. It also describes a prototype that implemented thosealgorithms to check an IPF rule-set for anomalies.

2.6.3 Packet Filter

This research project focused on management of already existing packet fil-ters. Designing and implementing a packet filter would not add any importantresearch value to this project since it has main focus on packet filtering config-uration problems. For a brief summary of existing packet filters please refer toSection 2.3.

6http://www.fwbuilder.org

2.6. FIREWALL SYSTEM COMPONENTS 17

2.6.4 Communication Interface

Having an open, reusable and easily replaceable communication interface isuseful. There are several alternatives ranging from creating a proprietary com-munication protocol to using CORBA [49]. Common Object Request BrokerArchitecture (CORBA) provides a framework for building distributed systems,regardless of the hardware or software platform. CORBA is maintained bythe vendor-neutral Object Modeling Group (OMG) standards body. A prob-lem with most CORBA implementations is that they do not implement all ofthe CORBA specifications or implement it differently from product to product.This makes CORBA unsuitable and difficult to use in a computing environmentsuch as the mobile platform.XML and XML Schema validation was chosen as the basic communication con-trol. There are several XML parser available in both commercial and free soft-ware variants for both the mobile and PC platform. For further details on howXML and Schema was utilized in this research project please refer to Chapter5.

Chapter 3

Mobile Firewall GUI

Implementation

This chapter gives an overview of similarities between stationary and mobileplatforms. Furthermore an example threat scenario in a mobile operator net-work is discussed, and existing firewall configuration approaches are examined.At last a new firewall configuration concept suitable for mobile devices is pre-sented.

This chapter will discuss the difficulties involved in creating a graphical userinterface for firewall configuration on a mobile handset. Existing approaches fora stationary platforms are investigated and evaluated.

The security on the mobile platform can be significantly increased by imple-menting a generic mobile packet filter(firewall) and a simple configuration tool.This research project focuses on the development of a graphical firewall configu-ration tool, a generic firewall description language and a prioritization and rulesorting engine.

Like the Internet, the 3G mobile networks will provide no security features otherthan authentication for the end user. A user-friendly way to configure securitywill help to give the end user the needed security and flexibility. Although Sym-bian1 has agreements with some data security companies there is no indicationthat a firewall solution like the one proposed in this thesis is being developed.However Bluefire Security Technologies2 have a firewall solution running on theWindows Mobile3 operating system. This solution is targeted towards enterpriseuse and is not very user friendly.

The GUI prototype has been implemented on the Symbian platform. There are

1http://www.symbian.com/2http://www.bluefiresecurity.com/3http://www.microsoft.com/windowsmobile/default.mspx

19

20 CHAPTER 3. MOBILE FIREWALL GUI IMPLEMENTATION

Similarities Differences

Run advanced operating systems Screen sizeHave a processor Input possibilitiesShared memory UsersJava and C++ available as development Computing powerlanguages Storage possibilitiesCan be connected to a network Different connection possibilities

(GPRS [16], IRda, Bluetooth[19], ...)Wireless transportation of data.

Table 3.1: Similarities and differences between the Mobile and PC platform.

no connection security features or firewall like technologies included in the Sym-bian OS today, and there is a need to develop a solution where the connectionsecurity can easily be configured from the mobile phone itself.

3.1 The Mobile Platform

The mobile platform has many similarities with the PC platform. There are stillsome major differences that must be addressed when developing a graphical frontend for a packet filter on a mobile platform. The similarities and differencesare presented in Table 3.1. The important similarities in the scope of thisproject are common programming languages and network connectivity. Themost important differences are size, input possibilities and different networkconnection possibilities.Due to the similarities between the next generation of mobile phones and the PCplatform it is natural to take a closer look at the threats already existing on thePC platform. Most of these threats are applicable to the mobile platform [45].The National Institute of Standards and Technology (NIST) classifies securitythreats into nine categories [13]:

• Errors and omissions;

• Fraud and theft committed by authorized or unauthorized users of thesystem;

• Employee sabotage;

• Loss of physical and infrastructure support;

• Malicious hackers;

• Industrial espionage;

• Malicious code;

3.2. EXAMPLE THREAT SCENARIO 21

• Foreign government espionage; and

• Threats to personal privacy.

The most immediate threats to a wireless device would be, fraud and theft,malicious hackers, malicious code, and industrial and foreign espionage [45].The availability of a firewall or a packet filter for a mobile platform with asuitable configuration tool would help solve these security issues by restrictingthe communication possibilities both into the device and out from the device.

3.2 Example Threat Scenario

On July the 16, 2003 Microsoft released Security Bulletin MS03-026, BufferOverrun in RPC Interface Could Allow Code Execution4. This security bulletinhad the severity rating of “critical” and all Windows (not Millennium, 95 and98) users were urged to patch their systems immediately.On August the 11, 2003 CERT Advisory CA-2003-20 W32/Blaster worm wasreleased5. This worm reportedly used vulnerabilities in the Microsoft remoteprocedure call (RPC) Interface. Measurements by Symantec showed that theaverage time it took for an unprotected PC to become infected after it connectedto the Internet was about 25 minutes6.The worm affected end users by automatically shutting down the computerwithout leaving the end user any choice. (Writing the command shutdown /aon the command line would stop the shutdown, but that is hardly commonknowledge for ordinary Windows users). This made it particularly hard for theinfected PC to download any patches or any information on how to removethe worm. This was not the desired effect of the worm, however this was howmost users discovered that they had the worm on their system. Once installedon the host computer it tried to infect other PCs in the network. The maingoal of the worm was to launch a DDoS attack against windowsupdate.com atcertain dates. (This was stopped by removing the DNS record of the domainwindowsupdate.com).Even though the worm did not create the havoc it could have on the Internet,due to limitations in the way the worm was coded to infect other machines, itstill highlighted some major security problems. The worm used a well knownsecurity exploit in the RPC interface. This meant it could happily infect othermachines without any user intervention (like opening a executable or clickingon a link in a email or on a web page). Even though the security exploit was

4http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx5http://www.cert.org/advisories/CA-2003-20.html6Alfred Huger, Symantec


well know almost a month before the attack occurred, only a few systems wherepatched, most notably servers run by professional administrators. This is aproblem because many of the Internet users are home users with no knowledgein how to protect themself from these threats.Normal virus scanners running on computers were not able to stop the worm.Since the worm spread by connecting itself to the computer and then exploitinga security flaw, pure virus scanners were not able to stop the virus [10]. Howeverstopping the worm with a firewall is quite easy: Just block access to the com-puter on port 135 (TCP, DCOM RPC). Which was the port used by the wormto connect to and infect the PC. To prevent the PC from infecting others, allthat had to be done on the firewall was to block port 69 (UDP, TFTP) and port4444. This would make it impossible for the worm to contact and infect anyother hosts. A normal corporate firewall effectively stopped the worm, howeverif an infected laptop was connected to the corporate LAN, either physically orby a VPN link, it could easily infect any other unprotected PC on the samecorporate LAN. It is important to take a note of this, because it shows thateven if the border security is well implemented and administered, it is still easyto be infected by worms like MS Blaster and it variants. It is important to pro-tect the network in depth, not just rely on the border protection a traditionalfirewall provides [54].To summarize the W32.Blaster.Worm

• It used a well known vulnerability. This works because users do not patchtheir systems frequently.

• End users were affected. The worm was not designed to harm anything,but it is annoying to have the computer restart every so often.

• Local Network was affected. Infected hosts generated a lot of traffic whentrying to compromise other hosts.

• Internet was affected. Compromised hosts were programmed to be partof a DDoS attack against windowsupdate.com

• Easy to stop. Just by having a firewall installed. By blocking port 69, 135and 4444.

Imagine a well written blaster like worm on the 3G mobile network. Mobilephones are getting more and more similar to a PC. They have a moderatelyfast processor and they run their own operating system such as Symbian orthe Windows Mobile solution from Microsoft. It is reasonable to presume thatthose operating systems will encounter some of the same security problems theoperating systems on the PC platform are struggling with today. Operating

3.2. EXAMPLE THREAT SCENARIO 23

systems are large and complex software components and therefore it is difficultto avoid bugs or design flaws that can be exploited by malicious software suchas worms.

Let us pretend that the Mobile.Blaster worm has the same characteristics asthe original blaster worm. It infects connected hosts, then seeks out possiblynew hosts to infect. It then shuts down the host, and at a certain date itis programmed to participate in a DDoS attack against a predefined vendorservice. The affected parts in this mobile scenario are the mobile phone users,network operators, phone resellers, phone manufacturers, OS providers and theservice providers. The following paragraphs take a closer look at how each ofthese entities are affected and why.

Mobile phone users would not be able to use their phones properly if they shutdown randomly. Today users pay per transferred bytes on the mobile network.As a result the user will actually pay for being part of a DDoS attack againsta predetermined service. The end user will also have to pay for the bandwidthused by the worm to spread to new hosts.

Network Operators would lose revenue by randomly disconnecting phones. Peo-ple would not be able to make phone calls or use any bandwidth. As long asthe subscriber phone is out of order the network operator loses revenue becausethe subscriber is not able to make any calls or use any bandwidth. A lot of endusers would refuse to pay for the bandwidth caused by the worm. Such a wormwould cause a lot of damage to the trust of the network operator, and the costof cleaning up after the worm would be significant. In addition, other serviceswill suffer because the worm itself is using a significant part of the available ofbandwidth, thus blocking any legitimate network traffic. This causes an evenlarger loss of revenue for the operator.

End users would approach the phone reseller to sort out the problem with theirmalfunctioning phone. With a fast spreading worm their ability to offer supportto the phone users would be limited. Resellers would not be equipped or havethe resources to cope with the vast number of customer support cases causedby a Moble.Blaster worm.

Phone manufacturers have to help the struggling resellers with their supportneeds. They also need to provide a fix for the problem quickly because theirreputation is at stake. If it is known that any users of a particular brand weremore severely affected than others they will lose market shares.

OS providers would eventually have to come up with a fix to the problem.Meanwhile all the phone manufacturers that have licensed their OS are callingfor a solution. Even thought the OS providers would not be in the publicspotlight at first, this would change after the problem is fixed. After all it wasa flaw in their system that caused the problem. This may cause the phone


manufacturers to choose another operating system for their next generation ofmobile phones.

Service providers will not be able to sell their services. With a loss of revenueas the result. They may discontinue support for troubled phones or operatingsystems. Thus further damaging the consequences for the manufacturers or theOS providers.

There is alarmingly little happening on the security side of mobile phone devel-opment. The focus is on how to attract customers with multimedia and other“flashing lights”. Security is not yet an end user sales argument.

To stop a worm like the one described above, the only thing needed to was asimple packet filtering firewall. However the firewall should be designed for themobile market. This work discusses and solves the major obstacles in imple-menting such a firewall system on a mobile handset.

3.3 Existing Firewall Configuration Approaches

There are a few firewall configuration visualization concepts currently known.Most of them aim to make the life of a network administrator easier. Settingup firewalls can be a daunting task, especially if the organization has severalfirewalls and a complicated security policy. Having an easy to use firewall config-uration tool makes the possibility for misconfiguration less likely. The technicalquality of today’s firewalls is very high, so focusing on simplicity of the config-uration tool would be likely to give the greatest gain in security.

Every firewall has a set of rules that defines what action is to be taken whenspecific events occur. A rule-set can drop all IP-packets originating from aspecified IP-address and it can allow other packets through. A rule-set is whatenforces the defined security policy on the firewall. In its crudest form a rule-set is only a set of kernel calls. In newer Linux kernels this would be thenetfilter/iptables part of the kernel [7]. Since normal users don’t like to writesmall C programs that uses those kernel calls just to configure the firewall, auser-space tool is usually provided. In Linux this is iptables. An example of theiptables commands to set up a small firewall is shown in Figure 3.1.

Even with the use of command line tools like iptables, configuring a firewallis a difficult task. Another abstraction layer is needed. The following sectionscontain a brief overview of some of the visualization concepts that exist on thecommercial market for configuring firewalls.

3.3. EXISTING FIREWALL CONFIGURATION APPROACHES 25

Figure 3.1: Iptables Example Shell Script

3.3.1 The Matrix Approach

This is probably the most common way to present the firewall configuration tothe user. All the filtering rules and the corresponding actions are presented ina matrix. Most of the firewalls on the commercial market seems to use thisapproach.

Using a matrix like the one shown in Figure 3.2 has some benefits. It is flexibleand usually presents the user with all the underlying features of the packetfilter. Since it is used extensively for presenting the rule-set, it will be familiarto persons with firewall configuration experience.

Users with no firewall knowledge will probably not benefit from this approachbecause they don’t have any understanding of the underlying technology. Thusthe rule matrix will probably mean nothing, or at least be unintuitive.

The matrix approach also requires a considerable amount of screen estate. With-out seeing the different entries at the same time it will be difficult to see theactual effect of one rule in a large rule-set.

Rule entry position in a matrix matters. A rule that allows traffic too early ortoo late in the matrix can cause unintended holes in the firewall (short circuit).The application would probably issue a warning if a rule short circuit like thatwas attempted, however the principle with the matrix remains; the position ofthe rule in the matrix decides where the packet goes. Chapter 4 proposes a setof algorithms to help the end user create a rule-set with the correct order of therules.

Bluefire Security Technologies develops mobile and wireless security software


Figure 3.2: Screen shot from Innertek fBuilder

that protects hand held devices and data. The company’s flagship product, theBluefire Mobile Firewall Plus solution, provides a firewall, intrusion prevention,integrity management, encryption, device authentication and policy-based en-terprise security management features that enable the safe use of mobile andwireless applications. This is a matrix based solution implemented on a mobile(PDA) platform.

3.3.2 Zone Policies

Instead of presenting the ruleset in a matrix, the Trustix developed firewall [11]divides the screen into zones as shown in Figure 3.3. Each zone represents onenetwork device connected to a network segment. The users can then implementa security policy by defining objects in the zones, and decide what traffic isallowed or disallowed by drawing arrows between different objects or zones.

The user does not need to specify rule priorities. The application creates theappropriate rule-set according to the default defined policy. This makes it veryintuitive. It makes it easy for another administrator to see how the firewall isconfigured.

This approach requires a lot of screen estate. It is not as flexible as the matrixapproach, because the matrix represents a direct mapping to the rule-set. The

3.3. EXISTING FIREWALL CONFIGURATION APPROACHES 27

Figure 3.3: Screen shot from Trustix Firewall

Trustix firewall interprets the policy and then creates a firewall rule-set.

3.3.3 Application Approach

Personal firewalls use an application approach which is more concerned withwhat sends or receives the packet rather than how it is done. The personalfirewall asks the user which programs should be able to send or receive data,and sets up a firewall according to that information. This approach is suitablefor protecting one computer, and not routing firewalls. A sample GUI is showin Figure 3.4.

This is a suitable solution for novice users. The users only need a basic under-standing of how a computer and a network function. Since the firewall operatesat the application level, it hides the intricate and often difficult task of settingup manual filter rules.


Figure 3.4: Screen shot from ZoneAlarm

3.3.4 Summary of existing visualization concepts

No configuration approach was found that is suitable for implementation onthe mobile platform. The main reasons for this are small screens, limited userinput and limited knowledge of underlying technology at the end user. Address-ing these limitations is the focus of this research. The factor of a larger andmore non-technical user mass is also important. A new visualization concept isneeded. A proposed solution to this problem will be presented in the followingsections.

3.4 Graphical Firewall Configuration Tool

Two factors make the task of creating the GUI challenging. Firstly, the sizeof the screens on mobile devices. They are typically small and have limiteduser input options. Secondly, the users typically have no understanding of thetechnology and are not particularly interested in how it works; only that itworks. Hence our goal is to develop a GUI simple enough for anyone to use,and advanced enough to configure a complex firewall system.

Developing a graphical configuration tool for firewall administration on a mobileplatform is not trivial. Due to the non-technical nature of ordinary mobile phoneusers it must be very simple and intuitive to use. The tool must hide some ormost of the complexity in today’s firewall mechanisms. By doing so one expectsto lose functionality and flexibility. It is important to find a balance that works.

The graphical presentation of the firewall configuration must take up little screenestate, be somewhat familiar to non-technical users, and expandable so new

3.5. VISUALIZATION CONCEPT 29

communication units can be added to the mobile phone. If for instance an802.11b [38] wireless interface is added to the phone, the configuration toolshould be able to reflect that change. This makes the user aware of the change,and the user is instantly able to configure the device in a familiar way.

3.5 Visualization Concept

A new visualization concept called “Slide the Tiles” was developed as a part ofthis research project. The idea itself was conceived when working on anotherfirewall project, but the idea was never realized. The original ideas have beenimproved and refined during this project. It is important to take note that theprinciples used are not based on any user interface principles. It was beyondthe scope of this project to measure the effect of the user interface on differentgroups of mobile phone users.

Everything that can send or receive data on a mobile phone is visualized in a tile.Typical tiles would represent the Bluetooth, GPRS, IRda and serial interfaces.The mobile phone itself is also given a tile because it is able to send and receivedata from applications running on it.

The concept consists of four main components; surrounding tiles, the centre tile,nodes and relations to and from the centre tile.

Figure 3.5: Slide the Tiles Overview

Figure 3.5 shows a generic layout of the concept. The tiles are surrounding thecentre tile. The relationships between the centre tile and other tiles are shownas arrows. A tile can also contain nodes. The four main components will nowbe described in greater detail.


3.5.1 Surrounding Tiles

A surrounding tile can hold or be given certain properties. It can be a host on anetwork, the network itself, a network device, a file on a computer, a directory,a user, a peripheral connected to the computer or any other device or propertyin a computer system. The possibilities are many, and should not be limited tothe way we are used to organize and view things in today’s computer paradigm.

The placement of the tiles does not matter. Any of the surrounding tiles canswap positions without changing the underlying data model. In other words itis only the view, not the model that changes [37].

3.5.2 Centre Tile

All of the surrounding tiles can act as a centre tile. There is no differencebetween the centre tile and the surrounding tiles with regard to what kind ofinformation or entity the tile represents. The centre tile is the only tile thatshows its relations to other surrounding tiles. This reduces the complexity andmakes it possible to visualize complex policies on a device with small screens.

3.5.3 Relations

A relation is any kind of action or policy that can be applied on the two tiles therelation points to. It is visualized as an arrow pointing from the centre tile to asurrounding tile. A relation can represent read or write access permission in afile system, actions like deny or allow in a firewall system or any other action auser or a device can do in a computer system.

A relation is directional with the direction indicated by which direction anarrow points. Figure 3.6 illustrates a possible usage of relations in a firewallconfiguration GUI.

In Figure 3.6 the user is placed in the centre tile, all relationships betweenthe user and the other devices are shown. The user in this context is the mo-bile phone itself running different applications. The configuration in Figure 3.6means that any applications running on the mobile phone can send and receivepackets from the GPRS interface. The applications are also able to initiate com-munication via the Bluetooth interface. However no Bluetooth device is allowedto initiate a communication channel with the mobile phone. If no relationship isindicated the default is to deny the traffic. This means that no traffic is allowedto occur between the user and the IRda and serial interfaces.

3.5. VISUALIZATION CONCEPT 31

Figure 3.6: User in the centre

3.5.4 Nodes

To allow a more fine-grained control without a dramatic increase in the numberof tiles visible on the screen at the same time each tile can contain several nodes.A node represents a tile within a tile. This gives the user a more fine grainedcontrol over the relations between tiles. If all the nodes within two tiles have thesame properties on the relation, this would be equal to set a relation between theparent tiles. However if one or several of the nodes have different properties ontheir relations, the relation arrow between the the parent tiles should indicatethis. The user can then choose that relation and zoom into the nodes of the twocorresponding parent tiles.

Figure 3.7 show how nodes and fine grained control is visualized. The relationarrow between Tile 2 and the centre tile is solid, indicating that all the nodes(B1,B2 and C1,C2) in the corresponding parent tile share the same relationproperties. The relation arrow between Tile 1 and the Centre Tile is dottedindicating that there are different relation properties between the nodes in thecorresponding parent tiles. To visualize the exact properties of the relationbetween the nodes the user can choose to expand the view, as shown to theright in Figure 3.7. It shows all the nodes expanded into tiles. This makes itpossible to set specific relations between nodes.


Figure 3.7: Fine-grained control

3.6 “Slide the Tiles” Implementation

To explain the features of the implemented “Slide the Tiles” GUI concept weuse the scenario described in Figure 3.8. This case contains the following:

• Mobile User 1 - Connected to an ordinary mobile network (GPRS, 3G).

• Television Set - Bluetooth enabled. Is able to show pictures sent from thephone.

• Car - Bluetooth enabled. Makes it possible to retrieve service history andthe current state of the car.

• Mobile User 2 - Connected to an ordinary mobile network.

• Laptop - Usually connected to Mobile User 2’s mobile phone with a cable.Sometimes a 802.11b wireless option is used.

• Internet User - Friendly Internet user that wants to send data to the mobileusers. (A document to Mobile User 1 and hold a presentation on Mobileuser 1’s television set.)

• Server - Runs ssh, http and ftp.

• Trusted Workshop - Mobile User 1’s workshop.

The pictures describing the user actions in the following sections are actualscreen shots from a prototype implementation running on a SonyEricsson P800smartphone. The prototype implementation uses solid colored arrows to deter-mine the action of the rule. A red arrow translates into deny traffic, while a

3.6. “SLIDE THE TILES” IMPLEMENTATION 33

Figure 3.8: Example Case

green arrow translates into allow traffic. If an arrow is dashed this indicatesthat contradicting rules between some of the nodes within that tile exists.

3.6.1 Case 1 - Presentation on TV

Internet User wants to hold a remote power point presentation on Mobile User1’s Television set. The mobile handset must be configured to allow such trafficto be routed safely from the mobile network interface (GPRS, 3G) throughthe phone and out on the Bluetooth interface. This must be done withoutcompromising the security of the phone, or allowing other malicious users tosend data to the television set or any other connected devices.

The screen shot of Step 1 (Figure 3.9) shows a top view of all the tiles. Notraffic is allowed between any of the tiles. This means that the firewall doesnot allow any traffic to, from or through the handset (indicated by red arrows).The implementation uses red arrows to indicate that no traffic is allowed. Thiscould also have been visualized by no arrows between the two tiles where notraffic is allowed (no relation, no traffic).

In Step 2 (Figure 3.9) the user clicks on the arrow pointing from Internet tothe Bluetooth interface. The user wants to allow some traffic from Internet toa Bluetooth device connected to the phone. (Traffic from the Internet to theTelevision set). To do this without opening up traffic to all the connected Blue-tooth devices, the users must choose the details option to get a more detailedview of the configuration possibilities.


Figure 3.9: Case1 (part1)

Step 3 (Figure 3.9) shows the screen after the user has chosen to set the detailsof the Internet and Bluetooth tile. The Internet tile contains three nodes andis expanded to three new tiles: EMail, JohnDoe and WEB. The Bluetooth tilealso has three nodes: Car, Television and Mobile User 1. The EMail and theJohnDoe tiles are grayed out because it is not possible to set rules between theweb tile and those tiles. It is not possible for the firewall to stop traffic betweentwo nodes on the same interface. The status bar on the bottom of the screenshows which parent tiles the user is currently looking at. The back button isalso active, indicating that it is possible to return to a parent view.



In Step 4 (Figure 3.10) the user has put the JonDoe tile in the centre. Thisallows the user to set rules to and from this tile.

Step 5 (Figure 3.10) shows the user clicking on the rule from the JohnDoe tileto the Television tile. The intended action is to change the rule to allow datatraffic to flow from the Internet through the handset and to the television set.

As the screen shot in Step 6 (Figure 3.10) shows the user has now success-fully changed the deny rule to an allow rule. This allows JohnDoe to show hispresentation on the television set (indicated by a green arrow).


Step 7 (Figure 3.11) shows the parent view. The rule pointing from Internetto Bluetooth is now a deny rule with exceptions (indicated by a dashed redarrow). This tells the user that the default policy between those tiles are deny,but there exists exceptions. The firewall is configured to allow traffic to theTelevision node in the Bluetooth tile.

3.6.2 Case 2 - Giving Workshop access

Mobile Users 1 owns a car that has a Bluetooth interface. Through this inter-face it is possible to get information about the general condition of the car. Theuser is very fond of his car, but is totally reliant on a workshop to remind himof services and other potential problems with his car. As a customer service theworkshop offers to monitor the car and if any serious problems occur immedi-ately schedule an appointment. However if a less serious fault is found, schedulean appointment at an off-peak hour, and thus reduce the price.

For this scenario to work the mobile handset must be set up to allow traffic tobe routed from the car and to the trusted workshop when the car is within range(10m) of the handset. Information must be allowed to flow in both directions.


If the car is out of range, any packets coming from the workshop should bestopped.


In Step 1 (Figure 3.12) the user looks at the parent view of the tiles in thefirewall configuration. This view looks almost identical to the setup in Step 7in the first case (Figure 3.11). A closer examination of the Internet zone revealsthat there is one additional node. This is shown with 4 small node icons insidethe tile.Step 2 (Figure 3.12) shows the user selection details to allow for a more finegrained control of the traffic through the handset.The screen shot in Step 3 (Figure 3.12) shows the details of the Internet tile andthe Bluetooth tile. The only difference from Case 1 is that a workshop node isadded to the Internet tile. This node represents the server the workshop has onthe Internet.The user now wants to allow traffic from the workshop to the car. This is doneby clicking on the rule and then choosing allow on the pop up menu. This isshown in Step 4 (Figure 3.13).The screen shot in Step 5 (Figure 3.13) shows the results from the action in step4.In Step 6 the user has also allowed traffic to be initiated and sent from the carto the workshop. A connection can now be initiated by both parties (indicatedby two green arrows). This is necessary to allow the car to automatically sendstatus reports to the workshop, and to allow the workshop to automaticallycheck the car for faults. (That is, if they have some spare workshop time theywant to sell cheap, they can poll available cars to see who may need sometuning.)




Step 7 (Figure 3.14) shows the resulting parent view. The deny rules going toand from the Internet and Bluetooth tile are both dotted. This shows the userthat there is an exception from the default deny policy between some of thenodes in those tiles.


3.6.3 Case 3 - Restricting services

The handset runs several services. Only a handful of these should be allowed tosend and receive packets on the mobile network interface (GPRS, 3G). Howeveron the Bluetooth and serial interface almost all of the services should be allowedto receive and send data.


Step 1 (Figure 3.15) starts with no traffic passing to or from any tile. Thismeans that the phone effectively stops all traffic to, from or trough the phone.

To allow for a more fine-grained control of the traffic the user chooses to seethe details between the Internet and the P800 tiles. Step 2 (Figure 3.15) showsthe resulting screen. It shows the applications running on the P800; Email andOpera. Secondly it shows some well defined protocols on the Internet; IMAPand HTTP. The IMAP tile is grayed out because it is not possible to set rulesbetween two protocols. In theory it is possible to set a rule with different sourceand destination port, but that would severely confuse any end user. In this caseboth of the protocol tiles reside on the interface (Internet) thus it is not possiblefor the firewall to filter traffic between those tiles.

To allow the Email client running on the phone to check and download e-mailfrom any IMAP server on the Internet the user creates an allow rule (Greenarrow) from the Email tile to the IMAP tile. This is shown in Step 3 (Figure3.15).

Step 4 shows the parent tile view. The rule from the P800 tile to the Internettile is now dotted. There is a rule between two nodes within those tiles that havea different action. The default action between the P800 tile and the Internettile is deny, but the the Email client is able to access mail.



The user now wants to configure the Bluetooth device. In Step 5 (Figure 3.16)the user has dragged the Bluetooth tile to the centre. The screen now shows allthe rules between the Bluetooth tile and the surrounding tiles.Step 6 (Figure 3.16) shows that the user has changed the default policy betweenthe Bluetooth tile and the Internet tile to allow (Indicated by green arrow).However the arrow is dotted. This tells the users that there are some morespecific rules with a different action between some of the nodes in those tiles.


In Step 7 (Figure 3.17) the user is looking at the nodes in the Internet andBluetooth tiles. The user wants to allow HTTP traffic from the Laptop, that isconnected to the phone with Bluetooth, out to the Internet. This means that


the user can surf the web using the phone as a data carrier. The same is alsopossible with the Mobile User 1.Step 8 (Figure 3.14) shows the same as Step 7 but IMAP as the protocol insteadof HTTP. This means that both the laptop and Mobile User 1 can read theirmail using the phone as a data carrier.The parent tile view is shown in Step 9 (Figure 3.17). The rule from the Blue-tooth tile to the Internet tile is now solid green. This tells the users that all thenodes in the two tiles correspond to the policy.

3.7 Summary

The security on the mobile platform can be significantly increased by imple-menting a generic mobile packet filter and a simple configuration tool. Just likethe Internet the 3G mobile networks will provide no security features for theend user. A user-friendly way to configure the connection security will give theend user the needed security and flexibility. Although Symbian has agreementswith some data security companies there is no indication that a firewall solutionlike the one proposed in this thesis is being developed.This chapter presented a graphical firewall visualization concept suited for hand-held devices. The proposed solution solves the problem with small screens andlimited input possibilities. This is done by dividing the screen into tiles thatrepresent different network entities. The firewall configuration is determined bythe relations between the tiles. A relation is visualized by an arrow between twotiles. The arrows also have different color dependent of what kind of relationtwo tiles have. A red arrow between two tiles would translate into deny alltraffic from the network entity represented by the first tile to the network entityrepresented by the second tile.The “Slide the Tiles” concept was informally tested on people with technicaland non-technical background. People with technical background and with anunderstanding of Internet related security problems quickly felt at home with theproposed concept. However non-technical people saw the point in configuringthe security in the first place. For a security mechanism to be effective in amobile environment the process must be automated. An automated securityservice provided by the network operator is probably the optimal solution.

Chapter 4

Sorting And Validation

Engine

The main goal of this chapter is to be able to sort and discover any anomalies inexisting firewall rule-sets configuration formats. This will help improve securitywhen implementing a firewall security policy. The following sections take a closerlook at how packet filters work and existing sorting prioritizing approaches. Atlast the proposed algorithms for anomaly avoidance and detection is presented.

The proposed sorting and anomaly discovery algorithms described in later sec-tions uses an object oriented approach. It is beyond the scope of this thesis todiscuss object oriented development [27][47] and the benefits. A rule is definedas a rule object. The rule instance contains instances of the objects address,protocol, service and action. This is explained in greater detail in Section 4.5.For source code examples please refer to Appendix D.

4.1 Packet Traversal of a Firewall

A packet filtering firewall uses rules to determine what action to take whenmatching packets arrives at the firewall. A rule tells the firewall how to matchan incoming or outgoing packet and what to do with that packet if a matchoccurs. A rule matches some or all of the fields source address, destinationaddress, protocol and service (port). Other fields in a TCP/IP packet like flagsand destination port is also used.

One rule is not sufficient to do any filtering usable for securing a network or acomputer. To be able to effectively filter out undesired traffic and let desiredtraffic through the rules are combined into a rule-set. A sample rule-set and adiagram showing how TCP/IP packets would traverse the firewall is given in

41

42 CHAPTER 4. SORTING AND VALIDATION ENGINE

Figure 4.1. This sample rule-set is a first hit match rule-set. When a packettraverses the rule-set it stops at the first matching rule. It then looks at theaction field to determine what to do with the actual matching packet. A lasthit rule-set traverses the whole rule-set, then look at the last matching rule todetermine what to do with the matching packet.

Figure 4.1: TCP/IP Packet Traversal of a Firewall

When a packet arrives at the firewall it is matched against the rules in thefiltering rule-set. Packet P1 in Figure 4.1 matches the first rule, R1. Since thisis a first hit match rule-set, the firewall then immediately looks at the actionassociated with that rule. The action is allow so the packet is allowed to passthrough the firewall. Packet P2 does not match any of the three first rulesin the rule-set. However it matches the last catch them ally deny rule in therule-set. The packet is discarded. Having such a general restrictive rule at theend of the rule-set ensures that if no packets are matched to any previous rule,the packet is simply rejected. This is according to the restrict first, open laterprinciple [54]: Start with the most restrictive rule-set possible, block all trafficin and out, then start to open up to traffic according to specific needs. Thismakes it easier to avoid costly security mistakes.

A difference between existing firewall implementations is if they perform last-hitmatching or first-hit matching. This refers to how a packet is matched when ittraverses the firewall rule-set. In a first hit-match based rule-set, the packet isdealt with according to the action field as soon as a match occurs. In a last-hit

4.2. EXISTING SORTING AND PRIORITIZING APPROACHES 43

match firewall the packet is checked against the whole rule-set. The action takendepends on the last match in the rule-set.

4.2 Existing Sorting and Prioritizing Approaches

This section examines existing approaches to sort and validate firewall rule-sets.Even though firewall security gets attention from the research community, themain focus of that attention is on performance issues and hardware support [26][34][55]. Another focus area in firewall research is development of high levelpolicy languages [20][23] [40][4][18]. Some researchers also examine the designof the firewall [46]. Only a few papers relate to anomaly discovery in rule-sets. Apaper by Adiseshu, Suri and Parulkar [14] discusses the problem when a packetcan match to possible or more filter rules. This is in Section 4.2.2 referredto as a correlation. A correlation is hard to detect manually by a firewalladministrator. This paper is good as background information and at discussingproblems regarding firewall management and fault discovery. However due tothe lack of other anomaly discovery discussions no part of this paper was directlyused in this research project. The most relevant papers will now be examinedin greater detail.

4.2.1 Binary Decision Diagrams

Hazelhurst, Attar and Sinnappan proposes to use a reduced binary decisiondiagram (BDD) to represent a firewall rule-set [52]. BDDs have the potentialsto speed up lookup, assist with analysis and possible integration with hardware.

The paper presents a technique for representing a rule-set as a boolean expres-sion using BDDs. The authors introduce a set of algorithms that can be usedto analyze a rule-set to help validate it, and to understand the effect of changesmade to the rule-set. A simple prototype of a graphical user interface that aidsthe user in analyzing the rule-set is proposed. Using BBDs it is easy to presentthe rule-sets in different formats depending what the user’s wants to examine.The authors also discuss how the BDD representation can be for fast lookups,and as a basis for hardware support.

There are two important properties of BDDs. They are a compact representa-tion of boolean expressions, and given a variable ordering the BDD representa-tion of an expression is canonical. This means that checking equivalence can bedone with little resources once the BDD is constructed.

This approach makes it easy to visualize the effect a new rule have on a rule-set.The paper does not cover error detection or any other kind of automatic faultdetection it was only used as background material in this research. The biggest


contribution of this paper was to show the impact of new rules added to therule-set.

4.2.2 Policy Tree

Al-Shaer and Hamed proposed to use a policy tree to visualize and find rule-setanomalies [33][32][15]. They represent the filtering policy by a single rootedtree. This tree model allows easy discovery of relations and anomalies amongthe rules. Every field in the filtering rule is represented by a node in the tree.Each branch of this node represents a possible value of the associated field. Theroot of the tree represents the protocol field, the leaf nodes represent the actionfield, and intermediate nodes represent other network fields. Every tree pathstarting from the root and ending at a leaf represents a rule in the policy. Rulesthat have the same field value at a specific node, will share the same branchrepresenting that value.

To discover anomalies in a rule-set it is possible to determine if any two rulescoincide in the same policy three path. This is the case if they are exactlymatching inclusively matching or correlated. To insert a rule in the tree, eachfield in the rule is compared with existing branches at the node representingthis field. If at a given node the field is a subset or equal to a branch, the rule isinserted in this branch. If the field is a superset of a branch, the rule is insertedin the subset branch, and a new branch is created at this node. If there was nomatch a new branch is created at this node. If the rule coincides with anotherrule on any of these paths, there is a potential anomaly. The type of anomalycan be determined using the definitions proposed by the authors.

Al-Shaer and Hamed formalizes the firewall rule relations. They define all thepossible relations that may exist between any rules in a rule-set. They alsoclaim to show that no other relations exist.

They define the possible relations as follows:

Definition 1. Rules Rx and Ry are completely disjoint if every field in Rx isnot a subset and not a superset and not equal to the corresponding field in Ry.

Formally, Rx and Ry are completely disjoint if:

∀i : Rx[i] 6./ Ry[i]

where ./∈ {⊂,⊃,=}, i ∈ {protocol, src ip, src port, dst ip, dst port}

Definition 2. Rules Rx and Ry are exactly matched if every field in Rx isequal to the corresponding field in Ry.

4.2. EXISTING SORTING AND PRIORITIZING APPROACHES 45

Formally, Rx and Ry exactly matches if:

∀i : Rx[i] = Ry[i]

where i ∈ {protocol, src ip, src port, dst ip, dst port}

Definition 3. Rules Rx and Ry are inclusively matched if they do not exactlymatch and if every field in Rx is a subset or equal to the corresponding field inRy. Rx is called the subset match while rule Ry is the superset match.Formally, Rx inclusively matches Ry if:

∀i : Rx[i] ⊆ Ry [i] and ∃j such that : Rx[j] 6= Ry[j]

where i, j ∈ {protocol, src ip, src port, dst ip, dst port}

Definition 4. Rules Rx and Ry are partially disjoint (or partially matched) ifthere is at least one field in Rx that is a subset or a superset or equal to thecorresponding field in Ry, and there is at least one field in Rx that is not asubset and not a superset and not equal to the corresponding field in in Ry.Formally, Rx and Ry are partially disjoint (or partially matched) if:

3 i, j such that Rx[i] ./ Ry[i] and Ry[j] 6./ Ry[j] and i 6= j

where ./ ∈ {⊂,⊃,=}; i, j ∈ {protocol, src ip, src port, dst ip, dst port}

Definition 5. Rules Rx and Ry are correlated if at least one field in Rx is asubset to the corresponding fields in Ry, and at least one field in Rx is a supersetof the corresponding field in Ry, and the rest of the fields in Rx are supersets ofor equal to the corresponding fields in Ry. 1

Formally, Rx and Ry are correlated if:

∀i : Rx[i] ./ Ry[i] and 3 i, j such that : Rx[i] ⊂ Ry[i] and Rx[j] ⊃ Ry[j] and i 6= j

where ./∈ {⊂,⊃,=}; i, j ∈ {protocol, src ip, src port, dst ip, dst port}

A more formal presentation of these relations and how they are used to validateour sorting algorithm follows in Section 4.5. The authors claim that theserelations are distinct and complete. That means that only one relation canrelate Rx and Ry, and no other relation between Rx and Ry can exist. This ispresented in the following two theorems that the authors claim to have provenin [42].

1Minor correction to the original text to emphasize the importance of the existing of atleast one subset field pair and at least one superset field pair. The formal mathematicalexpression is correct in the original paper.


Theorem 1. The relations defined above are distinct; i.e. any two k-tuple filtersin a firewall policy are related by only one of the defined relations.

Theorem 2. The union of these relations represents the universal set of rela-tions between any two k-tuple filters in a firewall policy.

The paper also describes and defines four possible firewall anomalies. That isif there exist two or more different filtering rules that would match the samepacket. Pleas note that these anomalies are based on a first-hit match packetfilter. The algorithms later in this chapter uses last-hit packet filter matching.The anomalies discussed are:

Anomaly 1. Generalization anomaly. A rule is a generalization of anotherrule if this general rule can match all the packets that match a specific rule thatprecedes it. Rule Ry is a generalization of rule Rx if Ry follows Rx in the order,and Ry is a superset match of Rx, and the actions of Rx and Ry are different.Formally:

Rx[order] < Ry[order], Ry inclusive matches Rx, Rx[action] 6= Ry[action]

Anomaly 2. Redundancy anomaly. A redundant rule performs the same actionon the same packets as another rule such that if the redundant rule is removed,the security policy will not be affected. Rule Ry is redundant to rule Rx if Rx

precedes Ry in the order, and Ry is a subset or exact match of Rx, and theactions of Rx and Ry are equal. If Rx precedes Ry in the order, and Rx is asubset match of Ry, and the actions of Rx and Ry are equal, then rule Rx isredundant to rule Ry provided that Rx is not involved in any generalization orcorrelation anomalies with other rules preceding Ry.Formally:

Rx[order] < Ry[order], Rx exactly match Ry, Rx[action] = Ry[action]

Rx[order] < Ry[order], Rx inclusive match Ry, Rx[action] = Ry[action]

Whereas rule Rx is redundant to rule Ry if:

Rx[order] < Ry[order], Ry inclusive match Rx, Rx[action] = Ry[action]

Anomaly 3. Shadowing anomaly. A rule is shadowed when a previous rulematches all the packets that match this rule, such that the shadowed rule willnever be activated. Rule Ry is shadowed by rule Rx if Ry follows Rx in theorder, and Ry is a subset match of Rx, and the actions of rule Rx and Ry aredifferent.

4.3. PROTOTYPE IMPLEMENTATION 47

Formally:

Rx[order] < Ry[order], Rx exact match Ry, Rx[action] 6= Ry[action]

Rx[order] < Ry[order], Rx inclusive match Ry, Rx[action] 6= Ry[action]

Anomaly 4. Correlation anomaly. Two rules are correlated if the first rule inthe order matches some packets that match the second rule and the second rulematches some packages that match the first rule. Rule Rx and rule Ry have acorrelation anomaly if Rx and Ry are correlated, and the actions of Rx and Ry

are different.

Formally:Rx correlate Ry, Rx[action] 6= Ry[action]

The Redundancy Anomaly discussed here can lead to errors in a rule-set. Itis important to do additional checks to see if a rule really is redundant whenlooking at the whole rule-set. A rule is not redundant if by removing it therule-set changes behavior. This is discussed in more detail in Section 4.5.3.

Both the possible rule relations and anomalies discussed by Al-Shaer and Ham-mad are vital to show the correctness of the sorting and validation algorithmsproposed in this thesis. The next sections will extensively use the anomaliesand rule relations discussed here. Please note that the anomalies discussed inthis section uses a first-hit match rule-set.

4.2.3 Summary

There is no existing research regarding sorting and anomaly discovery in bothfirst hit and last hit rule-sets was found. Other research also had little emphasison on creating generic algorithms and building blocks for sorting and anomalydiscovery. This research project focused on those issues.

The next sections will discuss the proposed algorithms and the the prototypethat implements those algorithms. Please note that the anomalies discussed inthis section uses a first-hit match rule-set. The subsequent sections will dealwith last-hit match rule-sets.

4.3 Prototype Implementation

A prototype that is able to sort and discover anomalies in a IPF (See Section2.3.2 ) firewall rule-set was developed to test the proposed sorting and anomalydiscovery algorithms. The prototype was developed on the FreeBSD platform2.

2http://www.freebsd.org/


It was was mainly developed on and for this platform, but should compile andrun on most POSIX compatible systems. It successfully compiles and runs underthe cygwin3 environment in Windows.

C++ was chosen as the development language, using gcc4 as the compiler. Toensure compatibility with other UNIX like systems GNU5 autoconf6 and au-tomake7 were used to create the makefiles. A makefile is like a project filecontaining information such as witch files to compile, and how to link the ob-ject files to create an executable. Automake and autoconf hide the differencesbetween the different platforms by creating a universal configure script. Thisscript can be run on all the supported platforms to create the makefiles neededto build the software.

To parse the firewall config files flex8 and bison9 were used. Flex is free imple-mentation of the lex program. It is used as a lexical analyzer generator. It isa tool for generating programs that perform pattern-matching on text. Bisonis the GNU replacement of yacc. Bison is a general-purpose parser generatorthat converts a grammar description into a C program to parse that grammar.Bison was used to convert the grammar of an IPF configuration file into a C++parser that is able to parse this configuration file format. Xerces10 was used toparse the XML [31] files. XML was used to describe a minimal common set ofdata needed by the sorting and anomaly detection algorithms. The use of XMLis explained in greater detail in Chapter 5.

As a unit test framework cppunit11 was used. Cppunit is a C++ port of theJUnit framework for unit testing. It enables the developers to create test on atthe class level to test whether the object gives the correct output to a certaininput. This gives the developer a safety net. If a change in a object leads toan unintended changes of behavior of another object, the unit test (if writtenproperly) will detect that.

4.4 Anatomy of an IPF Filtering Rule

The examples in the following sections all use the syntax from the IPF config-uration format. To better understand the examples this section gives a briefexplanation of how a basic IPF rule is constructed.

3http://www.cygwin.com/4http://gcc.gnu.org/5http://www.gnu.org/6http://www.gnu.org/software/autoconf/7http://www.gnu.org/software/automake/8http://www.gnu.org/software/flex/9http://www.gnu.org/software/bison/

10http://xml.apache.org/11http://sourceforge.net/projects/cppunit/

4.4. ANATOMY OF AN IPF FILTERING RULE 49

IPF Rule

Action Option Proto IP

"block"

"pass" "quick"

"on" [nic]

"proto" [protocol]

srcdst flags

"all" "from" object "to" object

"any"IP addr

Object

"port=" port num

"in"

in/out

"out"

Figure 4.2: Simplified IPF BNF Tree

Figure 4.2 shows a simplified version of a IPF BNF tree. For the complete BNF(Backus Naur Form) file please refer to Appendix E.A basic rule is built up of an action, option, proto and IP part. The action fielddetermines what kind of action to take with a matching packet. To match onpacket going in or out from the firewall in and out is used. Options is used toset different options, most notably quick and on. The quick keyword is veryuseful in a last hit match rule-set such as IPF. If a packet match a quick rule, thefirewall do not continue trough the whole rule set as it would if the rule was nota quick rule. Instead it immediately upon a match executes the correspondingaction field in the rule. The on keyword is used to match packet coming fromor going to a specific network interface. The IP portion of the rule lets the userdefine to and from addresses, with associated port numbers.A simple IPF rule can be as follows:

block in from 192.168.10.10 to any

This blocks all traffic from the host 192.168.10.10 to any. Any is used to includeall possible values of an IP address, port number or protocol. If the desiredeffect is to just block TCP traffic and traffic on port 80 from the same host therule will be as follows:


block in proto tcp from 192.168.10.10 to any port=80

The normal use of a quick rule is to allow the firewall to speed up filtering ontraffic going to high traffic servers. To create a quick rule for all the http trafficgoing to web server the rule will look like this:

pass in quick from any to 192.168.10.10 port=80

The examples cover only the aspects of this research project. IPF has muchmore functionality than described above. Please refer to other sources if theintention is to implement a live firewall in a network.

4.5 Proposed Algorithms for Anomaly Avoid-

ance and Detection

The usual filtering criteria used in a packet filter are source and destinationaddress, transport protocol, application protocol (port numbers) and flags. Theproposed algorithm is based on the information on IPv4-addressing found inRFC 950 [48], RFC 1570 [39], RFC 1518 [50] and RFC 1519 [36]. Rule relationsand possible anomalies are as described by Al-Shaer and Hamed with adjust-ments as already mentioned in Section 4.2.2. There exist certain rule relationsthat are important when finding faults and errors in a firewall rule-set.The algorithms first try to avoid any anomalies. This is achieved by sorting therule-set according to how specific a rule is. With a sorted rule-set it is easier todetect the other anomalies. The flow of the algorithms is shown in Figure 4.3.

Figure 4.3: Error Detection Flow

As Figure 4.3 shows; the rule-set is first sorted according to the criteria de-scribed in greater detail in Section 4.5.1, then checked for any possible redun-

4.5. ANOMALY AVOIDANCE AND DETECTION 51

dant, shadowed or correlated rules. The resulting rule-set should be free of anyknown anomalies.By sorting the rule-set we avoid any generalization anomalies as defined inAnomaly 1 in Section 4.2.2. A rule is a generalization of another rule if thisgeneral rule can match all the packets that match a specific rule that precedesit.When we sort the rules we use the possible rule relations by Al-Shaer andHamed, with the exception of Definition 5 because this doubles as an anomalyas described in Anomaly 4 and will be handled by the error detection algorithmsdescribed in Section 4.5.5.To make the algorithms easy to use each object involved in the sorting algorithmmust implement a compare method. A rule object has a compare method thatcompares two rules, rule R1 and rule R2, and returns a negative or positive valuedepending on how those two rules could be sorted according to each other. Ifthe order of the rules does not matter it returns 0.

4.5.1 Sorting the Rule-set

By sorting the rule-set we ensure that there no longer exist any generalizationanomalies. A generalization anomaly is described by Al-Shaer and Hamed intheir paper [33]. A rule is a generalization of another rule if this general rulecan match all the packet that match a specific rule that precedes it. By sortingthe rule-set with the most specific rules (first hit rule-set) at the top and themost general rule at the bottom, no generalization anomaly can exist.To be able to sort a rule-set there must be precedence among the sorting ele-ments. We defined this precedence on the rule elements:

1. Source address

2. Destination address

3. Protocol (either ‘any’ or defined)

4. Service/Port (either ‘any’ or defined)

5. Action

This choice of precedence provides the most readable rule-set. It is possiblethat other orders of precedence will still provide a safe ordering. Figure 4.4describes the flow of the algorithm. All the sorting criteria entities have theirown compare method which is called when the rule-set is sorted.The first action is to compare the source addresses field from rule R1 with ruleR2 by calling the appropriate compare function. This is in effect achieved by


Figure 4.4: Rule comparison algorithm flow.

calling the compare method (Method is the object oriented name of a function)of the src address member variable of rule R1, with the inn arguments being thesrc address member variable of rule R2. If the compare method returns 0 thismeans that the src address member variables of rule R1 and rule R2 are equal.To be able to sort the two rules we then use the same compare method on thedst address member variables of rule R1 and rule R2. If we still are unable todo any sorting, i.e. the compare method returns 0, we compare the protocolfields. If still no resolution we move on to compare the service fields and thenfinally the action fields.

In other words we keep on calling the compare method of the fields until we geta return value that does not equal 0. With this approach it is very convenientto use a q-sort [28] algorithm to sort the rule-set. When using this approach itis important prioritize the fields and have a clear understanding on how eachfield impacts the placement of a rule within the rule-set.

The following paragraphs will describe each of those parts in more detail. Allthe examples are written in IPF configuration format. This means that all theexample rule-sets is last-hit match rule-sets.

Compare IPv4 Addresses A routing decision in IPv4 is based upon four pa-rameters, IP-address, net-mask, network-address and broadcast-address. Usu-ally the IP-address and the net-mask is known, the other two can be calculated.

Network Address = (IP-address) binary AND Netmask

Broadcast Address = Inverted(Network Address) binary XOR (Netmask)

The network address represents the lower bound of the address space, andthe broadcast represents the highest. Figure 4.5 illustrates how this comparemethod works. If an IP address falls between those values, that IP address is


more specific. This means a rule containing source address 192.168.10.21/24must appear in front of a rule containing a source address 192.168.10.0/24 (As-suming a first match hit rule-set).

Figure 4.5: Compare Address

The pseudo code below illustrates how one IP-address is compared to another.(Assumes that the IP address is stored as 32-bit integer.) Please refer to Ap-pendix D.1 for C++ source code.

if ip address1.broadcast == ip address2.broadcast

if ip address1.network == ip address2.network

return 0 //Equal

else

return ip address1.network − ip address2.network

else

return ip address1.broadcast − ip address2.broadcast

Broadcast and network are the boundaries for the address range. This makes itpossible to sort more specific addresses in ascending order.The following example illustrates how the rules will be sorted with differentsubnets and hosts within those subnets. (IPF, last hit match rule-set)

4 block in from 192.168.10.128/255.255.255.192 to any

1 pass in from 192.168.10.130/255.255.255.255 to any



Rule 4 and R1 are grouped together because they belong to the same subnet.Rule R1 is more specific and is therefore sorted below rule 4. The same appliesto rules R2 and R3.


The intended result of the rule-set is visualized in Figure 4.6. The intention withthe rule-set is to block traffic originating from the subnet 192.168.10.128/26, butallow traffic from the host 192.168.10.30 within that subnet. And to allow trafficfrom subnet 192.168.10.0/26 but stop traffic from the host 192.168.10.12 withinthat subnet.

192.168.10.128/26

192.168.10.130

192.168.10.0/26

192.168.10.12Block

Pass

(4)

(1)

(3)

(2)

ANY

Figure 4.6: Visualization of Rule-set (Address example)

It is possible to simplify the sorting algorithm by just looking at how many bitsare set in the netmask. This sorting method makes the rule-set harder to readbecause subnets will no longer be grouped together.

The above example would have been sorted as shown beneath if only the netmaskwas used as a sorting variable.





This makes the rule-set much harder to read. It makes sense to group the rulestogether as shown first. It makes it much easier to visualize the rule-set by justlooking at it. The rules are grouped logically together just as in Figure 4.6. Ifthe rule-set are sorted according to the principle as first shown in this section,it increases the readability of the generated rule-set.

Compare IPv4 Transport Protocols Assumes that the protocol is storedas an integer. A transport protocol is usually either TCP or UDP. We makesure that if the protocol is specified(i.e. not ANY), it is to be sorted before anyANY protocols. The pseudo-code below demonstrates how this is achieved.

if proto1 == proto2


return 0 //Equal

else if proto1 == any

return −1

else if proto2 == any

return 1

else

return proto1 − proto2

The example below shows how rules with similar source and destination ad-dresses, but with different protocols, will be sorted. This example serves asan example of how IP addresses and transport protocols will be sorted by theproposed algorithm.

1 block in all

3 pass in proto udp from any to any

2 pass in proto tcp from any to any

4 pass in from 192.168.10.10/255.255.255.255 to 10.0.0.14/255.255.255.255

5 # pass in proto tcp from 192.168.10.10/255.255.255.255 to 10.0.0.14/255.255.255.255

The effect of the rule-set is shown in Figure 4.7. Imagine that the in keyword inthe rule-set describes traffic traveling from left to right. The rule-set starts witha rule that stops all traffic. This is a normal way to configure a firewall. Startby restricting all traffic and then open up for needed traffic. The all keywordin the first rule could also have been written as from any to any just as it isvisualized in Figure 4.7. The second rule(R3) opens up traffic from any to anyif it is UDP traffic. This rule is more specific than the first one because theprotocol is set. The first rule can be thought of as having the any protocol set.The third rule (R2) opens up for TCP traffic. This rule is sorted after the UDPrule because TCP have a higher value in the IANA12 protocol number list . Thesorting order of the two rules does not change the behavior of the rule-set. Thefourth rule allows traffic to flow from the host 192.168.10.10 to host 10.0.0.14.This rule is considered to be more specific than the others because it has theip addresses set. Hence it is sorted below the other rules. The last rule opensfor TCP traffic to the same hosts. It is even more specific because it has the IPaddresses and the protocol set. Notice the # sign. It indicates that the rule hasno effect in the rule-set. This is a redundancy anomaly and will be discussed ingreater detail in Section 4.5.3

Compare IPv4 Services (port) The port number is a 16-bit integer. Thisalgorithm is equal to the one used to sort protocols and the pseudocode is asbelow.

12http://www.iana.org


192.168.10.10 10.0.0.14

(4)

(1)

(3) UDP

(2) TCP ANYANY

(5) TCP

Block

Pass

Figure 4.7: Visualization of Rule-set (Protocol example)

if service1 == service2

return 0 //Equal

else if service1 == any

return −1

else if service2 == any

return 1

else

return service1 − service2

This will ensure the sorting on service or port number. The example belowshows how.

2 block in proto tcp from 192.168.10.0/255.255.255.0 to any

1 pass in proto tcp from 192.168.10.0/255.255.255.0 to any port = 8080

3 pass in proto tcp from 192.168.10.0/255.255.255.0 to any port = 80

192.168.10.0/24

(1) TCP

(3) TCP, 80

(2) TCP, 8080ANY

Block

Pass

Figure 4.8: Visualization of Rule-set (Service example)

Figure 4.8 shows the effect of the sorted rule-set. The first rule (R1) blocks alltraffic from the network 192.168.10.0/24. The second rule (R2) is more specificand opens up for traffic going from the 192.168.10.0 network to the port number8080 on any host. The third rule (R3) opens up traffic from the same network toany host on port 80. The sorting order of rule (R2) and (R3) does not matter,but due to the algorithm higher port numbers are sorted first.

Compare Action The most important thing about sorting the action field,is to prefer deny rules to allow rules. The algorithm shown below does this.


if action1 == action2

return 0 //Equal

else if action1 == deny

return −1

else

return 1

To allow higher security it makes sense to give higher priority to deny rules.That means that a deny rule is always more specific than an allow rule, if therules are equal in all other fields. The following example shows how action willbe sorted in a last hit match rule-set.

2 # pass in from 192.168.10.0/255.255.255.0 to any


Note that the first rule R2 is marked with a # sign. This indicates that therule is already covered by another rule in the rule-set. How this is detected anddealt with is described in Section 4.5.3. This ensures that no unintended trafficgoes through the packet-filter.

Figure 4.9: Visualization of Rule-set (Action example)

The block rule is considered more specific than the pass rule, and is thereforesorted last in this last hit match rule-set. This ensures that the most restrictiverules are always in effect.

Compare Two Rules The precedence among the different fields in a firewallrule was defined earlier in this Section. According to that defined precedencethe algorithm to compare to rules is shown below. Please refer to Appendix D.5for C++ source code.

RETVAL = rule1.srcAddress COMPARE TO rule2.srcaddress

if RETVAL == equal

RETVAL = rule1.dstAddress COMPARE TO rule2.srcaddress

if RETVAL == equal

RETVAL rule1.protocol COMPARE TO rule2.protocol

if RETVAL == equal


RETVAL rule1.service COMPARE TO rule2.service

if RETVAL == equal

RETVAL = rule1.flags COMAPRE TO rule2.flags

if RETVAL == equal 10

RETVAL = rule1.action COMPARE TO rule2.action

return RETVAL

This ensures that the rules will be sorted as follows (last hit):

1 block in all

2 pass in proto tcp all

4 block in from any to 10.10.10.0/255.255.255.0


5 pass in from 192.168.10.0/255.255.255.0 to 0.0.0.0/0.0.0.0 port = 80

6 block in from 192.168.10.0/255.255.255.0 to 0.0.0.0/0.0.0.0 port = 80

Rule R1 is the most general and is sorted on the top. Rule R2 is more specificthan rule R1 because of the protocol. Rule R3 is more specific than rule R4

because source address takes precedence over destination address. Rule R5 ismore specific because the port is given. And rule R6 is more specific than ruleR5 because of the block (deny) action.

4.5.2 Building Blocks for Error Detection

This section examines the common building blocks needed to detect all typesof errors in a firewall rule-set. The following three sections describe how thosebuilding blocks are used to detect rule-set errors.In some cases it is not possible to sort the rules without leaving behind rulesthat will never be matched by the packet filter. Two identical rules are thesimplest case where one of the rules should be marked as invalid.With the CoveredBy method implemented in all the sorting parameter entitieswe are now able to find rules that are blocked by another rule, and have nopractical effect in the rule-set.

IPv4 Rule CoveredBy To check if a rule R1 is covered by another rule R2,all the IP related fields a rule consists of must be examined; src, dst, proto andservice. If the corresponding fields in R1 cover all the fields in R2, R1 coversR2. The algorithm is shown below.

if rule1.src address COVEREDBY rule2.src address AND

rule1.dst address COVEREDBY rule2.dst address AND

rule1.protocol COVEREDBY rule2.protocol AND

rule1.service COVEREDBY rule2.service

return true

else


return false

The algorithm returns true if all the fields in rule R1 are covered by the corre-sponding field in rule R2.The following paragraphs examine in greater detail how to check if a specificfield is covered by a corresponding field.

IPv4 Address CoveredBy To test if the address parts of two rules arecovering each other, we simply test if the network address of the first rule islarger than the second rule. And then test if the broadcast address of the firstrule is smaller than the broadcast address of the second rule. If both of thoseare true the first rule is covering by the second rule. This means that thesecond rule will have no effect in the rule-set. This corresponds with the sortingalgorithm for IP addresses discussed earlier. The pseudo code below containsthe validation algorithm for IP addresses.

if rule1.NetworkAddress >= rule2.NetworkAddress AND

rule1.BroadCastAddress <= rule2.BroadCastAddress

return false

else

return true

Figure 4.10: Network Addresses coveredBy

In Figure 4.10 the algorithm is visualized. The figure shows the whole 32 bitaddress range of all possible IP addresses. The network address of rule A1 isshown as rule A1start. The broadcast address of rule A1 is shown as A1stop.The network address and the corresponding broadcast address can be viewed asthe starting and ending point of a none inclusive range of possible IP addresses(hosts) that can be in that network (subnet). In Figure 4.10 address A2 iscovered by A1 because the whole range of possible IP addresses of A2, is withinthe range of rule A1.


IPv4 Protocol CoveredBy A protocol can only cover another protocol ifthey are equal, or the protocol in the first rule is of the ANY type. Thealgorithm is shown below.

if protocol2 == any

return true

if protocol1 == protocol2

return true

else

return false

0 2 8P P8 bit

protocol number range

1 2

P = Protocol number ( 6, TCP )1

P = Protocol number ( 17, UDP )2

(Protocol range not to scale)

Figure 4.11: Protocol coveredBy

As shown in Figure 4.11 the only way a protocol can cover another is when itis specified as any. A protocol is just a number not a range, except if specifiedas ANY, and thus they can not cover each other.

IPv4 Service CoveredBy Checking a service (port) is similar to checkingthe protocol. They are both represented by an integer value. The pseudo codebelow contains the proposed algorithm.

if service2 == any

return true

if service1 == service2

return ture

else

return false

Figure 4.12 shows the possible range of port numbers. As with protocol nooverlapping is possible unless the port is specified as the special range any. Thismeans that the only port that can cover another port is if it is defined as any.Port ranges is not supported by the algorithms.

4.5.3 Detecting Redundant Rules

As defined [33] a redundant rule (Section 4.2.2, Anomaly 2 ) performs the sameaction on the same packets as another rule such that if the redundant rule is


0 2 1616 bit portnumber range

P1

P2

P = Port number ( 80, HTTP )1

P = Port number ( 8080 )2

(Port range not to scale)

Figure 4.12: Port (service) coveredBy

removed, the security policy will not be affected.The proposed algorithm to detect redundant rules in a sorted rule-set is asfollows:

for ALL rules IN ruleset do

if rule[j] isCoveredBy rule[i] and

rule[j].action == rule[i].action

for ALL rules In ruleset do

check if rule[j] is needed

if rule[j] not needed

mark rule[j] as redundant

The algorithm must search the rule-set for rules R1 and R2 where R2 is coveredby R1. If such an instance is found the algorithm must check if the overall rule-set policy changes if R2 is removed. This is achieved by traversing the rule-setonce more to check if the rule is needed. The algorithm to check if a rule isneeded follows:

isNeeded( isNeeded, Rule1, Rule2)

if Rule2 CoveredBy isNeeded AND

isNeeded.action != Rule2.action

if isNeeded ISBETWEEN Rule1 and Rule2

rule is needed

The rule Risneeded is needed if it is covered by rule R2 and the actions are notequal. Furthermore Risneeded must be sorted between R1 and R2 in the rule-set.Running the prototype on a rule-set containing redundant rules gives the fol-lowing output:

Warning! Warning!


pass in from any to 192.168.10.45/255.255.255.255 id: 3

Is made redundant by the following rule(s):

−> pass in from any to 192.168.10.0/255.255.255.0 id: 2

block in from any to 10.10.10.10/255.255.255.255 id: 5

Is made redundant by the following rule(s):

−> block in all id: 1

10

1 block in all

2 pass in from any to 192.168.10.0/255.255.255.0

3 # % 2 pass in from any to 192.168.10.45/255.255.255.255

4 block in from any to 192.168.10.13/255.255.255.255

5 # % 1 block in from any to 10.10.10.10/255.255.255.255

Rule R3 can safely be removed from the rule-set without changing the behaviorof the rule-set. This rule is covered by rule R2. They are identical. Rule R5

can also safely be removed. It does not have any effect because of rule R1.Removing rule R5 does not change the overall policy of the rule-set.At a first glance it also looks like rule R4 is covered by rule R1. It is, butremoving it would change the behavior of the rule-set because of rule R2. RuleR2 allows traffic into a specific subnet. Rule R4 blocks traffic going to a specifichost on that subnet. Since this is a last hit match rule-set the overall policywould change if we remove rule R4 because the last rule that matched thatpacket would be rule R2. This changes the desired behavior from blockingtraffic to that host to allowing it.

4.5.4 Detecting Shadowed Rules

As defined [33] a rule is shadowed (Section 4.2.2, Anomaly 3 ) when a previousrule matches all the packets that match this rule, such that the shadowed rulewill never be activated.The following algorithm will work on both first hit match and last hit matchrule-sets. The algorithm presumes that the rule-set is sorted.

checkShadowed()

for ALL rules IN ruleset do

if rule2 CoveredBy rule1 and

rule2.action != rule1.action

if rule1 CoveredBy rule2 or

rule2 SortedAfter rule1 or

rule1 isQuick

10

mark least restrictive rule as shadowed


First the algorithm searches for any rules covering another rule. According tothe definition R1 is a subset match of R2. If the action is different on the tworules we may have a shadowing rule.If rule R1 is covered by rule R2 the rules are shadowing each other. In this casethe part of the firewall rule describing the IP packets is equal since both rulesare covering each other. In the sorting algorithm this is handled by giving themost restrictive rule precedence. This makes the rule-set more secure, but thepossibility of shadowing rules still arises. The shadowing detection algorithmcatches this and warns the user.In the case where rule R2 is sorted after rule R1 in a first hit match rule-set ashadowing anomaly exist. However this should not be possible to the previoussorting of the rule-set. It is included in the algorithm to make sure that this isdetected if there is a flaw in the sorting algorithm.The only possibilities in a last hit match rule-set for a shadowing anomaly isif rule R1 is a quick rule. Otherwise the sorting would make sure that noshadowing anomalies can occur.Running the prototype on a rule-set containing a rule that shadows another rulegives the following output:

Warning! Warning!

pass in quick from any to 192.168.10.10/255.255.255.255 id: 3

Is shadowing the following rule(s):

−> block in from any to 192.168.10.10/255.255.255.255 port = 135 id: 2

3 # @ 2 pass in quick from any to 192.168.10.10/255.255.255.255

2 block in from any to 192.168.10.10/255.255.255.255 port = 135

1 pass in from 192.168.10.0/255.255.255.0 to 10.10.10.10/255.255.255.255

Rule R3 is sorted first because it is a quick rule. From the warnings we see thatrule R3 is shadowing for rule R2. That means that as long as rule R3 is placedwhere it is, no packet will reach rule R2. Rule R3 is removed because it is lessrestrictive than rule R2. This ensures that no unintended holes in the firewallsuddenly appear. Rule R1 is sorted at the end and has no relationship with thetwo other rules.

4.5.5 Detecting Correlations

From the definition of correlated rules in Section 4.2.2 (Anomaly 4 ), two rulesare correlated if the first rule in the order matches some packets that match thesecond rule and the second rule matches some packets that match the first rule.


To detect correlations we must search through the rule-set for two rules wherethere exist one or more field subsets, one or more field supersets and the rest ofthe fields are equal. This is performed as follows:

isCorrelated( rule1, rule2 )

if number of field subsets >= 1 and

number of field superset >=1 and

rest of fields equal

rules are correlated

field subset 10

if rule1.field CoveredBy rule2.field AND

(rule1.field compare rule2.field) < 0

rule1.field is a subset of rule2.field

field superset

if rule2.field CoveredBy rule1.field AND

(rule2.field compare rule1.field) < 0

rule1.field is a superset of rule2.field

field equal 20

if rule1.field compare rule2.field == 0

rule1.field and rule2.field are equal

The coveredBy and compare functions are described in Section 4.5.1 and Section4.5.2. A rule field can be source address, destination address, protocol or service(port). If the specific field of rule R1 is covered by the corresponding field inrule R2 and the field of R1 is less specific than the corresponding field in R2,the field in R1 is a subset of the field in R2. If the specific field in R2 iscovered by the corresponding field in R1 and the field in R2 is less specific thanthe corresponding field in R1, the field in R1 is a superset of the field in R2.Checking if two fields are equal is done with a simple compare. The comparemethod returns 0 if the fields are equal.

Running the prototype on a rule-set that contains correlated rules gives thefollowing output:

Warning! Warning!

pass in from 10.0.0.1/255.255.255.255 to 192.168.10.0/255.255.255.0 port = 80 id: 1

Is corrolated with the following rule(s):

−> block in from 10.0.0.1/255.255.255.255 to 192.168.10.10/255.255.255.255 id: 2

block in from 10.0.0.1/255.255.255.255 to 192.168.10.10/255.255.255.255 id: 2

4.6. LAST HIT RULE-SETS AND QUICK RULES 65

Is corrolated with the following rule(s):

−> pass in from 10.0.0.1/255.255.255.255 to 192.168.10.0/255.255.255.0 port = 80 id: 1

10

1 # ! 2 pass in from 10.0.0.1/255.255.255.255 to 192.168.10.0/255.255.255.0 port = 80

2 # ! 1 block in from 10.0.0.1/255.255.255.255 to 192.168.10.10/255.255.255.255

The source fields in both rules are equal. The destination field of rule R1 is asuperset of the destination field of rule R2 (subnet contains a host). Lookingcloser at the service field reveals that the port 80 specified in rule R1 is a subsetof the service field in rule R2 (port 80 is a subset of port ANY). By not specifyinga field, the field is implicit defined as ANY. This also means that the protocolfields in the two rules are equal. This means that the two rules are correlated.

The algorithm correctly detects the two correlations existing in the rule-set.Rule R1 is correlated with rule R2. If that is the case rule R2 must also becorrelated with rule R1. The only difference is that the fields that where subsetsare now superset and the fields that where superset now are subsets.

4.6 Last Hit Rule-sets and Quick Rules

Introducing quick rules also introduces another problem. In a last hit matchrule-set they can be treated as a special case where all the quick rules can besorted as a first hit match rule-set.

To honor the intention13 of a quick rule, they should be placed at the beginningof the rule-set. This ensures that the rule truly is quick, that means it is quicklyreached, matched and executed.

For simplicity two assumptions where made:

• Quick rules must be sorted first.

• Quick rules can be grouped together and be treated as a first hit matchrule-set.

To sort a rule-set as a last hit match we simply reverse the order. This is achievedmy multiplying the return value from the compare method from Section 4.5.1with -1.

If both of the rules are quick rules no corrections to the return value from thecompare method is needed. Two quick rules in a last hit match rule-set actsinternally as a first hit match rule-set.

If one of the rules is a quick rule the algorithm must make sure that this ruleis sorted first. This is achieved by altering the return value to -1 for the quick

13This may be discussed, people often use it to make a last hit match into a first hit.


rule. This makes the rule more specific, and the rule is sorted before the othernon-quick rule. The algorithm follows.

lastHitCorrections( rule1, rule2, original sorting order )

if rule1.isQuick AND rule2.isQuick

//Should be treated as a FirstHit

return original sorting order

if rule1.isQuick

return −1

if rule2.isQuick 10

return 1

//No more quick rules

//Just reverse sorting order

return original sorting order * (−1)

This ensures that the rule-set will be sorted like this:

Warning! Warning!

pass in from any to 192.168.10.10/255.255.255.255 port = 21 id: 5

Is shadowed by the following rule(s):

−> block in from any to 192.168.10.10/255.255.255.255 port = 21 id: 4

pass in from 158.38.48.10/255.255.255.255 to 192.168.10.12/255.255.255.255 port = 135 id: 6

Is shadowed by the following rule(s):

−> block in quick from any to any port = 135 id: 2

10

1 pass in quick from any to 192.168.10.10/255.255.255.255 port = 80

2 block in quick from any to any port = 135

3 block in from any to any

5 # @ 4 pass in from any to 192.168.10.10/255.255.255.255 port = 21

4 block in from any to 192.168.10.10/255.255.255.255 port = 21

6 # @ 2 pass in from 158.38.48.10/255.255.255.255 to 192.168.10.12/255.255.255.255 port = 135

The two quick rules, rule R1 and rule R2, are correctly sorted at the top of therule-set. Furthermore the rules are internally correctly sorted, the most specificquick rule is sorted first. The error detection algorithms also work correctly withquick rules in the rule-set. Rule R6 is correctly commented out as no packetwould ever reach this because of the quick rule R2. Rules rule R4 and rule R5

are also shadowing each other. The packet part of the rules is equal, the onlydifference is the action. To make sure that no unintended holes occur in therule-set the least restrictive rule is commented out.

4.7. TESTING THE ALGORITHMS AND THE IMPLEMENTATION 67

4.7 Testing the Algorithms and the Implemen-

tation

Testing an algorithm and testing an implementation can be combined into onetask because a common attribute of the two tasks is to divide the large partsinto smaller and more manageable parts. If it can be proven that a small partworks in the big picture, it is reasonable to assume that the algorithms and theimplementation as a whole is correct. However since it is difficult to determineall possible errors a user can make when writing a firewall rule-set, absolutecorrectness of the algorithms or implementation is difficult to achieve. This wasnot the goal of the research project. Earlier sections have discussed the buildingblocks that makes it possible to sort and validate complicated and hard to readfirewall rule-sets.Section 4.5.1 describes the compare method and breaks it into smaller tasks.Those tasks are investigated in greater detail and the proposed algorithms aretested and validated by checking against an example rule-set made especiallyto test that specific part of the algorithm. For instance, an IPv4 Rule objecthas a compare method. This compare method can be used to sort the rules in afirewall rule-set. But this is complicated because there are so many requirementsto be met to sort the rules correctly. A IPv4 Rule object is sorted against thefields, source address, destination address, protocol, and service (port). All ofthose fields have their own compare methods. By looking at just one of thosefields and how that particular compare method is implemented the complexityis dramatically reduced.Providing proof of correctness of the algorithm is achieved by testing and vali-dating each small building block of the algorithm. Figure 4.13 shows a UML [35]diagram of the core elements of the sorting algorithm.The ideas from Test Driven Development (TDD) [22] were used as a basis whenthe prototype was developed. A TDD process or cycle goes as follows:

1. What functionality do you want to implement. (Customer input).

2. How do you test that functionality?

3. Write a small test. Think about the API.

4. Write enough code to compile and run the project.

5. Run the test program. The test will fail because the code to achieve thecorrect functionality is not yet written. This makes sure that the testworks.

6. Write just enough code to pass the test and any previous tests.


IPv4_Rule

+src: IPv4_Address

+dst: IPv4_Address

+protocol: IPv4_Protocol

+service: IPv4_Service

+action: FilterAction

+compare(rule:IPv4_Rule): int

+coveredBy(rule:IPv4_Rule): bool

IPv4_Address

+compare(address:IPv4_Address): int

+coverdBy(address:IPv4_Address): bool

IPv4_Protocol

+compare(protocol:IPv4_Protocol): int

+coveredBy(protocol:IPv4_Protocol): int

IPv4_Service

+compare(servoce:IPv4_Serice): int

+coveredBy(service:IPv4_Service): bool

FilterAction

+compare(action:FilterAction): int

Figure 4.13: IPv4 Rule Building Blocks

7. Run tests. Hopefully they will pass.

8. Remove duplicate logic and inexpressive code. (Refactoring).

9. Run test. They should still pass, unless an error was made during therefactoring.

10. Repeat the steps until no more tests can be written.

Having a development cycle like this helps to put focus on what little part ofthe problem that is being solved at the moment. The process also makes surethat the problem that is being solved is tested, and the test is reusable. Ifanything at any stage in the development unintentionally changes the behaviorof an object, the tests will catch that.Describing each functionality as a story as in eXtreme Programming [21] helpsto keep track of the desired functionality. The desired functionality is writtendown on a index card. This is a story. With a stack of index cards it is easy toreprioritize. When a story is finished, all the tests written for the story shouldpass, data on how long the implementation time was can be added. This is abrilliantly simple way of project management.To write the actual tests, cppunit was used. Specific tests were written to testthe following objects; FilterAction, IPv4 Service, IPv4 Protocol, IPv4 Address,

4.8. PROTOTYPE FUNCTIONALITY 69

IPv4 RuleTest, IPv4 FilterRuleSet, IpfRule and IpfRuleSet. In the test thereare 387 possible asserts, or points in the code where a test can fail. The tests arebuilt up as described earlier. Starting with tests of the basic building blocks likeIP address and protocol. On top of that layer we test the objects that use thosebuilding blocks, in this case the IPv4 Rule object. In addition to that we alsotest how the IPv4 Rules behave when they are combined in a rule-set. This isspecifically achieved in the IPv4 RuleSet object. Finally we test the top classeslike IpfRule and IpfRuleSet. Those objects are actual implementations of a realworld rule-set. This provides the source code with a good test coverage.

4.8 Prototype Functionality

The program ipfcheck is provided for the purpose of sorting and checking a ipf(or pf) firewall rule-set. This will reduce the risk of misconfiguration caused byblocking or short circuiting of rules.Options

• -m, –mode [XML — NATIVE] sets the mode of operation. Can either beXML or NATIVE. In XML mode the output file or the output to stdoutwill be an well formed XML stream. In NATIVE mode the output is thesame as the the input file.

• -f input-file to read the rule-set from.

• -o output-file. Format dependent on the mode of operation. (see -m,–mode)

The prototype executable, ipfcheck, is able to read either native ipf (or PF)configuration format or a XML file. The program automatically detects theformat of the input file. It is possible to set the mode of operation with the-m switch. This can either be XML or NATIVE. If the input file is a ipfconfiguration file and the mode of operation is set to XML, the resulting outputwill be a generic XML firewall stream or file if the file is specified with the -fswitch. If the input file is a XML file and it successfully validates it is possibleto write it out again as an ipf configuration file. The XML and validation partis described in Chapter 5.Figure 4.14 shows a screen shot of the prototype running.

4.9 Limitations

This section addresses the known limitations of the sorting algorithms and theprototype. Some of the limitations are of a nature that makes the prototype


Figure 4.14: Ipfcheck Prototype Screen shot

not yet a useful tool for firewall administrators. However enough functionalityis implemented to prove that the sorting algorithms do sort and detect errorscorrectly.The prototype itself has no support for macros. Usually in a firewall configura-tion file macros for the different interfaces are defined, such as a macro for theinterface towards the LAN, another macro for the interface towards the Internetand yet another for the DMZ. Those macros can later be used in the configu-ration file. So if one of the interfaces change it only has to be changed once inthe configuration file. This has no impact on the sorting or error detection.Ranges or tables are not supported either by the algorithms or the prototype.With ranges it is possible to give the start and endpoint of a range of addresses,protocols or services (ports). A example of a firewall rule using ranges follows:

• pass in from any to 92.168.10.12, 192.168.10.20 proto tcp,udp,icmp port80,8080,21

Ranges add to the complexity to the proposed algorithms because with rangesdifferent fields of the rule can be partly covered. One quick solution is to expandthe rules using ranges into several simple rules without the use of ranges, and theuse the existing algorithms to sort and validate the expanded rule-set. Otherwisethe algorithm can be extended or changed to handle this problem.Support to sort on the different flag fields in the TCP/IP protocol has not beenincluded in the sorting algorithms. This can easily be achieved by creating anew object flag and then implement the coveredBy and compare methods. Im-plementing this would not add any new significant new features to this researchproject.To allow traffic through the firewall in ipf two rules must be written. One thatallows the traffic in on one interface and out on another interface. In this sense

4.10. USE OF RESEARCH OUTCOMES 71

a rule with one direction on one interface must relate with another rule with adifferent direction and a different interface. This can be difficult to achieve andshould be investigated further. Another problem that arises from this problemis translation from ipf (section 2.3.2) firewall rules to netfilter (section 2.3.1)firewall rules. Since ipf has two directions and relies on two rules to allow trafficthrough the firewall. Netfilter has three different chains, one input (INPUT)chain for traffic to the firewall, one output (OUTPUT) chain for traffic comingfrom the firewall, and one chain (FORWARD) for traffic going through thefirewall. This is shown in Figure 4.15.

Figure 4.15: Ipf(pf) and Netfilter

4.10 Use of Research Outcomes

The rule-sorting and anomaly discovery algorithms is technology that can bepart of many possible security systems in today’s mobile environment. A Con-nection Security Controller that runs on both the mobile handset and in station-ary gateways is a possible product. This possible product will now be describedin greater detail.

4.10.1 Connection Security Controller

The controller is capable of translating security policies into actual firewall con-figurations.Figure 4.16 show a conceptual view of the Security Controller. It takes thedesired security policies and combines them into one enforceable rule-set. Forinstance a web browser running on a mobile phone probably wants to sendtraffic on port 80 and then receive a response from a web server. The networkoperator may want to stop traffic from a specific host or subnet, or the user ofthe phone want to be able to use the phone to read e-mail. All those examplesare examples of desired security policies, or to be more accurate, parts of asecurity policy.For a security policy to be effective the whole picture must be taken into ac-count, not just small parts of it. Otherwise undesired security holes caused by


Security Controller

Security Policy

Security Policy

Security Policy

Firewall Rule set

Figure 4.16: Connection Security Controller Overview

misconfiguration may occur. The security controller makes sure that this doesnot occur by merging all the desired security policies, and then thoroughly ex-amine the result to find errors. The end result is a secure firewall rule-set thatis ready to be implemented on a firewall.

There are two possible versions of the connection security controller. The mo-bile version is tailored to run on and protect a mobile device. The stationaryversion is designed to protect the operator network and would be localized atthe perimeter of that network, typically at the BSC (base Station Controller)or at the Internet gateway. This is shown in Figure 4.17.

4.10.2 Mobile Connection Security Controller (mSCS)

The mobile security controller run on the mobile handset and is responsible fortransforming security policies into enforceable rules. The use of the controlleris explained in Figure 4.18. There we see the different possible policy providers.This is just examples of possible providers.

Operator based policy providers are examples of how the network operators canutilize the security controller. This can be a subscription service that createsadditional revenues for the network operator. Examples of such subscriptionbased services can be location based services (or any kind of context awareservice). A location based security service provided by the network operatorcould configure the connection security based on the location of the handset. Ifthe handset (and hopefully the user as well) is located at work or at home heis allowed to access his Internet bank. At all other locations this action would

4.10. USE OF RESEARCH OUTCOMES 73

Operator Network BSC

BSC

Internet

InternetGateway

Operator Admin

LAN

Corporate Admin

ISP Network

EndUser

Figure 4.17: Network Overview

Security Controller

Firewall Rule set

SecurityManager

Other Application

C++Interface

C++/JavaInterface

Network Operator Administrator

Location Based Services

XML

XML

Local Policy Providers

Other Operator BasedServices

Operator Based Policy Providers

XML

PC SecurityManager

Enterprise SecurityManager

XML

XML

Network Based Policy Providers

Figure 4.18: Connection Security Controller

not be allowed.

The network based policy providers could be the user’s own PC. Maybe theuser prefer to sit in front of a PC and configure the security policy and thentransfer the policy to the mobile phone. The enterprise solution would be ableto administrate a fleet of mobile phones. This would be the light version of theadmin tool available for the network operators. But still a very useful featurefor companies that wants to administrate the security of the employees mobilephones in an easy and secure manner.


4.10.3 Stationary Connection Security Controller (sCSC)

The stationary security controller runs on a stationary networked firewall. TheStationary Security Controller is able to implement a given security policy onany of the supported platforms. This makes sCSC a versatile component thatenhances the security on any supported firewall platform. The input policiescan either be XML or any of the native supported platforms. This makes it easyto migrate between any of the platforms as well as the sCSC is able to translatefrom and to any of the supported platforms.

4.11 Summary

A working prototype was developed. This prototype is able to demonstrate howa real life rule-set will be sorted by the proposed object oriented algorithms.The prototype has been released under a BSD license and can if time permitsbe extended to be a useful tool for firewall administrators or other security pro-fessionals. The strength of the prototype is the object oriented implementationwith a loose coupling of the objects.The project has also developed many small and useful building blocks. Forinstance the IPv4 Address class is class for anybody dealing with IPv4 addresses.All the classes are relative lightweight but can easily be extended. However themain contribution on the source code side is all the objects included as a partof the sorting and error detection algorithms. They provide a developer with avery useful set of base classes where any firewall related development is to beundertaken.The algorithms and their implementation verify the work already done by Al-Shaer and Hamed with their formalization of possible rule-relations and possibleanomalies [33]. This project contributes with a solution to the last hit first hitrule-set sorting problem. It also discusses how to deal with quick rules in a lasthit rule-set. As far as the candidate knows no other papers have been releaseddiscussing those problems. By using an existing rule-set like ipf the project alsomade sure that real life problem were encountered and solved. This is preferableinstead of using a simplified rule-set to test the algorithm.

Chapter 5

XML Firewall Interface

This chapter examines how XML can be used to describe a packet filter rule-set.XML Schema is also introduced to validate the XML stream.Having a universal and generic description language of a firewall configurationwill benefit the overall network security significantly. With such a descriptionlanguage in place there is no longer a 1:1 mapping of configuration tools andfirewall platforms. Being able to configure all the firewall platforms from all theavailable configuration tools would make it possible to choose a tool designedfor the administrators level of competency.It is an important design principle to separate the data from the presenta-tion [37]. That means that there must be an independent standalone datamodel that describes the firewall configuration. It should be possible to alterthat data model with a wide array of tools.XML is a technology capable of providing a good solution to the above problemsand requirements. Figure 5.1 shows how the sorting and prioritizing enginedescribed in Chapter 4 can utilize XML.Figure 5.1 shows how the logic component removes the one to one mappingbetween configuration tool and actual firewall implementation. As an addedbonus, it makes it easy for other system entities like an intrusion detectionsystem to insert rules into the firewall policy. This is possible because all of theentities use XML and a predefined Schema as a communication protocol. Thisconcept will now be described in greater detail.

5.1 XML Validation Schema

When developing a software system a large amount of the time is spent onwriting code to parse and check that the data is valid. This is a difficult and errorprone job. To make matters even worse, much time is spent finding bugs in the

75

76 CHAPTER 5. XML FIREWALL INTERFACE

Figure 5.1: Vertical and horizontal integration.

same part of the software. Using a validating XML parser does the validationfor the developer, thus saving valuable time spent on both development anddebugging. Using XML reduces the complexity of the software system.The XML Schema provides functionality to help with validating the structure,content and semantics of an XML document. The XML Schema standard wasapproved as a W3C Recommendation on 2 May 2001 [12]. Another definitionof an XML Schema is [31]:

A Schema defines the allowable contents of a class of XML docu-ments. A class of documents refers to all possible permutations ofstructure in documents that will still conform to the rules of theschema.

A Schema tells the XML parser what kind of data and what values are ac-ceptable for a XML stream. This reduces the complexity of the other softwarecomponents in the same system. If a component knows that the XML streamhas been validated with a given Schema, it also knows that the data is validwith correct values set. Early detection of errors in the data stream also reducesthe risk of later bugs or errors in other software components. XML Schema isa better and more powerful alternative to the old DTD format.The XML Schema described in the following sections is derived from the spec-ification and requirements to the rule sorter described in Section 4.5.1. Sincethe rule sorter was developed with an object oriented approach, it is a simpletask to take each object and create a validation schema for it. For complete

5.2. RULE-SET VALIDATION 77

examples of the proposed XML Schema and an example XML stream pleaserefer to Appendix A and B.

5.2 Rule-set Validation

A firewall rule-set is a set of firewall rules describing the desired security policyimplementation on the firewall. For a more detailed description of a rule-set seeSection 2.2.The purpose of the rule-set validation is to validate that all the containing rulesconforms to the specification. This is important because it enables the rulesorter to sort and prioritize the rules within the rule-set. If a rule does notcomply with the specification, or in other words does not validate, the user isnotified before any sorting has occurred.Below is the part of the schema that validates a rule-set:

<xsd:element name="ruleset">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="rule" type="filterRule" maxOccurs="unbounded" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

This part of the proposed XML Schema tells the validator that a rule-set isa sequence of filter rules. This sequence can contain from zero to unlimitednumber of rules. The validation of the actual rules is described in Section 5.3Figure 5.2 shows a UML diagram of a generic rule-set containing rules. In theactual implementation of the Ruleset class no array or vector is used to storethe rule-set. This class contains a set of abstract methods the subclasses mustimplement. How the subclasses actually store the rules are of no interest to theparent class or any users of the subclass.

(Generic)RuleSet

+rules

IPv4_Rule1 n

Figure 5.2: UML Diagram; Rules in a Rule-set

Below is an example of a valid XML stream that conforms to this part of theXML Schema:

<ruleset xmlns="http://www.rulesorter.org"


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.rulesorter.org fwXML.xsd">

<rule> .... </rule>

<rule> .... </rule>

</ruleset>

The schema ensures that there is a least one rule element in a rule-set. Eachrule is later validated by a different part of the schema.

5.3 Rule Validation

This part of the XML Schema tells the system how to validate a rule. Asdescribed in Section 4.5.1 the usual criteria used to filter IP packets are sourceaddress, destination address, transport protocol and application protocol (portnumbers or service).The data model we need to serialize and deserialize is shown in a UML diagramin Figure 5.3.

IPv4_Rule

+src: IPv4_Address

+dst: IPv4_Address

+protocol: IPv4_Protocol

+service: IPv4_Service

+action: FilterAction

+direction: Direction

+m_interface: string

+m_Sorder: int

+m_quick: bool

+m_fragments

IPv4_Address

+ip_address: long

+netmask: long

IPv4_Protocol

+protocol: int

IPv4_Service

+service: int

FilterAction

+m_action: int

Figure 5.3: Data Model

The UML diagram shows the data members of the IPv4 Rule class that need tobe serialized. In this prototype the serialization is limited to the fields; action,src, dst, protocol and service (port). The rest of the fields: direction, interface,quick and fragments must be part of the XML stream in a real implementation.If not, vital data will be lost when serializing the data model. This makes it

5.3. RULE VALIDATION 79

impossible to deserialize the XML stream correctly. The supported fields arehowever sufficient to show the usefulness of using XML in the prototype.The goal of this part of the XML Schema is to ensure that a rule within arule-set contains the necessary information.

<xsd:complexType name="filterRule">

<xsd:annotation>

<xsd:documentation>

The filterRule type holds information needed to set up a

single rule on a packet filtering firewall.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="action" type="action_content"

minOccurs="1" default="deny"/>

<xsd:element name="src" type="ipv4" minOccurs="1" />

<xsd:element name="dst" type="ipv4" minOccurs="1" />

<xsd:element name="protocol" type="protocol_content"

minOccurs="0" default="any"/>

<xsd:element name="service" type="service_content"

minOccurs="0" default="any"/>

</xsd:sequence>

</xsd:complexType>

This ensures that the following elements are present in the XML Stream; action,src and dst. These are the minimum requirements of the sorting algorithm.The elements protocol and service can be omitted from the stream. The defaultvalue of those omitted elements will be “any”.The following example shows a valid example of an XML rule stream:

<rule>

<action>allow</action>

<src>

<address>0.0.0.0</address>

</src>

<dst>


<netmask>255.255.255.0</netmask>

</dst>

<protocol>tcp</protocol>

<service>http</service>

</rule>


This will be equivalent to the following IPF firewall rule:

pass proto TCP from ANY to 192.168.10.10 port=http

In other words traffic to a web server running on th IP address 192.168.10.10is allowed. Please refer to Section 4.4 for a brief explanation of the IPF rulesyntax.

5.4 IPv4 Address Validation

An IPv4 network address consists of three parts. Address, netmask and broad-cast address. If address and netmask is known it is possible to calculate thebroadcast address. And if the address and the broadcast address is know it ispossible to calculate the netmask. If no default netmask is given it is implicit ahost address this means that the netmask is effectively set to 255.255.255.255.Figure 5.4 shows the container class of an IPv4 Address.

(Generic)RuleSet

+rules

IPv4_Rule1 n

Figure 5.4: UML Diagram; IPv4 Address

<xsd:complexType name="ipv4">

<xsd:sequence>

<xsd:element name="address" type="basicip" minOccurs="1"

maxOccurs="1" />

<xsd:element name="netmask" type="basicip" minOccurs="0"

maxOccurs="1" />

<xsd:element name="broadcast" type="basicip" minOccurs="0"

maxOccurs="1" />

</xsd:sequence>

</xsd:complexType>

To reflect this, the XML Schema specifies that there must be at least one occur-rence of the address field. The netmask and broadcast fields are not mandatory.There can only be one occurrence of each element in a valid XML stream.The example below shows two valid IPv4 network address XML streams. Theyare packed in a src and dst element, but those element must be of the type IPv4,thus forcing them to comply with the above specified Schema.

<src>

5.5. ACTION VALIDATION 81



<broadcast>1.1.1.255</broadcast>

</src>

<dst>


</dst>

5.5 Action Validation

An action element can be either allow or deny. Figure 5.5 shows a UML diagramof the FilterAction class. The only member variable is a int. This in can onlybe set with a enum defined as follows:

enum FilterActions

{

ACTION_DENY = 1,

ACTION_ALLOW = 2,

};

This ensures that there are only two possible values for the member variable inthe Filteraction class. 1 if the action is deny and 2 if the action is allow.

FilterAction

+m_action: int

Figure 5.5: UML Diagram; FilterAction

The following part of the XML schema makes sure this is the case.

<xsd:simpleType name="action_content">

<xsd:restriction base="xsd:string">

<xsd:pattern value="allow|deny" />

</xsd:restriction>

</xsd:simpleType>

Examples of the only two valid action elements are given below.

<action>deny</action>

<action>allow</action>


5.6 Basic IP validation

Validating the content of a basic IP address is an important and reusable partof the XML Schema. This enables the system to detect invalid or mistyped IPaddresses early.

<xsd:simpleType name="basicip">


<xsd:pattern value="(([0-9]?[0-9]|[0-1][0-9][0-9]|[0-2][0-4]\

[0-4]|25[0-5])\.){3}([0-9]?[0-9]|[0-1][0-9][0-9]|[0-2][0-4]\

[0-4]|25[0-5])" />

</xsd:restriction>

</xsd:simpleType>

The above XML Schema will only allow addresses on the form of four octetsseparated by a full stop. The value of the octet must be between 0 and 255.Bellow three examples of valid basic address formats are given. The elementsaddress, netmask and broadcast are all of the type basic IP address.



<broadcast>1.1.1.255</broadcast>

5.7 Protocol Validation

This part of the XML Schema validates that the protocol part of the rule con-tains valid data if it is specified.

IPv4_Protocol

+protocol: int

Figure 5.6: UML Diagram; IPv4 Protocol

Figure 5.6 shows a UML diagram of the IPv4 Protocol class. The only membervariable is an int describing the protocol. As a useful feature the parser shouldalso accept a textual representation of known protocols such as tcp and udp.This is achieved with the following schema:

<xsd:simpleType name="protocol_content">


<xsd:pattern value="tcp|udp|any|[0-9]*" />

</xsd:restriction>

</xsd:simpleType>

5.8. SERVICE VALIDATION 83

Valid data in the protocol element is tcp, udp, any, or any number.Below is an example of valid protocol elements.

<protocol>tcp</protocol>

<protocol>udp</protocol>

5.8 Service Validation

This part of the schema ensures that the service (port) specification is valid.Figure 5.7 shows a UML diagram of the IPv4 Service class. This class has onlyone member variable. An integer value with the port number the service isrunning on.

IPv4_Service

+service: int

Figure 5.7: UML Diagram; IPv4 Service

Again it is convenient if the parser understands textual descriptions of commonlyused port numbers such as http, ssh, imap and so on.The following schema addresses this problem.

<xsd:simpleType name="service_content">


<xsd:pattern value="any|http|ssh|smtp|[0-9]*" />

</xsd:restriction>

</xsd:simpleType>

At the moment this XML Schema only validates the strings any, http, ssh andsmtp and any number. This should be expanded to cover all the entries in/etc/services.The following is a example of an valid XML stream.

<service>http</service>

<service>25</service>

5.9 Summary

Using XML to represent the data in the data model and an existing XML parserto read and write data to and from this model not only saves development timebut also reduces the risk of introducing bugs in the software. Writing a parser


is difficult and time consuming, and it is difficult to think of all possible thingsthat can go wrong when reading a file. Can a space here lead to problems,what about a newline after an occurrence of this data? By using XML all suchproblems are solved.However having a well formatted data stream like XML does not guarantee thatthe data is correct. The XML file or stream must also be validated. This isachieved with an XML Schema. A schema tells the XML parser what kindof data an element can contain. It is also possible to limit the number ofoccurrences of an element, or the maximum and minimum limits of the actualvalue.In this section a Schema for validating firewall rule-sets has been proposed.This schema makes it possible to ensure that the firewall or rule-sorter receivescorrect data. The schema also dictates the bare minimum of data needed forany meaningful firewall rule and rule-set. It is therefore possible to transforman XML stream that is validated by this schema to any native filtering rule-set available. An prototype which can transform an XML stream into an IPFrule-set has been developed.

Chapter 6

Conclusion and Future

Work

Security is important, and some argue that 3G will not be a commercial successuntil basic end user security is in place. A mobile phone contains as much criticaland important information as a PC, and thus it should be just as well protected.An Internet connected PC is almost always protected by some kind of firewall.A firewall provides basic security and is a very good first line of defence. As oftoday there exist no solutions the author is aware of in the market that provideexisting or emerging mobile phones with a firewall like first line of defence.In this thesis possible obstacles and solutions on how to implement a firewallsystem on a mobile device have been investigated.

A generic firewall system aimed towards an end user consists of the followingcomponents; A configuration utility (preferably graphical), some sort of logic toensure a correct rule-set, and at last the packet filter. In addition to that it isimportant to develop well defined interfaces between those components. Packetfilters must be considered to be a stable technology, and research efforts are bestspent on firewall management issues.

6.1 Conclusion

Presenting a firewall configuration to an end user is a difficult task. There isthe problem of making it simpler, without losing any of the advanced featuresof the firewall. The ideal solution would be a large red button with the text:“Secure me now”. However tempting it may sound to the end user this is notpossible to achieve. We need some more input from the user such as who hewants to communicate with and by what means. What services does he plan to

85

86 CHAPTER 6. CONCLUSION AND FUTURE WORK

use and how frequently. The user must be able to input the data in a quick andeasily understandable way. Furthermore the system should also respond witha visualization of the resulting policy. This is a difficult task on a stationaryfirewall with access to a large screen, and the user is a network administratorwith at least basic networking skills. Creating a firewall configuration for amobile device with a small screen, limited user input possibilities and userswith no understanding of the technology is even more challenging.In Chapter 3 a new firewall configuration visualization concept called “Slidethe Tiles” was presented. This solves many of the problems associated withcreating a graphical representation of a firewall configuration. The user is ableto configure a firewall policy on the small screen of an existing mobile phone.A prototype was developed running on Sony-Ericsson P800 and P900 mobilephones.Administrating and configuring a firewall is a difficult task. A rule-set canquickly become complicated and it is difficult to see the consequences of changingit. This makes it easy to introduce security holes by misconfiguration. Thisproblem and a proposed solution were presented in Chapter 4. A prototypeable to parse and check an IPF rule-set for errors was developed. As part ofthis development a set of object oriented algorithms for rule-set sorting andanomaly discovery was developed. The prototype is able to do sorting andanomaly checking on last hit match rule-sets. No relevant papers in the area offirewall management focusing on last hit match rule-sets were found.A limitation of the research is that the sorting and anomaly discovery prototypewas implemented on a single platform. Developing a prototype based on thesame algorithms that supports first-hit match rule-sets would resolve the issuesconcerning scalability.In Chapter 5 an XML Schema for common firewall rule-set fields was developed.This makes it easy to store any packet filtering firewall configuration in a moregeneric XML format. It also enables the possibility of easy translation betweendifferent native configuration formats.

6.2 Future Work

It was beyond the scope of this research project to perform any usability testingof the proposed mobile firewall GUI described in Chapter 3. A study of howusers with different technical knowledge and experience with mobile phoneswould be beneficial before any more development of the proposed GUI proceeds.The rule-set sorting and anomaly discovery prototype described in Chapter 4could be improved upon in several ways. Currently the prototype does not workon first-hit match rule-sets. Another limitation is the lack of proper support for

6.2. FUTURE WORK 87

handling of directions. In some cases when configuring IPFilter to allow trafficthrough the firewall it is necessary to allow traffic in to one network interfacecard and out another. Currently the prototype is unable to ensure that thishappens correctly, although the prototype in its current state will not introduceany security holes because of this. Furthermore the prototype is not able tosupport ranges. This is a handy feature for administrators to create rules witha range if IP addresses, protocols or port numbers.Extending the XML Schema proposed in Chapter 5 to include a subset of allcommon packet filtering firewall rule configuration possibilities is another areafor future work. To achieve this all common packet filtering firewall configura-tion formats must be examined, and a set of common attributes must be decidedupon.

88 CHAPTER 6. CONCLUSION AND FUTURE WORK

Bibliography

[1] 3GPP homepage. http://www.3gpp.org/.

[2] Design the firewall system. http://www.cert.org/security-improvements/practices/p053.html.

[3] Firewall history. http://dmsweb.badm.sc.edu/mgsc890/firewalls/fire2.htm.

[4] HLFL homepage. http://www.hlfl.org/.

[5] IPF homepage. http://coombs.anu.edu.au/ipfilter/.

[6] Netfilter FAQ. http://www.netfilter.org/documentation/.

[7] Netfilter homepage. http://www.netfilter.org/.

[8] OpenBSD PF FAQ. http://www.openbsd.org/faq/pf/.

[9] PF homepage. http://www.benzedrine.cx/pf.html.

[10] Symantec Security Response W32.Blaster.Worm.http://securityresponse.symantec.com/avcenter/venc/data/w32.blaster.worm.html.

[11] Trustix. http://www.trustix.com.

[12] XML Schema Homepage. http://www.w3.org/XML/Schema.

[13] An Introduction to Computer Security: The NIST Handbook. Number Spe-cial Publication 800-12. National Institute of Standards and TechnologyTechnology Administration U.S. Department of Commerce, 1996.

[14] Hari A, Suri S, and Parulkar G. Detecting and resolving packet filterconflicts. In INFOCOM 2000. Nineteenth Annual Joint Conference of theIEEE Computer and Communications Societies. Proceedings. IEEE, Vol.3,Iss., 26-30 Mar 2000 Pages:1203-1212 vol.3, 2000.

[15] E. Al-Shaer and H. Hamed. Modeling and management of firewall policies.In IEEE Transactions on Network and Service Management, Volume 1-1,April 2004.

89

90 BIBLIOGRAPHY

[16] Christoffer Andersson. GPRS and 3G Wireless Applications. John Wiley& Sons Inc; ISBN : 0-471-41405-0, 2001.

[17] A.Rubin, D. Geer, and M.Ranum. Web Security Sourcebook;. John Wiley& Sons; ISBN 047118148X, 1997.

[18] A.Wool. Architecting the lumeta firewall analyzer. In Proceedings of 10thUSENIX Security Symposium, August 2001.

[19] D.M Bakker and Diane McMichael Gilster. Bluetooth End to End. HungryMinds Inc; ISBN: 0-7645-4887-5, 2002.

[20] Y. Bartal, A. Mayer, K. Nissim, and A.. Wool. Firmato: a novel firewallmanagement toolkit. In Security and Privacy, 1999. Proceedings of the1999 IEEE Symposium on, Vol., Iss., 1999, 1999.

[21] Kent Beck. Extreme Programming Explained: Embrace Change. O’Reilly;ISBN: 1565928717; 2nd edition, 2000.

[22] Kent Beck. Test Driven Development: By Example. Addison-Wesley PubCo; 1st edition; ISBN: 0321146530, 2002.

[23] A. Begel, S. McCanne, and S. L. Graham. Bpf+: Exploiting global data-flow optimization in a generalized packet filter architecture. In In Proc. ofACM SIGCOMM ’99, 1999, 1999.

[24] W.R. Bellovin, S.M.and Cheswick. Network firewalls. IEEE Communica-tions Magazine, Vol.32, Iss.9, 1994.

[25] Simon Buckingham. Data on GPRS. Mobile Lifestreams; ISBN :1929105061, 1999.

[26] M. M. Buddhikot, S. Suri, and M.Waldvogel. Space decomposition tech-niques for fast layer-4 switching. In In Proc. of PHSN, Aug. 1999, 1999.

[27] Alistair Cockburn. Surviving Object-Oriented Projects. Addison-WesleyPub Co; ISBN 0201498340, 1997.

[28] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and CliffordStein. Introduction to Algorithms. MIT Press; ISBN 0262032937; 2ndedition, 2001.

[29] Cisco documentation group. Evolution of the firewall industry.http://www.cisco.com/univercd/cc/td/doc/product/iaabu/centri4/user/scf4ch3.htm.

BIBLIOGRAPHY 91

[30] Suelette Dreyfus. Computer hackers: Juvenile delinquents or internationatsaboteurs? Internet Crime Conference Melbourne, 16-17 February, 1998.

[31] Jon Ducket, Oliver Griffin, Stephen Mohr, Francis Norton, Ian Stockes-Rees, Kevin Williams, Kurt Cagle, Nikola Ozu, and Jeni tennison. XMLSchemas. Wrox Press Ltd; ISBN 1-861005-47-4, 2001.

[32] Al-Shaer E.S and Hamed H.H. Firewall policy advisor for anomaly discov-ery and rule editing. In Integrated Network Management, 2003. IFIP/IEEEEighth International Symposium on , 24-28 March 2003 Pages:17 - 30,2003.

[33] Al-Shaer E.S and Hamed H.H. Management and translation of filteringsecurity policies. In Communications, 2003. ICC ’03. IEEE InternationalConference on, Vol.1, Iss. Pages: 256- 260, 2003.

[34] A. Feldmann and S. Muthukrishnan. Tradeoffs for packet classification. InProc. of 19th IEEE INFOCOM, Mar. 2000, 2000.

[35] Martin Fowler. UML Distilled: A Brief Guide to the Standard Object Mod-eling Language. Addison-Wesley Pub Co; 3rd edition; ISBN: 0321193687,2003.

[36] V. Fuller, T. Li, J. Yu, and K. Varadhan. RFC 1519: Classless Inter-DomainRouting (CIDR): an Address Assignment and Aggregation Strategy, 1993.

[37] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. DesignPatterns. Addison-Wesley Pub Co; ISBN: 0201633612 ; 1st edition, 1995.

[38] Matthw S. Gast. 802.11 Wireless Networks. O’Reilly & Associates; ISBN0-595-00183-5, 2002.

[39] Internet Engineering Steering Group. RFC 1517: Applicability Statementfor the Implementation of Classless Inter-Domain Routing (CIDR), 1993.

[40] J. D. Guttman. Filtering postures: Local enforcement for global policies.In n Proc. of IEEE Symp. on Security and Privacy, pages 120.129, 1997,1977.

[41] Timo Halonen, Javier Romero, and Juan Melero (Editor). GSM, GPRSand EDGE Performance : Evolution Towards 3G/UMTS. John Wiley &Sons Inc; ISBN : 0470866942, 2003.

[42] H. Hamed and E. Al-Shaer. Design and implementation of firewall policyadvisor tools. In DePaul CTI Technical Report, CTI-TR-02-006, 2002.

92 BIBLIOGRAPHY

[43] Daniel Hartmeier. Design and performance of the OpenBSD stateful packetfilter (pf). In USENIX, 2002.

[44] R. Rashid J. Mogul and M. Accetta. The packet filter: An efficient mech-anism for user-level network code. In Proceedings of the 11th ACM Sym-posium on Operating Systems Principles (SOSP), volume 21, pages 39–51,1987.

[45] Tom Karygiannis and Les Owens. Wireless network security; 802.11, blue-tooth and handheld devices (draft). National Institute of Standards andTechnology, Special Publication 800-48, 2002.

[46] Xiang-Yang Alex Liu and Mohamed G. Gouda. Firewall design: consis-tency, completeness and compactness. In Proc. 24th Int. Conf. DistributedComputing Systems (ICDCS 2004), IEEE, Mar 2004.

[47] Bertrand Meyer. Object Oriented Software Construction. Prentice Hall;ISBN 0136299554, 2000.

[48] J. Mogul and J. Postel. RFC 950: Internet Standard Subnetting Procedure,1985.

[49] Thomas J. Mowbray, William A. Ruh, and Richard M. Soley. Inside Corba:Distributed Object Standards and Applications. Addison-Wesley Pub Co;1st edition; ASIN 0201895404, 1997.

[50] Y. Rekhter, T.J. Watson, and T. Li. RFC 1518: An Architecture for IPAddress Allocation with CIDR, 1993.

[51] Smith R.N. and Bhattacharya S. Firewall placement in a large networktopology. In Distributed Computing Systems, 1997., Proceedings of theSixth IEEE Computer Society Workshop on Future Trends of, Vol., Iss.,29-31, 1997.

[52] Hazelhurst S, Attar A, and Sinnappan R. Algorithms for improving thedependability of firewall and filter rule lists. In Dependable Systems andNetworks, 2000. DSN 2000. Proceedings International Conference on, Vol.,Iss., 2000 Pages:576-585, 2000.

[53] Knut Soelberg and Jon lnes. Internet sikkerhet - en oversikt. InUNINETT’95, 1995.

[54] Wes Sonnenreich and Tom Yates. Building Linux and OpenBSD Firewalls.John Wiley & Sons; ISBN 0471353663, 2000.

BIBLIOGRAPHY 93

[55] V. Srinivasan, G. Vargheseand S. Suri, and M. Waldvogel. Fast and scalablelayer four switching. In In Proc. of ACM SIGCOMM, pages 191.202, 1998.,1998.

[56] B. Walke, P. Seidenberg, and M. P. Althoff. UMTS: The Fundamentals.John Wiley & Sons Inc; ISBN : 0470845570, 2002.

[57] R. Zalenski. Firewall technologies. In IEEE Potentials, Vol.21, Iss.1,Feb/Mar 2002, 2002.

[58] Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman. BuildingInternet Firewalls. Addison-Wesley Pub Co; ISBN: 0201710919; 1st edition,2000.

94 BIBLIOGRAPHY

Appendix A

Firewall XML Schema

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"targetNamespace="http://www.rulesorter.org"elementFormDefault="qualified">

<xsd:annotation><xsd:documentation>Schema for packet filtering firewallrulesets

</xsd:documentation></xsd:annotation>

<xsd:element name="ruleset"><xsd:complexType><xsd:sequence><xsd:element name="rule" type="filterRule"

maxOccurs="unbounded" /></xsd:sequence>

</xsd:complexType></xsd:element>

<xsd:complexType name="filterRule"><xsd:annotation><xsd:documentation>The filterRule type holds information needed to set up asingle rule on a packet filtering firewall.

</xsd:documentation></xsd:annotation><xsd:sequence><xsd:element name="action" type="action_content"minOccurs="1" default="deny"/>

<xsd:element name="src" type="ipv4" minOccurs="1" /><xsd:element name="dst" type="ipv4" minOccurs="1" /><xsd:element name="protocol" type="protocol_content"minOccurs="0" default="any"/>

<xsd:element name="service" type="service_content"minOccurs="0" default="any"/>

95

96 APPENDIX A. FIREWALL XML SCHEMA

</xsd:sequence></xsd:complexType>

<xsd:complexType name="ipv4"><xsd:sequence><xsd:element name="address" type="basicip" minOccurs="1"maxOccurs="1" />

<xsd:element name="netmask" type="basicip" minOccurs="0"maxOccurs="1" />

<xsd:element name="broadcast" type="basicip" minOccurs="0"maxOccurs="1" />

</xsd:sequence></xsd:complexType>

<xsd:simpleType name="action_content"><xsd:restriction base="xsd:string"><xsd:pattern value="allow|deny" />

</xsd:restriction></xsd:simpleType>

<xsd:simpleType name="basicip"><xsd:restriction base="xsd:string"><xsd:pattern value="(([0-9]?[0-9]|[0-1][0-9][0-9]|[0-2][0-4]\

[0-4]|25[0-5])\.){3}([0-9]?[0-9]|[0-1][0-9][0-9]|[0-2][0-4][0-4]|\25[0-5])" />


<xsd:simpleType name="protocol_content"><xsd:restriction base="xsd:string"><xsd:pattern value="tcp|udp|any|[0-9]*" />


<xsd:simpleType name="service_content"><xsd:restriction base="xsd:string"><xsd:pattern value="any|http|ssh|smtp|[0-9]*" />


</xsd:schema>

Appendix B

XML Stream

<?xml version="1.0"?><ruleset xmlns="http://www.rulesorter.org"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.rulesorter.org fwXML.xsd"><rule><action>deny</action><src><address>192.168.10.13</address><netmask>255.255.255.0</netmask><broadcast>192.168.10.255</broadcast>

</src><dst><address>158.38.48.10</address><netmask>255.255.255.255</netmask>

</dst><protocol>tcp</protocol><service>http</service>

</rule><rule>

<action>allow</action><src><address>0.0.0.0</address>

</src><dst><address>67.78.145.0</address><netmask>255.255.255.0</netmask>

</dst><protocol>65</protocol>

</rule></ruleset>

97

98 APPENDIX B. XML STREAM

Appendix C

UML Diagrams

Figure C.1: Prototype Design Overview

99

100 APPENDIX C. UML DIAGRAMS

Figure C.2: IPv4 Rule Subsystem Design

Appendix D

Source Code

D.1 IPv4 Address

compare

int IPv4 Address::compare( IPv4 Address *input address ){

// If broadcast addresses are equal - we do a compare on the network addresses// If this network address is less than input network address, this is more// general and we return positive.if( getBroadcastAsLong() == input address−>getBroadcastAsLong() ){

if( getNetworkAddressAsLong() == input address−>getNetworkAddressAsLong() ){

return 0; 10

}return (input address−>getNetworkAddressAsLong() < getNetworkAddressAsLong() )? −1 : 1;

}

// If this broadcast address is less than input broadcast address, this is more// specific and we return negative.return (getBroadcastAsLong() < input address−>getBroadcastAsLong())? −1 : 1;

}

coveredBy

bool IPv4 Address::coveredBy( IPv4 Address *input address ){

if( (getNetworkAddressAsLong() >= input address−>getNetworkAddressAsLong())&& ( getBroadcastAsLong() <= input address−>getBroadcastAsLong()) )

{return true;

}

return false;} 10

101

102 APPENDIX D. SOURCE CODE

getNetworkAddressAsLong

unsigned long IPv4 Address::getNetworkAddressAsLong()

{unsigned long netaddress = ip address & netmask;

return netaddress;

}

getBroadcastAsLong

unsigned long IPv4 Address::getBroadcastAsLong()

{unsigned long netaddress = getNetworkAddressAsLong();

// unsigned long broadcast = netaddress ^ ˜netmask; // XOR

unsigned long broadcast = netaddress | ˜netmask; // OR

return broadcast;

}

D.2 IPv4 Protocol

compare

int IPv4 Protocol::compare( IPv4 Protocol *input protocol )

{if( getProtocolAsInt() == input protocol−>getProtocolAsInt() )

return 0;

if( getProtocolAsInt() == −1 )

return 1;

10

if( input protocol−>getProtocolAsInt() == −1 )

return −1;

return (getProtocolAsInt() < input protocol−>getProtocolAsInt() )? −1 : 1;

}

coveredBy

bool IPv4 Protocol::coveredBy( IPv4 Protocol *input protocol )

{if( input protocol−>getProtocolAsInt() == −1) return true;

if( input protocol−>getProtocolAsInt() == getProtocolAsInt() ) return true;

return false;

}

D.3. IPV4 SERVICE 103

D.3 IPv4 Service

compare

int IPv4 Service::compare( IPv4 Service *input service ){

if( getServiceAsInt() == input service−>getServiceAsInt() )return 0;

// This service (any) is always more general - we return positiveif( getServiceAsInt() == −1 )

return 1;

// This service is always more specific than input service (any) 10

// - we return negativeif( input service−>getServiceAsInt() == −1 )

return −1;

return (getServiceAsInt() < input service−>getServiceAsInt() )? −1 : 1;}

coveredBy

bool IPv4 Service::coveredBy( IPv4 Service *input service ){

if( input service−>getServiceAsInt() == −1) return true;if( input service−>getServiceAsInt() == getServiceAsInt() ) return true;return false;

}

D.4 IPv4 Action

compare

int FilterAction::compare( FilterAction *input action ){

if( getActionAsInt() == input action−>getActionAsInt() )return 0;

return( ( getActionAsInt() < input action−>getActionAsInt() )? −1: 1 );}

D.5 IPv4 Rule

compare

int IPv4 Rule::compare( const IPv4 Rule* const input rule ) const{

int retval = 0;

retval = (getInterfaceName().compare( input rule−>getInterfaceName()))*−1;if( retval == 0)


{retval = getDirection()−>compare( input rule−>getDirection() );if(retval == 0)

{ 10

retval = getSrcAddress()−>compare( input rule−>getSrcAddress() );if( retval == 0 )

{retval = getDstAddress()−>compare( input rule−>getDstAddress() );if( retval == 0 )

{retval = getProtocol()−>compare( input rule−>getProtocol() );if( retval == 0 )

{retval = getService()−>compare( input rule−>getService() ); 20

if( retval == 0 ){

retval = getAction()−>compare( input rule−>getAction() );}

}}

}}

}30

if(m Sorder == ccsa::LAST HIT){

retval = lastHitCorrections( input rule, retval);}

if(m Sorder == ccsa::FIRST HIT){

retval = firstHitCorrections( input rule, retval);}

40

return retval;}

lastHitCorrections

int IPv4 Rule::lastHitCorrections( const IPv4 Rule* const input rule,int const in sorting) const

{int retval = in sorting;//Special case with quick rules.//If both rules are quick they should be sorted as a First hit.if(isQuick() && input rule−>isQuick())

{//If any of the rules handles fragments it should be sorted first. .if(coverFragments()) 10

{retval = −1;

}else if(input rule−>coverFragments())

{retval = 1;

}return retval;

}20

//Makes this more spesific, and is sorted first.

D.5. IPV4 RULE 105

if(isQuick()){

return −1;}

//Makes input rule more spesificif(input rule−>isQuick())

{return 1; 30

}

//No quick rules. Just reverse the order.return retval*−1;

}

firstHitCorrections

int IPv4 Rule::firstHitCorrections( const IPv4 Rule* const input rule,int const in sorting) const

{//For the time beeing do nothing. . .return in sorting;

}

coveredBy

bool IPv4 Rule::coveredBy( IPv4 Rule *input rule ) const{

//fragmented rules does not cover anything. .if(input rule−>coverFragments()) return false;

//rules with different direction can not cover each otherif((getDirection()−>compare(input rule−>getDirection())!=0)) return false;

//Rules with diffeent interface name does not cover each otherif( getInterfaceName() != input rule−>getInterfaceName()) return false; 10

return( getSrcAddress()−>coveredBy( input rule−>getSrcAddress() ) &&getDstAddress()−>coveredBy( input rule−>getDstAddress() ) &&getProtocol()−>coveredBy( input rule−>getProtocol() ) &&getService()−>coveredBy( input rule−>getService() ) );

}

correlated

bool IPv4 Rule::correlated( IPv4 Rule *input rule ) const{

unsigned int sub = getSubSetFlag(input rule);unsigned int eq = getEqualFlag(input rule);unsigned int sup = getSuperSetFlag(input rule);//This must be adjusted if more fields are to be checked for possible//correlation. We only check for src,dst,prot and port. That is four (4) bits.unsigned int all bits = 0x0000000F;unsigned int no bits = 0x0; 10


if(sub+sup+eq == all bits &&sub != all bits &&sup != all bits &&eq!= all bits &&sub!= no bits &&sup!= no bits ){

//If the action is fifferent then we have a correlation. .if(input rule−>getAction()−>getActionAsInt() != getAction()−>getActionAsInt()) 20

{return true;

}}

return false;

}

getSubSetFlag

unsigned int IPv4 Rule::getSubSetFlag( IPv4 Rule *input rule ) const{

unsigned int sub = 0;

if( getSrcAddress()−>compare( input rule−>getSrcAddress() ) < 0 &&getSrcAddress()−>coveredBy( input rule−>getSrcAddress() ) ) sub += 1;

if( getDstAddress()−>compare( input rule−>getDstAddress() ) < 0 &&getDstAddress()−>coveredBy( input rule−>getDstAddress() ) ) sub += 2;

10

if( getProtocol()−>compare( input rule−>getProtocol() ) < 0 &&getProtocol()−>coveredBy( input rule−>getProtocol() ) ) sub += 4;

if( getService()−>compare( input rule−>getService() ) < 0 &&getService()−>coveredBy( input rule−>getService() )) sub +=8;

return sub;}

getSuperSetFlag

unsigned int IPv4 Rule::getSuperSetFlag( IPv4 Rule *input rule ) const{

unsigned int sup = 0;

if( input rule−>getSrcAddress()−>compare( getSrcAddress() ) < 0 &&input rule−>getSrcAddress()−>coveredBy( getSrcAddress() ) ) sup += 1;

if( input rule−>getDstAddress()−>compare( getDstAddress() ) < 0 &&input rule−>getDstAddress()−>coveredBy( getDstAddress() ) ) sup += 2;

10

if( input rule−>getProtocol()−>compare( getProtocol() ) < 0 &&input rule−>getProtocol()−>coveredBy( getProtocol() ) ) sup += 4;

if( input rule−>getService()−>compare( getService() ) < 0 &&input rule−>getService()−>coveredBy( getService() )) sup +=8;

D.6. FWRULESET 107

return sup;}

getEqualFlag

unsigned int IPv4 Rule::getEqualFlag( IPv4 Rule *input rule ) const{

unsigned int eq = 0;if( getSrcAddress()−>compare( input rule−>getSrcAddress() ) == 0 ) eq += 1;if( getDstAddress()−>compare( input rule−>getDstAddress() ) == 0 ) eq += 2;if( getProtocol()−>compare( input rule−>getProtocol() ) == 0 ) eq += 4;if( getService()−>compare( input rule−>getService() ) == 0 ) eq +=8;return eq;

}10

D.6 FwRuleSet

checkRuleSetErrors

bool FwRuleSet::checkRuleSetErrors(){

bool error = false;if(checkRedundant()) error = true;if(checkShadowed()) error = true;if(checkCorrelated()) error = true;return error;

}

checkRedundant

bool FwRuleSet::checkRedundant(){

bool redundant = false;int numberOfRules = getNumberOfRules();

for( int i = 0; i < numberOfRules; i++ ){

FwRule *rule1 = getRule(i);for( int j = i+1; j < numberOfRules; j++)

{ 10

FwRule *rule2 = getRule(j);if(rule2−>coveredBy(rule1) &&

rule2−>getIPv4Rule()−>getAction()−>compare(rule1−>getIPv4Rule()−>getAction())==0){

bool needed = false;for(int k = 0; k < numberOfRules; k++)

{if(k!=j) //Dont bother checking yourself. .

{ 20

FwRule *rule3 = getRule(k);if(isNeeded(rule2,rule1,rule3))

{needed =true;


}}

}if(!needed)

{rule2−>setRedundant(true); 30

rule2−>addBlockedBy(rule1);redundant=true;

}}

}}//for

return redundant;}

isNeeded

bool FwRuleSet::isNeeded(FwRule* const needed,FwRule* const rule1,FwRule* const rule2) const

{if( needed−>coveredBy(rule2) &&

needed−>getIPv4Rule()−>getAction()−>compare(rule2−>getIPv4Rule()−>getAction())!=0 )

{if( needed−>compare(rule2) > 0 &&

rule1−>compare(rule2) < 0) 10

{return true;

}}

return false;}

checkShadowed

bool FwRuleSet::checkShadowed(){

bool shadowed = false;int numberOfRules = getNumberOfRules();


FwRule *rule1 = getRule(i);for( int j = i+1; j < numberOfRules; j++) 10

{FwRule *rule2 = getRule(j);if(rule2−>coveredBy(rule1) &&

//rule2->compare(rule1) >= 0 &&rule2−>getIPv4Rule()−>getAction()−>compare(rule1−>getIPv4Rule()−>getAction())!=0){

if( rule1−>coveredBy(rule2) | |rule1−>getIPv4Rule()−>isQuick() | |rule2−>compare(rule1) <= 0) 20

//if( true )

D.6. FWRULESET 109

{//make sure we remove the least restrictive ruleif(rule1−>getIPv4Rule()−>getAction()−>

compare(rule2−>getIPv4Rule()−>getAction()) > 0){

rule1−>setShadowed(true);rule1−>addBlockedBy(rule2);shadowed = true;

} 30

else{

rule2−>setShadowed(true);rule2−>addBlockedBy(rule1);shadowed = true;

}

}}

} 40

}//for

return shadowed;}

checkCorrelated

bool FwRuleSet::checkCorrelated(){bool correlated = false;int numberOfRules = getNumberOfRules();


FwRule *rule1 = getRule(i);for( int j = i+1; j < numberOfRules; j++)

{ 10

FwRule *rule2 = getRule(j);if(rule1−>correlated(rule2))

{rule1−>setCorrelated(true);rule1−>addBlockedBy(rule2);rule2−>addBlockedBy(rule1);rule2−>setCorrelated(true);correlated = true;

}20

}}//for

return correlated;}

Appendix E

IPF BNF ConfigurationFormat

filter-rule = [ insert ] action in-out [ options ] [ tos ] [ ttl ][ proto ] [ ip ] [ group ].

insert = "@" decnumber .action = block | "no-match" | "pass" | log | "count" | skip | auth | call .in-out = "in" | "out" .options = [ log ] [ "quick" ] [ "on" interface-name [ dup ] [ froute ]

[ via ] ] .tos = "tos" decnumber | "tos" hexnumber .ttl = "ttl" decnumber .proto = "proto" protocol .ip = srcdst [ flags ] [ with withopt ] [ icmp ] [ keep ] .group = [ "head" decnumber ] [ "group" decnumber ] .

block = "block" [ return-icmp[return-code] | "return-rst" ] .auth = "auth" | "preauth" .log = "log" [ "body" ] [ "first" ] [ "or-block" ] [ "level" loglevel ] .call = "call" [ "now" ] function-name .skip = "skip" decnumber .dup = "dup-to" interface-name[":"ipaddr] .via = "in-via" interface-name | "out-via" interface-name .froute = "fastroute" | "to" interface-name [ ":" ipaddr ] .protocol = "tcp/udp" | "udp" | "tcp" | "icmp" | decnumber .srcdst = "all" | fromto .fromto = "from" object "to" object .

return-icmp = "return-icmp" | "return-icmp-as-dest" .loglevel = facility"."priority | priority .object = addr [ port-comp | port-range ] .addr = "any" | nummask | host-name [ "mask" ipaddr | "mask" hexnumber ] .port-comp = "port" compare port-num .port-range = "port" port-num range port-num .

111

112 APPENDIX E. IPF BNF CONFIGURATION FORMAT

flags = "flags" flag { flag } [ "/" flag { flag } ] .with = "with" | "and" .icmp = "icmp-type" icmp-type [ "code" decnumber ] .return-code = "("icmp-code")" .keep = "keep" "state" | "keep" "frags" | "keep" "state-age" state-age .state-age = decnmber [ "/" decnumber ] .

nummask = host-name [ "/" decnumber ] .host-name = ipaddr | hostname | "any" .ipaddr = host-num "." host-num "." host-num "." host-num .host-num = digit [ digit [ digit ] ] .port-num = service-name | decnumber .

withopt = [ "not" | "no" ] opttype [ withopt ] .opttype = "ipopts" | "short" | "frag" | "opt" ipopts .optname = ipopts [ "," optname ] .ipopts = optlist | "sec-class" [ secname ] .secname = seclvl [ "," secname ] .seclvl = "unclass" | "confid" | "reserv-1" | "reserv-2" | "reserv-3" |"reserv-4" | "secret" | "topsecret" .

icmp-type = "unreach" | "echo" | "echorep" | "squench" | "redir" |"timex" | "paramprob" | "timest" | "timestrep" | "inforeq" |"inforep" | "maskreq" | "maskrep" | "routerad" |"routersol" | decnumber .

icmp-code = decumber | "net-unr" | "host-unr" | "proto-unr" | "port-unr" |"needfrag" | "srcfail" | "net-unk" | "host-unk" | "isolate" |"net-prohib" | "host-prohib" | "net-tos" | "host-tos" |"filter-prohib" | "host-preced" | "cutoff-preced" .

optlist = "nop" | "rr" | "zsu" | "mtup" | "mtur" | "encode" | "ts" | "tr" |"sec" | "lsrr" | "e-sec" | "cipso" | "satid" | "ssrr" | "addext" |"visa" | "imitd" | "eip" | "finn" .

facility = "kern" | "user" | "mail" | "daemon" | "auth" | "syslog" |"lpr" | "news" | "uucp" | "cron" | "ftp" | "authpriv" |"audit" | "logalert" | "local0" | "local1" | "local2" |"local3" | "local4" | "local5" | "local6" | "local7" .

priority = "emerg" | "alert" | "crit" | "err" | "warn" | "notice" |"info" | "debug" .

hexnumber = "0" "x" hexstring .hexstring = hexdigit [ hexstring ] .decnumber = digit [ decnumber ] .

compare = "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" |"le" | "ge" .

range = "<>" | "><" .hexdigit = digit | "a" | "b" | "c" | "d" | "e" | "f" .digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" .flag = "F" | "S" | "R" | "P" | "A" | "U" .

conﬁguration and implementation issues for a firewall...

Documents