linux mint IT admin tips info

Investigation and Testing of Shorewall Firewall Application on a Linux Platform

This is an old college Project document that I thought I would show as it covers some important and interesting Networking aspects for security minded technicians (and it was a lot of work to waste!) – from Firewall packet treatment, port-knocking, Squid, Dan's Guardian, nmap, TCP/UDP, content filtering, IDENT port 113, and more - if you want a deeper understanding of the overall workings of why firewalling with NAT translation works to produce a "stealthed" connection.


Investigation and Testing of Shorewall Firewall Application on a Linux Platform    2010


This Project was inspired by a personal interest in, and insufficient knowledge and understanding of, the Firewall process at a packet level, particularly in respect to Linux based Firewall methods, and their use in conjunction with other useful Open Source network and security tools – a basic knowledge of which I regard as essential for any Network Engineer.

The initial catalyst for this investigation was the discovery on the Internet of a well written "How To" called Firewalls by Daryl Caudill, an IT Professional from Florida, USA.

This incomplete document, available from here:


laid out a desired plan for the installation and testing of Shorewall, a Linux based application, in conjunction with various other optional security applications, to create a flexible but very secure Firewall/Web Content Filtering system that can run on a suitably equipped, relatively low specification I386 based IBM compatible PC or higher.

Project Objectives

My intention was to install the system on a 4GB USB stick for portability - as many PCs offer USB boot functionality - using the latest Debian Lenny Stable I386 based kernel version, which is an upgrade to the Etch release which Daryl Caudill's original document was based on.

I also planned to continue the installation and testing of some the applications that were incomplete in Daryl's document. The stages of this will be outlined in further detail later, but with a minimum Project goal of configuration, testing and suitably thorough investigation of the Firewall and its functionality for my level of Networking knowledge and interest.

Resource Requirements

  • 4GB USB memory stick or IDE hard drive 1GB minimum capacity
  • I386 processor based PC with bootable USB BIOS capability as a host PC for the USB system
  • sufficient memory (as little as 256MB RAM)
  • 2 x Linux compatible Network Interface Cards
  • keyboard, monitor, CD/DVD unit
  • writeable CD/DVD disk for initial booting of the Linux image
  • Internet access via suitable modem and 4 port hub for Internet based research/testing/software downloads
  • 2 x Test PCs/laptops for LAN/WAN side network testing
  • basic to intermediate working knowledge of Computer Networking by the installer (highly recommended).


For documentation reasons, some of the installation may be done in tandem on other machines, as it is identical at any stage, to be able to connect suitably to the available equipment and network setup at the various times of writing, mainly so that screen dumps can be taken of the process, by connecting via "PuTTY" Secure Shell ( from another machine running Windows Word, to be able to paste the screen dumps at relevant stages. This is required because the Linux machines will not have a desktop environment installed, as they are headless, command line only servers in the finished state in which they will operate.

This method also ensures that only the required software is installed, configured, explained and documented clearly at each stage on the Linux system, and the environment for testing is fixed with regard to the software installed on the system at each stage. This should aid in the fault finding and solving process if problems are encountered.

Proposed Outcome

I expect some software/Linux library incompatibilities between applications and the OS as it is a later version (Lenny) than the OS (Etch) in Daryl's original paper, but hope to find solutions to this should problems arise.

I expect this system to be able to function satisfactorily on 90+% of suitably equipped IBM compatible PCs - or on as many PCs that can run the Linux OS itself as the functionality of any of the applications available with each distribution is fundamental to this in the first place, if the Debian Linux distribution is marked as "Stable" which Lenny is.

The overall goal of the project is to gain a better understanding of the Firewalling process down to a network packet level, and to learn some other useful network concepts and security tools.

Basic Firewall Packet Theory

Before going further, I will introduce some basic principles as related to the treatment of packets in a Firewalled system. Much of the following information was learned from Daryl Caudill's' original and informative text, and other sources on the Internet which will be in the Reference section.

The simplest system (2 Network Interface Cards, No Demilitarised Zone or DMZ) is divided into three main areas of packet inspection and/or regeneration – OUTSIDE, FIREWALL and INSIDE, or the Internet (public WAN), Server (packet processing/regeneration zone), and Private (LAN) zones. These will come to be known as the NET (Internet), FW (firewall) and LOC (local) zones when configuring the appropriate files later:

OUTSIDE NET (Distrusted Zone)    Eth0    FW    Eth1    INSIDE LOC (Trusted     Zone)

[ADSL] <--> [eth0, WAN] <----> [Firewall zone ] <-----> [eth1, LAN ]
[ Inet ] <--> [I/O packets] <----> [packet initiation] <----> [I/O packets]

This concept allows for the passage of traffic over 6 distinct path combinations to, from and "through" the Firewall from various directions.

These six paths are:

(eth0 in: NOTHING initiated from outside is EVER allowed except for Administrative Secret "Port Knocking" to be explained later. When all unsolicited packets initiated from the Internet are ignored (dropped) the firewall is said to be "stealthed" as no replies of any sort are made to any web based requests and is the desired state for a Firewall to be configured as.
(eth0 out: FW server to Internet requests: apt-get updates for Linux on port 80, Squid web proxy, Network Time Protocol, Domain Name Server Masq, Secure Shell client to Net, ping/Nmap to Web etc.)
(eth1 out: maybe only to ping/Nmap from the FW to the LAN if you have SSH'd into the FW for Admin/testing purposes)
(eth1 in: For security, users NEVER allowed direct WAN access, so they will request Web access from the FW based Squid proxy server, which connects to the Web for them, and caches the pages, unless there is no issue with users accessing any site on the Web, which is bad practise due to the legal and viral implications of pornographic and Relay Chat (IRC) sites. Security for this will be handled by Squid (Website access control) and Dan's Guardian (page content filtering).
(eth1 in, eth0 out: NOTHING directly allowed usually, except Windows updates requests from LAN pHs, and perhaps web based virus scans at specific IPs, and other special cases)
(eth0 in, eth1 out; "through" traffic via DNAT - Destination Network Address translation i.e. port forwarding to your allowed services e.g. a Web Server. This translation retains stealth as the actual LAN IP addresses are invisible from the WAN).

The Firewall server inspects each packet that enters each interface and forwards (regenerates) it, or denies (drops) it according to a set of pre-defined rules set up in an Access Control List (ACL). As this process is relatively processor intensive, the faster the server is and the more efficient the coded software is, the better, obviously.

A general rule relating to ACL creation and placement is:

1 ACL: per
interface, per direction, per protocol.

For example, if Internet Web page access for all users in the LAN were to be given, but with no regard for security, as this gives users direct Internet access, at least 2 ACLs would have to be created and placed accordingly once Firewall software is installed, as installation of this software changes the default state of the Linux systems default routing behaviour. The default behaviour is recorded later for reference in the System Configuration section below.

The first ACL – per
interface, per direction, per protocol, would have to allow packets to interface eth1 in an inward direction (relative to the centre of the Firewall) to eth1 from LOC, for TCP protocol.

The second would have to allow return traffic from the outside interface eth0, in an inward direction
(relative to the centre of the Firewall) to eth0 from NET, for TCP protocol.

The reason that no more ACLs have to be configured specifically for this example for outgoing traffic from the inside of the Firewall through the external interface (eth0 out) is because the Linux kernel is already configured to track established, legitimate requests from the inside interface (eth1 in), through itself, to the exit path via eth0 out, so does not require an exit ACL to allow eth0 outbound traffic, because both interfaces are directly connected to the server and the kernel and Shorewall software is programmed accordingly. The baseline tests documented later will show the default connectivity for the basic Linux installation before the Shorewall software is installed, then after installation.

The actual Firewall server is the buffer zone between the Internet (NET) and the internal network (LOC). Traffic can be:

  • DROPPED (no notification reply is returned, so is more secure)
  • REJECTED (a notification is sent to the request source, which is insecure as it gives information to a potential hacker)
  • ACCEPTED (from a legal source requesting legitimate services from the LAN, hopefully)
  • MASQUERADED (or "port forwarded" from a legal source requesting legitimate services from the LAN, hopefully).

NOTE: The default Linux system routing behaviour may be different from a Cisco or other router for example, where a routing protocol or static routes between directly connected interfaces may have to be enabled, and appropriate ACLs configured separately to allow connectivity between router interfaces and connected equipment.

IPTables and Shorewall

To better understand any firewalling process that runs on most Linux systems, a brief overview of the base components required for packet inspection need to be mentioned.

" is home to the software of the packet filtering framework inside the Linux 2.4.x and 2.6.x kernel series. Software commonly associated with is iptables." [accessed 6/5/10]

IPTables is software that is embedded in the Linux kernel which enables traffic manipulation at the packet level, so can be configured to implement firewalls, NAT, and other packet inspection mechanisms on a Linux server. It uses three main "Tables" of categories for packet treatment:

  • filter — The default table for handling network packets.
  • nat — Used to alter packets that create a new connection.
  • mangle — Used for specific types of packet alteration.

It uses a "rule sets", that can act within each Table, in a similar fashion to Cisco Access Control Lists, for example, comparing packets individually to the sequential rule set, and manipulating each packet according to any rules that apply to it. For clarity, brevity, and future reference, and as an understanding of the basic principles underlying this project is fundamental for me at this point for relating Shorewall to IPTables later, I am reproducing this overview in its entirety from the Redhat site, as it is well written and succinct:

Each of these tables in turn have a group of built-in chains which correspond to the actions performed on the packet by the netfilter.

The built-in chains for the filter table are as follows:

  • INPUT — Applies to network packets that are targeted for the host.
  • OUTPUT — Applies to locally-generated network packets.
  • FORWARD — Applies to network packets routed through the host.

The built-in chains for the nat table are as follows:

  • PREROUTING — Alters network packets when they arrive.
  • OUTPUT — Alters locally-generated network packets before they are sent out.
  • POSTROUTING — Alters network packets before they are sent out.

The built-in chains for the mangle table are as follows:

  • INPUT — Alters network packets targeted for the host.
  • OUTPUT — Alters locally-generated network packets before they are sent out.
  • FORWARD — Alters network packets routed through the host.
  • PREROUTING — Alters incoming network packets before they are routed.
  • POSTROUTING — Alters network packets before they are sent out.

Every network packet received by or sent out of a Linux system is subject to at least one table.

A packet may be checked against multiple rules within each table before emerging at the end of the chain. The structure and purpose of these rules may vary, but they usually seek to identify a packet coming from or going to a particular IP address or set of addresses when using a particular protocol and network service.

Regardless of their destination, when packets match a particular rule in one of the tables, a target or action is applied to them. If the rule specifies an ACCEPT target for a matching packet, the packet skips the rest of the rule checks and is allowed to continue to its destination. If a rule specifies a DROP target, that packet is refused access to the system and nothing is sent back to the host that sent the packet. If a rule specifies a QUEUE target, the packet is to be passed to user-space. If a rule specifies the optional REJECT target, the packet is dropped, but an error packet is sent to the packet's originator.

Every chain has a default policy to ACCEPTDROPREJECT, or QUEUE. If none of the rules in the chain apply to the packet, then the packet is dealt with in accordance with the default policy.

The iptables command configures these tables, as well as sets up new tables if necessary.

Many people, including myself, find the IPTables rule set commands too confusing, unwieldy, and difficult to understand in their base form to want to use IPTables directly at the command line and in configuration files to build a firewall - some examples of such commands are:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -i eth1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Without a lot of research and a large learning curve, it may be a while before you had a suitable firewall using IPTables commands directly.

Many applications have been written as more user friendly environments that control IPTables itself. These range from less cryptic command line and configuration files based applications – such as Shorewall – to full blown GUIs that shield the user completely from the IPTables rules working behind the scenes. Guarddog is a nice user-friendly example of this that I have looked at in the past, aimed at novices using a Desktop Environment, available at and can be installed from the command line in Debian with:

apt-get install guarddog

Base Linux Installation

A base network installation ISO image for the I386 PC platform is downloaded from and burned to CD/DVD for booting.

This method ensures that only the latest version, minimum required base system is installed. Only the required software for each stage is installed and configured subsequently.

The screen dumps for the base installation and hard drive partitioning sections are in the glossary at the end of the document, and are standard and self-explanatory for any Linux base install.

After the base install is complete, the system is rebooted into the new system for the first time and the required software installed and configured manually from this point. The first thing to do is log into the new system as "root" with full administrative access to the whole system, and install a Secure Shell server so access and control can be done from a remote machine running Windows/Word, using the PuTTY application so that software installation and system configuration can begin and be documented via screen dumps, using the Alt/Print Screen buttons, once I know the Firewall machine's IP address that it obtained from the Access Point via DHCP ( at this point).

Initial System Configuration

From the Windows control/documentation pc using PuTTY:

Now I can log in to the Firewall server remotely.

As I am somewhat familiar with Linux systems, I like to colourise the text based display, which helps identify some file types.

This requires using a command line text editor that I use called VIM, which has to be installed from the Internet based depositories of the Debian network.

I can now edit the appropriate hidden file (.bashrc) and remove the comment hash marks (#) to make the text line active, to colourise the output using:

vi .bashrc



Now, after editing and logging out and in again, and running the list command for the root directory, the output shows coloured text:

Different directories and files are coloured according to their attributes and types; executables are bright green, links are light blue, and directories are dark blue, for example.

Network Topography

To help visualisation, I have a basic network of a Wi-Fi capable, ADSL connected Access Point to simulate an ISP DHCP connection to the eth0 External NET interface of the Firewall, and a LAN host connected to the LOC eth1 interface of the Firewall. I can also access the LAN LOC test laptop from the AP test laptop directly via Windows Remote Desktop, so I can test from it to the FW and beyond and document the results via screen dumps.



I check/set the external NET eth0 interface to DHCP (already done during base install). As the eth0 interface cannot connect directly to an ISP here, the DHCP server Access Point will simulate the external WAN in all of the future tests, bearing in mind that provision will have to be made for Private IP addresses and their treatment by network devices according to RFC1918. This will be explained later.

Pings and Nmap scans to and from both sides of the Firewall server to/from the connected hosts on the each subnet will document the default behaviour before Shorewall or other software is installed.

To check the external LAN interface (eth0) was set to DHCP during the base install, and is accepting an IP address offer, and set the internal eth1 LOC LAN interface to a static address (, I edit the /etc/network/interfaces file:

vi /etc/network/interfaces

The Access Point is Wireless, so I can also connect via that to the internal LAN test laptop (as the direct wired path via the FW is unusable because the test laptops are on two different subnets), allowing me to control all the required devices from one pc and document tests from both sides of the network.

I can now connect the internal eth1 interface of the FW to the test laptop on the LOC LAN, setting a static IP address on it of

I restart the network services to activate the eth1 interface on the Firewall using:

/etc/init.d/networking restart

I then check its IP address and functionality using the commands:


This command gives information about the layer 2 and 3 addresses and traffic of all known interfaces amongst other details


The Packet Internet Groper utility sends ICMP (Internet Control Message Protocol) packets from a layer 3 interface to another, to try and obtain information about its connected state.

Initial functionality of both the server interfaces (eth0 and eth1) has been established as seen above.

Default Routing Behaviour

To set a baseline for the Linux systems' default install network connectivity behaviour, I need to collate a set of ping results from both sides of the server and from within it, that will serve as references for later tests, and to understand any behaviour that may be different to what I think it would or should be. These will be summarised and any conclusions drawn. There will be ten reference pings across the three zones of the network from both directions and from the centre, in total.

The 10 Reference Tests

1:    LOC laptop to eth1

2:    LOC laptop to eth0

3:    LOC laptop to NET Access Point

4:    FW to LOC laptop

5:    FW to eth1

6:    FW to eth0

7:    FW to NET AP

8:    NET laptop to LOC laptop

9:    NET laptop to eth1

10:    NET laptop to eth0



The 10 Reference Ping Tests Results

1: LOC laptop ( to eth1 (

2: LOC laptop ( to eth0 (

3: LOC laptop ( to Access Point (

4: FW ( to LOC laptop (

5: FW ( to eth1 (

6: FW ( to eth0 (

7: FW ( to Access Point (

8: NET laptop ( to LOC laptop (

9: NET laptop ( to eth1 (

10: NET laptop ( to eth0 (

Default Ping Test Summary

1:    LOC laptop ( to eth1 (            successful

2:    LOC laptop ( to eth0 (            successful(?!)

3:    LOC laptop ( to NET Access Point (    failed

4:    FW ( to LOC laptop (            successful

5:    FW ( to eth1 (                successful

6:    FW ( to eth0 (                successful

7:    FW to ( NET Access Point (        successful

8:    NET laptop ( to LOC laptop (        failed

9:    NET laptop ( to eth1 (            failed

10:    NET laptop ( to eth0 (            successful

Default Ping Test Conclusions:

All of these results are what would be expected, as the successes should be simply due to devices sharing the same network, and the failures simply due to devices being on different networks.

However, test 2 shows an initially unexpected result until thought about further and some more information gathered.

The Firewall server is not acting in a symmetrical fashion, as the LOC traffic to the server can connect to the interface on the opposite side (eth0) of the server from itself - even though it is on a different network - but the NET traffic cannot connect to eth1.


As a network layer3 device requires a default gateway, or route of last resort for traffic it otherwise does not have local information for where to send it to, eth0 appears to act as this gateway which would explain why traffic from a different network generates a ping response from it.

The command to show routing information in Debian is route:


This default route ( via the eth0 interface explains why eth0 is accessible to traffic entering the server that is not on the same network. Other connected interfaces not on a same network as the traffic are not accessible, as eth1 ( does not respond to traffic from the NET (192.168.0.x). The inside of the eth0 gateway interface would be expected to be accessible to all packets entering the FW regardless of their source address, so base routing functionality must be due to IPTables installed in Linux kernel itself as explained earlier, as no specific routing software has been manually installed by me at this point.


A key utility that will be used a lot to test the network, is an open source program, Nmap, available from

It is available as a Windows executable and a Linux package, that I have installed on both client laptops and the server.

This utility is used mainly to look for available or unprotected services that are running on a system that could lead to that system being compromised. Because a system does not reply to Internet Control Message Protocol ping packets, it does not mean it is inaccessible via other ports or protocols. Nmap will be used to show these where possible. It uses various means to report these services, as it processes the responses of different hardware and operating systems to its requests for services that use the ICMP, TCP and UDP protocols, by varying the sent packets characteristics, such as type, length and timing. An overview of the utility can be found at:

Hopefully more will be learned about the many switch options of Nmap during this project, which makes it so versatile but quite hard to learn to use effectively and appropriately.

As Nmap is fundamental to this Project, some key information from the manual pages is reproduced here rather than in the Appendix, for a brief overview of its behaviour, and to help understand the coming investigation at each step:


While Nmap has grown in functionality over the years, it began as an efficient port scanner, and that remains its core function. The simple

command nmap target scans more than 1660 TCP ports on the host target. While many port scanners have traditionally lumped all ports into the open

or closed states, Nmap is much more granular. It divides ports into six states: open, closed, filtered, unfiltered, open|filtered, or


These states are not intrinsic properties of the port itself, but describe how Nmap sees them. For example, an Nmap scan from the same network as

the target may show port 135/tcp as open, while a scan at the same time with the same options from across the Internet might show that port as


The six port states recognized by Nmap


An application is actively accepting TCP connections or UDP packets on this port. Finding these is often the primary goal of port scanning.

Security-minded people know that each open port is an avenue for attack. Attackers and pen-testers want to exploit the open ports, while

administrators try to close or protect them with firewalls without thwarting legitimate users. Open ports are also interesting for

non-security scans because they show services available for use on the network


A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it. They can be helpful

in showing that a host is up on an IP address (host discovery, or ping scanning), and as part of OS detection. Because closed ports are

reachable, it may be worth scanning later in case some open up. Administrators may want to consider blocking such ports with a firewall. Then

they would appear in the filtered state, discussed next.


Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be

from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so

little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication

administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several

times just in case the probe was dropped due to network congestion rather than filtering. This slows down the scan dramatically.


The unfiltered state means that a port is accessible, but Nmap is unable to determine whether it is open or closed. Only the ACK scan, which

is used to map firewall rule sets, classifies ports into this state. Scanning unfiltered ports with other scan types such as Window scan, SYN

scan, or FIN scan, may help resolve whether the port is open.


Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open

ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does

not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, null, and Xmas scans classify ports this way.


This state is used when Nmap is unable to determine whether a port is closed or filtered. It is only used for the IP ID idle scan."

on usage and switch options for various scan types is shown by running nmap on the Linux server with no arguments:


Default Nmap Reference Scans

I will use Nmap to show the services status of all the interfaces at this point of the installation, in the same way as I did for the ping reference tests.

Configuration change comparisons can then be made after DNSMasq, Shorewall or other relevant software is installed and configured. Again, I ensure that the Windows firewall is turned off on the LOC laptop in case it is configured to block any traffic, and ensure that the Wi-Fi connection is disabled to guard against alternative routes via the AP affecting results from these tests.

There will be ten "quick" scans (nmap –T4 –F) run in total by the three PCs:

From LOC

1:    LOC laptop to eth1

2:    LOC laptop to eth0

3:    LOC laptop to NET Access Point

From FW

4:    FW to LOC laptop

5:    FW to eth1

6:    FW to eth0

7:    FW to NET AP

From NET

8:    NET laptop to LOC laptop

9:    NET laptop to eth1

10:    NET laptop to eth0

1: LOC laptop ( to eth1 ( Nmap

2: LOC laptop ( to eth0 ( Nmap

3: LOC laptop ( to NET Access Point ( Nmap

4: FW ( to LOC laptop ( Nmap

5: FW ( to eth1 ( Nmap

6: FW ( to eth0 ( Nmap

7: FW ( to NET Access Point Nmap (

8: NET laptop ( to LOC laptop Nmap (

9: NET laptop ( to eth1 Nmap (

10: NET laptop ( to eth0 Nmap (

Default Nmap Test Summary

1:    LOC laptop ( to eth1 (            successful

2:    LOC laptop ( to eth0 (            successful

3:    LOC laptop ( to NET Access Point (    failed

4:    FW ( to LOC laptop (            successful

5:    FW ( to eth1 (                successful

6:    FW ( to eth0 (                successful

7:    FW ( NET Access Point (        successful

8:    NET laptop ( to LOC laptop (        failed

9:    NET laptop ( to eth1 (            failed

10:    NET laptop ( to eth0 (            successful

Default Nmap Test Conclusions:

All of these results are what would be expected, and follow the ping test results regarding connectivity, as the successes should be simply due to devices sharing the same network, and the failures simply due to devices being on different networks, except in the case of test2, where again is seen the connection to the default gateway (eth0 ) - now expected.

The services visible on these interfaces have now to be taken as the references, as any more appearing or disappearing for the same type of scan, should now be due to the effects of subsequently installed software. This is not to say that Nmap has definitively revealed all services running on the relevant devices because it depends on what ports are programmed to be checked in the "quick" scan (-T4 -F), and as there are issues regarding the reporting of UDP services for example, the detailed technical reasons for this are beyond my education and interest for this particular Project, at this stage at least.

Any issues I deem relevant that affect the tests will be researched and documented here, as part of the learning process. DHCP UDP packets will be researched further as it is relevant to the tests I will run, as it is fundamental to the operation of the Firewall when configured later.

The services these set of Nmap scans has revealed running on the devices are summarised below:

FW Reference Services

22/tcp open ssh

111/tcp open rpcbind

Access Point Reference Services

22/tcp open ssh

23/tcp open telnet

53/tcp open domain

80/tcp open http

LOC Laptop Reference Services

135/tcp open msrpc

139/tcp open netbios-ssn

445/tcp open microsoft-ds

3389/tcp open ms-term-serv

The main services to note here and why they exist on each device are:

  • ssh running on both the Access Point and the server to enable server control from a central point for documentation reasons.
  • rpc (remote procedure call) running on all PCs are required Operating System processes in Linux and Windows server/client systems
  • dns running only on the AP at present, to allow web access for research and for testing client Internet connectivity changes when the Firewall is installed and configured
  • http running only on the AP at present, to allow Admin web access to the AP
  • ms-term-serv running to enable Remote Desktop control of the LOC laptop from a central point for documentation reasons.
  • microsoft-ds and netbios-ssn running as I have Netshares available on the network

There is now an issue to be resolved, as I know that DHCP is also running on the Access Point, as it serves eth0 ( at present. I need to be able to detect it now, before the next stage where DNSMasq is installed, as this will affect the overall functionality of the current system, as DNSMasq can also serve DHCP and DNS.

Unlike DNS which can use both UDP and TCP protocols for transport,

DHCP only uses UDP.

This is why DHCP was not revealed by Nmap in its "quick" TCP scans but DNS was.

The effect of this for Nmap when detecting UDP services is important for this project:

"The ports are either open or
filtered, and there is no easy way to distinguish the two.
A closed port would return an icmp-port-unreacheable, but if no answer
is received)…the port is either open (application
accepting the packets) or a portfilter (is silently dropping the packets)"

The manual pages for Nmap have information on UDP port scanning techniques:

man nmap

"…Upon hitting a closed port on the target machine, the UDP

probe should elicit an ICMP port unreachable packet in

return. This signifies to Nmap that the machine is up and

available…The primary advantage of this scan type is that it bypasses firewalls and filters that only screen TCP."

This means that only a closed port will give a definite response to Nmap and allow its state to be known definitively.

For now, I will UDP scan the Access Point as I know it is DHCP active, using the –sU switch, from the server to see what results:

From the Nmap section introduction, when Nmap shows:


Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open

ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does

not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, null, and Xmas scans classify ports this way.

DHCP UDP runs on ports 67 (server) and 68 (client), so a UDP scan run to specifically target these ports reveals:

In this case, as I know for sure that DHCP (server 67) is running and unfiltered on the AP, but DHCP client (68) is not, I can use this result as a reference later when DNSMasq and Shorewall are installed.


As the two server Ethernet cards need to be on different subnets for isolation from a direct Internet DHCP connection, and so that Network Address Translation can be utilised for many LAN clients to share a single IP address (eth0), the Firewall server needs to remain in control of the LAN side network via DHCP, wherever it is installed. A utility called DNSMasq can be used to forward DHCP and/or DNS packets from one interface to another across the FW zone, or act as a dedicated DHCP server from either interface. In this case I require the DNS services provided by the ISP/AP so the FW and LAN clients can access the Internet via named addresses and not just IP address numbers, without having a separate dedicated DNS server installed on the Firewall, so that each client gets consistent DNS server and subnet address information, and so NAPT (Network Address Port Translation) remains functional across these two different networks when configured as part of the Firewall functionality later.

When DNSMasq is installed, configured and enabled, I will be able to set the LAN laptop client interface from its current static IP to DHCP. As usual, when a new Debian package is installed, its man pages are read (if only the description) to get an overview of the program.

apt-get install dnsmaq

man dnsmasq


dnsmasq is a lightweight DNS, TFTP and DHCP server. It is intended to

provide coupled DNS and DHCP service to a LAN.

Dnsmasq accepts DNS queries and either answers them from a small,

local, cache or forwards them to a real, recursive, DNS server. It

loads the contents of /etc/hosts so that local hostnames which do not

appear in the global DNS can be resolved and also answers DNS queries

for DHCP configured hosts.

The dnsmasq DHCP server supports static address assignments, multiple

networks, DHCP-relay and RFC3011 subnet specifiers. It automatically

sends a sensible default set of DHCP options, and can be configured to

send any desired set of DHCP options, including vendor-encapsulated

options. It includes a secure, read-only, TFTP server to allow net/PXE

boot of DHCP hosts and also supports BOOTP.

Dnsmasq supports IPv6 for DNS, but not DHCP.

Editing the configuration file "/etc/dnsmasq.conf", and setting "interface=eth1" (line 85):

vi /etc/dnsmasq.conf

I uncomment "expand-hosts" (line 114) to add domain name information to host names in the hosts file; set "domain=mydomainname" (line 124); and "dhcp-range=,,12h" for the LAN while here (line 130) so that only 1 DHCP address ( is given out during testing for documentation consistency;

And then restart the DNSMasq server with:

/etc/init.d/dnsmasq restart

I am able to set the LAN client to DHCP now and retain my current address. Nmap immediately reveals the DNS forwarding service on port 53 as active on eth1 which was not active before:

The IP address has now been changed from static and assigned by DHCP via DNSMasq:


Nmap DHCP and UDP Services Discovery

I know that the DNSMasq DHCP service is working correctly as LOC laptop has a DHCP address, from the information above, and as DHCP is fundamental to the Firewall operation I will also have to run the same 10 reference tests for the detection of UDP services, as before for pings and TCP, for consistency and a more complete reference. The prior research revealed that UDP services can be detected by Nmap and represent a potential vulnerability for a system, from the Nmap manual:

"The primary advantage of this scan type is that it bypasses firewalls and filters that only screen TCP."


It is therefore vital to know the level of security that a Firewall can offer with regard to UDP, and so its overall usefulness, by what its behaviour is in relation to its treatment of these packets. Following the same test format as before, and remembering to disable the LOC Wi-Fi:

1: LOC laptop ( to eth1 (

2: LOC laptop ( to eth0 (

3: LOC laptop ( to NET Access Point (

4: FW ( to LOC laptop (

5: FW ( to eth1 (

6: FW ( to eth0 (

7: FW to ( NET Access Point (

8: NET laptop ( to LOC laptop (

9: NET laptop ( to eth1 (

10: NET laptop ( to eth0 (

Default Nmap UDP Scan Summary

1:    LOC laptop ( to eth1 (            successful

2:    LOC laptop ( to eth0 (            successful

3:    LOC laptop ( to NET Access Point (    failed

4:    FW ( to LOC laptop (            successful

5:    FW ( to eth1 (                successful

6:    FW ( to eth0 (                successful

7:    FW to ( NET Access Point (        successful

8:    NET laptop ( to LOC laptop (        failed

9:    NET laptop ( to eth1 (            failed

10:    NET laptop ( to eth0 (            successful

Default Nmap UDP Scan Conclusions:

At this point it is realised that UDP reference scans should have been taken before the installation of DNSMasq for consistency, but as a major part of this Project is a learning experience, I realise I should have thought about and planned my test procedures for baseline references better before hand, and followed a set test pattern at each stage. I was not aware of the repercussions of UDP scanning for testing a Firewall, so did not expect to be involved with it for testing using Nmap.

It has opened up a massive area of research.

However, as the main focus of the Project is the investigation and effects the Shorewall Firewall has on a default system to better understand the workings of the Firewall itself, doing the UDP scans after the installation of DNSMasq are sufficient for my purposes, as the documentation of the system state at this point is all that is important for referencing the changes the Firewall configurations will have on the system compared to before Shorewall was installed.

Some points to note from the last set of scans are:

  • general connectivity is the same as previous tests, as expected, with general connectivity fails on tests 3, 8, and 9
  • there are many more UDP services listed than initially expected and their purposes could be researched with sufficient interest if relevant here within Project time and goal constraints
  • the nmap manual pages listing port states as open|filtered are regarded as inconclusive results, as only a closed port gives a definitive response revealing its state. This means false positives are possible and require further investigation as required

What is interesting at this point is that these scans led to further Back-Orifice and Nmap research and the discovery that Nmap has a library of default scripts to run with (the Nmap Script Engine, NSE), to aid in its evaluations, which is indicated by the options drop-down menu shown in the Windows versions:

As a menu with defaults is not available for the Debian command line, the relevant switches would have to be entered to run an identical scan as those in the Windows menus. This may account for differences in the results of scans against the same interfaces from the Windows PCs to the Linux server, as Back-Orifice (port 31337) is not shown for the Linux server scan (test 5) from the FW to eth1 ( interface, but they are from the LOC laptop at (test 1) to eth1 ( This could also be due to different script versions run in each package version. To investigate this further, a scan using the –p switch for scanning specific ports was tried and a different result obtained when scanning the BO port 31337 specifically from the LOC laptop ( compared to before, as this time it showed as closed:

This scan was repeated on the server and found closed also:

It seems that specifically targeting a UDP port using the –p switch forces a definitive response to a closed port, than when a generic "sweep" scan is run, so can be used if a more definitive result is required for services of interest that "might" be running, from an open| filtered result.

One method of verifying services and ports on a Linux server is to run "

netstat –tunapv" to show all TCP and UDP services actually running on the server, to cross verify:



This output does not show a service running on port 31337, only those expected due to the kernel, and software installed so far, so I will assume mostly false positives for this type of sweep scan in future, for results that show as open|filtered and will check specifically using the –p switch as required.

As I have a reasonably comprehensive set of reference data, and am more familiar with Nmap, I feel I can proceed on to the net stage - installing the actual Firewall software itself.

Shorewall Firewall Installation

The Shorewall program can be installed and the "manual" help documentation studied as required with:

apt-get install shorewall

After reading the documentation in /usr/share/doc/shorewall-common/README.Debian after gunzipping it, and looking at /etc/shorewall/shorewall.conf, I copy all the "two-interfaces" files from the /usr/share/doc/shorewall-common/examples/two-interfaces/* to the configuration directory, /etc/shorewall/

cp -vr /usr/share/doc/shorewall-common/examples/two-interfaces/* /etc/shorewall/

Changing file perms for only root access for security reasons:

chmod 600 /etc/shorewall/*

The effect of this command on the files is to make the files read/writeable for root only:

Now I edit each of the important files in /etc/shorewall/ which are:

  • zones
  • interfaces
  • masq
  • policy
  • rules
  • shorewall.conf

The most important file is RULES, as this is where the others files generally prohibitive settings are over-ridden to allow traffic that is otherwise blocked by default settings. Note that the string "$FW" for firewall zone in the rules file is interchangeable to "fw".

Taking a closer look at the relevant parts of these files it is seen they are quite simple to understand in most cases, with terminology relating to the 3 Firewall zones:


vi /etc/shorewall/zones

No changes are made to this file, as it merely defines the zone traffic types in terms of FW, NET and LOC that has been used so far. For example, another physical interface (eth2) could be added and named DMZ.

Interfaces File

vi /etc/shorewall/interfaces

This file defines interfaces and options to Shorewall. For example, if we added the DMZ zone via eth2 as mentioned above, an example line could be added, giving a specific broadcast address:

dmz     eth2


The "loc eth1" line gets changed to: loc eth1 detect tcpflags, detectnets, nosmurfs, dhcp
This line allows DHCPDISCOVER packets detection from the LAN clients, and "smurf" packets generated from the LAN.


RFC1918 is a Request For Comments paper relating to the blocking of Private Addresses to the Internet. In effect it makes these addresses totally illegal on the Internet, so if they occur it is either a device misconfiguration, or a deliberate attempt at mischief. This is why it is set as detectable by default on eth0, to block any Private address traffic, which is the NET WAN side interface. However, I have to remove this as I am simulating the Internet side traffic using Private addresses. The blocks of addresses in this category are:        -  (10/8 prefix)      -  (172.16/12 prefix)     - (192.168/16 prefix)

nosmurfs option

This option filters traffic for "smurfs".

Smurfs can be forged source address packets that are broadcast to responsive networks, to appear to be a query from the intended victims IP address and are designed to cause an ICMP echo reply "denial of service" attack to that victim and/or its network from devices responding to the query, by causing all recipients of the broadcast on multiple networks, to transmit ping replies to the spoofed source address victim, so amplifying the traffic returning to the victim and its network. This can clog a network to the point where it fails to operate.

Use of a device that blocks specific broadcast traffic is a way to prevent this from happening, by only allowing specific source addressed packets to pass through a particular interface, for example. To secure a network with a Cisco router from taking part in a smurf attack, issue the router command:

no ip directed-broadcast

logmartians option

martian definition:

In a computer networkpackets with source addresses not routable by some computer on a network segment are referred to as martians or "packets from Mars", on the grounds that they are of no evident "terrestrial" (i.e. normal) source. Martian packets can arise from network equipment malfunction, misconfiguration of a host, or simple coexistence of two logical networks on a single physical layer. For instance, if the IP networks and operate on the same Ethernet segment, packets from are Martians to the computer at, and vice versa.

tcpflags option

If the interface on which the packet entered the firewall has the tcpflags option specified in /etc/shorewall/interfaces and the packet's protocol is TCP then the TCP flags are checked by the tcpflags chain (filter table).

There are a number of types of flags that can be set in a TCP packet, most commonly used are the flags involved in a "3-way-handshake" (SYN, ACK and FIN) for the negotiation of parameters in a communication session between devices:


A, ACK- (Acknowledge) The receiver will send an ACK that equals the senders sequence number plus the Len, or amount of data, at the TCP layer.

SYN, and FIN flags count as 1 byte. The ACK can also be thought of as the sequence number of the next octet the receiver expects to receive. 

S, SYN- Synchronize is used during session setup to agree on initial sequence numbers. Sequence numbers are random. 

F, FIN- Finish is used during a graceful session close to show that the sender has no more data to send. 

R, RST- Reset is an instantaneous abort in both directions (abnormal session disconnection). 

P, PSH- Push forces data delivery without waiting for buffers to fill. This is used for interactive traffic. The data will also be delivered to the application on the receiving end without buffering. 

U, URG- Urgent- Data is sent out of band.

routefilter option


Turn on kernel route filtering for this interface (anti-spoofing measure).

Only those interfaces with the routefilter option will have their setting changes; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

The value 2 is only available with Shorewall and later when the kernel version is 2.6.31 or later. It specifies a loose form of reverse path filtering.



vi /etc/shorewall/masq

Use this file to define dynamic NAT (Masquerading) and to define Source NAT (SNAT).


Masquerading or Network Address Translation allows IP addresses from one interface to be translated and tracked between different networks, allowing routing between them. This was initially invented to buy time when it became apparent that Internet Public addresses would run out quicker than initially thought due to its unexpected exponential growth. This method of routing allows multiple Private addresses to share a single or multiple Public addresses and vice versa, and prevent unnecessary "waste" of the finite number of Public addresses remaining, to allow more time for the transition to IP version6 addressing scheme, which can easily cater for foreseeable future Internet addressing requirements. A common variation of this is Network Address Port Translation, which further increases the flexibility by translating multiple services/sessions for multiple hosts over single or multiple IP connections by altering and tracking the IP address to port numbers for particular hosts' active sessions, allowing many hosts connections to use fewer addresses simultaneously.

No changes are made to this file as it is already set to translate between eth0 and eth1.

It will be possible to view these translations occurring later using "netstat-nat" when installed and Shorewall configured accordingly.


This file defines the high-level policy for connections between zones defined in shorewall-zones.

This file determines what to do with a new connection request if we don't get a match from the /etc/shorewall/rules file. For each source/destination pair, the file is processed in order until a match is found ("all" will match any client or server).


I note in this file that there is an implicit REJECT ALL rule that must be last in the list, similar to an implicit DENY rule that exists at the end of Cisco device Access Control Lists.

vi /etc/shorewall/policy

The POLICY file is the second most important file because:

The default allows all LOC LAN traffic to the NET unless overridden by the RULES file. This may be OK for home use, but not for Corporate strength, or general good practise, as to not prevent unrestricted user access to any website is a risk, or for LAN hosts to have the potential to spoof their LAN address and potentially abuse the network (though detect smurfs would stop this if set in the interfaces file above), so it is locked down to REJECT from ACCEPT, and logged to /var/log/syslog at KERNEL.INFO level with "info" here, so the loc to net line only is changed:


loc         net         REJECT         info
loc         $FW         REJECT         info
loc         all         REJECT         info

The relevant desired access that is REJECTED or DROPPED in this file will be overridden in the Rules file.


The RULES file is where the fun begins, as it is where specific access is controlled between zones by overriding the general prohibitions in the POLICY file. The default settings are:

vi /etc/shorewall/rules

It takes time to familiarise oneself with this file, as a lot of information can be added here.
I think that the basic default RULES file is badly laid out.

For clarity, I found it better to put each zone pair together as "to" and "from" so you can keep track of what traffic you are allowing to go where, especially as the file grows. There are three zones of two directions (in and out as explained in the Theory section above) of potential traffic that have to be thought about and configured for each of the NICS, which are 6 separate path combinations that can be individually configured in the Rules file.

The IPTables internal table automatically tracks a sessions' return traffic when valid, so you DONT have to think about or configure this traffic, as already explained above. I will try to show that traffic legally allowed to access an interface that requires a response will have a 3-way-handshake TCP session allowed, without having to configure a return path in the RULES file.

This greatly minimises the headache and traffic paths needed to be thought about across all the possible zones - unlike setting an ACL in Cisco, where a separate ACL may have to be written and set per interface, per direction, per protocol to allow for return traffic. This can be different for Cisco devices running the ASA Adaptive Security Algorithm software such as the PIX and ASA Firewall devices where connection tracking is also employed for TCP and UDP traffic.


As I want the first tests to be reference default behaviour with no configuration, there are no entries in the RULES file:


The RULES file is edited after backing up the original, and the installation default settings removed so is effectively blank:



# Shorewall version 4.0 - Sample Rules File for two-interface configuration.

# Copyright (C) 2006,2007 by the Shorewall Team


# This library is free software; you can redistribute it and/or

# modify it under the terms of the GNU Lesser General Public

# License as published by the Free Software Foundation; either

# version 2.1 of the License, or (at your option) any later version.


# See the file README.txt for further details.


# For information about entries in this file, type "man shorewall-rules"


# The manpage is also online at









# From the NET to FW: # eth0 in


# From the FW to NET: # eth0 out



# From the FW to LOC:

# From the LOC to the FW:



# From the LOC to the NET (all users):

# From the NET to LOC (internal servers PORT FORWARDING):


 It isn't necessary to specify a return path as packets for all established connections are allowed.

Before starting Shorewall I will check the file format is correct by running:

shorewall check

As no errors were found, I remove the "No Config Inhibitors" by setting "STARTUP_ENABLED=Yes" and "IP_FORWARDING=On" (line 107) in /etc/shorewall/shorewall.conf:

vi /etc/shorewall/shorewall.conf

Also, "startup=1" in "/etc/default/shorewall" needs to be set for Shorewall to start.

vi /etc/default/shorewall

Once these changes have been made, Shorewall can be started.

shorewall start

Testing the Firewall

I was surprised to note that my SSH session from the NET laptop was left intact when Shorewall started, again confirming that IPTables running underneath is controlling and tracking established settings. This means I can still document the internal server tests via PuTTY as before.

The ten reference ping, TCP and UDP tests are run again at this point, as references for the initial Shorewall configuration with NO rules set in the RULES file at all. I expect this should put the Firewall in a completely inaccessible state from outside, and I expect to see no TCP services available when doing the Nmap TCP scans. I expect some connectivity responses for the UDP scans because of the information regarding the nature of UDP traversal of Firewalls cited earlier, even though I hope all UDP packets would be blocked also.

First Configuration Ping Scans

1:    LOC laptop ( to eth1 (

2:    LOC laptop ( to eth0 (

3:    LOC laptop ( to NET Access Point (

4:    FW ( to LOC laptop (

5:    FW ( to eth1 (

6:    FW ( to eth0 (

7:    FW to ( NET Access Point (

8:    NET laptop ( to LOC laptop (

9:    NET laptop ( to eth1 (

10:    NET laptop ( to eth0 (


1:    LOC laptop ( to eth1 (            failed

2:    LOC laptop ( to eth0 (            failed

3:    LOC laptop ( to NET Access Point (    failed

4:    FW ( to LOC laptop (            failed

5:    FW ( to eth1 (                successful

6:    FW ( to eth0 (                successful

7:    FW to ( NET Access Point (        failed

8:    NET laptop ( to LOC laptop (        failed

9:    NET laptop ( to eth1 (            failed

10:    NET laptop ( to eth0 (            failed

First Configuration Ping Test Conclusions:

The Firewall appears to function correctly as it denies pings from any external source to their directly connected interfaces, or the server receiving replies to the pings initiated from within to external hosts.

The anomaly here is the responses to the two Windows laptops as the LOC laptop running XP receives a reply "from" the Firewall:

Reply from Destination host unreachable.

The LAN laptop, running Vista, times out and does not receive this message indicating a different response from the Firewall to the different laptops on eth0 and eth1.

This could be a difference in how the Windows OS's report failed pings, or how the Firewall treats the inside and outside interfaces differently?


Research is required here, but I ran out of patience trying to find suitable answers to the different responses that different OS versions of Windows ping can receive.


I expect to get successes only for tests 5 and 6, as these are the inside of both of the Firewall interfaces that do not cross a defined zone boundary, so effectively cannot have a rule set against them, because in both cases it is merely the server pinging itself, in the same way I would expect a ping to to always function on a Firewall when ICMP is blocked.

First Configuration Nmap TCP Scans

All Nmap scans that give a reply "host seems down" will be marked as a fail, as this means that no response was returned from the host because of lack of connectivity for the reasons explained earlier regarding the default routing behaviour of the server between different networks.

1: LOC laptop ( to eth1 (

2: LOC laptop ( to eth0 (

3: LOC laptop ( to NET Access Point (

4:    FW ( to LOC laptop (

5: FW ( to eth1 (

6: FW ( to eth0 (

7: FW to ( NET Access Point (

8: NET laptop ( to LOC laptop (

9: NET laptop ( to eth1 (

10: NET laptop ( to eth0 (

First Configuration Nmap Summary

1:    LOC laptop ( to eth1 (            failed

2:    LOC laptop ( to eth0 (            failed

3:    LOC laptop ( to NET Access Point (    failed

4:    FW ( to LOC laptop (            failed

5:    FW ( to eth1 (                successful

6:    FW ( to eth0 (                successful

7:    FW to ( NET Access Point (        failed

8:    NET laptop ( to LOC laptop (        failed

9:    NET laptop ( to eth1 (            failed

10:    NET laptop ( to eth0 (            successful

First Configuration Nmap TCP Test Conclusions:

All of these results show the Firewall working as would be expected with no RULES configured, except for test 10 which gives a reply from service port 113.

This is a good result, with the exception of TCP port 113 auth, which is a known problem port for firewalls to conceal as stated by

"The idea behind this protocol was to provide an automated means for remote servers to automatically identify the users who were attempting to connect to them. This means that when a user attempts to connect to a remote machine offering some public service, that remote server would, in turn, attempt to connect back to the user to ask the user's computer to identify the user.

This was originally conceived as a convenient means for allowing things like automatic logon to FTP servers so that users would not need to manually "authenticate" themselves with a username and password. While that might have been a nice idea, the protocol was so simple-minded that it was trivial to fool. It provided no real security, so no one ever took it seriously or trusted it. It was finally renamed from "Authentication Protocol" to "Identification Protocol" because it fell so far short of being able to usefully authenticate anything.

The problem with completely stealthing port 113

Despite the fact that IDENT was never very useful, even today some crusty old UNIX servers — most commonly IRC Chat, but some email servers as well — still have this IDENT protocol built into them. Any time someone attempts to establish a connection with them, that connection attempt is completely put on hold while the remote server attempts to use IDENT to connect back to the user's port 113 for identification.

If the user had no NAT router or personal firewall — and no IDENT server running in their machine to accept the remote server's connection request on port 113 — the user's computer would receive the port 113 connection request and immediately, actively reject the connection. The remote server would quickly know that IDENT was not running on the remote user's machine, it probably wouldn't care, and it would proceed to grant the user's suspended connection request.

However, if either a NAT router or a personal firewall ARE blocking and dropping incoming IDENT requests — if IDENT is fully stealthed — the remote server's attempts to connect would go unanswered. After waiting a while to hear back from its first connection request packet, it would send a second request packet. Then, after waiting much longer, it would send a third, and a fourth after waiting even longer still. With port 113 stealthed by the user, each incoming request would simply be dropped and ignored by the user's local security defences. But in the meantime the remote server — and the user's original connection request — are "hung" waiting for some reply.

Since stealthed TCP connection attempts usually take 45 seconds or more to be abandoned, the effect is that stealthing of port 113 can cause some connections to some remote servers to hang for nearly a minute. (And SOME remote servers will even go so far as to finally refuse the original connection request if nothing is ever heard back from the client's port 113.)

Is all this really a problem?

Probably . . . Not.  Most people who arrange to fully stealth port 113 never have any trouble connecting to any remote servers they commonly use. If, after stealthing port 113, you do experience connection delays, such as when sending or retrieving email, you'll know it immediately since it's usually quite apparent, and you'll know that your ISP is using an IDENT-dependent email server. (But this is not common.)

The trouble experienced by most security conscious people, is that port 113 can sometimes be rather tricky to stealth . . .

Stealthing port 113 on NAT routers

NAT router manufacturers certainly don't want to get the reputation that their NAT router causes connection trouble. But NAT routers have the problem that incoming IDENT requests are inherently unsolicited. As we know, NAT routers double as terrific hardware firewalls due to their natural tendency to drop all incoming unsolicited packets, thus stealthing their owner's networks. But since stealthing port 113 can "theoretically" cause connection problems (but probably never does) NAT routers usually treat port 113 specially. They deliberately return a "closed" status, actively rejecting connection attempts . . . but blowing their otherwise full-stealth cover in the process.

New users of NAT routers, who use this site to check their security, are often disappointed to discover a single closed (blue) port floating in a calm sea of stealth green.

The good news is . . . it is possible to configure NAT routers to return them to full stealth. The trick is to use the router's own "port forwarding" configuration options to forward just port 113 into the wild blue yonder. Just tell the router to forward port 113 packets to a completely non-existent IP address, one way up at the end of your router's internal address range. The router will then NOT return a port closed status. It will simply forward the port 113 packet "nowhere" . . . and your network will be returned to full stealth status."

First Configuration UDP Scans

After this set of scans, it won't be necessary to repeat all ten tests types when testing a particular change, just the relevant interface or service tests, as this will be a sufficient reference data for the "unconfigured" state for UDP, TCP or ICMP protocols.

1: LOC laptop ( to eth1 (


2: LOC laptop ( to eth0 (


3: LOC laptop ( to NET Access Point (

4: FW ( to LOC laptop (

5: FW ( to eth1 (

6: FW ( to eth0 (

7: FW to ( NET Access Point (

8: NET laptop ( to LOC laptop (

9: NET laptop ( to eth1 (

10: NET laptop ( to eth0 (


First Configuration UDP Scans Summary

1:    LOC laptop ( to eth1 (            successful

2:    LOC laptop ( to eth0 (            successful

3:    LOC laptop ( to NET Access Point (    failed

4:    FW ( to LOC laptop (            successful

5:    FW ( to eth1 (                successful

6:    FW ( to eth0 (                successful

7:    FW to ( NET Access Point (        successful

8:    NET laptop ( to LOC laptop (        failed

9:    NET laptop ( to eth1 (            failed

10:    NET laptop ( to eth0 (            successful

First Configuration UDP Scans Conclusions

As was stated in the Nmap man page regarding UDP scans being useful for traversing Firewalls that only filter ICMP and TCP, it seems that Shorewall is only filtering for these and not UDP, as scans 1, 2, 4 and 7 indicate the bulk of the ports are closed, which means a response was received by Nmap from the devices. The default state of the Firewall is NOT stealthy with regard to UDP.

Principles of Stealth

A Firewall that does not respond to any UDP, TCP or ICMP requests on its external interface is known as "Stealthed" whereby it does not give away its existence to arbitrary "ping sweeps" by the many port scanners and other utilities that exist for network device discovery. There are free ones available on the Internet to test the visibility of a device from outside, such as at "Shields UP" at . This offers varied scan types such as "All Service Ports", "Common Ports" or "manual" scans.

When this test is run on the ADSL Access Point on this network it shows the status of the Access Point seen from the Internet, but does not respond to any requests that the TCP and ping scans try to generate from the first 1056 ports, so gets a "Tru Stealth" rating by this website.

Testing Single Entry ACL Return Paths

To verify that Shorewall only requires one Access Control entry to enable a TCP session between two devices - a send AND receive channel - I will add an ACCEPT statement for SSH from the NET to the FW, where the SSH service is running. This should allow a connection from the NET laptop to the server, (after tearing down the one I already have from before Shorewall was started for the first time). I also have SSH server enabled on the Access Point, as seen on the Nmap Reference test 7 that was run before Shorewall was started:

7: FW ( to NET Access Point Nmap (

I should be able to connect to the FW from the LAN laptop, but not connect from the FW to the Access point with only one ACCEPT entry for the LAN to LOC:

After tearing down the current SSH session and restarting the Firewall locally, I scan the FW from the NET laptop to show SSH is available, and re-connect via PuTTY to the FW:

Now I can try to connect to the NET Access Point from the Firewall but get a connection refused response:

Editing the RULES file and unhashing the ACCEPT statement for the FW to NET rule, and restarting Shorewall now allows this session also:

shorewall restart

I have access to the Access Point now also:

This proves that only one rule is required to open up a single bi-directional TCP session between two devices, where IPTables and conntrack is maintaining the connection state in a "state table" until it is torn down by one or other device, or times out.

Running "netstat –an" shows both SSH sessions to and from the Firewall, with NAPT translations and States:

netstat –an

ICMP and PING Research


Researching ping and ICMP in general revealed there is a lot more to this than I thought, as there are different ICMP message types of which ping is only one - type 8 - which give a particular response to a query depending on the interface state, packet treatment, etc:


Type 8 - Echo Request - this is sent by Ping (Packet Internet Groper) to a destination in order to check connectivity. The Variable field is made up of a 2 octet Identifier and a 2 octet Sequence Number. The Identifier matches the Echo with the Echo Reply and the sequence number

As ping is used more than any other tool to show connectivity between devices, with little understanding of the results in many cases, by Networking students and novices alike, I want to explore some of the Firewall options for treatment of these packets and document the responses.

Ping Message Tests

First I allow ICMP traffic to the Firewall from the LOC laptop with the ACCEPT clause in both directions:

# From LOC to FW

ACCEPT loc fw icmp # allows pings and all icmp in to eth1 from LOC

# From FW to LOC

fw loc icmp # allows pings and all icmp out from eth1 to LOC


Shorewall is restarted and the FW pinged successfully from LOC:

LOC is also pinged successfully from the FW:

Changing both clauses from ACCEPT to DROP and retesting both ways:

The above response is not a normal ICMP response because it is generated from the FW server because of Shorewall constraints disallowing ping packets to exit in the first place instead.


The DROP clause is now changed to REJECT both ways:

# From FW to LOC

REJECT fw loc icmp

# From LOC to FW:

REJECT loc fw icmp


These results show the different responses to the ping request, which in turn give information about the interface. In the case of the DROP clause, as no information is returned it is not possible to determine if the interface is up or down (i.e. it is stealthed), but a REJECT clause allows a request a definitive answer – that it is unreachable – at least giving away its active state. This last response may make a hacker decide to explore other possibilities for this interface knowing it is definitely up, rather than waste time on an interface that may or may not be up.

Below is part of a table showing the message types involved in the last tests.

All the ICMP messages are listed below (notice the gaps, this does not mean that some are missing!) along with any additions within the Variable field:

Type 0 - Echo Reply - this is the Echo reply from the end station which is sent as a result of the Type 8 Echo. The Variable field is made up of a 2 octet Identifier and a 2 octet Sequence Number. The Identifier matches the Echo with the Echo Reply and the sequence number normally increments by one for each Echo sent. These two numbers are sent back to the Echo issuer in the Echo Reply.

Type 3 - Destination Unreachable - the source is told that a problem has occurred when delivering a packet.

Type 8 - Echo Request - this is sent by Ping (Packet Internet Groper) to a destination in order to check connectivity. The Variable field is made up of a 2 octet Identifier and a 2 octet Sequence Number. The Identifier matches the Echo with the Echo Reply and the sequence number normally increments by one for each Echo sent. These two numbers are sent back to the Echo issuer in the Echo Reply.

Type 11 - Time Exceeded - the packet has been discarded as it has taken too long to be delivered. This examines the TTL field in the IP header and the TTL exceeded code is one of the two codes used for this type. Trace under UDP, uses the TTL field to good effect. A Code value of 0means that the Time to Live was exceeded whilst the datagram was in transit. A value of 1 means that the Fragment Reassembly Time was exceeded.

SSH Message Tests

To understand more about these messages, I will do similar tests to and from the NET access point, for a SSH session one way, to determine if any messages are ICMP types, or controlled by the SSH software in the different cases. I can leave my current SSH session open from the NET laptop, to document the FW to AP session and alter the RULES file each time.

At present I cannot connect to the AP from the FW with SSH because no configuration is set at all from FW to NET for SSH:

To allow an SSH session from the FW to the Access Point I add:

# FW to NET

SSH/ACCEPT fw net # allows SSH requests out of eth0 to web


Shorewall is restarted and a connection attempted:

This is successful, so I change ACCEPT to REJECT and re-try:

A refusal does not appear in the ICMP TYPE list and as it is authorisation based I expect it to be generated by the SSH software over TCP. This is interesting, as it makes the response look like it is coming from the AP in the same way it would for an unauthorised access attempt like an incorrect password after maximum attempts, but it is the Firewall configuration that is the cause, not the AP. I would have expected a different message that explained the lack of connectivity, but from a security point of view, the vaguer a reply to a potential hacker, the better?

Wireshark would have to be used to analyse the packet content in more depth.

Changing to DROP returns a hung state that would not time out:

This is particularly interesting, as opening up another SSH server session to the FW, (after allowing it in the RULES file) allowed me to re-try the connection to the AP from the FW, and see its hung state by running netstat –an in the second window which revealed the reason, which is a SYN_SENT state (session start synchronisation request), awaiting an ACK (session start acknowledgement) that can never return because of the return DROP clause:

After this, the session did time out eventually:

I now want to open up some services for the LOC side client to show NAPT traversing the Firewall from end to end. I will do this in on zone at a time show the services being made available at each point with the appropriate configurations.

I want the LOC laptop to have web access (HTTP and HTTPS), get DHCP from DNSMasq, SSH to the FW, and be able to ping both ways. This means allowing correct access across all three zones, so I will configure the FW-LOC and LOC-FW zones first.

The RULES file needs:

# From the FW to LOC:
ACCEPT fw loc icmp # allows pings and all icmp out of eth1 to LOC

# From the LOC to FW:

Ping/ACCEPT loc fw # allows pings in to eth1 from LOC
DNS/ACCEPT loc fw # allows DNS requests in to eth1 from LOC
SSH/ACCEPT loc: fw # allows SSH client requests in to eth1 from LOC
HTTP/ACCEPT loc: fw # allows HTTP requests in to eth1 from LOC subnet only
HTTPS/ACCEPT loc: fw # allows secure HTTP requests in to eth1 from LOC subnet only


After Shorewall is restarted, tests for the LOC side services are checked with an Nmap scan from the LOC laptop:

The DNS (53) and SSH (22) services are visible on the FW above.

The FW responds to the LOC laptop ping also:

And vice-versa:

I can open an SSH session between the LOC client and FW:

However, an Nmap scan from the FW to the LOC laptop fails to give a services report:


NAT and NAPT translation

I want to check that translation is occurring across the Firewall end to end, so will load a RULES file that allows the LOC laptop access to the Internet/Access Point and shows the format for some common service protocols. These are self explanatory. The key RULES for this are:


LOC to NET # allow users direct NET access via general protocols

HTTP/ACCEPT loc: net


SSH/ACCEPT loc: net

FTP/ACCEPT loc: net

POP3/ACCEPT loc: net

POP3S/ACCEPT loc: net

IMAP/ACCEPT loc: net


SMTP/ACCEPT loc: net



As DNS is already forwarded by DNSMasq, the LOC laptop should be able to surf the web, open a SSH session to the Access Point or a website, file transfer from the Web/NET devices, and send and receive email. If this works, then the sessions will be shown with NAT translation occurring across eth0 and eth1 after disabling the LOC laptop Wi-Fi, to force the route across the Firewall and first checking that the NAT translation table is empty:

As can be seen below, the web, email, and SSH sessions are shown with the external interface eth0 having the actual protocol port values of web (80), imaps (993, 587 for Gmail), and ssh (22), while the eth1 internal interface has been issued different port numbers mapped to each of the other standard ones.:


This NAT process effectively hides the internal real IP addresses from the outside eth0 interface, as sessions can only be set up from the inside to the outside with SYN packet requests, as this uni-directional behaviour is the default configuration set up in the MASQ file earlier.

If a service, such as a web server exists on the LOC LAN that is to be offered to the public NET side, it has to have its presence made available to the eth0 outside interface. This is accomplished with DNAT or Dynamic Network Address Translation.


DNAT - Dynamic Network Address Translation


The clause enabling DNAT in the RULES file is of the form:


# From the NET to LOC (internal servers PORT FORWARDING)

DNAT net loc: tcp 80 # local web server


I will install Apache web server for Windows on the LOC laptop, check it is working locally, then try to connect to it from the NET laptop.


The service is working locally, as shown by the local IP address in the browser:



The service is visible to Nmap on eth0:


The web server is accessible on port 80 by typing the address of eth0 ( into the browser:

The interesting part to note here is that netstat-nat does NOT show translations in the reverse direction for this session:


"netstat –an" does not show this either, just the established TCP and UDP sessions that were initiated by the LOC laptop:


To leave the Firewall configured for the next stage, I will do some final tests to check that the status of the Firewall is correct for all appropriate services and interfaces, so summarising these requirements:

LOC laptop: SSH, DNS, Ping from FW

LOC laptop: Web, Email, SSH from NET

FW server: Web, SSH, DNS and Ping access from NET

FW server: Ping from LOC

NET laptop: Web from LOC

NET laptop: SSH, ping from FW


The required RULES for this configuration is:


# From the FW to LOC (service running)

Ping/ACCEPT $FW loc


# From the LOC to FW (services running)

Ping/ACCEPT loc fw


SSH/ACCEPT loc: fw

HTTP/ACCEPT loc: fw (webmin)

HTTPS/ACCEPT loc: fw (webmin)


# From the NET to FW (services running)

Ping/ACCEPT net $FW # allows pings into eth0 from NET

SSH/ACCEPT net $FW # we will close this & add port knock later

ACCEPT net fw icmp #


# From the FW to NET (services running):

Ping/ACCEPT $FW net




HTTP/ACCEPT $FW net # apt-get uses 80


# From the LOC to the NET (services running):

HTTP/ACCEPT loc: net


SSH/ACCEPT loc: net

FTP/ACCEPT loc: net

POP3/ACCEPT loc: net

POP3S/ACCEPT loc: net

IMAP/ACCEPT loc: net


SMTP/ACCEPT loc: net



# From the NET to LOC (internal servers PORT FORWARDING):

DNAT net loc: tcp 80 # web server


After restarting Shorewall, all connections, pings and Nmap tests are correct and netstat –nat confirms those from the LOC laptop:

An interesting point here is that the SSH session between the AP and LOC laptop shows the application running on the AP ( is Kermit, a Linux based utility, as the IOS is Linux.


All required connections I configured are working on the laptop:

The SSH connection to the FW


Web access from LOC:


The SSH session to NET AP


The services available on the Firewall from LOC


The services available on the Firewall from NET:


Web server and SSH available on LOC and FW from NET:


Shorewall Section Summary

There are many features that could be explored within this section, some of which I may come back to if I have time. Each small part of the process of the testing and configuration can spiral off to many other avenues of research and learning, the UDP topics were a good example, as it is an important area to understand as it relates to Firewalls, and probably overlooked by many Network Engineers and Admins as to the threats it potentially poses to systems because so many aspects of it are a difficult to define and control because it is "stateless" in the sense that it does not establish defined connections in the same way that TCP does, so is more intangible. I want to research this further here, but the overall project goals preclude this at this point.

The learning curve for this section steep, as it forces deeper understanding regarding what is going at a packet level, and learning different commands to enable relevant information to be viewed, to get a better understanding of the workings of different protocol traffic and how it can be manipulated by the Firewall to obtain desirable conditions that enhance security, as well as realising the difficulties Firewall designers face to achieve this, as dealing with the characteristics of the protocols themselves is complex enough let alone guarding against ways these can be used for malicious intent to penetrate a system.

The next section deals with another aspect of security, now that general traffic access and prevention by the Firewall has been "briefly" covered – but what can be done to control the content of traffic once it has been allowed? An easy example for why this may be required is to safeguard children from inappropriate material such as pornography or violence. Many ways have been devised to accomplish this without implementing a complete block of all traffic for a specific scenario.

Access Control and Content Filtering – SQUID and Dan's Guardian

proxy server

A proxy server acts as an intermediary between a network and the Internet - usually. It can be set up to access the Internet on behalf of a host, so disallowing direct web access. One advantage of this is it can cache copies of web pages locally, so save time and bandwidth for repeated requests for multiple users for the same page. It can be set up as an authorisation and logging central point, to limit access by privilege and time of day, for example, and allow or block access to particular sites to only some, all or no users. The most popular software used on Linux servers for this role is called Squid

traffic content filtering

A basic principle behind content filtering is comparison of the textual content of a traffic stream against dictionaries of defined words, then blocking access to the source on that basis. The software available for the Linux server I will be investigating for this is called Dan's Guardian.

I have mentioned them together as they work in conjunction with each other, but it is necessary for configuration reasons to install and test Squid first.

Squid Installation

Installation is from the command line as usual:

apt-get install squid


The configuration file for squid is way too large at 5000 lines long to read, decipher and edit without spending a lot of time working out the options, so it is easier and quicker to find pre-configured files on the Internet to learn from, rather than wading through the man file. It was noted that the default file has to be edited for squid to start initially though.

The original is backed up for reference and a new one created from the version found at with a much smaller configuration file was used to experiment with:


### Squid squid.conf


########### squid.conf ###########


## interface, port and proxy type

#http_port transparent



## general options

cache_mgr not_to_be_disturbed

client_db on

collapsed_forwarding on

detect_broken_pconn on

dns_defnames on

dns_retransmit_interval 2 seconds

dns_timeout 5 minutes

forwarded_for off

half_closed_clients off

httpd_suppress_version_string on

ignore_unknown_nameservers on

pipeline_prefetch on

retry_on_error on

strip_query_terms off

uri_whitespace strip

visible_hostname localhost


## timeouts

forward_timeout 30 seconds

connect_timeout 30 seconds

read_timeout 30 seconds

request_timeout 30 seconds

persistent_request_timeout 1 minute

client_lifetime 20 hours


## host definitions

acl all src

acl localhost src

acl to_localhost dst


## proxy server client access

acl mynetworks src

http_access deny !mynetworks


## max connections per ip

acl maxuserconn src

acl limitusercon maxconn 500

http_access deny maxuserconn limitusercon


## disable caching

cache deny all

cache_dir null /tmp


## disable multicast icp

icp_port 0

icp_access deny all


## disable ident lookups

ident_lookup_access deny all


## no-trust for on-the-fly Content-Encoding

acl apache rep_header Server ^Apache

broken_vary_encoding allow apache


## logs

logformat combined [%tl] %>A %{Host}>h "%rm %ru HTTP/%rv" %Hs %<st "%{Referer}>h" "%{User-Agent}>h" %Ss:%Sh

access_log /var/log/squid/access.log combined

cache_store_log /var/log/squid/store.log

cache_log /var/log/squid/cache.log

logfile_rotate 8


## support files

coredump_dir /tmp

pid_filename /var/log/squid/


## ports allowed

acl Safe_ports port 80 443

http_access deny !Safe_ports


## ssl ports/method allowed

acl SSL_ports port 443


http_access deny CONNECT !SSL_ports


## protocols allowed

acl Safe_proto proto HTTP SSL

http_access deny !Safe_proto


## browsers allowed

# acl Safe_browser browser ^Mozilla/5\.0.*Firefox/2\.0\.0\.6

# http_access deny !Safe_Browser


## disable ads ( )

# acl ads dstdom_regex "/etc/squid/ad_block.txt"

# http_access deny ads

# deny_info TCP_RESET ads


## Banned Sites

# acl Bad_Site dstdom_regex

# http_access deny Bad_Site


## redirector

# acl my_url dstdomain SITE_NAME.COM

# redirector_access allow my_url

# redirect_children 1

# redirect_rewrites_host_header off

# redirect_program /etc/squid/


## methods allowed

acl Safe_method method CONNECT GET HEAD POST

http_access deny !Safe_method


## allow replies to client requests

http_reply_access allow all


## header re-write

#header_replace Accept */*

#header_replace Accept-Encoding gzip

#header_replace Accept-Language en

#header_replace User-Agent OurBrowser/1.0 (Some Name)


## header list ( DENY all -> ALLOW listed )

header_access Accept allow all

header_access Accept-Encoding allow all

header_access Accept-Language allow all

header_access Authorization allow all

header_access Cache-Control allow all

header_access Content-Disposition allow all

header_access Content-Encoding allow all

header_access Content-Length allow all

header_access Content-Location allow all

header_access Content-Range allow all

header_access Content-Type allow all

header_access Cookie allow all

header_access Expires allow all

header_access Host allow all

header_access If-Modified-Since allow all

header_access Location allow all

header_access Range allow all

header_access Referer allow all

header_access Set-Cookie allow all

header_access WWW-Authenticate allow all

header_access All deny all


########## END ###########


The various components in this file are reasonably self explanatory, and lines that require change will be mentioned in more detail.

The shorewall RULES files is edited to allow HTTP access on its default port of 3128:

# From the LOC to the FW:

ACCEPT loc fw tcp 3128 # squid


For now squid is started with "/etc/init.c/squid start" and any configuration errors can be identified as part of getting familiar with the configuration file.

"/etc/init.c/squid start"

To see if squid is available on the Firewall, nmap is run:

A browser is opened and configured to access the web via a proxy server via the Tools/Connection Tab/LAN Settings in Internet Explorer and set to Squids default port 3128:

A web conection can now be attempted:

It seems Squid needs to be allowed NET access in the RULES file to cross the Firewall, but Squid itself is working and generating this ERROR page.

Comments are closed.

Post Navigation