// Buchempfehlung: Linux-Firewalls von Ralf Spenneberg

Cover, Ralf Spenneberg: Linux-Firewalls Jeder, der Linux-Server verwaltet oder z.B. Linux-SOHO-Router1) betreibt, wird früher oder später mit dem Thema “iptables/Netfilter” (bzw. ip6tables/Netfilter6) konfrontiert. Oft hangeln sich die jeweiligen Administratoren und Benutzer dann via Google von HowTo zu HowTo, und zimmern sich mit gefährlichem Halbwissen eine iptables-Firewall-Konfiguration zusammen. Alternativ wird zu Shorewall oder vergleichbaren Projekten gegriffen.

Falls man sich mit Linux basierenden Firewalls auseinandersetzen will, kann ich stattdessen jedem das Buch Linux-Firewalls von Ralf Spenneberg in seiner neusten Auflage empfehlen. Es ist sehr gut strukturiert und äußerst verständlich geschrieben, sofern man zumindest die absoluten Grundlagen eines Netzwerks hinsichtlich IP, TCP und UDP beherrscht. Der Autor führt den Leser gut an das Thema heran. Alles beginnt mit der Erklärung einfacher stateless-Paketfilter und geht dann über zu gut nachvollziehbaren stateful-iptables-Regeln. Es wird dabei genau für die Art von Grundverständnis gesorgt, welches bei einfachen Tutorials im Netz meist unter den Tisch fällt. Anschließend werden DMZ, transparente Firewalls, NAT-Router und vieles mehr mit iptables gebaut. Connection Tracking und dessen Konfiguration, wichtige Kernel-Parameter, Protokollierung und hilfreiche Werkzeuge nehmen ebenfalls einen großen Teil des Buchs ein. Auch das Thema IPv6 wird sehr verständlich betrachtet und das nötige Wissen vermittelt, um IPv6-fähige Firewalls betreiben zu können. Alles in allem kann ich das Buch uneingeschränkt empfehlen, auch als Nachschlagewerk.

1)
Ich schreibe absichtlich SOHO-Router: man will für gewöhnlich keinen 10GbE-Router mit iptables betreiben/bauen.

// How to create SSH keys

SSH provides the possibility to use Public Keys to log in to a target system (which is very likely more secure than a password). To make this possible:

  1. The user has to create a Public/Private Key pair
  2. The user's Public Key(s) has/have to be stored on the target system running the SSH Server (normally within ~/.ssh/authorized_keys)
  3. The server's Public Key has to be stored on the local system running the SSH Client (normally within ~/.ssh/known_hosts)

Some popular services like GitHub do not even provide a password based authentication for data exchange, forcing you to use a SSH Public Key. Same for the Fedora Account System (FAS) where I created an account recently.

On a common Linux system, all needed SSH client tools should be installed by default. If not (e.g. because they were removed), simply install the openssh-clients package on Fedora or the openssh-client package on Debian/Ubuntu. After installation, the SSH tool for authentication, key generation, management and conversion is available via terminal: ssh-keygen

Creating a Public/Private Key pair

As already said, ssh-keygen is the tool for creating a key pair. It brings a lot of options, I'm going into detail on the most important ones:2)

  • -b <bits>:
    From the manpage: “Specifies the number of bits in the key to create. For RSA keys, the minimum size is 768 bits and the default is 2048 bits. Generally, 2048 bits is considered sufficient. DSA keys must be exactly 1024 bits[…]”.
  • -t <type>:
    Specifies the type of key to create. The cryptographic algorithm to use will selected through specifying this parameter. For SSH2, you can choose between “rsa” and “dsa”.3)
  • -C "<comment>":
    Provides a comment for the key. The comment is used as “name” for the key in most applications. If not given, username@host will be set by default. You can change the comment later without any problems.

Using a 2048bit long RSA key is a good choice for most use-cases. 1024bit RSA is no longer regarded as indisputably secure, 4096bit RSA is for paranoid person like me. Please make sure you set a passphrase to protect your key. Otherwise everyone who may gets access to it (e.g. because someone steals your laptop and copies the keyfile) is able to get instant access to all systems you used the key for logging in. In contrast, you should have enough time to change the keys on all affected system without any danger if you used a good passphrase for a leaked private key. Additionally, it is no problem to use multiple SSH keys. So if you need a SSH key without password (e.g. for a quickly hacked backup script), create a separate key for this special task but do not use it for logging in to important systems.

Before you start: If you do not answer the question “Enter file in which to save the key” properly, you possibly overwrite an already existing key pair (if any). So take care which filename you are using for storage. The defaults are id_rsa and id_dsa (depending on the used algorithm). You have been warned!

Now open a terminal and let's go:

user@local:~$ ssh-keygen -t rsa -b 2048 -C "user@local"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):

As you can see, the key will be stored into ~/.ssh/id_rsa by default. To choose another file, you have to provide the complete path (→ ~/ normally does not work to point to your home dir). I use the non-default path /home/user/.ssh/mykey in this example.

You should store all SSH keys into the default directory ~/.ssh (no matter which filenames you are using for them). Otherwise, many tools and programs are not able to locate your SSH keys by default, leading to more configuration issues. None the less, it is possible to store your keys in another directory than the default one. ssh-add /path/to/your_key is your friend.

Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/.ssh/mykey
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/mykey.
Your public key has been saved in /home/user/.ssh/mykey.pub.
The key fingerprint is:
10:af:1e:58:a3:a2:2a:7e:11:23:52:bf:c2:32:61:fa user@local
The key's randomart image is:
+--[ RSA 2048]----+
| ...     o       |
|     + o         |
|  . o = .        |
| ... o +         |
|.. .  . S        |
| o  .            |
|Bo.  .       .+  |
|E oo.            |
| +o+o            |
+-----------------+

Done. Now you got the needed key pair:

  • /home/user/.ssh/mykey is the private key. Never share this one with someone else. Simply keep the Private Key… well, private. ;-)
  • /home/user/.ssh/mykey.pub is the public key (also called “ID file” or “identity file”). This is the one you have to upload to the remote systems.

Tips and tricks

  • If you never heard about the “randomart image”, you may have a look at “What is randomart produced by ssh-keygen?”.
  • If you need a GUI, have a look at GNOME Seahorse or PuTTY.
  • Have a look at IBM: Shhh ... secrets about SSH and GitHub: Multiple SSH keys if you have trouble when using more than one SSH key.
  • Close ssh if the session is not responding anymore: The command ~. closes the ssh client program if the server hangs (e.g. because it was unexpectedly shut down or your internet connection is not stable).
  • Copy the Public Key(s) to a remote system: ssh-copy-id helps you to copy your SSH Public Key into the ~/.ssh/authorized_keys file of the remote system and/or copy the remote system's public key into your local ~/.ssh/known_hosts file. Usage:
    ssh-copy-id -i "~/.ssh/mykey.pub" remote-user@remote.example.com
  • Change the passphrase of a SSH key: ssh-keygen is also the tool of choice to change a key's password. The -f parameter specifies the private key file you want to change. The -p parameter tells the program that you want to change the password of an existing key, preventing the generation of a new one:
    ssh-keygen -f /path/to/your_key -p
  • Change the comment of a SSH key: ssh-keygen is also the tool of choice to change a key's comment. The -f parameter specifies the private key file you want to change. The -c parameter tells the program that you want to change the comment of an existing key, preventing the generation of a new one:
    ssh-keygen -f /path/to/your_key -c
2)
it is very likely you do not need any others. Consider the manpage otherwise.
3)
Which one is better is arguable. I wrote about this in another context. :lang_de:

// How to start with Bash

Writing Bash scripts is fundamental to automate and understand many tasks on common Unix-like environments. If you are new to Bash (or even Unix-like systems) you'll have it a lot easier if you take a weekend to learn some fundamental principles before starting to script your stuff. No matter how experienced you are in programming, everything you'll find regarding Bash is much easier to follow and understand if you know some things before.

High quality online readings

IMHO, the following resources are good starting points:

  1. Linux Shell Scripting Tutorial (LSST) :!:Extremely good resource, especially for beginners.
  2. Bash FAQ – Many answers to frequently asked questions.
  3. The official GNU bash manual – Reference work. If you are generally familiar with Bash/*ix or simply search for a specific thing: look at the manual. Nearly everything should be documented there.

Things you should understand before you write serious scripts

To make it much easier for yourself, make sure you understand4) the following (the resources mentioned above will help you):

  1. Streams and redirection
    Standard Input (stdin, 0), Standard Output (stdout, 1) and Standard Error (stderr, 2). It is really fundamental to understand the stream concept. How streams are working. And how to manipulate, redirect and merge them. This is particularly important before writing much code or libraries. Otherwise you may have to change many things over and over again to make your scripts are interacting smoothly with the system (→ error logging etc.).
    Example of things you should be able to do blindfolded:
    • merge foobar's stderr (2) into foobar's stdout (1):
      foobar 2>&1
    • If you redirect foobar's stdout (1) into a file now, all error messages will also be written into the file because stderr (2) is merged into stdout (1):
      foobar > ~./logfile.log 2>&1
    • If you understand the two steps above, it is clear what the following does:
      echo "message" 1>&2

      Explanation: echo prints something to stdout (1). 1>&2 merges stdout into stderr. Therefore “message” will be printed as error to stderr(2) instead of creating simple standard output – this is the way to go if you want to print a simple error message. You also need redirections if you want to use sudo.

  2. Exit codes
    This is particularly important before writing much code to make sure your scripts are interacting smoothly with other applications.
  3. Pipes and Filters
  4. Subshells and the so called Subshell Problematic
  5. Background processes
    E.g. how to start them (→ &).
  6. Globbing and the Internal Field Separator (IFS)
    Make sure you be able to change and restore the IFS. And know how to use find and why you need it.
  7. Regular Expressions and useful tools
    The sed, cut, grep and find commands are available on nearly every system and are very helpful when you need to edit, find, manipulate or create files and data.
  8. Learn how to detect if you are root
    if [ "$(id -u)" != "0" ]
    then
        echo "This script needs root privileges!" 1>&2
        exit 1
    fi
  9. Learn how to define functions
  10. Here Documents
    See the Here Documents at the LSST for details.

Last but not least: find a project

You'll learn the most if your scripts are doing real jobs. Create a backup script. Or try to configure your whole desktop by script to make things comfortable on freshly installed systems.

4)
at least: know when you will need them and where you can look it up. Or better: be able to do the things blindfolded.
I'm no native speaker (English)
Please let me know if you find any errors (I want to improve my English skills). Thank you!
Recent Comments
QR Code: URL of current page
QR Code: URL of current page start (generated for current page)