Gone are the days when we could live our lives without the Internet.
It became our “go to” place when looking for fun, information or business.
But there are also nefarious actors on this largest computer network.
Their goal is often gaining access to information, damaging systems
and (most importantly) penetrating into systems with the intention
to gain control and use them as a launching pad for further activities.
There are no commands int this article that will secure your computer
nor information about NAT (hiding a computer network behind one IP address),
but you will find here information that will (hopefully) help you
to understand how such protection may work.
One of the defense lines against such attackers are firewalls. This word is composed of word “fire” and “wall” – it is a wall that we can place between us and the attackers out there, that are trying to damage our systems or networks. In the following paragraphs, I’ll describe principles that are the basis of IP firewall. such as the one we can find in Linux kernel.
Communication in computer networks is a relatively complicated topic and for that reason, it is broken into several levels. The levels are arranged in a stack and each level takes care of a different
an aspect of the task. Near the bottom of the network, the stack is IP protocol. This protocol takes care of delivering the information – whatever it can be – from one computer to another.
IP protocol is described in RFC 791. In this document, we can find the description of sending blocks of data across the network. These blocks are called packets and consist of a header and the transferred data. The header has following structure:
Request and replyTypical firewall works by examining the individual parts of the IP packet’s header and based on that making a decision whether to let the packet through (to the application
or modules, that handle forwarding packets to other networks) or discard the packet. Typical communication in the network works so, that one computer (let’s call it Centaur) sends a packet request to and another computer (let’s call it Sirius). Sirius receives the packet, processes it and generates a packet with the answer back to Centaur. Request and response may, of course, also consist of multiple packets. The important point is that in order for the request to arrive at Sirius, the request has to contain information who is the recipient of the request (where should the packet be delivered) – Destination address. In order for Sirius to know who sent the request and where to send the response the packet with the request also has to contain information who sent the request – the Source address. When Sirius creates the answer he is becoming a sender of the packet and the originator of the request – Centaur, is becoming the destination. That means that in the request packet the source and destination addresses are swapped compared to the response packet:
So the first thing that can be used for filtering is the source and destination IP address.
Filtering by IP address
- From the packets coming to our system, we let in only those,
that are originating from a trusted source. For example, if we use a DNS server,
that is on the other side of the firewall as our system, then DNS responses
should be let in only if they are coming from this DNS server. There is
no reason to let in DNS packets originating from some other DNS server.
Similarly, if we need to allow access from branch office over ssh,
we can allow only ssh IP packets from the IP address of our branch office.
(For that reason it is a good idea for our branch office to have a static
IP address and not dynamic).
- We can also apply egress filtering – any packets leaving our network
can be let through only if they are supposed to. For example, if we
have a SMTP server on our network, then we should let out SMTP
packets only if they have our SMTP packets as the source address.
If an attacker gained control of workstation of Janice in accounting
and plans to use it for sending out spam, our firewall should
not let such connections out.
Further filtering depends on the type of the protocol, that is carried inside of the IP packets. For that reason I’ll for a moment diverge from the topic and describe how incoming and outgoing the packets look like. The list of protocols and their numbering can be found in file
/etc/protocols. In practice you will mostly meet following:
- This protocol is used by programs such
tracerouteto transfer information about reachability
and connectivity of systems.
- This protocol transfers relatively small blocks of information
or packets for which the ordering is not important.
Services using this protocol are called
As an example, the DNS (Domain Name Service) is or NTP (Network Time Protocol)
are based on UDP.
- This protocol provides service called
connection oriented services.
It provides the functionality of recovering lost packets, guarantees
to keep the order of packets etc. TCP is the basis for much well-known
protocols such as HTTP, FTP, SSH, TELNET, POP3, SMTP etc.
ICMP packets contain an information about ICMP-type. It is nothing unusual that the packet with one type is replied with a packet with a different type. For example, ping works so, that our machine sends a request with ICMP-type
echo. The target system responds with a packet with an ICMP-type
echo reply. The traceroute program sets the field TTL (Time To Live) in the outgoing packets. This field is decremented by each router along the path. The router that decrements the value to zero discards the packet (does not forward it to the destination) and sends us back an ICMP packet with type
time-exceeded. This allows discovering which routers are traversed when sending a packet from us to some other machine.
We can receive ICMP packets even if we did not send the request in with ICMP. This situation happens for example when we are trying to open a connection using some other protocol, but the remote server is down. In such case, the last outer lets us know by creating an ICMP packet with
host-unreachable. If the router does not even know how to deliver the packet to the right network, it can send us a message with
network unreachable. A system that can be reached but cannot accept our packet (does not talk the protocol that we asked for) it can answer with ICMP packet
From the previous paragraphs about ICMP, it is apparent, that we should filter ICMP packets because it allows the attacker to learn about the structure of our network. On the other hand, we need to let in some ICMP packets in order to learn about unreachability of other servers. Outgoing ICMP packets can be filtered if we do not need to verify connectivity using ping or traceroute. We can also filter information about the reachability of some of our servers and services.
TCP and UDP
Packets in protocols based on TCP and UDP are not distinguished by ICMP-type but with something else – a field called
port. Outgoing packets specify what kind of service should handle them on the server. The services have assigned a number and we can learn about them in
/etc/services. The packet with the request contains also information about the port that should be used in the response.
Let’s explain that on an example. Sending e-mail is handled by protocol SMTP If at the same time two mailing programs want to send and e-mail to one SMTP server, then both send a packet with a destination address of the server, their own address in the source address field and destination port 25 (STMP). To unambiguously identify which answer should be delivered to which program, the request gets also assigned a random number – a source port. This number is usually bigger than 1024 because smaller numbers are reserved for
well-known services The address with the port is usually written numerically
192.168.0.1:25 or in text form
Filtering by port
Filtering of TCP and UDP packets can be also done based on port. If we are providing DNS service we should let in into DNS server only packets that are carrying DNS request. That can be identified based on the destination port of the packet.
This approach has one flaw. For example with protocol HTTP, that is used to transfer web pages, our web browser wants to talk to an arbitrary web server. So we cannot filter HTTP packets. We want to let in only packets that are a reply to packets that originated from us. Firewall Netfilter solves that using connection tracking. That allows identifying
the incoming packet as
related – that are packets, that are a reply to our request packet. This includes ICMP packets informing us about errors or remote server being unreachable).
Another problem is protocols such as FTP. The trouble is that with this protocol there are two IP connections. One is used to transfer commands, the other one is used to transfer data. Port used to transfer data has usually the number 20. However, connection on this port is independent and is initiated by the server. Therefore, the client has a problem to identify packets from this connection as packets related to packets carrying the commands. That is true for classic FTP connection. However, there is also a passive mode for FTP. In passive mode, the client, and the server first agrees on the port that will be used to transfer data. Both theses ports have the number bigger than 1024. That means that this port cannot be obtained from the packet header but from the packet data.
That requires more work from the firewall because it is not enough to analyze packet header with a fixed structure, but it also has to analyze the data transferred in IP packets. (Netfilter handles that using module ip_conntrack_ftp). Similar troubles can be found with IRC protocol.
Network interfaces is a generic term not only for network cards but also for external and internal modems and virtual interfaces (e.g. for VPN). It is an interface used to receive packets on our computer. Often the network structure defines what IP addresses should not appear on the specified interface. For example, on a standalone a computer connected using a modem to the Internet we should not be getting packets with the source address 127.0.0.1. Or on an NAT-ing router, we should not have packets coming from the internet with a source address belonging to a local network (for example, reserved ranges 10.x.x.x, 172.16-31.x.x, 192.168.x.x). Such packets can appear if someone is creating packets with fake IP source address (address spoofing).
Finally, we should mention packets, that are invalid. For example TCP packet initiating the connection – has flag SYN – can happen only at the beginning of the connection. Similarly, TCP packets
with flags ACK,FIN set or RST can arrive only for existing connections. Invalid are also packets that do not have a matching checksum etc. etc.
As you can see the topic is quite complicated. For that reason, the network engineer configuring the firewall should have a good understanding of how things work. If he does not, he can create a feeling of false security. Something like having the building full of security staff but they are guarding only the basement while there is an open window on the first floor.
Renowned security expert Bruce Perens says
Security is not a state – it is a process.
Keep an eye on your firewalls. Manage them and improve them and hopefully,
you will push away the time when someone gets through. Good luck.