Catégories
Open-source Planet-libre raspberry Systeme

Mes 5 premières minutes sur un serveur Debian

sam

Sur une idée originale pompée honteusement sur le blog de Bryan Kennedy.

La virtualisation ou la possibilité d’acheter des machines à bas prix comme le Raspberry implique le fait que l’installation de serveurs devient une tâche de plus en plus fréquente. Afin d’éviter les grossières erreurs qui peuvent rapidement devenir fatales si la machine est exposée au réseau Internet, voici les actions que j’effectue systématiquement sur mes systèmes d’exploitations Debian ou Ubuntu Server.

Si vous suivez ce blog, vous savez que je suis un gros fainéant pour ce genre de tâches récurrentes. J’ai donc écrit un ensemble de scripts permettant d’effectuer les actions de « post installation ». J’ai également commencé à regarder du coté des systèmes de gestion de configuration comme Puppet qui sont des solutions à utiliser en priorité si vous avez un parc informatique important.

L’objectif de ce billet est donc pédagogique pour partager avec vous les actions à effectuer et, je l’espère, en apprendre de nouvelles.

Assez de palabres, place au clavier…

1) S’occuper de ses comptes

Je parle bien évidemment ici des comptes utilisateurs qu’il va falloir sécuriser. On commence par le compte root qui ne sera PAS (jamais, c’est mal) utilisé directement pour vous connecter sur votre machine. Lors de l’installation du système, il faut saisir un mot de passe sécurisé, c’est à dire assez long avec un mélange de lettres, de chiffres et d’autres caractères mais sans utiliser des mots connus ou des suites de chiffres. Vous n’avez pas besoin de connaitre ce mot de passe par coeur mais il faudra le conserver bien au chaud.

Une fois logué sur la machine (on durant la phase d’installation du serveur), on commence par créer un utilisateur principal que l’on utilisera pour se connecter à la machine.

J’ai choisi morpheus pour illustrer mon billet.

useradd morpheus
mkdir /home/morpheus

La suite des opérations sera donc faite à partir de cet utilisateur.

2) S’occuper de ses portes d’entrées avec SSHd

SSH est devenu le mode d’accès le plus utilisé pour accéder aux serveurs GNU/Linux. Par défaut, il propose un contrôle d’accès par nom d’utilisateur et mot de passe. J’essaye au maximum d’éviter cette solution. J’utilise le système d’authentification par clé publique qui est un peu plus lourde à mettre en oeuvre et à administrer mais qui offre un niveau de sécurité plus important.

Pour ajouter la clé publique de mon PC avec lequel je vais me connecter au serveur, il suffit de lancer la commande suivante à partir de cette machine:

ssh-copy-id morpheus@monserveur

Puis on force l’utilisation de l’authentification par clé publique et on ferme ensuite cette porte à l’utilisateur root:

sudo vim /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no

Attention: l’authentification par  nom d’utilisateur / mot de passe sera désactivée pour les accès SSH. 

On relance ensuite le daemon SSH:

sudo service  ssh restart

3) Contrôler les entrées avec Fail2ban

Une fois le daemon SSH sécurisé, il faut ensuite ajouter une couche permettant de contrôler plus finement les accès. J’utilise pour cela Fail2ban que j’ai abordé plus précisément dans un précédant billet. Dans notre sujet du jour, je vais configurer Fail2ban pour bloquer, pendant 5 minutes, l’accès à SSH à un utilisateur qui se trompe 3 fois de mot de passe.

On commence par installer fail2ban:

sudo apt-get-install fail2ban

On va ensuite éditer le fichier /etc/fail2ban/jail.conf pour le configurer comme l’on souhaite:

[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3
bantime = 300

On relance ensuite le service pour prendre en compte la configuration:

sudo service fail2ban restart

4) Fermer les fenêtres (de votre Firewall)

Comme nous l’avons vu dans le point précédant, Fail2ban utilise le Firewall IPtable qui part défaut laisse passer l’ensemble des flux. J’applique systématiquement une configuration beoucoup plus restrictive qui autorise les flux SSH entrant (pour l’accès à distance) et HTTP/HTTPs/DNS sortant (pour la mise à jour de mon serveur).

J’utilise pour cela un script de démarrage maison:

sudo wget --no-check-certificate -O /etc/init.d/firewall.sh https://raw.github.com/nicolargo/debianpostinstall/master/firewall.sh
sudo chmod a+x /etc/init.d/firewall.sh

que je lance au démarrage de la machine (et aussi immédiatement):

sudo update-rc.d firewall.sh defaults 20
sudo service firewall start

Il est bien sûr possible d’adapter ce script à vos besoins de flux entrants et sortants en éditant les lignes suivantes:

# Services that the system will offer to the network
TCP_SERVICES="22" # SSH only
UDP_SERVICES=""
# Services the system will use from the network
REMOTE_TCP_SERVICES="80 443" # web browsing
REMOTE_UDP_SERVICES="53" # DNS

5) Prendre soin de ses fondations en tenant son système à jour

Maintenir à jour ses serveurs est une tâche à la fois indispensable et rébarbative. Il y a ici deux écoles possibles. La première est d’utiliser un logiciel comme unattended-upgrades qui va installer automatiquement pour vous les mises à jours de sécurités ou même l’ensemble de votre système. C’est une solution élégante mais qui n’est pas sans risque si un pépin arrive suite à une mise à jour alors que vous êtes loin de vous machines. J’opte donc pour la seconde solution, basée sur cron-apt, qui va me notifier par mail les mises à jours à effectuer sur mes machines.

On installe cron-apt avec la commande:

sudo apt-get install cron-apt

Puis on configure l’adresse mail de destination des messages de notifications dans le fichier /etc/cron-apt/config:

MAILTO="bibi+monserveur@gmail.com"

Note: comme vous pouvez le lire, j’utilise une adresse Gmail bibi@gmail.com pour la réception de mes notifications. J’y ajoute +monserveur (qui sera ignoré par Gmail) afin de pouvoir facilement les filtrer.

On relance le service pour prendre en compte la configuration:

sudo service cron-apt restart

Les notifications seront envoyés par défaut toutes les nuits à 4h du matin.

6) Surveiller le tout avec Logwatch

A ce stade vous avez un serveur disposant d’une sécurité de base qui va le protéger de la grande majorité des attaques que l’on peut trouver sur Internet. Il ne reste plus qu’à installer Logwatch, un outil permettant d’analyser les logs et ainsi de remonter par mail des rapports permettant d’analyser des tentatives d’intrusions éventuelles.

La mise en place est assez simple.

sudo apt-get install logwatch

Puis on configure l’adresse mail de destination des messages de notifications dans le fichier /etc/cron-apt/config:

#execute
/usr/sbin/logwatch --output mail --mailto bibi+monserveur@gmail.com --detail high

On relance le service pour prendre en compte la configuration:

sudo service cron-apt restart

Les notifications seront envoyés par défaut toutes les nuits.

7) Conclusion

Nous arrivons à la fin de ce billet avec une machine à l’épreuve d’une exposition à Internet sans risque de se faire hacker par le premier « script kiddie » venu.

A vous de nous faire partager vos techniques, méthodes que vous appliquez sur vos nouveaux serveurs !

Catégories
Gstreamer Open-source Planet-libre Video Web

Un serveur RTSP basé sur GStreamer

Dans le petit monde du streaming vidéo, RTSP est un protocole permettant à un client (lecteur multimédia) de contrôler un serveur (serveur de streaming) en lui envoyant des ordres simples: lire, pause, stop, déplacement temporel (pour avoir une liste des fonctions théoriquement disponibles, vous pouvez lire la RFC 2326). Il est important, pour comprendre la suite de ce billet que le protocole RTSP ne fait pas lui même le streaming vidéo (il utilise pour cela le protocole RTP). RTSP est juste une couche complémentaire permettant de contrôler ce streaming.

Nous allons dans ce billet étudier un serveur basé sur le framework GStreamer. Maintenu par Wim Taymans, un des développeurs de GStreamer, gst-rtsp se compose d’un ensemble de librairies permettant de concevoir simplement son propre serveur RTSP. Pour effectuer des tests, les développeurs fournissent quelques exemples de serveurs.

Installation de gst-rtsp

On commence par récupérer les sources puis à compiler:

mkdir ~/src

cd ~/src

wget http://gstreamer.freedesktop.org/src/gst-rtsp/gst-rtsp-0.10.8.tar.bz2

bzip2 -d gst-rtsp-0.10.8.tar.bz2

tar xvf gst-rtsp-0.10.8.tar

cd gst-rtsp-0.10.8/

./configure

make

Premier streaming RTSP: la mire

On commence par lancer le serveur de test qui va streamer une mire:

cd examples/

./test-readme

Le serveur est maintenant lancé, en écoute sur le port TCP/8554 et l’URL: rtsp://127.0.0.1:8554/test

Note: si vous lancer le client sur une autre machine il faut bien sur remplacer 127.0.0.1 par l’adresse IP (ou le nom d’hôte) de votre serveur.

Si on regarde le code C de ce premier serveur (./test-readme.c), on peut retrouver la pipeline GStreamer qui va s’occuper de diffuser le flux sur le réseau:

videotestsrc is-live=1 ! x264enc ! rtph264pay name=pay0 pt=96

On a donc la génération de la mire avec videotestsrc, puis un encodage H.264 avec x264enc puis enfant un streaming RTP avec rtph264pay.

Pour lire se genre de flux, on peut utiliser plusieurs logiciels. Le plus « populaire » est le très frenchie VLC. On lance donc le logiciel puis on va dans le menu Média / Ouvrir un flux réseau, puis on entre l’URL: rtsp://127.0.0.1:8554/test

Après quelques secondes, la vidéo devrait s’afficher:

On peut aussi utiliser FFplay (le player basée sur FFmpeg):

ffmplay rtsp://127.0.0.1:8554/test

Ou bien directement une pipeline GStreamer, ce qui ouvre la porte à des post traitements:

gst-launch -v rtspsrc location=rtsp://127.0.0.1:8554/test ! queue ! decodebin ! ffmpegcolorspace ! autovideosink

Il est bien sur possible de lancer plusieurs clients vers la même source RTSP (j’ai testé 3 clients en parallèle).

Une mire c’est bien, un fichier MPEG-4 c’est mieux

Les esprits chagrins vont me dire que pour tester les fonctions de seekink (déplacement temporel) avec une mire ce n’est pas terrible… Nous allons donc streamer une vidéo MPEG-4 (j’ai utilisé le logiciel Avidemux pour produire une vidéo de 640×360 en MPEG-4 ISO à partir d’une source Big Buck Bunny 720p AVI).

On va lancer le serveur avec les commandes suivantes (toujours dans le sous répertoires examples):

./test-mp4 ~/big_buck_bunny_360p_surround.mp4

Lecture à partir de VLC:

On a alors, pour cette vidéo, un flux réseau entre le serveur et le client variant entre 350 et 550 Kbps. Ceci est normal car la pipeline suivante que l’on peut trouver dans le fichier test-mp4.c ne fait en fait aucun transcodage. Comme la vidéo n’a pas été encodé en CBR (constant bit rate) on se retrouve avec des variations de débits:

filesrc location=%s ! qtdemux name=d d. ! queue ! rtph264pay pt=96 name=pay0 d. ! queue ! rtpmp4apay pt=97 name=pay1

Coté occupation CPU du coté client je suis à environ 25% sur un Core 2 à 1.8 Ghz.

Capture réseau

Pour les plus curieux d’entre vous, voici le résultat d’une capture réseau entre mon serveur RTSP (192.168.29.79) et un client (192.168.29.148).

On peut notamment y voir la négociation RTSP avec la liste des fonctions disponibles sur le serveur (OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET-PARAMETER, TEARDOWN) puis le début du streaming RTP.

Conclusion

Bien qu’en développement, ce projet de serveur RTSP basé sur GStreamer est très stable (je n’ai pas rencontré de plantage lors de mes tests) et facile à intégrer dans un développement en C. Si vous voulez faire mumuse et développer votre propre serveur, je vous conseille la lecture du fichier README qui se trouve dans le sous répertoire docs.

A vos serveurs !

Catégories
Open-source Planet-libre Web

Un serveur Jabber en 5 minutes chronos sous Debian/Ubuntu

Oui je sais c’est un pompage en règle du billet de Cyrille Borne. Mais bon il faut dire que par les temps qui courent c’est une rudement bonne idée que de disposer de son propre serveur Jabber.

Nous allons donc détailler les étapes d’installation et de configuration d’un serveur Prosody dans sa dernière version (0.7) avec un chiffrement SSL entre les clients et le serveur.

Pourquoi Prosody et pas Jabber ? Tout simplement car il est bien plus simple et léger à installer (un peu trop usine à gaz). Et puis le titre du billet aurait été moins vendeur: « Un serveur Jabber en 3h45 chronos… ».

Installation de Prosody

L’installation de Prosody se fait en utilisant les commandes suivantes:

echo « deb http://packages.prosody.im/debian stable main » | sudo tee -a /etc/apt/sources.list

wget http://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add –

sudo aptitude update

sudo aptitude install prosody

Sous Ubuntu 10.04, j’ai du en plus installer à la main la librairie LibLua (pour le SSL):

wget http://prosody.im/downloads/debian/liblua5.1-sec0_0.3.2-2prosody1_i386.deb

sudo dpkg -i liblua5.1-sec0_0.3.2-2prosody1_i386.deb

PS: la librairie LibLua est utilisé pour le chiffrement SSL. Le fichier liblua5.1-sec0_0.3.2-2prosody1_amd64.deb doit être utilisé pour les machines sous AMD 64 bits.

On génère la clés et le certificat SSL:

cd /etc/prosody/certs/

sudo openssl req -new -x509 -days 365 -nodes -out « monbeaudomaine.com.cert » -keyout « monbeaudomaine.com.key »

Configuration de Prosody

Puis on configure en éditant le fichier /etc/prosody/prosody.cfg.lua:

sudo vi /etc/prosody/prosody.cfg.lua

VirtualHost « monbeaudomaine.com »

ssl = {

key = « /etc/prosody/certs/monbeaudomaine.com.key »;

certificate = « /etc/prosody/certs/monbeaudomaine.com.cert »;

}

enabled = true;

On relance Prosody pour prendre en compte la configuration:

sudo /etc/init.d/prosody restart

Si vous avez un Firewall sur votre serveur (ce qui est une bonne idée), il faut penser à ouvrir les ports TCP de Jabber en ajoutant les lignes suivantes dans votre script de configuration iptable (/etc/init.d/iptables.sh dans mon cas):

iptables -A INPUT -p tcp –dport 5222 -j ACCEPT

iptables -A INPUT -p tcp –dport 5269 -j ACCEPT

iptables -A OUTPUT -p tcp –dport 5269 -j ACCEPT

On relance ensuite le Firewall:

sudo /etc/init.d/iptables.sh

Puis on vérifie que les règles existent:

sudo iptables -L | grep xmpp

ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-client

ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-server

ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-server

Création d’un compte utilisateur Jabber dans Prosody

On peut ensuite passer à la création d’un utilisateur Jabber:

sudo prosodyctl adduser monbeauuser@monbeaudomaine.com

Il faut saisir deux fois le même mot de passe…

Configuration d’un client Jabber pour utiliser votre serveur Prosody

Enfin, sur son/ses PC, on configure le client de chat (Pidgin dans mon cas).

Il faut aller dans le menu Comptes > Gérer les comptes puis cliquer sur le bouton Ajouter:

Et hop voili !

Catégories
Blog Open-source Planet-libre Reseau Systeme

Sécuriser son blog WordPress #2

Dans ce deuxième billet, nous allons aborder la pierre angulaire de la sécurisation de votre site/blog: la sécurisation du couple infernal Apache/PHP.

Bien qu’il existe d’autres serveurs Web (par exemple le très rapide NGinx ou le très simple Cherokee), Apache reste, à ce jour, le plus répandu. Un des reproche que l’on peut lui faire est sa lourdeur de configuration. Cette lourdeur et l’utilisation de fonctions pas forcement utiles à votre site peut rapidement entraîner des failles de sécurité. Nous allons donc détailler la sécurisation du serveur Web ainsi que celle du moteur de langage PHP qui est utilisé par WordPress.

Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #2):

Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).

Serveur Web Apache

Sécuriser l’installation par défaut d’Apache2

Apache est développé en tenant compte de la sécurité mais dévoile, dans le header HTTP, son identité (son nom et son numéro de version) à chaque client qui se connecte. Ne pas divulguer ces informations permet d’éviter aux scripts kiddies de connaitre directement les failles connues pour la version d’Apache utilisée et peut compliquer le travail des crackers.

Pour cacher ces informations aux clients HTTP, il suffit d’éditer le fichier /etc/apache2/conf.d/security et d’y ajouter/modifier les variables suivantes:

ServerTokens Prod
ServerSignature Off
TraceEnable On

Module de securité IDS pour Apache

Il existe dans Apache un module optionnel nommé ModSecurity2 qui permet de détecter et de protéger son serveur contre des attaques touchant vos applications Web (notamment les « SQL injections », « cross-site scripting », « path traversal attacks »…).

On commence par l’installation de mod-secure:

sudo aptitude install libapache2-mod-security2

Par défaut, aucune règle n’est appliquée. Il faut donc partir du fichier de configuration qui est donné en exemple:

sudo cp /usr/share/doc/mod-security-common/examples/modsecurity.conf-minimal /etc/apache2/conf.d/mod-security.conf

On édite ensuite le fichier /etc/apache2/conf.d/mod-security.conf:

# Basic configuration options
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Handling of file uploads
# TODO Choose a folder private to Apache.
SecUploadDir /tmp/
SecUploadKeepFiles Off

# Debug log
SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel 0

# Serial audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/apache2/modsec_audit.log

# Maximum request body size we will
# accept for buffering
#SecRequestBodyLimit 131072
SecRequestBodyLimit 8192000

# Store up to 128 KB in memory
SecRequestBodyInMemoryLimit 131072

# Buffer response bodies of up to
# 512 KB in length
SecResponseBodyLimit 524288

# Verify that we’ve correctly processed the request body.
# As a rule of thumb, when failing to process a request body
# you should reject the request (when deployed in blocking mode)
# or log a high-severity alert (when deployed in detection-only mode).
SecRule REQBODY_PROCESSOR_ERROR « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Failed to parse request body.’,severity:2 »

# By default be strict with what we accept in the multipart/form-data
# request body. If the rule below proves to be too strict for your
# environment consider changing it to detection-only. You are encouraged
# _not_ to remove it altogether.
SecRule MULTIPART_STRICT_ERROR « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_SEMICOLON_MISSING}, \
IQ %{MULTIPART_INVALID_QUOTING}' »

# Did we see anything that might be a boundary?
SecRule MULTIPART_UNMATCHED_BOUNDARY « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Multipart parser detected a possible unmatched boundary.' »

On relance ensuite Apache pour prendre en compte le plugin:

sudo /etc/init.d/apache2 restart

Ce module contient un ensemble d’expressions rationnelles dont l’objectif est de bloquer les requêtes jugées dangereuses. Il bloquera une partie des tentatives de piratage. C’est  tout de même une barrière de protection faillible mais qui peut empêcher l’exploitation de certaines failles. Dans tout les cas, cela n’empêche pas le développeur de coder correctement, en prenant en compte la sécurité au moment du développement des sites.

Module anti DOS

Nous allons installer le module Apache mod_evasive qui permet d’atténuer les attaques DOS faite en utilisant le protocole HTTP en bloquant les adresses IP des clients trop gourmand, c’est à dire ceux qui demandent trop rapidement des pages webs.

Contrairement à ce que l’on peut lire sur certains sites, ce module ne protège pas des DDOS, seulement des DOS (lire ici une explication des attaques DOS et DDOS). Autrement dit, il bloque les reqêtes venant d’une adresse IP (DOS).

Si un très grand nombre d’IPs font une seule requête : votre serveur sera saturé et le mod_evasive n’aura pas servi (DDOS). Bloquer les DDOS est très difficile car les requêtes sont difficilement reconnaissables des requêtes autorisées.

On commence par installer le module:

sudo aptitude install libapache2-mod-evasive

On édite le fichier /etc/apache2/conf.d/mod-evasive:

<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
</IfModule>

C’est la configuration par défaut qui va bloquer pendant 10 secondes (DOSBlockingPeriod) les requêtes HTTP venant de l’adresse IP source si une des assertions suivantes est vérifiée:

  • il y a plus de 2 requêtes (DOSPageCount) sur la même page dans un intervalle de 1 seconde (DOSPageInterval)
  • il y a plus de 50 requêtes (DOSSiteCount) sur l’ensemble du site dans un intervalle de 1 seconde (DOSSiteInterval)

On relance ensuite Apache pour prendre en compte le plugin:

sudo /etc/init.d/apache2 restart

Sécurisation du moteur PHP

PHP est un langage interprété, largement utilisé pour générer dynamiquement des pages HTML. C’est le langage utilisé par le moteur de CMS WordPress. La génération des pages de votre blog se faisant directement sur votre serveur, il est important de protéger l’environnement d’exécution des scripts PHP.

Il est donc conseillé d’utiliser suphp. Il est relativement facile à installer et permet d’exécuter vos scripts PHP sous un utilisateur autre que www-data et donc protéger votre système.

Cela permet aussi de servir plusieurs sites internet sur un même serveur. Si un pirate atteint un site, il ne pourra pas toucher aux autres.

Ce module fournit aussi la possibilité de disposer d’un fichier PHP.ini par site web, et offre donc plus de flexibilité que l’installation standard de PHP.

La sécurité a néanmoins un coup: la performance. Attendez vous à des pertes de performances sur vos applications. Dans le cas d’une application codée correctement et d’un serveur non surchargé, cette perte devrait cependant être minime.

Il est également possible de désactiver certaines fonctions sensible de PHP (system, exec…) en éditant le fichier php.ini (voir exemple dans l’étape n°3 de ce billet).

Pour installer  suPhp sur votre serveur je vous conseille la lecture de cet article. (si vous voulez/devez faire cohabiter deux versions de PHP, par exemple la 4 et la 5, vous pouvez également consulter ce billet).

Conclusion (temporaire)

On dispose donc maintenant d’un système et d’un serveur Web sécurisé. Il ne reste plus qu’à attendre la suite de cette série de billets pour s’attaquer à la sécurisation du moteur de blogging WordPress.

Catégories
Blog Open-source Planet-libre Reseau Systeme

Sécuriser son blog WordPress #1

Il n’y a rien de plus rageant que de se faire pirater son blog. En plus de réduire à néant notre amour propre, cela peut avoir, dans le cas d’une indisponibilité prolongée, des impacts non négligeables sur le « saint » référencement dans gOOgle et donc sur le trafic sur votre site (je suis bien placé pour en parler…).

Après avoir détaillé l’installation d’un blog WordPress sur un serveur VPS Gandi Ubuntu Server puis optimiser ce dernier en 12 étapes, nous allons donc aborder des techniques permettant de protéger votre blog WordPress hébergé sur un serveur dédié ou virtuel (mais un bon nombre de ces techniques sont aussi applicables sur n’importe quel site Internet). Il faut garder à l’esprit que cela ne garantira en rien une protection efficace à 100%. Si une personne compétente décide de pirater votre site, il y a de fortes chances qu’elle réussisse. Par contre, ces techniques vous protégeront sûrement d’une grande majorité des attaques lancées via des « script kiddies« .

Cet article va être découpé en plusieurs billets (vous êtes en train de lire le #1):

Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).

Sécurisation du système d’exploitation

C’est la base de votre infrastructure. Ici, pas la place pour des systèmes d’exploitations (OS) de comique. Il faut du lourd, du sûr, du solide, du stable, du libre: c’est-à-dire une distribution GNU/Linux ou BSD.

Pour les serveurs Web, j’utilise FreeBSD ou Ubuntu Server, selon mon humeur. Comme je le répète assez souvent il vaut mieux choisir un système d’exploitation que l’on maîtrise bien. En discutant avec des “experts”, vous aurez autant de sons de cloches que d’OS…

Dans la suite de ce billet, nous travaillerons sur la sécurisation d’un serveur sous Ubuntu Server 10.04 LTS, ces méthodes sont applicables facilement sur une Debian (et toute autre distribution Debian like).

Pense bête lors de l’installation

Lors de la configuration des partitions du disque dur de votre serveur, ne tombez pas dans la facilité en faisant une partition unique qui contiendra le système, les application et vos données sur un même volume logique.

Séparer intelligemment les répertoires de son système permet de cloisonner les données et simplifie la ré-installation d’un système. Au minimum, il est conseillé de séparer au moins les partitions suivantes:

  • / (~ 5 Go)
  • /boot (~ 100 Mo)
  • /var (~ 12 Go)
  • /home (Tout l’espace restant)
  • /var/tmp (Voir plus bas)
  • /tmp (Voir plus bas)

Dans notre cas, l’idée est de ne pas stocker nos sites sur /var/www mais sur /home, qui contient tout l’espace.

Le répertoire /var, dédié principalement aux logs, pourra alors se remplir sans impacter votre arborescence principale sur / ou vos comptes sur /home.

Surveiller l’espace utilisé sur vos partition est important, une partition pleine empêcherait vos logs de s’écrire ou vos sites de fonctionner correctement. Le programme logwatch (décrit plus bas) vous fournit un récapitulatif de l’espace disque utilisé, il est donc utile pour surveiller ce point.

Utilisation de tmpfs

Sous les systèmes GNU/Linux, on a deux dossiers temporaires: /tmp et /var/tmp. Passer ces dossiers “World Writable” (c’est à dire que n’importe quel utilisateur/processus de votre système peut écrire et lire dans ces répertoires) en tmpfs (disque RAM). Il faut que votre serveur dispose d’une quantité de mémoire RAM conséquente car une partie de celle-ci sera utilisée pour stocker les fichiers temporaires.

Pour mettre en place tmpfs sur un système de fichier (/tmp dans cet exemple), éditez le fichier /etc/fstab et ajouter la ligne suivante :

tmpfs        /tmp     tmpfs        defaults,user_xattr          0    0

Je vous conseil de mettre tmpfs en place pour les répertoires /tmp, /var/tmp et /dev/shm. La rêgle pour savoir síl faut le mettre en place est « sur tous les répertoires dont le données sont volatiles ». Ainsi, /var/lock devrait en faire partie, sauf que certains programmes, mal codé, n’apprécient pas que ce dossier soit vidé.

L’idée derrière l’utilisation de la RAM est de rendre ces répertoire très rapides. Le stockage sur RAM limite aussi intrinsèquement leur taille, que le noyau gère automatiquement pour étendre ou diminuer la taille de ces partitions en fonction des besoins du système.

Mise à jour du système

C’est un des principe de base de la sécurité de votre système informatique (malheureusement aussi un des plus rébarbatif):

« Toujours avoir un système et des applications à jour. »

Pour m’aider dans cette lourde tache, j’utilise l’application cron-apt qui permet de vérifier automatiquement si des mises à jours sont disponibles. Si c’est le cas, le logiciel peut envoyer un mail et optionnellement, mettre à jour le système pour vous.

Installation de cron-apt:

sudo aptitude install cron-apt

Il faut ensuite configurer votre adresse mail dans le fichier /etc/cron-apt/config. Par défaut cron-apt s’exécute automatiquement tout les matins à 4h00.

Voici un exemple de mail envoyé:
Pour les machines sous Fedora, il existe une fonction équivalente directement dans Yum (lire ce billet pour plus d’informations).

Tuning de la sécurité

Configurer les paramètres de sécurité réseau par défaut dans le fichier  /etc/sysctl.conf.

Vous pouvez vous inspirer des billets suivants pour effectuer cette configuration:

Protection contre les « forks bombs »

Une attaque par « forks bombs » est de type DOS (Deny Of Service) qui utilise la commande système fork. Pour se protéger de telle attaque et limiter leurs impacts sur le reste du système,  il faut éditer le fichier /etc/security/limits.conf et y ajouter les lignes suivantes (en adaptant « username » à vos besoins):

username soft nproc        300

username hard nproc        350

username soft nice         0

username hard nice         0

username soft priority     5

username hard priority     5

username –    maxlogins    10

Ces limitations empêchent un utilisateur de se logguer plus de 10 fois sur la machine (en SSH notamment), de lancer plus de 350 processus simultanément (empêche les forks-bombs) et met une priorité faible a ses tâches par défaut (haute priorité < 0, normal 0, basse priorité > 0).

Source: http://www.cyberciti.biz/tips/linux-limiting-user-process.html

Firewall

Ne laisser passer que les flux réseaux utiles à l’utilisation de votre serveur par les utilisateurs (HTTP / HTTPs) et l’administration (SSH).

Concernant le protocole SSH, on lit souvent qu’il faut changer le port d’écoute du daemon SSHd (par défaut TCP/22). Mise à part le bloquage de certains scripts automatique, je ne pense pas que cette sécurité soit suffisante. En effet, un simple scan de votre machine avec Nmap permettra de retrouver facilement le port d’écoute.

Une solution plus efficace pour protéger cette porte d’entrée sur le serveur est d’utiliser la technique du “portknockers”. Avant de s’ouvrir, on doit taper à la porte de notre serveur en  envoyant une séquence de requêtes vers des ports prédéfinis. Par exemple avant de ce connecter en SSH sur le port TCP/22, il faudra envoyer “taper à la porte” des ports 2222, 3333 et 4444.

Le programme knockd permet de configurer facilement un “portknockers” sur son serveur Linux: https://help.ubuntu.com/community/PortKnocking

Fail2Ban analyse les logs de votre système et bloque automatiquement les indésirables au niveau du firewall iptables, ce qui est très efficace. Vous pouvez aussi bloquer manuellement des plages d’IPs considérées comme “malfaisantes”, il m’est arrivé de bloquer un pays entier cas de nombreux tentatives de piratage provenaient de ce site, et qu’aucun visiteur en provenance de ce pays ne viennent sur mes sites (bon c’est vrai cela fait un peu censure :)).

A installer à partir des sources:

sudo aptitude install fail2ban

Le fichier de configuration par défaut est /etc/fail2ban/jail.conf. Vous pouvez notamment y configurer les adresses IP à ignorer (par exemple l’adresse IP publique ou le nom d’hôte de votre propre box):

ignoreip = 127.0.0.1 home.mondomaine.com

Et également ajouter ou modifier les prisons (jail) pour des services spécifiques. Par exemple pour le serveur pure-ftpd:

#

# FTP servers

#


[pure-ftpd]

enabled = true

port = ftp,ftp-data,ftps,ftps-data

filter = pure-ftpd

logpath = /var/log/messages

maxretry = 6

Pour aller plus loin dans la configuration de fail2bna, vous pouvez lire ce billet.

Autres idées en vrac

  • instaurer des quota disk stricts par utilisateur (quotatool) : très utile pour éviter de bloquer tous ses sites à cause d’un script mal codé.
  • empecher le reboot par syskey /etc/inittab : intéressant mais peu utile, une personne avec un accès physique à votre serveur peut de toute façon faire à peu prêt tout ce qu’elle veut.
  • utiliser rsyslog pour envoyer les logs sur un serveur distant, sans accès de modification/suppression de logs de préférence : permet d’analyser les actions d’un pirate après détection du piratage (un pirate ne peut pas effacer toutes les traces laissées par les tentatives de piratage infructueuses). Un peu cher à mettre en place pour un site perso.

Les commentaires sont ouverts pour nous faire partager votre expérience dans la sécurisation de vos sites Internet.

Sources ayant servies à la rédaction de ce billet:

Catégories
Open-source Planet-libre Systeme

Profiter de sa Dropbox sur son serveur GNU/Linux

Depuis quelques mois, j’utilise le service Dropbox (gratuit jusqu’à 2 Go) pour sauvegarder, partager et synchroniser les fichiers entre mes différentes machines. Souhaitant pouvoir également mon serveur VPS (Ubuntu Server 10.04 LTS) dans ce « cloud » et ainsi permettre la sauvegarde de certains fichiers de mon serveur dans ma Dropbox, il a fallu que je passe outre la limitation du client Dropbox de fonctionner sans un environnement graphique (no-gui…).

Pour tester cette procédure, il faut disposer:

  • d’un compte Dropbox (même un compte gratuit suffit)
  • d’un serveur avec un accès SSH et les droits admin (j’ai validé cette procédure sur un Ubuntu Server 10.04 LTS mais elle doit fonctionner sur d’autre distribution avec quelques adaptations)

Installation du daemon Dropbox

On commence par récupérer le daemon GNU/linux Dropbox sur notre serveur:

cd

wget -O ~/dropbox.tar.gz http://www.dropbox.com/download/?plat=lnx.x86

tar zxvf dropbox.tar.gz

rm -f ~/dropbox.tar.gz

L’archive va être décompressé dans le répertoire ~/.dropbox-dist. Il faut ensuite lancer le programme dropboxd qui va permettre d’associer votre serveur avec votre compte Dropbox.

.dropbox-dist/dropboxd

This client is not linked to any account…

Please visit https://www.dropbox.com/cli_link?host_id=c241bed09af0ae77383c4d89310b08cf to link this machine.

Il faut donc lancer un navigateur Web (depuis votre PC) puis visiter l’URL précédente.

Il se peut que le message suivant s’affiche:

/bin/sh: xdg-open: not found

Il n’a aucun impact sur le bon fonctionnement du daemon dropboxd.

Le programme va ensuite créer votre répertoire ~/Dropbox et y copier le contenu de votre Dropbox (personnellement, j’ai déplacé le répertoire Dropbox vers un disque virtuel attaché à mon VPS puis j’ai créé un lien symbolique entre ce répertoire et mon répertoire ~/Dropbox). Il va également générer un répertoire ~/.dropbox avec un cache et des informations sur votre compte Dropbox.

Une fois terminé, on peut ensuite quitter le programme d’installation avec un CTRL-C.

Automatisation du lancement de Dropbox

On commence par récupérer le script suivant:

http://wiki.dropbox.com/TipsAndTricks/TextBasedLinuxInstall/UbuntuStartup

Ensuite on fait un copier/coller du script dans le fichier /etc/init.d/dropbox . On édite ce fichier et on change la première ligne en mettant la liste des utilisateurs Dropbox sur notre serveur. Par exemple, pour un seul utilisateur nommé nicolargo:

DROPBOX_USERS= »nicolargo »

Puis on change les propriétés du fichier:

sudo chmod a+rx /etc/init.d/dropbox

Et on automatise le lancement:

sudo update-rc.d dropbox defaults

Enfin on essaye une séquence stop / startpour vérifier que le script fonctionne correctement:

/etc/init.d/dropbox stop

Stopping dropbox…

/etc/init.d/dropbox status

dropboxd for USER nicolargo: not running.

/etc/init.d/dropbox stop

Stopping dropbox…

/etc/init.d/dropbox status

dropboxd for USER nicolargo: running (pid 10996)

Test de la Dropbox

Le plus simple est de copier un fichier dans le répertoire ~/Dropbox et de voir si il est bien copié dans votre Dropbox (attendre quelques secondes/minutes selon la taille de votre fichier)…

touch ~/fichiertest.txt

… à l’inverse, si vous supprimé ce fichier de votre Dropbox, il devrait également être supprimé de votre répertoire ~/Dropbox.

Sur mon serveur VPS Gandi, cela marche du tonnerre 🙂

Aller plus loin avec la ligne de commande

Dropbox propose un script en Python (sous licence libre GPL v3) permettant d’administrer sa Dropbox à partir de la ligne de commande cotre serveur. Pour récupérer et installer la dernière version du script, il faut saisir les commandes suivantes:

cd

wget -O dropbox.py http://www.dropbox.com/download?dl=packages/dropbox.py

chmod a+rx dropbox.py

sudo mv dropbox.py /usr/local/bin/

On lance le script sans paramètre pour voir la liste des fonctions disponibles:

/usr/local/bin/dropbox.py

Dropbox command-line interface

commands:

status       get current status of the dropboxd

help         provide help

puburl       get public url of a file in your dropbox

filestatus   get current sync status of one or more files

ls           list directory contents with current sync status

Les plus intéressantes:

dropbox.py status: affiche ce que le daemon Dropbox est en train de faire (exemple: « Downloading 62 files (630.8 KB/sec, 1 hr left) »).

dropbox.py  puburl ~/Dropbox/Public/conky-faenza-nicolargo.tar.gz: affiche l’URL publique de votre fichier.

Maintenir le bouzin à jour

Rien de bien compliqué, une fois la configuration faite, elle restera en mémoire même en cas de mise à jour. La séquence de commande suivante devrait faire l’affaire:

sudo /etc/init.d/dropbox stop

cd

wget -O ~/dropbox.tar.gz http://www.dropbox.com/download/?plat=lnx.x86

tar zxvf dropbox.tar.gz

rm -f ~/dropbox.tar.gz

sudo /etc/init.d/dropbox start

wget -O dropbox.py http://www.dropbox.com/download?dl=packages/dropbox.py

chmod a+rx dropbox.py

sudo mv dropbox.py /usr/local/bin/

Des remarques, questions ? Les commentaires sont là pour ça !

Sources utilisées pour la rédaction de ce billet:

Catégories
Blog Open-source Web

Installation d’un blog WordPress sur un VPS Gandi

Comme vous le savez, je me suis fait hacké mon site pendant les « grandes vacances ». Cette petite contrariété m’a fait faire dans l’urgence une chose que j’avais planifier depuis un certain moment: la migration du Blog de Nicolargo sur un serveur privé virtuel de Gandi.

Nous allons donc voir dans ce billet comment installer, sécuriser et optimiser une blog WordPress sur une serveur privé virtuel !

Catégories
Hardware Open-source

Installation Ubuntu Serveur 10.04 sur HP Proliant DL160 G6

Voici le bloc note de l’installation de la dernière version d’Ubuntu « Server » (Lucid 10.04) sur un HP Proliant DL160 G6.

En route…

Catégories
Gstreamer Open-source Video Web

Configuration pas à pas d’un serveur de streaming Flumotion

Flumotion est un projet de serveur de streaming vidéo open-source distribué sous licence GPL. Développé en Python et basé sur les frameworks Twisted et GStreamer, il permet de diffuser sur un réseau des vidéos venant de sources lives (caméra, tv…) ou stockées dans des fichiers (on parle alors de VoD pour Video à la demande) en proposant un interface utilisateur de type Web (vous pouvez voir une démo ici).

Catégories
Open-source Reseau Systeme

Installation d’un serveur NTP sous Ubuntu

Si vous disposez de plusieurs machines sur votre réseau, il peut, dans certains cas être intéressant de les synchroniser sur une date et une heure commune (par exemple pour de l’analyse de fichiers de log). Les systèmes d’exploitation modernes utilisent maintenant le protocole NTP pour se synchroniser via le réseau IP.

C’est quoi donc NTP ?

Le principe général est simple: on configure le client NTP pour aller demander à un serveur NTP l’heure de référence à quelques millisecondes (ou dizaines de millisecondes) près. En fait la résolution théorique est de 233 ps, mais en pratique la précision est limité par la variabilité des latences réseau. Le client peut alors modifier sa date système en concéquence. Cette description simpliste est à nuancer par le fait que le protocole NTP est basé sur une architecture en arbre.

Par exemple, sur un système d’exploitation GNU/Linux de type Debian ou Ubuntu, il suffit de saisir la commande suivante pour faire appel à un serveur NTP secondaire (ntp.ubuntu.com définie dans le fichier /etc/default/ntpdate):

[shell]

sudo ntpdate-debian

15 Mar 10:11:01 ntpdate[5406]: adjust time server 91.189.94.4 offset 0.038837 sec

[/shell]

Nous allons voir maintenant comment installer un serveur de temps NTP sur votre réseau qui pourra continuer de servir de référence même en cas de coupure de votre liaison Internet.