TUTORIAL: Aldaba Knocking Suite
This tutorial introduces Aldaba, an open source Port Knocking and Single Packet Authorization system for GNU/Linux. Some sections may still be imcomplete. If you think something could be improved, please send a message to the mailing list or visit section "Contact" at http://www.aldabaknocking.com/
LAST UPDATED: Jan 5, 2008.
Table of contents:
1. Getting the source files.
First of all you need to get the latest version of Aldaba. To get it, just go to Aldaba Project's page at Sourceforge (Click Here) and click on the latest version of both Aldaba Client and Aldaba Server.
Download page in Sourceforge.
I'll assume that you saved the files in a directory called Aldaba in your Desktop.
2. Decompressing the files.
The files that we've just downloaded are compressed so we need to decompress them.
Now open a terminal window and go to the directory where the files are located.
cd /home/jimmyjazz/Desktop/Aldaba
Now it's time to decompress the files (Change filename if appropriate):
gunzip -c aldaba-server-0.1.1.tar.gz | tar xvf -
gunzip -c aldaba-client-0.1.3.tar.gz | tar xvf -
You'll see a lot of file names on screen. Those are the files that were decompressed.
Source files being uncompressed.
3. Installation.
3.1 Install Aldaba Client
To install aldaba client go to the directory where the files were decompressed and execute the following commands:
cd aldaba-client-0.1.3
This enters aldaba-client directory.
make
This compiles the program. If everything goes well, it should look like this:
Compiling with make.
sudo make install
This installs the compiled program, the manual page and the configuration file in the filesystem. This operation requires administrator privileges so you need to run it using the sudo command (or becoming root first and then running "make install"). If everything goes well, it should look like this:
Installing.
3.2 Install Aldaba Server.
The installation process for Aldaba-server is similar but has some extra steps.
3.2.1 Getting libpcap development files.
Aldaba server works by listening network traffic through a network interface. For this, Aldaba uses a library called libpcap. This library needs to be installed in the system before Aldaba-server is compiled. Depending on the flavour of Linux you are running you may need to run one command or another but in general you need to install a package called libpcap-dev, libpcap-devel or something like that.
In Fedora you can install this package running (as root) yum install libpcap-devel
In Ubuntu and Debian this package may be install running sudo apt-get install libpcap-dev
You can find the latest release of libpcap at http://www.tcpdump.org/.
3.2.2 Compiling and Installing
Once libpcap is installed we just need to compile and install Aldaba-server. For that, we have to run the same commands we used to install the client.
1- Go to the directory where aldaba-server files are and run:
cd aldaba-server-0.1.1
make
sudo make install
The output should be very similar to the one you saw with the client.
Now let's check that everything was installed correctly. Type:
cd
aldaba --version
aldabad --version
If the output looks like this, then congratulations, Aldaba-client and Aldaba-server are installed correctly.
Checking if everything went OK.
4. Post installation configuration.
4.1 Aldaba Client
Aldaba client does not need any special configuration after installation. However, it has a configuration file stored at /etc/aldaba/aldaba.conf. Running aldaba from the command line can sometimes be a pain in the ass because it requires many arguments to be passed. For example, this is a normal invocation:
sudo aldaba -h 192.168.1.99 -p 22 -t 15223,56443,7655,3478 --verbosity 7 --noise 100 -s 192.168.1.8 -S 192.168.1.33
To avoid having to type so much information you can use the configuration file. Open the file (/etc/aldaba/aldaba.conf) with your favourite text editor and set the all the options that you would normally use. See section 6.3.11 for more information.
Once you are done, aldaba client can be executed just like this:
sudo aldaba --config=/etc/aldaba/aldaba.conf
4.2 Aldaba Server
Aldaba-server does require you to take a few steps before it's ready to work.
4.2.1 Configuration File
Although Aldaba-server can be configured entirely through the command line, for convenience, it is better to set up a configuration file. The server stores its configuration file at /etc/aldabad/aldabad.conf. Its a good idea to adapt it for your own needs.
Once the file is configured correctly, aldaba may be called using the following command:
aldabad start
This forces Aldaba Server to load its configuration from that file. Alternatively, a different file may be specified using option --config="". See section 5.3.9 for more information.
4.2.2 Open/Close Scripts
Different systems have different firewall configurations so instead of manipulating firewall rules directly, Aldaba Server lets you specify what
should be done after correct knocks are received (open ports, enable services, shutdown, delete files, run programs...)
Once Aldaba Server is installed, there are 2 files that should be customized:
/etc/aldabad/aldaba_open.sh
/etc/aldabad/aldaba_close.sh
These files are the scripts that are executed as a result of a correct knock. If the received knock specifies the action "open" then aldaba_open.sh will be executed. If it specifies the action "close", aldaba_close.sh will be used.
Both scripts are executed with root privileges so be careful, think twice before setting them up.
4.2.3 Getting Aldaba-Server to run at system startup
In most cases you would want Aldaba-server to run automatically at startup. In this tutorial we'll just see the easiest way to do it. There are more elegant ways to handle script execution at startup but that's out of the scope of this tutorial.
To get Aldaba-server to run at startup, open (as root) the following file with a text editor: /etc/rc.local/ and add "aldabad start" right before the last line (which contain something like "exit 0").
The file should look similar to this:
-
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
aldabad start
exit 0
5. Usage of Aldaba Server
5.1 Introduction
Aldaba is divided in two different applications: a client and a server. This section covers the use and configuration of Aldaba-server.
5.2 Authentication Techniques
Aldaba is a Port Knocking and Single Packet Authorization system. This means that it supports two different types of authentication.
5.2.1 IP-Id (Port Knocking).
In this technique, the client uses TCP-SYN packets to transmit the following information to the server:
- An IP address (a port will be opened/closed on the server for this IP).
- A port number (port to be opened or closed).
- An open/close flag (specifies the action to take).
- A checksum (validates the previous data).
All the information is sent by the client through a covert channel, created using the Identification field of the IPv4 header.
IP version 4 Header.
The IP Identification field is 16 bits long so 2 bytes of information can be transferred in every packet. This knocking technique uses 4 TCP-SYN packets, targeted to 4 specific ports (the knocking sequence) to transfer that information. The information is encoded as follows:
[IP Address][Port No][Checksum][Open/Close Flag]
[ 4 bytes ][2 bytes][ 15bits ][ 1 bit ]
The following diagram illustrates Aldaba's IP-Id protocol.
IP-Id Technique.
SPA (Single Packet Authorization).
This technique is similar to IP-Id but uses only a single packet to transfer information to the server. 384 bytes of information are transferred in a single UDP packet. The following diagram represents the SPA Protocol version 2 header:
Currently some features like One-Time-Passwords or Challenges are not supported. Future releases will support them.
This technique does not require the use of a covert channel as it is based on the Single Packet Authorization scheme proposed by Rash (2004) and Jeanquier (2006).
The following diagram illustrates the flow of SPA protocol v2 designed for Aldaba.
5.3 Configuration
This section will provide detailed information about the parameters that can be used to configure Aldaba-server.
5.3.1 Listening Ports
5.3.1.1 IP-ID (Port Knocking Mode)
Port Knocking requires both client and server to know 2 shared secrets: a pashprase (covered in section 5.3.3) and a knock. A knock is a sequence of ports that have to be reached in order to get Aldaba-server to process and verify a knocking attempt. As you may recall from section 5.2.1, the IP-Id technique uses 4 TCP-SYN packets targeted to a set of pre-defined ports to send 8 bytes of information to the knocking server. Those ports are the knock. Options "-t" and "--listening-ports" let us specify this sequence of ports.
The sequence has to be specified as a comma-separated list of ports with no spaces in it.
e.g: aldabad --listening-ports 10,101,1001,10001
e.g: aldabad -t 7331,1337,8080,314
WARNING: Aldaba provides protection against packet disorder (packets that don't arrive in the order that were sent) but it requires knock packets to be generated using the exact same sequence on both client and server. This is, if the client uses the knock 100,200,300,400 and the server uses 200,100,300,400 the authentication will NOT be successful.
5.3.1.2 SPA (Single Packet Authorization Mode)
SPA just needs a single UDP packet to perform the authentication. For this reason, in SPA mode, Aldaba-server just needs one port to listen on. However, up to ten ports may be specified. In that case, SPA packets may be received on any of those ports. Use options "-t" and "--listening-ports" to specify the ports.
If there is more than one port to listen on, a comma-separated list of ports with no spaces in it must be specified.
e.g: aldabad --listening-ports 1001
e.g: aldabad -t 7335
e.g: aldabad -listening-ports 7335,7336,7337,7338 --SPA
If 4 ports are specified, Aldaba-server assumes that the IP-Id technique should be used. If what we want is to use SPA but to listen on 4 ports, we have to tell the server explicitly using --SPA or option --technique (covered in the following section).
5.3.2 Technique
Options "-T" and "--technique" set the authentication technique to be used.
Value may be either "IP-Id" or "SPA".
e.g: aldabad --listening-ports 1,2,3,4 --technique IP-Id
e.g: aldabad --listening-ports 7331 -T SPA
Alternatively, parameters "--IP-Id" or "--SPA" can be specified.
e.g: aldabad -t 11,22,33,44,55,66 -v 9 --SPA
e.g: aldabad --IP-Id --listening-ports 5,6,7,8
Don't worry about case, long arguments are case-insensitive.
This argument is optional. If no technique is specified it defaults to IP-Id unless only one port was specified through the "-t" parameter. In that case the SPA technique will be used.
5.3.3 Passhprase, cipher and encryption key
Cipher:
If the knocking information was sent in clear text, an attacker with the ability to sniff network traffic could intercept it and change it for his own benefit. For this reason, any communication between Aldaba-client and Aldaba-server is encrypted before transmission. Currently Aldaba supports 4 encryption algorithms: Blowfish, Twofish, Serpent and Rijndael(AES).
Options "-c" and "--cipher" set the cipher to be used for encryption/decryption of SPA packets. The following values are supported: "blowfish", "bf", "twofish", "tf", "serpent", "sp", "rijndael", "rj", "aes". Note that IP-Id mode cannot use other algorithm than Blowfish because it requires a block size of 64 bits.
Blowfish: Symmetric ; 64-bit block size ; Very Fast.
Rijndael: Symmetric ; 128-bit block size ; Fast ; AES Standard.
Serpent: Symmetric ; 128-bit block size ; Medium ; AES Contest finalist (2nd position)
Twofish: Symmetric ; 128-bit block size ; Fast ; AES Contest finalist (3rd position)
If this option is not specified, it defaults to Twofish.
e.g: aldabad -t 1,2,3,4 -c blowfish -k "Squeamish Ossifrage"
e.g: aldabad -t 7331 --cipher rijndael --passphrase 41d4b4S3rv3r_2k32n4hjb3243kjnb4mnfsakji
Encryption key:
As with any encryption algorithm, an encryption key is needed in order to cipher information. Aldaba uses a 256 bit key that is the SHA256 Hash of a user-supplied passphrase, salted with a 4 byte value.
Options "-k" and "--passphrase" set the passphrase that is used to generate the encryption key. This passphrase must be the same on both client and server, otherwise the decryption process will fail and any authentication attempt will be discarded.
Passphrases must be at least 8 characters long and have a maximum of 56 characters. If they contain spaces, they should be enclosed in double quotes. Special characters should be escaped using a backslash. Passphrases longer than 56 characters are valid but will be truncated. If no passphrase is specified it will be asked interactively.
Remember that if you want Aldaba-server to run in daemon mode (Covered in section 5.3.6) an encryption key must be specified either through the command line or using a configuration file.
e.g: aldabad -t 1,2,3,4 -k "Squeamish Ossifrage"
e.g: aldabad -t 7331 --passphrase 41d4b4S3rv3r_2k32n4hjb3243kjnb4mnfsakji
e.g: aldabad -t 11,22,33,44 -v 9 -k "Vivo en el numero 13, calle melancolia"
The following screenshot shows what happens if no passphrase is specified.
Passphrase being asked interactively.
5.3.4 Network interface
Aldaba-server needs a network interface to capture network traffic. Options "-i" and "--interface" set the name of the interface that will be opened for packet capture. Most devices supported by libpcap can be used.
e.g: aldabad -t 1,2,3,4 --interface eth0
e.g: aldabad -t 7331 -i wlan0
e.g: aldabad -t 11,22,33,44 -v 9 -i ath1
This argument is optional. If no network interface is specified Aldaba-server will try to open the first device that is suitable for packet capture.
5.3.5 Promiscuous mode
Packet capture can be done in two ways: in promiscuous mode or in non-promiscuous mode.
Usually network cards receive lots of different packets. Some of those packets may not be destined to its host so they are discarded. To set a network card into promiscuous mode means to tell the card to accept any incoming packet regardless of its destination address.
So, how can promiscuous mode be useful for Aldaba-Server? Well, let's imagine that the server running Aldaba has the IP 192.168.5.37 and is located in a hubbed network with addresses in the range 192.168.5.0-255. The fact that the network was built using Hubs means that every node gets a copy of any packet in the network. If you use Aldaba-client to send the knock to the IP 192.168.1.99, the server would still get it but no one would be able to tell that Aldaba-server is at 192.168.5.37 instead of at 192.168.1.99. This just adds some protection using a bit of obscurity.
Options "-p" and "--promiscuous" put the network card into promiscuous mode. By default the network interface is left in non-promiscuous mode. Note that if the device was already in promiscuous mode it will stay that way. Option "--non-promiscuous" can be specified explicitly but it is redundant as non-promiscuous mode is the default behaviour.
e.g: aldabad -t 1,2,3,4 --promiscuous
e.g: aldabad -t 7331 -p
e.g: aldabad -t 11,22,33,44 -v 9 --non-promiscuous
5.3.6 Daemon mode
As most network services, Aldaba-server normally operates as a daemon. This is, a program that runs in the background, without human intervention, to accomplish a specific task. Daemon mode is the default behaviour but sometimes it may be interesting to run Aldaba-server in interactive mode (non-daemon mode). This way we would be able to see every authentication attempt on screen and a bunch of information about the whole process.
Options "-d0" and "--dont-daemonize" force Aldaba-server to run interactively. Although daemon-mode is the default behaviour options "-d1" and "--daemonize" can be specified explicitly to tell Aldaba-server to run as a daemon.
e.g: aldabad -t 1,2,3,4 --dont-daemonize
e.g: aldabad -d0 -t 1,2,3,4 -i eth1 -v 7
e.g: aldabad -t 11,22,33,44 -v 9 --daemonize
The following screenshot shows how Aldaba-server looks like when it's run interactively.
Aldaba-server in non-daemon mode.
5.3.7 Verbosity levels
When Aldaba-server is run in non-daemon mode, the level of verbosity can be adjusted. Options "-v" and "--verbosity" let us specify a verbosity level. The argument to these options must be an integer between 0 and 9. There are 10 different levels of verbosity. Higher levels include all lower levels.
Here is the list of levels:
Level 0: No output at all.
Level 1: Parsing Error messages.
Level 2: Fatal error messages. (Default).
Level 3: Warnings.
Level 4: Information about knocking attempts
Level 5: Information about current configuration
Level 6: Important debug information.
Level 7: Any debug information
Level 8: Reserved for future use.
Level 9: Reserved for future use.
If no verbosity level is specified it defaults to level 2.
e.g: aldabad -t 1,2,3,4 -v 9
e.g: aldabad --verbosity 0 -t 1,2,3,4 -i ath0
e.g: aldabad -t 6677,5544,8877,9988 -v 4 --daemonize -i eth1
5.3.8 Logging levels
Aldaba-server offers support for log generation. Logs are sent via syslog. Entries use the prefix "aldabad" and the current PID of the process.
Options "-l" and "--logging" let us specify a logging level. The argument to these options must be an integer between 0 and 9. There are 10 different logging levels. Higher levels include all lower levels.
Here is the list of levels:
Level 0: No logging at all.
Level 1: Failed authentication attempts.
Level 2: Successful authentication attempts.
Level 3: Fatal error messages. (Default).
Level 4: Warnings.
Level 5: Information about current configuration.
Level 6: Important debug information.
Level 7: Any debug information
Level 8: Reserved for future use.
Level 9: Reserved for future use.
If nothing is specified it defaults to level 3.
e.g: aldabad -t 1,2,3,4 -v 9 --logging 9
e.g: aldabad --verbosity 0 -t 1,2,3,4 -i ath0 -l 0
e.g: aldabad -t 1337 -v 4 -i eth1 --logging 5
5.3.9 Configuration file
Although Aldaba-server can be configured entirely through the command line, for convenience, it is better to set up a configuration file. By default, the server stores its configuration file at /etc/aldabad/aldabad.conf. It's usually a good idea to adapt this file for your own needs.
The syntax of the configuration file is pretty simple: option="string". Empty lines or lines that begin with # will be ignored. The options that are supported are usually the long version of the command line arguments detailed in the man page without the initial hyphens. These are some examples:
technique="" ; listening-ports="" ; interface="" ; promiscuous="" ; daemonize="" ; verbosity="" ; logging="" ; cipher=""
The best way to learn how to set up the configuration file is to have a look at the default that comes with every release of Aldaba-server. This default configuration file may be found in /etc/aldabad/aldabad.conf or in a folder named conf/ located where the contents of the source tarball were extracted.
The following example shows a typical configuration file for aldaba server:
# +-----------------------------------------------+
# | ALDABA KNOCKING SERVER CONFIGURATION FILE |
# +-----------------------------------------------+
#
listening-ports="1,2,3,4"
technique="IP-Id"
passphrase="Squeamish Ossifrage"
interface="eth1"
promiscuous="no"
daemonize="yes"
verbosity="2"
logging="5"
# EOF
Once the file is configured correctly, aldaba may be called using the following command:
aldabad start
This forces Aldaba Server to load its configuration from that file. Alternatively, a different file may be specified using the --config="" option.
e.g: aldabad start
e.g: aldabad --config="/home/jimmyjazz/aldaba/myaldabacfg.conf"
5.3.10 Additional options
Option --quiet automatically sets verbose and logging levels to 0 so no output or logs are generated.
Option --debug automatically sets the maximum verbosity level and disables daemon mode.
Option --help displays usage information.
Option --version displays the current version.
e.g: aldabad --quiet -t 1,2,3,4
e.g: aldabad -t 1,2,3,4 -i ath0 --debug
e.g: aldabad --help
e.g: aldabad --version
5.4 Troubleshooting
This section will contain solutions to common problems that may occur when using Aldaba-server. As soon as you start sending questions through the mailing list, this section will grow.
6. Usage of Aldaba Client
Aldaba is divided in two different applications: a client and a server. This section covers the use and configuration of Aldaba-client.
6.1 Introduction
6.2 Authentication Techniques
Please see Section 5.2 for details about the Authentication techniques.
6.3 Configuration
6.3.1 Destination Host
Aldaba-client needs to know where to send SPA packets or Knocking authentication attempts. Options "-h" and "--host" set the hostname or IP address of the target Aldaba-server. The argument to those options may be an IPv4 address written in standard dot-decimal notation or a hostname. If a host name is specified a standard DNS query is performed using the default DNS server configured in the system.
NOTE: If Aldaba-server is running in promiscuous mode and it is in position to gather packets destined to other hosts, it is possible to specify the address of one of those hosts and Aldaba-server will still be able to process the authentication attempt. This could be used to add a bit of obscurity to the process so it is harder to tell which machine is running Aldaba-server.
e.g: aldaba -t 1,2,3,4 --host 192.168.66.30 -p 22
e.g: aldaba -h kernel.org -p 22 -t 1991
e.g: aldaba --host cvs.tcpdump.org -p 22 -t 398,383,372,371
6.3.2 Port Number
This is the port number that will be passed to the scripts that are run on the server when a valid authentication is processed. Usually those scripts contain calls to the system firewall requesting this port number to be opened or closed.
Options "-p" and "--port" set that port number. The argument must be a valid UDP/TCP port, this is, a positive integer in the range [1-65635].
e.g: aldaba -t 1936,1939,1984,2007 --host 212.33.53.101 --port 22
e.g: aldaba -h freebsd.com -p 7799 -t 1993
e.g: aldaba --host cvs.tcpdump.org --port 22 -t 398,383,372,371
6.3.3 Techniques
Options "-T" and "--technique" set the authentication technique to be used.
Value may be either "IP-Id" or "SPA".
e.g: aldaba --target-ports 1,2,3,4 --technique IP-Id -p 22 -h google.com
e.g: aldaba -t 7331 -T SPA --port 1337 --host 192.168.1.1
Alternatively, parameters "--IP-Id" or "--SPA" can be specified.
e.g: aldaba -t 11 -v 9 --SPA --port 53 --host alanturing.net
e.g: aldaba --IP-Id --target-ports 5,6,7,8 -p 6800 -h ibm.com
Don't worry about case, long arguments are case-insensitive.
This argument is optional. If no technique is specified it defaults to IP-Id unless only one port was specified through the "-t" parameter. In that case the SPA technique will be used.
6.3.4 Target Ports
6.3.4.1 IP-ID (Port Knocking Mode)
Port Knocking requires both client and server to know 2 shared secrets: a pashprase (covered in section 5.3.3) and a knock. A knock is a sequence of ports that have to be reached in order to get Aldaba-server to process and verify a knocking attempt. As you may recall from section 5.2.1, the IP-Id technique uses 4 TCP-SYN packets targeted to a set of pre-defined ports to send 8 bytes of information to the knocking server. Those ports are the knock. Options "-t" and "--target-ports" let us specify this sequence of ports.
The sequence has to be specified as a comma-separated list of ports with no spaces in it.
e.g: aldaba --target-ports 10,101,1001,10001 -h la-moncloa.es -p 1936
e.g: aldaba -t 7331,1337,8080,314 -p 22 -h 192.168.1.1
WARNING: Aldaba provides protection against packet disorder (packets that don't arrive in the order that were sent) but it requires knock packets to be generated using the exact same sequence on both client and server. This is, if the client uses the knock 100,200,300,400 and the server uses 200,100,300,400 the authentication will NOT be successful.
6.3.4.2 SPA (Single Packet Authorization Mode)
SPA just needs a single UDP packet to perform the authentication. For this reason, in SPA mode, Aldaba-client just needs one target port. Use options "-t" and "--target-ports" to specify the port.
e.g: aldaba --target-ports 10 -h la-moncloa.es -p 1936
e.g: aldaba -t 7331 -p 22 -h 192.168.1.1
6.3.5 Passhprase, cipher and encryption key
Cipher:
If the knocking information was sent in clear text, an attacker with the ability to sniff network traffic could intercept it and change it for his own benefit. For this reason, any communication between Aldaba-client and Aldaba-server is encrypted before transmission. Currently Aldaba supports 4 encryption algorithms: Blowfish, Twofish, Serpent and Rijndael(AES).
Options "-c" and "--cipher" set the cipher to be used for encryption/decryption of SPA packets. The following values are supported: "blowfish", "bf", "twofish", "tf", "serpent", "sp", "rijndael", "rj", "aes". Note that IP-Id mode cannot use other algorithm than Blowfish because it requires a block size of 64 bits.
Blowfish: Symmetric ; 64-bit block size ; Very Fast.
Rijndael: Symmetric ; 128-bit block size ; Fast ; AES Standard.
Serpent: Symmetric ; 128-bit block size ; Medium ; AES Contest finalist (2nd position)
Twofish: Symmetric ; 128-bit block size ; Fast ; AES Contest finalist (3rd position)
If this option is not specified, it defaults to Twofish.
e.g: aldaba -t 1,2,3,4 -c blowfish -p 12345 -h packetstormsecurity.nl
e.g: aldaba -t 7331 -h yahoo.com -p 8080 --cipher serpent --passphrase "Satanas, el infierno es demasiado dulce"
Encryption key:
As with any encryption algorithm, an encryption key is needed in order to cipher information. Aldaba uses a 256 bit key that is the SHA256 Hash of a user-supplied passphrase, salted with a 4 byte value.
Options "-k" and "--passphrase" set the passphrase that is used to generate the encryption key. This passphrase must be the same on both client and server, otherwise the decryption process will fail and any authentication attempt will be discarded.
Passphrases must be at least 8 characters long and have a maximum of 56 characters. If they contain spaces, they should be enclosed in double quotes. Special characters should be escaped using a backslash. Passphrases longer than 56 characters are valid but will be truncated. If no passphrase is specified it will be asked interactively.
e.g: aldaba -t 1,2,3,4 -k "Magic words are Squeamish Ossifrage" -p 12345 -h packetstormsecurity.nl
e.g: aldaba -t 7331 -h yahoo.com -p 8080 --passphrase "Satanas, el infierno es demasiado dulce"
e.g: aldaba -t 11,22,33,44 -v 9 --host jsabina.com -p 19500 -k "Siempre que lo intento ha salido ya el tranvia"
The following screenshot shows what happens if no passphrase is specified.
Passphrase being asked interactively.
Remember that if you want Aldaba-client to run from an automated script, an encryption key must be specified either through the command line or using a configuration file. Otherwise, the script will block.
6.3.6 Getting the Knock IP Address and the Source IP Address
In most situations Aldaba-client bypasses the system's IP stack, crafting its own packets and sending them through a raw socket. This means that the source IP address must be resolved before sending anything. One could think that this is the easiest thing to do but UNIX systems are a bit picky about this kind of things.
There are 2 pieces of information that must be obtained:
- The Source IP address, this is, the address that will be used as sender in every IP packet that is sent.
- The Knock IP address, this is, the IP address that will be included in the knocking information. This is the address that will be passed to the open/close scripts on the server.
6.3.6.1 --source-IP
Options "-s" and "--source-IP" set the source IP address for any outgoing IP packet. Port Knocking and SPA do NOT require this address to be the one that is associated with the machine where the client is being executed. This means that generally any IP address can be spoofed and Aldaba-server will still be able carry out the authentication process correctly. Just remember, if you set the source IP to a spoofed address, make sure you specify the Knock IP address explicitly. Otherwise you would be authenticating the spoofed IP on the knocking server, and that's probably something you don't want to do.
WARNING: Some firewalls might be configured to discard traffic leaving the internal network with unknown IP ranges. This means that sometimes, spoofing the source IP address of the knocking or SPA packets may result in packets being dropped before they reach Aldaba-server. Always make sure your packets contain a source IP address that won't be blocked by the firewall.
The source IP can be specified as a standard IP address in dot decimal notation or as a hostname, in which case a standard DNS query is performed.
If no source IP is specified:
- If an interface name was supplied using option --interface, then the IP associated with that interface will be used.
- Else, if the knock-IP was set (either using
"--knock-IP" or "--resolve-IP") then the knock-IP will be used as source address.
- Else, the address assigned to interface "eth0" will be the source address.
e.g: aldaba -t 1,2,3,4 -s 192.168.1.99 -p 8080 -h securityfocus.com
e.g: aldaba -t 7331 -h insecure.org -p 8080 --source-IP 212.23.43.101
e.g: aldaba -t 11,22,33,44 -v 9 --host 192.168.1.45 -p 5446 -s 192.168.1.2 --knock-IP 192.168.1.33
6.3.6.2 --knock-IP
Options "-S" and "--knock-IP" set the IP address that will be included in the knocking information. This is the IP that will be passed to the open/close scripts on the server.
The knock-IP can be specified as a standard IP address in dot decimal notation or as a hostname, in which case a standard DNS query is performed. If no knocking IP address is specified then the address used as source IP will be used.
e.g: aldaba -t 1,2,3,4 --knock-IP 192.168.1.99 -i eth1 -p 8080 -h securityfocus.com
e.g: aldaba -t 7331 -h insecure.org -p 8080 -S 212.23.43.101
e.g: aldaba -t 11,22,33,44 -v 9 --host 192.168.1.45 -p 5446 -s 192.168.1.2 --knock-IP 192.168.1.33
6.3.6.3 --interface
Options "-i" and "--interface" can be used to specify a network interface name. The IP address associated with that network interface will be used as the source IP address for knock or SPA packets. If no interface is specified and options --source-IP, --knock-IP and --resolve-IP are not supplied, "eth0" will be used by default.
Note that this option is NOT compatible with "--source-IP". Make sure you don't use both options at the same time.
e.g: aldaba -t 1,2,3,4 --knock-IP 192.168.1.99 -i eth1 -p 8080 -h securityfocus.com
e.g: aldaba -t 7331 -h insecure.org -p 8080 --interface wlan0
e.g: aldaba -t 11,22,33,44 -v 9 --host 192.168.1.45 -p 5446 --interface eth1 --resolve-IP
6.3.6.4 --resolve-IP
Imagine you are on a NATed network. The internal IP of your machine will probably have a non-routable IP address, something like 192.168.6.203. However, when you connect to services out on the internet, they'll see you as other IP, the internet-side IP address, what could be something like
212.12.34.56. If you want to authenticate against a remote Aldaba-server located somewhere on the internet, you will probably want to specify that internet-side IP so authorization is made to the IP address that the server will see packets originating from, not your local network address.
Option "--resolve-IP" resolves the internet-side IP address using the service http://whatismyip.aldabaknocking.com. Using "--resolve-IP" is equivalent to using "--knock-IP" to supply the internet-side IP explicitly. This is, if the external IP is 212.12.34.56, options "--resolve-IP" and "--knock-IP 212.12.34.56" will do exactly the same.
e.g: aldaba -t 1,2,3,4 --resolve-IP -i eth1 -p 8080 -h securityfocus.com
e.g: aldaba -t 11,22,33,44 -v 9 --host 192.168.1.45 -p 5446 --interface eth1 --resolve-IP
The following screenshot shows Aldaba-client resolving the external IP.
Using option --resolve-IP
6.3.7 Action
When a valid knock or SPA packet is received, the server executes one of two different scripts, depending on the action requested by Aldaba-client. Options "-a" and "--action" let us specify which of those scripts should be run. To execute aldaba_open.sh either "1" or "open" should be specified. To run aldaba_close.sh use "0" or "close". Alternatively parameters "--open" and "--close" may be used. If no action is specified, it always defaults to "open".
e.g: aldaba -t 1,2,3,4 --resolve-IP -a open -i eth1 -p 8080 -h securityfocus.com
e.g: aldaba -t 11,22,33,44 -v 9 --host 192.168.1.45 -p 5446 --interface eth1 -S 192.168.1.2 --action close
e.g: aldaba -t 556 -v 9 --host 192.168.1.89 -p 5453 -S 192.168.1.2 --close
e.g: aldaba -t 1,2,3,4 --resolve-IP -a 0 -i ath0 -p 22 -h barrapunto.com
6.3.8 Noise
Although the fact that an attacker knows the knock sequence or the SPA port does not compromise the system, it is probably better if that information remains secret. To prevent attackers with sniffing capabilities from guessing the port knocking sequence, a number of additional packets can be sent along with the knock or SPA packets. This way it would be hard to tell which of those packets belong to real authentication attempts and which are just noise.
Options -n and --noise let us specify how many noise packets should be sent. Packets will be targeted to random ports on the remote system. If the specified value is less than 5000, the target ports are guaranteed to be all different.
By default, information about every packet is printed to stdout. When thousands of noise packets are sent, printing information about it becomes computationally expensive. This can lead to execution times that range from a few seconds to a few tens of seconds. To avoid delays, specify a verbosity level < 4.
WARNING: Note that this option does not add any real security, just some obscurity.
e.g: aldaba -t 1337 --resolve-IP -n 20999 -i eth1 -p 822 -h schneier.com
e.g: aldaba -t 11,22,33,44 -v 9 --host 192.168.1.45 -p 5446 --interface eth1 -S 192.168.1.2 --noise 1000 --action close
6.3.9 Decoys
Although knocking sequences can be easily sent from a spoofed IP address, sometimes it may be interesting to send additional fake sequences from additional IPs. This adds a bit of obscurity to the knocking process so an attacker with sniffing capabilities doesn't really know which packet or set of packets carries the real knocking information.
Options -d and --decoys let us specify a list of IP addresses to be used as decoys. The list should contain IP addresses in standard dot-decimal notation. It should also be comma separated and have no spaces in it. This option can be combined with --noise for extra effect.
e.g: aldaba -t 1337 --resolve-IP --decoys 203.141.52.43,209.191.83.220 -i eth1 -p 822 -h schneier.com
e.g: aldaba -t 11,22,33,44 -v 9 --host 192.168.1.45 -p 5446 --interface eth1 -S 192.168.1.2 --noise 1000 --decoys 216.239.59.98,64.233.173.207,66.249.69.2,64.68.90.74
The following screenshot shows Aldaba-client using both --noise and --decoys options.
Sending a knock with noise and 4 decoys.
6.3.10 Verbosity Levels
By default, Aldaba-client prints information about errors, warnings and current authentication attempts. However, the level of verbosity can be adjusted. Options "-v" and "--verbosity" let us specify verbosity levels. The argument to these options must be an integer between 0 and 9. There are 10 different levels of verbosity. Higher levels include all lower levels.
Here is the list of levels:
Level 0: No output at all.
Level 1: Parsing Error messages.
Level 2: Fatal error messages.
Level 3: Warnings.
Level 4: Information about knocking attempts (Default).
Level 5: Information about current configuration
Level 6: Important debug information.
Level 7: Any debug information
Level 8: Reserved for future use.
Level 9: Reserved for future use.
If no verbosity level is specified it defaults to level 4.
e.g: aldaba -t 1337 --resolve-IP --verbosity 7 -i eth1 -p 822 -h schneier.com
e.g: aldaba -t 11,22,33,44 -v 9 --host 192.168.1.45 -p 5446 --interface eth1 -S 192.168.1.2 -v 0
6.3.11 Configuration file
Although Aldaba-client is usually configured through the command line, sometimes it may be a good idea to create a configuration file to avoid typing all those ugly arguments every time we need to authenticate. By default a sample config file is installed in /etc/aldaba/aldaba.conf. It's usually a good idea to have a look at it and adapt it for your own needs.
The syntax of the configuration file is pretty simple: option="string". Empty lines or lines that begin with # will be ignored. The options that are supported are usually the long version of the command line arguments detailed in the man page without the initial hyphens. These are some examples:
hostname="" ; port="" ; target-ports="" ; passphrase="" ; technique="" ; interface="" ; source-ip="" ; knock_ip="" ; action="" ; verbosity="" ; noise="" ; decoys="" ;
The best way to learn how to set up the configuration file is to have a look at the default that comes with every release of Aldaba-client. This default configuration file may be found in /etc/aldaba/aldaba.conf or in a folder named conf/ located where the contents of the source tarball were extracted.
The following example shows a typical configuration file for Aldaba-client:
# +-------------------------------------------+
# | ALDABA KNOCKING CLIENT CONFIGURATION FILE |
# +-------------------------------------------+
hostname="localhost"
port="22"
target-ports="2001,1984,2046,900"
passphrase="Police came looking for Jimmy Jazz"
technique="IP-Id"
source-ip="192.168.1.6"
knock_ip="192.168.1.77"
action="open"
verbosity="7"
noise="100"
decoys="192.168.1.1,192.168.1.2,192.168.1.3,192.168.1.4,192.168.1.5"
#EOF
Once the file is configured correctly, Aldaba-client may be called using the following command: aldaba --config="path/to/config/file"
e.g: aldaba --config="/home/jimmyjazz/aldaba/myaldabacfg.conf"
6.3.12 Additional options
Option --quiet automatically sets verbosity level to 0.
Option --debug automatically sets the maximum verbosity level.
Option --help displays usage information.
Option --version displays the current version.
Option --dont-send prevents Aldaba-client from actually placing Knock or SPA packets on the network. The process will be carried out normally but calls to sendto() will be skipped. This may be useful for testing purposes. Note that this option only disables Knock and SPA packets. DNS lookups and HTTP requests for option --resolve-IP will still be sent.
e.g: aldaba --quiet -t 1,2,3,4 -p 22 -h marioconde.gov
e.g: aldaba -t 69,6969,96,9696 -p 8080 -h hustler.com --debug
e.g: aldaba --help
e.g: aldaba --version
e.g: aldaba -t 1070,1080,1090,2000 -p 21 -h kriptopolis.org --dont-send
-
6.4 Troubleshooting
This section will contain solutions to common problems that may occur when using Aldaba-client. As soon as you start sending questions through the mailing list, this section will grow.
(c) Luis Martin Garcia 2007. Some rights reserved. This document is distributed under the terms of the GNU Free Documentation License, Version 1.2 or later. A copy of the license may be found at http://www.gnu.org/licenses/fdl.txt.