Discussion :

[nasuu]

Bonsoir (bonjour),

Après une longue utilisation de Plesk sans aucun souci, hormis une forte consommation. Je me suis décidé à configure mon serveur LAMP moi même pour mieux connaitre Linux (debian et centos). Je voudrais votre avis afin de me dire si les choix que j'ai effectués sont corrects.

Parfeu (firewall) :
Autorise toutes les données sortantes
Bloc tout les donnés entrant sauf :

• port 80
• ports 22 (uniquement mon IP, celle de mon hébergeur, celle d'un sou domaine (au cas ou mon IP ne serais plus fixe).
• port 21 (idem)
• ports icmp (ping illimité sur les IP de mon hébergeur, mon IP, les autres une fois toutes les 2 secondes maximum)

SSH :
l'identification par password est désactivée, seule l'authentification par clef est autorisée.

Apache :
Création du groupe et utilisateur apache avec des droits limités.
Seuls les modules nécessaires sont activés, fail2ban est configuré pour apache, j'hésite à installer le mod_security d'apache (auriez-vous un avis le concernant ?). Apache est chrooter pour éviter tout souci
J'ai prinicpalement suivis ce tuto : http://www.symantec.com/connect/arti...he-2-step-step

PHP :
Pareil uniquement les modules nécessaires, les applications sont correctement programmés peu de risque d'avoir une injection xss, mysql
J'ai suivis uniquement ce tuto : http://www.symantec.com/connect/arti...-php-step-step

Serveur SQL (mysql) :
Création du groupe et utilisateur de mysql avec des droits limité.
Compte mysql valide uniquement pour le domaine demander, mysql est également chrooter.
J'ai suivi principalement ce tutti : http://www.symantec.com/connect/arti...ysql-step-step

Dossiers TMP :
J'ai créé une partition dédier de 4 gigas, limiter les droits pour exécuter les fichiers au sein de se dossier sachant que la fonction exec(): de PHP est désactivé.
J'ai suivi à la lettre ce tuto : http://www.securecentos.com/basic-security/secure-tmp/ (sauf pour la taille la taille de la partition).

DNS :
Je me sers du serveur DNS d'OVH, je n'utilise donc pas Bind9.

Logiciel de détection :
Chkrootkit, fail2ban, RKhunter.

FTP :
Je ne suis pas encore décidé, mais je pense prendre Proftpd. Au niveau de la configuration, si j'ai bien compris suffit de créer des utilisateurs sans aucun droit. D'ajouter "DefaultRoot ~" a la fin du dossier et il est sécuriser ? Sachant que je bloque l'accès aux autres sur le port 21.

Configuration systeme :
J'ai éditer le fichier "/etc/sysctl.conf" en modifiant les lignes si dessous :
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.tcp_syncookies = 1

Je vous offre 2 jours de recherche et d'essai de configuration sur debian et centos, maintenant avant de le mettre sur le serveur de production j'aimerais l'avis de personne utilisant un ou plusieurs de ses caractéristiques ci-dessus.
De combien évaluer vous la sécurité de ce serveur ou d'une installation spécifique sur une échelle de 1 à 10. Étant novice cette note m'aidera vraiment à améliorer mes compétences et corriger mes erreurs.

Je vous remercie d'avance en espérant que cet article aura aidé quelques autres personnes. N'hésiter pas à laisser vos résultats de recherche on trouvera solution plus rapidement ensemble que seul

[ovh]

2 remarques :

• SSH : change le port par défaut du serveur, car le 22 est LE port utilisé par tous les robots de pénétration.
• FTP : si possible, passe-toi de ce protocole, ou alors uniquement en mode SSL (TLS). Mais si c'est uniquement pour ton usage perso, utilise SFTP (équivalent de FTP mais qui utilise le protocole SSH; les clients graphiques tels que gftp et filezilla le supportent).

Pour l'ICMP, tu peux améliorer encore en limitant le nombre de requêtes avec iptables

[nasuu]

Je vous remercie de votre réponse

SSH
Je vais donc changer le port SSH vers un port avec une valeur plus élevée, je pense un port 20xxx.

Concernant ICPM j'utilise cette règle (sauf pour moi et OVH comme décris à cette adresse http://guides.ovh.com/FireWall) :
/sbin/iptables -A INPUT -i eth0+ -p icmp --icmp-type echo-request -m limit --limit 2/s -j ACCEPT
Je me demande tout de même si cela vaut le coup de laisser activé le ping pour les IP non connu pour cette configuration ?

Concernant SFTP :
Je vais tenter d'en savoir plus

Pourriez vous me donner votre avis svp sur cette configuration tel qu'indiquer offre t'elle une meilleure sécurité que Plesk ou du moins équivalente ou vaut il mieux garder Plesk ?

Edit :
J'ai cherché quelques informations concernant SFTP. Je suis étonné de la simplicité, de plus Filezila reconnais Pagean de Putty. Actuellement je m'y connecte en root mais je pense le faire avec un utilisateur qui ne risque pas de supprimer tout le contenu (on n’est jamais à l'abri d'une erreur). Cela m'évitera d'installe un serveur ftp qui augmente le risque potentiel de faille. Merci beaucoup.

[gangsoleil]

Bonjour,

• Suppression de ftp
• Suppression de toute connexion en root, meme par clef
• Mises a jour de securite de tous les logiciels
• Mises a jour de l'OS idem
• Suppression de tous les packages inutiles a un serveur, car ils peuvent etre source de faille.

A quoi te sert le filtrage partiel ICMP ?

Et sinon, si tu veux plus de securite, tu supprimes debian pour la remplacer par OpenBSD

[ovh]

Exact pour le coup de la connexion root, j'avais zappé, mais bien sûr il faut empêcher toute connexion root directe !

Pour le ping, c'est toujours utile de le laisser, c'est un diagnostic de base pour savoir si ta machine répond ou pas depuis n'importe où (à savoir il existe par exemple le service pingdom bien utile).

[frp31]

Bonjour,

• Suppression de ftp
• Suppression de toute connexion en root, meme par clef
• Mises a jour de securite de tous les logiciels
• Mises a jour de l'OS idem
• Suppression de tous les packages inutiles a un serveur, car ils peuvent etre source de faille.

A quoi te sert le filtrage partiel ICMP ?

Et sinon, si tu veux plus de securite, tu supprimes debian pour la remplacer par OpenBSD

en tant que grand parano, j'irai même à la suppression du compte root, (en cas de besoin par accès physique à la machine tu peux le rétablir) ou le renomer simplement pour qu'il ne s'appelle pas "root". Ainsi même avec le bon password, unhacker se fait jeter parce qu'il connait pas le "nom de login".
(il est préférable pour cette manoeuvre de traffiquer le CD d'install, pour se faciliter la vie)

OpenBSD c'est une très bonne solution mais elle a quand même un défaut, pour l'aide la communauté est pas très francophone. quand au principe c'est l'inverse de linux ou presque, rien n'est difficile, mais tout est long à faire car l'install de base comme son nom l'indique est super-basique, en particulier en terme réseaux et sécurité, puisque seul SSHD est lancé par défaut c'est tout.

checker régulièrement la sécurité,
poser en crontab:
**chkrootkit
**tiger
poser en service
**denisshd

comme ça t"a été indiqué plus haut FTP et telnet sont interdits
etc...

[gangsoleil]

quand au principe c'est l'inverse de linux ou presque, rien n'est difficile, mais tout est long à faire car l'install de base comme son nom l'indique est super-basique, en particulier en terme réseaux et sécurité, puisque seul SSHD est lancé par défaut c'est tout.

Comme cela a ete dit dans un autre thread, tu as deux philosophies :

• Linux, tout est installe, tout est ouvert, tu dois fermer les points un par un pour securiser
• OpenBSD, rien n'est installe, rien n'est ouvert, tu dois ajouter les choses une par une.

L'avantage que j'y vois, c'est que si tu oublies quelque chose, avec Linux tu as une (potentielle) faille de securite, avec OpenBSD ca ne fonctionne juste pas. Le second cas est visible, pas le premier.

[frp31]

Comme cela a ete dit dans un autre thread, tu as deux philosophies :

• Linux, tout est installe, tout est ouvert, tu dois fermer les points un par un pour securiser
• OpenBSD, rien n'est installe, rien n'est ouvert, tu dois ajouter les choses une par une.

L'avantage que j'y vois, c'est que si tu oublies quelque chose, avec Linux tu as une (potentielle) faille de securite, avec OpenBSD ca ne fonctionne juste pas. Le second cas est visible, pas le premier.

absolument très bien résumé.

[ovh]

• Linux, tout est installe, tout est ouvert, tu dois fermer les points un par un pour securiser

C'est pas moins vrai qu'avant ça ? Actuellement, la plupart des distrib n'ouvrent pas tant de ports que ça par défaut, si ?

[nasuu]

Lors d'une installation Linux Debian chez OVH ou Amazon, il me semble que le port SMTP et SSH sont ouverts par défaut.
J'ai remarqué que moins de programmes étaient installés par défaut sur la distribution de Amazon AWS basé sur Centos contrairement de celle d'OVH Centos.
Vous me conseillez d'aller du côté de OpenBSD pour minimiser les risques ? Je ne le connais absolument pas je sais qu'historiquement il existe depuis presque le début de Linux, mais il me semble qu'OVH ne propose uniquement FreeBDS es la même chose ?

Bien que je supprime toutes les applications inutiles, j'avais l'intime conviction qu'en bloquant l'accès à cette application avec Iptable je ne risquerais rien (du moins sauf si la personne exploite une autre application ouverte depuis l'extérieur pour ensuite exploiter celle-ci). Étant donné que seul apache et réellement accessible depuis l'extérieur, je me suis dit qu'il faut donc tout miser sur une bonne configuration et le chroot d’apache pour minimiser les risques. Peut-être que je pense mal ?

Concernant le root :
La suppression du root peut me poser problème, car je n'ai malheureusement pas accès à la machine physiquement. Peut-être devrais-je suivre le conseil de frp31 en renommant simplement root.

Edit :
Concernant ICPM je l'ai laissé pour qu'OVH puisse vérifier que la machine répond et intervenir au cas où. Je l'ai laissé également pour les autres, mais je pense le retirer, car je n'y vois pas d'intérêt.

[frp31]

tu peux utiliser nessus pour tester et verouiller la securité, au fur et à mesure avant de "lancer" ton site/serveur comme OK

[gangsoleil]

Actuellement, la plupart des distrib n'ouvrent pas tant de ports que ça par défaut, si ?

Il est difficile de repondre simplement tellement les distributions ont des installations par defaut differentes (mode serveur, mode developpeur, mode ...).

Mais globalement, la philosophie est bien celle que j'ai resumee au dessus. On trouvera facilement une distrib Linux qui installe Apache sans que l'utilisateur ne soit au courant ou l'ai demande.

Nasuu : Pour resumer les philosophies BSD, grossierement :

• OpenBSD est oriente securite,
• FreeBSD est oriente performance
• NetBSD est oriente portabilite

Encore une fois, je ne dis pas que tu ne peux pas securiser un serveur Linux, je previens juste qu'il ne faut pas oublier d'etape (et le fait de venir poser des questions ici sur le sujet montre bien que c'est ton but).

[nasuu]

En tout cas je te remercie je vais tester Nessus, j'en en avais déjà entendu parler, mais je ne l'ai pas encore utilisé. Il y a bien une chose que je déteste apprendre, c'est la sécurité, car malheureusement je ne sais jamais quand m'arrêter. Heureusement qu'il existe certains outils de validation en tout cas pour Linux. Car lorsque l'on débute ce terme reste abstrait. Mais, bon à force d'essayer on obtient un peu plus d'assurance et cela vient avec le temps malheureusement je suis pressé .
C'est pour cela que j'ai déposé ma question ici même principalement pour comprendre si ma démarche sécuritaire était suffisante ou non.
J'en peu plus de Plesk 9.5 ou 10 avec apc j'obtiens une baisse de moins 92% de performance par rapport environnement chrooter LAMP avec apc ce qui est énorme ! Me reste qu'a résoudre le problème d'envoi de mail avec certaine fonction de PHP qui ne fonctionne pas par exemple date ou un time.

Ce qui amène à ma dernière question, ça vaut vraiment le coup de chrooter apache ? Je sais que cela augmente grandement la sécurité en cas de hack (d'entrée par là), mais du coté de mes scripts, je n'ai pas de doute tout est vérifier de A à Z.
Je veux dire par là si l'on utilise apache sans Chroot risque t'ont réellement quelques choses (si ont le garde constamment à jours)?

edit :
gangsoleil, le souci c'est que OVH ne propose que FreeBsd et je n'ai malheureusement pas envis d'aller par exemple chez Amazon AWS qui sans doute le propose. Mais j'ai lu quelques parts que la version serveur de debian squeeze a que des paquets utile.
Est un mauvais choix vis-à-vis de ce que j'ai apporté comme modification (cité plus haut). Est-ce que c'est suffisant ?

[dahtah]

Bonjour a tous,
Tout d'abord, desole pour les accents, mais j'ai un clavier US, et c'est vraiment la plaie de les gerer.

Il y a bien une chose que je déteste apprendre, c'est la sécurité, car malheureusement je ne sais jamais quand m'arrêter.

Moi c'est ce qui m'interesse en securite, c'est que tu ne t'arretes jamais d'apprendre.

Ce qui amène à ma dernière question, ça vaut vraiment le coup de chrooter apache ? Je sais que cela augmente grandement la sécurité en cas de hack (d'entrée par là), mais du coté de mes scripts, je n'ai pas de doute tout est vérifier de A à Z.
Je veux dire par là si l'on utilise apache sans Chroot risque t'ont réellement quelques choses (si ont le garde constamment à jours)?

Un petit conseil, ne soit jamais 100% sur de ce que tu codes du point de vue securite, ni meme 50%. C'est la premiere etape pour te faire avoir.
Oui, chrooter Apache est plus que necessaire, meme sur un apache a jour. Tu n'es pas a l'abris d'une erreur de config, ou d'une faille dans ton code. Le fait d'etre chroote limitera l'attaquant dans son acces au systeme de fichier. Ca rendra le travail d'elevation de privileges plus difficile. Sans meme aller jusque la, cela empechera l'acces au fichier read-only pout tout le monde.

J'arrive au point ou je voulais en venir. Il a ete mentionne ici les techniques de securisation des services, mais pas du systeme, une fois le serveur compromis.
Concernant les services, je trouve utile de creer un wrapper xinetd autour des services. Cela permet de gerer les acces grace au fichiers hosts.allow et hosts.deny egalement.
Concernant le firewall, je suis contre le fait de laisser toutes les connections sortantes autorisees. Au contraire, il faut toutes les bloquer, sauf les connections TCP prealablement etablies (deja recu un SYN pour TCP, UDP seulement vers des ports connus). Un serveur, sauf certains services au cas pas cas, n'a jamais besoin d'initialiser une connection. Bloquer les connexions sortantes, permet de rendre l'exfiltration de donnees plus difficile, et meme de bloquer certains reverse-shell.
Maintenant concernant le systeme de fichier, tu dois eviter d'avoir des fichiers world-writable (le pire) et si possible world-readable. Un truc que je trouve bien est de changer le umask de certains demons vers 027, ou meme 077.
Maintenant, pour contrer les techniques d'exploitations courantes, tu dois etre sur que X^W, ASLR et ascii armor (sous composantes d'Exec Shield) sont actives (pour une utilisation raisonnable, sans aller trop dans le durcissement PaX et consort...).
Sur centos

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
# Active ASCII Armor. En gros, les shared libs sont mappees vers des zones commencants par 0x00,
# afin d'empecher l'utilisation de telles addresses par des attaques sur les fonctions de types strcpy et consort.
# En effet, strcpy arretes la copy a chaque \0 rencontree. ASCII Armor a pour effet d'empecher le shellcode
# d'utiliser des attaques types Return Oriented Programming (ret2libc pour la plus connue) pour reussir a outrepasser W^X,
# car l'adresse de saut vers la fonction contiendra forcement des \0. Par contre,
# cette technique peut etre contournee en faisant du ROP vers la zone .text (qui est statiquement mappee).
sysctl -w kernel.exec-shield=1

Sur Debian, oublie ASCII Armor a moins d'avoir du courgae, car il faut patcher le noyau.

Pour W^X (nx bit), si ton systeme est 64bits il doit etre active par default. Sur 32 bits, il faut activer PAE dans le bios.
W^X fait en sorte que les zones memoires ne soit pas a la fois accessibles en ecriture et en execution. En effet, par exemple, il n'y a pas de bonne raison que l'on puisse executer du code sur la stack, puisque l'on peut y ecrire en cas de faille. Autre example, il n'est pas normal de pouvoir ecrire dans la zone .text, puisque cela revient a modifier en memoire le programme execute.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
# Active l'ASLR. Cela permet de randomiser les adresses en memoire, afin d'eviter que l'attaquant connaissent ces adresses a l'avance.
# Cela evite que tu puisses connaitre a l'avance l'adresse d'une librairie partagee par exemple (libc), ou ton adresse sur la stack.
# Sur 32 bits, cette protection est assez facilement contournable par brute force des offsets. En 64 bits, c'est vraiment interessant.
sysctl -w kernel.randomize_va_space=1

Autre point si tu peux te permettre de compiler depuis les sources, compiler avec l'option -fstack-protector-all de gcc permet d'ajouter un canari (32 ou 64 bits aleatoires) avant l'adresse de retour de la stack frame. Ainsi si en cas de buffer overflow, l'adresse de retour est ecrase, le canari l'est aussi, et au depilement de la stack frame, le canari n'est plus bon. Le programme arrete ainsi son execution, empechant le shellcode de s'executer. Pro-police re-ordonne egalement les variables a la compilation, afin que les tableaux soient au dessus des variables, pour eviter l'ecrasement des variables lors d'un BO.

Concernant la gestion des logs. Tu dois absolument empecher que tes logs soient supprimes en cas de compromission de ton systeme. Tu peux les envoyers sur un serveur de centralisation, mais rien n'empeche que celui-ci a son tour soit compromis. Ce que tu peux faire, c'est a chaque logrotate, forcer le chiffrement des logs avec une cle publique que tu laisses sur le serveur. Seule ta cle privee peut decrypter les logs. Tu dois aussi faire en sorte que les logs ne puissent etre ecrases, c'est a dire copie a distance, ou copie sur une partition faites RO ensuite.

Tu peux ajouter un HIDS egalement, tel que OSSEC.

Ensuite, comme cela a deja ete precise, pas de connection en tant que root, utilisation de cle, pas de paquet inutiles, ...
Personnellement je trouve que fail2ban n'est pas tres utile, vu que iptables propose la meme solution de maniere native.

Tu as active l'utilisation des syn-cookies, c'est une bonne idee, meme si tres peux de clients le supportent a ma connaissance.

Je suis d'acord avec gangsoleil et frp31 qu'il est beaucoup plus simple de durcir OpenBSD que Linux dans sa config par default. OpenBSD active deja de maniere native la plupart des points presentes (pa trop lourdement j'espere) ici, plus d'autres non evoques (effacement memoire avant malloc, suppression de fichier surs (shred)....)

Il y a encore des millions de choses a dire, et j'ai sans doute ouble plein de chose.

Bon courage en tout cas...