One of the key features of port knocking is it provides a stealthy method of authentication and information transfer to a networked machine that has no open ports. It is not possible to determine successfully whether the machine is listening for knock sequences by using port probes. Thus, although a brute-force attack could be mounted to try to guess the ports and the form of the sequence, such breach attempts could be detected easily.
Second, because information is flowing in the form of connection attempts rather than in typical packet data payload, without knowing that this system is in place it would be unlikely that the use of this authentication method would be detected by monitoring traffic. To minimize the risk of a functional sequence being constructed by the intercepting party, the information content containing the remote IP of the sequence can be encrypted.
Third, because the authentication is built into the port knock sequence, existing applications need not be changed. Implementing one-time passwords is done easily by adjusting the way particular sequences are interpreted. A sequence could correspond to a request that a port be opened for a specific length of time and then closed and never opened again to the same IP. Furthermore, a one-time pad could be used to encrypt the sequence, making it indecipherable by those without the pad.
To use port knocking, a client script that performs the knock is required. The client and any associated data should be considered a secret and kept on removable media, such as a USB key. The use of the client imposes an overhead for each connection. Certain locations, such as libraries or Internet cafés, may not allow execution of arbitrary programs.
In order to use port knocking, a number of ports need to be allocated for exclusive use by this system. As the number of such ports increases, the knock sequences becomes shorter for a given amount of information payload, because the number of coding symbols is increased. Practically, 256 free privileged ports (in the 1-1024 range), not necessarily contiguous, usually can be allocated and used to listen for port knocks.
Finally, any system that manipulates firewall rules in an automated fashion requires careful implementation. For the scenario in which no ports are initially open, if the listening dæmon fails or is not able to interpret the knocks correctly, it becomes impossible to connect remotely to the host.
In this section, three examples are outlined that illustrate how the port knocking system can be used.
1. Single Port, Fixed Mapping
Connection to only one port (ssh/22) is required. The ssh dæmon is running; all privileged ports are closed, including ssh/22; and packets addressed to ports 30,31,32 are being logged. The following port sequences are recognized:
31,32,30 open ssh/22 to connecting IP 32,30,31 close ssh/22 to connecting IP 31,30,32 close ssh/22 to connecting IP and disregard further knocks from this IP
The justifiably paranoid administrator can open the ssh/22 port on his system by initiating TCP connections to ports 31,32,30. At the end of the ssh session, the port would be closed by using the second sequence shown above. If the host from which the administrator is connecting is not trusted (if, say, keystrokes may be snooped), the use of the third sequence would deny all further traffic from the IP, preventing anyone from duplicating the session. This assumes the port sequence and system login credentials are not captured by a third party and used before the legitimate session ends.
In this example, only three sequences are understood by the system, as the requirements call for only a handful of well-defined firewall manipulations. The sequences were chosen not to be monotonically increasing (30, 31, 32), so they would not be triggered by remote port scans. If multiple ports are to be protected by this system, a mapping needs to be derived between the port sequence and a flexible firewall rule. This is covered in the next example.
2. Multiple Port, Dynamic Mapping
In this example, a network may be running any number of applications. Ports 100-109 are used to listen to knocks. The port sequence is expected to be of the form:
102,100,110 10a,10b,10c,10d 10(a+b+c+d mod 10) 110,100,102 header payload checksum footer
The first and last three ports let the port knocking dæmon know that a sequence is starting and ending. The next four ports encode the port (abcd) to be opened. For example, if a connection to port 143 is required, the sequence would be 100,101,104,103. The final element in the sequence is a checksum that validates the sequence payload. In this example, the checksum is 8 (1+4+3 mod 10). The sequence element therefore is 108, and the full sequence would be
102,100,103 100,101,104,103 108 103,100,102
When this sequence is detected, port 143 would be made available to the incoming IP address. If the port is open already, the knock would rendered it closed. The knock can be extended to include additional information, such as an anticipated session length, that can be used to close the port after a set amount of time.
3. Mapping with Encryption
The information contained in the knock sequence can be encrypted to provide an additional measure of security. In this example, 256 ports are allocated and logged. A knock map of the form
remote IP port time checksum
is used where the remote IP, port, time and checksum (sum of other fields mod 255) are encrypted. The encrypted string can be mapped onto eight unsigned chars using Perl's pack("C*",STRING) command, see Listing 1.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Interview with Patrick Volkerding
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script