International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No.

7 ISSN: 1837-7823

A Modified Approach to Analysis and Design of Port Knocking Technique

Rajesh Kumar Research Scholar , Department of Computer Science & Engineering NIMS University Rajasthan, Jaipur (India) Email: seemarks@gmail.com Dr.I.M.Talwar Professor, Department of Computer Science & Engineering Kurukshetra Institute of Technology and Management, Bhor Saidan , Kurukshetra ,India Email: indertalwar@yahoo.com Kapil Kumar Research Scholar, Department of Computer Science & Engineering Geeta Institute of Management & Technology, Kanipla, Kurukshetra, India Email: er.kapilkumar0001@gmail.com

Abstract
With increasing vulnerabilities, caused by port scan attacks, replay attacks and predominantly IP Spoofing , targeting services, the network behavior is getting malicious. But there is a lack of any clear threat model .The authors have endeavored to consider this problem in order to improve the network security and enhance Secure Shell Daemon protection . A mechanism , QUICKKNOCK improving upon the potentialities of technologies such as port knocking and SPA (Single Packet Authorization), has been proposed . KEYWORDS: QUICKKNOCK, SSH Daemon, Network Security, Port knock, Encryption algorithms, IP Spoofing, Key- Exchange, Symmetric Cryptography, Single Packet Authorization, Fwknop.

1.

Introduction

In the computing world , security is a crucial research area. This is because the computing world as we know has largely become a collection of technologies. A problem is caused when one of the users wants to connect to our network with bad intention . With the increasing security vulnerabilities, more and more malicious network behaviors such as replay attack Dictionary attack , IP Spoofing etc. [1]. Security attack is an action which compromised the security of information owned by an organization. If a server runs no vulnerable software, a port scan is not a serious threat, but software security is a sufficiently hard problem that this cannot be seen as an immediate solution. A popular method of protecting against such network attacks is the firewall, which simply blocks all connection attempts to internal network hosts from external ones. Since there are many reasons why it might be desirable for a given service to be externally accessible for instance, users may access a network service from a priori unknown network addresses depending on their physical location this solution is not always satisfactory. One class of proposed solutions to this problem is port knocking wherein a rewall is deployed to protect a server, and before allowing a client connection to a particular port, that client must transmit a special 28

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

knock that authenticates it. This knock may be either common to all authorized users of the system, or may be unique to a given user. Attempts to connect that are not associated with the correct knock will be dropped; thus to an unauthorized user it should appear as if no network services are running on the server. A variety of knocking methods , such as a sequence of (dropped) connection attempts inclusion of a cryptographic authenticator in the initial connection request packet [2,3] have been conjectured . Given that the goal of a port knocking scheme to conceal the set of services running on a network host, all existing implementations have a serious flaws [3]. Under relatively weak attack models, these schemes fail to conceal that a port knocking service itself is running. Moreover, on most currently deployed operating systems, exploiting a code injection attack in a port knocking service would lead to a total compromise of the host. Since the port knocking service is such a high-value target, it is that the presence of port knocking itself should be undetectable. Port knocking schemes generally use the port number within the TCP or UDP header to transmit information from the knock client to the knock server, whereas its successor Single packet authorization (SPA) scheme uses messages to be sent over any IP protocol; not just those that provide a port over which data is communicated. Improving Fwknop currently supports sending SPA messages over ICMP or TCP. We use Port Knocking and SPA interchangeably. In this paper, we have developed a formal security model that captures above notion. A formal security model is critically important in order to be certain that a given protocol, even one that seems secure at a glance, is secure in true sense. Examples of such apparently secure protocols, developed without formally stated security goals, are numerous [4,5,13], and some of them have been in operation for years (and have even become industry standards). So much so all those protocols were originally designed for security, and even used well-known cryptographic primitives, but the protocols were not secure.

1.1 Formal Definition of Port Knocking

A Port Knocking (PK) protocol is a TCP implementation , P in which both Client and Server take as additional input a secret key. We let PK (C) denote the result of the standard interaction between Client and Server where the key input to both is K [6]. We say that P extends TCP implementation W if for every command sequence C, there is an efficiently computable command sequence C such that PK (C) and W (C) are computationally indistinguishable, for uniformly chosen K. This requirement states that a port knocking protocol, in which the client and server share a secret key, should allow any communication that is allowed by the TCP implementation it extends. It has been observed that a TCP implementation is trivially port knocking protocol (insecure) with null keyspace: every TCP session is initiated when the client knocks at the server port he wishes to connect to. The Figure 1(a),(b) below describes the process of accessing PK Daemon from Client on closed Ports through UDP and TCP , the Client uses Secure Shell for

29

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

communication to PK Daemon which maintains the Security of Services that resides on Server . There is also the inclusion of Firewall to check the Malicious User (Attacker )on the Server Side .

Figure 1(a) Port Knocking

Figure 1(b) Port Knocking Authentication

2. System Design
In this section we introduce and discuss QUICKKNOCK, we shall show implementation of a secure port knocking scheme, and discuss how this enhanced security model implementation to avert a number of limitations of previous system which only attempt to authenticate the start of a connection [6], but provides no guarantee that connections stay authentic. In other words, previous implementations does not protect against such as connection hijacking (a well-known problem in TCP security ) IP Spoofing attack protection, client/server synchronization, and

indistinguishability [7]. Next, we analyze a number of possible attacks on our implementation. Finally, we present results showing our system in action. 2.1 Universal Compatibility We provide ease-of-use (for end-users, system administrators, and programmers)

by choosing an application-agnostic design. The Kernel Module part gives increased speed and efficiency over the user-space part . This approach allows any application to transparently use QUICKKNOCK provided that the network protocol used by the application has a steganographic embedding/extraction method supported by QUICKKNOCK . We note that for certain protocols, such as TCP, with many implementations that may have subtle differences, each implementation may require a different steganographic embedding routine to preserve indistinguishability. Our goal is to support as many transport protocol implementations as possible, although currently only TCP under RHEL 5.4 is supported. 2.2 Design Choices Our implementation is designed to run on the Linux operating system with a 2.6.18.164.el5

kernel. We chose Linux 2.6.18.164.el5 due to our familiarity with the system and the availability of the netlter/libIPQ API[8] which allowed us to implement our system entirely in user space instead of modifying the

30

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

operating system. We use Poly1305- AES [9] as our MAC function since it is optimized specifically for network packets and has very fast implementations available for most processor types.

3. Protocol
The QUICKKNOCK Pseudo Code is outlined in Figure 2. which has the enhanced capability and reliability to the previous Implementations [1,6,12,13]. A QUICKKNOCK client initiates a connection (composes a TCP SYN packet) to a QUICKKNOCK-enabled server and steganographically embeds an authentication token into the packet. The embedding algorithm and resulting packet header structure are described in Figures 3 and 4, respectively. The server receives a SYN packet and extracts the authenticator. Ifcation is successful, the server allows the veri connection to continue, otherwise the packet is dropped. The client and server share a key, as well as a counter which is incremented for every client connection attempt. The counter prevents IP Spoofing attacks by ensuring that every SYN packet sent by the client is different from any packets sent previously, and is also used as the nonce required by our MAC function. The key, initial counter, and resynchronization interval are exchanged out of band, since negotiation is impossible in case of one-way communication. 3.1 MAC A Message Authentication Code (MAC) is a short piece of information, similar to a hash code which provides both origin authentication and integrity protection of a message. MACs are generated by

block ciphers and use symmetric secret keys to ensure that only those who know the key can modify, or verify the message. 3.2 Steganography and Indistinguishability. We use the TCP sequence number and timestamp elds of the TCP SYN packet to embed our Information. The Pseudo Code is as under regarding packet movement .

1. Y 2. X 3. Y

X : Ny, MACKreq (NY, NX, IDX, req) Y: MACkreq (Nx , Ny, IDy, req) X: MACK,ctrY(l) ; encoded in TCP/IP headers of SYN Packets ctrx+1

4. X : Set ctrx for i=0 to ft

if ((MACk,ctry -1 + i (l) =MACk, ctr(l)) Set ctrx X ctrx + i Y : SYN-ACK goto 7 5 : Y : If ( SYN ACK received ) then +1 ; resynchronizes counter if client is ahead

31

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

Set ctry

ctry + 1 , goto 7; connection successful

6 : Y : if (SYN-ACK) not received ) then Set ctry goto 5 7: X,Y : proceed with TCP connection if (FIN or RST received) then goto 1 ctry + 1; considering server recieves SYN, but SYN-ACK was lost

Where X is the server Y is the client req is a request for authentication Nx is a nonce chosen by X Kreq is a secret key shared by A and B IDx is the IP address of X

ctrP is a per-IP- address counter maintained by principal P k is a value derived from Ys IP address and a symmetric key shared between X and Y l is a TCP ow identier ft is a failure-tolerance parameter. MAC is a cryptographic message authentication function , (a comma) represents concatenation Figure 2: The Pseudo Code for Proposed QUICKKNOCK One issue that arises when using the TCP timestamp eld to encode MAC data is the possibility of lost SYN packets. However, TCP requires that re-transmitted SYN packets have the same sequence number but different timestamp [10], so we can no longer encode stegotext in the timestamp: if the SYN packet was lost due to a malicious host, or if an adversary is observing all SYN packets, that adversary would detect that the least signi cant byte of the timestamp in the original and re-transmitted SYN packets are identical. The probability of this is only 1/256, so the adversary could conclude that QUICKKNOCK was in use. To solve this problem, we ensure that the last byte of the timestamp looks random to our malicious user, even when we are trying to re-transmit the same MAC. We can use two existing properties of our system to help us, the rst having originally caused this problem: the higher order bytes of the new timestamp must be different from the one in the original SYN packet. Secondly, we do not transmit the entire MAC. As in Figure 3 below 32

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

S : TCP SYN packet Sseq = {P1, P2 , P3 , P4 } : Sequence number of packet (4 bytes) Stp = {T1 , T2 , T3 , T4 } : Timestamp of packet S (4 bytes) l = (IPY , source port, IPX , destination port) : Authenticator MACK,ctr (l) = {L1 , L2 , . . . , Ln} : n byte MAC P2 = L1 , P3 = L2 , P4 = L3 T4 = hl ({T2 ||T3 }) : n-Universal hash function Figure. 3.The steganographic encoding protocol. Decoding is performed by reversing the operations in this protocol. We implement Murdoch and Lewis system for embedding steganographic information into TCP initial sequence numbers (ISNs) and use the TCP timestamp option (enabled by default in Linux Kernal) to embed an additional byte of information into the timestamp, delaying packets when needed [11]. 3.3 Counter management Scenario To protect against IP Spoofing attacks, we employ a per-user counter, incremented after every connection attempt. If a given user has never before accessed a QUICKKNOCK-protected server, the counter is initialized to 0 by both the client and the server. The counter poses additional challenges, such as what happens when the client and server counters become desynchronized. Desynchronization can occur in two ways: either the clients SYN packet never reaches at the server, leading to the client having a counter higher than the servers, or the servers SYN-ACK can be lost, meaning the client and server are actually in sync, but the client does not know this. The Packet Header Structure has been from the Source Port to Packet Destination Port which has been adjusted with Internal Consistency which handles the synchronizations of Packets with reliable and efficient manner as well as Timestamp Scenario has been properly been synchronized. As given below
Packet From Source Port Adjusted for Internal Consistency Sequence No. Packet to Destination Port MAC bytes 1-3

Acknowledgement Number Offset Checksum Timestamp Scenario Timestamp Echo Response Reserved Flag Urgent Pointer Encoded MAC bytes 4 Window

Figure. 4. The TCP SYN packet after steganographic embedding. A client would have a hard time attempting to resynchronize after a failed connection, since the client does not know whether the server received the SYN packet and verification failed, or whether the server received and veri the ed 33

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

SYN packet but the SYN-ACK was lost, or whether the SYN never arrived at the server[6]. We allow an enhanced approach for and automatic in-protocol resynchronization after a certain time period. Figure 5 and 6 shows the synchronization and authentication as well authorization of Packets between client and server vice-versa, as below

Figure. 5 Synchronization from Server to Client

Figure.6 Synchronization from Client to Server

For this purpose, we enforce the equation ctrserver ( qkknockd ) ctrclient ( knockSquid) by having the client always increment its counter when sending a SYN packet. The server, however, will only increment its counter upon successful MAC validation, to prevent malicious de- synchronization by sending bogus packets to the server. In the nave scheme of insisting the counter be exactly right, the server and client may never again get into sync once desynchronized, since the client will increment its counter on each connection attempt, but the servers counter remains the same.

4. System Architecture
The QUICKKNOCK system is composed of two separate programs - qkknockd (server side), and knock Squid (client side). Connections are authenticated on a per-ow instead of per-source (IP address) basis. The Synchronization of Packets at client is modified whereas on server side remains unchanged. On both client and server side, we only send packets we are potentially interested in to user space, to avoid excess context switching between user-space and kernel-space. Both qkknockd and knock Squid currently detect closed connections as far as the Port knocking based features are concerned. 4.1 Knock Daemon (Server). qkknockd, the server side of the QUICKKNOCK system, listens for connections on a port it reads from its cong uration le (the port offering the protected service, i.e. SSH on port 22), and examines incoming SYN packets on those ports before the TCP/IP stack sees them. When a packet is received, qkknockd checks the source IP address of the packet and picks up the secret key as well as the counter for that IP address from its conguration le (per-user shared keys are also supported). Using the TCP steganographic algorithm, qkknockd extracts stegotext from the packet, treats it as a MAC, and attempts to verify it. If verification is successful the packet is accepted. 34

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

4.2 Knock Squid (Client) Knock Squid reads a configuration file to nd out which servers supports QUICKKNOCK, and for which services e.g IMAP,POP,SSH etc. The conguration le also includes the key shared with the server, and the last value of the connection counter (if this is therst time connecting to that server, the counter is initialized to 0). The number of initial netlter rules is linear in the number of QUICKKNOCKprotected services that might be contacted.

In the Figure 7 the client communicates with server . The Server creates a SYN Packet , Knock Squid recieves packet before its departure. Further, the server receives packet and its daemon gives it to the server . After successful picking up and verification of MAC , the packet is sent to application via kernel . The qkknockd after acceptace of SYN Packet does not examine other packets . However, Knock Squid rewrites incoming and outgoing packet preventing client TCP Stack from getting disturbed due to Sequence Number mismatch.

5. SPA with PSAD and IPTABLES based Secure Packet Synchronization

Good network security begins with a properly configured firewall that is only as permissive as absolutely necessary in order to allow basic network connectivity can detect various types of suspicious traffic, and services. In its current incarnation, PSAD (Port Scan Detector) such as port scans generated by tools like Nmap Figure 7 shows for

various backdoor programs, Distributed Denial of Service (DDoS) tools, and efforts to abuse networking protocols.

35

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

Figure 8: Nmap (Network Mapping ) with IP address scanning

5.1

Visualization of Malicious Packets using iptables Policy Configuration

Port scans are an important technique for interrogating remote targets, and PSAD was developed primarily with the goal of providing advanced port scan detection for Linux systems. Fundamentally, psad is a log analyzer. It assumes that the iptables policy on the system where psad is deployed is configured in a log-and-drop stance. This

ensures that iptables only accepts those packets that are strictly necessary for the network to function; all other packets are logged and dropped. Port scans, probes for backdoor programs, subversive application commands, so iptables logs derived from such a policy can commonly provide a valuable supplement to a dedicated intrusion

detection system.Because psad is strongly tied to the iptables firewall, it has not yet been ported to oper ating systems other than Linux. We deploy it on a syslog server that is running a different operating system and that is accepting iptables log messages. What we need to see is the distribution of byte values across each byte position in a large sampling of SPA packets. That is, for the first byte in each packet across our sample, can we find a relation to any of the other first bytes in the other packets? This process needs to be repeated across all bytes in every packet We use Gnuplot to visualize the byte distribution across two sets of 20,000 encrypted packets in the script below using 3D visualization. The shell script below shows us malicious packet movement. If Gnuplot shows any recognizable features or relationships across our sample sets, then we know that we have more work to do: [spaclient]$ for ((i=1;i<=20000;i+=1)); do fwknop -A tcp/22 -a 192.168.100.1 -D 192.168.100.1 --Save-packet -Save-packet-file spa_artifacts.pkts --Save-packet-append --get-key spa.pw --Include-salted --Include-equals > /dev/null;echo $i;done [spaclient] $head n 2 spa_artifacts.pkts U2FsdGVkX1/s7OmvQtYk9UnQuGg8htJ+19pru9NdhflmGhS9d/9fFET7jnPKWsk3/lnd CbGprkkUBkEYXNORP8RU8ZhkCS+pexZ2J+FbQzmwiuD7/9nA1DAmBGnUQi7mLyZYtOGm iCa8yL9IaP43DVhMflAEf+tQGaPw5xUd2/0= U2FsdGVkX18NuTMq50ef6hjD0t16ZUnKrVYjirVW81UIRNDfclS812vZAWTdcio8t3GC

36

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

QVxZz/uwrJsjkzevD0OhxJhba+CQVeKuJpfUOhskDQMtYDcH2hkGeDRK9Oc6AfLjO5Fd JXxBJuf8pmxfLC2iWkfAfooCJpjkOm+afH4= [spaclient]$ ./base64_byte_frequency.pl spa_artifacts.pkts [+] Parsing SPA packets from: spa_artifacts.pkts... [+] Writing 2D results to: spa_artifacts.pkts.2d... [spaclient]$ cat > spa_artifacts_2d.gnu GNUPLOT reset set title "2D SPA packet randomness (artifacts included)" set terminal png transparent nocrop enhanced set output "spa_artifacts_2d.png" set xlabel "Time interval" set ylabel "Packet Frequency" plot 'spa_artifacts.pkts.2d' using 1:2 with lines title '(Time interval l,Packet Frequency)' [spaclient]$ gnuplot spa_artifacts_2d.gnu [spaclient]$ ls -atlr *png -rw-r--r-- 1 mbr mbr 5977 2008-09-14 09:31 spa_artifacts_2d.png We will perform our own analysis of the cipher data sets (20,000 packets each),We need two capabilities: 1) the ability to automatically generate 20,000 encrypted packets with the fwknop client and store them in a file (one packet to a line), and 2) the ability to parse the file and count the number of different characters in each byte position across all 20,000 encrypted packets and print this data to a file so that it can be graphed. Each packet is encrypted in this case with the Rijndael cipher, and we use the --Include-salted and --Include-equals command line arguments to produce encrypted packets that are compatible with fwknopd servers.

37

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

6. CONCLUSION AND FUTURE RESEARCH

The schemes used in the existing PK/SPA implementation were flawed and vulnerable to password search and MITM connection hijacking as well as IP spoofing. On top of that, there is no guarantee of backward and forward secrecy since the same keys are used. By utilizing machine generated QUICKKNOCK communication ,we have designed a more secure SPA authentication scheme that withstands those attacks and capable of recovering from packet loss differentiating Port Scans and Port Knocks . In addition to this Port Knocking based algorithm/method has been developed differentiating port scans and port knocks. There is also an improvement avoiding code complexity in implementations for embedded Port Knocking techniques such as Symmetric and Asymmetric ciphers and algorithms such as SHA-256 etc, packet sniffing as far as malicious user is concerned . However, Our scheme does have drawbacks. Our scheme is unable to ignore IP address that have flooded fwknop with bogus packets and there is need to Develop a benchmarking to find the current bottlenecks in the fwknopd Server as well as there is no current capability to generating large number of valid SPA packets in order to benchmark the fwknopd deamon. Our scheme is more rigorous as compared to existing implementations .We need

38

International Journal of Computational Intelligence and Information Security, September 2012 Vol. 3, No. 7 ISSN: 1837-7823

yet to address and sort out above mentioned security issues . Our future work is to be focused on Mobile communication network using technologies such as One Time Knocking using SPA and IPsec ( IPv6).

REFERENCES
[1] Sebastian Janquier (2006) An Analysis of Port Knocking and Single Packet Authorization : Masters Thesis University of London . [2] Barham, P., Hand, S., Isaacs, R., Jardetzky, P., Mortier, R., Roscoe, T.: Techniques for lightweight concealment and authentication in IP networks. Technical Report IRB-TR-02-009, Intel Research Berkeley (July 2002). [3] Krzywinski, M.: Port knocking: Network authentication across closed ports. SysAdmin Magazine 12(6), 1217 (2003)], [4] Fluhrer, S., Mantin, I., Shamir, A.: Attacks on RC4 and WEP. RSA Laboratories, Crypto(2002). bytes 5(2)

[5] Bleichenbacher, D.: Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS# 1. In: Krawczyk, H. (ed.) CRYPTO 1998. LNCS, vol. 1462, pp. 112. Springer, Heidelberg (1998). [6] Eugene Y. Vasserman , Nicholas Hopper , John Laxson , and James Tyra SILENTKNOCK: Practical, Provably Undetectable Authentication Vol 8, pp. 121-135(2009). Available at http://sclab.cs.umn.edu/node/151 [7] Bellovin, S.M.: Security problems in the TCP/IP protocol suite. SIGCOMM Comput. Com- mun. Rev. 19(2), 3248 (1989). [8] Welte, H., Kadlecsik, J., Josefsson, M., McHardy, P., Kozakai, Y., Morris, J., Boucher, M., The netlter.org project, http://www.netfilter.org/. Russell, R.:

[9] Bernstein, D.J.: The Poly1305-AES message authentication code. In: Gilbert, H., Hand- schuh, H. (eds.) FSE 2005. LNCS, vol. 3557, Springer, Heidelberg (2005). [10] Postel, J. (ed.): Transmission control protocol (1981), http://www.ietf.org/rfc/rfc0793.txt. [11] Murdoch, S.J., Lewis, S.: Embedding covert channels into TCP/IP. In: Barni, M., Herrera- Joancomart, J., Katzenbeisser, S., Perez-Gonzalez, F. (eds.) IH 2005. LNCS, vol. 3727, pp. 247261. Springer, Heidelberg (2005). .

[12] Juin-Hau Liew One-Time Knocking Framework using SPA and IPSec, ICETC, vol 5, pp 209 213
(June 2010). Available at http://ieeexplore.ieee.org/xpl/login.jsp [13] Smits R., Jain D., Pidcock S., Goldberg I., Hengartner U. Bridge SPA: Improving tor bridges with single packet authorization (2011) Proceedings of the ACM Conference on Computer and Communications Security, pp. 93-101.

39