Author: Petko GerdzhikovSupervisor: Ola FlygtSemester: VT 2016Subject: Computer Science

Bachelor Thesis Project

Behaviour of port-knockingauthentication mechanism

Abstract

Port-knocking is a security mechanism used in computer systems to hide availablenetwork services. Its operation relies on a drop policy firewall setting in order tomake impossible for port-scanning attacks to occur. This project researches the im-pact of implementing such a software solution. Furthermore, it looks into the be-haviour of three chosen implementations and make conclusions on the benefits anddisadvantages that they bring. In addition, the surrounding implications related toboth user and administrator are explored. This thesis includes tests on the resourceconsumption of the implementations as well as records of the added delay of usingthe mechanism when initiating a SSH session. There has not been such researchperformed 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 ofthis study state that port-knocking is overlooked and has great benefits in preventingzero-day exploits and hacker tools relying on exposed network services.

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

Contents

1 Introduction 11.1 Background and history . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Previous research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Problem formulation and motivation . . . . . . . . . . . . . . . . . . . . 21.4 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Scope/Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.6 Target group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Method 42.1 Scientific approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Hardware load experiment . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Response time experiment . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Multiple client behaviour experiment . . . . . . . . . . . . . . . . . . . . 52.5 Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Port-knocking 63.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Knockd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Fwknop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 Knockknock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.5 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Experiment results 104.1 Single client hardware experiment . . . . . . . . . . . . . . . . . . . . . 104.2 Single client response time experiment . . . . . . . . . . . . . . . . . . . 124.3 Multiple clients behaviour experiment . . . . . . . . . . . . . . . . . . . 15

5 Analysis 175.1 User experience analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Hardware analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Discussion 20

7 Conclusion 217.1 Future research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

References 22

A Appendix 1 A

1 Introduction

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

Throughout this paper, the behaviour of this security mechanism is going to be thefocus. Different aspects ranging from the theoretical limitations to actual results from ex-periments on available implementations are going to be presented in a structured manner.In addition to standard port-knocking solutions, this report also examines Single packetauthorization or SPA, which is considered similar to port-knocking (PK). Whereas thereare differences in the execution, both mechanisms carry out the same functions and theyare 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 asecurity authorization mechanism. Its goal is to provide integrity and concealment whenaccessing services on remote nodes. Although, this concealment is often misinterpretedas obscurity. With port-knocking the system does not rely on open network ports inorder for a service to be reached. Instead, the implementation of the mechanism worksin tandem with a firewall solution that handles the access control parameters and a policyfor 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 rulesin order to allow the client to access the originally desired service.

The concept behind this security mechanism goes way back to the beginning of the21st 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 reasonsfor leaving open ports constantly on a system to have services available. He saw that asa problem and proposed a solution that is very similar to the modern day port-knockingthat we use today. The title “port-knocking” was first brought onto the world by MartinKrywinski in 2003 [2]. Then he was talking about the idea that by sending packets topredefined network ports, you could form a combination or a ‘secret knock’ that wouldtranslate 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 thedifferent features of several port-knocking implementations and have graded them cor-respondingly. This report would like to expand on that document by shifting the focustowards the behaviour aspect and the real implications of introducing a port-knocking so-lution to a physical system. Furthermore, the project by Sebastien Jeanquier [4] has beenfound to be close to the field of study presented in this report and has served as a startingpoint in the performed research.

1

1.3 Problem formulation and motivation

By inspecting the design of port-knocking, we can see that is a neat solution to a problemrelated to accessibility and protection of remote services. However, there are varyingopinions regarding the benefits that it offers. Some authors claim that the method is boundto cause more trouble than it provides security [5], whereas others suggest that it can serveas a successful most outer layer of defence [4]. With that in mind, the goal of this thesisis to abstract itself from this dispute by taking a more practical approach and study theactual impact of implementing a port-knocking solution. In this way the study will befocused more on the user experience aspect than theoretical capabilities. The results thatwould come out of setting up and testing real port-knocking implementations should shedmore light on the choice that a system administrator would make regarding this additionallayer 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 orderto accomplish this, there would be a controlled environment setup, where one wouldcompare and contrast each implementation separately against a system that does not runport-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 thebehavior 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 significantload on the running system. Moreover, handling multiple clients should be in the scopeof capabilities of the examined implementations. On the subject of network security,regarding this mechanism, the expected results should reinforce the idea that this methodcould 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 theresearch 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 andsingle packet authorization implementations. Hence there must be a certain aspect of thisbehaviour that is going to be the focus. For this study the implementations are evaluatedbased on their hardware performance and response time. Furthermore, any features orcomplications regarding the operation and maintenance of these mechanisms is also ofinterest.

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

2

the selection was primarily based on popularity. This report covers two port-knockingand SPA solutions - knockd and fwknop. In addition, another PK implementation by acomputer security researcher known as Moxie Marlinspike is also being examined andcompared. 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 languagethroughout the paper strides to be as basic as possible. However, this report aims toinform people that are interested in advanced network security mechanisms and thereforeprevious knowledge in computer science is recommended. Moreover, the target groupthat this work might be of most value to is personnel that is currently working on anadministrator position or responsible for network security in general.

3

2 Method

This chapter of the report is dedicated to describe the procedures that were performed inorder to find answers to the aforementioned research questions. Furthermore, a statementabout 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 au-thentication mechanisms, a quantitative approach was utilized. This implies that numer-ical data is gathered and analyzed. The study focuses on experiments with actual imple-mentations, where their performance is evaluated and compared against one another. Theresearch also draws and reinforces conclusions made beforehand from previous work onthe subject.

2.2 Hardware load experiment

In order to fulfil the quantitative approach that is used to prove the afore set hypothesisfrom the previous chapter, the experimental method has been selected. With regard tothe behaviour of the implementations, this experiment aims to showcase the system loadvariables. For that purpose the hardware performance of the test platform is evaluatedfor each separate implementation. To define hardware performance the following metricshave 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 inthe behaviour of a system. By examining them, conclusions about the effects of the soft-ware could be drawn. The experiment has been performed in instances of 100 for each ofthe chosen implementations utilizing an expect script. During this, the hardware perfor-mance of the test server, running the PK/SPA solution, has been recorded and stored. Theapplication 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 saidexperience, the response time is one of the most valued criteria when comparing applica-tions. For that reason, a quantitative approach in the form of experiment has been electedto study the area. Each of the selected implementations has been assigned to make aknock and SSH request to the test server 100 times. The measurement of the responsetime was held on the client side. The procedure involves taking a time-stamp from theinitialization 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 describedexperiment.

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

4

2.4 Multiple client behaviour experiment

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

The behavioural aspect is observed again from a hardware and response time perspec-tive. The testing environment features one machine acting as a server and four clientcomputers. The experiment itself involves the sending of a knock and establishing a SSHconnection to the server from all the clients at the same time. To aid the synchronizationof 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 toensure simultaneous authorization attempts. During the execution of the experiment theclient output has been recorded and monitored for irregularities in the operation of theknocking process or the establishment of the SSH connection. Moreover, the server hashad 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 thesystem specifications in Table 4.1 have been followed. The methods used to collect thedata, such as the monitoring tool atop, do not cause inconsistencies given the measuredmetrics. Furthermore, the results should be considered valid, since the outcomes andconclusions that have been displayed rely on unbiased numerical data gathering duringthe preparation of the report.

5

3 Port-knocking

The following gives an overview in addition to the general benefits and flaws that areaccompanied 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 occursbetween two nodes. In Figure 3.1 the transaction model is presented. In the authenticationprocess there are two actors - the client and the server. The server is running a servicethat a remote client would like to utilize. As an example there is SSH - network protocolused 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 ofSSH (Secure Shell protocol), port 22 has been assigned. In this example, these accessrules are being governed by a firewall solution that is operating on the server. When theclient sends the request, the firewall makes a decision based on said pre configured rulesand 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 num-bers. The client would have to attempt to connect to these ports in their correctly givenorder. This combination serves as the secret “knock” that would open a service on theserver-side. In Figure 3.2 a port-knocking request could be observed. The client makesconnection 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 dropall 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 systemand 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”, theport-knocking application would make modifications to the firewall rules on the serverand 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. Aswith port-knocking there are two actors - client and server. Instead of using a sequence offailed connection attempts, however, only a single UDP packet is being sent by the client.

6

This packet contains specifications of the service that is desired, such as port number andtransport layer protocol. Furthermore, the security details of the encryption that have beenagreed 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 providean additional security layer. Different implementations offer different capabilities and thechoice of the most suitable one for a certain system could have impact on the system’sbehaviour. This thesis project examines three open source applications - knockd, fwknopand knockknock.

3.2 Knockd

Knockd is a port-knocking application that follows the original model of “knocking” theclosest among the chosen implementations for this project. The server daemon couldoperate on a *NIX system only. In the case of monitoring, it works by inspecting thesystem log of the system for connection attempts. This monitoring is made possible withlibpcap network framework. Moreover, knockd works in conjunction with the firewallsolution 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 accessfile, which holds the port-knocking sequence among other options. An administratorcould set up multiple sequences that correspond to different commands that the PK dae-mon could execute. Furthermore, there is the possibility to set a timing window for eachcommand. Another property that could be configured is related to the set TCP flags of theincoming potential knocks [7].

The “knocks” that a client performs could be either TCP or UDP frames directed toa network port on the server. There is no additional characteristics that must be appliedto 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 nameof knock by the same author.

3.3 Fwknop

This application implements the Single Packet Authorization scheme for providing secu-rity 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 supportedby Windows, iPhone, Android or Cygwin. Fwknop relies on the library libfko, which isdeveloped especially for the project. The libcap features are utilized to monitor the trafficto the system. Moreover, the implementation is designed to operate alongside an iptables,ipfw or pf firewall solution [8].

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

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

7

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

3.4 Knockknock

Knockknock is a project developed in python to improve on the original port-knockingauthentication 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 operatingsystem.

The server daemon in this implementation monitors directly the kern.log log file forthe “knock” of the client. When such packet has found, the daemon makes the appropri-ate changes to the firewall - in this case iptables. The structure of this packet is basedupon previously exchanged parameters between client and server. Moreover, this is donemanually when configuring the client platform. Each client implementation has a profilecontaining the cipher key, HMAC and the internet port they would like to use for theirrequests. These pieces must be present on the system running the server in order for theimplementation to operate.

3.5 Security considerations

When looking at the operational model of port-knocking there are some arising concernswith accessibility. The implementation of such security mechanism is introducing anapparent “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 functioningproperly. Furthermore, any irregularities or failure of said daemon could render the systemclosed-up and would require physical personnel to attend and resolve the issue. From thetested implementations only fwknop has a fail-back sequence programmed [11], which isachieved by event-based monitoring daemon - upstart.

A security consideration that has been brought up by the creator of knockd is relatedto DNS traffic [7]. The problem originates from the design of the implementations whenit comes to resolving domain names. Since iptables requires an argument in the form ofan 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 sys-tem that includes port-knocking. This is due to the danger of the knock sequence beingmonitored and then replayed. If that scenario occurs, it would make the whole mecha-nism obsolete and would risk exposing the services to an attacker. With knockd this is areal 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 textwhen trying to authenticate with the server. On the other side, fwknop and knockknockmake use of encryption for their exchanges. The single packet authorization applicationfwknop utilizes the Secure Hash Standard [12] and in particular SHA-256 in combinationwith HMAC (Hash Message Authentication Code) [13]. These algorithms are highly re-garded and approved by the National Institute of Standards and Technology, also knownas NIST. The same security mechanism is also implemented by knockknock. With such

8

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

One of the biggest controversies surrounding port-knocking is the fact that is con-sidered to be “security through obscurity” [5]. What that implies is that the defensivecapabilities of this mechanism are due to keeping the way of operation of the system asecret. While this is partly correct, the fact of the matter stays that the system and each ad-ditional layer of security must be looked as a whole. The article by Jay Beale [14] bringssome important points in understanding the benefits of obscurity. It highlights some of themajor threats that port-knocking deals with, for example raising up the awareness level inthe system in case of an attacker trying to overcome the authentication. Furthermore, asystem protected by a port-knocking mechanism eliminates some of the tools that couldbe 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 theirdesign. 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 withunderstanding the mechanism’s purpose and design. The design of the implementations isopen to look at by everyone and therefore cannot be stated that the security that it providesis merely obscurity. The purpose of port-knocking is that of concealing a system.

9

4 Experiment results

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

SERVER CLIENTSProcessor Intel(R) Core(TM) i7-3537U

@ 2.00GHzIntel(R) Core(TM) 2 CPU6300 @ 1.86GHz

Memory 3930 MB 1024 MBOperating system Ubuntu 14.04.4 LTS Ubuntu 14.04.4 LTSKernel 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 CorporationNetXtreme BCM5754

Table 4.1: Server and client specifications reference

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

fwknop knockd knockknock

CPU (busy) 0% 4% 0%

Virtual memory size8752 49296

10972(Kbytes) 40712

Resident memory size8348

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 structuredinto tables. As it can be seen in Table 4.3 and Table 4.4, each implementation has acolumn corresponding to the values derived from the experiment. These digits representthe average value that was calculated for the hundred port-knocking attempts. Due to thefact that both knockd and knockknock spawn multiple processes, two separate values areshown in the tables.

10

fwknop knockd knockknock

Virtual memory size8752 49552

10972(Kbytes) 0 114440

Resident memory size3800 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 in37.14 4.06

1.23user mode (clock ticks) 39.75 0.19

CPU-consumption in206 2.36

3.53system 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 themilliseconds spent on disk operations for each instance of a knock - SSH attempt. Thevertical values represent the number of time spent on I/O operations during the singleclient experiment. Throughout the horizontal axis, the progression of each attempt can beseen.

11

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. Thedata is structured in Figure 4.4, Figure 4.5 and Figure 4.6, where there is a separate graphfor each implementation. In addition, Figure 4.7 combines all of the previous results forimproved visualization and comparison. All graphs show the time in milliseconds thatit took to establish an SSH connection from the client to the server. The horizontal axisexpresses one instance of executing the experiment for response time.

Figure 4.4: knockd response times graph with single client

12

Figure 4.5: fwknop response times graph with single client

Figure 4.6: knockknock response times graph with single client

13

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

14

4.3 Multiple clients behaviour experiment

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

fwknop knockd knockknock

Virtual memory size8752 49548

10972(Kbytes) 0 335892

Resident memory size3840 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 islocated. The values are the average derived from the performed experiment instances.

fwknop knockd knockknock

CPU-consumption in230.58 0.5

1user mode (clock ticks) 230.17 0.5

CPU-consumption in1233.87 0.5

0.5system 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 operationsproved to be identical to the results of the single client experiment. Therefore, turn toFigure 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 ob-served 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 separateclients. The presented values are in milliseconds. In addition, the experiment strived tosynchronize the execution of the four clients as much as possible and the end result wasno initialization difference more than 300 milliseconds in total.

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

15

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

fwknop knockd knockknockClient 1 300 6450 350Client 2 6561 6441 864Client 3 - 6692 341Client 4 - 6400 6537

Table 4.7: Response time for performing a synchronized connection attempt

16

5 Analysis

This chapter includes analysis and conclusions, based on the outcomes produced by thepreviously described experiments. More specifically, it will give insight on the behaviourof the examined implementations. Furthermore, the results have been put through sta-tistical 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 haveconfirmed that the figures correspond to multiple different sets carrying statistical signifi-cance each.

5.1 User experience analysis

Implementing additional layers of security to a system usually implies that the complex-ity of said system would increase and the user satisfaction would detriment in some wayas a consequence. Take the simple example of securing a user account with a passwordopposed to having no need for credentials in order to authenticate. In the former, we havesubstantially increased the security properties, but we have put pressure on the personthat should use this account by having them responsible for the password. However, if weelaborate more, the user could, for example, take advantage of a password managementsystem 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 experi-ence aspect when handling port-knocking and SPA.

The impacts of not requiring a password for authentication are of course much largerthan the absence of a PK/SPA mechanism. However, the act of providing a password issimilar in a way to the initialization of a “knock”. With knockd, the client must providethe target server’s hostname or IP address as well as a predefined sequence of ports thathe has a reference of and that would allow him to accomplish his original task. In thecase of fwknop and knockknock the user must supply the hostname or IP address of theserver again, but instead of inputting a knock sequence, a network port number of thedesired service must be given. Hence, it can be concluded that the last two mentionedimplementations would be trivial to operate and would not pressure the user by loadinghim with multiple complex extra steps. Moreover, the required input for knockd, in par-ticular the knock sequence, can be closely compared to a passphrase. This brings us tothe aforementioned example of passwords and how with a password management systemwe 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, systemadministrators could turn to scripting, in order to achieve the same goal. All of the per-formed experiments have been executed with the help of scripts, which initiate the knockand perform a SSH request immediately after. Therefore, any concerns that port-knockinghinders the user experience by introducing additional complexity to the system could beput to rest.

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

17

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

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

5.2 Hardware analysis

Computer systems operate with finite resources. Furthermore, the management of theseresources 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 lim-itations of a device. Therefore, the hardware load caused by implementing an additionallayer of authentication should not be of major impact to the performance. The performedexperiments strived to break down the different aspects of hardware impact and conse-quently have showcased the memory usage, CPU load and disk operations.

By examining the resources that the implementations consume when they are func-tioning in an idle state, presented in Table 4.2, it could be seen they are not necessarilydemanding. Memory usage for knockd and fwknop falls between the range of 7 to 12megabytes, which is completely negligible for today’s standards. Moreover, the combina-tion of the two processes that knockknock utilizes amounts to roughly 100mb and wouldstill not cause strain to a modern system. However, by inspecting the CPU values someconcerns could be raised. While fwknop and knockknock displayed no processor activitywhile idle, the fact that knockd loads 4% of the processing unit while in idle state bringsup some problems with the implementation. As a supposed lightweight application thatamount of strain seems out of place. Granted the software performed the best in terms ofmemory usage, CPU management is crucial in server-based devices and the software theyutilize.

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

18

mentation, it can be said that knockd requires double the memory space of fwknop. Forthe third application - knockknock the variance is much greater. While the previous twodisplayed consistency of memory usage in the three tested states - idle, with single clientand multiple clients, this port-knocking solution exhibited different values across the ex-periments. With the two processes that it spawns it proved to be the most demanding outof the bunch. Regarding virtual memory, the first process alone showed that it occupies50 megabytes, which is more than the other two implementations combined. Moreover,the second process related to knockknock grew proportionally according to the amountof clients that were authenticating. From the single client experiment results, found inTable 4.3, it can be seen that the “knock” took 100 megabytes of memory and then whenadding more clients it rose to 335 megabytes. This can be considered a big jump in virtualmemory consumption and it should be contemplated if adding more clients would causecritical 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 processorto be occupied at all times. Furthermore, by performing authentication attempts to theserver the amount of CPU activity raises proportionally as it can be seen by comparingthe values in Table 4.4 and Table 4.6. However, the gap between 38 clock ticks for singleclient and 230 for multiple clients in user mode is not that staggering and could be consid-ered negligible. Same statement could be made for system mode where the difference isbetween 204 and 1216 clock ticks. For the two remaining implementations the processorload was virtually identical and close to none. Based on the previous statements it couldbe considered that all three applications showed no excessive CPU load.

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

19

6 Discussion

In the beginning of the project the initial idea was to shed light on this authenticationmechanism. Through experimentation with real implementations the goal that was setwas 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 forenforcing “security through obscurity”, which is generally frown upon in the securityfields. However, with the given explanations it is clear that the mechanism provides con-cealment to a system, instead of simple obscurity. Such concealment only reinforces theunderlying 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 againstzero-day exploits for the aforementioned underlying services. That sort of feat should notbe passed away with a light hand. In addition, the fact that port-knocking is of not so greatpopularity serves as an added benefit in way that it causes malicious users to re-evaluatetheir attack vectors.

A major angle that this thesis project strived to investigate was the overall effects ofport-knocking to a system that implements it. From a hardware perspective the perfor-mance 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 realserver device. On the topic of the client side in the model, with automation by scripting theimplementations will not hinder the standard operation and procedures when accessing re-mote services. In this project this is deployed with the help of expect scripts. They arestraightforward in their operation and easy to compose. The setup of the test environmentbrought some further discoveries. In the specifications for fwknop there is the option toimplement the authorization with the help of GPG keys. However, during the preparationthere appeared a problem related to the dependencies of the application. Fwknop han-dles GPG functionality with libgpgme library, but unfortunately after multiple attempts toconfigure 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. Theother issue related to fwknop and handling multiple clients also seems unclear. Duringtesting 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 theresult turned out in the inability to authenticate two out of the four clients. Whether thisis from a design incoherence or faulty set up of the environment is tough to state, but theproblem of inconsistency with multiple clients persists.

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

20

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 questionsfound in the first chapter of the report. From the final results in the research and the follow-ing analysis, it can be stated that they all found some conclusion. The presented figuresprove that from hardware standpoint the implementations do not overload the system. Inaddition, the misconception that port-knocking is merely providing ”security though ob-scurity” was discussed and an explanation to why this mechanism has no similarities withthe term was shown. Furthermore, the user experience is not affected when using remoteservices in combination with port-knocking or single packet authorization, based on theresponse 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 implementand also to address the security consideration shown in the third chapter.

As far as the tested software, when examining each individual implementation it canbe stated that knockd displayed the worst outcomes. The fact that there is no encryptionin any form makes it very dangerous to use without any additional solutions. While beingthe 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 isthat there have not been any recent updates and longevity is an issue. Thus, the bestsolution that showed greatest promise is fwknop. With the continuous support and varietyof features that it offers it seems the logical choice in the selection of a port-knockingsolution.

In conclusion it can be said that port-knocking is a rather overlooked mechanism thatcould provide additional layer of security to a system. While it has its issues, it is mostlya reliable feature that would delay or even divert a huge portion of attacks directed tousually transparent services. Its behaviour does not result in anomalies within the systemand 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 couldbe explored further. From the conducted experiments the exact cause of that occurrencecould not be pinpointed to certain factor. Furthermore, the implementations could betested 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 closerto a real-life scenario additional variables could be introduced to the testing.

21

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 ClosedPorts’. SysAdmin Magazine, pp 12:12-17.

[3] Khan, Z. A. , Javaid N. , Arshad M. H. , Bibi A. and Qasim B. (2012) , “PerformanceEvaluation of Widely used Portknoking Algorithms”, 2012 IEEE 14th InternationalConference 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 BSDGuy, 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 guideto 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 an-other 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. ‘TheKeyed-Hash Message Authentication Code (HMAC)’. National Institute of Standardsand 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

22

[14] Beale, J. (2000) “Security through Obscurity Ain’t What they think it is”. BastilleLinux 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

23

A Appendix 1

The following appendix contains the configuration files related to the tested implementa-tions.

Knockd.conf:[options]UseSyslogInterface = eth0[SSH]sequence = 7000,8000,9000seq_timeout = 10command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp –dport 22 -j ACCEPTtcpflags = syncmd_timeout = 5 stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -jACCEPT

Knockknock main config and client profiles[main]delay=15error_window=20

Client1:[main]knock_port = 1111

Client2:[main]knock_port = 2222

Client3:[main]knock_port = 3333

Client4:[main]knock_port = 4444

Fwknop access.confSOURCE 192.168.0.1OPEN_PORTS tcp/22KEY_BASE64 D/t6XA4JI/HsOPR5aDISn7ZzxjgUuZxDd/36quBJ69w=HMAC_KEY_BASE64 N6rxw49Nki5cmIf4kaPSrk9VBu46n7DkqnwK3S7ZivGu64b4pgBojEPLXkerUZQ3WC76dU2yxmsnauxkiu4Flw==

SOURCE 192.168.0.2OPEN_PORTS tcp/22KEY_BASE64 dFdH0sfjskS64BUXuK86WwrUiFM/7+l9b1dnvq077mM=HMAC_KEY_BASE64 IgMsDdX404TUicgPDZlbYVU6vp7zuCLQTBxQHcV185VVF/wFMqFsJ6BUXB3+NMpxAG7C5+5BaBpC1eAIdAfmTQ==

A

SOURCE 192.168.0.3OPEN_PORTS tcp/22KEY_BASE64 nwWmqXtoa4YAKtgFjom758b4SQFdXvZKtrEzCyPFITE=HMAC_KEY_BASE64 hbLPGz+02jxzgFWlT4caV20M09fnZJHomVFKcNF+EUlgYIcfM9rVJoJ/R3qtYKacD6zAaeXItaPfxxxKUHZaOw==

SOURCE 192.168.0.4OPEN_PORTS tcp/22KEY_BASE64 ND+vzFOdhl1VVtEMN9Geeb8nTGrHNnJFrGTayBaqAMwHMAC_KEY_BASE64RQVZaZ05WYwtLdGexq6wFExrLQf2b723GQTxbfpQjJLKvTd8vxl3KeobijA1J6UDGJZHzZtV5VniitiRpyrRMw==

B