Not the law, but a good idea.
Port knocking: a stealthy system for network authentication across closed ports
Port Knocking has not been seen on TV
port knocking > primer > packets

Firewall Primer

Perl prototype: v0.30

  • pcaplib support added; daemon no longer requires firewall log file

2004-Nov-14 18:59 | ...more

new Net::Pcap support added to sniff packets directly ...more

This section introduces the idea of communication ports and firewalls at a very introductory level. If you are familiar with TCP/IP and firewalls, you can skip past this section and go straight to the details of the port knocking implementation. This introduction is not a technical document and is targetted at a non-technical audience or novices computer users and administrators.


Recall that a socket look up socket on look up socket on FOLDOC is a combination of IP address and port. Information flows between two sockets. These sockets can be on the same computer, as in the case of inter-process communication (IPC), or on different computers, as in the case of network communication.

In order to transmit data reliably (more on this term later), computers divide the data up into smaller pieces. These pieces are called packets look up packet on look up packet on FOLDOC . Each packet contains header information that describes how the packet was formatted, where it came from and so on. Think of the packet as a letter, with the headers as the envelope. If you had to mail someone a large book, but your maximum transfer unit (MTU - more on this later) was a letter, you would have to rip pages (data payload) out of the book and put them each into separate envelopes and in this way mail the book. Thus, a packet is a block of data that contains all the information necessary to deliver it. As packets travel across the Internet, various network devices examine and manipulate the packets on their way from destination to source.

TCP/IP Suite

Now that you know a bit out packets, let's turn to how they're created. Consider two computers on a network. Each computer has a network card, an operating system, and some software to send and receive the packets. All components must be able to communicate with one another in order for the packets to flow from one application on one computer (e.g. web browser) to another application on the other computer (e.g. web server). In order to formulate a model that describes the communication between these components two frameworks have been designed. First is the OSI look up OSI on look up OSI on FOLDOC (Open Systems Interconnection Reference) model and the Internet Protocol look up TCP/IP on look up TCP/IP on FOLDOC (or TCP/IP) Suite.

Both of these frameworks try to abstract the flow of data and identify tiers at which data is handed off between subsystems. The frameworks look slightly different but encompass the same process. I'll briefly mention the TCP/IP Suite here to give you a sense of how you should think about network data transfer.

The TCP/IP Suite is considered to be composed of 5 layers. Each layer works independently of one another and only adjacent layers can communicate. When data flows up the stack (1, 2, 3 and so on), the previous layer strips headers from the packet (in analogy, takes the letter out of the envelope) and passes the data payload (in analogy, the letter) to the next layer. When data flows down the stack (5, 4, 3, and so on), the top-most layer adds a new header to the data (in analogy, puts the letter in an envelope) and passes it down to the next layer down.

The layers in the TCP/IP Suite are as follows.

  • [5] Application Layer This layer describes communication with network-aware programs (HTTP, FTP, SSH, etc). Data is encoded into an application-specific format and then passed to the transport layer for delivery by one of the transport protocols.
  • [4] Transport Layer This layer is concerned with robustness, order and completeness of the data. This layer includes TCP (data delivery, completeness and order is verified) and UDP (no verification) protocols. The UDP protocol is a "best effort" protocol, which does not verify that the packets arrived at its destination and in the right order. UDP is frequently used when speed of delivery is critical, such as in streaming applications, or for query-response applications, like DNS. TCP builds on UDP and contains mechanisms to ensure that packets have been delivered and that the order of the delivery reflects the order of transmission. TCP is slower than UDP, necessarily because of the overhead of monitoring transmission quality, but alleviates the burden of delivery verification by the application.
  • [3] Network Layer This layer is concerned with routing of packets across multiple networks using protocols such as the Internet Protocol (IP).
  • [2] Data Link Layer In this layer data is framed, a process in which special headers/footers are added to the packet to mark its start and end. Ethernet is one of the most common transport mechanisms.
  • [1] Physical Layer This is the layer that models the physical characteristics of the medium across which the data flows, such as cabling, fibre optics and wireless links. Sometimes this layer is not counted in the TCP/IP suite.

Figure 1 illustrates how a packet may look once it's made its way down from the application layer (e.g. web browser) down to the physical layer. The data payload bundled between the many headers is the information provided by the application. This data is formatted specific to the application and presumably in such a way that the receiving application (e.g. web server) can interpret it. At the transport layer a UDP or TCP header is added, then an IP header at the Network Layer and finally an Ethernet header at Layer 2. You can see that there can be quite a bit of overhead in the headers when sending a very small amount of information (e.g. <100 bytes).

Port Knocking (c) 2002-2014 Martin Krzywinski
Figure 1 | A packet sent using TCP or UDP protocol contains three headers: Ethernet (22 bytes), IP (20 bytes) and TCP or UDP (8 or 20 bytes), a variable-length data payload section and a final frame checksum which is added at the network access layer. Generally the MTU is 1,500 bytes, which is very small compared to present network speeds.

A datagram is a specific packet format defined by the IP protocol. The datagram contains the IP header, protocol-specific header (TCP, UDP, etc.) and the data payload. Within each header, a variety of information is stored to provide the hardware and software that operates at that layer to correctly deliver the data up or down the TCP/IP stack.

Packet Headers

At three of the four TCP/IP stack layers, another header is added. The Ethernet header is added at the network access layer, the IP header at the internet layer and protocol-specific header (e.g. TCP or UDP) at the transport layer. In each case the header of a layer further up the stack is part of the data payload of the previous layer. The Ethernet standard (IEEE 802.3) permits the data payload at the network access layer to be up to 1500 bytes (Maximum Transfer Unit, or MTU). With recent advancements in data transfer speeds, it is commonly thought that the MTU is too small, causing too much protocol overhead, and there is an ongoing effort to include support for larger MTUs (12kb for a 100Mbit link, for example).

Port Knocking (c) 2002-2014 Martin Krzywinski
Figure 2 | The data payload and header of a layer becomes the data payload of the layer immediately below it in the TCP/IP stack. (zoom).

All this business about packets and headers is important because some port knocking systems inject information into the headers for authentication purposes. From Figure 2 you can see that there are a lot of fields a TCP header. These fields store a variety of data used in the delivery process. Some fields are not critical for delivery and can be freely modified.

Additional Resources

The wikipedia has excellent and lucid descriptions of the Internet Protocol Suite, OSI Model and packets.

Network Sorcery has a very detailed and complete list of TCP/IP Suite headers (e.g. TCP, UDP) and protocols.

last updated 2005-Oct-25 13:26
Port Knocking (c) 2002-2014 Martin Krzywinski