Behaviour of Port-knocking authentication mechanism

(1)

Author: Petko Gerdzhikov Supervisor: Ola Flygt Semester: VT 2016

Subject: Computer Science

Bachelor Thesis Project

Behaviour of port-knocking

authentication mechanism

(2)

Abstract

Port-knocking is a security mechanism used in computer systems to hide available network services. Its operation relies on a drop policy firewall setting in order to make impossible for port-scanning attacks to occur. This project researches the impact of implementing such a software solution. Furthermore, it looks into the behaviour of three chosen implementations and make conclusions on the benefits and disadvantages that they bring. In addition, the surrounding implications related to both user and administrator are explored. This thesis includes tests on the resource consumption of the implementations as well as records of the added delay of using the mechanism when initiating a SSH session. There has not been such research performed in this field and the results of it could be beneficial to those who are in- volved in computer science and network security in particular. Finally, the product of this study state that port-knocking is overlooked and has great benefits in preventing zero-day exploits and hacker tools relying on exposed network services.

Keywords: port knocking, network security, security through obscurity, concealment, single packet authorization

(3)

1 Introduction

Although, port-knocking is not a new concept, there have been mixed opinions regarding the operation and benefits that could be gained by such an implementation. Part of the purpose of this project is to gather such opinions and attempt to give rational explanations and facts that support or renounce the subject. Furthermore, this thesis work will try to give a more definitive answer on the topic by examining the working process of real implementations. In order to achieve this, experiments that test the behaviour of the system, are performed.

Throughout this paper, the behaviour of this security mechanism is going to be the focus. Different aspects ranging from the theoretical limitations to actual results from experiments on available implementations are going to be presented in a structured manner.

In addition to standard port-knocking solutions, this report also examines Single packet authorization or SPA, which is considered similar to port-knocking (PK). Whereas there are differences in the execution, both mechanisms carry out the same functions and they are referenced throughout the paper as equivalent.

1.1 Background and history

The simplest answer to the question “What port-knocking is?”, is that port-knocking is a security authorization mechanism. Its goal is to provide integrity and concealment when accessing services on remote nodes. Although, this concealment is often misinterpreted as obscurity. With port-knocking the system does not rely on open network ports in order for a service to be reached. Instead, the implementation of the mechanism works in tandem with a firewall solution that handles the access control parameters and a policy for dropping all incoming requests is enforced. When a correct authentication request or

“knock” is being detected, the port-knocking daemon issues changes in the firewall rules in order to allow the client to access the originally desired service.

The concept behind this security mechanism goes way back to the beginning of the 21st century. It was first publicly discussed on a German Linux user group mailing list [1]. The original poster, by the name of Christian Borss, was questioning the reasons for leaving open ports constantly on a system to have services available. He saw that as a problem and proposed a solution that is very similar to the modern day port-knocking that we use today. The title “port-knocking” was first brought onto the world by Martin Krywinski in 2003 [2]. Then he was talking about the idea that by sending packets to predefined network ports, you could form a combination or a ‘secret knock’ that would translate to some sort of unique response.

1.2 Previous research

The inspiration for this thesis project comes from the paper titled “Performance Evalua- tion of Widely used Portknocking Algorithms” [3]. In it the authors have described the different features of several port-knocking implementations and have graded them cor- respondingly. This report would like to expand on that document by shifting the focus towards the behaviour aspect and the real implications of introducing a port-knocking solution to a physical system. Furthermore, the project by Sebastien Jeanquier [4] has been found to be close to the field of study presented in this report and has served as a starting point in the performed research.

(5)

1.3 Problem formulation and motivation

By inspecting the design of port-knocking, we can see that is a neat solution to a problem related to accessibility and protection of remote services. However, there are varying opinions regarding the benefits that it offers. Some authors claim that the method is bound to cause more trouble than it provides security [5], whereas others suggest that it can serve as a successful most outer layer of defence [4]. With that in mind, the goal of this thesis is to abstract itself from this dispute by taking a more practical approach and study the actual impact of implementing a port-knocking solution. In this way the study will be focused more on the user experience aspect than theoretical capabilities. The results that would come out of setting up and testing real port-knocking implementations should shed more light on the choice that a system administrator would make regarding this additional layer of security.

Characteristics such as response time, multiple user support, ease of implementation, hardware load and maintenance requirements would be the prime area to study. In order to accomplish this, there would be a controlled environment setup, where one would compare and contrast each implementation separately against a system that does not run port-knocking.

1.4 Research Question

RQ1 What are the differences and similarities in the design of port- knocking with “security through obscurity”?

RQ2 How does the implementation of a port-knocking service affect the behavior of a system?

RQ2.1 What is the hardware load that port-knocking adds to a system?

RQ2.2 How reliable is port-knocking as an authentication mechanism in a system with multiple users?

RQ2.3 What kind of system requirements are needed in order to support port-knocking from an administrator’s perspective?

RQ3 What are the potential security risks for a system with port-knocking authentication?

It is expected that implementing a port-knocking solution does not cause significant load on the running system. Moreover, handling multiple clients should be in the scope of capabilities of the examined implementations. On the subject of network security, regarding this mechanism, the expected results should reinforce the idea that this method could indeed bring benefits. Furthermore, there is a consideration that by design port- knocking and its derivatives introduce a “bottleneck” in a system. Thus, it is up to the research to prove the reliability of the highlighted implementations.

1.5 Scope/Limitation

The intention of this research is to explore the behaviour of existing port-knocking and single packet authorization implementations. Hence there must be a certain aspect of this behaviour that is going to be the focus. For this study the implementations are evaluated based on their hardware performance and response time. Furthermore, any features or complications regarding the operation and maintenance of these mechanisms is also of interest.

An important consideration is that all of the experimentation and diagnostics have been performed only on a UNIX system. As for the choice of existing implementations,

(6)

the selection was primarily based on popularity. This report covers two port-knocking and SPA solutions - knockd and fwknop. In addition, another PK implementation by a computer security researcher known as Moxie Marlinspike is also being examined and compared. It can be found under the name knockknock.

1.6 Target group

Given the fact that port-knocking and its derivatives are not that popular, the language throughout the paper strides to be as basic as possible. However, this report aims to inform people that are interested in advanced network security mechanisms and therefore previous knowledge in computer science is recommended. Moreover, the target group that this work might be of most value to is personnel that is currently working on an administrator position or responsible for network security in general.

(7)

2 Method

This chapter of the report is dedicated to describe the procedures that were performed in order to find answers to the aforementioned research questions. Furthermore, a statement about the reliability and validity of the thesis is mentioned.

2.1 Scientific approach

To draw some scientific conclusions on the topic of the behaviour of port-knocking authentication mechanisms, a quantitative approach was utilized. This implies that numerical data is gathered and analyzed. The study focuses on experiments with actual implementations, where their performance is evaluated and compared against one another. The research also draws and reinforces conclusions made beforehand from previous work on the subject.

2.2 Hardware load experiment

In order to fulfil the quantitative approach that is used to prove the afore set hypothesis from the previous chapter, the experimental method has been selected. With regard to the behaviour of the implementations, this experiment aims to showcase the system load variables. For that purpose the hardware performance of the test platform is evaluated for each separate implementation. To define hardware performance the following metrics have been identified to be of interest:

• CPU load

• Memory utilization

• Disk operations

The reasoning behind the choice of these metrics is that they are primary actors in the behaviour of a system. By examining them, conclusions about the effects of the software could be drawn. The experiment has been performed in instances of 100 for each of the chosen implementations utilizing an expect script. During this, the hardware performance of the test server, running the PK/SPA solution, has been recorded and stored. The application used to monitor system status was atop [6].

2.3 Response time experiment

Since this thesis project has a focus on the behaviour of port-knocking implementations, the user experience holds a huge role. When discussing different factors regarding said experience, the response time is one of the most valued criteria when comparing applications. For that reason, a quantitative approach in the form of experiment has been elected to study the area. Each of the selected implementations has been assigned to make a knock and SSH request to the test server 100 times. The measurement of the response time was held on the client side. The procedure involves taking a time-stamp from the initialization of the knock and then also recording the time when a successful SSH lo- gin has been made. This was made possible using scripting, as the previously described experiment.

In order to keep the environment consistent, the test server has a NTP (Network Time Protocol) service running as well. All the clients are synchronized before the experiment and their system time checked against the server machine.

(8)

2.4 Multiple client behaviour experiment

Since the concept of port-knocking is functioning as the most outer layer of authentication, the consistency of operation should be as high as possible. This implies that management of multiple clients is of interest to this project. To explore the subject, a quantitative approach in the form of an experiment, has been performed here as well.

The behavioural aspect is observed again from a hardware and response time perspective. The testing environment features one machine acting as a server and four client computers. The experiment itself involves the sending of a knock and establishing a SSH connection to the server from all the clients at the same time. To aid the synchronization of the knock, the clients are instructed to perform a NTP query to the test server. Further- more, the initiation of the experiment is handled by the task scheduler cron, in order to ensure simultaneous authorization attempts. During the execution of the experiment the client output has been recorded and monitored for irregularities in the operation of the knocking process or the establishment of the SSH connection. Moreover, the server has had its system monitored with the process monitoring tool atop.

2.5 Reliability and Validity

The experiments performed in this project should be considered reliable, granted that the system specifications in Table 4.1 have been followed. The methods used to collect the data, such as the monitoring tool atop, do not cause inconsistencies given the measured metrics. Furthermore, the results should be considered valid, since the outcomes and conclusions that have been displayed rely on unbiased numerical data gathering during the preparation of the report.

(9)

3 Port-knocking

The following gives an overview in addition to the general benefits and flaws that are accompanied with the implementation of port-knocking or single packet authorization.

3.1 Overview

To give a better idea of the concept we are going to look at the transaction that occurs between two nodes. In Figure 3.1 the transaction model is presented. In the authentication process there are two actors - the client and the server. The server is running a service that a remote client would like to utilize. As an example there is SSH - network protocol used in remote access schemes. In order for the client to be able to access such service, a predefined network port must be set to be accessible on the server. For the purpose of SSH (Secure Shell protocol), port 22 has been assigned. In this example, these access rules are being governed by a firewall solution that is operating on the server. When the client sends the request, the firewall makes a decision based on said pre configured rules and either discards the request or allows the communication to continue.

Figure 3.1: Standard SSH connection request

By original design, port-knocking depends on a predefined combination of port numbers. The client would have to attempt to connect to these ports in their correctly given order. This combination serves as the secret “knock” that would open a service on the server-side. In Figure 3.2 a port-knocking request could be observed. The client makes connection attempts to ports 17, 231, 721, 9001 and 4, which is presumably the pre- configured sequence. With port-knocking implemented, the server’s firewall is set to drop all connection attempts made. However, there is also a port-knocking daemon operating.

It has the function to examine the failed connection attempts made towards the system and record the correlating IP address of the client and the port numbers that were tried.

When a client has successfully managed to produce a correct sequence of “knocks”, the port-knocking application would make modifications to the firewall rules on the server and would allow the client to access the originally desired service.

Figure 3.2: Port-knocking request

Single packet authorization or SPA is a modification on simple port-knocking. As with port-knocking there are two actors - client and server. Instead of using a sequence of failed connection attempts, however, only a single UDP packet is being sent by the client.

(10)

This packet contains specifications of the service that is desired, such as port number and transport layer protocol. Furthermore, the security details of the encryption that have been agreed upon on configuration are shared, in order for the server to verify a potential client.

When implementing a port-knocking mechanism to a system the end goal is to provide an additional security layer. Different implementations offer different capabilities and the choice of the most suitable one for a certain system could have impact on the system’s behaviour. This thesis project examines three open source applications - knockd, fwknop and knockknock.

3.2 Knockd

Knockdis a port-knocking application that follows the original model of “knocking” the closest among the chosen implementations for this project. The server daemon could operate on a *NIX system only. In the case of monitoring, it works by inspecting the system log of the system for connection attempts. This monitoring is made possible with libpcap network framework. Moreover, knockd works in conjunction with the firewall solution iptables in order to fulfil the authentication scheme [7].

The server application must have administrator rights on the system, in order to mod- ify the network access rules. The configuration of knockd is handled by a single access file, which holds the port-knocking sequence among other options. An administrator could set up multiple sequences that correspond to different commands that the PK daemon could execute. Furthermore, there is the possibility to set a timing window for each command. Another property that could be configured is related to the set TCP flags of the incoming potential knocks [7].

The “knocks” that a client performs could be either TCP or UDP frames directed to a network port on the server. There is no additional characteristics that must be applied to the frames and they could be performed using any number of network tools, e.g nmap.

However, the application features a standalone port-knocking client software by the name of knock by the same author.

3.3 Fwknop

This application implements the Single Packet Authorization scheme for providing security to a system. This implies that a single UDP packet is sent as a “knock” to the server.

The server application must be installed on a *NIX system, but the client is supported by Windows, iPhone, Android or Cygwin. Fwknop relies on the library libfko, which is developed especially for the project. The libcap features are utilized to monitor the traffic to the system. Moreover, the implementation is designed to operate alongside an iptables, ipfwor pf firewall solution [8].

In order to configure fwknop to operate, the administrator must make a choice regarding the type of encryption that is going to be utilized. The implementation has the option to choose from using either symmetric or asymmetric encryption during the authentication exchange. The former is accomplished by using Rijndael [9], whereas the latter utilizes GnuPG keys. With Rijndael, the clients must generate a set of secret keys and associate them with the IP address and hostname of the server. On the other side, if GnuPG is the preferred encryption method, the gpg software suite must be installed on the system and appropriate gpg-keys must be exchanged between server and client.

Regardless of the encryption, the server daemon must be configured with the provided access configuration file. The way that it is organized is that all of the client’s parameters must be included into stanzas. Stanzas represent a set of options related to an entity

(11)

or groups of entities that would be authorized into the system. Details such as source IP address, network port/s that would be opened and the aforementioned secret keys compose the core of this software’s authorization rules [8].

3.4 Knockknock

Knockknock is a project developed in python to improve on the original port-knocking authentication scheme. Instead of having a chain of TCP/UDP packets directed to vari- ous network ports on the server, the client sends a single TCP packet, similarly to Sin- gle Packet Authorization [10]. This is done by using the security network tool hping3.

Consequently, this results in the implementation being unusable on a Windows operating system.

The server daemon in this implementation monitors directly the kern.log log file for the “knock” of the client. When such packet has found, the daemon makes the appropriate changes to the firewall - in this case iptables. The structure of this packet is based upon previously exchanged parameters between client and server. Moreover, this is done manually when configuring the client platform. Each client implementation has a profile containing the cipher key, HMAC and the internet port they would like to use for their requests. These pieces must be present on the system running the server in order for the implementation to operate.

3.5 Security considerations

When looking at the operational model of port-knocking there are some arising concerns with accessibility. The implementation of such security mechanism is introducing an apparent “bottleneck” in the system. The fact that services are behind a firewall drop- policy implies that they cannot be accessed unless the PK/SPA daemon is functioning properly. Furthermore, any irregularities or failure of said daemon could render the system closed-up and would require physical personnel to attend and resolve the issue. From the tested implementations only fwknop has a fail-back sequence programmed [11], which is achieved by event-based monitoring daemon - upstart.

A security consideration that has been brought up by the creator of knockd is related to DNS traffic [7]. The problem originates from the design of the implementations when it comes to resolving domain names. Since iptables requires an argument in the form of an IP address, when contacting a server by a FQDN, the –lookup option must be used.

The security risk comes if a malicious user is monitoring the DNS traffic to the system.

The first port in the sequence becomes known in that case.

Man-in-the-middle attacks are another area that pose a great deal of threat to a system that includes port-knocking. This is due to the danger of the knock sequence being monitored and then replayed. If that scenario occurs, it would make the whole mechanism obsolete and would risk exposing the services to an attacker. With knockd this is a real concern, since the implementation does not have any integrated encryption by design.

What this implies is that TCP or UDP packets from the client are transmitted in plain text when trying to authenticate with the server. On the other side, fwknop and knockknock make use of encryption for their exchanges. The single packet authorization application fwknoputilizes the Secure Hash Standard [12] and in particular SHA-256 in combination with HMAC (Hash Message Authentication Code) [13]. These algorithms are highly re- garded and approved by the National Institute of Standards and Technology, also known as NIST. The same security mechanism is also implemented by knockknock. With such

(12)

protection these implementations are resistant to “eavesdropping, replay attacks and all known forms of cryptanalysis against IND-CCA secure schemes" [10].

One of the biggest controversies surrounding port-knocking is the fact that is considered to be “security through obscurity” [5]. What that implies is that the defensive capabilities of this mechanism are due to keeping the way of operation of the system a secret. While this is partly correct, the fact of the matter stays that the system and each additional layer of security must be looked as a whole. The article by Jay Beale [14] brings some important points in understanding the benefits of obscurity. It highlights some of the major threats that port-knocking deals with, for example raising up the awareness level in the system in case of an attacker trying to overcome the authentication. Furthermore, a system protected by a port-knocking mechanism eliminates some of the tools that could be used for finding exploits in networks. This is due to the fact that PK/SPA is an ab- normal addition and rudimentary hacker tools manufactures do not consider them in their design. Moreover, it is wrong to look at port-knocking as “security through obscurity”.

As pointed out by Sebastien Jeanquier in his master’s project [4], the confusion is with understanding the mechanism’s purpose and design. The design of the implementations is open to look at by everyone and therefore cannot be stated that the security that it provides is merely obscurity. The purpose of port-knocking is that of concealing a system.

(13)

4 Experiment results

For the experiments to be performed, there has been one machine that acted as server and four other computers that carried out the client part. The LAN environment has been made possible with a Netgear GS724T switch that has only factory default settings. The testing network topology resembles a simple star topology. For a reference to the hardware and software specifications of the client and server turn to Table 4.1.

SERVER CLIENTS

Processor Intel(R) Core(^TM) i7-3537U

@ 2.00GHz

Intel(R) Core(^TM) 2 CPU 6300 @ 1.86GHz

Memory 3930 MB 1024 MB

Operating system Ubuntu 14.04.4 LTS Ubuntu 14.04.4 LTS Kernel version Linux 3.19.0-59-generic

(x86_64)

Linux 3.19.0-59-generic (x86_64)

Network controller Realtek Semiconductor Co., Ltd. RTL8111/8168/8411

Broadcom Corporation NetXtreme BCM5754

Table 4.1: Server and client specifications reference

In order to evaluate the output of the performed experiments, a base case test has been performed. It consisted of two parts - the first measured the time it took to establish a SSH connection without any additional port-knocking or SPA. As a consequence, the average recorded time it took amounted to 2 milliseconds. The second part of the base test recorded the idle consumption of hardware resources by the showcased implementations. Refer to Table 4.2 for the corresponding values. Note that knockknock spawns two separate processes in the system and therefore two figures are given.

fwknop knockd knockknock

CPU (busy) 0% 4% 0%

Virtual memory size

8752 49296

10972

(Kbytes) 40712

Resident memory size

8348

4156 792

(Kbytes) 6324

Table 4.2: Idle operations resource consumption

4.1 Single client hardware experiment

The results of the conducted measurements for CPU and memory usage are structured into tables. As it can be seen in Table 4.3 and Table 4.4, each implementation has a column corresponding to the values derived from the experiment. These digits represent the average value that was calculated for the hundred port-knocking attempts. Due to the fact that both knockd and knockknock spawn multiple processes, two separate values are shown in the tables.

(14)

fwknop knockd knockknock Virtual memory size

8752 49552

10972

(Kbytes) 0 114440

3800 8976

4184

(Kbytes) 4160 8068

Shared text memory 120 0 0

Minor page faults 557 159 318

(average)

Table 4.3: Implementations memory usage table with single client fwknop knockd knockknock CPU-consumption in

37.14 4.06

1.23

user mode (clock ticks) 39.75 0.19

CPU-consumption in

206 2.36

3.53

system mode (clock ticks) 203.84 0.14 Table 4.4: Implementations CPU usage table with single client

Furthermore, disk operations are expressed in a graph in Figure 4.3. It shows the milliseconds spent on disk operations for each instance of a knock - SSH attempt. The vertical values represent the number of time spent on I/O operations during the single client experiment. Throughout the horizontal axis, the progression of each attempt can be seen.

(15)

Figure 4.3: Disk operation graph with single client 4.2 Single client response time experiment

In this section the results of the single client response time experiment are presented. The data is structured in Figure 4.4, Figure 4.5 and Figure 4.6, where there is a separate graph for each implementation. In addition, Figure 4.7 combines all of the previous results for improved visualization and comparison. All graphs show the time in milliseconds that it took to establish an SSH connection from the client to the server. The horizontal axis expresses one instance of executing the experiment for response time.

Figure 4.4: knockd response times graph with single client

(16)

Figure 4.5: fwknop response times graph with single client

Figure 4.6: knockknock response times graph with single client

(17)

Figure 4.7: Comparison of response times with single client between implementations

(18)

4.3 Multiple clients behaviour experiment

The multiple client experiment results can be seen in the following figures. Table 4.5 shows the memory usage for each individual implementation when handling four clients simultaneously. As explained before, knockd and knockknock spawn a couple of processes and they exhibit multiple values. The figures for virtual and resident memory size represent the average dedicated kilobytes.

fwknop knockd knockknock Virtual memory size

8752 49548

10972

(Kbytes) 0 335892

3840 8884

4340

(Kbytes) 4020 8164

Shared text memory 0 0 0

Minor page faults 70 169 268

(average)

Table 4.5: Implementations memory usage table with multiple clients

In Table 4.6 the output from the monitoring of the CPU handling multiple clients is located. The values are the average derived from the performed experiment instances.

fwknop knockd knockknock CPU-consumption in

230.58 0.5

1

user mode (clock ticks) 230.17 0.5

CPU-consumption in

1233.87 0.5

0.5

system mode (clock ticks) 1199.6 0.5 Table 4.6: Implementations CPU usage table with multiple clients

The results concerning disk operations and amount of time spent on I/O operations proved to be identical to the results of the single client experiment. Therefore, turn to Figure 4.3 in the previous subsection for reference of the data.

The output of the response time portion of the multiple client experiment can be observed in Table 4.7. The data that is given represents the time it took for a "knock", combined with a SSH session attempt to be made to the test server for four separate clients. The presented values are in milliseconds. In addition, the experiment strived to synchronize the execution of the four clients as much as possible and the end result was no initialization difference more than 300 milliseconds in total.

In the case of fwknop there were problems regarding clients one and two. During execution these two clients did not produce any results with the developed test scripts.

(19)

After elaborate testing and research, the dysfunction proved not to be caused by the script itself, but by the command scheduler cron. Attempts made without cron by these two clients were successful, but the issue with the multiple client experiment persisted and proved to be unavoidable during the testing period.

fwknop knockd knockknock

Client 1 300 6450 350

Client 2 6561 6441 864

Client 3 - 6692 341

Client 4 - 6400 6537

Table 4.7: Response time for performing a synchronized connection attempt

(20)

5 Analysis

This chapter includes analysis and conclusions, based on the outcomes produced by the previously described experiments. More specifically, it will give insight on the behaviour of the examined implementations. Furthermore, the results have been put through statistical tests, in order to validate if the produced output is of statistical significance [15].

The ANOVA and t-test have been utilized throughout the showcased cases and they have confirmed that the figures correspond to multiple different sets carrying statistical significance each.

5.1 User experience analysis

Implementing additional layers of security to a system usually implies that the complexity of said system would increase and the user satisfaction would detriment in some way as a consequence. Take the simple example of securing a user account with a password opposed to having no need for credentials in order to authenticate. In the former, we have substantially increased the security properties, but we have put pressure on the person that should use this account by having them responsible for the password. However, if we elaborate more, the user could, for example, take advantage of a password management system that would store credentials and would assist when it comes to authentication.

There are certain parallels that could be drawn between this example and the user experience aspect when handling port-knocking and SPA.

The impacts of not requiring a password for authentication are of course much larger than the absence of a PK/SPA mechanism. However, the act of providing a password is similar in a way to the initialization of a “knock”. With knockd, the client must provide the target server’s hostname or IP address as well as a predefined sequence of ports that he has a reference of and that would allow him to accomplish his original task. In the case of fwknop and knockknock the user must supply the hostname or IP address of the server again, but instead of inputting a knock sequence, a network port number of the desired service must be given. Hence, it can be concluded that the last two mentioned implementations would be trivial to operate and would not pressure the user by loading him with multiple complex extra steps. Moreover, the required input for knockd, in particular the knock sequence, can be closely compared to a passphrase. This brings us to the aforementioned example of passwords and how with a password management system we could simplify the authentication process for the user. Although in the case of port- knocking there is currently no system that could automate the process on its own, system administrators could turn to scripting, in order to achieve the same goal. All of the performed experiments have been executed with the help of scripts, which initiate the knock and perform a SSH request immediately after. Therefore, any concerns that port-knocking hinders the user experience by introducing additional complexity to the system could be put to rest.

Another criteria that was identified as being an important actor in the user’s experience is the response time of the authentication process. Naturally, a long time spent idle would result in frustration and dissatisfaction with the software. Examining the results of the experiments related to the response time of each implementation we can see that the caused delay is rather unsubstantial. From Figure 4.7 in the single client response time subsection it can be derived that for one hundred repetitions fwknop gives an average response time of 518 milliseconds, knockd - 473 milliseconds and knockknock - 603 milliseconds. The average value across all of the tested software amounts to approximately 531 milliseconds, which correlates to half of a second rounded down. Even by comparing

(21)

these results to the base case SSH request, which amounted to 2 milliseconds response time as mentioned in chapter 4, the difference is not perceivable. Moreover, by examining the results for the multiple client tests from Table 4.7 in chapter 4, the average delay amounts to 4093 milliseconds, which even if it is eight times more than with single client it would not make an impactful difference. Thus it can be concluded that for the human perception that sort of delay is unnoticeable and would usually not catch the attention of a user utilizing a service and therefore not hinder the user experience. However, by further examination of Figure 4.7 the fact that the response time grows after each following attempt could be noticed. This can be seen for each implementation and could raise concerns. If the response time gradually grows over the time it could result in inactivity by the daemon and would drastically rise the dissatisfaction with the mechanism by a client.

Finally, from the conducted experiments we can make conclusions about the stability of each implementation based on the success rate of connection attempts. This analysis so far has gravitated primarily on the outcome of the single client experiments, which achieved one hundred percent successful authentication requests. However, this mechanism is not limited to only one-to-one exchanges and in a real environment the case of multiple users trying to authenticate at the same time is far from unimaginable. If we refer to Table 4.7 in chapter 4, showing the response time with multiple clients, we see that fwknop had an undeniable problem. The fact that half of the clients could not initiate the authentication proves that there is instability with the implementation.

5.2 Hardware analysis

Computer systems operate with finite resources. Furthermore, the management of these resources is crucial in the optimization and proper operation of the system. In particular, hardware capabilities is one of the primary characteristics that dictates the functional limitations of a device. Therefore, the hardware load caused by implementing an additional layer of authentication should not be of major impact to the performance. The performed experiments strived to break down the different aspects of hardware impact and consequently have showcased the memory usage, CPU load and disk operations.

By examining the resources that the implementations consume when they are functioning in an idle state, presented in Table 4.2, it could be seen they are not necessarily demanding. Memory usage for knockd and fwknop falls between the range of 7 to 12 megabytes, which is completely negligible for today’s standards. Moreover, the combination of the two processes that knockknock utilizes amounts to roughly 100mb and would still not cause strain to a modern system. However, by inspecting the CPU values some concerns could be raised. While fwknop and knockknock displayed no processor activity while idle, the fact that knockd loads 4% of the processing unit while in idle state brings up some problems with the implementation. As a supposed lightweight application that amount of strain seems out of place. Granted the software performed the best in terms of memory usage, CPU management is crucial in server-based devices and the software they utilize.

Going from idle state to operation mode did not seem to drastically affect the memory characteristic of some of the applications. Fwknop showed the most consistent results concerning memory among the three showcased implementations with a margin of 100 kilobytes difference in virtual memory across all of the executed experiments - single and multiple client. In the case of knockd the situation was similar in terms of virtual memory, but while active the resident memory share is more than five times more opposed to the idle values. Furthermore, since there are two separate processes related to the imple-

(22)

mentation, it can be said that knockd requires double the memory space of fwknop. For the third application - knockknock the variance is much greater. While the previous two displayed consistency of memory usage in the three tested states - idle, with single client and multiple clients, this port-knocking solution exhibited different values across the experiments. With the two processes that it spawns it proved to be the most demanding out of the bunch. Regarding virtual memory, the first process alone showed that it occupies 50 megabytes, which is more than the other two implementations combined. Moreover, the second process related to knockknock grew proportionally according to the amount of clients that were authenticating. From the single client experiment results, found in Table 4.3, it can be seen that the “knock” took 100 megabytes of memory and then when adding more clients it rose to 335 megabytes. This can be considered a big jump in virtual memory consumption and it should be contemplated if adding more clients would cause critical strain to the system.

In terms of CPU load that the implementations cause to the system there is one ob- vious under-performer As mentioned previously, knockd demands 4% of the processor to be occupied at all times. Furthermore, by performing authentication attempts to the server the amount of CPU activity raises proportionally as it can be seen by comparing the values in Table 4.4 and Table 4.6. However, the gap between 38 clock ticks for single client and 230 for multiple clients in user mode is not that staggering and could be considered negligible. Same statement could be made for system mode where the difference is between 204 and 1216 clock ticks. For the two remaining implementations the processor load was virtually identical and close to none. Based on the previous statements it could be considered that all three applications showed no excessive CPU load.

Finally, going over the disk operations that the implementations performed during the experiments it can be concluded they do not rely on major I/O activity. For first portion of several authentication requests, the port-knocking solutions spent a mere average of 75 milliseconds on disk activities. Afterwards the variance dropped, as seen in Figure 4.3, and stayed at an average of 20 milliseconds. Furthermore, the fact that by adding additional clients did not affect the I/O activity reinforces the statement that these implementations are not demanding in terms of disk operations.

(23)

6 Discussion

In the beginning of the project the initial idea was to shed light on this authentication mechanism. Through experimentation with real implementations the goal that was set was to test the practical implications of adding such software to a working environment.

From the final results and research it can be stated that port-knocking is rather underes- timated. As explained in chapter 3, the concept of PK/SPA is commonly mistaken for enforcing “security through obscurity”, which is generally frown upon in the security fields. However, with the given explanations it is clear that the mechanism provides concealment to a system, instead of simple obscurity. Such concealment only reinforces the underlying security measures and it is wrong to look at it as a single line of defence. Fur- thermore, with such implementation the system is given the possibility to protect against zero-day exploits for the aforementioned underlying services. That sort of feat should not be passed away with a light hand. In addition, the fact that port-knocking is of not so great popularity serves as an added benefit in way that it causes malicious users to re-evaluate their attack vectors.

A major angle that this thesis project strived to investigate was the overall effects of port-knocking to a system that implements it. From a hardware perspective the performance is within the borders of reason. An argument could be made for knockd, however.

The implementation is causing unwarranted processor load that could be found unreason- able by some. Looking pass this situation, all of the applications would not overload a real server device. On the topic of the client side in the model, with automation by scripting the implementations will not hinder the standard operation and procedures when accessing remote services. In this project this is deployed with the help of expect scripts. They are straightforward in their operation and easy to compose. The setup of the test environment brought some further discoveries. In the specifications for fwknop there is the option to implement the authorization with the help of GPG keys. However, during the preparation there appeared a problem related to the dependencies of the application. Fwknop handles GPG functionality with libgpgme library, but unfortunately after multiple attempts to configure said library the final result was an error stating that the feature is unsupported.

Consequently, that is the reason not to investigate the GPG method of encryption. The other issue related to fwknop and handling multiple clients also seems unclear. During testing it was confirmed that each individual client could perform a successful “knock”

and SSH session with the same piece of script. However, with the addition of cron the result turned out in the inability to authenticate two out of the four clients. Whether this is from a design incoherence or faulty set up of the environment is tough to state, but the problem of inconsistency with multiple clients persists.

Naturally all of the previous statements have the most impact on the judgement of the system administrator that would consider implementing such a mechanism. The examined implementations do not demand more in terms of maintenance, so that makes them easy to operate pass the initial configuration. Although, an important point that could be made after the research is that only fwknop has a build-in recovery if the daemon fails. With the implementations of the other applications a process monitoring/recovery tool is crucial to consider to avoid lockouts from the system. Other security risks could be found lying in the simplistic design of knockd. The fact that it does not posses integrated encryption makes is dangerous to use in big networks. Moreover, the problems surrounding DNS are also detrimental to the choice of using such implementation.

(24)

7 Conclusion

This project shows the behaviour aspect concerning systems that implement port-knocking.

The work strived to exhibit this by looking for answers to the set of research questions found in the first chapter of the report. From the final results in the research and the following analysis, it can be stated that they all found some conclusion. The presented figures prove that from hardware standpoint the implementations do not overload the system. In addition, the misconception that port-knocking is merely providing ”security though obscurity” was discussed and an explanation to why this mechanism has no similarities with the term was shown. Furthermore, the user experience is not affected when using remote services in combination with port-knocking or single packet authorization, based on the response time, and through automation the operation of the mechanism could go unno- ticed. This would fall down as a requirement for the system administrator to implement and also to address the security consideration shown in the third chapter.

As far as the tested software, when examining each individual implementation it can be stated that knockd displayed the worst outcomes. The fact that there is no encryption in any form makes it very dangerous to use without any additional solutions. While being the simplest to operate it is outdated and easily surpassed by the two other applications.

Knockknock shows satisfying results in all of the performed tests. The only problem is that there have not been any recent updates and longevity is an issue. Thus, the best solution that showed greatest promise is fwknop. With the continuous support and variety of features that it offers it seems the logical choice in the selection of a port-knocking solution.

In conclusion it can be said that port-knocking is a rather overlooked mechanism that could provide additional layer of security to a system. While it has its issues, it is mostly a reliable feature that would delay or even divert a huge portion of attacks directed to usually transparent services. Its behaviour does not result in anomalies within the system and it definitely solves more problems than it causes.

7.1 Future research

As a future research based on this project, the expanding response time anomaly could be explored further. From the conducted experiments the exact cause of that occurrence could not be pinpointed to certain factor. Furthermore, the implementations could be tested in a more loose environment. The setup that was used, strived to not include un- controlled variables, such as excessive internet traffic. However, in order to come closer to a real-life scenario additional variables could be introduced to the testing.

(25)

References

[1] Borß, C. (2001). "DROP/DENY vs. REJECT", The Linux User Group Braun- schweig Mailinglist <lug-bs.lk.etc.tu-bs.de>, Oct. 2001, Braunschweig, Ger- many, Available online: http://www2.ika.rub.de/publications/2001/www.lk.etc.tu- bs.de_lists_archiv_lug-bs_2001_msg05734.html

[2] Krzywinski M. (2003) ‘Port Knocking: Network Authentication Across Closed Ports’. SysAdmin Magazine, pp 12:12-17.

[3] Khan, Z. A. , Javaid N. , Arshad M. H. , Bibi A. and Qasim B. (2012) , “Performance Evaluation of Widely used Portknoking Algorithms”, 2012 IEEE 14th International Conference on High Performance Computing and Communications.

[4] Jeanquier S. (2006) , “An analysis of Port Knocking and Single Packet Authoriza- tion”, Information Security Group, Royal Holloway College, University of London, 2006.

[5] Hansteen P. N. M. (2012), “Why Not Use Port Knocking?”, That Grumpy BSD Guy, 2012. Available online: http://bsdly.blogspot.se/2012/04/why-not-use-port- knocking.html

[6] atop, Atoptool, Available online: http://www.atoptool.nl/

[7] knockd – a port-knocking server. Available online:

http://www.zeroflux.org/projects/knock

[8] fwknop: “Single Packet Authorization: A Comprehensive guide to Strong Service Concealment with fwknop”, Available online:

http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html

[9] National Institute of Standards and Technology (2001) FIPS PUB 197. ‘Ad- vanced Encryption Standard (AES)’. National Institute of Standards and Technol- ogy, 100 Bureau Dr. Stop 8900, Gaithersburg, MD 20899-8900. Available online:

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

[10] Moxie Malinspike. (2012), knockknock, Thoughcrime, Available online:

http://www.thoughtcrime.org/software/knockknock/

[11] Rash, M. (2013) “Port Knocking: Why you should give it another look”. [Article] cipherdyne. 17 October 2013, Available online:

http://www.cipherdyne.org/blog/2013/10/port-knocking-why-you-should-give- it-another-look.html

[12] National Institute of Standards and Technology (2002) FIPS PUB 180- 2. ‘Secure Hash Standard’. National Institute of Standards and Technology, 100 Bureau Dr. Stop 8900, Gaithersburg, MD 20899-8900. Available online:

http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

[13] National Institute of Standards and Technology (2008) FIPS PUB 198-1. ‘The Keyed-Hash Message Authentication Code (HMAC)’. National Institute of Standards and Technology, 100 Bureau Dr. Stop 8900, Gaithersburg, MD 20899-8900. Avail- able online: http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf

(26)

[14] Beale, J. (2000) “Security through Obscurity Ain’t What they think it is”. Bastille Linux Project. Available online: http://www.portknocking.org/docs/security-through- obscurity-beale.pdf

[15] Marshall, E. and Boggis, E. “The Statistics Tutor’s Quick Guide to Com- monly Used Statistical Tests”, University of Sheffield. Available online:

http://www.statstutor.ac.uk/resources/uploaded/tutorsquickguidetostatistics.pdf

(27)

A Appendix 1

The following appendix contains the configuration files related to the tested implementations.

Knockd.conf:

[options]

UseSyslog Interface = eth0 [SSH]

sequence = 7000,8000,9000 seq_timeout = 10

command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp –dport 22 -j ACCEPT tcpflags = syn

cmd_timeout = 5 stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -j ACCEPT

Knockknock main config and client profiles [main]

delay=15

error_window=20 Client1:

[main]

knock_port = 1111 Client2:

[main]

knock_port = 4444 Fwknop access.conf SOURCE 192.168.0.1 OPEN_PORTS tcp/22

KEY_BASE64 D/t6XA4JI/HsOPR5aDISn7ZzxjgUuZxDd/36quBJ69w=

HMAC_KEY_BASE64 N6rxw49Nki5cmIf4kaPSrk9VBu46n7DkqnwK3S7ZivGu64b4pgBojEPLXkerUZQ3WC76dU2yxmsnauxkiu4Flw==

SOURCE 192.168.0.2 OPEN_PORTS tcp/22

KEY_BASE64 dFdH0sfjskS64BUXuK86WwrUiFM/7+l9b1dnvq077mM=

HMAC_KEY_BASE64 IgMsDdX404TUicgPDZlbYVU6vp7zuCLQTBxQHcV185VVF/wFMqFsJ6BUXB3+NMpxAG7C5+5BaBpC1eAIdAfmTQ==

(28)

KEY_BASE64 nwWmqXtoa4YAKtgFjom758b4SQFdXvZKtrEzCyPFITE=

HMAC_KEY_BASE64 hbLPGz+02jxzgFWlT4caV20M09fnZJHomVFKcNF+EUlgYIcfM9rVJoJ/R3qtYKacD6zAaeXItaPfxxxKUHZaOw==

KEY_BASE64 ND+vzFOdhl1VVtEMN9Geeb8nTGrHNnJFrGTayBaqAMw HMAC_KEY_BASE64

RQVZaZ05WYwtLdGexq6wFExrLQf2b723GQTxbfpQjJLKvTd8vxl3KeobijA1J6UDGJZHzZtV5VniitiRpyrRMw==

Behaviour of Port-knocking authentication mechanism

Author: Petko Gerdzhikov Supervisor: Ola Flygt Semester: VT 2016

Subject: Computer Science

Bachelor Thesis Project

Behaviour of port-knocking

authentication mechanism

Contents

1 Introduction

2 Method

3 Port-knocking

4 Experiment results

5 Analysis

6 Discussion

7 Conclusion

References

A Appendix 1