Tag: serveur dédié | Page 7

Apache : résoudre l’erreur “421 Misdirected Request”

29 March 202207 janvier 2016 by Matt Biscay · Lecture: 2 minutes

Après la mise à jour d’Apache et HTTP/2, il est apparu un nouveau type d’erreur : l’erreur 421 Misdirected Request.

Erreur 421 : erreur de configuration mod_ssl entre Virtual Hosts

Ce type d’erreur arrive lorsque:

HTTP/2 est activé,
les paramètres SSL de plusieurs Virtual Hosts diffèrent du serveur responsable du handshake SSL/TLS.

En analysant le changelog d’Apache 2.4.18, je me suis rendu compte que si les paramètres SSL et notamment la liste des ciphers utilisables ne sont pas équivalentes entre les différents Virtual Hosts, alors l’erreur 421 est déclenchée.

Solution : harmoniser la configuration mod_ssl

La solution est donc toute simple, il suffit de comparer la configuration mod_ssl des Virtual Hosts et l’harmoniser de manière à lisser les différences. Je vous recommande un outil comme Meld pour comparer les différences entre vos fichiers.

Meld est disponible dans les dépôts de base, vous pouvez l’installer sur votre machine de dév avec un simple:

apt-get install meldCode language: JavaScript (javascript)

Le domain sharding ou servir les ressources statiques sur un sous-domaine

Sur le site, cela est dû à la mise en place du domain sharding que j’avais mis en place il y a quelques années pour charger plusieurs fichiers ressources en parallèle et accélérer les temps de chargement.

HTTP/2 promet beaucoup de choses et apparemment le domain sharding serait maintenant devenu inutile. J’attends un peu de voir comment vont évoluer les choses avant de changer toute ma configuration et éditer tous mes liens.

Bash : personnaliser les couleurs de l’invite de commande (prompt) du terminal

29 March 202231 décembre 2015 by Matt Biscay · Lecture: 2 minutes

Bash : réparer les tables MySQL en cas de crash photo

Lorsque l’on jongle avec différents serveurs et plusieurs fenêtres de terminal, il n’est pas toujours évident d’identifier immédiatement sur quelle machine on se trouve.

Pour remédier à ce problème, je vous propose de changer les couleurs de l’invite de commande (prompt) de votre terminal sous linux.

Editer le fichier .bashrc

Nous allons éditer le fichier .bashrc, qui permet d’éditer les préférences utilisateurs pour tout ce qui concerne bash:

nano .bashrcCode language: CSS (css)

Ajout de styles

Et voici quelques styles sympas à ajouter pour tuner votre prompt.

Style Lemon Lime

Ajoutez ceci à votre fichier .bashrc:

export PS1="\[$(tput bold)\]\[$(tput setaf 6)\]\t \[$(tput setaf 2)\][\[$(tput setaf 3)\]\u\[$(tput setaf 1)\]@\[$(tput setaf 3)\]\H \[$(tput setaf 6)\]\w\[$(tput setaf 2)\]]\[$(tput setaf 4)\]\\$ \[$(tput sgr0)\]"Code language: JavaScript (javascript)

C’est mon style préféré, très cocktail d’été. Voilà ce que cela donne:

Style Matrix

Vous pouvez aussi opter pour le style Matrix, tout vert:

export PS1="\[$(tput bold)\]\[$(tput setaf 2)\][\u@\h \W]\\$ \[$(tput sgr0)\]"Code language: JavaScript (javascript)

Style Rainbow

Ou encore pour un arc-en-ciel de couleurs :

export PS1="\[$(tput bold)\]\[$(tput setaf 1)\][\[$(tput setaf 3)\]\u\[$(tput setaf 2)\]@\[$(tput setaf 4)\]\h \[$(tput setaf 5)\]\W\[$(tput setaf 1)\]]\[$(tput setaf 7)\]\\$ \[$(tput sgr0)\]"Code language: JavaScript (javascript)

Personnalisation du prompt

Si vous souhaitez ajoutez des composants à votre prompt, voici quelques mots-clé utiles:

\u le nom de session utilisateur
\h le nom d’hôte jusqu’au premier ‘.’
\H le nom d’hôte complet
\n saut de ligne
\$ affiche le signe $ pour un simple utilisateur ou # pour l’utilisateur root
\\ un backslash “\”

Et voilà, un peu de couleur dans notre terminal !

Serveur dédié : mettre à jour Apache et configurer le mod_h2 pour HTTP/2 photo

Serveur dédié : mettre à jour Apache pour HTTP/2

7 March 202420 décembre 2015 by Matt Biscay · Lecture: 6 minutes

C’est sur toutes les lèvres : 2015 aura vu l’arrivée de PHP7 et de la révision du protocole HTTP qui passe à la version 2, en remplacement du mod_spdy de Google.

Tout cela promet pas mal de gains de performance donc il est très tentant de le vérifier par nous-mêmes.

HTTP/2 : une évolution du protocole HTTP

Avec HTTP/1.1, la vie des développeurs n’était pas simple. L’optimisation d’un site revenait à plusieurs techniques qui tournaient toutes autour de l’idée de minimiser le nombre de requêtes HTTP vers un serveur d’origine.

Un navigateur ne peut ouvrir qu’un nombre limité de connexions TCP simultanées vers une origine et le chargement des ces ressources via chacune de ces connexions est un processus en série : la réponse de chaque ressource doit être retournée avant que la réponse de la ressource suivante ne soit envoyée. C’est ce qu’on appelle le head-of-line blocking.

HTTP/2 promet donc des gains de performance d’environ 30%, sans avoir à gérer ni minification ni concaténation dans le processus de création et déploiement des pages.

Plus besoin (normalement!) d’optimiser les connexions TCP ou les requêtes HTTP avec la création de sprites, le chargement des ressources directement dans le corps des pages, la concaténation ou la création de sous-domaines pour charger les ressources en parallèle (domain sharding) pour contourner les limitations d’HTTP 1.1.

Fail2Ban: protéger Postfix contre les attaques AUTH DoS photo

Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO

24 March 202215 décembre 2015 by Matt Biscay · Lecture: 3 minutes

Aujourd’hui, Jac m’envoie un message pour m’informer que sa redirection email ne fonctionne plus.

Je lance donc un terminal et vérifie les logs de Postfix, qui chargent des dizaines de lignes d’erreurs de ce type:

Dec 15 16:30:33 mail postfix/smtpd[5912]: connect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5912]: lost connection after AUTH from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5912]: disconnect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5908]: connect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5908]: lost connection after AUTH from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5908]: disconnect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]

Comme vous pourvez le constater, ça débite et ça impacte forcément les ressources du système. Voyons donc comment nous pouvons y mettre un terme.

Pré-requis : fail2ban

Nous allons utiliser fail2ban, un compagnon très utile pour surveiller les logs et analyser les comportements néfastes à l’aide d’expressions régulières.

Je vous invite à relire le guide d’installation de fail2ban.

Nouvelle définition dans fail2ban : postfix-auth

Nous ajoutons donc une nouvelle définition, [postfix-auth], dans notre fichier jail.local:

nano /etc/fail2ban/jail.local

On l’ajoute à la fin des déclarations pour les serveurs mails :

[postfix-auth]
enabled     = true
filter      = postfix.auth
action      = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp]
#           sendmail[name=Postfix, dest=you@mail.com]
logpath     = /var/log/mail.logCode language: PHP (php)

Je désactive volontairement l’envoi des notifications, ce serait un comble.

Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP photo

Serveur dédié : optimiser la couche TCP

12 September 202114 décembre 2015 by Matt Biscay · Lecture: 4 minutes

Aujourd’hui, nous allons mettre quelques petites astuces qui permettent d’optimiser un peu le temps de réaction du serveur Apache.

Nous allons commencer par réduire le nombre de connexions TIME_WAIT des sockets TCP et nous verrons ensuite comment optimiser un peu la couche TCP.

Réduire le TIME_WAIT des sockets TCP

De temps à autre, on tombe sur un serveur Apache qui possède des tonnes de connexions TIME_WAIT qui semblent errer dans les limbes. Même si ces connexions ne prennent pas autant de ressources que des connexions ESTABLISHED, il n’est pas vraiment utile de les garder aussi longtemps.

Commençons par faire un petit état des lieux de nos connexions :

netstat -nat | awk '{print $6}' | sort | uniq -c | sort -nCode language: JavaScript (javascript)

Résultat :

      1 established)
      1 Foreign
      2 ESTABLISHED
      3 FIN_WAIT1
     20 LISTEN
    228 TIME_WAIT

Nous avons donc 228 connexions dans les limbes en TIME_WAIT, qui sont totalement inutiles. Voyons donc comment nous pouvons réduire ce nombre.

Vérifiez ces valeurs:

cat /proc/sys/net/ipv4/tcp_fin_timeout
cat /proc/sys/net/ipv4/tcp_tw_recycle
cat /proc/sys/net/ipv4/tcp_tw_reuse

Vous devriez obtenir, respectivement, les valeurs 60 pour le timeout, 0 pour le reyclage et 0 pour la réutilisation.

Nous allons modifier ces valeurs pour réduire le timeout à 30 secondes, et recycler et réutiliser nos connexions :

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuseCode language: JavaScript (javascript)

Pour que les changements soient persistants, il faut ajouter ces valeurs au fichier sysctl.conf.

Serveur dédié : installer PHP7 FPM avec FastCGI photo

Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian

29 March 202208 décembre 2015 by Matt Biscay · Lecture: 4 minutes

Aujourd’hui, on passe de PHP5 à PHP7 en moins de 20 minutes montre en main sur notre serveur dédié qui tourne sous la version stable de Debian.

Pré-requis : les dépôts Dotdeb

Avant toute chose, vous devez avoir les dépôts Dotdeb installés dans votre apt.

On édite donc la liste des dépôts:

nano /etc/apt/sources.listCode language: PHP (php)

puis on y ajoute :

# Dotdeb stable
deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable allCode language: PHP (php)

On installe la clé GPG de Dotdeb:

wget https://www.dotdeb.org/dotdeb.gpg
sudo apt-key add dotdeb.gpgCode language: JavaScript (javascript)

et on met notre liste de paquet à jour :

apt-get update && apt-get upgradeCode language: JavaScript (javascript)

Lorsque vous avez complété cette étape, vous êtes prêt à lancer la mise à jour de PHP.

Installation de PHP7

Je découpe volontairement cette installation en plusieurs sous-étapes, par souci de clarté.

Suppression des paquets PHP5

On commence par supprimer tous les paquets relatifs à PHP5 sur le serveur:

apt-get purge php5-*Code language: JavaScript (javascript)

Résultat:

The following packages will be REMOVED:
libapache2-mod-php5* php-pear* php5* php5-apc* php5-cli* php5-common* php5-curl* php5-dev* php5-fpm* php5-gd* php5-json* php5-mcrypt* php5-mysql* php5-mysqlnd* php5-pecl-http* php5-propro* php5-raphf* php5-ssh2*

On garde cette liste sous le coude en cas de problème.

Installation des paquets PHP7

On installe les paquets PHP7 qui nous sont nécessaires:

apt-get install php7.0 php7.0-fpm php7.0-gd php7.0-mysql php7.0-cli php7.0-common php7.0-curl php7.0-opcache php7.0-jsonCode language: CSS (css)

8 règles d'or pour un bon déploiement de DNSSEC et DANE photo

8 règles d’or pour bien déployer DNSSEC et DANE

29 March 202207 décembre 2015 by Matt Biscay · Lecture: 4 minutes

Vous avez sécurisé votre domaine avec DNSSEC et DANE ? Très bien ! Il a cependant quelques petites choses à garder à l’esprit pour anticiper les difficultés et bien gérer la maintenance.

De la rigueur dans la gestion des enregistrements DS (DNSSEC) et TLSA (DANE)

Les enregistrements au niveau du DNS sont à manipuler avec précaution, ce ne sont pas le genre de choses que l’on peut configurer une bonne fois pour toute. On ne publie pas des enregistrements DS (DNSSEC) et TLSA (DANE) par effet de mode.

Les zones DNSSEC doivent être signées régulièrement et les enregistrements TLSA mis à jour en cas de changement de certificats TLS. Si la maintenance n’est pas assurée correctement, le domaine risque d’être injoignable.

Automatiser la signature de la zone DNS

Vous devez absolument mettre en place un crontab qui signe votre zone DNS automatiquement et vous informe du bon fonctionnement de votre zone.

Mettre à jour les enregistrements TLSA avant la chaine de certificat du serveur

Vous devez absolument mettre à jour les enregistrements TLSA avant de mettre à jour la chaine de certificat du serveur (déploiement de nouvelles clés ou utilisation d’un nouveau certificat TLS issu par une autorité de certification).

Lorsque vous mettez à jour votre certificat, vous devez garder les anciens enregistrements TLSA dans votre fichier de zone et ajouter les nouveaux enregistrements TLSA.

Les anciens et les nouveaux doivent donc coexister, le temps que les enregistrements DNS soient mis à jour, après quelques TTLS (quelques jours seulement).

Par exemple, la key1 est déployée initialement sur le serveur :

_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)

On ajoute la nouvelle clé key2 pendant quelques jours, juste derrière la key1 :

_25._tcp.mail.example.com. IN TLSA 3 0 1 
_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)

Après le déploiement de la key2, on supprime la key1 :

_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)

Serveur dédié : mise en place du protocole DANE

12 September 202102 décembre 2015 by Matt Biscay · Lecture: 6 minutes

Aujourd’hui, je vous montre comment mettre en place le protocole DANE sur votre serveur.

En pré-requis, votre domaine doit:

Cela prend environ 20 minutes à configurer, auxquelles s’ajouteront quelques heures afin que la résolution DNS avec les changements soit complète.

DANE : l’authentification TLS sans autorité de certification

DANE (DNS-based Authentication of Named Entities) est un protocole qui permet aux certificats X.509 – généralement utilisés pour TLS – d’être liés au DNS en s’appuyant sur DNSSEC.

L’IETF a défini DANE dans la RFC 6698 comme un moyen d’authentifier des clients TLS et des serveurs sans passer par une autorité de certification (AC).

Cette démarche s’enregistre dans une logique de sécurisation des accès clients-serveurs pour d’une part sécuriser les requêtes DNS effectuées depuis les postes clients au travers des protocoles/mécanismes DNSSEC et TLS, et d’autre part mieux sécuriser les accès chiffrés des clients vers le serveurs.

Le chiffrement TLS est actuellement basé sur des certificats qui sont délivrés par des Autorités de Certification (AC ou Certificate Authority, CA en anglais).

Or, ces dernières années ont vu un certain nombre d’AC qui ont souffert de sérieux problèmes d’intrusions et de failles de sécurité, ce qui a permis la délivrance de certificats pour des sites très connus à des personnes qui ne détenaient pas ces domaines.

Faire confiance à un large nombre d’Autorités de Certification peut être un problème, étant donné que n’importe laquelle d’entre elles, si elle est compromise, pourrait délivrer un certificat pour n’importe quel nom de domaine.

Le protocole DANE permet à l’administrateur d’un nom de domaine de certifier les clés utilisées dans les clients ou serveurs TLS de ce domaine en les insérant au niveau du DNS.

DANE a donc besoin que les enregistrements DNS soient signés avec DNSSEC pour que son modèle de sécurité fonctionne.

De surcroit, DANE permet à l’adminstrateur du domaine de spécifier quelle autorité de certification est autorisée à délivrer des certificats pour une ressource particulière, ce qui résoud le problème des autorités de certification qui sont capables de délivrer des certificats pour n’importe quel nom de domaine.

Serveur dédié : mise en place du protocole DANE photo 3

Les enregistrements TLSA

DANE utilise des enregistrements TLSA, qui incluent l’empreinte du certificats X.509 qui protège un nom de domaine.

Nous devons tout d’abord générer cet enregistrement TLSA en nous basant sur le certificat installé sur notre serveur. Ensuite, cet enregistrement TLSA sera ajouté à notre zone DNS.

Postfix : résoudre l’erreur SASL “_sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql”

29 March 202205 novembre 2015 by Matt Biscay · Lecture: 1 minute

Il y a quelques mois, j’ai aperçu quelques messages d’erreurs récurrents dans les fichiers logs du serveur de mail Postfix, concernant SASL.

Voici un extrait de ces messages:

Oct 10 11:35:05 mail postfix/smtpd[18553]: sql_select option missing
Oct 10 11:35:05 mail postfix/smtpd[18553]: auxpropfunc error no mechanism available
Oct 10 11:35:05 mail postfix/smtpd[18553]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql

La solution est toute simple – commencez par éditer le fichier de configuration de Postfix:

nano /etc/postfix/main.cf

Puis commentez la ligne qui commence par smtpd_sasl_path. Chez moi, cela donne :

#smtpd_sasl_path = private/authCode language: PHP (php)

Et enfin, il suffit de relancer tous les services relatifs à l’identification SASL ainsi que Postfix :

find /etc/init.d/ | grep courier | while read line; do $line restart; done
service saslauthd restart
service postfix restartCode language: PHP (php)

Et voilà, plus de messages d’erreur dans les logs.

Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine

7 March 202226 octobre 2015 by Matt Biscay · Lecture: 15 minutes

Aujourd’hui, nous allons mettre en place DNSSEC afin d’ajouter une couche de sécurité supplémentaire dans la gestion des DNS de notre domaine.

Principe de fonctionnement du DNS

Le DNS (Domain Name System) est un maillon clé du fonctionnement d’Internet car la quasi-totalité des services en ligne utilisent des noms de domaine à un moment ou à un autre.

Le DNS est organisé sous la forme d’une arborescence inversée, avec une « racine » dont dépendent les différentes « branches ».

Au premier niveau de l’arborescence se trouvent les « Top Level Domains » (TLD) ou domaines de premier niveau, comme les .fr, .com, .net etc.

Au second niveau, nous avons les noms de domaine « classiques » comme « skyminds.net ».

Fonctionnant comme une base de données distribuée sur des millions de machines, le DNS repose sur des interactions entre ces machines permettant d’identifier celle qui est la plus susceptible de pouvoir répondre à la requête d’un internaute.

Serveur dédié : mise en place de DNSSEC pour sécuriser les DNS d'un nom de domaine photo 2

Dans l’exemple ci-dessus, l’utilisateur veut se connecter au site http://www.wikipedia.fr. Il envoie sa requête via son navigateur. Celle-ci est reçue par un serveur dit « résolveur » qui a pour première mission d’identifier la machine sur laquelle est installé le nom de domaine wikipedia.fr.

Le résolveur s’adresse d’abord à la « racine » du DNS, qui lui indique quels sont les serveurs « faisant autorité » (c’est-à-dire compétents) pour .fr puisque le nom de domaine est en .fr.

Dans un second temps, les serveurs du .fr indiquent à leur tour au résolveur que le nom de domaine wikipedia.fr est hébergé sur tel serveur.

Celui-ci est alors en mesure d’indiquer au navigateur l’adresse IP du serveur web hébergeant les contenus du site web www.wikipedia.fr.

Ce schéma se vérifie quel que soit le site web auquel on souhaite accéder.

DNSSEC : authentifier l’origine et l’intégrité des données

DNSSEC, acronyme de Domain Name System Security Extensions, désigne un ensemble défini d’extensions de sécurité du protocole DNS, standardisé par l’IETF dans la RFC 4033.

DNSSEC signe cryptographiquement les enregistrements DNS et met cette signature dans le DNS. Ainsi, un client DNS méfiant peut récupérer la signature et, s’il possède la clé du serveur, vérifier que les données sont correctes.

Cela permet de s’assurer que les données obtenues par résolution DNS proviennent de la zone légitime du nom de domaine (authentification de l’origine des données) et que les données ne sont pas altérées lors du transfert (intégrité des données).

Ces extensions de sécurité font de DNSSEC une composante essentielle des communications Internet qui nécessitent un haut niveau de confiance dans l’infrastructure DNS.

DNSSEC utilise un mécanisme reposant sur une paire de clés ayant des rôles complémentaires. La première clé, privée, crée une signature par chiffrement; alors que la seconde clé, publique, vérifie les signatures par déchiffrement:

Serveur dédié : mise en place de DNSSEC pour sécuriser les DNS d'un nom de domaine photo 4

Contrairement à d’autres protocoles comme SSL/TLS, DNSSEC ne sécurise pas juste un canal de communication mais il protège les données et les enregistrements DNS, de bout en bout. Ainsi, il est efficace même lorsqu’un serveur intermédiaire trahit l’intégrité des données (DNS menteur).

Les attaques par empoisonnement de cache

DNSSEC répond spécifiquement aux attaques par empoisonnement de cache : le résolveur est alors “intoxiqué” pour qu’il considère le serveur « pirate » comme légitime, en lieu et place du serveur d’origine.

Cette opération permet notamment de capter et de détourner les requêtes vers un autre site web sans que les utilisateurs puissent s’en rendre compte : ils risquent alors de confier leurs données personnelles en se croyant sur le site légitime.

Serveur dédié : mise en place de DNSSEC pour sécuriser les DNS d'un nom de domaine photo 3

Le bon fonctionnement du DNS dépend donc de la fiabilité des données transmises à chaque étape. Les extensions de sécurité du DNS cherchent à répondre à cette contrainte en assurant l’intégrité des données transitant sur le réseau, notamment entre résolveurs et serveurs faisant autorité.

Pré-requis avant de configurer DNSSEC

Avant de commencer, voici quelques pré-requis essentiels :

1. votre domaine doit être correctement configuré auprès de votre registrar et hébergeur au niveau DNS,

2. votre serveur possède suffisamment d’entropie pour la génération des clés de sécurité,

3. vous avez fait une copie de sauvegarde : site, base de données, enregistrements DNS, configuration BIND.

Vérifiez que vous êtes bien prêt. Ce tutoriel prend à peu près 30 minutes à réaliser.

Serveur dédié : générer de l'entropie additionnelle avec Haveged photo

Serveur dédié : produire une meilleure réserve d’entropie avec haveged

29 March 202214 octobre 2015 by Matt Biscay · Lecture: 8 minutes

Sur notre serveur dédié, nous avons parfois besoin de générer des nombres aléatoires avec une forte entropie, par exemple lorsque l’on génère une clé SSH, un certificat SSL/TLS ou une clé pour DNSSEC.

Aujourd’hui, je vous propose donc un article un petit peu plus théorique, qui nous permettra d’améliorer la qualité des données aléatoires et l’entropie générale de notre serveur.

On commence donc par la théorie et on enchaîne sur la partie technique.

L’entropie ou le caractère aléatoire sous Linux

Le chiffrement est basé sur deux facteurs principaux : les nombres premiers et les nombres aléatoires.

Sous Linux, les nombres aléatoires sont générés par le pseudo random number generator (PRNG) qui génère des données aléatoires depuis les interruptions matérielles (clavier, souris, accès disque, accès réseau…) et depuis d’autres sources provenant du système d’exploitation.

Serveur dédié : générer de l'entropie additionnelle avec Haveged photo 1

Une interruption matérielle (en anglais Interrupt ReQuest ou IRQ) est une interruption déclenchée par un périphérique d’entrée-sortie d’un microprocesseur ou d’un microcontrôleur.

Ce caractère aléatoire ou aléa, que l’on désigne sous le terme entropie, est utilisé principalement pour le chiffrement comme SSL/TLS mais peut aussi avoir plein d’utilisations pratiques (génération de mots de passe, de clés, de chaînes de caractères aléatoires…).

BASH : lister, bloquer et débloquer des adresses IP avec iptables

29 March 202205 octobre 2015 by Matt Biscay · Lecture: 4 minutes

Sur un serveur dédié, il n’est pas rare d’avoir des adresses IP à bannir pour se débarrasser de visiteurs malveillants, de spammeurs ou de bots qui effectuent des requêtes farfelues visant à perturber le bon fonctionnement des services du serveur.

Heureusement, toutes ces petites contrariétés peuvent être résolues en quelques secondes grâce à un firewall comme iptables.

Ce petit tutoriel vous montre les quelques commandes à retenir pour lister, bannir ou débloquer des adresses IP avec iptables ainsi qu’un petit script bash qui vous permettra d’automatiser la gestion de ces trois fonctions très simplement.

Bannir une IP

Pour bannir une adresse IP avec iptables, il suffit de lancer cette commande:

iptables -I INPUT -s x.x.x.x -j DROPCode language: CSS (css)

L’argument DROP indique que l’adresse IP indiquée (x.x.x.x) n’aura plus accès à la machine.

Lister les IP bloquées

Pour voir la liste des adresses IP bloquées, il suffit de demander à iptables la liste et de ne sélectionner que celles qui sont en DROP:

iptables -L INPUT -v -n | grep DROP

Résultat :

Chain INPUT (policy DROP 23 packets, 4122 bytes)

Débloquer une IP

Pour débloquer une IP, il faut d’abord afficher la liste des IP bannies:

iptables -L INPUT -v -n | grep DROP

Toutes les IP sont classées dans un ordre numéroté, ligne par ligne. Il suffit d’indiquer le numéro de la ligne de la règle à supprimer avec la commande:

iptables -D INPUT numero-de-la-regle

L’argument -D (pour delete) permet de supprimer la règle qui correspond à l’adresse IP que nous souhaitons supprimer. Par exemple, si on veut supprimer la règle 1, il suffit d’indiquer:

iptables -D INPUT 1

Vous aurez remarqué que toutes ces commandes sont bien fastidieuses et leurs syntaxes assez complexes à retenir.

Voyons donc comment créer un script bash qui prendrait en charge toutes ces commandes.

Script Bash pour automatiser la gestion des IP bannies dans iptables

Voici un script bash qui devrait grandement vous simplifier la gestion des IP dans iptables.

Il permet de bloquer, débloquer et lister les adresses IP en toute simplicité.

← Précédent Suivant →