Forum Thread: Port Knocking

Introduction to Port Knocking

In computing, port knocking is a method used to open ports on a firewall by a set of connection attempts launched over closed ports. When the correct connection sequence is received on the server, the firewall rules are modified dynamically to allow the host that sent the packets to connect to a specific port (s).

The main purpose of port knocking is to prevent port scans to a specific computer to avoid potential attacks on vulnerable services. This is achieved since, unless the correct knocks are sent, the ports will appear as closed to anyone who launches a scan on the computer. A 'port knocking' is similar to a handshake and consists of a series of TCP, UDP or even ICMP packets each directed to a specific port on the target machine. The complexity of 'knock' can range from a simple list of protocol-port packets to a complex hash encryption controlled by source IP and / or other factors.

Example: A sshd daemon configured by default will listen on port 22. We configure the firewall to close port 22 and select the sequence TCP-100, UDP-200, TCP-300 that will enable port 22 in knocks. machine. The port will remain closed until a user attempts to initialize TCP and UDP connections to ports 100, 200, and 300 in that order. In this case, the port will open for a certain time interval. Otherwise, the user will receive an RST / ACK packet when initializing TCP connections to port22.

But Port Knocking has some weaknesses:

• An attacker who does not know the sequence of 'knocks', by brute force, could get the required sequence to enable a certain service.

• Monitoring communications, an attacker could try to detect a sequence of ports to reproduce later against the server to gain access to the protected service.

• The port knock sequences can be encrypted and there are several implementations that can be found at www.portknocking.org. But each packet sent can contain only two bytes of information due to the 16-bit size of the port fields in the TCP and UDP headers. Therefore, to send an encrypted sequence, using for example a 128-bit symmetric algorithm, a port knock sequence would be made up of 128/16 = 8 packets. Here we encounter a possible problem of messy delivery of packages since in this case there is no client-server connection (type TCP). A half-second delay can be added to avoid this problem, and in this case the delivery time of the sequence would reach 4 seconds. But if you choose to use asymmetric encryption algorithms, the amount of bits to send is larger and the delivery time of these packets becomes excessive and impractical.

Conclusion: Port knocking provides some advantages that increase security, but it also has some serious limitations that must be taken into account. SPA (Single Packet Authorization) is a relatively new protocol that maintains the benefits of port knocking but solves some of its limitations.

Description of SPA (Single Packet Authorization)

SPA is a variant of port knocking where only a 'knock' is needed to validate the request. This knock consists of an encrypted package.

SPA offers an architecture similar to that of port cknocking:

1. Both have client and server components,
2. The server manages the default filter control to DROP
3. The server monitors passive packets.

-But this is where the similarities end.

The main advantage of SPA is that the amount of information that can be included in the package is only limited by the MTU. This advantage allows that SPA can be included in the packet not only access information, but also for example, commands that are executed in the SPA server.

In short, SPA provides a level of security similar to port knocking in terms of protecting a service with packet filtering on a system with a default policy from INPUT to DROP. In this environment, anyone who performs a scan to the machine would not be able to detect if a service is actually active in it, which makes it difficult to exploit many vulnerabilities. SPA offers an elegant solution to the limitations of port knocking.

Let's see through a practical example how to use fwknop in Single Packet Authorization mode to protect and provide access to the OpenSSH daemon.

• fwknop defines the following packet format in the application layer:

• 16 bytes of random data
• Client user name
• Client timestamp
• Version fwknop
• Mode (access or command)
• Access (or a command string)
• Summary MD5 / SHA

Once the fwknop client builds the package with the above fields, the entire package is encrypted using a symmetric key algorithm (128 bits) or asymmetric (using GnuPG with a key length of 1024-4096). By default, the client will send a UDP packet to port 62201, although this can be easily modified (by using the --Server-port parameter)

The following is an example of fwknop installation, configuration and testing:

We will have to have it installed GnuPG on both the server and the client.

• Install the OpenSSH server

# apt-get install openssh-server

• install fwknop:

# apt-get install build-essential libpcap-dev mailx

• install fwknop on the server:

In this case, we installed version 1.9.2 of March 12, 2008

# wget http: // www .cipherdyne.org / fwknop / download / fwknop-1.9.2.tar.gz
# tar zxvf fwknop-1.9.0.tar.gz
# cd fwknop-1.9.0
# sudo ./install.pl

• We do a series of questions to which the following has been answered:

In which mode will fwknop be executed on the local system?
(client / server): server

Which of the following data acquisition methods would you like to use?
(pcap, file_pcap, ulogd, syslogd, syslog-ng): pcap

Which network interface would you like to fwknop to sniff packets from? eth0

Enable fwknop at boot time (y / n)? and

• We can add fwknop to system boot:

# update-rc.d fwknop defaults 20

• install fwknop on the client:

# apt-get install build-essential libpcap-dev mailx
# wget http://www.cipherdyne.org/ / fwknop-1.9.2.tar.gz (12 Mar 2008)
# tar zxvf fwknop-1.9.0.tar.gz
# cd fwknop-1.9.0 # sudo ./install.pl

In this case, we reply with the same answers except that we indicate that it is installed as a client.

• Generate key pair on the client:

# gpg --gen-key

• We choose the following options:

• Type -> DSA

The code never expires

• Name and surname: client fwknop
• Email: cf@cf.com

• We obtain:

pub 1024D / A174FC70 2008-03-24
uid Server fwknop

sub 2048g / 3220AE91 2008- Fwknop -client.asc - We generate a pair of keys on the server: # gpg --gen-key Type -> DSA Size -> 2048

• Export the key to a file

# gpg -a --export A174FC70 Period -> The password never expires Name and surname: Server fwknop * Email: sf@sf.com - We obtain: pub 1024D / D417D41A 2008-03-09 uid Server fwknop sub 2048g / F5F02C2B 2008-03-09

• We export the key to a file:

# gpg -a --export D417D41A> fwknop-server.asc

We copy the respective files in the machines and import the keys.

• We import the server key into the client:

# gpg --import fwknop-server.asc
# gpg --sign-key sf@sf.com

• We import the client key into the server:

# gpg --import fwknop-client .asc
# gpg --sign-key cf@cf.com

• Finishing the installation:

• We edit /etc/fwknop/access.conf:

SOURCE: ANY;
OPEN_PORTS: tcp / 22;
DATACOLLECTMODE: PCAP;
GPGHOMEDIR: /root/.gnupg;
GPGDECRYPTID: D417D41A;
GPGDECRYPTPW: password for key D417D41A;
GPGREMOTEID: A174FC70;
FWACCESSTIMEOUT: 30;

• start fwknop:

# /etc/init.d/fwknop start

• Function test:

• syntax example:

fwknop -a 'ports' --gpg-recip SERVERKEY --gpg-sign CLIENTKEY -s -D SERVER_IP

• Con - s we indicate that the SPA server uses the source ip from which it received the package to create the rule. Instead of -s you can use -w that will make a request to www.whatismyip.com to find out the source ip

• :

# fwknop -a 'tcp / 22' --gpg-recip D417D41A --gpg-sign A174FC70 -s -D 192.168.6.137

• If all went well, the server adds the corresponding entry to iptables. This will be maintained for 60 seconds, after which it will be automatically deleted.

In this case, we create a rule that allows the IP 192.168.6.137 tcp connections to port 22.

• We can verify that everything went well by consulting the logs on the SPA server:

# tail -f / var / log / syslog | grep fwknop

• And when the time available to make the connection is finished:
• - We can check the iptables rules in real time with:

# watch -n1 iptables -L -n

NOTE:
fwknop creates a new a new string in iptables called FWKNOP_INPUT and chain INPUT refers to this.

On the server we tried putting the default iptables INPUT policy to DROP but not the OUTPUT string. It should be noted that fwknop, by default, only adds rules to FWKNOP_INPUT. It can also be enabled in fwknop.conf so that it is created using the

FWKNOP_OUTPUT string and thus create rules to allow OUTPUT traffic.

• To maintain the SSH connection that we have established during the allowed time, we must have in iptables a rule that allows the already established connections. If not, the connection will be cut off when fwknop deletes the corresponding rule. In our case, we have added:

# iptables -A INPUT -p tcp -i eth0 -m state --state ESTABLISHED, RELATED -j ACCEPT

c u