Par définition, un serveur est accédé de manière distante. C’est à dire qu’on doit pouvoir l’administrer sans être physiquement devant. Alors qu’il soit dans un datacenter à l’autre bout du globe ou dans le grenier de la maison, SSH nous permettra de gérer tout ça depuis notre ordinateur de bureau (ou laptop). Si vous louez votre serveur chez un hébergeur, vous l’avez sans doute-reçu avec ssh pré-installé. Cependant, si vous bidouillez au fond de votre garage, il va falloir l’installer vous-même, et qui plus est, il n’est pas inintéressant de peaufiner la config de SSH pour vos propres besoins !

Installer ssh

Pour ce faire, c’est très simple :

sudo apt-get install ssh

Cette commande va installer open-ssh sur votre machine. C’est d’ailleurs la seule commande que vous aurez à exécuter sur cette dernière puisque après ça, vous pourrez laisser le serveur au garage tandis que vous le gérerez confortablement assis à votre bureau !

Pour vous connecter au serveur, il vous faudra connaitre son nom de domaine ou son ip. Celle-ci est certainement fixe si ce dernier est loué aupres d’un hébergeur, en revanche, si vous êtes toujours dans votre garage, il va falloir vous occuper de ça. Sinon à chaque redémarrage de la box, vous ne saurez plus à quelle adresse le joindre. Je ne couvrirai pas cette technique dans le présent article, il existe cependant plusieurs manières de procéder, voir mon article sur l’ip fixe sur Ubuntu (lisez les commentaires, ils apportent des pistes supplémentaires).

Pour voir votre adresse ip, il faut utiliser la commande ifconfig et chercher dans eth0 (représente l’interface ethernet) la ligne qui commence par « inet addr » :

buzut@jarjar:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:14:0b:05:1f:cf  
          inet adr:192.168.0.13  Bcast:192.168.0.255  Masque:255.255.255.0
          adr inet6: fe80::214:bff:fe05:1fcf/64 Scope:Lien
          …

Ici, mon adresse ip est 192.168.0.13, c’est donc une ip locale.

Se connecter

On va maintenant se connecter en ssh à notre serveur depuis une autre machine. Celle-ci doit disposer d’un client ssh. Si vous êtes sous Linux ou Mac OS, je vous invite donc à ouvrir un terminal, si vous êtes sous Windows, regardez du côté de putty. Première connexion :

ssh nom_de_votre_user@ip_du_serveur

C’est tout. Dans mon cas, j’ai créé un compte buzut sur le serveur ayant pour ip 192.168.0.13, je tape donc dans mon terminal ssh buzut@192.168.0.13. Attention, cette adresse ip étant une adresse locale, vous ne pourrez accéder à ce serveur en utilisant cette ip, que lorsque l’ordinateur à partir duquel vous vous connectez est sur le même réseau local que votre serveur (sur la même box ADSL par exemple).

Dans le cas où vous voudriez vous connecter à votre serveur depuis l’extérieur, il faudra utiliser une IP publique. Aucun problème si vous avez votre serveur chez un hébergeur. En revanche, si vous auto-hébergez votre serveur, vous n’avez qu’une seule adresse IPv4 publique (cela n’est pas valable pour l’IPv6) pour une multitude d’appareils connectés sur la box. Votre box/routeur fait donc du NAT et il va falloir procéder à de la redirection de ports pour que le serveur soit joignable depuis l’extérieur.

Configurer SSH

Pour paramétrer SSH, rendez-vous dans son fichier de configuration :

sudo nano /etc/ssh/sshd_config

ssh est à vrai dire assez fonctionnel de base. On va tout de même changer certains points de la configuration. En premier lieu, j’ai pour habitude de changer le port d’écoute – à 22 par défaut pour le protocole ssh. En effet, si vous voulez vous connecter en mobilité, il y a de grandes chances que sur certains réseaux, le port 22 soit bloqué, je le remplace donc par le port 443 – port du https – qui n’a que très peu de chance d’être bloqué.

# What ports, IPs and protocols we listen for
Port 443

Vous pouvez aussi limiter les adresses IP qui auront le droit de se connecter au serveur, mais dans ce cas, il faudra vous connecter toujours du même endroit (ou alors passer par votre proxy ou VPN avec toujours la même IP). Remplacez pour cela « 0.0.0.0″ par l’IP en question et décommenter la ligne en enlevant le dièse.

# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0

Enfin, je vous conseille aussi de désactiver la possibilité de se connecter en tant que root (l’utilisateur qui a tout les droits). Il est préférable de se connecter avec un utilisateur ayant des droits plus restreints et d’utiliser « sudo » lorsque les opérations nécessitent d’être root.

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

LoginGraceTime concerne le temps pendant lequel le serveur ssh attend que l’utilisateur s’authentifie, au delà de ce laps de temps, il va clore la connexion. Vous pouvez spécifier le temps que vous voulez, sachant qu’il est par défaut à 2 minutes (120 secondes).

Vous pouvez aussi spécifier les utilisateurs que vous autorisez à se connecter. Ainsi, tout autre utilisateur sera dans l’impossibilité de se connecter via ssh. Pour se faire, il faut rajouter la directive AllowUsers suivie des noms d’utilisateurs à qui vous souhaitez accorder l’autorisation de se connecter en ssh :

AllowUsers login login2 login3 etc

C’est tout pour la configuration de ssh. Il va maintenant falloir redémarrer le serveur ssh pour que les modifications prennent effet.

sudo restart ssh

Enfin, pour vous connecter à votre serveur depuis un autre ordinateur, n’oubliez pas de préciser le port que vous avez choisi si vous n’avez pas laissé celui par défaut.

ssh login@adresse-ip-du-serveur -p 443

Se passer de mot de passe

Avec les attaques par bruteforce, les mots de passe deviennent de plus en plus faibles, et pour palier à cela, il faut en retenir de plus en plus compliqués. On peut cependant interdire toute connexion par mot de passe ! Comment ? En substituant le mot de passe par un certificat. L’ordinateur à partir duquel vous vous connectez (la machine cliente) génère un certificat, que l’on enregistre sur le serveur. Dès lors, il n’y aura plus de mot de passe à taper !

Pour mettre en place ce système, je vous invite à lire mon article qui traite de la question.

Voilà tout pour ssh ! Facile non ? Dans le prochain épisode, on verra comment installer un serveur web pour pouvoir héberger nos projets !

The post Configuration d’un serveur Linux – SSH appeared first on Buzut.

Partager pour mieux régner ! Le partitionnement est tout simplement LA première étape dans l’installation d’un serveur puisqu’elle doit s’effectuer avant même l’installation du système à proprement parler. Je ne vais pas aborder ici le gestionnaire de partitionnement de Ubuntu ou de Debian – ils sonts assez intuitifs, et c’est encore différent si vous passez par OVH par ex (n’ayant pas d’accès direct au serveur) – mais plutôt de l’architecture logique des partitions.

Pourquoi partitionner ?

Avant tout, pourquoi partitionner ? C’est une très bonne question. On pourrait en effet très bien créer une partition « / » géante, qui prendrait tout l’espace du disque dur, et tout se passerait pour le mieux, en toute simplicité. C’est vrai, sauf que. Sauf que si « / », la racine en d’autres termes, venait à être pleine, il y aurait nécessairement quelques instabilités sur votre système.

Le principe qui repose derrière cette logique consiste à séparer les différentes activités du serveur pour que chacune impacte le moins possible les autres. Il est par exemple très facile pour un attaquant d’écrire dans /tmp, qui contient tous les fichiers temporaires, reçoit par exemple les uploads via les formulaires http etc. Avec la commande cat /dev/zero > grosfichier un attaquant pourrait rapidement remplir votre disque dur. Si /tmp est une partition à part entière, une fois pleine, elle n’empêchera pas le bon fonctionnement du système.

De même un attaquant pourrait tenter de lancer des scripts depuis /tmp. On peut spécifier pour un répertoire donné qu’il soit impossible d’exécuter des programmes depuis celui-ci par exemple. Renseignez-vous sur les différentes options disponibles, notamment nodev, nosuid et noexec via la commande man mount.

Comment partitionner ?

Voilà une question à laquelle je pourrai plus difficilement apporter une réponse. Tout ceci dépend en effet de la manière dont vous comptez utiliser votre serveur, de ce que vous allez installer dessus, et de l’espace disque disponible bien entendu.

Bien qu’avoir différentes partitions paraît inévitable, je ne suis pas pour autant adepte de la multiplicité de ces dernières. Aussi, voici ce que je préconise comme étant le strict minimum. Et c’est aussi ce dont je me contente la plupart du temps.

# Mount Point       Min Size (MB)    
/                   4000             
/home               1000             
/tmp                1000             
/var                2000             
swap                1000

Là où cela devient compliqué, c’est en ce qui concerne la taille de chacune de ces partitions. Si vous avez un serveur qui fait plusieurs TB, vous pouvez être généreux, ça ne coûte pas grand chose. Vous avez ici le minimum qui convient à la plupart des cas. Le swap par exemple, ne sera presque jamais utilisé si vous avez 16GB ou plus de RAM pour une utilisation serveur web. Et dans tous les cas, si un serveur web commence à swaper, il va vite falloir trouver un remède.

Toujours dans le cas d’un serveur web, si par exemple, vous montez un petit dropbox et que vos fichiers sont stockés dans le dossier par défaut du serveur apache /var/www, il sera conseillé d’avoir une partition conséquente pour /var, tandis que home ne sera pas d’une grande utilité et quelques gigas feront donc l’affaire. En ce qui me concerne, sur des serveurs récents, j’attribue 10GB à « / », 4GB de swap (on ne s’en sert pas, mais 4GB, sur des disques modernes, qu’est-ce que c’est ?), et le reste entre /tmp, /home et /var, selon l’utilisation.

Si vous permettez l’upload de gros fichiers et que vous allez avoir beaucoup d’utilisateurs en même temps, je vous conseille d’attribuer pas mal d’espace à /tmp, car c’est là que les fichiers seront stockés en attendant leur upload complet et leur transfert à leur destination finale /var/www/uploads par exemple. Il faudra dans cet exemple-ci attribuer une taille encore plus importante à /var si les uploads sont destinés à y rester. Bref, vous l’avez compris, comme aurait dit Horace – hacker de renom – « il faut de la mesure en toute chose ».

Enfin, histoire de voir un peu ce que contiennent les différents points de montage, je vous conseille de regarder le man hier.

Je vous parlais tout à l’heure de noexec, nodev et nosuid. On peut configurer ces options une fois le système installé via le fichier /etc/fstab. Je vous invite à jeter un œil à man fstab.

# nous avons ici un système avec un raid logiciel
# on peut voit que /tmp ne permet ni l'exécution, 
# n’interprète pas les caractères spéciaux,
# et ne prend pas en compte les bits d'identification des fichiers
cat fstab
# <file system>	<mount point>	<type>	<options>	<dump>	<pass>
/dev/md1	/	ext4	errors=remount-ro,relatime	0	1
/dev/md2	/var	ext4	defaults,relatime	1	2
/dev/md3	/tmp	ext4	defaults,relatime,noexec,nosuid,nodev	1	2
/dev/md6	/home	ext4	defaults,relatime	1	2
/dev/sda5	swap	swap	defaults	0	0
/dev/sdb5	swap	swap	defaults	0	0
proc		/proc	proc	defaults		0	0
sysfs		/sys	sysfs	defaults		0	0
dev		/dev	devtmpfs	rw	0	0

Une grande partie de ce savoir vient d’une Q&A que j’avais initié sur serverfault [en]. N’hésitez pas à y faire un saut. Par ailleurs, je vous invite à aller lire l’article de mon ami MagiCrazy sur GPT et le partitionnement RAID5 en ligne de commande. Et bon partitionnement !

The post Configuration d’un serveur Linux – Le partitionnement appeared first on Buzut.

On le sait tous, le DDoS c’est une plaie ! Il y a en même temps mille et aucune manière de s’en prémunir réellement, et finalement, de la même manière que la meilleur prévention contre le SIDA est l’abstinence, la meilleure prévention contre le DDoS, est de n’être pas connecté au réseau… facile à dire.

On a déjà vu que Fail2Ban apporte quelques solutions contre ce type d’attaque, mais ce n’est pas forcément suffisant. Je vous propose donc ici une configuration de iptables qui tachera de filtrer et de bloquer les DDoS.

#! /bin/bash
 
MAXHIT=30
BURST=40
 
# créé une nouvelle chaine iptables
iptables -N seuil
 
# definir les limites de trafic au delà desquelles on vire les paquets
# vérifie que le paquet entre dans les limites et l'accepte
# puis stocke l'ip dans une table de hash pendant 1mn pour comparaison ultérieure
iptables -A seuilattaque -m hashlimit \
 --hashlimit-name seuil \
 --hashlimit-upto $MAXHIT/minute \
 --hashlimit-mode srcip \
 --hashlimit-burst $BURST \
 --hashlimit-htable-expire 60000 \
-j ACCEPT
 
# si le paquet est hors limite, il est dropé 
iptables -A seuil -j DROP
 
# passer tout le trafic dans le chaine seuil
iptables -A INPUT -p -tcp --dport 80 -j seuil

Il ne vous reste plus ensuite qu’à lancer ce script au démarrage en renseignant son path dans /etc/rc.local. Et n’oubliez pas de le rendre exécutable

The post Filtre anti-DDoS générique appeared first on Buzut.

Chaque navigateur possède son propre champ de type file, ce dernier n’est pratiquement pas modifiable en CSS. C’est fort dommage car d’une part, chaque navigateur possède son propre « design » de ce type de input, ce qui ne permet pas d’avoir une homogénéité entre les navigateurs, et d’autre part, cette impossibilité de le modifier via CSS, ne permet pas d’adapter ce dernier au design de notre site. Notre objectif est donc de palier à cette lacune, nous aurons recourt à CSS (quand même) et à jQuery.

Nous prendrons comme exemple Buzeo. Voici donc notre sélecteur avant opération :

Et le voici après :

Vous l’aurez compris, l’opération consiste donc à substituer cet hideux champ input file par un joli bouton, qui au clic, se chargera d’ouvrir un navigateur de fichiers. Il n’y a à ma connaissance pas d’événement en JavaScript qui permette d’ouvrir un tel navigateur.

Une solution Full CSS

Avant que nous nous lancions dans la solution que je vais présenter ici, sachez qu’il existe une solution full CSS à ce petit problème. Cependant, il se trouve qu’elle n’est pas l’élue de mon cœur car elle présente un inconvénient que vous allez vite comprendre. La solution full CSS, consiste à rendre le input transparent, et à placer un bouton sous lui. Simplissime !! En croyant cliquer sur le bouton, l’internaute clique alors sur votre input et déclenche l’ouverture du navigateur de fichiers. L’inconvénient à cela ? Le input recouvrant le bouton, vous ne pourrez jamais avoir d’effet CSS de type :hover, ou :focus, donc pas de retour visuel au survol de la souris. C’est dommage, d’autant plus si tout le reste de votre site présente cet effet. Ne cherche-t-on pas là justement à procurer une certaine homogénéité à notre site ?

La solution jQuery

Je le disais juste au dessus, il n’existe pas d’événement qui permette de déclencher l’ouverture du navigateur de fichier, mais on peut toujours utiliser la méthode clic() de jQuery pour déclencher un événement. En l’occurrence, nous voulons déclencher un clic sur le input file lorsqu’on capte un clic sur notre bouton.

Le code voulez-vous ?

<div id="upload" class="whiteGlass">
    <h1 class="browse">Sélectionnez des vidéos à charger :</h1>
    <input type="file" name="film" id="file" class="browse" multiple>
    <span id="fileSelectButton" class="browse button black">Sélectionnez des fichiers</span>
    <p class="browse"><strong>Taille maximale :</strong> 2 GB.</p>
    <p class="browse"><strong>Formats supportés :</strong> avi, flv, mp4, m4v, mkv, mov, mpg, mpeg, ogg, ogv, wmv, 3gp, 3g2.</p>
</div>

Nous avons donc notre input file au dessus de notre bouton (oui mes boutons sont ©FULLCSS aussi. Vous trouverez pleins d’infos sur ce genre de petites merveilles à cette adresse [en]). Il va donc s’agir dans un premier temps de faire « disparaître » ce input. Attention toutefois, si je mets disparaître entre guillemets, c’est parce qu’on ne peut pas se permettre de le mettre en display: none;. En effet, pour des raisons de sécurité – la même raison d’ailleurs qui fait qu’on ne peut invoquer directement en JS explorateur de fichier du navigateur – il ne sera pas possible sur certains navigateurs de simuler un clic sur cet élément s’il est en display none.

On le mettra donc en absolut, pour qu’il sorte du flux, une taille ridicule, et un z-index négatif, le tout afin qu’il soit caché derrière notre bouton. Voici mon petit bout de CSS :

#upload .browse input[type='file']{
	position: absolute;
	margin-top: 3px;
	margin-left: 3px;
	height: 1px;
	width: 1px;
	z-index: -5;
}

Enfin, en ce qui concerne l’élément de jQuery, il n’y a rien de sorcier. Il consiste juste à capturer le clic sur le span d’id fileSelectButton et de déclencher un clic sur notre input. Le tout en quelques lignes grâce à jQuery :

$('#upload #fileSelectButton').click(function()
{
	$('#upload input').click();
});

Je ne crois pas avoir besoin d’expliquer ce code là, niveau programmation, c’est pas trop ardu…

The post Customiser le input file appeared first on Buzut.

En dehors de toute notion de copyright, de vol intellectuel etc, lorsqu’on possède un site ou un serveur, dès lors qu’un autre site inclut un de nos médias sur ses pages en ne l’hébergeant pas lui-même, mais en faisant un lien direct vers le média hébergé sur notre serveur, il nous vole de la bande passante ! Alors bien évidemment, cela ne porte pas à conséquence si c’est un petit site perso avec très peu de trafic, mais dès que le site est un peu fréquenté, ça peut vite générer un fort trafic, et les coûts qui vont avec. Bien évidemment, plus le média est gros, plus c’est onéreux… C’est donc pour cela que nous allons aborder une technique pour se prémunir du hotlinking de vidéos.

À médias différents, traitements différents

Avec le HTML5, insérer une vidéo dans ses pages est tout aussi simple que d’insérer une image. Seulement, si un jpeg de quelques dizaines de Ko sauvagement hotlinké ne pèse pas bien lourd sur votre bande passante, il peut en être tout autrement d’une vidéo de plusieurs centaines de Mo.

La technique pour se prémunir du hotlinking au niveau des images est très connue. Au niveau de NGINX — puisque c’est sur ce serveur que nous allons travailler, bien que la technique s’adapte facilement à Apache — il suffit de quelques lignes :

location ~* \.(jpg)$ {
 valid_referers none blocked www.monsite.fr monsite.fr;
 if ($invalid_referer) { return 403; }

Puisque c’est si simple, pourquoi ne pas reproduire exactement la même technique pour les vidéos ? Il suffirait d’ajouter par exemple le mp4 aux extensions à prendre en compte : location ~* \.(jpg|mp4)$.

Je n’en connais pas trop la raison, mais concernant les vidéos, le navigateur n’envoie pas de referer dans l’en-tête HTTP. Donc dans le cas de la règle ci-dessus, deux choix s’offrent à nous :

1. Conserver « none » en tant que referer valide et dans ce cas autoriser toutes les vidéos à être lues, peut importe la page source,
2. Considérer que « none » n’est pas un referer valide et donc refuser de servir toutes les vidéos, même celles provenant de nos propres pages.

Vous en conviendrez, aucune de ces solutions n’est satisfaisante, puisque l’une d’elle est inutile et l’autre tout à fait contre-productive. Il s’agit donc de trouver une parade.

Le cookie en remplacement du referer

Nous n’avons pas de referer qui puisse nous indiquer si l’internaute requiert ce média à partir d’une de nos pages, ou à partir d’un site qui nous aurait « volé » notre contenu. Pour nous permettre de contrôler ceci, nous allons avoir recourt à un cookie !

Tout simplement, lors de la consultation de la page contenant la vidéo, il suffit de créer un cookie et de ne servir la vidéo qu’à la seule condition que ce cookie existe. Le but n’est pas ici d’expliquer comment créer un cookie dans votre langage de programmation de prédilection, si vous avez un trou, pour le php, c’est par ici. Je recommande cependant de mettre une durée de vie assez courte au cookie, de manière à ce qu’un internaute ayant navigué sur votre site ne puisse pas accéder au contenu spolié sur le site d’un concurrent 20mn plus tard par exemple…

Au niveau de NGINX, dans le fichier de conf de votre site, par exemple /etc/nginx/site-enabled/monsite, il va falloir intégrer cette directive :

# si le cookie "monCookieDeVerif" n'existe pas, on retourne une erreur 403
if ($http_cookie !~ "monCookieDeVerif") { return 403; }

Et voilà, encore plus court que la directive concernant le hotlinking d’images ! On pourrait cependant améliorer un petit peu la sécurité en se basant aussi sur le contenu du cookie. Par exemple en mettant dans le contenu le chemin du fichier vidéo à accéder, puis en comparant le contenu du cookie à la variable $uri. Ce n’est qu’une suggestion, et je reste ouvert à toute remarque. Cette sécurité n’est pas imparable, mais elle permettra déjà d’éviter la plupart des désagréments !

The post Anti-hotlinking pour vidéo avec NGINX appeared first on Buzut.

Les proportions sont conservées et dans l’ensemble ça ne défigurera pas votre site, à l’exception des images, qui risquent de paraître d’une bien piètre qualité. Autant s’adapter à cet usage, d’autant plus que de plus en plus de devices (tablettes smartphones et ordinateur) vont adopter des écrans de hautes résolutions.

Voici donc un article (en anglais), qui explore les différente manière de faire un design compatible Retina, sans pour autant pénaliser les écrans « normaux ».

The post Webdesign pour écrans Retina appeared first on Buzut.

• Si les images sont ajoutées dynamiquement, on évite un traitement supplémentaire gourmand en ressource (flou, sépia…)
• On évite de prendre plus de place sur le disque dur avec deux images alors qu’une seule peut suffire
• On évite aussi la consommation de plus de bande passante et un temps de chargement supplémentaire pour le client

Enfin, vous comprenez qu’il n’y a que des avantages à déporter le traitement des images côté client. On pense évidemment à JavaScript pour faire ce boulot. Oui… pourquoi pas… Mais sachez que les filtres de CSS permettent d’en faire autant, le tout dans une extrême simplicité. Pour vous mettre l’eau à la bouche, voici les effets qu’il est possible d’appliquer :

• flou,
• luminosité,
• saturation,
• contraste,
• teinte,
• inversion,
• nuances de gris,
• sépia

Ça ouvre quand même pas mal de possibilités ! Pour en savoir plus, je vous invites à aller jetez un œil à la traduction de l’article de Johnny Simpson sur Développez.com.

The post Insight sur les filtres CSS3 appeared first on Buzut.

Fail2Ban, en deux mots, c’est un petit utilitaire qui permet de configurer le parefeu iptables de Linux à la volée. Vous lui donnez une liste de règles, lesquelles lui permettent de détecter si quelqu’un tente de brutefrcer votre SSH, de vous faire un DoS sur apache etc, et à la volée, Fail2Ban prend les mesures qui s’imposent pour vous prémunir de ces attaques. Plutôt pratique !

Installation

Pour l’installer, c’est très simple :

sudo apt-get install fail2ban

Passons maintenant au plus important, la configuration de l’engin ! Il y a trois endroits où vous allez devoir fouiller :

Les réglages

# le fichier de configuration général
/etc/fail2ban/fail2ban.conf
 
# le fichier relatifs à vos prisons
/etc/fail2ban/jail.conf 
 
# le dossier filer.d qui contient tous les filtres définis dans le jail.conf
/etc/fail2ban/filter.d

Au niveau du fail2ban.conf, il n’y a en réalité pas grand chose à faire. Vous pourrez paramétrer l’endroit où fail2ban doit enregistrer ses logs, la verbosité de ces derniers et modifier les réglages du socket unix. En ce qui me concerne, je ne touche à rien.

Activation des filtres par défaut

Passons à plus intéressant, le jail.conf. Les paramètres que je modifie sont les suivants :

# mettez ici votre adresse ip histoire de ne pas vous blacklister tout seul
# il est possible de mettre plusieurs adresses, il suffit pour cela de les séparer par un espace 
# pour le bantime, je met 900, il est à 600 par défaut
ignoreip = 127.0.0.1/8
bantime  = 900
maxretry = 3
 
[ssh-ddos]
# j'active cette jail pour protéger mon ssh des Ddos
enabled  = true  
port     = ssh
filter   = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 6
 
# si on possède un serveur apache
[apache]
enabled = true
 
[…]
 
[apache-noscript]
 
enabled  = true  
 
[…]
 
[apache-overflows]
 
enabled  = true

Voilà pour les filtres pré-installés. Je n’active rien d’aute étant donné que je n’ai pas de serveur dns, ni de serveur de mail, ni de ftp, mais vous saurez mettre « true » dans les jail qui correspondent à ce qui peuple votre serveur, j’en suis certain !

Ajouts de nouveaux filtres

On va maintenant ajouter quelques jails pour parer des attaques supplémentaires. On va commencer par les dos, ajoutons donc une nouvelle jail dans notre jail.conf :

# pour apache
# Protect against DOS attack
# 360 requests in 2 min > Ban for 10 minutes
[http-get-dos]
 
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/apache2/access.log
maxretry = 360
findtime = 120
action = iptables[name=HTTP, port=http, protocol=tcp]
mail-whois-lines[name=%(__name__)s, dest=%(destemail)s, logpath=%(logpath)s]
bantime = 600
 
# si vous utilisez nginx, il faut mettre le fichier de log adéquat
logpath = /var/log/varnish/access.log

On va maintenant devoir créer le filtre correspondant :

sudo nano /etc/fail2ban/filter.d/http-get-dos.conf
 
# Fail2Ban configuration file
 
#
 
# Author: http://www.go2linux.org
 
#
 
[Definition]
 
# Option: failregex
# Note: This regex will match any GET entry in your logs, so basically all valid and not valid entries are a match.
# You should set up in the jail.conf file, the maxretry and findtime carefully in order to avoid false positives.
failregex = ^<HOST>.*"GET
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
 
ignoreregex =

Pour apache, on va aussi ajouter une règle anti w00tw00t (qui est un robot qui scan à la recherche de failles)

# dans le jail.conf 
 
[apache-w00tw00t]
enabled = true
filter = apache-w00tw00t
action = iptables[name=Apache-w00tw00t,port=80,protocol=tcp]
logpath = /var/log/apache2/access*.log
maxretry = 1

Et bien entendu, la règle correspondante :

sudo nano /etc/fail2ban/filter.d/apache-w00tw00t.conf
 
[Definition]
 
failregex = ^<HOST> -.*"GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).*".*
 
ignoreregex =

En ce qui concerne le filtre wootwoot, il semble qu’on puisse directement renseigner le fichier de log de nginx à la place de celui d’apache dans le cas d’un serveur nginx. Les logs sont assez similaires pour que ça fonctionne sans problème.

Petite config spéciale NGINX :

 [nginx-auth]
 enabled = true
 filter = nginx-auth
 action = iptables-multiport[name=NoAuthFailures, port="http,https"]
 logpath = /var/log/nginx*/*error*.log
 bantime = 600 # 10 minutes
 maxretry = 6
 
 [nginx-login]
 enabled = true
 filter = nginx-login
 action = iptables-multiport[name=NoLoginFailures, port="http,https"]
 logpath = /var/log/nginx*/*access*.log
 bantime = 600 # 10 minutes
 maxretry = 6
 
 [nginx-badbots]
 enabled  = true
 filter = apache-badbots
 action = iptables-multiport[name=BadBots, port="http,https"]
 logpath = /var/log/nginx*/*access*.log
 bantime = 86400 # 1 day
 maxretry = 1
 
 [nginx-noscript]
 enabled = true
 action = iptables-multiport[name=NoScript, port="http,https"]
 filter = nginx-noscript
 logpath = /var/log/nginx*/*access*.log
 maxretry = 6
 bantime  = 86400 # 1 day

Puis créez les fichiers correspondants dans filter.d :

# Noscript filter /etc/fail2ban/filter.d/nginx-noscript.conf:
 #
 # Block IPs trying to execute scripts such as .php, .pl, .exe and other funny scripts.
 #
 # Matches e.g.
 # 192.168.1.1 - - "GET /something.php
 #
 [Definition]
 failregex = ^<HOST> -.*GET.*(\.php|\.asp|\.exe|\.pl|\.cgi|\scgi)
 ignoreregex =
 
 #
 # Auth filter /etc/fail2ban/filter.d/nginx-auth.conf:
 #
 # Blocks IPs that fail to authenticate using basic authentication
 #
 [Definition]
 
 failregex = no user/password was provided for basic authentication.*client: <HOST>
             user .* was not found in.*client: <HOST>
             user .* password mismatch.*client: <HOST>
 
 ignoreregex =
 
 #
 # Login filter /etc/fail2ban/filter.d/nginx-login.conf:
 #
 # Blocks IPs that fail to authenticate using web application's log in page
 #
 # Scan access log for HTTP 200 + POST /sessions => failed log in
 [Definition]
 failregex = ^<HOST> -.*POST /sessions HTTP/1\.." 200
 ignoreregex =

Se protéger des DDoS de Loic

Créer la jail :

[apache-loic]
 
enabled = true
port = http
filter = apache-loic
action = iptables[name=Apache-loic, port=http, protocol=tcp]
# à adapter en fonction de votre config
# je n'ai pas testé avec nginx mais ça devrait marcher sans problème
logpath = /var/log/apache2/access*.log
maxretry = 1
bantime = 3600

Et au niveau du filte, voilà ce qu’on va mettre :

 #
 # Login filter /etc/fail2ban/filter.d/apache-loic.conf:
 #
 # Blocks request containing "U dun goofed" and doesn't contain the "GET" parameter
 #
 [Definition]
 failregex = <HOST>.*\"(U dun goofed)
 ignoreregex =

Erreurs au lancement

Il se peut que vous ayez des erreurs au lancement de fail2ban dans le cas notamment de multiples jails activées. Vous vous en rendrez compte en jetant un œil à vos logs : /var/log/fail2ban.log :

2012-11-18 04:37:35,774 fail2ban.actions.action: ERROR  iptables -n -L INPUT | grep -q fail2ban-ssh returned 100
2012-11-18 04:37:35,774 fail2ban.actions.action: ERROR  Invariant check failed. Trying to restore a sane environment
2012-11-18 04:37:35,783 fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp -m multiport --dports ssh -j fail2ban-ssh

Pour palier à ce problème, il faut ajouter un petit délai entre le chargement des jails (c’est aux alentours de la ligne 140) /usr/bin/fail2ban-client :

def __ping(self):
                return self.__processCmd([["ping"]], False)
 
        def __processCmd(self, cmd, showRet = True):
                beautifier = Beautifier()
                for c in cmd: 
# ajoutez la ligne ci-dessous 
                        time.sleep(0.1)
                        beautifier.setInputCmd(c)

Redémarrez fail2ban service fail2ban restart, retournez voir vos logs, l’erreur ne devrait plus se manifester. Et voilà le travail ! Vos serveurs sont un peu plus en sécurité (ou un peu moins en danger) c’est au choix.

The post Installer et paramétrer Fail2Ban appeared first on Buzut.

Vous en avez peut-être marre de sans arrêt devoir taper un mot de passe pour vous connecter à vos serveurs en ssh. Voir pire, ça vous inquiète de devoir passer en clair un mot de passe dans un script qui à besoin d’une connexion ssh. Mais saviez-vous les amis qu’il est tout à fait possible de se passer de ce mot de passe ? Il suffit pour cela de configurer une reconnaissance du client par clef ssh. C’est à dire que la machine à partir de laquelle vous vous connectez publie une clef (sa signature), laquelle sera enregistrée sur le serveur ssh. Par la suite, le serveur ssh saura reconnaitre ce client, donc si la signature est identique, il ne demandera plus aucun mot de passe. Et tout ceci s’effectue en à peine quelques minutes !

Côté serveur, modification du sshd

La première chose à faire est d’aller effectuer une petite modification dans le fichier de configuration de ssh, le sshd_config. En effet, l’option de connexion sans mot de passe par clef est désactivée par défaut :

sudo nano /etc/ssh/sshd_config
 
# décommenter la ligne ci-dessous
AuthorizedKeysFile      %h/.ssh/authorized_keys

Une fois la ligne dé-commentée et le fichier enregistré, on redémarre le serveur ssh : sudo service ssh restart. Et c’est tout bon du côté de la config du serveur.

Côté client, création et export des clefs ssh

Création de la clef

Là encore, l’opération est très simple et très rapide. On commence par créer une paire de clefs avec la commande ssh-keygen. On ne précisera pas de mot de passe pour protéger les clefs. Cette option est utile afin de vous permettre d’avoir un seul mot de passe pour l’ensemble de vos connexions ssh, au lieu d’un différent par serveur. Néanmoins, ça complique les choses dans un script, et puis vous n’avez cas garder un oeil sur votre laptop ou chiffrer l’ensemble du disque (ça aide en cas de vol – ou de voyage en chine ) De même, je laisse l’emplacement de sauvegarde par défaut (suffit donc d’appuyer sur entrer).

ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/buzut/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/buzut/.ssh/id_rsa.
Your public key has been saved in /home/buzut/.ssh/id_rsa.pub.
The key fingerprint is:
ed:08:92:af:32:79:90:00:27:97:b8:ca:e4:99:91:5e buzut@nibbler
The key's randomart image is:
+--[ RSA 2048]----+
| . .             |
|+ +              |
|.=.              |
|o+ E .   .       |
|*.=.o . S .      |
|.*o  o . o       |
|   o  . . .      |
|  + ..           |
|   +.            |
+-----------------+

Export de la clef

Voici l’ultime et dernière étape avant de pouvoir se connecter sans entrer aucun mot de passe : exporter sur le serveur ssh, notre clef ssh nouvellement créée. Cette étape, triviale, s’effectue avec la commande ssh-copy-id user@serverAdress. Il va vous demander le mot de passe (pour la dernière fois). Une fois l’opération effectuée, testez : ssh user@serverAddress, hop vous devriez être connecté sans autre forme de procès, pratique !

Interdire la connexion par mot de passe

Maintenant que nous avons rendu notre système plus pratique, pourquoi ne pas aussi améliorer la sécurité en désactivant la connexion par mot de passe ? Ainsi, il vous sera impossible de vous connecter depuis tout ordinateur dont le certificat n’a pas été enregistré sur le serveur !

Pour ce faire, c’est très simple, décommenter et de mettre à no la directive suivante :

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

The post Connexion SSH automatique appeared first on Buzut.

Les bases de données de wordpress ont l’étonnante faculté de gonfler assez rapidement. Cela est dû notamment au fait que wordpress enregistre le différentes versions de vos articles. Vous pouvez le constater en scrollant en bas de la page d’édition d’un de vos articles, dans la section révisions.

Certains y trouveront un intérêt, d’autres non. En tout cas, si vous n’y voyez aucun intérêt, autant faire subir une cure d’amincissement à cette jolie BDD ! Pour cela, on va commencer par supprimer toutes les révisions déjà présentes dans la base. Rendez vous donc dans l’interpréteur de commande MySQL ou dans phpMyAdmin et tapez la commande suivante :

DELETE FROM wp_posts WHERE post_type = "revision";

Hop, toutes vos révisions ont été effacées ! Dans mon cas, il y en avait plus d’une centaine !

Enfin, pour ne pas que ça se reproduise, on va ajouter une ligne dans le fichier functions.php de wordpress (il se trouve dans le dossier de votre thème : wp-content/themes/votre-theme) pour dire à wordpress :

• soit qu’on ne veut plus du tout des révisions
• soit qu’on en veut qu’un nombre limité

<?php
//enlève les révisions des articles, permet d'alléger la base de données
//il est possible de mettre un nombre à la place de false pour limiter le nb de revisions
define('WP_POST_REVISIONS', false);
?>

Et voilà le travail ! En prime, vous aurez peut-être gagné un peu en rapidité pour l’affichage de votre blog

The post Alléger la BDD de WordPress appeared first on Buzut.