Testing a Firewall Configuration

After you've designed an appropriate firewall configuration, it's important to validate that it does in fact do what you want it to do. One way to do this is to use a test host outside your network to attempt to pierce your firewall: this can be quite clumsy and slow, though, and is limited to testing only those addresses that you can actually use.

A faster and easier method is available with the Linux firewall implementation. It allows you to manually generate tests and run them through the firewall configuration just as if you were testing with actual datagrams. All varieties of the Linux kernel firewall software, ipfwadm, ipchains, and iptables, provide support for this style of testing. The implementation involves use of the relevant check command.

The general test procedure is as follows:

1.

Design and configure your firewall using ipfwadm, ipchains, or iptables.
2.

Design a series of tests that will determine whether your firewall is actually working as you intend. For these tests you may use any source or destination address, so choose some address combinations that should be accepted and some others that should be dropped. If you're allowing or disallowing only certain ranges of addresses, it is a good idea to test addresses on either side of the boundary of the range—one address just inside the boundary and one address just outside the boundary. This will help ensure that you have the correct boundaries configured, because it is sometimes easy to specify netmasks incorrectly in your configuration. If you're filtering by protocol and port number, your tests should also check all important combinations of these parameters. For example, if you intend to accept only TCP under certain circumstances, check that UDP datagrams are dropped.
3.

Develop ipfwadm, ipchains, or iptables rules to implement each test. It is probably worthwhile to write all the rules into a script so you can test and re-test easily as you correct mistakes or change your design. Tests use almost the same syntax as rule specifications, but the arguments take on slightly differing meanings. For example, the source address argument in a rule specification specifies the source address that datagrams matching this rule should have. The source address argument in test syntax, in contrast, specifies the source address of the test datagram that will be generated. For ipfwadm, you must use the –c option to specify that this command is a test, while for ipchains and iptables, you must use the –C option. In all cases you must always specify the source address, destination address, protocol, and interface to be used for the test. Other arguments, such as port numbers or TOS bit settings, are optional.
4.

Execute each test command and note the output. The output of each test will be a single word indicating the final target of the datagram after running it through the firewall configuration—that is, where the processing ended. For ipchains and iptables, user-specified chains will be tested in addition to the built-in ones.
5.

Compare the output of each test against the desired result. If there are any discrepancies, you will need to analyse your ruleset to determine where you've made the error. If you've written your test commands into a script file, you can easily rerun the test after correcting any errors in your firewall configuration. It's a good practice to flush your rulesets completely and rebuild them from scratch, rather than to make changes dynamically. This helps ensure that the active configuration you are testing actually reflects the set of commands in your configuration script.

Let's take a quick look at what a manual test transcript would look like for our naïve example with ipchains. You will remember that our local network in the example was 172.16.1.0 with a netmask of 255.255.255.0, and we were

Answered by Sharad Singh , an ibibo Master, at 6:13 PM on September 12, 2008

The general test procedure is as follows:
1. Design and configure your firewall using ipfwadm, ipchains, or iptables.

2. Design a series of tests that will determine whether your firewall is actually
working as you intend. For these tests you may use any source or destination
address, so choose some address combinations that should be accepted and some
others that should be dropped. If you're allowing or disallowing only certain
ranges of addresses, it is a good idea to test addresses on either side of the
boundary of the range—one address just inside the boundary and one address just
outside the boundary. This will help ensure that you have the correct boundaries
configured, because it is sometimes easy to specify netmasks incorrectly in your
configuration. If you're filtering by protocol and port number, your tests should
also check all important combinations of these parameters. For example, if you
intend to accept only TCP under certain circumstances, check that UDP
datagrams are dropped.

3. Develop ipfwadm, ipchains, or iptables rules to implement each test. It is
probably worthwhile to write all the rules into a script so you can test and re-test
easily as you correct mistakes or change your design. Tests use almost the same
syntax as rule specifications, but the arguments take on slightly differing
meanings. For example, the source address argument in a rule specification
specifies the source address that datagrams matching this rule should have. The
source address argument in test syntax, in contrast, specifies the source address of
the test datagram that will be generated. For ipfwadm, you must use the –c option
to specify that this command is a test, while for ipchains and iptables, you must
use the –C option. In all cases you must always specify the source address,
destination address, protocol, and interface to be used for the test. Other
arguments, such as port numbers or TOS bit settings, are optional.

4. Execute each test command and note the output. The output of each test will be a
single word indicating the final target of the datagram after running it through the
firewall configuration—that is, where the processing ended. For ipchains and
iptables, user-specified chains will be tested in addition to the built-in ones.

5. Compare the output of each test against the desired result. If there are any
discrepancies, you will need to analyse your ruleset to determine where you've
made the error. If you've written your test commands into a script file, you can
easily rerun the test after correcting any errors in your firewall configuration. It's a
good practice to flush your rulesets completely and rebuild them from scratch,
rather than to make changes dynamically. This helps ensure that the active
configuration you are testing actually reflects the set of commands in your
configuration script.

Answered by Shobhit , an ibibo Master, at 3:43 PM on September 01, 2008

The general test procedure is as follows:

1. Design and configure your firewall using ipfwadm, ipchains, or iptables.

2. Design a series of tests that will determine whether your firewall is actually working as you intend.

3. Develop ipfwadm, ipchains, or iptables rules to implement each test. It is probably worthwhile to write all the rules into a script so you can test and re-test easily as you correct mistakes or change your design.

4. Execute each test command and note the output. The output of each test will be a single word indicating the final target of the datagram after running it through the firewall configuration—that is, where the processing ended. For ipchains and iptables, user-specified chains will be tested in addition to the built-in ones.

5.Compare the output of each test against the desired result. If there are any discrepancies, you will need to analyse your ruleset to determine where you've made the error. If you've written your test commands into a script file, you can easily rerun the test after correcting any errors in your firewall configuration.

For more visit :

http://tldp.org/LDP/nag2/ x-087-2-firewall.checkingconf. html

Answered by Poonam Singh , an ibibo Master, at 7:39 AM on September 01, 2008

The general test procedure is as follows:
1. Design and configure your firewall using ipfwadm, ipchains, or iptables.

2. Design a series of tests that will determine whether your firewall is actually
working as you intend. For these tests you may use any source or destination
address, so choose some address combinations that should be accepted and some
others that should be dropped. If you're allowing or disallowing only certain
ranges of addresses, it is a good idea to test addresses on either side of the
boundary of the range—one address just inside the boundary and one address just
outside the boundary. This will help ensure that you have the correct boundaries
configured, because it is sometimes easy to specify netmasks incorrectly in your
configuration. If you're filtering by protocol and port number, your tests should
also check all important combinations of these parameters. For example, if you
intend to accept only TCP under certain circumstances, check that UDP
datagrams are dropped.

3. Develop ipfwadm, ipchains, or iptables rules to implement each test. It is
probably worthwhile to write all the rules into a script so you can test and re-test
easily as you correct mistakes or change your design. Tests use almost the same
syntax as rule specifications, but the arguments take on slightly differing
meanings. For example, the source address argument in a rule specification
specifies the source address that datagrams matching this rule should have. The
source address argument in test syntax, in contrast, specifies the source address of
the test datagram that will be generated. For ipfwadm, you must use the –c option
to specify that this command is a test, while for ipchains and iptables, you must
use the –C option. In all cases you must always specify the source address,
destination address, protocol, and interface to be used for the test. Other
arguments, such as port numbers or TOS bit settings, are optional.

4. Execute each test command and note the output. The output of each test will be a
single word indicating the final target of the datagram after running it through the
firewall configuration—that is, where the processing ended. For ipchains and
iptables, user-specified chains will be tested in addition to the built-in ones.

5. Compare the output of each test against the desired result. If there are any
discrepancies, you will need to analyse your ruleset to determine where you've
made the error. If you've written your test commands into a script file, you can
easily rerun the test after correcting any errors in your firewall configuration. It's a
good practice to flush your rulesets completely and rebuild them from scratch,
rather than to make changes dynamically. This helps ensure that the active
configuration you are testing actually reflects the set of commands in your
configuration script.

Answered by Anju Devi , an ibibo Master, at 7:45 PM on August 26, 2008

The test firewall configuration online as-
On the Internet, your computer may have 65,535 "ports" open. If the ports are open, an Internet outlaw's scanner may try to install a bot to make your computer into a zombie (part of a botnet). There are many online test sites. You need to be a bit skeptical about which of them to rely on. As a rule of thumb, do not rely solely on a testing site provided by a company that wants to sell you a personal firewall. Once you install a personal firewall, testing is needed to make sure that it is serving its intended purpose (closed ports plus...) and that you have configured it correctly.

Another kind of testing is

To find out from direct experience why you need a personal firewall, we suggest that you try one. After a few days, use the report function to see how many times your computer has been scanned. Please note that many scans are not dangerous, for example, your cable/dsl Internet service provider may be checking to see that your connection is ok. For firewalls that are free for personal use, see our Security Freeware page. Many vendors offer a free trial of their products, see our Personal Firewall Software Review page for choices and links. Whichever choice you make, check the vendor's website after you install your firewall for updates. The last step is to test the firewall to see how well it works and to make sure that you installed and configured it correctly.

For more information-
http://www.firew allguide.com/test.htm

Answered by Nagendra , an ibibo Master, at 9:07 AM on August 19, 2008

The general test procedure is as follows:

1. Design and configure your firewall using ipfwadm, ipchains, or iptables.

2. Design a series of tests that will determine whether your firewall is actually working as you intend.

3. Develop ipfwadm, ipchains, or iptables rules to implement each test. It is probably worthwhile to write all the rules into a script so you can test and re-test easily as you correct mistakes or change your design.

4. Execute each test command and note the output. The output of each test will be a single word indicating the final target of the datagram after running it through the firewall configuration—that is, where the processing ended. For ipchains and iptables, user-specified chains will be tested in addition to the built-in ones.

5.Compare the output of each test against the desired result. If there are any discrepancies, you will need to analyse your ruleset to determine where you've made the error. If you've written your test commands into a script file, you can easily rerun the test after correcting any errors in your firewall configuration.

For more visit :

http://tldp.org/LDP/nag2/ x-087-2-firewall.checkingconf. html

Answered by Ashish Yadav , an ibibo Wizard, at 7:14 PM on August 18, 2008

well, # Test to make sure configuration variables are set, die if not.

if [ ! -x "$PROG" ] || [ -z "$IFACE" ];
then
echo "$PROG is not executable, or interface is not set, exiting."
exit 0
else

# Get current IP address

IP=`ifconfig $IFACE| grep inet| cut -f2 -d:| cut -f1 -d" "`

# Get old IP from last firewall load (if any).
# The purpose of getting OLDIP is so you can use this script in a cron
# job to update the firewall with the current IP, great for dialups
# and other dynamic connections.
# Examples:
# Check every 15 minutes:
# */15 * * * * /path/to/this/script restart > /dev/null 2>&1
# Check every 5 minutes:
# */5 * * * * /path/to/this/script restart > /dev/null 2>&1

OLDIP=`$PROG -n -L INPUT| grep 6005|grep udp| cut -b55-|cut -f1 -d u`

case $1 in

start)
if [ -z "$OLDIP" ];
then
echo -n "Starting firewall..."
fireme
elif [ $IP = $OLDIP ];
then
echo "FIREWALL IS UPDATED."
fi
;;
restart)
echo -n "Restarting firewall..."
if [ -z "`$PROG -n -L INPUT| grep 6005`" ];
then
fireme
elif [ $IP = $OLDIP ];
then
echo "FIREWALL IS UPDATED."
else

$PROG -F INPUT
$PROG -F FORWARD

for i in DENIED_PORT_PRIV DENIED_PORT_UNPRIV_TCP DENIED_PORT_UNPRIV_UDP ONTHEFLY
do
$PROG -F $i
$PROG -X $i
done
fireme
fi
;;
refresh)
echo -n "Resetting firewall..."
if [ -z "`$PROG -n -L INPUT| grep 6005`" ];
then
fireme
else

$PROG -F INPUT
$PROG -F FORWARD

for i in DENIED_PORT_PRIV DENIED_PORT_UNPRIV_TCP DENIED_PORT_UNPRIV_UDP ONTHEFLY
do
$PROG -F $i
$PROG -X $i
done
fireme
fi
;;
stop)

$PROG -F INPUT
$PROG -F FORWARD

for i in DENIED_PORT_PRIV DENIED_PORT_UNPRIV_TCP DENIED_PORT_UNPRIV_UDP ONTHEFLY
do
$PROG -F $i
$PROG -X $i
done
echo "Firewall stopped...[OK]"
; ;
*)
echo
scripthelp
;;
esac
fi

Do wnload this script: http://linux.ardynet.com/ipmas q/ipmasq.php3

Answered by Romi , an ibibo Master, at 2:16 PM on August 18, 2008

The primary method for keeping a computer secure from intruders. A firewall allows or blocks traffic into and out of a private network or the user's computer. Firewalls are widely used to give users secure access to the Internet as well as to separate a company's public Web server from its internal network. Firewalls are also used to keep internal network segments secure; for example, the accounting network might be vulnerable to snooping from within the enterprise.

In the home, a personal firewall typically comes with or is installed in the user's computer (see Windows Firewall). Personal firewalls may also detect outbound traffic to guard against spyware, which could be sending your surfing habits to a Web site. They alert you when software makes an outbound request for the first time (see spyware).

In the organization, a firewall can be a stand-alone machine (see firewall appliance) or software in a router or server. It can be as simple as a single router that filters out unwanted packets, or it may comprise a combination of routers and servers each performing some type of firewall processing.

Firewall Techniques

Following are the different methods used to provide firewall protection, and several of them are often used in combination.

Stateful Inspection

Tracks the transaction to ensure that inbound packets were requested by the user. Generally can examine multiple layers of the protocol stack, including the data, if required, so blocking can be made at any layer or depth. See stateful inspection.

Network Address Translation (NAT)

Allows one IP address, which is shown to the outside world, to refer to many IP addresses internally; one on each client station. Performs the translation back and forth. NAT is found in routers and is built into Windows Internet Connection Sharing (ICS). See NAT and ICS.

Packet Filter

Blocks traffic based on a specific Web address (IP address) or type of application (e-mail, ftp, Web, etc.), which is specified by port number. Packet filtering is typically done in a router, which is known as a "screening router." See bastion host.

Proxy Server

Serves as a relay between two networks, breaking the connection between the two. Also typically caches Web pages

Answered by Nishu's , an ibibo Master, at 11:49 AM on August 18, 2008

Well Samhita, steps to test a firewall configuration are

1. Install SP2 onto your Windows Operating System
2. Enable Auto Updates for the Firewall.
3. Tweaking the Settings to your Usage
4. Keeping Settings Consistent Across Networks
5. Add Multiple Layers to your PC and Security System.
6. Use Strong Passwords
7. A 128-bit WEP Encryption on your Wireless Network
8. Standby is your PC's Best Friend
9. Test #1: Looking for Leaks
10. Test #2: Checking the Ports

For complete details , Please visit the source site :

http://www.itsecurity.com/feat ures/more-secure-firewall-012207/

Answered by Alok Gupta , an ibibo Guru, at 11:23 AM on August 18, 2008

The general test procedure is as follows:
1. Design and configure your firewall using ipfwadm, ipchains, or iptables.

2. Design a series of tests that will determine whether your firewall is actually
working as you intend. For these tests you may use any source or destination
address, so choose some address combinations that should be accepted and some
others that should be dropped. If you're allowing or disallowing only certain
ranges of addresses, it is a good idea to test addresses on either side of the
boundary of the range—one address just inside the boundary and one address just
outside the boundary. This will help ensure that you have the correct boundaries
configured, because it is sometimes easy to specify netmasks incorrectly in your
configuration. If you're filtering by protocol and port number, your tests should
also check all important combinations of these parameters. For example, if you
intend to accept only TCP under certain circumstances, check that UDP
datagrams are dropped.

3. Develop ipfwadm, ipchains, or iptables rules to implement each test. It is
probably worthwhile to write all the rules into a script so you can test and re-test
easily as you correct mistakes or change your design. Tests use almost the same
syntax as rule specifications, but the arguments take on slightly differing
meanings. For example, the source address argument in a rule specification
specifies the source address that datagrams matching this rule should have. The
source address argument in test syntax, in contrast, specifies the source address of
the test datagram that will be generated. For ipfwadm, you must use the –c option
to specify that this command is a test, while for ipchains and iptables, you must
use the –C option. In all cases you must always specify the source address,
destination address, protocol, and interface to be used for the test. Other
arguments, such as port numbers or TOS bit settings, are optional.

4. Execute each test command and note the output. The output of each test will be a
single word indicating the final target of the datagram after running it through the
firewall configuration—that is, where the processing ended. For ipchains and
iptables, user-specified chains will be tested in addition to the built-in ones.

5. Compare the output of each test against the desired result. If there are any
discrepancies, you will need to analyse your ruleset to determine where you've
made the error. If you've written your test commands into a script file, you can
easily rerun the test after correcting any errors in your firewall configuration. It's a
good practice to flush your rulesets completely and rebuild them from scratch,
rather than to make changes dynamically. This helps ensure that the active
configuration you are testing actually reflects the set of commands in your
configuration script.

Answered by Sumit Goel , an ibibo Citizen, at 11:10 AM on August 18, 2008