TCP/IP Overview and Vulnerabilities
We shall examine, in some detail,
aspects of the widely deployed TCP/IP internetworking suite that make it
vulnerable to attack.
While the TCP/IP suite works extremely well in practice,
it is the 'trusting' nature observed in the suite's history and
evolution that has recently exposed it to attackers.
We need to examine each of the four layers of the TCP/IP suite to locate
its potential vulnerabilities:
- application layer protocols,
such as telnet, FTP, HTTP, and SMTP, run on (possibly remote) machines to
which attackers may not otherwise have physical access.
On a case-by-case basis,
each of the application services may need to authenticate its remote
client, and may use local operating system authentication to perform this,
or (dangerously) employ its own mechanism.
Individual applications offering the networked services
are themselves also vulnerable - they may have been poorly written
(coded), exposing them to attacks which makes them perform in a manner
outside of their expected domain.
- transport layer protocols,
primarily provided by the reliable, streaming transport control
and the user datagram protocol (UDP) meet the data delivery
requirements of most Internet applications.
However, their very design introduces vulnerabilities,
because applications and operating systems expect the protocols to
perform in certain ways.
Incorrect interpretation (coding) of protocol RFCs,
or attacks against well known sequences of actions in protocols,
makes them perform not as expected,
or not at all.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p1, 20th May 2020.
TCP/IP Overview and Vulnerabilities, continued
Examining each of the four layers.....
In combination, we have multiple points of vulnerability
in the network protocols themselves.
This is before we consider that the network makes hosts more
vulnerable to remote attack.
In addition, each operating system's implementation of the TCP/IP stack
has its own idiosyncrasies.
Specifically, each operating system responds
differently to a variety of malformed packets.
Software performing protocol fingerprinting determines
an operating system from the way it 'appears' externally.
- the Internet layer protocols primarily consist of the
Internet protocol (IP),
and the Internet Control Message Protocol (ICMP) provide the
actual routed delivery of messages between source and destination,
and provide only a basic network management function by reporting
any observed errors.
IPv4, particularly, is vulnerable to attack and may be exploited to
not deliver messages,
deliver messages to the wrong destination,
or 'confuse' a destination to the extent that it may stop providing any
IP datagrams may be transmitted from one (attacking) host
while claiming to be from another,
and forged ICMP messages may make a destination network or host
- physical layer protocols are not strictly part of the TCP/IP
suite, but define how packets or frames are received via hardware,
and provided to the IP (software) layer above.
By its nature,
interface hardware must see all packets destined for,
or passing by,
and most hardware may be configured by software (the operating system) to
report all activity seen.
on a shared network,
an operating system (and probably some of its programs) may capture all
packets that are visible on a network.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p2, 20th May 2020.
Most computer networks consist of many personal computers or workstations
connected via a shared local area network (LAN and WLAN) segments.
Sharing, of course, means that computers
can receive information that was intended for other machines.
To capture the information traversing the network is termed sniffing.
The most popular form of local LAN topology,
Ethernet, works by transmitting addressed packets via a shared cable.
The Ethernet network interface card (NIC) in the intended destination
computer sees all packets,
but on seeing one with the NIC's unique 48-bit address,
the NIC will copy the entire packet to the operating system software for
analysis and eventual delivery to application programs.
There are two main problems with Ethernet's approach:
- most Ethernet NICs can be placed in promiscuous mode,
which results in all observed packets being sent to the operating system,
Many rootkits will replace the ifconfig program
(an abbreviation for interface configuration)
root> ifconfig eth0 promisc
root> ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:90:27:62:58:84
inet addr:184.108.40.206 Bcast:220.127.116.11 Mask:255.255.0.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
to avoid the simple detection of interfaces in promiscuous mode.
- and, most Ethernet NICs permit their NIC address to be modified,
and so one Ethernet NIC could (accidentally or deliberately) be given the
MAC address of another.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p3, 20th May 2020.
Packet Sniffing, continued
A variety of hardware and software tools are termed packet
Typical uses of such programs, both practical and sinister, include:
- Packet sniffer - originally a trademark of Network Associates,
denotes any hardware or software tool that can capture packets from the network,
by setting a node's Ethernet card to
report all packets to the system/application regardless of the packet's
destination MAC address.
- Network analyzers - tools that monitor network traffic and
devices with the goal of alerting the network manager of problems
(too much traffic, failed responses from known devices, IP address
- Protocol analyzers - tools that capture network packets,
providing some level of formatting for those packets,
allowing the user to analyze/visualize packets post-hoc.
- Automatic sifting of clear-text passwords and usernames from
Used by attackers to break into active accounts, and remote systems,
- Conversion of data to human readable format so that people can
read the traffic,
- Fault analysis to discover problems in the network, such as
why computer A can't talk to computer B,
- Network intrusion detection in order to discover attackers, and
- Network traffic logging, to create logs that attackers can't
break into and erase.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p4, 20th May 2020.
TCP/IP port scanning
Using port scanning an attacker tries to identify,
which services are supported from a potential target host.
Whenever an active port
is located, an attacker may
attempt to further determine the version number of any active server/service.
Although port-scanning software such as nmap may be used,
much of the information about active ports can be
determined by a simple tool like telnet as well.
What information does an attacker learn from port scanning?
For example, the naive TCP Connect Scan
completes the TCP three-way-handshake.
A SYN packet is sent to the system and if a SYN/ACK packet
is received, it is assumed that the port on the system is active.
If a RST/ACK packet is received,
it is assumed that the port on the system is not active.
Attackers may further attempt to hide their scans by:
- if an attacker learns that a port is open,
they can actually connect to the detected port.,
- if an attacker learns that a port is closed,
they learn that no service is listening to that port,
- additionally, some scanning software reports ports as
indicating that a connected attempt was terminated with a RESET
or timed out.
- scanning through ports very slowly,
and certainly not in numercial order - unless on a very quiet system,
these will not be detected.
- perform hundreds of scans simultaneously from hundreds of
random/spoofed IP addresses.
The target host will know they are being scanned, by not from where.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p5, 20th May 2020.
Stealth port scanning
Stealth scanning involves searching for open ports,
but without actually creating a connection.
Half-open scanning only performs the first part of TCP/IP handshake.
It sends a SYN flag and awaits a reply -
a reply with the SYN flag set reports an open port,
with the RST flag set reports an inactive port.
Half-open scanning is favoured by potential attackers
because (by default) nothing is logged.
Stealth scanning determines a port's status by sending different
combinations of TCP options.
according to RFC-793 a conforming TCP/IP stack should:
Implementing a stealth scan detector requires kernel-level programming.
We need to detect obvious signatures such as:
- send back a RST packet
when they receive a FIN packet for a specific closed port
(the TCP FIN Scan),
- send back a RST packet
when they receive a FIN/URG/PUSH packet
(TCP Xmas Scan), and
- send back a RST packet for all TCP ports closed when
they receive a packet without any IP flags set
(TCP Null Scan).
Even with IP spoofing, naive attacks may themselves leak information,
such as a correct TTL field indicating the distance to the attacker.
- several packets from the same source address to different destination
ports within a short period of time,
- connection attempts that are not completed
with a certain timeout, or
- a SYN to a non-listening port.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p6, 20th May 2020.
Internet protocol (IP) spoofing
The spoofing of IP packets allows an intruder on the
Internet to effectively impersonate a local system's IP address.
In general, IP spoofing and related attacks are possible
because programs (maybe requiring superuser access)
can open raw sockets, create, and send malformed IP packets.
An attacker uses source address spoofing for two reasons:
Note that some of these attacks employing these mechanisms are possible
even when no reply/response packets can be routed back to the attacker.
If other local systems perform simple session authentication based on
the IP address of a connection
(e.g. an rlogin with .rhosts
or /etc/hosts.equiv files under Unix),
they will believe incoming connections from the intruder
actually originate from a local 'trusted host'
and may not request a password.
Other services, such as the Network File System (NFS),
Server Message Block (SMB), and TCP wrappers all include
the source address (or system name, in the case of NFS) as part of
the access control checks.
It is possible for forged packets to penetrate firewalls based on
packet-filtering routers if the router is not configured to block incoming
packets with source addresses in the local domain.
- to gain access to resources that only accept requests from
specific source addresses, or
- to hide the source of an attack by directing the blame at others.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p7, 20th May 2020.
UDP Packet Spoofing
The User Datagram Protocol (UDP, RFC-768) is a lightweight
transport protocol built on top of IP.
UDP achieves extra performance from IP
by not implementing some of the session-based features
a more heavyweight protocol (like TCP) offers,
and typically sees twice the throughput.
An attacker may attack a UDP service because of these
properties - the attacker is unconcerned about reply packets.
the Network File Service (NFS) employs UDP to 'import' and 'export'
to write, delete, or change file attributes are atomic,
and can fit in a single UDP packet.
Replies only return a simple OK and status.
A poorly configured system
may permit NFS-based files to be visible to external hosts.
An attacker may employ IP source spoofing over UDP,
to modify or delete a file.
At the same time,
an attacker may also spoof their own source addresses in attacks where
reply packets are not important.
The attacker does not care about the OK response!
- UDP allows individual packets to
be dropped (with no retries),
- packets may be received in a different order than sent, and
- applications using UDP,
typically, do not establish a protocol-level session with their peers.
Each request and reply pair are often independent.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p8, 20th May 2020.
TCP/IP Sequence Number Attacks
We'll consider a representative problem with TCP/IP by examining
how TCP/IP establishes sessions between endpoints.
A three-way handshake is employed in the TCP open sequence.
If machine A wishes to establish a connection with machine
A transmits the following message:
This initial packet request has the synchronize sequence number
bit (SSN) set in its header,
and an initial 32-bit unsigned sequence number ISNa.
B replies with:
to provide its own initial sequence number, ISNb,
and to acknowledge ISNa.
A will finally acknowledge ISNb with
B->A : SYN, ISNb, ACK(ISNa)
and the connection is established.
This session establishment is considered secure,
provided that the initial sequence numbers are so random that they cannot
If strictly conforming to RFC-793,
each TCP/IP implementation is expected to employ its sequence number
as a 32-bit counter, modified every 4usec.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p9, 20th May 2020.
TCP/IP Sequence Number Attacks, continued
Traditional BSD-derived implementations only change the 2nd byte
of the sequence number every second,
and each new connection changes it by 64.
having established a valid connection,
is able to 'guess' the next number to be used.
A series of well known attacks exploit the non-randomness of
the initial sequence numbers.
The attacker, C, establishes a valid connection with B,
thus determining one of B's 'current' values for
The attacker, C, now impersonates A by sending a packet to
but by setting A's NIC address in the Ethernet packet:
B replies with
to the true machine A.
C will probably not see this message B->A,
but can guess the value of ISNb*.
C now sends
B->A : SYN, ISNb* , ACK(ISNc)
and B believes that it has a valid connection with A.
A is confused as to why it received B->A,
and may choose to ignore it, or inform B (with a RESET
packet) that something is amiss.
If A chooses to ignore the packet B->A,
then C can continue to send packets to B,
assuming A's identity.
If C can see all replies from B->A in the session,
then C can fully masquerade as A,
while A ignores the transmissions of which it is not a part.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p10, 20th May 2020.
Denial of Service (DoS) Attacks
Denial of service (DoS) attacks using source address spoofing became
popular in 1997, using tools to send thousands of
packets to a target system.
A denial of service attack is characterised by attackers'
explicit attempts to prevent or delay legitimate users from using a service.
Examples include :
Often, the source address of these packets is spoofed,
making it difficult to locate the real source of the attack.
- attempts to flood a network,
thereby preventing or delaying legitimate network traffic,
- attempts to disrupt connections between two
machines, thereby preventing access to a service,
- attempts to prevent a particular individual
from accessing a service, and
- attempts to disrupt service to a specific system or person.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p11, 20th May 2020.
The smurf DDoS Attack
In the smurf DDoS attack,
the attacker provides a spoofed source address,
when sending an ICMP echo, or ping,
to an IP broadcast address as the destination
(The name smurf was adopted after the name of the blue cartoon
characters who tended to flood into all locations) :
The smurf attack has 3 types of victims:
The use of broadcast addresses for protocol attacks is termed
- the attacker sends ICMP Echo Request
packets where the source IP
address has been forged to be that of the target of the attack.
- the attacker sends these ICMP datagrams to addresses of remote LANs'
broadcast addresses, using so-called directed broadcast addresses. These
datagrams are thus broadcast on the LANs by the connected router,
- all the hosts which are alive on the LAN each pick up a copy of
the ICMP Echo Request datagram, and sends an
ICMP Echo Reply datagram back to what they think is the source.
- the attacker can use large packets
(typically to the Ethernet 1500 byte maximum)
to increase the effectiveness of the attack.
One way to defeat smurfing is to disable IP broadcast addressing at each
internal network router,
however this strictly violates RFC-1812,
'Requirements for IP Version 4 Routers'.
- the single destination victim of the attack,
- a network abused (temporarily) to amplify the attack, and
- (always) the host harboring the attacker.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p12, 20th May 2020.
The SYN-Flood Attack
We recently saw how the standard
TCP/IP session establishment sequence may be used by an attacker
to establish one half of a valid connection with a target system.
However, an attacker may choose the SYN-Flood,
or half-open, attack:
Fast TCP session establishment is considered vital,
but operating systems allocate only a small number of these 'half-open'
sockets, before running out of resources.
The release of these incomplete 'half-open' sockets is slow (30secs),
and so an attacker can quickly exhaust the supply of buffers
which are pre-allocated.
To avoid SYN-Flood attacks,
modern operating systems will now not employ
large number of 'half-open' sockets for new connections.
Instead, they will encode and save the opening details
(such as the client's IP address) as a 32-bit number,
and use this as the initial sequence number in the SYN/ACK reply.
Only if the final ACK reply returns,
will socket resources be allocated.
- the attacker (client) sends a SYN request to the server,
- the server records the request on a queue of connections waiting to
complete, replies with a SYN/ACK packet,
and eagerly awaits the final ACK reply.
- however, the attacker does not send the ACK reply.
Instead, the attacker sends another, actually hundreds of,
SYN requests with different source forged address.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p13, 20th May 2020.
Distributed Denial of Service (DDoS) Attacks
In a distributed denial of service (DDoS) or a packet
an attacker will flood a single system with 'junk' packets to consume
bandwidth - preventing legitimate packets getting through.
Using only a single attacker, the effect of the attack is
greatly multiplied using attack servers termed agents,
zombies, daemons (in the trinoo attacks)
and servers (in the TFN attacks).
Attacks are launched simultaneously from hundreds of 'remote-controlled'
The attacker must first gain access to the hundreds of agent machines,
but will use scripts to locate many machines with the same vulnerability.
A single trojan program will typically be installed on each of the agent
machines, and triggered days or months later by a single UDP or
ICMP packet to the agent.
All agents will then launch their attacks,
using source spoofing, on a single target.
The increased use of ADSL and 'always on' connections,
increases the opportunity of DDoS attacks.
Reading (well over a thousand technical, historical,
legal, and societal articles on DDOS attacks).
On Feb 7 2000 a distributed denial of service (DDoS) attack
crippled Ebay, Yahoo!, CNN, Datek, E*Trade, ZDNet and several
other Web sites for several hours.
RFC-2267 was written in response to this type of attack,
suggesting that ISPs should filter traffic and drop any packets with spoofed
source addresses. In practical terms, this has proven difficult.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p14, 20th May 2020.
Security at Network Boundaries
Whereas many forms of network-based attacks can come from within
our own LANs,
the greatest opportunity is provided to an attacker
who connects to the LAN from the wider Internet.
Attacks from the Internet can, of course, attempt to bypass the
user- or system-level security of a single machine,
or possibly undertake a denial-of-service attack on the LAN itself.
In general, we wish to develop security practices at the
boundary between a LAN and the wider Internet,
to constrain the types of network traffic that may cross the boundary.
Specifically, we would like to:
We may have political and administrative control of 'both ends' of
a permitted connection,
but require that connection's traffic to cross the 'unfriendly' Internet.
- control network traffic based on both senders' and receivers'
network (IP) address,
- control network traffic based on requested services (IP ports),
- not expose our LAN topology to the wider-Internet,
hiding hostnames, addresses, and available services,
- constrain some network traffic based on its content,
- only permit internal access from remote users and services,
based on their verified identities and (possibly) location, and
- log all Internet connections, attempts, and (suspect?) traffic.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p15, 20th May 2020.
Packet filtering at network boundaries
Like most texts, we shall use the term firewall
to describe any
network device, appliance, or specially configured computer which protects
the boundary of an internal network.
we shall describe firewalls as software devices through which all
network packets must pass, both incoming and outgoing.
Providing a single ingress point to an internal network clearly provides a
single opportunity to apply a consistent policy to all network traffic.
The practices of:
often circumvent the purpose or effectiveness of having a firewall.
with which a computer can access the Internet without passing its traffic
through the firewall (for example, with a modem or wireless connection), and
- traffic tunneling,
with which users or applications can embed certain types of unwanted
network traffic within permitted protocols
(for example, uploading a complete file via a web-based CGI program
on a host not permitting HTTP's POST command),
 The origin of the term firewall is variously
described in texts,
including the iron plates separating train-drivers from the firebox,
car drivers from the engine,
and even the walls of castles,
from which arrows were fired through narrow slits.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p16, 20th May 2020.
Packet filtering at network boundaries, continued
Depending on the provided bandwidth to and from an internal network,
e.g. from home over a modem and PPP (56Kbps, 100 packets/sec),
or an ADSL or (now) NBN router (3-100Mbps, 250,000 packets/sec),
a firewall may be:
Because a traditional computer, acting as a firewall,
must inspect each packet entering and leaving the internal network via a
number of different network interfaces
(for example, modem, wired-Ethernet, wireless-Ethernet),
they must implement and respond to security policies as quickly as possible.
Such requirements usually place the responsibilities in the
operating system kernel,
with user-level programs used to set, modify, and enquire
about the current state.
This is in contrast to popular 'personal firewall' software for
home computers -
generally user-level programs to which an operating system
passes packets for inspection.
Such personal firewall programs,
often driven by GUI-based software,
run more slowly.
- part of a traditional, single, workstation (protecting itself),
- a computer or device protecting several other workstations, or
- a dedicated device doing nothing else but protecting other hosts.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p17, 20th May 2020.
Possible packet filtering criteria
Network packets may be filtered on a number of criteria,
such as their routing properties (for IP and ICMP),
and transport and service properties (for TCP and UDP).
By examining the headers of TCP/IP traffic,
we can detect obviously falsified traffic:
- filter on each IP packet's source address.
Packets which arrive on a network interface connected to the
outside of our internal network (i.e. the Internet)
and announce their source address as being from the internal network,
probably have spoofed source addresses.
- filter on each IP packet's destination address.
Packets destined for an internal network address should not leave the
network via an external interface.
- filter based on specific low-level routing or transport protocols,
such as denying all ICMP or UDP traffic from leaving,
- filter based on application protocols, such as permitting HTTP and
FTP requests to leave, but not permitting NFS mount requests to enter, and
- filter based on recent activity.
Stateful filtering (or stateful inspection)
has knowledge of recent traffic;
for example, stateful FTP filtering permits an incoming
FTP data-connection request, only if a corresponding outgoing
control-connection already exists.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p18, 20th May 2020.
Developing a Firewall Policy
The establishment of a firewall policy simplifies the practice of
deciding what traffic to permit and what to filter.
Moreover, a consistent, and consistently applied,
policy is a strong argument by system administrators to deny individual
requests for new small holes in the firewall by individuals.
Surprisingly the 'firewall community' is divided on default behaviours.
There exists a clear balance between security and user freedoms,
and for many organizations (e.g. freedom-loving universities)
there is often no simple answer.
it is unwise (ignorant)
to consider that an attack on external hosts and
networks could not be launched from within your internal network.
For this reason, conventional wisdom says we should have mirrored denial
policies filtering traffic leaving our networks.
- 'that which is not expressly forbidden is permitted', or
- 'that which is not expressly permitted is forbidden'.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p19, 20th May 2020.
Packet filtering with iptables
iptables is currently considered the state-of-the-art in
programmable firewall software,
recently replacing similar, but deficient, software named
ipfw and ipchains.
iptables is very similar to earlier software,
but also provides stateful control over network traffic.
iptables actually consists of two software components:
Some informative block diagrams:
the iptables software provides a variety of mechanisms to
perform network address translation, and
to mangle packet headers.
Three rule tables,
named filter, nat, and mangle,
are employed to perform these functions.
Each table of rules has a number of built-in rule chains (or lists),
which provide sequences of rules to be 'evaluated',
until it is decided what should happen to an individual packet.
The standard filter table provides default chains named
INPUT, FORWARD and OUTPUT,
and we'll initially focus on these.
- the iptables application program, controlling the set of
rules and policies to be enforced, and
- netfilter software configured as part of an operating system
kernel (compiled into the kernel)
to control IP traffic on several network interfaces.
The netfilter modifications have a long history from BSD Unix,
and support both IPv4 and IPv6 protocols,
including IPsec encrypted protocols.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p20, 20th May 2020.
Packet lifetimes using iptables
Consider the 'lifetime' of a single packet as it enters and traverses a
this generic approach permits the iptables software to act on a
single workstation with a single network interface
(such as an ADSL router link)
or as a specific firewall device with several (Ethernet) network
interfaces protecting a whole internal network.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p21, 20th May 2020.
An introduction to filtering rules
We will follow the development of filtering rules for a simple
(home) computer with a single network interface.
Initially, we'll just consider packet filtering.
define the internal and external networking interfaces
that we have,
flush any existing iptables rules for the
and define the default policy for each chain:
/sbin/iptables -t filter -F
/sbin/iptables -t filter -X
/sbin/iptables -t filter -P INPUT DROP
/sbin/iptables -t filter -P FORWARD DROP
/sbin/iptables -t filter -P OUTPUT DROP
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p22, 20th May 2020.
An introduction to filtering rules, continued
We'll next create a new rule-chain of named rules in
the filter table.
These can be considered as similar to a method, or procedure,
of new rules to be evaluated under certain conditions.
We then append individual new rules to this named rule-chain:
In addition, we can decide how to manage individual packets based on the
protocols (TCP, UDP...) being used,
or the services (ports) requested:
/sbin/iptables -t filter -N myrules
/sbin/iptables -t filter -A INPUT -j myrules
/sbin/iptables -t filter -A FORWARD -j myrules
We also wish to log all packets that our firewall drops,
but we don't wish an attacker to flood our machine's logfiles:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
These details are logged via the standard syslogd mechanism.
iptables -t filter -A INPUT \
-m limit --limit 15/minute \
-j LOG --log-prefix "suspicious, dropped"
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p23, 20th May 2020.
Examining packets on specific interfaces
we'll now omit the use of the -t filter options,
as the filtering table is the obvious default.
In each of these examples, we append some specific rules to our
named chain myrules:
- accept existing, established, connections arriving over the external
iptables -A myrules -i $EXT -m state \
--state ESTABLISHED,RELATED -j ACCEPT
- permit (we say ACCEPT)
new packet sequences to leave our machine if
they have not come from the external interface
(i.e. they are from the internal interface, or from local processes):
iptables -A myrules -i ! $EXT -m state --state NEW -j ACCEPT
- do not permit (we say DROP) new packets,
or ones with invalid option bits in their headers (such as the XMAS
port-scan), that arrive via the external interface.
In addition, we log the details before the packet is dropped:
iptables -A myrules -i $EXT -m state \
--state NEW,INVALID -j LOG --log-prefix "dropped"
iptables -A myrules -i $EXT -m state \
--state NEW,INVALID -j DROP
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p24, 20th May 2020.
IP masquerading or network address translation (NAT)
is a technique employed within a firewall,
or border gateway,
to translate, or map,
one set of IP addresses (usually private) to another (usually public).
To use NAT, the firewall connecting the internal LAN to
the external Internet will have
(at least) two network cards, each with their own IP address:
The primary motivations for using NAT are:
- on the Internet side,
the machine will use a fully-routable address assigned by an ISP.
- on the LAN side,
it will have an address from the non-routable addresses,
defined in RFC 1918 'Address Allocation for Private Internets':
- your network provider may only provide you with
a single IP address to use -
NAT permits multiple hosts to use the same IP address,
- it simplifies the later growth and re-design of a network, and
- external attackers cannot (easily) learn the topology of your internal
network unless they penetrate your firewall.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p25, 20th May 2020.
An Example of IP Masquerading
Consider the following example:
(with a single Ethernet interface, and IP address 192.168.3.10)
generates a packet,
from its port 400,
destined for server.com.
When the packet arrives at the NAT-enabled firewall
(on its internal Ethernet interface, IP address 192.168.3.1),
the firewall will de-encapsulate the packet,
and rewrite it so that it appears to have now originated
from the firewall itself
(with IP address 18.104.22.168, and a currently unused port on the firewall, 1430).
The packet is finally forwarded on the external Ethernet
When a reply is received from server.com,
its destination IP address will be 22.214.171.124, port 1430.
The firewall's mapping table is consulted to reverse the translation,
changing the IP address to 192.168.3.10 (for blue), port 400.
||Firewall's assigned port
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p26, 20th May 2020.
Network Address Translation (NAT)
NAT, as described in RFC1631, has many forms:
- overloaded NAT - maps multiple unroutable
IP addresses to a single registered (routable) IP address by using
different ports (as just seen).
This is variously known as PAT (Port Address Translation),
single address NAT or port-level multiplexed NAT,
- dynamic NAT - maps an unroutable IP address to one of
a managed group of registered IP addresses, and
- static NAT - maps an unroutable IP address to a
registered IP address on a one-to-one basis.
This is required when a device needs to be accessible from
outside the network, such as a web- or FTP-server.
Supporting NAT with iptables
iptables supports NAT very simply.
Consider a home system with a ppp external connection,
and an Ethernet internal connection:
iptables -t nat -P PREROUTING DROP
iptables -t nat -P POSTROUTING DROP
iptables -P FORWARD DROP
# NAT everything heading out the external interface
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 \
-o $EXT -j SNAT --to-source $PPP_IP
#This enables ip forwarding, and thus by extension, NAT
echo 1 > /proc/sys/net/ipv4/ip_forward
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p27, 20th May 2020.
Connection tracking refers to the ability for a firewall
to maintain state information about connections -
source and destination IP address and port number pairs
(known as socket pairs),
protocol types, connection state and timeouts.
Firewalls able to do this are termed stateful.
Stateful firewalling is inherently more secure than
its 'stateless' counterpart - the simple packet filtering
commonly seen in most 'personal firewalls'.
Consider an candidate packet arriving on an external interface:
To support connection-tracking for valid TCP traffic,
in iptables, we employ the state-tracking module:
- if the packet matches an entry already recorded
in the firewall's state table,
the packet is part of an ESTABLISHED connection,
- if the packet is ICMP traffic it might be RELATED
to a UDP/TCP connection already in the state table,
- the packet might be attempting to start a NEW connection, or
- it might be unrelated to any connection, we say INVALID.
Under Linux we can see how many connections may be tracked
and can see the connections from
iptables -A INPUT -p tcp -m state \
--state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -m state \
--state NEW,ESTABLISHED -j ACCEPT
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p28, 20th May 2020.
Tracking FTP Connections
FTP transfers show the power of connection tracking.
We can easily access a remote FTP service,
and its control-channel:
But that is not the whole story:
we must also permit, seemingly 'random' connections to our FTP client's
data-port as well.
Our FTP client sends its temporary port number over the FTP control-channel
via a PORT command to the remote FTP server,
which then connects from its port 20 to our specified port to send data,
such as a file, or the output from a DIR request.
iptables -A OUTPUT -p tcp --dport 21 -m state \
--state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 21 -m state \
--state ESTABLISHED -j ACCEPT
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p29, 20th May 2020.
Tracking FTP Connections, continued
To allow active FTP
we may consider a general rule allowing
connections from port 20 on remote FTP servers to high ports
(port numbers > 1023) on our FTP clients.
However, this is too general to be considered secure,
as remote attackers (who may be able to see our FTP PORT packets)
may attempt to quickly connect to our nominated ports.
To solve this, (stateful firewalls, such as)
iptables supports the specific
ip_conntrack_ftp (dynamically loaded) module,
which recognizes the PORT command and locates the port number
(requiring parsing of the payload):
The FTP-data connection between our clients and the remote server
is now classified as RELATED
to the original outgoing connection to the remote port 21 -
we don't need NEW as a state match.
iptables -A INPUT -p tcp --sport 20 -m state \
--state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 20 -m state \
--state ESTABLISHED -j ACCEPT
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p30, 20th May 2020.
Most organizations have a single firewall,
in hardware or software.
They hope that the firewall is not breached,
and that an attack is never launched from within.
However, both of these threats should be met by installing
multiple firewalls within an organization -
variously known as
internal firewalls, or
A large organization will contain a number of departments
whose information should not be seen from the wider Internet,
nor from other departments.
The internal network should be divided based more on the vulnerability of
systems and criticality of data, than on the department's name.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p31, 20th May 2020.
Intraorganization Firewalls, continued
Here, multiple firewalls are used to prevent a security breach spreading
through the organization.
Different administrative controls (people and passwords)
can manage each firewall.
Although all responsibilities could have been placed on the single
Firewall #1, we see a number of advantages:
- each firewall's rules will be simpler and less error-prone,
- each firewall has to handle less traffic,
particularly the Corporate Firewall,
which now only manages traffic to and from the Internet,
- only certain hosts in Finance may access the mainframe computer
(via Firewall #2), and
- new software products being developed in the R&D Test Lab
will not 'leak' into the internal network (via Firewall #3).
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p32, 20th May 2020.
A DeMilitarized Zone (DMZ) Subnet
We have also introduced a DeMilitarized Zone (DMZ) subnet -
a network segment where publicly-accessible servers are placed,
such as a company's web-server, or FTP-server.
The DMZ is neither really inside nor outside the corporate network.
A number of important decisions have been made in this setup:
- a very limited set of protocols may enter the corporate network,
probably only SSH and SMTP (email),
and their packets are only destined to specific hosts,
- each service in the DMZ has its own public server (hardware),
minimizing disruption if there's an attack
(we may also want to protect the DMZ from the internal network!),
- servers in the DMZ have their own disks containing data which may be
exposed to the Internet.
While this data may be defaced via an external attack,
it may be replaced by copies held on the internal network,
or even only served from read-only media,
- we have an external Domain Name Server (DNS) server,
mapping host names to (routable) IP addresses.
This only reports (to the Internet) the hosts on the DMZ subnet,
and does not reveal the names nor addresses of internal hosts,
- we have an internal DNS server as well,
which reveals internal hosts names only to the corporate network,
- we have internal email and FTP servers.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p33, 20th May 2020.
Virtual Private Networks and IPSec
A Virtual Private Network (VPN) enables secure communication
between users of two networks separated by a shared, untrusted, public network.
In its simplest form,
a VPN may simply consist of a security gateway
at the network border between each of the communicating networks and the
Each gateway employs tunnelling of protocols.
The gateways address packets to each other using the standard IP addresses
as tunnelling address.
Embedded in the data/payload of the packet is another full IP packet.
In this case the embedded addresses are for the (original) source and
Packets entering the
untrusted network (Internet) may also be encrypted by the sending VPN gateway,
decrypted by the receiving gateway.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p34, 20th May 2020.
The Security Case for Virtual Private Networks
Virtual private networks are described in literature as providing a
variety of benefits:
Not all VPN products, in either hardware or software,
will offer all services;
often encryption of each packet's payload is not (by default) provided.
Any security that requires a depth of understanding by a casual end-user
is likely to be bypassed.
In the case of VPNs, only each network administrator need understand the
technology in order to create a secure environment.
VPNs are not end-to-end (process to process) streams;
consequently, they are not substitutes for many other forms of security,
such as the secure sockets layer (SSL) libraries.
- Authentication -
a useful VPN can guarantee that data has come from the point of origin it
claims to have arrived from.
- Confidentiality -
A VPN should protect data while it is in transit,
thwarting packet sniffers.
- Integrity -
A VPN should be able to guarantee the data payload has not been tampered
with while in transit.
- Protection from insertion and replay -
A VPN should be able to ensure that data or information can only be sent once.
This is particularly the case with regards to financial transactions and
in preventing denial of service attacks.
CITS3002 Computer Networks, Lecture 11, Security of TCP/IP, p35, 20th May 2020.