[HOW-TO] Sécuriser son serveur web

09-06-2012, 23h07

Merci beaucoup pour ta contribution ! Wink

InstinctHack · 08-03-2013, 06h04

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*** · 08-03-2013, 09h39

Citation :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 · (Modification du message : 08-03-2013, 14h17 par 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... Smile

Mais keepass n'est jamais trop loin.. Smile

Junky

InstinctHack · 08-03-2013, 15h57

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

FraKtaL · 08-03-2013, 19h45

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.

04-08-2013, 09h56

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

ServerSignature: off et ServerTokens: Prod

Booster2ooo · 04-08-2013, 10h14

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 Smile

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 · 04-08-2013, 10h21

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...

04-08-2013, 10h29

(04-08-2013, 10h14)Booster2ooo a écrit : 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 · 04-08-2013, 15h29

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é Smile

gruik · (Modification du message : 04-08-2013, 16h51 par 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... Wink

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 · 08-08-2013, 22h20

(08-03-2013, 14h10)Junky a écrit : 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,

Identifiant Mot de passe
S’enregistrer \| Mot de passe oublié ? Se rappeler