个人工具

“UbuntuHelp:SinglePacketAuthorization”的版本间的差异

来自Ubuntu中文

跳转至: 导航, 搜索
(新页面: {{From|https://help.ubuntu.com/community/SinglePacketAuthorization}} {{Languages|UbuntuHelp:SinglePacketAuthorization}} #title Single Packet Authorization ''' ''Single Packet Authorizat...)
 
第2行: 第2行:
 
{{Languages|UbuntuHelp:SinglePacketAuthorization}}
 
{{Languages|UbuntuHelp:SinglePacketAuthorization}}
 
#title Single Packet Authorization
 
#title Single Packet Authorization
 
 
 
''' ''Single Packet Authorization (SPA)'' ''' using '''[http://www.cipherdyne.org/fwknop/ "fwknop"]''' is probably one of the coolest recent innovations in server and network access control technology. Just what is SPA, you ask? SPA is a method of limiting access to server and network resources by cryptographically authenticating users before any type of TCP/IP stack access is allowed.
 
''' ''Single Packet Authorization (SPA)'' ''' using '''[http://www.cipherdyne.org/fwknop/ "fwknop"]''' is probably one of the coolest recent innovations in server and network access control technology. Just what is SPA, you ask? SPA is a method of limiting access to server and network resources by cryptographically authenticating users before any type of TCP/IP stack access is allowed.
 
 
In its simplest form, your Linux server can have an inbound firewall rule that by default drops all access to any of its listening services. Nmap scans will completely fail to detect any open ports, and zero-day attacks will not have any effect on vulnerable services since the firewall is blocking access to the applications.
 
In its simplest form, your Linux server can have an inbound firewall rule that by default drops all access to any of its listening services. Nmap scans will completely fail to detect any open ports, and zero-day attacks will not have any effect on vulnerable services since the firewall is blocking access to the applications.
 
 
The server however has a nifty trick up its sleeve. An authorized user sends a single encrypted UDP packet that is passively sniffed and analyzed by the fwknopd service running on the server using pcap. If successfully authenticated, fwknopd dynamically creates an iptables firewall rule, granting the source IP address of the authorized client access to the service for a defined period of time (default is 30 seconds).
 
The server however has a nifty trick up its sleeve. An authorized user sends a single encrypted UDP packet that is passively sniffed and analyzed by the fwknopd service running on the server using pcap. If successfully authenticated, fwknopd dynamically creates an iptables firewall rule, granting the source IP address of the authorized client access to the service for a defined period of time (default is 30 seconds).
 
 
In this example, the service we will be protecting is SSH. I will be using a simple firewall rule that blocks all inbound connections, but has an unrestricted outbound policy. The client will authenticate using a GNUPG key pair.
 
In this example, the service we will be protecting is SSH. I will be using a simple firewall rule that blocks all inbound connections, but has an unrestricted outbound policy. The client will authenticate using a GNUPG key pair.
 
 
=== IMPORTANT INFORMATION ===
 
=== IMPORTANT INFORMATION ===
 
 
Before you even begin to mess with this software on a remote server, PLEASE make sure you know EXACTLY what you are doing!  If you do not carefully plan, test, and deploy, there is a serious potential that you will lock yourself out of your server.  How?
 
Before you even begin to mess with this software on a remote server, PLEASE make sure you know EXACTLY what you are doing!  If you do not carefully plan, test, and deploy, there is a serious potential that you will lock yourself out of your server.  How?
 
 
If you apply a default firewall policy that blocks all inbound traffic, including SSH, and your fwknop service is misconfigured or fails, then you will not be able to access your server, as the service will be unable to add the dynamic access list entry!  Please make sure you have alternate method of accessing the server during this initial deployment.  i.e. Direct console access; or SSH listening on two ports, one that's blocked, the other that's not.
 
If you apply a default firewall policy that blocks all inbound traffic, including SSH, and your fwknop service is misconfigured or fails, then you will not be able to access your server, as the service will be unable to add the dynamic access list entry!  Please make sure you have alternate method of accessing the server during this initial deployment.  i.e. Direct console access; or SSH listening on two ports, one that's blocked, the other that's not.
 
 
This will keep a minor mistake from becoming a larger one.  You have been warned.
 
This will keep a minor mistake from becoming a larger one.  You have been warned.
 
 
=== Install Software ===
 
=== Install Software ===
 
 
In the following section, we will download and install fwknop and all of its prerequisites.
 
In the following section, we will download and install fwknop and all of its prerequisites.
 
 
==== OpenSSH Server (Optional) ====
 
==== OpenSSH Server (Optional) ====
 
 
Since we are using SSH for this tutorial, make sure you have installed the OpenSSH server.  If you have already done so, you may skip this step.
 
Since we are using SSH for this tutorial, make sure you have installed the OpenSSH server.  If you have already done so, you may skip this step.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ sudo apt-get install openssh-server
 
$ sudo apt-get install openssh-server
 
</nowiki></pre>
 
</nowiki></pre>
 
 
==== fwknop installation prerequisites ====
 
==== fwknop installation prerequisites ====
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ sudo apt-get install build-essential libpcap-dev mailx
 
$ sudo apt-get install build-essential libpcap-dev mailx
 
</nowiki></pre>
 
</nowiki></pre>
 
 
==== fwknop installation ====
 
==== fwknop installation ====
 
 
 
Download the latest version of fwknop from the official website, and install.  Please check for latest version of fwknop at [http://www.cipherdyne.org/fwknop/download/].
 
Download the latest version of fwknop from the official website, and install.  Please check for latest version of fwknop at [http://www.cipherdyne.org/fwknop/download/].
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ wget http://www.cipherdyne.org/fwknop/download/fwknop-1.8.3.tar.gz
 
$ wget http://www.cipherdyne.org/fwknop/download/fwknop-1.8.3.tar.gz
第49行: 第29行:
 
$ sudo ./install.pl
 
$ sudo ./install.pl
 
</nowiki></pre>
 
</nowiki></pre>
 
 
The installer will ask you a couple of questions. You will need to provide the interface you wish the service to monitor, and specify that the installation should run as a server.
 
The installer will ask you a couple of questions. You will need to provide the interface you wish the service to monitor, and specify that the installation should run as a server.
 
 
Add the fwknop initialization script to the appropriate startup and shutdown locations.
 
Add the fwknop initialization script to the appropriate startup and shutdown locations.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ sudo update-rc.d fwknop defaults 20
 
$ sudo update-rc.d fwknop defaults 20
 
</nowiki></pre>
 
</nowiki></pre>
 
 
=== GnuPGP Authentication ===
 
=== GnuPGP Authentication ===
 
 
If you are new to PGP concepts, please see the Self:GnuPrivacyGuardHowto before going any further.  For those of you that regularly use GnuPG, these concepts are probably quite familiar.
 
If you are new to PGP concepts, please see the Self:GnuPrivacyGuardHowto before going any further.  For those of you that regularly use GnuPG, these concepts are probably quite familiar.
 
 
You (the client) and the server should use individualized PGP key pairs for this to work as securely as possible. The client will use its own private key to digitally sign the SPA packet payload, and use the servers public key to encrypt it as well. The server will use the clients public key and digital signature to verify that the SPA packet originated from a trusted source. This means that both the server and the client will need a signed copy of each others public keys in their keyring.
 
You (the client) and the server should use individualized PGP key pairs for this to work as securely as possible. The client will use its own private key to digitally sign the SPA packet payload, and use the servers public key to encrypt it as well. The server will use the clients public key and digital signature to verify that the SPA packet originated from a trusted source. This means that both the server and the client will need a signed copy of each others public keys in their keyring.
 
 
 
==== Generate Client-side GnuPG key pairs ====
 
==== Generate Client-side GnuPG key pairs ====
 
 
From the workstation you are using as a client, generate your client side key pair, and export the public key to a text file.
 
From the workstation you are using as a client, generate your client side key pair, and export the public key to a text file.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ gpg --gen-key
 
$ gpg --gen-key
第75行: 第45行:
 
uid                  fwknop client key <fwknop-client@localhost>
 
uid                  fwknop client key <fwknop-client@localhost>
 
sub  2048g/C3FD544F 2007-11-17
 
sub  2048g/C3FD544F 2007-11-17
 
 
$ gpg -a --export 2FBEA691 > fwknop-client.asc
 
$ gpg -a --export 2FBEA691 > fwknop-client.asc
 
</nowiki></pre>
 
</nowiki></pre>
 
 
Upload the client public key to the SSH server.
 
Upload the client public key to the SSH server.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ scp fwknop-client.asc <server-ip-address>:
 
$ scp fwknop-client.asc <server-ip-address>:
 
</nowiki></pre>
 
</nowiki></pre>
 
 
 
==== Generate Server-side GnuPG key pairs ====
 
==== Generate Server-side GnuPG key pairs ====
 
 
From the server, generate the server side key pair, and export the public key to a text file.
 
From the server, generate the server side key pair, and export the public key to a text file.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ gpg --gen-key
 
$ gpg --gen-key
第96行: 第59行:
 
uid                  fwknop server key <fwknopd@localhost>
 
uid                  fwknop server key <fwknopd@localhost>
 
sub  2048g/C6AABDF0 2007-11-17
 
sub  2048g/C6AABDF0 2007-11-17
 
 
$ gpg -a --export 3F89D02C > fwknop-server.asc
 
$ gpg -a --export 3F89D02C > fwknop-server.asc
 
</nowiki></pre>
 
</nowiki></pre>
 
 
From the client, download the server's exported public key.
 
From the client, download the server's exported public key.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ scp <server-ip-address>:fwknop-server.asc .
 
$ scp <server-ip-address>:fwknop-server.asc .
 
</nowiki></pre>
 
</nowiki></pre>
 
 
==== Import and sign GnuPG key pairs ====
 
==== Import and sign GnuPG key pairs ====
 
 
From your client side workstation, import the server's public key into your keyring and sign it.
 
From your client side workstation, import the server's public key into your keyring and sign it.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ gpg --import fwknop-server.asc
 
$ gpg --import fwknop-server.asc
 
$ gpg --sign-key fwknopd@localhost
 
$ gpg --sign-key fwknopd@localhost
 
</nowiki></pre>
 
</nowiki></pre>
 
 
From your server, import the clients public key into your keyring and sign it.
 
From your server, import the clients public key into your keyring and sign it.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ gpg --import fwknop-client.asc
 
$ gpg --import fwknop-client.asc
 
$ gpg --sign-key fwknop-client@localhost
 
$ gpg --sign-key fwknop-client@localhost
 
</nowiki></pre>
 
</nowiki></pre>
 
 
=== Finishing the installation ===
 
=== Finishing the installation ===
 
 
==== fwknop configuration ====
 
==== fwknop configuration ====
 
 
You will need to edit the fwknop configuration file “/etc/fwknop/access.conf”.  An example of this configuration is shown below.
 
You will need to edit the fwknop configuration file “/etc/fwknop/access.conf”.  An example of this configuration is shown below.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
SOURCE: ANY;
 
SOURCE: ANY;
第138行: 第89行:
 
FW_ACCESS_TIMEOUT: 30;
 
FW_ACCESS_TIMEOUT: 30;
 
</nowiki></pre>
 
</nowiki></pre>
 
 
'''Note:''' Be sure to replace the GPG_HOME_DIR variable with the path to the correct key ring.  The other variables are fairly self explanatory.
 
'''Note:''' Be sure to replace the GPG_HOME_DIR variable with the path to the correct key ring.  The other variables are fairly self explanatory.
 
 
==== Start fwknop ====
 
==== Start fwknop ====
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ sudo /etc/init.d/fwknop start
 
$ sudo /etc/init.d/fwknop start
 
</nowiki></pre>
 
</nowiki></pre>
 
 
 
=== Testing fwknop ===
 
=== Testing fwknop ===
 
 
You should now be ready to test things out using another computer with the fwknop client. You install everything exactly the same as the server, with the exception of specifying that the installer should run fwknop as a client.
 
You should now be ready to test things out using another computer with the fwknop client. You install everything exactly the same as the server, with the exception of specifying that the installer should run fwknop as a client.
 
 
The typical authorization process from client to server can be completed as follows.
 
The typical authorization process from client to server can be completed as follows.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ fwknop -A tcp/22 --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -w -k SERVER_IP
 
$ fwknop -A tcp/22 --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -w -k SERVER_IP
 
</nowiki></pre>
 
</nowiki></pre>
 
 
The “-w” flag queries www.whatismyip.com for the clients real ip address and uses that as the source address. This is useful when you are behind a NAT firewall, since the source address specified on the SPA packet would otherwise be a local address.
 
The “-w” flag queries www.whatismyip.com for the clients real ip address and uses that as the source address. This is useful when you are behind a NAT firewall, since the source address specified on the SPA packet would otherwise be a local address.
 
 
If you are on the same network as the server, or simply do not have to worry about NAT, the syntax would be as follows:
 
If you are on the same network as the server, or simply do not have to worry about NAT, the syntax would be as follows:
 
<pre><nowiki>
 
<pre><nowiki>
 
$ fwknop -A tcp/22 --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -a CLIENT_IP -k SERVER_IP
 
$ fwknop -A tcp/22 --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -a CLIENT_IP -k SERVER_IP
 
</nowiki></pre>
 
</nowiki></pre>
 
 
If successful, your server adds the appropriate access list entry for you to connect using your ssh client. You will have 30 seconds to make the connection, after which the access list is dynamically removed.
 
If successful, your server adds the appropriate access list entry for you to connect using your ssh client. You will have 30 seconds to make the connection, after which the access list is dynamically removed.
 
<pre><nowiki>
 
<pre><nowiki>
 
$ ssh username@SERVER_IP
 
$ ssh username@SERVER_IP
 
</nowiki></pre>
 
</nowiki></pre>
 
 
It is important to note that the SPA packet is sent to the servers IP address using the destination port of UDP/62201. You must ensure that this port number is allowed outbound from the network you are connecting from, and that no router or firewall is blocking it from reaching your server.
 
It is important to note that the SPA packet is sent to the servers IP address using the destination port of UDP/62201. You must ensure that this port number is allowed outbound from the network you are connecting from, and that no router or firewall is blocking it from reaching your server.
 
 
It should also be noted that the time stamp embedded in the SPA packet must fall within 120 seconds of the servers clock. You should make sure that both the server and client are using NTP to keep their clocks as close as possible.
 
It should also be noted that the time stamp embedded in the SPA packet must fall within 120 seconds of the servers clock. You should make sure that both the server and client are using NTP to keep their clocks as close as possible.
 
 
Check out your syslogs and iptables output for useful information while testing.
 
Check out your syslogs and iptables output for useful information while testing.
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ watch -n1 sudo iptables -L -n
 
$ watch -n1 sudo iptables -L -n
 
$ tail -f /var/log/syslog
 
$ tail -f /var/log/syslog
 
</nowiki></pre>
 
</nowiki></pre>
 
 
 
=== Firewall Configuration (Optional) ===
 
=== Firewall Configuration (Optional) ===
 
 
If you are already using an iptables firewall configuration on your server, you may skip this step.  If you would like additional information regarding iptables, please see the Self:IpablesHowTo.
 
If you are already using an iptables firewall configuration on your server, you may skip this step.  If you would like additional information regarding iptables, please see the Self:IpablesHowTo.
 
 
Here is a simple firewall script to help you test things out.  Please use it with caution, as it blocks all incoming traffic!  We will use it simply to demonstrate SPA functionality.
 
Here is a simple firewall script to help you test things out.  Please use it with caution, as it blocks all incoming traffic!  We will use it simply to demonstrate SPA functionality.
 
 
==== Download firewall script ====
 
==== Download firewall script ====
 
 
Download and save the following [https://help.ubuntu.com/community/SinglePacketAuthorization?action=AttachFile&do=get&target=firewall.sh firewall.sh] script in your home directory.
 
Download and save the following [https://help.ubuntu.com/community/SinglePacketAuthorization?action=AttachFile&do=get&target=firewall.sh firewall.sh] script in your home directory.
 
 
==== Test firewall script ====
 
==== Test firewall script ====
 
 
In order to test your script, start by opening a terminal window, (''Applications → Accessories → Terminal'').
 
In order to test your script, start by opening a terminal window, (''Applications → Accessories → Terminal'').
 
 
Check the syntax of the script and verify resulting output:
 
Check the syntax of the script and verify resulting output:
 
<pre><nowiki>
 
<pre><nowiki>
第201行: 第128行:
 
firewall.sh {start|stop|restart|reload|force-reload|show}
 
firewall.sh {start|stop|restart|reload|force-reload|show}
 
</nowiki></pre>
 
</nowiki></pre>
 
 
Show your current iptables configuration.  If you are not running any rules, it will look like a following:
 
Show your current iptables configuration.  If you are not running any rules, it will look like a following:
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ sudo sh firewall.sh show
 
$ sudo sh firewall.sh show
 
Chain INPUT (policy ACCEPT)
 
Chain INPUT (policy ACCEPT)
 
target    prot opt source              destination
 
target    prot opt source              destination
 
 
Chain FORWARD (policy ACCEPT)
 
Chain FORWARD (policy ACCEPT)
 
target    prot opt source              destination
 
target    prot opt source              destination
 
 
Chain OUTPUT (policy ACCEPT)
 
Chain OUTPUT (policy ACCEPT)
 
target    prot opt source              destination
 
target    prot opt source              destination
 
</nowiki></pre>
 
</nowiki></pre>
 
 
 
Start your firewall:
 
Start your firewall:
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ sudo sh firewall.sh start
 
$ sudo sh firewall.sh start
 
</nowiki></pre>
 
</nowiki></pre>
 
 
 
Show your new iptables configuration:
 
Show your new iptables configuration:
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ sudo sh firewall.sh show
 
$ sudo sh firewall.sh show
第235行: 第152行:
 
DROP      0    --  0.0.0.0/0            0.0.0.0/0          PKTTYPE = multicast
 
DROP      0    --  0.0.0.0/0            0.0.0.0/0          PKTTYPE = multicast
 
LOG        0    --  0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4
 
LOG        0    --  0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4
 
 
Chain FORWARD (policy ACCEPT)
 
Chain FORWARD (policy ACCEPT)
 
target    prot opt source              destination
 
target    prot opt source              destination
 
 
Chain OUTPUT (policy ACCEPT)
 
Chain OUTPUT (policy ACCEPT)
 
target    prot opt source              destination
 
target    prot opt source              destination
 
</nowiki></pre>
 
</nowiki></pre>
 
 
With your new rules in place, you are now blocking all incoming traffic.
 
With your new rules in place, you are now blocking all incoming traffic.
 
 
To stop your firewall:
 
To stop your firewall:
 
 
<pre><nowiki>
 
<pre><nowiki>
 
$ sudo sh firewall.sh stop
 
$ sudo sh firewall.sh stop
 
</nowiki></pre>
 
</nowiki></pre>
 
 
 
=== Related Articles ===
 
=== Related Articles ===
 
 
* [http://www.savvyadmin.com/2007/06/24/fwknop-single-packet-authorization-in-ubuntu/]
 
* [http://www.savvyadmin.com/2007/06/24/fwknop-single-packet-authorization-in-ubuntu/]
 
 
 
=== Resources ===
 
=== Resources ===
 
 
* [http://www.cipherdyne.org/fwknop/]
 
* [http://www.cipherdyne.org/fwknop/]
 
* [http://www.cipherdyne.org/fwknop/docs/faq.html]
 
* [http://www.cipherdyne.org/fwknop/docs/faq.html]
第264行: 第170行:
 
* Self:GnuPrivacyGuardHowto
 
* Self:GnuPrivacyGuardHowto
 
* Self:iptablesHowTo
 
* Self:iptablesHowTo
 
 
 
=== Credits ===
 
=== Credits ===
 
 
Special thanks to [http://www.cipherdyne.org/author.html Michael Rash], author of fwknop.
 
Special thanks to [http://www.cipherdyne.org/author.html Michael Rash], author of fwknop.
 
 
----
 
----
 
[[category:CategorySecurity]]
 
[[category:CategorySecurity]]
  
 
[[category:UbuntuHelp]]
 
[[category:UbuntuHelp]]

2007年11月30日 (五) 21:29的版本

  1. title Single Packet Authorization

Single Packet Authorization (SPA) using "fwknop" is probably one of the coolest recent innovations in server and network access control technology. Just what is SPA, you ask? SPA is a method of limiting access to server and network resources by cryptographically authenticating users before any type of TCP/IP stack access is allowed. In its simplest form, your Linux server can have an inbound firewall rule that by default drops all access to any of its listening services. Nmap scans will completely fail to detect any open ports, and zero-day attacks will not have any effect on vulnerable services since the firewall is blocking access to the applications. The server however has a nifty trick up its sleeve. An authorized user sends a single encrypted UDP packet that is passively sniffed and analyzed by the fwknopd service running on the server using pcap. If successfully authenticated, fwknopd dynamically creates an iptables firewall rule, granting the source IP address of the authorized client access to the service for a defined period of time (default is 30 seconds). In this example, the service we will be protecting is SSH. I will be using a simple firewall rule that blocks all inbound connections, but has an unrestricted outbound policy. The client will authenticate using a GNUPG key pair.

IMPORTANT INFORMATION

Before you even begin to mess with this software on a remote server, PLEASE make sure you know EXACTLY what you are doing! If you do not carefully plan, test, and deploy, there is a serious potential that you will lock yourself out of your server. How? If you apply a default firewall policy that blocks all inbound traffic, including SSH, and your fwknop service is misconfigured or fails, then you will not be able to access your server, as the service will be unable to add the dynamic access list entry! Please make sure you have alternate method of accessing the server during this initial deployment. i.e. Direct console access; or SSH listening on two ports, one that's blocked, the other that's not. This will keep a minor mistake from becoming a larger one. You have been warned.

Install Software

In the following section, we will download and install fwknop and all of its prerequisites.

OpenSSH Server (Optional)

Since we are using SSH for this tutorial, make sure you have installed the OpenSSH server. If you have already done so, you may skip this step.

$ sudo apt-get install openssh-server

fwknop installation prerequisites

$ sudo apt-get install build-essential libpcap-dev mailx

fwknop installation

Download the latest version of fwknop from the official website, and install. Please check for latest version of fwknop at [1].

$ wget http://www.cipherdyne.org/fwknop/download/fwknop-1.8.3.tar.gz
$ tar zxvf fwknop-1.8.3.tar.gz
$ cd fwknop-1.8.3
$ sudo ./install.pl

The installer will ask you a couple of questions. You will need to provide the interface you wish the service to monitor, and specify that the installation should run as a server. Add the fwknop initialization script to the appropriate startup and shutdown locations.

$ sudo update-rc.d fwknop defaults 20

GnuPGP Authentication

If you are new to PGP concepts, please see the Self:GnuPrivacyGuardHowto before going any further. For those of you that regularly use GnuPG, these concepts are probably quite familiar. You (the client) and the server should use individualized PGP key pairs for this to work as securely as possible. The client will use its own private key to digitally sign the SPA packet payload, and use the servers public key to encrypt it as well. The server will use the clients public key and digital signature to verify that the SPA packet originated from a trusted source. This means that both the server and the client will need a signed copy of each others public keys in their keyring.

Generate Client-side GnuPG key pairs

From the workstation you are using as a client, generate your client side key pair, and export the public key to a text file.

$ gpg --gen-key
$ gpg --list-key fwknop-client@localhost
pub   1024D/2FBEA691 2007-11-17
uid                  fwknop client key <fwknop-client@localhost>
sub   2048g/C3FD544F 2007-11-17
$ gpg -a --export 2FBEA691 > fwknop-client.asc

Upload the client public key to the SSH server.

$ scp fwknop-client.asc <server-ip-address>:

Generate Server-side GnuPG key pairs

From the server, generate the server side key pair, and export the public key to a text file.

$ gpg --gen-key
$ gpg --list-key fwknopd@localhost
pub   1024D/3F89D02C 2007-11-17
uid                  fwknop server key <fwknopd@localhost>
sub   2048g/C6AABDF0 2007-11-17
$ gpg -a --export 3F89D02C > fwknop-server.asc

From the client, download the server's exported public key.

$ scp <server-ip-address>:fwknop-server.asc .

Import and sign GnuPG key pairs

From your client side workstation, import the server's public key into your keyring and sign it.

$ gpg --import fwknop-server.asc
$ gpg --sign-key fwknopd@localhost

From your server, import the clients public key into your keyring and sign it.

$ gpg --import fwknop-client.asc
$ gpg --sign-key fwknop-client@localhost

Finishing the installation

fwknop configuration

You will need to edit the fwknop configuration file “/etc/fwknop/access.conf”. An example of this configuration is shown below.

SOURCE: ANY;
OPEN_PORTS: tcp/22;
DATA_COLLECT_MODE: PCAP;
GPG_HOME_DIR: /root/.gnupg;
GPG_DECRYPT_ID: SERVER_KEY_ID;
GPG_DECRYPT_PW: PASSWORD_HERE;
GPG_REMOTE_ID: CLIENT_KEY_ID;
FW_ACCESS_TIMEOUT: 30;

Note: Be sure to replace the GPG_HOME_DIR variable with the path to the correct key ring. The other variables are fairly self explanatory.

Start fwknop

$ sudo /etc/init.d/fwknop start

Testing fwknop

You should now be ready to test things out using another computer with the fwknop client. You install everything exactly the same as the server, with the exception of specifying that the installer should run fwknop as a client. The typical authorization process from client to server can be completed as follows.

$ fwknop -A tcp/22 --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -w -k SERVER_IP

The “-w” flag queries www.whatismyip.com for the clients real ip address and uses that as the source address. This is useful when you are behind a NAT firewall, since the source address specified on the SPA packet would otherwise be a local address. If you are on the same network as the server, or simply do not have to worry about NAT, the syntax would be as follows:

$ fwknop -A tcp/22 --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -a CLIENT_IP -k SERVER_IP

If successful, your server adds the appropriate access list entry for you to connect using your ssh client. You will have 30 seconds to make the connection, after which the access list is dynamically removed.

$ ssh username@SERVER_IP

It is important to note that the SPA packet is sent to the servers IP address using the destination port of UDP/62201. You must ensure that this port number is allowed outbound from the network you are connecting from, and that no router or firewall is blocking it from reaching your server. It should also be noted that the time stamp embedded in the SPA packet must fall within 120 seconds of the servers clock. You should make sure that both the server and client are using NTP to keep their clocks as close as possible. Check out your syslogs and iptables output for useful information while testing.

$ watch -n1 sudo iptables -L -n
$ tail -f /var/log/syslog

Firewall Configuration (Optional)

If you are already using an iptables firewall configuration on your server, you may skip this step. If you would like additional information regarding iptables, please see the Self:IpablesHowTo. Here is a simple firewall script to help you test things out. Please use it with caution, as it blocks all incoming traffic! We will use it simply to demonstrate SPA functionality.

Download firewall script

Download and save the following firewall.sh script in your home directory.

Test firewall script

In order to test your script, start by opening a terminal window, (Applications → Accessories → Terminal). Check the syntax of the script and verify resulting output:

$ sudo sh firewall.sh
firewall.sh {start|stop|restart|reload|force-reload|show}

Show your current iptables configuration. If you are not running any rules, it will look like a following:

$ sudo sh firewall.sh show
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Start your firewall:

$ sudo sh firewall.sh start

Show your new iptables configuration:

$ sudo sh firewall.sh show
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
DROP       0    --  0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast
DROP       0    --  0.0.0.0/0            0.0.0.0/0           PKTTYPE = multicast
LOG        0    --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

With your new rules in place, you are now blocking all incoming traffic. To stop your firewall:

$ sudo sh firewall.sh stop

Related Articles

Resources

  • [3]
  • [4]
  • [5]
  • Self:GnuPrivacyGuardHowto
  • Self:iptablesHowTo

Credits

Special thanks to Michael Rash, author of fwknop.