Cher journal,
Je t'écris car depuis quelques temps j'essaie de trouver une solution pour éviter que des script-kiddies "explosent" des applications PHP mal codées.
J'ai remarqué que la plupart du temps, ils modifient du code php existant, ou il rajoute leurs fichiers pour avoir un tracker bittorrent pour partager des films XXX.
Après 5 piratages, j'ai mis en place petit à petit certaines règles, d'après mes expériences et ce que j'ai lu sur le Web.
Je vous les fait partager car cela pourrait également vous servir:
1. Faire tourner Apache avec un user différent par vhost grâce à apache2-mpm-itk (packagé dans Debian), ainsi le pirate ne pourra pas lire les fichiers des autres virtualhosts.
2. Les fichiers PHP appartiennent à un autre utilisateur que celui d'Apache, afin que le pirate ne puisse pas écrire dedans, avec les bons droits.
Apache a le bon groupe pour pouvoir uniquement lire. N'étant que dans le groupe, Apache ne peut pas modifier les droits.
Apache a par contre le droit d'écrire dans le dossier qui contiendra les fichiers uploadés.
Exemple concret: pour le site www.toto.com, apache tourne en tant que toto_apache:toto.
Le site se situe dans /var/www/toto.com, les droits d'accès des fichiers sont:
rw-r----- toto:toto index.php
rw-r----- toto:toto db.php
rwxrwx--- toto:toto files/
3. Pour éviter que le pirate ne puisse exécuter des fichiers PHP dans le dossier où les fichiers sont uploadés, j'ajoute ceci dans le virtualhost:
[Directory /var/www/toto.com/files]
php_admin_flag engine off
AddType text/html .php
AddType text/html .phtml
AddType text/html .php4
AddType text/html .php3
Options -Indexes
Options -ExecCGI
AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .htm .shtml .sh .cgi
[/directory]
4. Desactivation des .htaccess via AllowOverride None: Ainsi, le pirate ne pourra pas modifier la configuration d'Apache
Il faut penser à rapatrier tous les .htaccess dans la configuration du virtualhost
5. Désactiver les informations de version fournies par Apache via ServerTokens et ServerSignature
6. Enlever le shell à toto_apache
7. Utiliser la variable de configuration PHP open_basedir pour éviter que le pirate puisse se promener sur le serveur avec PHP
Exemple: php_admin_value open_basedir "/var/www/toto.com:/tmp:/usr/share/php"
Depuis que j'ai mis tout ceci en place, je suis pour l'instant tranquille.
Et vous, avez-vous d'autres recettes pour sécuriser les applications PHP ? Pensez-vous à d'autres failles ?
Merci pour vos commentaires.
Journal Sécurisation d'applications PHP hébergées sur du LAMP
18
sept.
2009
# D'autres trucs
Posté par inico (site web personnel) . Évalué à 7.
* Utiliser seLinux pour restreindre encore plus le service Web.
[^] # Re: D'autres trucs
Posté par jeffcom . Évalué à 8.
- dans php.ini, positionner les directives :
--- expose_php = off
--- register_globals = off
--- magic_quotes_gpc = on
--- display_errors = off [1]
--- allow_url_fopen = off
- ne pas mettre le safe_mode à on, c'est une fausse sécurité
- désactiver certaines fonctions si on en a pas besoin (peut être fait via le vhost) soit : disable_functions = proc_open , popen, disk_free_space, diskfreespace, set_time_limit, leak, tmpfile, exec, system, shell_exec, passthru
après on peut compliquer :
- modifier les scripts pour scanner la variable globale $_REQUEST pour y dénicher les injections à l'aide regexps avant tout traîtement ou les passer par mysql_real_escape_string
- modifier les applis pour ne permettre qu'un certain nombre de tentatives de login par minutes (à la fail2ban)
- éventuellement utiliser le safemode pour mysql, mais normalement pas de soucis de ce coté si le reste est ok
- chrooter apache...
- ne pas héberger de site web... là pour le coup tu risques plus rien :)
[1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant) qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine, ou le régler via le vhost pour obtenir le même effet
[^] # Re: D'autres trucs
Posté par Bruno (site web personnel) . Évalué à 4.
--- magic_quotes_gpc = on
Pas sûr que mettre magic_quotes_gpc à on soit une bonne solution : la plupart des applis php existantes blindent déjà les échappements des requêtes, et activer le magic_quotes_gpc introduira des effets de bord importants. Cette option est d'ailleurs obsolète depuis php 5.3.
Coté parades, il y a aussi l'installation de mod_security. Il faut en revanche passer un certain temps à posteriori pour supprimer les règles un peu trop extrêmes...
[^] # Re: D'autres trucs
Posté par Victor STINNER (site web personnel) . Évalué à 5.
C'est surtout une grosse blague qui n'empêche sûrement pas les injections SQL (on peut injecter du SQL sans apostrophe ou guillemet si la requête SQL est mal écrite), mais emmerde surtout les développeurs.
PHP a enfin décidé de supprimer cette vieille blague (magic_quotes) dans PHP6. Voir la décision et les raisons :
http://www.php.net/~derick/meeting-notes.html#magic-quotes
Quelques lignes plus bas, on lit que le safe_mode sera également supprimé de PHP.
[^] # Re: D'autres trucs
Posté par jeffcom . Évalué à 2.
[^] # Re: D'autres trucs
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).
register_globals = off
allow_url_fopen = off
C'est encore activé par défaut ces horreurs ?
désactiver certaines fonctions si on en a pas besoin
Ce modèle de sécurité (liste noire) est bancal à mon avis. Plutôt que de lister quelques fonctions dangeureuses, il vaut mieux dresser une liste exhaustive des fonctions dont on a besoin (liste blanche). Je ne sais pas si c'est possible en PHP, mais ça serait la meilleure solution.
Pour illustrer mon propros (liste blanche vs liste noire) : c'est comme les protections « anti-include ». Refuser le motif « ../ » dans un nom de fichier est insuffisant. Si l'attaquant arrive à obtenir le chemin absolu (facile en général), il pourra accéder à n'importe quel fichier. La bonne solution est d'utiliser real_path() et vérifier que le fichier (ou le chemin) est dans une liste blanche.
modifier les applis pour ne permettre qu'un certain nombre de tentatives de login par minutes (à la fail2ban)
Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/
éventuellement utiliser le safemode pour mysql, mais normalement pas de soucis de ce coté si le reste est ok
Je pense qu'il vaudrait mieux créer un utilisateur MySQL aux droits restreints (ex : LOAD_FILE / SELECT INTO / ... sont-ils vraiment utiles sur un site web ?).
--
De ma petite expérience, PHP souffre de plusieurs problèmes :
* Le langage est trop laxiste, PHP devrait obliger les développeurs à corriger les erreurs. D'ailleurs, il faut beaucoup de motivation pour activer tous les avertissements et tous les corriger. Je vous déconseille de le faire sur un gros projet existant sous peine de dépression :-)
* Sites web développés par des développeurs ayant appris la programmation sur le tas (comme tout le monde) et n'ayant aucune connaissance en sécurité (comme la grande majorité des développeurs). Dans le cas de PHP, ça importe car les applications (sites web) sont accessibles depuis Internet.
* PHP et MySQL sont souvent installés avec un maximum de fonctionnalités, alors que du point de vue sécurité, il faudrait l'inverse. Exemple : allow_url_fopen activé par défaut.
* Pas de politique de sécurité globale : une faille PHP permet d'accéder à la base de données, au FTP, (parfois) aux autres sites hébergés sur le même serveur, puis à la boîte mail, etc. Un des problèmes courant est que le mot de passe est le même partout (FTP, MySQL, mail, etc.).
--
Je ne suis pas sûr que PHP soit l'origine du mal. C'est plutôt que les développeurs web débutent avec PHP. Il y a une association PHP = programmeur débutant, et donc indirectement PHP = site web peu sûr, puis PHP = langage peu sûr.
PS : Bien sûr, le langage en lui-même est vraiment une grosse merde comparés à ses concurrents (notamment Python et Ruby).
[^] # Re: D'autres trucs
Posté par jeffcom . Évalué à 3.
Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).
Oui mais normalement on restreint l'accès aux scripts en dev... ou alors on n'affiche les erreurs que pour le dev
C'est encore activé par défaut ces horreurs ?
ça dépend des distributions, et puis on ne sait jamais, si on arrive après un admin foireux, on pourra les trouver activées...
Ce modèle de sécurité (liste noire) est bancal à mon avis.
peut être mais on a pas le choix, et d'un autre coté ça permet d'être plus souple dans la gestion de la liste : en supprimant les fonctions à risque, on est relativement tranquille par la suite... et vu le nombre de fonctions de PHP, la lite noire sera toujours plus rapide à constituer et lire que la blanche.
Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/
je m'interroge sur l'utilité de remonter ça au mainteneur : si un utilisateur légitime a oublié son mot de passe : il le redemandera, les autres seront de faux utilisateurs essayant de trouver le mot de passe d'un utilisateur légitime... qu'est-ce qu'il s'en tape le mainteneur de savoir qu'un type a essayé de craquer un pass ? tant que le bloquage est efficace...
Je pense qu'il vaudrait mieux créer un utilisateur MySQL aux droits restreints (ex : LOAD_FILE / SELECT INTO / ... sont-ils vraiment utiles sur un site web ?).
ça dépend de ce que tu fais avec ton "site web"... et puis pour l'utilisateur : c'est évident je pense.
De ma petite expérience, PHP souffre de plusieurs problèmes :
on est déjà au courant et c'est hors de propos : l'objet du journal n'est pas de connaître les pb de php ou d'en faire le procès ni de le comparer à d'autres langages et n'est pas non plus un appel aux trolls poilus, mais juste une demande de constitution d'une liste de choses à faire pour sécuriser php autant que faire se peut.
Tout ce que tu dis est évident et notoire, cependant même en sachant ça, on ne sait pas forcément comment se prémunir de ces risques : ce journal devrait permettre à certains de savoir comment faire, point barre.
[^] # Re: D'autres trucs
Posté par Krunch (site web personnel) . Évalué à 2.
>
> Ce modèle de sécurité (liste noire) est bancal à mon avis. Plutôt que de lister
> quelques fonctions dangeureuses, il vaut mieux dresser une liste exhaustive des
> fonctions dont on a besoin (liste blanche). Je ne sais pas si c'est possible en PHP,
> mais ça serait la meilleure solution.
C'est pas beaucoup mieux : il suffit qu'une des fonctions whitelistées ne soit pas blindée pour qu'on puisse faire ce qu'on veut dans le contexte de PHP. De plus, je ne vois pas beaucoup de cas d'utilisation de PHP dans lesquels il serait faisable d'auditer toutes les fonctions utilisées.
Il me semle plus efficace de s'appuyer sur les mécanismes de sécurité du système qui sont a priori bien mieux audités et donc fiables. Chaque contexte dans son espace d'adressage propre sans possibilité d'interagir avec le monde extérieur en dehors de certaines interfaces prédéfinies. Bon, après il y a un problème de performances potentiel mais il existe des compromis.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: D'autres trucs
Posté par Ludo . Évalué à 1.
- fail2ban
- expose_php = off
- register_globals = off
- display_errors = off
- allow_url_fopen = off
Ainsi que logwatch pour avoir des informations de ce qui se passe sur le serveur.
[^] # Re: D'autres trucs
Posté par Krunch (site web personnel) . Évalué à 2.
> --- display_errors = off [1]
> - ne pas mettre le safe_mode à on, c'est une fausse sécurité
En quoi safe_mode=on est-il plus une fausse sécurité que expose_php=off ou display_errors=off ?
> [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
> qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,
Excellente idée pour introduire encore plus de failles potentielles.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: D'autres trucs
Posté par jeffcom . Évalué à 2.
Parce que le safe mode est tout sauf safe et introduit même de l'insécurité... en plus du fait que certains se permettent n'imp sous prétexte qu'ils sont en safe-mode...
Le expose_php et display_errors à off permettent simplement de ne pas donner trop d'infos concernant la configuration du serveur, ça évite, par exemple, que des robots scanent les page d'un serveur à la recherche d'une version de php ou d'une appli web particulière connue pour avoir telle et tell faille. Ça n'est pas, en soi un rempart infranchissable, mais ça permet d'éviter d'être trop facilement repéré.
> [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
> qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,
Excellente idée pour introduire encore plus de failles potentielles.
Le but de la manœuvre étant de ne pas afficher les erreurs pour le quidam ou simplement l'utilisateur final mais permettre aux mainteneurs d'avoir un retour en cas d'erreur, voire un meilleur retour : inscription dans une bdd des données utiles (utilisateur identifié, page, variables de session et tout ce qui peut être utile au debug) voire alerte plus importante dans le cas ou telle ou telle erreur survient sur tel ou tel script.
Évidemment, c'est comme tout, quand on sait pas faire : vaut mieux ne pas faire... si on garde ça en tête, on devrait éviter certaines grosses failles...
Si on va dans ce sens, la meilleur façon de ne pas avoir d'emmerde : c'est ne pas héberger de site web...
# Accès FTP
Posté par Bruno (site web personnel) . Évalué à 4.
En effet, depuis quelques temps sévissent un certain nombre de trojans qui se contentent de capturer les login/password qui transitent sur des flux ftp. Dans certains cas, les informations capturées sont uploadées sur un serveur distant. Il ne reste plus aux utilisateurs malveillants que de sniffer les espaces FTP ainsi récupérés, et injecter leur code dans tous les index.php trouvés, souvent un iframe qui contient un lien vers un SWF infecté.
C'est un sujet qui revient souvent sur les forums des hébergeurs, et il n'est pas aisé d'y remédier. Je suis tombé sur ce site qui évoque le déroulement de l'attaque : http://www.lepotlatch.org/index.php/post/2009/04/22/Mon-site(...)
Donc, pour sécuriser un peu plus le site :
* Recommander à ses utilisateurs d'avoir des logiciels de protection à jour
* Filtrer les IP ayant accès au FTP
* Eventuellement passer au sftp, en espérant que les trojans n'évoluent pas trop vite...
[^] # Re: Accès FTP
Posté par Seb . Évalué à 2.
dans ce cas le FTPS ne change rien malheureusement.
» ne jamais stocker un mot de passe en clair :)
[^] # Re: Accès FTP
Posté par suJeSelS . Évalué à 7.
[^] # Re: Accès FTP
Posté par Victor STINNER (site web personnel) . Évalué à 2.
SSH est plus rapide et surtout beaucoup plus sûr (chiffré) que l'horrible FTP.
[^] # Re: Accès FTP
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Lorsqu'on rapatrie plus 200Go des centres de calcul, c'est toujours en FTP, avec SSH, c'est quasiment impossible.
[^] # Re: Accès FTP
Posté par med . Évalué à 2.
[^] # Re: Accès FTP
Posté par Krunch (site web personnel) . Évalué à 2.
Après, si on veut bricoler, on peut utiliser SSH pour l'admin et netcat pour transférer les gros trucs sans chiffrer ni faire passer de mot de passe en clair.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Accès FTP
Posté par jeffcom . Évalué à 3.
[^] # Re: Accès FTP
Posté par srb (site web personnel) . Évalué à 1.
source: http://guides.ovh.com/SshMutualise
Donc, en dessous il faut faire sans. (On peut tout à fait comprendre qu'on ait pas accès à SSH pour les offres les moins chères, je ne discute pas ici le choix fait par ovh.)
[^] # Re: Accès FTP
Posté par jeffcom . Évalué à 2.
# bon sens
Posté par Psychofox (Mastodon) . Évalué à 5.
euh... c'est moi ou la réponse est dans la question ?
Si ces applications sont mal codées, il convient tout simplement de ne pas les utiliser au lieu de trouver des solution pour sécuriser la merde !
La suite de ton message, ce sont des pratiques applicables quelque soit la qualité du code de l'application utilisée. Mais si tu sais que le code que tu fais n'est pas sûr, il ne faut pas le faire tourner. Pas de négotiation possible.
[^] # Re: bon sens
Posté par Zenitram (site web personnel) . Évalué à 10.
(en pratique, toutes les applis ont des trous de sécurité, personne n'est parfait, la question est de savoir quand la faille va être trouvée. Ta solution revient à ne rien installer, c'est effectivement très sécurisé mais peu utile. En pratique, il y a des oublis sur les patch de sécurité. En pratique, on ne demande jamais à l'admin système si telle appli est utilisable, on dit "on a besoin de l'appli X, installe-la" etc...)
Pas de négotiation possible.
Effectivement, pas de négociation possible face à un admin comme ceci : à la porte, merci, mais on a besoin d'une personne qui fasse quelque chose (à la porte = soit plus de salaire, soit plus de responsabilité dans une association n'importe laquelle, une asso a aussi besoin de son serveur pour communiquer)
Si, tout est une question de négociation, et de gestion des contraintes (sécurité, utilisabilité, maintenabilité, fonctionnalités, délais...)
[^] # Re: bon sens
Posté par Etienne Bagnoud (site web personnel) . Évalué à 7.
Pas de négotiation possible.
Pas une question de négociation, ton job c'est de faire tourner des scripts (tout pourri) sur des serveurs, donc soit tu fais le job, soit tu en trouves un autre.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: bon sens
Posté par Maclag . Évalué à 5.
Je pense en particulier à tous les sites personnels, associatifs, etc.
Tu installes un CMS toi-même, tu dois le mettre à jour toi-même, et dans ton cas tu audites le code toi-même systématiquement au cas où?
Et encore, je ne parle pas des scripts perso...
# Mes remarques ...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
Tu ferais pas mieux de mettre ton répertoir d'upload à l'extérieur de l'arborescence web ?
4. Desactivation des .htaccess via AllowOverride None: Ainsi, le pirate ne pourra pas modifier la configuration d'Apache
Il faut penser à rapatrier tous les .htaccess dans la configuration du virtualhost
root:root 0644 sur .htaccess permet d'éviter des modifications. Car pour faire des petites redirections ça reste super pratique.
5. Désactiver les informations de version fournies par Apache via ServerTokens et ServerSignature
Je sais pas si ça a beaucoup d'importance, mais c'est pas un mal non plus.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mes remarques ...
Posté par Puyb (site web personnel) . Évalué à 4.
Dans ce cas, il faut aussi penser a créer un .htaccess vide dans "tous" les répertoires car sinon, rien n'empêche le pirate d'en créer un là ou li n'y en avait pas... Je préfère quand même la solution "pas de .htaccess", ça laisse mon de chance d'oublier un truc quelque part... Quitte à le réactiver sur quelques vhosts ou dossiers où l'on sait exactement ce que l'on fait...
[^] # Re: Mes remarques ...
Posté par Romeo . Évalué à 1.
[^] # Re: Mes remarques ...
Posté par blackshack . Évalué à 1.
[^] # Re: Mes remarques ...
Posté par Amand Tihon (site web personnel) . Évalué à 2.
Ce changement de droits est complètement inutile parce que justement, l'utilisateur du site, pour pouvoir uploader ses fichiers, a les droits en écriture sur le dossier.
[^] # Re: Mes remarques ...
Posté par Ludo . Évalué à 2.
4. L'autre problème, c'est qu'en autorisant la lecture de ces fichiers, tu fais perdre du temps à Apache qui devra les lire à chaque requête, contrairement au fichier de conf apache, où c'est lu uniquement au démarrage.
[^] # Re: Mes remarques ...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
/home/bohwaz/www/site.tld/www/.htaccess
/home/bohwaz/www/site.tld/.htaccess
/home/bohwaz/www/.htaccess
/home/bohwaz/.htaccess
/home/.htaccess
/.htaccess
Voilà, 6 accès au FS pour rien, en une requête. Imagine maintenant pour des centaines de requêtes secondes...
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Mes remarques ...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Il y a la méthode autre serveur sur le port 8080 sans possibilité de scripts ou cgi. Donc tu dois adapter tes liens (http://www.example.com:8080/fichier.jpeg) ou alors directement depuis ton script php (mes_fichiers.php?id=xxx).
Tu peux toujours utiliser une réécriture apache pour ça (www.example.com/fichiers/fichiers.jpeg -> www.example.com:8080/fichiers.jpeg), c'est transparent ou alors directement un autre serveur (fichier.example.com/fichier.jpeg). Tu retrouves cette dernière méthode sur des trucs comme yahoo (http://l.yimg.com/a/i/ww/beta/y3.gif).
J'aime bien la méthode autre serveur web juste pour les fichiers statiques. Mais ça dépend pourquoi tu le fais, sur un hébergement mutualisé, tu ne pourrais pas le faire.
4. L'autre problème ...
Oui, c'est pas parfait, ça dépend après ce que tu veux. J'aime bien avoir un fichier htaccess, qui généralement a les droits suivant : root:web 0664. Le groupe web étant les personnes autorisées à modifier les sites web.
Dans le cas d'un hébergement mutualisé, on pourrait imaginer avoir ftpuser:www-data 0640 (ftpuser étant différent pour chaque utilisateur, bien entendu).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mes remarques ...
Posté par Ludo . Évalué à 1.
Aurais-tu un exemple ?
[^] # Re: Mes remarques ...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Ensuite, et c'est personnel, j'aime bien avoir le minimum de configuration par démon. Donc avec deux serveurs web, tu as des configurations simple, presque "par défaut", donc moins de risque de te tromper.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# itk, open_basedir, bof .. vive mpm_peruser :)
Posté par Corentin Chary (site web personnel) . Évalué à 4.
Voir :
http://www.peruser.org/trac/projects/peruser
Un truc que j'avais fait dans le cadre d'un cours de sécu et qui parle de ça:
http://xf.iksaif.net/papers/securing-a-shared-web-server.pdf
[^] # Re: itk, open_basedir, bof .. vive mpm_peruser :)
Posté par Ludo . Évalué à 1.
[^] # Re: itk, open_basedir, bof .. vive mpm_peruser :)
Posté par Corentin Chary (site web personnel) . Évalué à 2.
Sous gentoo peruser est activé avec un simple useflag. Je l'utilise en prod depuis un ou deux ans sans problèmes notable (à part dans le cas de config ssl avec plusieurs virtual hosts, mais c'est reglé dans la prochaine version).
[^] # Re: itk, open_basedir, bof .. vive mpm_peruser :)
Posté par Ludo . Évalué à 1.
J'ai déjà eu quelques aventures avec une Gentoo stable en production.
J'utilise Gentoo pour héberger des applications en Ruby on rails.
[^] # Re: itk, open_basedir, bof .. vive mpm_peruser :)
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
itk + open_basedir reste pour le moment la meilleure solution pour un environnement de prod.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# Investigation ?
Posté par leoboy . Évalué à 2.
Je pense que les règles que tu proposes sont un bon début pour sécuriser la production. Avec un peu de chance, ça devrait suffire pour écarter bon nombre de script-kiddies en bouchant la(les) faille(s) qui a(ont) fait que ton serveur s'est retrouvé compromis.
Cependant, tu pourrais travailler sur un autre axe - l'analyse post mortem. J'en parle ici car je suis à la recherche d'idées ou de "bonnes manières" sur le sujet.
En ce moment, je réfléchis à une petite infrastructure pour externaliser un maximum d'informations décrivant le fonctionnement d'un serveur, dans le but de faire une analyse post-attaque. Globalement, cela consiste à :
-Envoyer une copie des logs sur un autre serveur avec les tentatives d'auth sur le ssh, le ftp, etc... (syslog en réseau)
-Activer le process accounting (paquet acct sous Debian et dérivés) qui donne beaucoup d'informations sur ce qui se passe et répliquer ces informations en dehors du serveur
-...
En sachant ce qui s'est passé pour que le serveur tombe, on peut en apprendre beaucoup sur l'attaque, et donc boucher les trous plus efficacement. Par contre, à part les deux sources d'infos que j'ai cité, je manque d'idées. Vous en avez d'autres ?
Au passage, changer le port par défaut de ssh est une TRES bonne idée si votre serveur est en public sur internet. La preuve : en 1 an, j'ai eu environ 1.500.000(!) tentatives de connection sur ssh, avec des login / pass très variés, la plupart du temps des bots qui déroulaient des listes. Depuis que ssh n'écoute plus sur le port 22 mais sur un port à 5 chiffres, je n'ai plus aucune tentative.
(Bon évidemment si on peut faire de l'authentif par clé, c'est mieux, mais vos clients n'aimeront peut-être pas toujours...)
[^] # Re: Investigation ?
Posté par bubar🦥 (site web personnel) . Évalué à 4.
ça t'évitera certainement de faire "l'analyse post-mortem" sur des serveurs de prod.
[^] # Re: Investigation ?
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Investigation ?
Posté par suJeSelS . Évalué à 5.
[^] # Re: Investigation ?
Posté par mamsekor . Évalué à 1.
Je conseille fortement d'utiliser ce protocole plutôt que FTP pour la mise à jour d'un site.
# Sinon si tu ne crains pas de lire
Posté par blackshack . Évalué à 5.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Des principes, en vrac, que j'utilise
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
DPKG {Pre-Invoke {
"mount -o rw,remount /usr";
}
Post-Invoke {
"mount -f -o ro,remount /usr";
}
}
Dans apt.conf te permets "d'oublier" tranquillement que tu as ton système en lecture seule.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Des principes, en vrac, que j'utilise
Posté par Ludo . Évalué à 1.
Quelqu'un aurait des informations à ce sujet ?
[^] # Re: Des principes, en vrac, que j'utilise
Posté par jeffcom . Évalué à 2.
Pas plus d'infos concernant «chroot vs jail BSD»
# Répertoire d'upload
Posté par Moogle . Évalué à 2.
Chez moi, les fichiers utilisateurs ne sont jamais uploadés dans un répertoire accessible directement depuis la racine du site. J'accède aux fichiers via une page PHP qui est faite pour, et qui me permet au passage d'ajouter par exemple une gestion des droits.
Si vraiment on doit pouvoir écrire dans un répertoire accessible directement, le mieux est encore de filtrer les fichiers en n'autorisant que certains types, voir même en forçant le nom du fichier (par exemple pour un avatar de forum, imposer que ça soit <hash du nom d'utilisateur>.jpg).
[^] # Re: Répertoire d'upload
Posté par Krunch (site web personnel) . Évalué à 2.
Voir par exemple http://code.google.com/p/browsersec/wiki/Part2#Content_handl(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Répertoire d'upload
Posté par Moogle . Évalué à 2.
[^] # Re: Répertoire d'upload
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# ModSecurity ?
Posté par ulver . Évalué à 1.
Quelqu'un l'utilise en production ?
[1] http://www.modsecurity.org/
# /o\
Posté par benoar . Évalué à 1.
[^] # Re: /o\
Posté par eon2004 . Évalué à 2.
[^] # Re: /o\
Posté par benoar . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.