A SEMINAR REPORT

ON

“Firewall Fingerprinting and Denial of Firewalling Attacks ”

SUBMITTED TO THE SAVITRIBAI PHULE PUNE UNIVERSITY ,PUNE

IN PARTIAL FULFILLMENT OF THE REQUIREMENTS
FOR THE AWARD OF THE DEGREE

THIRD YEAR OF ENGINEERING

(Computer Engineering)

BY

Mr. Gade Aniket Nagnath

Exam Seat No: T150194220

UNDER THE GUIDANCE OF

Prof. Khalate Y. R.

DEPARTMENT OF COMPUTER ENGINEERING

SVPM’S COLLEGE OF ENGINEERING
MALEGAON(Bk)
2018-2019
 DEPARTMENT OF COMPUTER ENGINEERING
SVPM’S COLLEGE OF ENGINEERING
SEMESTER VI 2018-2019

CERTIFICATE

This is to certify that the seminar work entitled

Firewall Fingerprinting and Denial of Firewalling Attacks
Submitted by
Mr. Gade Aniket Nagnath
Exam Seat No: T150194220

is a bonafide work carried out under the supervision of Prof. Y.R.Khalate

and it is submitted towards the partial fulfilment of the requirement
of savitribai phule pune university,pune for the award of the degree of
Third year of Engineering(Computer Engineering).

Prof. Y.R.Khalate Prof. H.R.Kumbhar

(Guide) (HOD Computer Dept.)

Dr. S.M. Mukane

(Principal)

Place: Malegaon(b.k)
Date:
 Acknowledgement

First and foremost, praises and thanks to the God, the almighty, for showers of
blessings throughout our seminar work to complete the seminar report successfully.

We would like to express our deep and sincere gratitude to our Seminar Guide,
Prof. Khalate Y. R. and Head of Computer Department Prof. Kumbhar H. R.,
S.V.P.M College of Engineering Malegaon BK. for giving the opportunity to do
Seminar Report and providing invaluable guidance throghout this Seminar.

Also, I would like to Thanks our project CoordinatorProf. Nimbalkar S. S.,

His Dynamism, Vision, Sincerity and Motivation have deeply inspired us.

It was a great privilege and honor to do work and study under his guidance
we extremely grateful for what he has offered us.

Also we express our thanks to principal Dr. Mukane S. M. and staff mem-
bers, in laws for their support and valuable prayers. Our special thanks goes to our
friends for the keen interest shown to complete this seminar Successfully.

Student Name
Contents

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

1 ABSTRACT 1
1.1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 INTRODUCTION 2
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 LITERATURE REVIEW 5
3.1 Review of Literature . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 TYPES OF FIREWALLS 8
4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 ALGORITHMS 15
5.1 Firewall Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . 15
5.2 RULE MATCHING ALGORITHM . . . . . . . . . . . . . . . . . 16

6 ANALYTIC STUDY 19
6.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 DENIAL OF FIREWALL ATTACKS 20

7.1 An Overview of DoS Attacks . . . . . . . . . . . . . . . . . . . . . 20

8 CONCLUSIONS 22

Bibliography 23
List of Figures

i
List of Tables

ii
 Abbreviations

DDoS : Distributed Denial of Service

DHCP : Dynamic Host Configuration Protocol
DNS : Domain Name System
DoS : Denial of Service
DPI : Deep Packet Inspection
HTTP : Hyper Text Transfer Protocol
ICMP : Internet Control Message Protocol
IDS : Intrusion Detection System
IP : Internet Protocol
LDAP : Lightweight Directory Access Protocol
NFS : Network File System
OSI : Open Systems Interconnection
SMTP : Simple Mail Transfer Protocol
SSH : Secure Shell
TCP : Transmission Control Protocol
UDP : User Datagram Protocol
VPN : Virtual Private Network

iii
Chapter 1

ABSTRACT

1.1 Abstract
Firewalls are critical security devices handling all traffic in and out of a net-
work. Firewalls, like other software and hardware network devices, have vulnera-
bilities, which can be exploited by motivated attackers. However, just like any other
networking and computing devices, firewalls often have vulnerabilities that can be
exploited by attackers. In this paper, first, we investigate some possible firewall
fingerprinting methods and surprisingly found that these methods can achieve quite
high accuracy. Second, we study what we call Denial of Firewalling (DoF) attacks,
where attackers use carefully crafted traffic to effectively overload a firewall. To our
best knowledge, this paper represents the first study of firewall fingerprinting and
Denial of Firewalling attacks.

The basic purpose of a firewall, whether corporate or SOHO is to prevent

unauthorized access to or from a private network (Webopedia). Firewalls do this
by, among other things, controlling which TCP and UDP ports traffic is allowed in
and out of. Historically, firewalls have been very difficult to install, configure, and
maintain. In an attempt to rectify this problem, and in order to add new features to
their products, such as remote management and VPN support, firewall vendors have
added in additional user-friendly features to make maintenance and management
easier as well as to provide these features. In many cases the side-effect of this has
been to open up additional TCP and/or UDP ports in the firewall to accommodate
these features. In many cases the port numbers associated with these services are
unusual enough that they can be recognized and associated with the particular ven-
dor. This opens up the possibility of ”fingerprinting” a firewall based on the results
of a port scan of the firewall.

1
Chapter 2

INTRODUCTION

2.1 Introduction
There are currently a wide variety of firewalls and firewall-type products on
the market: everything from software-based desktop firewalls such as Zone Alarm
all the way to larger, more expensive firewalls such as the Cisco PIX series of fire-
walls. What many of these firewalls seem to have in common is an increasing trend
towards ease of use and ease of administration. While this trend is not necessarily a
bad thing (nobody wants firewalls to be harder to manage, after all), there is at least
one possible ramification to this trend towards ease of management.

Several firewalls currently on the market open various TCP and/or UDP ports
by default for a wide variety of purposes. As a general rule these ports are generally
open for purposes such as remote management, inter-device communication, or for
VPNs. While not a bad thing in and of itself, it does present a rather unique situa-
tion: The corporate firewall, which is supposed to be monitoring and locking down
access to these ports, can in some cases be opening up new ones for its own use.

This fact opens up the intriguing possibility of fingerprinting firewalls using

known TCP/UDP port combinations in much the same manner that Nmap uses mal-
formed packets to fingerprint operating systems. If a hacker is aware that a specific
port or a combination of ports is associated with a certain firewall ( a Watchguard
Firebox II, for example), he would be able to use a port scanner to identify the fire-
wall with a reasonable degree of accuracy. While not an exploit in and of itself, this
would still be a potentially valuable reconnaissance technique, as it would allow
the hacker to determine the manufacturer (and possibly the model in some cases)
of the firewall being run by an organization. The hacker could then simply then

2
2.2. MOTIVATION CHAPTER 2. INTRODUCTION

search for known vulnerabilities for the identified firewall type and proceed to try
the exploit(s) against the target firewall.

It should be noted at the outset however, that not all firewalls that implement
remote management or other features will immediately be vulnerable to this type of
enumeration. Through the judicious use of port scanners and tools such as Fyodors
Nmap, it can be relatively easy to identify whether or not a firewall or firewall-like
device is leaking information of this type.

Of course, the best defense against this problem is simply to close down the
offending port(s) if at all possible. If not, it may be necessary to block the port(s)
at a perimeter device located further out in your network (such as a border router)
in order to prevent the identification of your firewall. Changing the default port
number is also a valid method to deter fingerprinting; unfortunately some firewalls
do not allow you to change the default port numbers. The use of a Network Intru-
sion Detection System (NIDS) ruleset to detect scans against known ports is also
advisable.

2.2 Motivation
The security and reliability of firewalls are critical because they serve as the
first line of defense in examining all traffic in and out of a network and they have
been widely deployed for protecting both enterprise and backbone networks. How-
ever, just like any other networking and computing devices, firewalls often have
vulnerabilities that can be exploited by attackers [1], [2]. To exploit firewall vul-
nerabilities, the first step that attackers need to do is firewall fingerprinting, i.e.,
identifying the particular implementation of a firewall including brand name, soft-
ware/firmware version number, etc.

On the defense side, we need to know how attackers possibly can fingerprint
a firewall so that we can design countermeasures accordingly. In this paper, for the
first time, we investigate firewall fingerprinting methods with quite high accuracy.
Designing countermeasures for firewall fingerprinting is out of the scope of this
paper, but is the next step of this line of research.

Dept. of Comp Engg. 3 SVPM’s COE,Malegaon(Bk)

2.3. OBJECTIVES CHAPTER 2. INTRODUCTION

2.3 Objectives

2.4 Outcomes

2.5 Advantages

Dept. of Comp Engg. 4 SVPM’s COE,Malegaon(Bk)

Chapter 3

LITERATURE REVIEW

3.1 Review of Literature

3.1 Firewall Types 1. Packet Filter Firewall: These are based on first generation
firewall technology. They analyze network traffic at the transport layer. They exam-
ine each IP network packet to see if it matches one of the rules defined for allowing
or denying data flows. The decision is based on the information they get from the
packet’s transport layer headers and the direction the packet is going into. They are
therefore configured to check: Transport layer type (TCP, ICMP and UDP) Source
port Destination IP address Source IP address Network interface the packet arrives
on Destination port Packet filters do the above by applying a rule set residing in the
TCP/IP kernel that defines what action goes with which rule[16 ].
2. Circuit Level Firewalls: These are based on second generation firewall tech-
nology. They work based on the fact that a packet is either a data packet or a
connection request belonging to a connection or circuit between two peer transport
layers. These firewalls work by: - checking that each connection setup follows a
handshake system for the transport layer protocol being used. - Storing a session
identifier for the connection - Connection state: handshake, established, or closing
- Only forwarding packets after the handshake is complete - Maintaining a table of
valid connections and removing it once the connection is terminated - Closing the
virtual circuit after transmission
3. Application Layer Firewall: Also called third generation firewall. These
firewalls evaluate packets for valid data at the application layer before allowing a
connection. - Examines data in network packets at the application layer - Maintains
connection state and sequencing information - Can validate passwords and service
requests Most of them include proxy services for specific services such as HTTP

5
3.1. REVIEW OF LITERATURE CHAPTER 3. LITERATURE REVIEW

or FTP which provide more checks and generate audit records about the traffic they
transfer.
4. Dynamic Firewall: A fourth generation firewall type allowing modification of
the rule base. A virtual connection is established and the packet is allowed to travel
the firewall server. These provide support for UDP packets by associating them with
a virtual connection. The connection information is kept for a short period and the
connection is terminated if no response packet is received within that short time.
They are good for not allowing unwanted UDP packets into a network because the
response packet must contain a destination address that matches the original source
address.
5. Hybrid Firewall: Because of the need to do more than packet inspection,
firewalls are being implemented as hybrid systems. These are mostly implemented
by adding packet filtering to an application gateway. Cisco PIX firewalls are an
example of such hybrid firewalls.

Two additional categories of firewall exist depending on whether the firewall

keeps track of the state of network connections or treats each packet in isolation.
1. Stateful Firewall :- It deals with the state of connections, state here is defined
as the condition of connection, which varies greatly depending on application or
protocol used. In Stateful firewall when the first packet in a network is allowed to
cross the firewall then all subsequent packets belonging to that flow and especially
the return traffic flow is also allowed to pass through the firewall. Stateful firewalls
typically build a state table and use this table to allow only returning traffic from
connections currently listed in the state table. After a connection is removed from
the state table, no traffic from the external device of this connection is permitted.
This statefulness has two advantages:
a. No need to write explicit rules for return traffic and such return-traffic rules
are inherently insecure since they rely on source-port filtering. This makes Stateful
firewalls more secure as compare to stateless firewall.
b. State lookup algorithms are typically simpler and faster than the rule-match
algorithms.
2. Stateless Firewall :- In stateless firewall packet filters at network layer or
it uses transport layer information only so they only look at the header part of a
packet. The packet filter does not examine the data section of a packet. Action

Dept. of Comp Engg. 6 SVPM’s COE,Malegaon(Bk)

3.1. REVIEW OF LITERATURE CHAPTER 3. LITERATURE REVIEW

decides which service is to permits or denies i.e. to allow the packets or to drop
them. Because of the stateless nature it needs to monitor all the incoming and
outgoing packets which is time consuming as each and every packets need to be
matched with the firewall rule list to check if the packets should be allowed or need
to get drop out of the system. Also search mechanisms by a slow algorithm like
linear search of the rule-base that implements the first match semantics makes its
more time consuming. Stateless Firewalls are the most basic and they are the most
common type of firewalls. Stateless firewalls basically watch the traffic and compare
the packets with the rules from its rules database. If a malicious activity is found it
drops the packet. They are not aware of the traffic flowing among them. For simple
lightweight host based protections usually stateless firewalls are preferred. There
are many examples for stateless firewalls: IP tables from Linux

Dept. of Comp Engg. 7 SVPM’s COE,Malegaon(Bk)

Chapter 4

TYPES OF FIREWALLS

1. Packet-Filtering Firewalls :- As the most basic and oldest type of firewall ar-
chitecture, packet-filtering firewalls basically create a checkpoint at a traffic router
or switch. The firewall performs a simple check of the data packets coming through
the routerinspecting information such as the destination and origination IP address,
packet type, port number, and other surface-level information without opening up
the packet to inspect its contents. If the information packet doesnt pass the inspec-
tion, it is dropped. The good thing about these firewalls is that they arent very
resource-intensive. This means they dont have a huge impact on system perfor-
mance and are relatively simple. However, theyre also relatively easy to bypass
compared to firewalls with more robust inspection capabilities. 2. Circuit-Level
Gateways :- As another simplistic firewall type that is meant to quickly and easily
approve or deny traffic without consuming significant computing resources, circuit-
level gateways work by verifying the transmission control protocol (TCP) hand-
shake. This TCP handshake check is designed to make sure that the session the
packet is from is legitimate. While extremely resource-efficient, these firewalls do
not check the packet itself. So, if a packet held malware, but had the right TCP hand-
shake, it would pass right through. This is why circuit-level gateways are not enough
to protect your business by themselves. Stateful Inspection Firewalls. These fire-
walls combine both packet inspection technology and TCP handshake verification
to create a level of protection greater than either of the previous two architectures
could provide alone. However, these firewalls do put more of a strain on computing
resources as well. This may slow down the transfer of legitimate packets com-
pared to the other solutions. Proxy Firewalls (Application-Level Gateways) Proxy
firewalls operate at the application layer to filter incoming traffic between your net-
work and the traffic sourcehence, the name application-level gateway. Rather than

8
4.1. SYSTEM ARCHITECTURE CHAPTER 4. TYPES OF FIREWALLS

letting traffic connect directly, the proxy firewall first establishes a connection to the
source of the traffic and inspects the incoming data packet. This check is similar
to the stateful inspection firewall in that it looks at both the packet and at the TCP
handshake protocol. However, proxy firewalls may also perform deep-layer packet
inspections, checking the actual contents of the information packet to verify that
it contains no malware. Once the check is complete, and the packet is approved
to connect to the destination, the proxy sends it off. This creates an extra layer
of separation between the client (the system where the packet originated) and the
individual devices on your networkobscuring them to create additional anonymity
and protection for your network. If theres one drawback to proxy firewalls, its that
they can create significant slowdown because of the extra steps in the data packet
transferal process.
3. Next-Generation Firewalls :- Many of the most recently-released firewall
products are being touted as next-generation architectures. However, there is not as
much consensus on what makes a firewall truly next-gen. Some common features
of next-generation firewall architectures include deep-packet inspection (checking
the actual contents of the data packet), TCP handshake checks, and surface-level
packet inspection. Next-generation firewalls may include other technologies as
well, such as intrusion prevention systems (IPSs) that work to automatically stop
attacks against your network. The issue is that there is no one definition of a next-
generation firewall, so its important to verify what specific capabilities such fire-
walls have before investing in one.

4.1 System Architecture

3 Firewall architectures Firewalls range from simple machines designed to be pur-
chased off-the-shelf and installed by a person unskilled in network security (e.g., as
shown in Figure 1) to complex, multiple-machine custom installations used in large
organizations. Regardless of their complexity, all firewalls have the concept of in-
side for the protected network, and outside for the untrusted network. These terms
are used even when a firewall protects the outside world from potentially compro-
mised machines inside. Another common feature of firewalls is the existence of
a DMZ (named for the demilitarized zone separating North and South Korea) or
screened network. Examples of how a DMZ may be constructed are illustrated in

Dept. of Comp Engg. 9 SVPM’s COE,Malegaon(Bk)

4.1. SYSTEM ARCHITECTURE CHAPTER 4. TYPES OF FIREWALLS

Figures 2 and 3. Machines such as email and web servers are often placed on the
DMZ. These machines are not allowed to make connections to machines on the
inside of the firewall, but machines on the inside are allowed to make connections
to the DMZ machines. Thus if a server on the DMZ is compromised, the attacker
cannot directly attack machines on the inside. Servers are particularly vulnerable
because they must be accessed in order to be useful, and current firewalls are largely
ineffective against attacks through these services (see Section 5.4). can do little
against Examples of attacks on servers include the Code Red and Nimda worms
which attacked Microsoft Windows machines running Microsofts web server IIS,
and in the case of Nimda, several additional routes. Firewall architectures are con-
strained by the type of filtering (described shortly) and the presence or absence of
a DMZ. 3.1 Packet filtering Packet filtering is looking at the headers in network
packets and deciding whether or not to allow the packet based on the policy en-
forced by the firewall. Packet filtering for network security began with Moguls
paper describing screend in 1989 [50]. Most early work on packet filtering for se-
curity emphasized performance (e.g., [4]); later papers continued this trend (e.g.,
[43, 66]). In addition to its efficiency, packet filtering is appealing because it does
not require the cooperation of users, nor does it require any special action on their
part like some proxies require (See Section 3.2). Packet filters use one or more
of the following pieces of information to make their decision on whether or not
to forward the packet: source address; destination address; options in the network
header; transport-level protocol (i.e., TCP, UDP, ICMP, etc.); flags in the transport
header; options in the transport header; source port or equivalent if the protocol
has such a construct; destination port or equivalent if the protocol has such a con-
struct; the interface on which the packet was received or will be sent; and whether
the packet is inbound or outbound. Although packet filtering is fast, it has some
drawbacks, most importantly the difficulty of writing correct filters. For example,
Chapman compares packet filter languages to assembly language [12]. In 1995,
Molitor proposed an improved commercial filter language [51]. A second draw-
back is that packet filtering cannot identify which user is causing which network
traffic. It can inspect the IP address of the host from which the traffic originates, but
a host is not identical to a user. If an organization with a packet-filtering firewall
is trying to limit the services some users can access, it must either implement an
additional, separate protocol for authentication (see Section 3.2 for one example of

Dept. of Comp Engg. 10 SVPM’s COE,Malegaon(Bk)

4.1. SYSTEM ARCHITECTURE CHAPTER 4. TYPES OF FIREWALLS

how this might be done) or use the IP address of the users primary machine as a
weak replacement for true user authentication. Also, because IP addresses can be
spoofed, using them for authentication can lead to other problems. If the router is
running a properly configured filter, remote attackers should not be able to spoof
local addresses, but they could spoof other remote addresses. Local machines can
spoof other local machines easily. In spite of these problems, many organizations
still use IP addresses or DNS names for access control. With packet filters, the local
machine directly initiates the connection to the remote machine. A result is that
the entire internal network is potentially reachable from external connections; oth-
erwise the reply packets from the remote host would not be delivered properly. As
a consequence, hostile remote computers can potentially exploit weaknesses in the
protocol implementation of the local computer (e.g., [61]). Protocols such as FTP
are difficult for packet filters. FTP uses a control channel opened from the client
to the server for commands. However, when getting a file, one method of using
FTP (active FTP) has the server open a connection back to the client, contrary to
the communication patters in other client-server protocols. FTPs lack of encryption
protecting user authentication data has led to reduced usage, and eventually it may
no longer be used. 3.1.1 Packet Filtering with State Originally, packet filters ignored
the state of a connection. This means that a remote host could send in packets which
appeared to be part of an established TCP connection (with the TCP ACK flag set),
but which in reality were not. Attacks against bugs in the TCP/IP protocol stack
(e.g., [61]) can pass through the packet filtering firewalls which do not keep state by
claiming to be part of an established TCP session. Some network mapping software
(e.g., [24]) can map the inside network as if the firewall did not even exist. The
solution to this problem is to record the state of a connection, a property referred to
variously as stateful firewalls, adaptive firewalling and packet inspection. In other
words, the packet filter records both the network level and the transport level data.
For example, a router can monitor the initial TCP packets with the SYN flag set
and allow the return packets only until the FIN packet is sent and acknowledged. A
similar pseudo-state can be kept for most UDP (e.g., DNS, NTP) and some ICMP
communication (e.g., ping)a request sent out opens a hole for the reply, but only for
a short time. In 1992, Chapman was one of the first to point out the problem of the
stateless packet filtering firewalls [12]. The first peer-reviewed paper to describe
adding state to packet filters was by Julkunen and Chow in 1998, which describes

Dept. of Comp Engg. 11 SVPM’s COE,Malegaon(Bk)

4.1. SYSTEM ARCHITECTURE CHAPTER 4. TYPES OF FIREWALLS

a dynamic packet filter for Linux [37]. Today, all major packet filtering firewalls
are capable of using connection state. 3.1.2 Improving Packet Filter Specification
Firewalls were originally built and configured by experts. However, firewalls are
now commodity products which are sold with the intent that nearly anyone can be
responsible for their networks security. Typically a graphical user interface (GUI) is
used to configure packet filtering rules. Unfortunately, this GUI requires the user to
understand the complexities of packet filters, complexities originally pointed out by
Chapman in 1992 [12]. In many cases, the only advance since then is the GUI. The
prevalence of transparent proxies only increases the complexity of the administra-
tors task because he or she must understand the advantages and drawbacks of using
proxies compared to packet filtering. Some researchers have therefore developed
higher-level languages for specifying packet filters. Specific examples include us-
ing binary decision diagrams (BDDs) to specify the policy, a compiler for a higher-
level language that produces packet-filtering rules, a LISP-like language describing
policy, and the Common Open Policy Service (COPS) protocol standard. In 2000,
Hazelhurst proposed BDDs for visualizing router rule sets [31]. Since BDDs repre-
sent boolean expressions, they are ideal for representing the block/pass rules which
occur in packet filters. BDDs also make automated analysis of packet filter rules
easier, as well as providing better performance than the table lookups used in many
routers. The filter language compiler, flc [58], allows the use of the C preproces-
sor, specification of a default block or pass policy for various directions of traffic
flow, and provides a simple if-then-else facility. flc also generates rules for several
different packet filters (IPF, ipfw, ipfwadm, ipfirewall, Cisco extended access lists,
and screend). Guttman described a LISP-like language for expressing access con-
trol policies for networks where more than one firewall router is used to enforce
the policy [28]. The language is then used to compute a set of packet filters which
will properly implement the policy. He also describes an algorithm for comparing
existing filters to the policy to identify any policy breaches. However, the automat-
ically generated filters are not expressed in the language of any router; the network
administrator must build them manually from the LISP-like output. The Internet
standards RFC2748, RFC3060, and RFC3084 describe the Common Open Policy
Service (COPS) protocol. This protocol is used between a policy server (Policy
Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). The
basic idea is that the policy is specified at a different location from the firewall (a

Dept. of Comp Engg. 12 SVPM’s COE,Malegaon(Bk)

4.1. SYSTEM ARCHITECTURE CHAPTER 4. TYPES OF FIREWALLS

PEP), and the policy server ensures that the various policy enforcers have and use
the correct policy. The policy may relate to Quality of Service (QoS), it may re-
late to security, or it may relate to some other part of network policy (e.g., IPsec);
the COPS protocol is extensible. The network is modeled as a finite state machine
and a policy is modeled as a collection of policy rules. These rules have a logical
expression of conditions and a set of actions. If the logical expression is true, then
the actions are executed. These actions may cause a state change in the network fi-
nite state machine. The policy rules can be prioritized, allowing conflict resolution
when two or more rules match but specify conflicting actions. As these proposed
standards are adopted, they will likely have a significant impact on how firewalls
are constructed. Stone et al. survey policy languages through 2000 and describe
a new approach to policy specification [64]. In addition to security concerns, their
approach also takes into account Quality of Service (QoS). In specifying policies,
they note that some policies are static, i.e., for security reasons, all access to certain
network addresses are prohibited. Other policies are dynamic, i.e., if the available
bandwidth is too low, streaming video is no longer allowed. Finally, different users
may receive different levels of service (e.g., customers in the company web store
have priority over employees browsing the web). Their policy language is called
the Path-Based Policy Language (PPL), and it corrects some of the deficiencies in
the other policy languages. Damianou et al. describe a policy language called Pon-
der [19]. Ponder is a declarative, object-oriented language, which uses its structures
to represent policies. Constraints on a policy can also be represented in Ponder. Al-
though Ponder appears to be a rich and expressive language for expressing policies,
there is not yet an automated policy implementation path. Bartal et al. describe
firmato [5]. firmato has an underlying entity-relationship model which specifies
the global security policy, a language in which to represent the model, a compiler
which translates the model into firewall rules, and a tool which displays a graphi-
cal view of the result to help the user visualize the model. A module for use with
firmato is the firewall analysis engine, Fang (Firewall ANalysis enGine) by Mayer
et al. [48]. Fang reads the firewall configurations and discovers what policy is de-
scribed. The network administrator can then verify that the actual policy on various
routers matches the desired policy. For example, the network administrator can ask
questions such as From which machines can our DMZ be reached, and with which
services? Fang builds a representation of the policy; it is not an active testing pro-

Dept. of Comp Engg. 13 SVPM’s COE,Malegaon(Bk)

4.1. SYSTEM ARCHITECTURE CHAPTER 4. TYPES OF FIREWALLS

gram. This difference allows Fang to test both the case in which authorized packets
succeed and the one in which unauthorized packets are blocked. It also allows test-
ing before the firewall is deployed; by contrast, active test tools require the firewall
to be up and

Dept. of Comp Engg. 14 SVPM’s COE,Malegaon(Bk)

Chapter 5

ALGORITHMS

5.1 Firewall Scheduling Algorithm

Input : (1) array color[1..n] where color[i] is the color of task i;

(2) array cost[1..z] where cost[j] is the cost of executing task j;
(3) array group[1..z] where group[h] is the set of all tasks with color h;
Output : (1) an optimal schedule of the n tasks;
(2) the cost of the optimal schedule;
Variables: C, M: array [1..n][1..n] of integer;
/*initial values of C and M are zeros*/
Steps:
1. FSA-Cost(1, n); /*compute optimal cost, store trace info in M*/
2. Print-FSA(1, 1, n); /*print an optimal schedule using array M*/
3. print the optimal cost C[1, n];
End
FSA-Cost(i, j)
if C[i, j]=0 then
1. min cost[color[i]] + FSA-Cost(i + 1, j);
2. M[i, j] i;
3. for every element x in group[color[i]] do
if i + 2 x j then
if FSA-Cost(i + 1, x 1) +
FSA-Cost(x, j) ¡ min then
min FSA-Cost(i + 1, x 1) +
FSA-Cost(x, j);
M[i, j] x;

15
5.2. RULE MATCHING ALGORITHM CHAPTER 5. ALGORITHMS

4. C[i, j] min;

return C[i, j];

Print-FSA(t, i, j)
if i = j then print interval [t, i];
else
if M[i, j] = i then
Print-FSA(i + 1, i + 1, j);
print interval [t, i];

else
Print-FSA(i + 1, i + 1, M[i, j] 1);
Print-FSA(t, M[i, j], j);

5.2 RULE MATCHING ALGORITHM

Most modern firewalls are stateful. This means that after the first packet in a net-
work flow is allowed to cross the firewall, all subsequent packets belonging to that
flow, and especially the return traffic, is also allowed through the firewall. Firewall
statefulness is commonly implemented by two separate search mechanisms: 1. A
slow algorithm that implements the first match semantics and compares a packet to
all the rules, and 2. A fast state lookup mechanism that checks whether a packet
belongs to an existing open flow.
4.1 Existing System The firewall packet matching problem finds the first rule
that matches a given packet on one or more fields from its header. Every rule con-
sists of set of ranges [ li , ri ] for i = 1, . . . , d, where each range corresponds to the
i-th field in a packet header. The field values are in 0 ¡=li ,ri¡= Ui ,where Ui=232 -
1 for IP addresses, Ui = 65535 for lport numbers, and Ui = 255 for ICMP message
type or code. The geometric efficient matching search data structure consists of
three parts[1]. The first part is an array of pointers, one for each protocol number.
The second part is a protocol database header, which contains information about
the order of data structure levels. The order in which the fields of packet header are

Dept. of Comp Engg. 16 SVPM’s COE,Malegaon(Bk)

5.2. RULE MATCHING ALGORITHM CHAPTER 5. ALGORITHMS

checked is encoded as a four tuple of field numbers. The third part represents the
levels of data structure themselves. Every level is a set of nodes where each node
is an array. Each array cell specifies a simple range, and contains a pointer to the
next level node. In the last level the simple range information contains the number
of the winner rule instead of the pointer to the next level. The search algorithm The
packet header contains the protocol number, source and destination address, and
port number fields. First, we check the protocol field and go to the protocol array of
the search data structure, to select the corresponding protocol.

Fig.2. The flow chart of proposed matching algorithm During implementation three
files are maintained namely main file containing firewall rule, a log file which is

Dept. of Comp Engg. 17 SVPM’s COE,Malegaon(Bk)

5.2. RULE MATCHING ALGORITHM CHAPTER 5. ALGORITHMS

subset of main rule set containing recently captured packets and an index file having
hash values. For every captured packet, a key value is calculated based on its header
information and mapping is done on the index file. Initially the index file and log
file is empty so for the first packet in the network flow lookup is performed on
the log file and based on the decision field action is taken. On finding the exact
match its hash value is computed and the corresponding entry is made in the index
file and in the log file. All the succeeding packets belonging to the same flow
performed matching by finding the record in log file instead of main rule set. Thus
by cataloguing the information of the recently received packets we try to reduce the
searching time to scan the main rule set. Here the log file is act as the subset of main
firewall rule set. The number of rules in the log file is less as compared to the rules
in the main file, so it is obvious that time required to scan the log file will be less .

Dept. of Comp Engg. 18 SVPM’s COE,Malegaon(Bk)

Chapter 6

ANALYTIC STUDY

6.1 Results

19
Chapter 7

DENIAL OF FIREWALL ATTACKS

7.1 An Overview of DoS Attacks

A Denial-of-Service (DoS) attack is an attack meant to shut down a machine
or network, making it inaccessible to its intended users. DoS attacks accomplish this
by flooding the target with traffic, or sending it information that triggers a crash. In
both instances, the DoS attack deprives legitimate users (i.e. employees, members,
or account holders) of the service or resource they expected. Victims of DoS attacks
often target web servers of high-profile organizations such as banking, commerce,
and media companies, or government and trade organizations. Though DoS attacks
do not typically result in the theft or loss of significant information or other as-
sets, they can cost the victim a great deal of time and money to handle. There are
two general methods of DoS attacks: flooding services or crashing services. Flood
attacks occur when the system receives too much traffic for the server to buffer,
causing them to slow down and eventually stop. Popular flood attacks include:
1. Buffer overflow attacks :- the most common DoS attack. The concept is to
send more traffic to a network address than the programmers have built the system
to handle. It includes the attacks listed below, in addition to others that are designed
to exploit bugs specific to certain applications or networks.
2. ICMP flood :- leverages misconfigured network devices by sending spoofed
packets that ping every computer on the targeted network, instead of just one spe-
cific machine. The network is then triggered to amplify the traffic. This attack is
also known as the smurf attack or ping of death.
3. SYN flood :-sends a request to connect to a server, but never completes
the handshake. Continues until all open ports are saturated with requests and none
are available for legitimate users to connect to. Other DoS attacks simply exploit

20
7.1. AN OVERVIEW OF DC
OHSAAPTTTEARCK
7.S DENIAL OF FIREWALL ATTACKS

vulnerabilities that cause the target system or service to crash. In these attacks, input
is sent that takes advantage of bugs in the target that subsequently crash or severely
destabilize the system, so that it cant be accessed or used.

An additional type of DoS attack is the Distributed Denial of Service (DDoS)

attack. A DDoS attack occurs when multiple systems orchestrate a synchronized
DoS attack to a single target. The essential difference is that instead of being at-
tacked from one location, the target is attacked from many locations at once.

The distribution of hosts that defines a DDoS provide the attacker multiple
advantages:
a. He can leverage the greater volume of machine to execute a seriously disrup-
tive attack.
b. The location of the attack is difficult to detect due to the random distribution
of attacking systems (often worldwide).
c. It is more difficult to shut down multiple machines than one.
d. The true attacking party is very difficult to identify, as they are disguised
behind many (mostly compromised) systems Modern security technologies have
developed mechanisms to defend against most forms of DoS attacks, but due to the
unique characteristics of DDoS, it is still regarded as an elevated threat and is of
higher concern to organizations that fear being targeted by such an attack.

Dept. of Comp Engg. 21 SVPM’s COE,Malegaon(Bk)

Chapter 8
CONCLUSIONS

22
Bibliography

[1] K. Pearson, The problem of the random walk, Nature, vol. 72, pp. 294294, 1905.

[2] Hao Ma, Jianke Zhu, Member, IEEE, Michael Rung-Tsong Lyu, Fellow, IEEE,
and Irwin King, Senior Member, IEEE Bridging the Semantic Gap Between
Image Contents and Tags, IEEE TRANSACTIONS ON MULTIMEDIA, VOL.
12, NO. 5, AUGUST 2010.

[3] Y. Rui, T. S. Huang, M. Ortega, and S. Mehrotra, Relevance feedback:A power

tool in interactive content-based image retrieval,, IEEE Trans. Circuits Syst.
Video Technol., vol. 8, no. 5, pp. 644655, Sep. 1998.

[4] C. Djeraba, Association and content-based retrieval,, IEEE Trans. Knowl. Data
Eng., vol. 15, no. 1, pp. 118135, Jan.Feb. 2003.

[5] R. Datta, D. Joshi, J. Li, and J. Z. Wang, Image retrieval: Ideas, influences, and
trends of the new age, ACM Comput. Surv., vol. 40, no. 2, pp. 160, 2008.

23