Univers Libre - sysadmin

Containerize ZNC with systemd-nspawn

2019-04-20T00:00:00+00:00

On my previous server, I had an IRC client (weechat) running in a screen session. I recently migrated this setup to a ZNC bouncer running on my server + weechat running on my laptop, mainly to avoid network lags through SSH and to have a better desktop integration (notifications, etc.).

My server hosts my e-mails, important and confidential documents (among other things) and I always thought that running an always connected IRC client on the same machine was a bad idea.

So in the same time I got rid of my weechat+screen to migrate to ZNC, I had a look at systemd-nspawn, also known as systemd containers. It’s actually pretty much like LXC containers, but managed with the systemd logic in mind.

Here is a quick tutorial of how I containerized ZNC into a systemd container on a Debian stretch system:

First, install systemd-container and debootstrap packages:
```
# apt install systemd-container debootstrap
```
Create directories used by systemd-container (which aren’t create on install):
```
# mkdir /var/lib/machines/ /etc/systemd/nspawn/
```
/var/lib/machines/ will host the containers’ hierarchy and containers unit files will be stored into /etc/systemd/nspawn/.
Install a Debian system + znc package using debootstrap into /var/lib/machines/znc/:
```
# cd /var/lib/machines/
# debootstrap --include znc stretch znc
```
To make the container start on boot, you have to enable the corresponding systemd-nspawn instance and the machines target (which will start all enabled instances of systemd-nspawn unit:
```
# systemctl enable systemd-nspawn@znc machines.target
```
At this stage, your container is ready. You can start your container (run its init process) with:
```
# systemd-nspawn -D /var/lib/machines/znc/
```
Or execute a command in the container:
```
# systemd-nspawn -D /var/lib/machines/znc/ hostname
```
systemd-nspawn comes with the machinectl command which allows you to easily manage your containers:
```
# machinectl [list|list-images|start|stop|status|…]
```
See its man page for all supported sub-commands and options.
Now, let’s configure some few extra stuff to run ZNC. Create a dedicated user in the container:
```
# systemd-nspawn -D /var/lib/machines/znc/ useradd -u 1002 -g 1002 -m znc
```

And customize the container’s options by putting a config file into /etc/systemd/nspawn/:

[Exec]
# Don't start the init process inside the container, instead execute
# `znc`
Boot=off
Parameters=/usr/bin/znc --foreground

# Drop all default capabilities: the container will run with no
# capabilities, ZNC doesn't need any
DropCapability=CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_FSETID CAP_IPC_OWNER CAP_KILL CAP_LEASE CAP_LINUX_IMMUTABLE CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CAP_SETGID CAP_SETFCAP CAP_SETPCAP CAP_SETUID CAP_SYS_ADMIN CAP_SYS_CHROOT CAP_SYS_NICE CAP_SYS_PTRACE CAP_SYS_TTY_CONFIG CAP_SYS_RESOURCE CAP_SYS_BOOT CAP_AUDIT_WRITE CAP_AUDIT_CONTROL

# Start `znc` as znc
User=znc

# Those 2 options aren't supported by the version of systemd shiped
with Debian stretch. Ephemeral=on makes the container discard on
shutdown any modification made during its runtime (Docker style) and
NoNewPrivileges ensures that the code executed inside the container
won't be able to gain greater privileges (with setuid bit for instance)
#Ephemeral=on
#NoNewPrivileges=on

# Use private user namespace (equivalent to LXC's unprivilegied mode)
PrivateUsers=on
    
[Files] 
# Mount my .znc configuration directory onto the container (with write
access) and the znc.pem containing the private key, certificates chain
and DH param (read-only)
Bind=/home/romain/.znc/:/home/znc/.znc/
BindReadOnly=/var/lib/acme/live/irc.univers-libre.net/combined:/home/znc/.znc/znc.pem
    
[Network]
# Use the same network stack as the host
VirtualEthernet=no

This file will automatically be read by systemd-nspawn before starting the container. All these options can be specified as commandline parameters to systemd-nspawn as well.

Resources:

List changed configuration files and restore the maintainer's version

2019-01-24T00:00:00+00:00

Recently I had to clean one of my server (a virtual machine hosted by Tetaneutral) to make it as close to a fresh install as possible, but without reinstalling it or migrate it somewhere else. It is an old server and it has been installed by hand. Since I now use Ansible to manage my other servers, I wanted to include it to the inventory and apply the same configuration on it.

On Archlinux, I used to use this command which list me all configuration files (in /etc) which have diverged from the version shipped by the package:

$ pacman -Qii | awk '/^MODIFIED/ {print $2}'

I didn’t find a simple equivalent way to do it in Debian with dpkg tools, however I found debsums, an extra package that does the job pretty well:

$ debsums -se

I then can restore the package’s version by reinstalling the corresponding package with --force-confask option:

# apt install --reinstall -o Dpkg::Options::="--force-confask"

Here is an oneliner to automate the process (careful, it doesn’t ask for any confirmation!):

# debsums -se 2>&1 |awk '{print $4}' |xargs -n 1 dpkg -S |awk -F: '{print $1}' |sort -u |xargs apt install --reinstall -o Dpkg::Options::="--force-confask" -o Dpkg::Options::="--force-confnew"

Since xargs doesn’t work well with interactive commands, I force the choice by passing both --force-confask and --force-confnew options.

As a conclusion, keep in mind the configuration files added in *.d/ directories won’t be listed nor removed, so you still have to clean these directories manually.

Safe paste in terminal

2018-12-22T00:00:00+00:00

In my daily life of sysadmin, I copy-paste many chunk of text (commands, IP addresses, URLs, file paths, whole scripts or file contents sometimes because it’s easier to copy-paste them rather than to scp them). I usually copy them from other servers or from my company’s internal documentation (trusted sources). However, I may sometimes follow howtos or read Stackoverflow answers and copy text and commands from those less trusted websites.

I want to talk about how easy one could trick you by replacing copied text in your clipboard or inserting terminal escape sequences so that your shell will run additional and potentially malicious commands. And how I protecting myself against these tricks.

Tricks I have identified

Here is a list of tricks an attacker can use to fool you and make you paste a malicious command in your terminal.

Replacing copied text with Javascript

Dylan Ayrey demonstrates that with a few lines of Javascript, a malicious website can alter your clipboard content. The code runs on key release event (keyboard shortcut or right click) and override clipboard content with the malicious code the attacker wants you to execute.

Obviously this attack doesn’t work if you disable Javascript on unstrusted websites, which is by the way always a good idea.

Hiding malicious code with CSS

But even with Javascript disabled it’s easy for an attacker to put hidden text in your clipboard. The idea is to put the malicious code in the middle of the displayed command in a <span /> element and apply different CSS properties on it, so that the malicious code isn’t visible for the user. For instance make it float and move it away from the viewport, make it transparent, with no height or width…

Here is an interesting article about this attack. It also show how to hide the malicious code once pasted in the victim’s terminal so that the victim can’t even known he has been p0wned.

What about disabling CSS then?

Inserting non-printable characters

That’s no enough since you could have non-printable characters (like backspaces) in raw text. Here is an example (the whole thread is an interesting reading by the way). Basically, the idea is to insert extra characters and a backspace character after each of them to make the code appear inoffensive.

How I protect myself

So what next? What solutions I use to protect myself against those attacks?

Pasting into a text editor: the bad idea

In most shell, I can easily start $EDITOR with ^X^E to edit the current command. But that’s totally ineffective since the pasted text can contain ^ESC:!<malicious code> which will work in vim, or simply send the right shortcut to close the editor and get back to the shell.

Shell’s bracketed paste mode

This is an elegant solution. Bash (actually readline) can configure the terminal to enclose the pasted text between paste sequences (hence the bracketed paste mode):

enable-bracketed-paste (Off) When set to On, readline will configure the terminal in a way that will enable it to insert each paste into the editing buffer as a single string of charac‐ ters, instead of treating each character as if it had been read from the key‐ board. This can prevent pasted characters from being interpreted as editing commands.

To enable it:

$ echo "set enable-bracketed-paste on" >>~/.inputrc

If you then try to paste multi-lines commands in your terminal, the commands won’t be executed unless you press enter. You have a chance to review and edit them before their execution.

But it has two main drawbacks:

obviously enabling bracketed paste mode will work on your own computer only, unless you enable it on all your remote servers as well.
you may still be vulnerable to code injection if the pasted text contains the bracketed-paste-mode end sequence, whether your terminal automatically filter this sequence or not.

You can test this here.

confirm-paste plugin in URxvt

URxvt has a nice plugin called paste-confirm. It is shipped with URxvt and can be found in its plugin directory (/usr/lib/urxvt/perl/). Once loaded, the plugin will detect multi-lines pastes and will ask you whether to really paste it to the shell or not.

To enable it, simply add it to the plugin list in your ~/.Xdefaults:

URxvt.perl-ext-common: […],confirm-paste

Print your clipboard content before you paste

It’s always a good idea to double-check your clipboard content before pasting it somewhere. I sometimes don’t remember or I’m not sure about what was my previous selection, and I remember pasting whole file content into my terminal a couple of times…

I now use clipster for my cliboard manager with roficlip. Thus with a simple shortcut I can quickly double-check and select the previous entries in my clipboard.

Convert SSH keys from a format to another

2017-09-06T21:46:24+00:00

An SSH key can be stored in multiple format. ssh-keygen from OpenSSH generates keys in its own format, but other SSH implementations can use other formats. PuTTY for example generates keys in RFC4716 format, which looks like this:

You can’t simply copy-paste this in an authorized_keys file. Hopefully you can easily convert the public key from a format to another. This is done by I-do-about-anything-and-everything command, aka ssh-keygen:

$ ssh-keygen -i -m <format> -f input_key.pub > output_key.pub

-m specify the input key format among RFC4716 (the format used by PuTTY, this is the default if -m isn’t specified), PKCS8 and PEM.

Upgrade to Debian Jessie, introducing relay_access_restrictions in Postfix

2016-06-10T10:51:42+00:00

Abstract for TL;DR readers: since debconf append a relay_access_restrictions at the end of your main.cf file with same values of recipient_access_restriction, you have to do the same on all your services listed in master.cf. relay_access_restrictions intends to replace recipient_access_restriction on next Postfix releases.

After upgrading my mail server to Debian Jessie, I faced a weird problem with Postfix: emails sent from authenticated clients were rejected with a “Relay access denied” error.

I have a particular setup, though not-so-uncommon I think, since it should be the standard: port 25 is for server-to-server communications, no authentication is supported here. Instead, clients which want to send emails have to submit them on submission port (obviously). Concretely on my master.cf file, I override recipient_access_restriction for submission service to allow sending of emails with minimum restrictions if clients got authenticated.

So in my case, it seemed that the recipient_access_restriction option passed to submission process was ignored, or the one setup on my main.cf file won. Enabling debugging didn’t tell me anything. It even confirmed me that the recipient_access_restriction option for submission process was ignored since I saw Postfix testing all conditions specified on my main.cf

Then after some time, I have seen a new line at the end of my main.cf file : relay_access_restrictions, with all the tests of recipient_access_restrictions. Searching this on postconf(5) manual confirmed me that it replace recipient_access_restriction, although this one is always supported and not planed to be removed on the next coming versions. So debconf has added this new directive on my main.cf file, without any debconf advertisment as far as I remember, and without reason (Postfix don’t even raised a depreciation warning about that), and that breaks other services setted up on master.cf.

No ones seem to mention that on the Internet.

How to enlarge your raw disk image

2015-09-10T17:04:19+00:00

Extending a disk image file (of a KVM guest for example) is a tricky operation, especially if we haven’t enough disk space to keep a backup of the image we will working on. So I write a little howto for the next time we have to do this operation.

Prerequisites

First, you need to have the following packages installed: qemu-utils kpartx parted.

Make sure your VM is halted and no processes have opened the file:

# lsof $img

Note: for following commands, I assume $img contains the path to your image file.

Extend the image file

Pretty easy step, you can simply use qemu-img tool:

# qemu-img resize $img +50G
Image resized.

You can mount the image and check that it has the correct size:

# kpartx -v -a $img
add map loop0p1 (254:13): 0 195318207 linear /dev/loop0 63
# fdisk -l /dev/loop0 

Disk /dev/loop0: 214.7 GB, 214748364800 bytes
[...]

Extend the partition

Then, you have to extend the partition. That supposes of course either the disk image contains only one partition (which could be a LVM PV) or the partition you want to extend is at the end of the image.

Before all, backup your partition table:

# sfdisk -d /dev/loop0 >~/loop0.parts

(It could be restored with sfdisk /dev/loop0 <~/loop0.parts).

And remove and recreate the partition using all free space with parted:

# parted /dev/loop0 print
Model:  (file)
Disk /dev/loop0: 215GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  100GB  100GB  primary  ext3
..
# parted /dev/loop0 rm 1
# parted /dev/loop0 mkpart primary ext3 32.3kB 215GB
# parted /dev/loop0 print

Remount the image to see her new size:

# kpartx -d $img
loop deleted : /dev/loop0
# kpartx -v -a $img
add map loop0p1 (254:13): 0 419430337 linear /dev/loop0 63

Extend the filesystem

We are almost there, remaining the filesystem. First, this is a good thing to run a fsck before all:

# e2fsck -f /dev/mapper/loop0p1 
e2fsck 1.42.5 (29-Jul-2012)
/dev/mapper/loop0p1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/loop0p1: 41753/6111232 files (9.1% non-contiguous), 23479003/24414775 blocks

Then, resize the filesystem:

# resize2fs /dev/mapper/loop0p1 
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mapper/loop0p1 to 52428792 (4k) blocks.
The filesystem on /dev/mapper/loop0p1 is now 52428792 blocks long.

It’s done! We can check if we see the correct size after mounting the partition:

# mount /dev/mapper/loop0p1 /mnt
# df -h /mnt
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/loop0p1  197G   89G  109G  45% /mnt
# umount /mnt

Finally, unmount the image:

# kpartx -d $img
loop deleted : /dev/loop0

Get verbose output from an already launched cp/mv/rsync process

2015-05-27T19:26:18+00:00

This could be a bit obvious for others sysadmins, but I use this trick quite often and it’s really helpfull.

Imagine you connect on a server and see a running process (a cronjob for example) doing some file copy operations, running for a while and launched without -v option (or you can’t see his stdout).

Or imagine you launched a big cp/mv (from a partition to another)/rsync or whatever, you know it will probably run for a while, but you missed to add the -v option.

No problem, here is how we could get an equivalent with strace:

strace -p $(pidof cp) 2>&1 |grep open

Or for a rm:

strace -p $(pidof rm) 2>&1 |grep unlink

If you want just to see the current file your command is currently on:

lsof -p $(pidof cp)

Reverse proxy avec re-chiffrement du flux vers le backend

2014-07-11T20:50:27+00:00

Dans un environnement web critique/à fort trafic, il est courant d’avoir de multiples serveurs web, et un ou deux load-balancer devant permettant de répartir la charge et d’avoir une tolérance de panne sur les serveurs web.
Dans le cas d’un site en HTTPS, le flux est en général déchiffré par les load-balancer, puis transite en clair vers les frontaux. Cela permet de décharger les frontaux du traitement cryptographique et au load-balancer d’interpréter le HTTP, donc d’avoir certaines fonctionnalités intéressantes (répartition du trafic en fonction du virtualhost ou de l’URL, gestion des cookies de session, interprétation des codes d’erreurs HTTP renvoyés par les frontaux pour anticiper un problème, etc…).
Cependant le fait que le flux HTTP transite en clair entre les load-balancers et les frontaux peut poser problème dans certains cas :

les données qui y transitent nécessitent un haut degré de confidentialité (numéros de cartes bancaires par exemple) ;
le réseau entre le load-balancer et les frontaux n’est pas sûr (le flux repasse sur Internet par exemple).

Dans ces cas, la solution est de re-chiffrer le trafic après traitement par le load-balancer, puis chaque frontal le déchiffre à nouveau. Il faut bien noter que cette charge supplémentaire en traitement cryptographique (déchiffrement, re-chiffrement, re-déchiffrement), n’est pas anodine et la quantité de requêtes par seconde que peut encaisser la plateforme sera bien moindre que dans le cas d’un simple déchiffrement du flux par le load-balancer.

Pour en venir au cœur de l’article, j’ai dû mettre en place récemment une architecture de ce type, et j’ai été confronté à un problème dont je ne m’attendais pas vraiment : peu de reverse proxies HTTP savent re-chiffrer le flux HTTP vers les backends !

Parmi les logiciels existants :

HAProxy : dans sa version stable actuelle (1.4), il ne sait pas déchiffrer le trafic entrant, et donc encore moins re-chiffer derrière. Sa version encore en dév (1.5) supporte le déchiffrement du HTTPS néanmoins ;
Nginx : il sait bien sûr déchiffrer le HTTPS mais pas le re-chiffrer vers les backends ensuite ;
Pound : pareil que Nginx, ne sais que déchiffrer ;
Apache : le seul après recherche à savoir faire les 2 !

Voici la conf (en somme très simple) d’Apache pour lui dire de re-chiffrer le flux vers les backends. Elle nécessite bien évidemment d’avoir mod_proxy_http et mod_ssl :

<VirtualHost *:443>

    # Activation de SSL pour le trafic entrant, cas dans le cas d'un
    # serveur web classique.
    SSLEngine On
    SSLCertificateFile    /etc/ssl/certs/example.com.crt
    SSLCACertificateFile  /etc/ssl/certs/example.com-intermediate.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key

    # Activation de SSL pour la communication avec les backends.
    # On vérifie au passage que le certificat fourni par le backend est
    # bien valide.
    SSLProxyEngine          On
    SSLProxyCheckPeerExpire On
    SSLProxyVerifyDepth     10

    # Configuration classique du mod_proxy, mis à part qu'on spécifie bien
    # https dans l'URL du backend.
    ProxyRequests     Off
    ProxyPreserveHost On
    ProxyPass         / https://192.0.2.42:443/ keepalive=On retry=5
    ProxyPassReverse  / https://192.0.2.42:443/

    ErrorLog  /var/log/apache2/example.com_error.log
    CustomLog /var/log/apache2/example.com_access.log combined
</VirtualHost>

Ajout d'une carte son à chaud dans un conteneur LXC

2014-01-21T21:02:08+00:00

Voici un article express pour rajouter une carte son dans un conteneur LXC, plus un aide-mémoire en fait, car c’est pas le genre de chose que je fais tous les 4 matins.

Brancher la carte son à la machine hôte. Dans mon cas une carte USB, si c’est en PCI, la procédure n’a que peu d’intérêt puisqu’il faudra dans tout les cas redémarrer.
le kernel doit la détecter et créer des fichiers spéciaux de type caractère dans /dev/snd :

```
# ls -l /dev/snd/
total 0
drwxr-xr-x 2 root root       60 Jan 21 19:44 by-id
drwxr-xr-x 2 root root       60 Jan 21 19:44 by-path
crw-rw---T 1 root audio 116,  4 Jan 21 19:44 controlC0
crw-rw---T 1 root audio 116,  3 Jan 21 19:44 pcmC0D0c
crw-rw---T 1 root audio 116,  2 Jan 21 19:44 pcmC0D0p
crw------T 1 root root  116,  1 Dec 17 09:24 seq
crw-rw---T 1 root audio 116, 33 Dec 17 09:24 timer
```

Notez le numéro majeur et mineur de chaque pseudo fichier (dans mon cas 116
et de 1 à 4 et 33).

Ajoutez les autorisations nécessaires dans votre conf LXC pour le conteneur en question :

```
# /dev/snd/*
lxc.cgroup.devices.allow                = c 116:4 rwm
lxc.cgroup.devices.allow                = c 116:3 rwm
lxc.cgroup.devices.allow                = c 116:2 rwm
lxc.cgroup.devices.allow                = c 116:1 rwm
lxc.cgroup.devices.allow                = c 116:33 rwm
```

Adaptez bien sûr avec les bons numéro majeurs et mineurs.

À ce stade, il faut redémarrer le conteneur pour que les nouveaux cgroups s’appliquent. Comme j’avais pas envie de faire ça et que les cgroups cesttropbien, On va appliquer les nouvelles règles à chaud via son pseudo système de fichier :

```
# cat >/sys/fs/cgroup/lxc/<nom du conteneur>/devices.allow
c 116:4 rwm
c 116:3 rwm
c 116:2 rwm
c 116:1 rwm
c 116:33 rwm
^D
```

Maintenant, on peut créer manuellement les pseudo fichiers dans le conteneur :

# mkdir /dev/snd; cd /dev/snd
# mknod controlC0 c 116 4
# mknod pcmC0D0c c 116 3
# mknod pcmC0D0p c 116 2
# mknod seq c 116 1
# mknod timer c 116 33
# chgrp audio controlC0 pcm* timer
# chmod 1660 controlC0 pcm* timer
# chmod 600 seq

Et ajoutez vous dans le groupe audio si besoin.

Installer alsa-utils puis :
```
$ alsactl init
```

Votre carte devrait à présent être détectée, vous pouvez vérifier que tout
fonctionne avec un `speaker-test`.

Et voila.

Bon c’est pas tout ça, allons mettre à jour le kernel et rebooter :-).

Changer simplement la couleur du curseur dans rxvt

2013-11-01T17:53:37+00:00

Où comment identifier facilement le serveur de prod de celui de preprod (ou le master du slave, ou celui de prod et son futur remplaçant…).
Bref, comment différencier facilement votre terminal avec une connexion SSH sur un serveur critique, et celui vers un serveur où vous pouvez tout casser^W^W^W^W^W moins critique.
C’est surtout valable quand les hostnames ne diffèrent que d’une lettre ou d’un chiffre, où la confusion est plus facile.

Si il s’agit d’un serveur perso, le plus simple reste de modifier le prompt de votre shell. Mais ce n’est pas envisageable sur un serveur sur lequel vous vous contentez d’intervenir, ou où plusieurs admin sont susceptibles d’utiliser le compte root.

La solution est d’agir au niveau de votre terminal, ici urxvt. Les options de rxvt peuvent être quasiment toutes changées à chaud grâce à des commandes envoyées dans des séquences d’échappement du shell. Par exemple, pour avoir un curseur rouge, la commande à envoyer est \033]12;red\007. Vous pouvez tester avec un simple echo :

$ echo '\033]12;red\007'

C’est magique, mais ça reste compliquer à écrire, et encore plus à retenir. On va donc affecter la commande à une séquence de touche, par exemple Alt+! (et Alt+Shift+!). Dans votre .Xdefaults/.Xressources :

URxvt.keysym.M-S-exclam: command:\033]12;red\007
URxvt.keysym.M-exclam: command:\033]12;#657b83\007  # #657b83 à remplacer par la couleur de votre police par défaut.

À noter qu’ainsi, même en étant dans un éditeur de texte, vous identifierez rapidement le serveur de prod car le curseur restera rouge, ce qui n’est pas le cas avec un prompt coloré.

L’inconvénient est que le changement de couleur du curseur n’est pas automatique, même si il est bien simplifié. Si vous avez une liste précise de serveurs en prod, une idée peut être, à l’aide d’une extension Perl à rxvt, de comparer le titre de la fenêtre X11 (qui contient le hostname du serveur) à cette liste, pour pouvoir changer la couleur du curseur en conséquence.

Référence :

Article de Ulhume très intéressant et plus complet à propos des styles de curseur, avec une utilisation différente.

Limiter le nombre de connexions SSH avec pf

2013-09-05T22:19:19+00:00

Le port SSH doit probablement être parmi les plus testés par les scripts kiddies. Même si le mieux reste de restreindre l’accès par IP et de n’autoriser l’authentification que par clé, ce n’est des fois pas possible. Dans ce cas, on se retrouve avec une avalanche de tentative de connexion et le auth.log qui explose en taille. Ça devient lourd (dans les 2 sens du terme :-) ).

Afin de bannir une IP au bout d’un trop grand nombre de connexions par unité de temps, il existe différents outils qui analysent les logs et ajoutent des règles dynamiquement comme fail2ban, mais je préfère agir directement au niveau pare-feu quand c’est possible. Avec iptables sous Linux, il existe le module limit. Avec Packet Filter, voici comment procéder :

Créer une table, qui contiendra les IP bannies :
```
table <badguys> persist
```
on drope donc tous ce qui provient des IP présentes dans la table :
```
block in quick on $wan_if from <badguys>
```
et enfin la règle intéressante :
```
pass in on $wan_if proto tcp to self port ssh flags S/SA keep state (max-src-conn 3, max-src-conn-rate 5/30, overload <badguys> flush global)
```
La règle permet de limiter l’établissement d’une connexion sur le port SSH à 3 connexion simultanée (max-src-conn 3) et avec une limite de 5 connexion par tranche de 30 secondes (max-src-conn-rate 5/30). Si une IP dépasse cette limite, elle est ajoutée à la table badguys (overload <badguys>) et tous les états que l’IP aurait déjà pu avoir sont supprimés (flush global).

Ensuite, on peut faire expirer les IP présentes dans la table avec un simple cron :

33 3 * * *  /sbin/pfctl -t badguys -T expire 86400 2>&1 |grep -v "0/0 addresses expired."

Archlinux dans un conteneur LXC et paquet filesystem

2013-06-03T21:04:00+00:00

Parmis mes conteneurs LXC, il y en a un qui tourne sous Archlinux. Comme j’avais un peu joué avec les capabilities (7) du noyau, qu’on peut retirer avec lxc.cap.drop dans le fichier de conf du conteneur, mon /sys/ (entre autre) est en lecture seule pour le système chrooté.
Par jouer il faut comprendre rajouter des lxc.cap.drop sur des capabilities choisies au feeling, jusqu’à ce que ça ne marche plus. J’exagère mais c’était un peu ça l’idée au final :-).

Donc, comme mon /sys/ est en lecture seule, la mise à jour du paquet filesystem chie lamentablement dans la colle :

error: cannot remove file '/sys/': Read-only file system
error: could not commit transaction
error: failed to commit transaction (transaction aborted)

Par flème, lorsque une mise à jour du paquet était disponible, je l’excluais manuellement avec :

# pacman --ignore filesystem -Syu

Puis vint le jour où la mise à jour d’un paquet demandait une version à jour du paquet filesystem. Forcement, ça devait arriver un jour…

Et c’est là qu’en cherchant un peu, j’ai découvert que dans la configuration de pacman, on peut lui dire d’empêcher un paquet de toucher à un fichier. Ça se rapproche un peu du dpkg-divert de Debian.

Dans /etc/pacman.conf :

NoUpgrade    = sys/
NoExtract    = sys/

le répertoire /sys/ sera ignoré, et la mise à jour de filesystem se fait sans soucis !

Pour plus de détails, voir pacman.conf(5).

Tracer un processus sur un système BSD

2013-05-09T21:01:04+00:00

Récemment sur un système OpenBSD, j’ai voulu suivre les appel système que faisait un process :

# strace isakmpd -vd
ksh: strace: not found
# pkg_add strace
Can't find strace

OMG, comment faire ?!

En fait, strace est spécifique à Linux, et un équivalent existe sur les systèmes BSD. Il s’agit du couple ktrace/kdump. En gros, ktrace permet de contrôler l’enregistrement ou non des appels que fait un process, et kdump permet de lire le fichier binaire que son cousin a généré (nommé ktrace.out par défaut).

Petit exemple d’utilisation :

ktrace <PID>

Équivalent de l’option -f de strace (pour tracer également les processus fils) :

ktrace -id <PID d'une processe qui fait plein de petits>

Équivalent de l’option -p de strace (pour tracer un process existant, sans devoir le relancer). Bon là ça ne change pas trop :

ktrace -p <PID d'un process applicatif super critique, lancé depuis une éternité, que plus personne ne sait comment le relancer et que si il crash c'est la fin du monde>

Quand vous avez récupéré suffisamment de traces à lire (ou quand vous vous apercevez que votre ktrace.out a pris 100 % de l’espace libre restant sur la partition), pour arrêter l’enregistrement :

ktrace -C

Maintenant que vous avez votre bon gros fichier binaire avec plein de traces dedans :

kdump |less

Si l’enregistrement des traces est toujours en cours, vous pouvez avoir l’équivalent d’un tail -f :

kdump -l

Pour plus de détail, voir bien sûr les man de ktrace (1) et kdump (1).

Passer root sans terminal

2012-01-26T00:00:00+00:00

Dans certains rares cas, on peut vouloir exécuter des commandes en tant que root sans avoir la possibilité d’allouer un terminal sur la machine en question.

Pour ceux qui aiment bien lire la fin en premier, je mets la fin au début :-) :

echo "mypassword" |sudo -S id

Pour illustrer le problème, prenons un cas concret qui m’est arrivé.
Un serveur s’est soudainement mis dans un état bizarre, à savoir que tout marchait, les processus déjà en cours continuaient de s’exécuter, d’autres processus pouvaient se créer, mais certaines choses ne marchaient pas, notamment l’allocation de pseudo-terminaux (les /dev/pts/*) ; si je tente une connexion SSH au serveur, le serveur répond bien, l’authentification se fait, et au moment d’avoir mon prompt, la connexion se freeze.
Après divers tests, je m’aperçois qu’en passant directement une commande à ssh, ça marche :

ssh serveur-foireux dmesg

La différence vient du fait que dans le deuxième cas, ssh n’ouvre pas de pseudo-terminal sur le serveur distant, puisqu’il se contente de récupérer directement stderr et stdout.
On peut faire en sorte de se connecter sans allouer de terminal sur le serveur avec l’option -T de la commande ssh :

-T Disable pseudo-tty allocation.

On a ainsi un shell qui s’exécute sur la machine, et on récupère la sortie brute de stderr et stdout (pas de prompt, d’édition de la commande en cours, etc…). Pareil pour stdin, ce qui fait que les commandes sudo ou su retournent une erreur, étant donné qu’elles font une manipulation spécifique sur stdin (pas d’echo pour la saisie du mot de passe). De ce fait, on est un peu coincé pour passer root.

Il existe une solution (que j’ai bien sûr trouvé après avoir brutalement redémarrer le serveur), une simple option à sudo qui permet de lire le mot de passe depuis stdin. Et là, pas besoin d’exécuter la commande dans un terminal donc !

echo "mypassword" |sudo -S id
[sudo] password for rdessort: uid=0(root) gid=0(root) groupes=0(root)

Et comme cela affiche votre mot de passe en clair sur l’écran, voici un petit script pour améliorer la chose :

#!/bin/bash

echo -n "Enter password: "
read -s passwd

ssh serveur-foireux "echo $passwd |sudo -S id"

Une autre application probablement beaucoup plus courante pourrait être de pouvoir scripter des commandes nécessitant d’être root sur le serveur. Notamment exécuter la même commande sur plusieurs dizaines de serveurs d’affilée.

Utiliser AWStats sans CGI

2011-01-09T00:00:00+00:00

AWStats est un générateur de statistiques, le plus souvent utilisé pour générer des stats sur des serveurs web (il peut aussi être utilisé pour des serveurs mail, ftp…). C’est une appli en Perl, qui peut donc être appelé par le serveur web via CGI pour générer les pages HTML.

Sur Apache ou Lighttpd ça marche sans problème, mais sur un serveur web qui ne supporte pas CGI (NginX par exemple, à moins de passer par des hacks assez tordus) ça ne marche plus.

La solution est donc de dire à AWStats de générer les page HTML automatiquement après chaque mise à jour de sa base de données. Voici la procédure :

Créez tout d’abord le répertoire qui contiendra les pages HTML, avec les bons droits :
```
mkdir /var/www/awstats/
chown www-data:www-data /var/www/awstats/
```

Modifiez ensuite le fichier /etc/cron.d/awstats pour appelez le script awstats_buildstaticpages.pl au lieu de awstats.pl :

[ -x /usr/share/doc/awstats/examples/awstats_buildstaticpages.pl \
-a -f /etc/awstats/awstats.yoursite.conf -a -r /var/log/nginx/yoursite.access.log ] \
&& perl /usr/share/doc/awstats/examples/awstats_buildstaticpages.pl -update \
-config=yoursite -dir=/var/www/awstats -awstatsprog=/usr/lib/cgi-bin/awstats.pl >/dev/null

À adapter bien sûr avec les bons noms de fichiers de conf et de log.

N’oubliez pas d’ajouter un alias dans la conf de votre serveur web pour les icônes. Sous NginX, ça donne ça :
```
  location /awstats-icon/ {
      alias /usr/share/awstats/icon/;
  }
```

Utiliser la fonction PHP imagerotate() sous Debian

2010-09-18T00:00:00+00:00

imagerotate est une fonction PHP qui, comme son nom l’indique, permet de tourner une image selon un angle. Cependant elle n’est disponible que si PHP a été compilé avec la version embarqué de la bibliothèque GD.

Sous Debian ce n’est pas le cas, car cette version est difficilement maintenable au niveau sécurité (cf le bug report Debian)

Pour contourner le problème, en cherchant un peu sur le net (ici par exemple), beaucoup de monde recompile PHP avec la version embarqué de GD. Ce n’est à mon avis pas la meilleure solution au niveau “maintenabilité”.

Voici donc 2 autres possibilités.

Utiliser les dépôts dotdeb

Les dépôts dotdeb contiennent des versions plus récentes et/ou modifiés de paquets Debian pour serveurs LAMP. Le paquet php5 présent dans dotdeb est justement compilé avec la version embarqué de la bibliothèque.

Réécrire la fonction imagerotate()

Si vous n’avez besoin que de cette fonction et que vous n’avez pas envi d’utiliser la version embarqué de GD, il est tout à fait envisageable de réécrire la fonction en question :

readImage($temp_src);
      $imagick->rotateImage(new ImagickPixel($bgd_color?$bgd_color:'black'), $angle);
      $imagick->writeImage($temp_dst);
      //trigger_error( 'imagerotate(): could not write to ' . $file1 . ', original image returned', E_USER_WARNING );
      $result = imagecreatefromjpeg($temp_dst);
      unlink($temp_dst);
      unlink($temp_src);
      return $result;
  }
}
?>

trier numériquement la sortie d’un du -h

2010-09-11T00:00:00+00:00

Afficher la taille que prend un répertoire ainsi que ses sous répertoires est une tache assez courante, du moins pour un administrateur système. Cela se fait simplement avec la commande :

du -sh foo/*

Ou bien, si on veut avoir aussi les sous sous répertoires :

du -h --max-depth 2 foo/*

L’option -h permettant d’avoir la taille exprimé en kilo, méga, giga, etc…

Là où les choses se compliquent, c’est lorsqu’on veut trier numériquement le résultat par ordre décroissant. Si on fait un :

du -sh foo/* |sort -rn

le tri sera faussé du fait de la présence des lettres qui suivent la taille.

D’où l’astuce du jour : comment trier numériquement la sortie d’un du tout en ayant la taille exprimé en “human readable” ?

Si vous avez le paquet coreutils en version ≥ 7.5, vous êtes sauvé, sort implémente l’option -h qui répond exactement au problème :

du -sh foo/* |sort -rh

Dans le cas contraire (si vous êtes sur une Debian Lenny par exemple), c’est un peu moins simple.
En cherchant un peu sur le net, il existe un tas d’astuces différentes utilisant perl ou awk. Voici celle que j’utilise, qui me semble la moins tordue (mais un peu quand même) :

du -s foo/* |sort -rn |cut -f2 |xargs -d '\n' du -sh

Le principe est d’obtenir d’abord la liste des répertoires avec leur taille “brute”, de trier cette liste, puis de refaire un du (avec -h cette fois) sur chaque répertoire de la liste).
Le fait d’exécuter 2 fois un du n’est pas super élégant point de performance, mais en pratique, comme le résultat du premier du est caché en mémoire, le second est très rapide.

Hard reboot à distance

2010-08-09T00:00:00+00:00

Voici une astuce bien utile si votre serveur est complètement planté. Il faut néanmoins pouvoir se connecter en SSH sur la machine et avoir un shell en root.

Dans mon cas, il s’agissait d’un problème d’accès disque, la plupart des commandes exécutées renvoyaient des erreurs d’entrée/sortie, y compris la commande reboot, qui a besoin d’exécuter les scripts d’init de niveau 6.

Mais tout n’est pas perdu, si vous n’avez pas d’accès physique à la machine ! On va passer par le pseudo système de fichier /proc pour parler directement au noyau et lui dire de redémarrer la machine. Avant tout (et si il ne s’agit pas d’un problème disque), on tente de forcer la synchronisation du cache vers le disque :

sync

On active ensuite les magic sysrq key si elles ne le sont pas déjà :

echo 1 > /proc/sys/kernel/sysrq

Puis on modifie l’état de la machine :

echo b > /proc/sysrq-trigger

Cette dernière action a exactement le même effet que la combinaison Alt + Syst + b.

Après cela, priez pour que la machine redémarre correctement :-).

Compter le nombre de connections par IP

2010-06-18T00:00:00+00:00

Aujourd’hui au boulot, j’ai été confronté à un petit problème : sur un serveur victime d’une attaque DDoS (visiblement), je voulais savoir quelles IP ouvraient le plus de connections. Ne trouvant rien de bien intéressant dans les commandes Unix, j’ai écris un petit script en Perl.

Il se charge de récupérer la sortie de netstat (la commande est à adapter à votre besoin) et compte le nombre de lignes identiques (donc d’IP), qu’il se charge ensuite de trier par ordre décroissant et d’afficher.

Voici le script en question :

#!/usr/bin/perl

use strict;
use warnings;

my %addrs = ();
my @netstatOut = split( /\n/, `netstat -taupen | grep SYN | tr -s " " | cut -d" " -f 5 | cut -d: -f1` );
for (@netstatOut) {

    chomp $_;
    $addrs{$_} += 1;
}

for my $key ( sort {$addrs{$b} <=> $addrs{$a}} keys %addrs ) {
    print $addrs{$key}."\t$key\n";
}

Le script retourne alors son résultat sous la forme :

nbConnection    IP1
nbConnection    IP2
...

Il ne vous reste plus qu’à blacklister les IP les plus actives avec la commande

iptables -I INPUT -s IP -j DROP

Connexion ssh derrière un proxy

2009-11-17T00:00:00+00:00

Peut-être avez vous déjà rencontré ce problème, il n’est pas possible de se connecter en SSH sur un serveur lorsqu’on se trouve derrière un proxy.

Je m’en suis aperçu quelques jours après le début des cours à l’IUT de Nancy lorsque j’ai voulu créer un tunnel SSH (on verra comment par la suite) pour pouvoir accéder à mes mails, les messageries instantanées, etc… Le réseau de l’université se trouve en effet derrière un proxy qui bloque tout et n’importe quoi (en fait seul les ports http et https sont autorisés).
Souvenir du réseau wifi de l’IUT de Marseille où on pouvait télécharger en P2P les ~~films~~ ISO Linux en quelques minutes… :(.

Pour résoudre le problème (du ssh, pas du P2P), il y a deux choses à faire.

Coté serveur

Bien entendu, comme le proxy bloque tout sauf http et https, il n’y a pas de miracles, il faut faire écouter le serveur SSH sur le port https (les transfert sont chiffrés pour https et SSH, le proxy ne peut pas voir la différence). Pour ça, modifiez votre /etc/ssh/sshd_config pour changer la valeur de Port :

Port 443

Redémarrez OpenSSH et assurez vous de changer les ports également dans votre pare feu et votre routeur.

Coté client

À priori, on peut croire que le problème est maintenant résolu, le serveur écoute sur le port https, le proxy laisse passer les données sur le port https, et le client indique de ce connecter par le port https. Et bien non, ce n’est pas aussi simple, et je n’ai eu la réponse qu’aujourd’hui, pendant un cours sur les serveurs web.

En fait, le fait de passer par un proxy interdit de faire une connection direct entre le client et le serveur (un proxy étant fait pour s’intercaler entre les échanges). Il faut donc dire explicitement au proxy d’établir une connection direct entre les deux machines, et de ne plus s’en mêler ensuite. C’est grâce à la commande HTTP CONNECT que c’est possible (vous voyez mieux le rapport avec les serveurs web à présent ;) ).

Pour réaliser ça en pratique, on va utiliser corkscrew. Installez le puis modifiez votre fichier client /etc/ssh/ssh_config comme ceci :

Host univers-libre.net-proxy
        Hostname univers-libre.net
        Port 443
        ProxyCommand /usr/bin/corkscrew vivianen.iuta.univ-nancy2.fr 3128 %h %p

Host univers-libre.net
        Port 443

Explications :
on a définit 2 configurations (host, dans le fichier) : une dans le cas normal (univers-libre.net) et une autre avec un proxy (univers-libre.net-proxy).
Ainsi, si vous êtes derrière le proxy, vous devrez taper :

ssh univers-libre.net-proxy

Dans le cas contraire :

ssh univers-libre.net

Dans la configuration avec proxy, on indique que, en fait le vrai nom n’est pas univers-libre.net-proxy mais univers-libre.net (avec la directive hostname). Le port est bien sûr fixé à 443 (https) dans les 2 cas.
Viens la ligne ProxyCommand : on dit à OpenSSH de faire appel à corkscrew en lui passant en paramètre l’adresse du proxy (ici vivianen.iuta.univ-nancy2.fr), le port du proxy (3128 qui est le port par défaut des proxies). %h et %p indiquent respectivement l’hôte à atteindre et son port (univers-libre.net et 443).

Maintenant que vous avez un accès SSH sur votre serveur à vous la liberté :) . Vous pouvez alors créer un tunnel SSH pour certaines applications, en rajoutant une ligne de ce type dans le fichier /etc/ssh/ssh_config de votre client :

LocalForward 143 localhost:143

Dans cet exemple je dis de rediriger toutes les demandes de connections qui sont envoyées sur le port 143 (imap), vers le même port et sur le même serveur que le serveur SSH (localhost). Ainsi mon client mail pourra accéder à mon serveur imap, le tout de façon transparente, mais crypté dans le tunnel :-).

Passer une partition de ext2 à ext3 sans la reformater

2009-01-19T00:00:00+00:00

Même si plus beaucoup de monde utilise encore le système de fichier ext2, il se peut qu’il vous reste de vielles partitions ext2 qui traine dans un coin de votre disque dur.

Si c’est votre cas, et que vous avez toujours eu la flemme de sauvegarder les données de la partition, la formater, puis restaurer les données, voici la commande magique, à appliquer tel quel, sans sauvegarde des données :

tune2fs -j votre_partition

Petite explication (et la commande semblera moins magique :-) ) :
Il faut savoir que la différence entre ext2 et ext3 vient uniquement du fait que ext3 est journalisé, c’est à dire (en gros) que toutes les écritures réalisées sur le disque (appelées transactions) sont inscrites (journalisées) dans un journal stocké sur la partition. Cela permet, si un crash du disque survient (coupure de courant, freeze, …), de garder une cohérence dans les données écrites sur le disque (en analysant uniquement le journal, pas besoin d’aller scanner tout le disque).
Pour revenir à notre commande, celle ci ne fait que créer ce fameux journal sur la partition, rien de plus. Au prochain montage de la partition, celle ci sera monté en tant qu’ext3.