International Journal of Computer Trends and Technology (IJCTT) – volume4Issue8–August 2013

ISSN: 2231-2803 Page 2796
Radical Testing of Firewall Schemes
Vagolu Vanaja
, Sandhya
, BetamSuresh
V. Vanaja pursuingM.Tech (CSE) from Vikas Group of Institutions (Formerly known as Mother Teresa
Educational Society Group of Institutions), Affiliated to JNTU-Kakinada, Nunna, Vijayawada, AndraPradesh,
Mrs Sandhya ,working as an Asst. Professor (CSE) at Vikas Group of Institutions (Formerly known as Mother
Teresa Educational Society Group of Institutions), Affiliated to JNTU-Kakinada, Nunna, Vijayawada., A.P., India.
Betam Suresh ,working as an HOD at Vikas Group of Institutions (Formerly known as Mother Teresa
Educational Society Group of Institutions), Nunna, Vijayawada, Affiliated to JNTU-Kakinada, A.P., India.

Abstract: Firewall is an application software that plays a major
role in securing the private networks, so that is the reason why
this firewalls are becoming as a popular applications in
enterprise security as the quality of protection provided by a
firewall directly depends on the quality of its policy (i.e.,
configuration), ensuring the correctness of firewall policies is
important and yet difficult. To help ensure the correctness, we
propose a radical testing approach for firewall policies. Here in
this paper we are proposing a test that can successfully test the
firewall policy which will check for two things one is
Authentication and one more is malware if the node is not in the
list of authenticated and also if it found any packet having
malware automatically it blocks that particular IP from the next
time onwards.
We have conducted a test on a set of firewall policies
and a set of faulty policies to detect malicious packets with
default packets. Generally, our experimental results state that a
higher structural coverage packet has the higher fault detection
capability. Coming to the reduced Structural coverage maintains
the same fault detection level with the original set.

Index Terms—Firewall policy, validation, test packet generation,
structural coverage, fault detection.


Firewall serves as the initial point to identify the
malicious attacks such as DOS, Integrity attacks,
Unauthorized packets etc. Firewalls identify these kind of
items as a malware get themblocked without entering the
private networks of business area, private institutions. It can
be said as an intermediate point between the World-Wide-
Web and the Internal network by which the traffic must flow
across it. The main responsibilities of firewalls are filtering,
monitoring, and verifying packet headers for authorized
information. If the firewalls are misconfigured and if they are
blocked manually they cannot filter the incoming packets
which may leads to allowing the malicious packets into the

As the firewall must be configured properly in order to
maintain the network in a secured and safe manner.
Misconfiguration in the firewall’s are caused mainly due to
ignorance of firewall policies and by disabling the services
which are a supporting processes for the firewall. Building a
reliable firewall is a challenging task because there are many
factors to be considered such as strict firewall policies. The
policies in the firewalls must be logically independent to
ensure that they will not collide with each other which may
result to failing of that policy. The rule set of firewall must
consist a large number of firewall policies. Most of the
internet firewall policies contains huge number of policies
even like thousands of policies. These policies should be
updated regularly to meet the needs of daily added attacks.

As the firewall policies are created they must tested
for identifying configuration mistakes. As researchers and
practitioners had developed various firewalls testing tools
which test the firewall policies and its configuration
properties. Even though the firewall testing tools cannot
identify anomalies and the anomalies may not be the mistakes
and which could be too large to be useful. This can be tested
by giving the data packets as input to the firewall which is
under firewall testing policy.

Policy testing persons generate a test suite to achieve
high structural coverage which will be helpful in investigating
a huge policy set. Based upon this requirement an automated
packet generation technique has been introduced which has
the techniques of randompacket generation which considers
the individual rules in a policy and a sophisticated one based
on global constraint solving which considers multiple rules
globally. As the generated packets are large and manual
inspection is tedious an automated packet reduction tools are
used to reduce the number of packets without effecting the
structural coverage.
An experiment on the set of real firewall policies by
mutation testing which mainly resides on fault injection. It has
been tested with six packet sets in which the first three are
generated by the above stated techniques and the second set of
three are generated by the packet reduction tools respectively.
The results show that the packet set with higher structural
coverage often achieves high fault detection capability and
coming to the reduced packet sets achieves similar to that of
the original packet set.

International Journal of Computer Trends and Technology (IJCTT) – volume4Issue8–August 2013
ISSN: 2231-2803 Page 2797
The rest of the paper is organized as follows. Section
II presents background information on firewall policies,
Section III presents a Firewall Policies Testing, Section IV
describes structural coverage criteria of a firewall policy and
our proposed approach, and Section V concludes the paper.

A firewall is an appliance (a combination of hardware and
software) or an application (software) designed to control the
flow of Internet Protocol (IP) traffic to or froma network or
electronic equipment. Firewalls are used to examine network
traffic and enforce policies based on instructions contained
within the Firewall's Ruleset. Firewalls represent one
component of a strategy to combat malicious activities and
assaults on computing resources and network-accessible
information. Other components include, but are not limited to,
antivirus software, intrusion detection software, patch
management, strong passwords/passphrases, and spyware
detection utilities.
Firewalls are typically categorized as either “Network” or
“Host”: a Network Firewall is most often an appliance
attached to a network for the purpose of controlling access to
single or multiple hosts, or subnets; a Host Firewall is most
often an application that addresses an individual host (e.g.,
personal computer) separately. Both types of firewalls
(Network and Host) can be and often are used jointly.
This policy statement is designed to:
 Provide guidance on when firewalls are required or
recommended. A Network Firewall is required in all
instances where Sensitive Data is stored or
processed; a Host Firewall is required in all instances
where Sensitive Data is stored or processed and the
operating environment supports the implementation.
Both the Network and Host Firewalls afford
protection to the same operating environment, and
the redundancy of controls (two separate and distinct
firewalls) provides additional security in the event of
a compromise or failure.
 Raise awareness on the importance of a properly
configured (installed and maintained) firewall.
In the rest of the paper we use short hand notations
described below
P: indicates a set of the rules in a policy, C: a rule in a
firewall policy I, r
clause in a predicate, p
i :
a field(may be IP
address), F
i :
fomain of field(e.g.[0,232-10] for a IP address,
a subset of domain. S
a constraint of a predicate pi.


This section presents our framework for testing firewall
policies. Figure 3 shows the overview of framework of our
approach. Our framework includes three phases: test packet
generation, test reduction, and fault detection. In the test
packet generation phase, our test packet generation component
analyzes a firewall policy and generates test packets to cover
entities (e.g., predicates and clauses) in the policy. We
propose four different test packet generation techniques
described in Section V-A. In the test reduction phase, the test
reduction component reduces the number of packets based on
coverage criteria by including only packets that help increase
policy coverage measurement during evaluation. In the fault
detection phase, the policy authors manually inspect whether
the actual decisions (i.e., evaluated decisions of the generated
packet against the firewall policy) are consistent with
expected decisions. If the authors find any inconsistent
decisions, the authors determine that they detect a fault in the

A. Test Packet Generation
As manually generating packets for testing policies is tedious,
we have developed four techniques to automatically generate
packets for the policy under test. The objective is to generate
packets for achieving high structural coverage. This section
describes four packet generation techniques (developed in our
approach): the random packet generation technique, the packet
generation technique based on local constraint solving, the
packet generation technique based on global constraint
solving, and the packet generation technique based on
boundary values. The key difference between the second and
third techniques is the scope (i.e, local or global) of
constraints used in the packet generation. While the second
and third techniques generate packets based on randomvalues
within values solved by each constraint solving, the fourth one
generates test packets based on boundary values within values
solved by local constraint solving. In this section, p and C(p)
denote a predicate and its
constraint, respectively. To evaluate p to be true (false),a
packet should satisfy the constraint C(p) (¬C(p)) (for the true
(false) branch of p). C(p) is represented in the formof Cp(c1)
∧.... ∧Cp(cn), where Cp(c1), ..., Cp(cn) are the constraints of
the clause c1, ..., cnin p, respectively.
1) Random Packet Generation Technique:
The randompacket generation technique is straightforward. A
packet k isin the formof (k1, ...,kn), where k1, ..., kn are
numeric value sover fields (such as source addresses), whose
domains are denoted by D1, ..., Dn). Given the domains of the
policy under test, the generator for the technique
automatically generates a packet k by randomly selecting k1,
...,kn(within the domain D1, ..., Dn, respectively). While the
technique does not require the policy itself in test generation
and can quickly generate a large number of test packets, the
technique often
lacks effectiveness to achieve high structural coverage with
the generated packets. Due to randomness, the number of the
entities (i.e., predicates or clauses) being covered is often
small in comparison to the total number of the entities in the
policy under test.
2) Packet Generation Technique based on Local Constraint
Solving: In general, packet generation should focus on
generating packets to cover those entities (i.e., predicates and
clauses) that have not been covered previously. Different from
the preceding technique, the technique based on local
constraint solving statically analyzes the entities in an
International Journal of Computer Trends and Technology (IJCTT) – volume4Issue8–August 2013
ISSN: 2231-2803 Page 2798
individual rule and generates packets to evaluate the
constraints (i.e., conditions) of the entities to be true or false.
The technique takes into account local constraints (given by a
rule) without considering the impact of other rules in the
policy. More specifically, the generator constructs constraints
C(p)and ¬C(p) (for both true and false branches of p) for
each rule. The generator generates a packet based on the
concrete values to satisfy each constraint. As the generator
generates packets based on satisfying constraints in predicates,
SCHEMES 5generated packets may not be effective in
covering each clause(to be true and false).
There are two major limitations of the technique. First, the
generated packets may fail to cover target entities due to
overlapping predicates (i.e., predicates that can be satisfied by
the same packet) across multiple rules. As shown in Figure1, a
packet k (whose destination IP address is
protocol type is UDP) satisfies the predicates of bothr1 and r3
but fails to be evaluated against r3, which can
bek’s potential target entities. Second, the technique cannot
determine whether a structural entity could be covered in
advance. Some rules may be completely shadowed by other
rules and never evaluated. In such cases, there is no criterion
to decide whether to generate additional packets (based on
other more capable solutions to solve the same constraints) or
stop testing.
3) Packet Generation Technique based on Global Constraint
To better generate packets to cover target entities, our
generator (based on global constraint solving) analyzes the
policy under test and generates packets by solving global
constraints (collected from the policy). The motivation of
global constraint solving is to take into account the influence
of overlapping predicates across rules. Covering entities in a
rule requires that the predicates of all the preceding rules
should be evaluated to false. To find such entities, we define
rule reach ability as follows.

Algorithm 1: Packet Generation Technique based
onBoundary Values


Policy testers may generate and select a test suite to
achieve a certain (high) level of coverage. However, our main
objective, through testing, is to detect faults in the firewall
policy while reaching a certain level of coverage. Coverage
analysis helps investigate a larger portion of entities for fault
detection using a test suite that achieves higher structural
coverage. Consider that a fault in entities (i.e., rules, predicate,
or clause) may cause to output incorrect decisions when
evaluating some packets. A fault in a rule’s decision (e.g.,
using accept by mistake instead of discard) is discovered if
and only if the rule is covered and the derived decision is
verified. A test suite with high rule coverage may detect such
faults easily and increase our confidence on the correctness of
the policy against such faults. Similarly, a test suite with high
predicate/clause coverage may have a high chance to detect
faults in predicates/clauses. Therefore, we are interested in
covering each entity at least once to exercise a wide range of
the policy’s behavior.
Here in this section what we are saying is that a test
that covers more about structurally in a firewall policy then
that firewall test strategy was succeeded in testing a firewall
policy and here structural coverage is nothing but a policy is
having a no of rules and predicates so the test should test all
predicates and their outcomes, suppose take an example that a
firewall having three rules and here our test packet is having a
malware and we are sending that packet fromunauthorized
host that is not in the list of the firewall so if that firewall
having 3 rules
R1-this can check if the ip is authorized or not
R2-this can check if that received packet is having malware or
R3-this will block the ip address which the malware contained
packet belonging.
If our test covers all the three rules then we said that our test
covers complete structural part of the firewall policy.
Here finally what we are going to say is that if a firewall
testing strategy that can cover all predicates and rules of a
policy then we said that that firewall will do good and the
firewall policy is tested successfully and the test also accurate
in checking firewall policies’ performance that is it.


We have developed a radical testing approach for firewall
policies. We defined three types of structural coverage for
firewall policies: rule, predicate, and clause coverage criteria.
Among the four proposed packet generation techniques, the
global constraint solving technique often generated packet sets
International Journal of Computer Trends and Technology (IJCTT) – volume4Issue8–August 2013
ISSN: 2231-2803 Page 2799
to achieve the highest structural coverage. Generally, our
experimental results showed that a packet set with higher
structural coverage has higher fault-detection capability (i.e.,
detecting more injected faults). Our experimental results
showed that a reduced packet set (maintaining the same level
of structural coverage with the corresponding original packet
set) maintains similar fault-detection capability with the
original set.
Here finally we are concluding that a policy covered with
a test strategy by testing all its rules, predicates, clauses and
all means we said that test covers more structural part of
policy then the policy covered more is well in fault detection
so finally we will choose that policy to protect our private
networks and here policy is nothing but configuration of a
firewall application software


S. W. Lodin and C. L. Schuba, “Firewalls fend off
invasions from the net,” IEEE Spectrum, vol. 35, no. 2,
pp. 26–34, 1998.

A. Wool, “A quantitative study of firewall configuration
errors,” Computer, vol. 37, no. 6, pp. 62–67, 2004.

E. Al-Shaer and H. Hamed, “Discovery of policy
anomalies in distributed firewalls,” in Proc. 2004 IEEE
Conf. on Communications, pp. 2605–2616.

L. Yuan, J. Mai, Z. Su, H. Chen, C.-N. Chuah, and P.
Mohapatra, “FIREMAN: a toolkit for FIREwall Modeling
and ANalysis,” in Proc. 2006 IEEE Symposium on
Security and Privacy, pp. 199–213.

M. R. Lyu and L. K. Y. Lau, “Firewall security: policies,
testing and performance evaluation,” in Proc. 2000
International Conference on Computer Systems and
Applications, pp. 116–121. HWANG et al.: RADICAL
A. X. Liu, M. G. Gouda, H. H. Ma, and A. H. Ngu, “Non-
intrusive testing of firewalls,” in Proc. 2004 International
Computer Engineering Conference, pp. 196–201.

D. Hoffman and K. Yoo, “Blowtorch: a framework for
firewall test automation,” in Proc. 2005 IEEE/ACM
international Conference on Automated Software
Engineering, pp. 96–103.

H. Zhu, P. A. V. Hall, and J. H. R. May, “Software unit
test coverage and adequacy,” ACM Comput. Surv., vol.
29, no. 4, pp. 366–427, 1997.

R. A. DeMillo, R. J. Lipton, and F. G. Sayward, “Hints
on test data selection: help for the practicing
programmer,” IEEE Computer, vol. 11, no. 4, pp. 34–41,


Vagolu Vanaja, Pursuing
M.Tech(CSE) Vikas Group
of Institutions (Formerly
Mother Teresa Educational
society Group of Institutions),
Nunna, Vijayawada,
Affiliated to JNTU-Kakinada,
A.P., India

Sandhya, is working as an
Asst. Professor, Department
of Computer science
Engineering at Vikas Group
of Institutions (Formerly
Mother Teresa Educational
society Group of
Institutions), Nunna,
Vijayawada, Affiliated to
JNTU-Kakinada, A.P., India
Betam Suresh, is working
as an HOD, Department of
Computer science
Engineering at Vikas Group
of Institutions (Formerly
Mother Teresa Educational
society Group of
Institutions), Nunna,
Vijayawada, Affiliated to
JNTU-Kakinada, A.P., India