sslh : faire cohabiter SSH et HTTPS

Sur un système Unix libre, il n'est pas possible de faire écouter deux services réseau sur un même port. sslh est un logiciel qui permet d'écouter sur un port et redirige le trafic vers un service, selon les premiers octets écoutés. Il devient ainsi possible, par exemple, de partager son port 443 entre un serveur SSH et un serveur HTTPS.

La configuration est très simple, voici ce que j'ai mis en place sur un Raspberry Pi fonctionnant sous NetBSD :

verbose: false;
foreground: false;
inetd: false;
numeric: false;
transparent: false;
timeout: 2;
user: "nobody";
pidfile: "/var/run/sslh.pid";

listen:
(
    { host: "netpi3"; port: "443"; }
);

protocols:
(
     { name: "ssh"; service: "ssh"; host: "netpi3"; port: "22"; probe: "builtin"; },
     { name: "ssl"; host: "netpi3"; port: "8443"; probe: "builtin"; }
);

Avec cette configuration, sslh redirige le trafic SSH vers netpi3 sur le port 443 vers netpi3 sur le port 22 (j'aurais pû mettre localhost), et redirige aussi le trafic HTTPS vers netpi3 sur le port 443 vers netpi3 sur le port 8443 (j'aurais aussi pû mettre localhost). Un inconvénient à ce système, c'est que le trafic vu par le serveur SSH ou par le serveur HTTPS est vu comme provenant de l'IP hébergeant sslh. Cela peut s'avérer gênant dans la configuration d'un pare-feu ou d'autres outils comme Fail2ban. Il existe toutefois une configuration pour ce dernier, et dans le cas de Linux et de FreeBSD, sslh gère une fonctionnalité de proxy transparent (voir la documentation).

A noter que HTTPS et SSH ne sont pas les seuls protocoles pris en charge. Il est possible de faire pareil avec XMPP et OpenVPN, par exemple.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : David Verbrugge - 20160214_183534.

CentOS 7 : installation vraiment minimale

Il y a deux ans, j'ai écrit un article sur une installation minimaliste de CentOS 7. Celle-ci avait le mérite d'avoir été réalisée rapidement, et d'être assez satisfaisante. Bref, un bon exemple de la loi de Pareto. Toutefois, je n'en étais pas pleinement satisfait, par exemple à cause de paquets de type firmware, qui peuvent être ajoutés avec le temps lors de nouvelles versions de CentOS, mais aussi parce que j'enlevais pas mal de paquets par rapport au groupe nommé Base. J'ai donc décidé de toucher au groupe Core.

Avertissement : ce genre d'exercice ou d'expérience n'est pas à utiliser "en production" tel quel. Le système réellement basique qui en résulte ne contient pas vraiment grand-chose, et il manque ainsi de nombreux outils de diagnostic ou d'administration qui peuvent s'avérer utile en environnement professionnel. Dans le cas d'une reproduction de ces manipulations avec un système RHEL, il faudra très probablement ajouter de nombreux paquets pour gérer l'enregistrement auprès du RHN (ou d'un Satellite), ainsi que des paquets requis par le support de Red Hat.

Je vois donc cet exercice comme une base, me permettant ensuite d'installer les logiciels que j'estime nécessaires pour le besoin de chaque serveur.

Pourquoi ?

Quel est l'intérêt de faire une installation vraiment minimale ? En fait j'en vois plusieurs :

  • tout d'abord, moins de paquets c'est moins de place occupée, même si la place sur nos disques durs augmente avec le temps, il apparaît pertinent dans le cas de machines virtuelles d'occuper le moins de place possible ;
  • ensuite, car cela peut rendre l'installation plus rapide : moins de paquets à installer, moins de temps à les installer ;
  • enfin, car c'est une recommandation ANSSI, de n'installer que le strict nécessaire, afin de limiter la surface d'attaque ; j'en viens d'ailleurs à passer pour un extrémiste auprès de certains lorsque j'annonce que les pages de manuel n'ont rien à faire sur un système de production...

Un autre point à aborder avant de mettre les mains dans le cambouis : jusqu'où aller ? A quel point peut-on dire que cela est réellement une installation minimale, et à quel point le système qui en résulte est utilisable ? Voici mes critères pour cette installation :

  • le système doit pouvoir démarrer, au moins en machine virtuelle, idéalement en machine physique ;
  • le système doit avoir un accès au réseau filaire fonctionnel avec une adresse IPv4 fixe (le DHCP n'est pas nécessaire) ;
  • le système doit pouvoir installer et mettre à jour des paquets ;
  • le partitionnement est réduit au minimum (/boot, / et swap) et utilise le système de fichiers utilisé par défaut (XFS) ;
  • les fonctions suivantes sont disponibles : serveur SSH, client NTP, pare-feu (firewalld) ;
  • le système peut rester en anglais.

Tout le reste peut être retiré. Tout ? Presque, pour éviter de me casser la tête avec un clavier QWERTY, j'ai décidé d'installer le paquet kbd. Mais cela reste une préférence toute personnelle.

Comment ?

Partir d'une installation "manuelle" et retirer des éléments est contre-productif. Pour arriver à l'objectif, il va falloir automatiser l'installation, grâce à kickstart.

Voici donc le fichier que j'utilise pour cela :

# Kickstart file automatically generated by anaconda.

#version=DEVEL
install
text
reboot
firstboot --disabled
lang en_US.UTF-8
keyboard fr-latin9
firewall --enabled
authconfig --enableshadow --passalgo=sha512
selinux --enforcing
services --enabled sshd,chronyd
timezone --utc Europe/Paris

network --onboot yes --device eth0 --mtu=1500 --bootproto static --ip A.B.C.D --netmask 255.255.255.0 --gateway A.B.C.E --nameserver A.B.C.F --activate --hostname pxemachine.anotherhomepage.loc

rootpw centos
user --name=nils --homedir=/home/nils --uid=1001 --gid=1001 --password=centos --groups=wheel

url --url ftp://X.Y.Z.T/pub/centos/7/os/x86_64/
repo --name=updates --baseurl=ftp://X.Y.Z.T/pub/centos/7/updates/x86_64/

bootloader --location=mbr --driveorder=sda --append="crashkernel=auto rhgb quiet"
clearpart --all --initlabel
part /boot --asprimary --size=500
part swap --asprimary --size=1024
part / --asprimary --size=1024 --grow

%packages --excludedocs --instLangs=en --nocore
bash
yum
centos-release
passwd
iputils
iproute
systemd
rootfiles
kbd
openssh-server
-bind-license
-dhclient
-kexec-tools
-e2fsprogs-libs
-e2fsprogs
%end

Comme évoqué plus haut, j'ai utilisé quelques arguments de la directive %packages qui me permet de n'installer que le minimum : ainsi, pas de documentation, on reste en anglais, et le groupe Core saute ! Il m'a donc fallu spécifier volontairement les paquets indispensables, comme le noyau, bash ou encore yum. Pour aller encore plus vite, j'ai choisi d'effectuer l'installation en mode texte (je pourrais être plus brutal et remplacer text par cmdline), mais effectuer celle-ci en mode graphique n'a pas d'incidence sur le nombre de paquets installés.

Malgré tout, il m'a fallu retirer volontairement quelques paquets qui me semblent peu utiles pour le moment : pas besoin de gérer des partitions ext2, 3 ou 4, pas besoin de kexec, ni de dhcp.

Le pare-feu reste activé, ainsi que SELinux : ils s'agit de paramètres par défaut assez sains, je ne vais donc pas recommander de les retirer. A noter malgré tout que le système est utilisable sans ces deux éléments.

Résultat

J'ai pu abaisser l'installation à 193 paquets installés. En poussant plus loin (pas de pare-feu, pas de ssh, pas de NTP, pas de kbd), je peux descendre à environ 170. Ma partition principale est alors utilisée à 466Mo, dont 393Mo dans /usr, et 11Mo dans /etc. Jamais je n'ai installé ou démarré un système CentOS aussi vite. Jamais je n'ai eu un système CentOS aussi austère : pas de vim, pas de less, pas de htop, et c'est limite si je dois me considérer heureux de disposer de grep !

D'un autre côté, pas de fioritures : pas de firmware de matériel non utilisé, pas de system-config-*, ni de NetworkManager. Bon, par contre faut pas rêver, systemd est obligatoire ;)

Et la suite ?

A partir de maintenant il est possible de personnaliser plus en avant son installation, et de n'utiliser des outils non pas parce qu'ils sont présents, mais parce qu'on en a besoin. Je ne sais pas encore quelle suite je pourrais donner à ce billet, qui vaille la peine d'être racontée : il n'est probablement pas intéressant de faire des billets en mode "yum install" pour vim, audit, ou quelque autre logiciel. Une possibilité pourrait être de coller aux recommandations ANSSI, mais il existe déjà plein de guides de sécurité pour Linux, non ?

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : badr yousef - Feather.

Quelques statistiques du blog

Suite au commentaire de Xate dans un récent billet, quelques statistiques sur les billets (blogmas ou pas) sur la première quinzaine de décembre. Pour cela, je me suis servi de mes one-liners en awk décrits ici et .

Les billets les plus vus

Commençons par les billets les plus visités :

root@vhost2:~/tmp# grep "GET /post/" ./access.log | awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' | sort -nr -k 2,2 | head -20
/post/python-3-outils-anaylser-code     1527
/post/make-automatiser-quelques-taches-avec-un-makefile 260
/post/livre-apprendre-a-programmer-avec-python  243
/post/xz-pour-une-meilleure-compression-de-ses-fichiers 224
/post/centos-7-desactiver-firewalld-reactiver-iptables  209
/post/2016/12/29/Vous-naviguez-toujours-sur-un-site-HTTPS       192
/post/livre-introduction-au-langage-c   168
/post/logrotate-exemple-vite-fait       165
/post/paris-open-source-summit-2017-jour-2      161
/post/en-retard 152
/post/paris-open-source-summit-2017     143
/post/centos-7-desactiver-firewalld-reactiver-iptables/ 124
/post/Trouver-des-fichiers-doublons-avec-fdupes 123
/post/raspberry-pi-attention-alimentation       112
/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH  83
/post/2011/10/03/Installation-de-phpMyAdmin-sur-CentOS-6        76
/post/pbulk-aller-plus-loin-sur-les-parametres  72
/post/systemd-reconfigurer-unite-service        71
/post/2017/02/13/clamav-installation-et-scan-antivirus-sur-macos        69
/post/2016/12/29/Vous-naviguez-toujours-sur-un-site-HTTPS&fromurl=redirect.asp  67

Le billet le plus populaire est donc celui sur les outils d'analyse de code Python, et de loin ! Je note que j'ai mal écrit "analyser" dans l'URL, il faudra vraiment que je fasse attention à cela à l'avenir ! Il m'arriver d'ailleurs régulièrement de dépublier puis republier un billet en m'apercevant que l'URL ne me convient pas. J'en profite pour remercier Dashie pour notre conversation sur Mastodon, sans ça je n'aurais pas eu l'idée d'écrire ce billet.

Les tag les plus vus

Quels tags sont les plus populaires ?

root@vhost2:~/tmp# grep "GET /tag/" ./access.log | awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' | sort -nr -k 2,2 | head -20
/tag/NetBSD     73
/tag/Apache     55
/tag/CentOS     50
/tag/PHP        47
/tag/Linux/page/3       46
/tag/Linux      41
/tag/Perl       40
/tag/ssl        38
/tag/blogmas    34
/tag/Awstats    32
/tag/Mac%20OS%20X       31
/tag/RHEL       31
/tag/mp3        29
/tag/pkgsrc     29
/tag/RPM        29
/tag/macOS      28
/tag/Xen        27
/tag/ssh        27
/tag/tls        27
/tag/https      25

Visiblement, je commence à devenir populaire pour NetBSD, Apache, CentOS et PHP ! Dommage que pkgsrc soit un peu bas à mon goût. Le tag blogmas n'est pas non plus super populaire.

Les referers

D'où viennent les visites ?

root@vhost2:~/tmp# grep "GET /post/" ./access.log | awk '{frequencies[$11]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' | sort -nr -k 2,2 | head -20
"-"     5077
"http://www.google.co.uk/url?sa=t&source=web&cd=1"      468
"https://blog.anotherhomepage.org/"     203
"https://www.google.fr/"        196
"https://www.journalduhacker.net/"      193
"http://blog.anotherhomepage.org/"      124
"https://blog.anotherhomepage.org/post/centos-7-desactiver-firewalld-reactiver-iptables/"       66
"http://blog.anotherhomepage.org/post/centos-7-desactiver-firewalld-reactiver-iptables/"        58
"https://blog.anotherhomepage.org/post/centos-7-desactiver-firewalld-reactiver-iptables"        52
"https://blog.anotherhomepage.org/post/python-3-outils-anaylser-code"   45
"https://www.google.com/"       31
"https://blog.anotherhomepage.org/category/Humour"      29
""      28
"https://socialmediascanner.eset.com"   24
"https://blog.anotherhomepage.org/page/2"       22
"https://blog.anotherhomepage.org/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH"        19
"https://www.google.fr" 19
"https://www.journalduhacker.net/s/asxn1a/python_3_outils_pour_analyser_son_code"       16
"https://blog.anotherhomepage.org"      15
"https://blog.anotherhomepage.org/feed/tag/Linux/atom"  15

Pas grand-chose à dire de ce côté, si ce n'est que beaucoup n'ont pas de referer, et en creusant un peu, le lien vers Google UK est utilisé par la même IP, et toutes les visites vont sur le billet sur les outils d'analyse de code Python. J'ai par contre été cité par le Journal du Hacker, ce qui fait bien plaisir !

Des erreurs ?

Quelques trucs étranges :

root@vhost2:~/tmp# awk '{frequencies[$9]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -10
200     48038
301     17578
304     10958
404     834
"-"     716
503     464
302     229
400     143
206     22
403     17

Voyons voir les erreurs 404 :

root@vhost2:~/tmp# grep -w "404" access.log | awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' | sort -nr -k 2,2 | head -10
/post/centos-7-desactiver-firewalld-reactiver-iptables/ 66
/pages/Welcomerobots.txt        64
/wp-login.php   45
/ads.txt        20
/tag/Apachepage/2       12
/pages/Welcomelicense.txt       12
/a2billing/common/javascript/misc.js    11
/post/2017/01/21/macOS-installer-pkgsrc-pour-beneficier-de-plus-de-logiciels    11
/apple-app-site-association     11
/post/  11

Résultat : sans doute des tentatives de bruteforce du blog, pensant qu'il s'agit d'un Wordpress ou d'autre chose. Par contre, il faudra que je regarde plus attentivement les billets à propos de firewalld et de pkgsrc sur macOS.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Bernard Spragg. NZ - Passing Time 2010 ).

CentOS 7 : démarrer Anaconda en PXE

Je voulais, à la base, écrire un billet sur une installation particulière de CentOS 7. J'ai donc voulu utiliser mon "infrastructure de boot PXE" à la maison et commencer à gribouiller un kickstart, mais quand j'ai démarré ma machine virtuelle sur le réseau, le drame :

dracut-initqueue[584]: Warning: Could not boot.
dracut-initqueue[584]: Warning: /dev/root does not exist

Ma configuration pxelinux à ce moment est la suivante :

LABEL centos7amd64
        MENU LABEL Install CentOS 7 x86_64 (interactive)
        KERNEL pub/centos/7/os/x86_64/isolinux/vmlinuz
        APPEND initrd=pub/centos/7/os/x86_64/isolinux/initrd.img ip=dhcp inst.repo=ftp://X.Y.Z.T/pub/centos/7/os/x86_64/ inst.ks=ftp://X.Y.Z.T/pub/ks/c7_x86_64.cfg

Et bien entendu, le même type de configuration fonctionne en CentOS 6.

Ce message d'erreur arrive à des moments et des types d'installation parfois différents, de ce que j'ai lu. Et la résolution n'est pas toujours la même. Dans mon cas, il a fallu que j'ajoute le chemin vers un fichier squashfs, qui doit contenir l'OS minimal pour démarrer Anaconda je crois. Cela donne donc la configuration suivante :

LABEL centos7amd64
        MENU LABEL Install CentOS 7 x86_64 (interactive)
        KERNEL pub/centos/7/os/x86_64/isolinux/vmlinuz
        APPEND initrd=pub/centos/7/os/x86_64/isolinux/initrd.img root=live:ftp://X.Y.Z.T/pub/centos/7/os/x86_64/LiveOS/squashfs.img ip=dhcp inst.repo=ftp://X.Y.Z.T/pub/centos/7/os/x86_64/ inst.ks=ftp://X.Y.Z.T/pub/ks/c7_x86_64.cfg

J'espère que cela rendra service à d'autres !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Mattias - Car Glass 03.

NetBSD : recompilation d'un noyau pour intégrer NPF dans un domU

Dans un billet précédent, j'abordais l'installation d'une machine virtuelle Xen NetBSD en mode paravirtuel. NetBSD, comme Linux, dispose en plus d'un noyau, de modules permettant d'étendre ses fonctionnalités. Ainsi, l'une des briques de pare-feu de NetBSD, NPF, est disponible sous forme de module. Le problème avec ce module, c'est qu'il n'est pas compatible avec un noyau domU. Il est donc nécessaire de recompiler un noyau NetBSD pour en profiter, en incluant le pilote NPF directement dedans plutôt qu'en module.

Récupération des sources

Recompiler un noyau NetBSD est assez facile. D'abord, je récupère les sources, ici celles de NetBSD 7.1 :

nils@shell2:/srv$ export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"
nils@shell2:/srv$ export CVS_RSH="ssh"
nils@shell2:/srv$ cvs checkout -r netbsd-7-1-RELEASE -P src

La documentation officielle le fait dans /usr/src, mais je le fais dans /srv/src, cela ne pose pas de problème.

Si vous souhaitez recompiler un système complet (et pas juste le noyau), il faudra aussi récupérer xsrc, ce que je ne ferai pas ici.

Création d'une configuration noyau personnalisée

Maintenant que les sources sont disponibles, je crée un fichier de configuration pour notre nouveau noyau. Pour cela pas besoin de repartir de zéro, je vais tout simplement copier un fichier existant, et ajouter l'option qui m'intéresse. A noter que les configurations de noyau pour NetBSD sont placées dans les sous-arborescences des différentes architectures. Dans mon cas, mes machines virtuelles sont en x86_64, ce qui correspond à amd64 côté NetBSD :

nils@shell2:/srv$ cd src
nils@shell2:/srv/src$ sys/arch/amd64/conf

Le fichier de configuration du noyau utilisé par défaut est GENERIC, et il en existe aussi un spécialisé pour un invté Xen : XEN3_DOMU. Je vais copier ce dernier au lieu de le modifier pour facilement différencier ma configuration de l'officielle :

nils@shell2:/srv/src/sys/arch/amd64/conf$ cp -vp XEN3_DOMU XEN3_DOMU_NPF

Je peux ensuite éditer mon nouveau fichier, et aller chercher cette ligne :

#pseudo-device  npf                     # NPF packet filter

Il suffit alors de commenter cette ligne, et de sauvegarder le fichier. Passons maintenant à la compilation en elle-même.

Compilation du noyau NetBSD personnalisé

La compilation d'un noyau NetBSD peut se faire de deux manières : manuellement ou via l'aide d'un script nommé build.sh. Ce script est capable, depuis n'importe quel OS compatible, de créer très simplement non seulement un noyau, mais aussi une release complète de NetBSD. Ce script est fourni dans les sources, et se trouve d'ailleurs à la racine.

D'abord, compilons les outils nécessaires :

nils@shell2:/srv/src/sys/arch/amd64/conf$
nils@shell2:/srv/src$ ./build.sh -U -u -m amd64 tools

Autre détail intéressant, et c'est aussi la raison de la présence de l'option -U dans la commande précédente, je n'ai pas besoin d'être root pour ces opérations :) Passons donc à la compilation du noyau à proprement parler :

nils@shell2:/srv/src$ ./build.sh -U -u -m amd64 kernel=XEN3_DOMU_NPF

Selon la puissance de la machine, quelques minutes plus tard un résultat similaire au suivant devrait apparaître :

===> Kernels built from XEN3_DOMU_NPF:
  /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd
===> build.sh ended:      Sun Jun 18 20:29:39 CEST 2017
===> Summary of results:
         build.sh command:    ./build.sh -U -u -m amd64 kernel=XEN3_DOMU_NPF
         build.sh started:    Sun Jun 18 20:29:26 CEST 2017
         NetBSD version:      7.1
         MACHINE:             amd64
         MACHINE_ARCH:        x86_64
         Build platform:      NetBSD 7.1 amd64
         HOST_SH:             /bin/sh
         MAKECONF file:       /etc/mk.conf
         TOOLDIR path:        /srv/src/obj/tooldir.NetBSD-7.1-amd64
         DESTDIR path:        /srv/src/obj/destdir.amd64
         RELEASEDIR path:     /srv/src/obj/releasedir
         Updated makewrapper: /srv/src/obj/tooldir.NetBSD-7.1-amd64/bin/nbmake-amd64
         Building kernel without building new tools
         Building kernel:     XEN3_DOMU_NPF
         Build directory:     /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF
         Kernels built from XEN3_DOMU_NPF:
          /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd
         build.sh ended:      Sun Jun 18 20:29:39 CEST 2017
===> .

Il me suffit donc de copier le fichier /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd sur mon dom0 et de l'utiliser dans un fichier de configuration Xen pour un domU !

Et NPF alors ?

Une fois notre domU démarré à l'aide de ce noyau, il suffit de suivre la documentation de NPF.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : D - 15 photography - GT3 RS.

Propulsé par Dotclear