[HOW-TO] Sécuriser son serveur web

[Gr3ps]

Parce que nous sommes jamais à l’abri d’une quelconque attaque, voici
quelques petites astuces afin d’améliorer la sécurité d’un serveur :


Utilisez de vrais mots de passe

Un bon mot de passe, est un mot de passe respectant un certains nombre de caractéristique que l’on nomme complexité.
Il est important de mixer ces complexités afin que les logiciels type bruteforce/rainbowtables ne puissent décoder ce mot de passe.

Ainsi, un mot de passe de plus de 8 caractères, comprenant à la fois des chiffres, des lettres, et des caractères spéciaux est quasiment inviolable.

Afin de le retenir plus facilement, vous pouvez opter pour une phrase auquel vous changerez certains caractères.

Ex : C3#paSS3#3st#s3cure@

Si le protocole le permet, il est possible d’utiliser des clés partagés (SSH par exemple).


Désactiver l’accès root depuis SSH

De base, un accès SSH autorise l’accès avec le login « root ».

Ce point est critique car le login « root » dispose bien évidemment de tous les droits.

Le moyen le plus simple pour éviter cela, c’est de désactiver l’accès SSH en root, en éditant le fichier /etc/ssh/sshd_config et en remplaçant la ligne :

PermitRootLogin: yes

Par

PermitRootLogin: no

Un redemarrage du service ssh est alors de rigueur :

/etc/init.d/ssh restart

Changer le port SSH par défaut

Par default, le service SSH écoute sur le port 22.
C’est en general le port le plus attaqué par les scanner, car il permet un accès directe à la machine.
Le fait de changer le port d’écoute, et de fermer le port 22 vous évitera donc pas mal de risques.

Toujours dans le même fichier /etc/ssh/sshd_config, changer le numéro de port par défaut (22) par un autre :

Port 12345

Attention toutefois de ne pas utiliser un port déjà pris par un autre service (serveur web sur le 80 ou smtp sur le 25).
Le plus pratique pour ne pas se tromper est de prendre un port superieur à 10000

Un redemarrage du service ssh est alors de rigueur :

/etc/init.d/ssh restart

Blacklister les IP malsaines

Des outils existent permettant de blacklister les ips tentant du forcing sur vos authentifications.

Fail2Ban par exemple fait ca très bien et est très simple à utiliser :

Pour l’installation :

Apt-get install fail2ban

Les fichiers de configuration se trouvent dans le répertoire /etc/fail2ban/

- Fail2ban.conf
Défini la criticité et l’emplacement des logs.

- Jail.conf
Défini les differents services à surveiller, les ips à ignorer, les actions à entreprendre en cas de detection (mailing, log).


Interdire l’execution depuis /tmp

Le repertoire /tmp est par default accessible à tous.
Aussi, si un utilisateur arrive à bypasser vos authentification (ou à uploader via un script corrompu), il aura tout le loisir de déposer et d’executer des fichiers dans ce fameu dossier /tmp.

L’astuce consiste donc à rendre ce dossier non exécutable.
Les fichiers pourront alors y être déposés, supprimés, modifiés, mais en aucun cas exécutés.

Pour cela, un simple ajout de l’attribut « noexec » dans votre fichier /etc/fstab :

/dev/sda3 /tmp ext3 noexec,nosuid 0 2

Attention toutefois, l’outil d’ajout de packet “apt” a parfois besoin d’un accès en exécution dans ce répertoire.
Il convient donc d’agir avec prudence sur cette manipulation.


Vérifier régulièrement la présence de rootkits

Un rootkit (en français : « outil de dissimulation d’activité ») est un type de programme (ou d’ensemble de programmes ou d’objets exécutables) dont le but est d’obtenir et de maintenir un accès frauduleux (ou non autorisé) aux ressources d’une machine , de la manière la plus furtive possible.

(source : http://fr.wikipedia.org/wiki/Rootkit)

L’utilitaire « chkrootkit » permet de détecter un grand nombre de ces indésirables, et ce très simplement en scannant la machine.

Installation :

apt-get install chkrootkit

Utilisation :

chkrootkit

On peut alors créé une tache cron qui lancera la détection automatiquement toutes les nuits et enverra un rapport par email :

0 3 * * * chkrootkit 2>&1 | mail votre@email.com -s « Rapport de chkrootkit »

Restriction des accès via iptables

Une des manières de sécuriser un serveur, est aussi de restreindre son utilisation qu’à un périmètre bien défini.

Ainsi, il n’est peut etre pas utile d’ouvrir l’accès SSH à tous le monde, mais uniquement à son adresse IP
(Idem pour les consoles d’administration de type webmin)

Ex :

Pour une machine d’admin ayant l’ip 192.168.0.2 et le serveur en 192.168.0.1

Chain INPUT (policy ACCEPT 1449K packets, 314M bytes)
pkts bytes target prot opt in out source destination
5 276 ACCEPT tcp — * * 192.168.0.2/32 192.168.0.1/32 tcp dpt:22

Ainsi de suite pour tous les autres services n’ayant pas besoin d’un accès par tous.

[...:: BliNK ::...]

Merci beaucoup pour ta contribution !

[InstinctHack]

Je relis ce tuto et bien que je soit pas un expert de AS, je pense que le truc qui cloche dans ton tuto, c'est le password :>
8 caractère me semble un peu faible, le bruce-force ça va vite (bien que là, ça soit en réseau), je dirais plûtot 12 moi désormais. après si on utilise un soft (dont j'ai le nom sur le bout de la langue) qui blacklist l'ip au bout de 3 tentatives, c'est bon pour 8 je dirais, mais le parano...

[supersnail]

après si on utilise un soft (dont j'ai le nom sur le bout de la langue) qui blacklist l'ip au bout de 3 tentatives

Fail2ban ? :3

[Junky]

bonjour.

Un tit trick pour générer des mots de passes:

Code :

</dev/urandom tr -dc ICI LES ENSEMBLES | head -cN

ce qui donne par exemple avec un mot de passe de 30 caratères:

Code :

echo $(</dev/urandom tr -dc _a-zA-Z0-9\;\:^\&\" | head -c30)
#stdout:
9RQE;35SYHZ"8WtRANECpwvGBL"B8I

Le echo ici n'est que pour le '\n'
Il est vrai par contre que pour retenir un mot de passe pareil sa relève un peu de l'impossible... Mais keepass n'est jamais trop loin..

Junky

[InstinctHack]

\o/ pwgen révisité \o/
Mais merci quand meme junky

[FraKtaL]

J'ai un truc a rajouter avant de mettre PermitRootLogin: no il faut penser a créer un Utilisateur avec adduser.

Vous pouvez pas savoir le nombre de contract d'infogérance que l'on récupère car "l'informaticien du client" a sécurisé sans avoir au préalable créer un compte user standard.

[0pc0deFR]

Penser aussi à supprimer l'affichage de la version de apache avec dans le fichier apache2.conf:

ServerSignature: off et ServerTokens: Prod

[Booster2ooo]

J'avais aussi lu que désactiver tous les compilers étaient une bonne idée (chmod 000) pour éviter au hax0r de compiler les malware sur le serveur. Je sais pas si c'est très utile, je ne suis jamais qu'un gros noob sur linux

Sinon, modifier le .bash_profile du root pour ajouter une ligne qui vous envoie un email à chaque ouverture de session en root:

Code :

echo 'ALERT - Root Shell Access on:' `date` `who` | mail -s "Alert: Root Access from `who | awk '{print $6}'`" your@email.com

src: http://www.webhostingtalk.com/printthread.php?t=468168

[InstinctHack]

Je suis pas sûr de mon coup, mais normalement si tu réussi à avoir un compte même www-data, l'user peut upload des binaires déjà compilés, donc bon...

[0pc0deFR]

Sinon, modifier le .bash_profile du root pour ajouter une ligne qui vous envoie un email à chaque ouverture de session en root:

Code :

echo 'ALERT - Root Shell Access on:' `date` `who` | mail -s "Alert: Root Access from `who | awk '{print $6}'`" your@email.com

src: http://www.webhostingtalk.com/printthread.php?t=468168

Pour une ouverture de session (donc brute force) c'est utile mais dans le cas d'une escalation de privilège je ne suis pas sûr qu'il y ai une ouverture de session tel quelle.

Et oui, il est possible d'uploader des binaires sur le serveur ne serais-ce qu'avec wget par exemple.

[Polo]

Et le firewall c'est important aussi :B

Perso j'ai rajouté des regles iptables pour bloquer les attaques Dos et entre autre SlowLoris (elles ne sont pas de moi :B ) :

Code :

iptables -N BLACKLIST
iptables -A BLACKLIST -m recent --name BLACKLIST --set -j DROP
iptables -A INPUT -m recent --update --name BLACKLIST --seconds 60 --rttl -j DROP
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --name COUNTER --set
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --name COUNTER --update --seconds 10 --hitcount 10 --rttl -j BLACKLIST
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 100 -j DROP

Le plus simple pour le firewall c'est de tout bloquer par défaut et débloquer les ports un par un ensuite ; un petit bash qui se lance tout seul au démarrage et le tour est joué

[gruik]

bon la totalité de ce thread est quand même assez mal avisé il me semble, la sécurisation d'une machine - fût-elle autre chose qu'un serveur web - s'envisage d'abord globalement avant de s'envisager localement
c'est comme si on dit "qu'est-ce qu'il faut pour organiser un pique-nique ? => prendre sa bagnole", on sent bien qu'il manque quelque chose, une vue d'ensemble...

de fait y'a potentiellement des choses intéressantes ou qui pourraient l'être, mais hors de tout contexte ça perd complétement de son intérêt, quelques lignes iptables ne font pas un firewall, quelques lignes dans le bashrc ne font pas le café non plus, et c'est justement là, à cet endroit précis lorsqu'on est censé envisager la sécurisation d'un ou plusieurs services que "ouin savoir pirater ca permet de savoir mieux se défendre", simplement parce que l'on ne va pas forcément envisager toutes les menaces possibles et imaginables, on va plus ou moins classer les risques et parer au plus pressé, d'autres contraintes telles que les performances de la machine ou la lourdeur des processus sécurité pourront ensuite entrer en ligne de compte également et limiter les actions dans ce sens

plus globalement, on peut envisager pour sécuriser une machine par exemple d'avoir une gestion des droits correcte, et même plus largement un cloisonnement des services les uns par rapport aux autres
ça veut dire par exemple qu'on va faire tourner mysql avec son propre utilisateur, apache aussi, certains scripts de maintenance aussi etc. mais attention, il peut arriver qu'un service ait besoin d'avoir un accès chez l'autre et dans ce cas il faut gérer ça "au mieux"

y'a pas de méthode miracle, des grandes lignes tout au plus, des principes de sécurité (pour le Mr sécurité) et de précaution (pour Mr sysadmin), plus on a une connaissance exhaustive des schémas d'attaques possibles/existants, des failles existantes à un instant T etc. plus on est armé pour réagir vite en cas d'incident, et en amont parer à toute éventualité, le bon sens fait le reste, et le risque 0 n'existe pas

[T1loc]

bonjour.

Un tit trick pour générer des mots de passes:

Code :

</dev/urandom tr -dc ICI LES ENSEMBLES | head -cN

Pourquoi ce compliquer la tâche quand il existe des petits outils toutes aussi sympa :
pwgen


Les mots de passe c'est une bonne chose. Mais la sécurité d'un serveur web ne s'arrête pas là.

Un exemple concret :
- J'ai un serveur X derrière un firewall dernière génération (ici un watchguard)
- Ce serveur est dans une DMZ isolé de l'ensemble du lan.
- Fail2ban est installé et configuré
- l'accès ssh se fait par un port dynamic (+ de 1045) et via un système de ports supplémentaire (udp ou tcp) : knock. Exemple de connexion : $> knock t:11 u:22 t:33 && ssh user@ip -p 1045
- l'accès root est désactivé
- le sudoers est désactivé
- apache tourne avec le mode secure + fastcgi
- crawltrack et crawlprotect sont installés et configuré.

Et malgré ce semblant de sécurité le serveur est exploitable, pourquoi ?
Si je vous répond : CMS + obsolète ?

Je tiens juste à faire remonté que les choix que nous prenons lorsque nous installons, développons un site et/ou un intranet ou tous ce que vous voulez, nous "DEVONS" absolument pensez au futur, à obsolescence, au suivi de cette sécurité.

L'émission de rapport, le développement de script basique (quand je dis basique : un tour sur : abs.traduc.org permet en moins de 10min de faire un script d'analyse des permissions par exemples). Tous ces petits éléments constitue votre sécurité.

Tachez d'ouvrir les yeux, et ne pas vous arrêtez sur ce que vous voyez.


T1loc,