J'ai été victime d'un piratage d'un serveur apache 2 équipé de awstats en
cgi. Apparament, des SK ont utilisé mon système pour télécharger des trucs
pas très catholiques. Je ne savais pas que awstats était si sensible/
J'ai conservé tous les logs, bien sûr
les clients incriminés sont:
82.77.209.42
66.148.165.235
les fichiers téléchargés sont:
soit des executables
'anacrond'
'awstats.pl'
'https'
'proc'
ou des tar.gz qui sont des sources:
b.tar.gz
gradina.tar.gz
Les adresses où se sont connectés les pirates sont:
http://zburchi.idilis.ro/https
http://adrians.lx.ro/proc
http://iceghost.go.ro/anacrond
apparament, c'est surout en roumanie
les logs se manifestent de la façon suivante dans le error log de apache,
c'est très voyant, peu dans le access log
[Sun Mar 20 17:23:40 2005] [error] [client 66.148.165.235] sh: line
1: /awstats.mon_site_internet.com.conf: No such file or directory
[Sun Mar 20 17:24:18 2005] [error] [client 66.148.165.235] sh: line
1: /awstats.mon_site_internet.com.conf: No such file or directory
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] --17:24:38--
http://adrians.lx.ro/proc
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] =>
`proc'
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] Resolving
adrians.lx.ro...
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] 66.230.157.75
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] Connecting to
adrians.lx.ro[66.230.157.75]:80...
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] connected.
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] HTTP request
sent, awaiting response...
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] 200 OK
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] Length:
unspecified [application/octet-stream]
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235]
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] 0K .
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] ..
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] ..
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] . .
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] ..
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] ..
[Sun Mar 20 17:24:38 2005] [error] [client
66.148.165.235] . ??% 71.1K
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235]
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] 17:24:38 (70.88
KB/s) - `proc' saved [19,578]
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235]
[Sun Mar 20 17:24:38 2005] [error] [client 66.148.165.235] sh: line
1: /awstats.mon_site_internet.com.conf: No such file or directory
[Sun Mar 20 17:24:45 2005] [error] [client 200.217.110.54] File does not
exist: /usr/share/awstats/icon/awstats.pl
[Sun Mar 20 17:24:53 2005] [error] [client 66.148.165.235] sh: line
1: /awstats.mon_site_internet.com.conf: No such file or directory
[client 65.54.188.65] script '/mnt/data/websites/meme-anna/web/sondages.php'
not found or unable to stat
[Sun Mar 20 17:33:01 2005] [error] [client 66.148.165.235] sh: line
1: /awstats.mon_site_internet.com.conf: No such file or directory
[Sun Mar 20 17:33:05 2005] [error] [client 66.148.165.235] sh: line
1: /awstats.mon_site_internet.com.conf: No such file or directory
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] --17:33:18--
http://zburchi.idilis.ro/https
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] =>
`https'
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] Resolving
zburchi.idilis.ro...
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] 217.156.85.3
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235]
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] Connecting to
zburchi.idilis.ro[217.156.85.3]:80...
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] connected.
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] HTTP request
sent, awaiting response...
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] 200 OK
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] Length: 19,807
[text/plain]
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235]
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] 0K .
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] ..
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] ..
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] . .
[Sun Mar 20 17:33:18 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:33:19 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:33:19 2005] [error] [client 66.148.165.235] ..
[Sun Mar 20 17:33:19 2005] [error] [client 66.148.165.235] .
[Sun Mar 20 17:33:19 2005] [error] [client 66.148.165.235] ..
[Sun Mar 20 17:33:19 2005] [error] [client 66.148.165.235] .
100% 117K
[Sun Mar 20 17:33:19 2005] [error] [client 66.148.165.235]
[Sun Mar 20 17:33:19 2005] [error] [client 66.148.165.235] 17:33:19 (116.90
KB/s) - `https' saved [19,807/19,807]
[Sun Mar 20 17:33:19 2005] [error] [client 66.148.165.235]
[Sun Mar 20 17:33:19 2005] [error] [client 66.148.165.235] sh: line
1: /awstats.mon_site_internet.com.conf: No such file or directory
[Sun Mar 20 17:38:19 2005] [error] [client 66.148.165.235] (70007)The
timeout specified has expired: ap_content_length_filter: apr_bucket_read()
failed
Bon ben voilà, ça dit quelque chose à quelqu'un
J'ai tout bloqué les CGI, signalé partout, faites gaffe vous qui avez
awstats installé en CGI
( Mon, 21 Mar 2005 10:14:29 +0000 ) Sebastien Vincent :
je pense; sans en être sur qu'il s'agissait de faire tourner des bots irc, au vu des sources qu'ils avaient téléchargés.
Bah des warbots et/ou bouncer :)
Chez moi il faisaient tourner un process nomé psyncb sous le login d'un des user (jason)
et oui justement netstat me rendait compte de plusieurs connections vers des machine sur un port irc (mais je n'ai pas eu le temps de vérifier si c'est vraiment de l'irc qu'il faisaient) ce n'etait pas des transferts, car je l'aurai vu par iftop sinon. de toutes façon en cherchant psyncb surinternet, j'ai trouvé que c'est un truc qui a un rapport avec IRC.
ils avaient établi aussi (ou tentaient d'établir) quelques milliers de connections sur le port 22 d'une machine en *.ru .
Ca permet de lancer des attaques depuis ton serveur.
Voilà. sinon moi j'ai demandé la reinstallation... -- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Mon, 21 Mar 2005 10:14:29 +0000 ) Sebastien Vincent :
je pense; sans en être sur qu'il s'agissait de faire tourner des bots irc,
au vu des sources qu'ils avaient téléchargés.
Bah des warbots et/ou bouncer :)
Chez moi il faisaient tourner un process nomé psyncb sous le login d'un
des user (jason)
et oui justement netstat me rendait compte de plusieurs connections vers
des machine sur un port irc (mais je n'ai pas eu le temps de vérifier si
c'est vraiment de l'irc qu'il faisaient) ce n'etait pas des transferts,
car je l'aurai vu par iftop sinon. de toutes façon en cherchant psyncb
surinternet, j'ai trouvé que c'est un truc qui a un rapport avec IRC.
ils avaient établi aussi (ou tentaient d'établir) quelques milliers de
connections sur le port 22 d'une machine en *.ru .
Ca permet de lancer des attaques depuis ton serveur.
Voilà. sinon moi j'ai demandé la reinstallation...
--
Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois!
La preuve http://www.google.fr/search?q=serveur+dedie
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Mon, 21 Mar 2005 10:14:29 +0000 ) Sebastien Vincent :
je pense; sans en être sur qu'il s'agissait de faire tourner des bots irc, au vu des sources qu'ils avaient téléchargés.
Bah des warbots et/ou bouncer :)
Chez moi il faisaient tourner un process nomé psyncb sous le login d'un des user (jason)
et oui justement netstat me rendait compte de plusieurs connections vers des machine sur un port irc (mais je n'ai pas eu le temps de vérifier si c'est vraiment de l'irc qu'il faisaient) ce n'etait pas des transferts, car je l'aurai vu par iftop sinon. de toutes façon en cherchant psyncb surinternet, j'ai trouvé que c'est un truc qui a un rapport avec IRC.
ils avaient établi aussi (ou tentaient d'établir) quelques milliers de connections sur le port 22 d'une machine en *.ru .
Ca permet de lancer des attaques depuis ton serveur.
Voilà. sinon moi j'ai demandé la reinstallation... -- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
HelloMan
Mon post précédant, c'était du snortlog (libpcap)
J'avais oublié de joindre le snort alert correspondant.
Le Mon, 21 Mar 2005 12:01:04 +0000, Rakotomandimby (R12y) Mihamina a écrit :
Chez moi il faisaient tourner un process nomé psyncb sous le login d'un des user (jason)
Psybnc est un bouncer IRC. D'où les connexions IRC que tu as pu voir.
-- BOFH excuse #308:
CD-ROM server needs recalibration
HelloMan
et oui justement netstat me rendait compte de plusieurs connections vers des machine sur un port irc (mais je n'ai pas eu le temps de vérifier si c'est vraiment de l'irc qu'il faisaient) ce n'etait pas des transferts, car je l'aurai vu par iftop sinon. de toutes façon en cherchant psyncb surinternet, j'ai trouvé que c'est un truc qui a un rapport avec IRC.
psyncb fait partie des fichiers téléchargés.
et oui justement netstat me rendait compte de plusieurs connections vers
des machine sur un port irc (mais je n'ai pas eu le temps de vérifier si
c'est vraiment de l'irc qu'il faisaient) ce n'etait pas des transferts,
car je l'aurai vu par iftop sinon. de toutes façon en cherchant psyncb
surinternet, j'ai trouvé que c'est un truc qui a un rapport avec IRC.
et oui justement netstat me rendait compte de plusieurs connections vers des machine sur un port irc (mais je n'ai pas eu le temps de vérifier si c'est vraiment de l'irc qu'il faisaient) ce n'etait pas des transferts, car je l'aurai vu par iftop sinon. de toutes façon en cherchant psyncb surinternet, j'ai trouvé que c'est un truc qui a un rapport avec IRC.
psyncb fait partie des fichiers téléchargés.
Sebastien Vincent
je pense; sans en être sur qu'il s'agissait de faire tourner des bots irc, au vu des sources qu'ils avaient téléchargés.
Bah des warbots et/ou bouncer :) Ca permet de lancer des attaques depuis ton serveur. J'ai vérifié immédiatement sur dshield, apparament je suis clair, mais cela
ne veut rien dire
En effet... Un nmap exaustif du poste peut aider, un tcpdump sur la gateway encore plus
La franchement, il semble qu'il y ai eu compromission root, si tu as des solides connaissances de ton systeme, tu peux partir a la recherche de la backdoor (s'il n'y en a qu'une) mais c'est un travail long et laborieux que je ne saurais te recommander. Reinstalle from scratch... Yeah, comme sous windows !!!
Maheuresement un systeme d'exploitation est consitués de dizaines de milliers de fichiers, et personne ne les connais tous par coeur...
PS: tout cela m'accélère la dernière étape du transit intestinal
Si tu prend le temps de faire ce que je t'ai dis en privé tu calmera 99.99% des scripts kiddies. Une mise a jour quotidienne et une bonne distribution permet de réaliser le travail "chiant" en quelques minutes.
Amicalement,
Seb :)
je pense; sans en être sur qu'il s'agissait de faire tourner des bots
irc, au vu des sources qu'ils avaient téléchargés.
Bah des warbots et/ou bouncer :)
Ca permet de lancer des attaques depuis ton serveur.
J'ai vérifié immédiatement sur dshield, apparament je suis clair, mais cela
ne veut rien dire
En effet...
Un nmap exaustif du poste peut aider, un tcpdump sur la gateway encore
plus
La franchement, il semble qu'il y ai eu compromission root, si tu as des
solides connaissances de ton systeme, tu peux partir a la recherche de
la backdoor (s'il n'y en a qu'une) mais c'est un travail long et
laborieux que je ne saurais te recommander. Reinstalle from scratch...
Yeah, comme sous windows !!!
Maheuresement un systeme d'exploitation est consitués de dizaines de
milliers de fichiers, et personne ne les connais tous par coeur...
PS: tout cela m'accélère la dernière étape du transit intestinal
Si tu prend le temps de faire ce que je t'ai dis en privé tu calmera
99.99% des scripts kiddies. Une mise a jour quotidienne et une bonne
distribution permet de réaliser le travail "chiant" en quelques minutes.
je pense; sans en être sur qu'il s'agissait de faire tourner des bots irc, au vu des sources qu'ils avaient téléchargés.
Bah des warbots et/ou bouncer :) Ca permet de lancer des attaques depuis ton serveur. J'ai vérifié immédiatement sur dshield, apparament je suis clair, mais cela
ne veut rien dire
En effet... Un nmap exaustif du poste peut aider, un tcpdump sur la gateway encore plus
La franchement, il semble qu'il y ai eu compromission root, si tu as des solides connaissances de ton systeme, tu peux partir a la recherche de la backdoor (s'il n'y en a qu'une) mais c'est un travail long et laborieux que je ne saurais te recommander. Reinstalle from scratch... Yeah, comme sous windows !!!
Maheuresement un systeme d'exploitation est consitués de dizaines de milliers de fichiers, et personne ne les connais tous par coeur...
PS: tout cela m'accélère la dernière étape du transit intestinal
Si tu prend le temps de faire ce que je t'ai dis en privé tu calmera 99.99% des scripts kiddies. Une mise a jour quotidienne et une bonne distribution permet de réaliser le travail "chiant" en quelques minutes.
Amicalement,
Seb :)
Rakotomandimby (R12y) Mihamina
( Mon, 21 Mar 2005 14:12:00 +0000 ) Sebastien Vincent :
Si tu prend le temps de faire ce que je t'ai dis en privé tu calmera 99.99% des scripts kiddies.
Puis-je en bénéficier s'il te plait ?
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Mon, 21 Mar 2005 14:12:00 +0000 ) Sebastien Vincent :
Si tu prend le temps de faire ce que je t'ai dis en privé tu calmera
99.99% des scripts kiddies.
Puis-je en bénéficier s'il te plait ?
--
Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois!
La preuve http://www.google.fr/search?q=serveur+dedie
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Mon, 21 Mar 2005 14:12:00 +0000 ) Sebastien Vincent :
Si tu prend le temps de faire ce que je t'ai dis en privé tu calmera 99.99% des scripts kiddies.
Puis-je en bénéficier s'il te plait ?
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
Sebastien Vincent
Si tu prend le temps de faire ce que je t'ai dis en privé tu calmera 99.99% des scripts kiddies. Puis-je en bénéficier s'il te plait ?
Je suis en train de faire un nouveau thread clair sur le sujet pour que tout le monde puisse en bénéficier. Il est nommé "Sécuriser son serveur web".
Amicalement,
Seb :)
Si tu prend le temps de faire ce que je t'ai dis en privé tu calmera
99.99% des scripts kiddies.
Puis-je en bénéficier s'il te plait ?
Je suis en train de faire un nouveau thread clair sur le sujet pour que
tout le monde puisse en bénéficier. Il est nommé "Sécuriser son serveur
web".
Si tu prend le temps de faire ce que je t'ai dis en privé tu calmera 99.99% des scripts kiddies. Puis-je en bénéficier s'il te plait ?
Je suis en train de faire un nouveau thread clair sur le sujet pour que tout le monde puisse en bénéficier. Il est nommé "Sécuriser son serveur web".
Amicalement,
Seb :)
Sebastien Vincent
Bonjour,
Suite à la discussion "apache2 et awstats", voici quelques petits conseils, trucs et astuces sur comment monter un serveur web et "limiter" les risques, j'insiste sur le mot "limiter" :)
Toutes les remarques seront constructives et ces recommandations repose sur mon expérience de 2 ans dans le domaine de l'administration réseau. (j'ai appris ce qu'était un DNS il y a deux ans :))
=== Guide de l'administrateur de site Unix en herbe :) == 1. Environnement : ================= 1.1 Système d'exploitation --------------------------
Je recommande OpenBSD, et cela n'engage que moi et mes raisons sont les suivantes : - confinement chroot par défaut. - protection de la pile propolice. - séparation des pouvoirs (nombreux utilisateurs) par défault - pas de shell pour apache.
Ce n'est pas forcément un système facile à prendre en main, meme si une excelente documentation existe sur le site à l'adresse http://www.openbsd.org/faq/fr/index.html
Si sauter le pas vers OpenBSD vous fait peur, alors optez pour gentoo pour les raisons suivantes : - gestion des packages très puissante (dépendances, fonctionalités des programmes, etc...) - réactivité impressionnante de l'équipe faces aux problèmes de sécurité. - apache n'a pas de shell - sensation de maitriser son système qui donne envie d'aller plus loin dans la sécurisation.
Debian ressemble beaucoup a gentoo, et est une alternative qui peut être envisagée avec sérénité aussi.
1.2 Administration ------------------
Administrez par ssh, pas de telnet, ne vous loguez pas en root. Pour vous faire violence mettez "PermitRootLogin No" dans sshd_config, vous vous habituerez très vite à ce nouveau mode opératoire :)
2. Droits sur le site : ====================== 2.1 PhpMyAdmin -------------- Souvent il est sympa d'avoir PhpMyAdmin ce qui n'est pas forcément une bonne idée pour les raisons suivante : - lecture du fichier config par un intru - faille de sécurité potentielle
Pour palier a cela pensez a utiliser un fichier .htaccess
2.2 Les dossiers ---------------- Il ne faut pas que le listing de dossier soit activé, cela n'a pas d'interet, si celui ci est indispensable (par exemple pour certains de vos clients si vous hébergez) limitez la casse au cas par cas pour forcer l'attaquant a y aller au tatonnement. L'attaquant se servira de cette possibiliter de lister pour trouver un fichier contenant des informations confidentielles (ie. contenant des mots de passes) ou un fichier/dossier inscriptible.
Le dossier incriptible servira a heberger un shell php, qui sera utilisable facilement dans un schéma du style : http://www.monpigeon.com/client3/test/phpshell.php
Mantenant autre chose, vous avez bien placé le dossier en lecture seule, mais la l'attaquant y trouve un fichier php sur lequel il peut ecrire, il remplacera le contenu du fichier par son shell php (fera un petit backup s'il est discret dans /tmp).
Alors protégez vos dossiers mais aussi vos fichiers php, cgi, etc...
3. Le shell : ============ Souvent l'attaquant aura utilisé un exploit de type "remote command execution", dans un outil tel que AwStat, PhpBB, etc... Il cherchera un shell potable : - envoi d'un shell ou reverse shell sur le site - execution de celui-ci.
Pour l'empécher de télécharger cet exécutable sur le site, retirez les outils de téléchargement, dont voici une petite liste : - wget - lynx (--source >) - ftp - links et links2
La solution a mon avis la plus simple est de créer un groupe "download" dans lequel on rajoutera les utilisateurs en ayant absolument besoin (par exemple votre compte adminstrateur qui servira pour télécharger les mises a jour).
Le même probleme se répète avec les compilateurs et outils de développement, la aussi, créez un groupe "devel" pour les outils suivants : - gcc - g++ - as - nm - objdump - ar - ht (si pas possibilité de le supprimer)
Autres outils à ne pas laisser a disposition : - lsof (permet une liste quasi-exhausive de tous les logs) - nmap - tcpdump
4. Le compte root : ================== Bon l'attaquant a réussi a avoir un compte shell, il est sur le système et dispose maintenant d'une multitude de moyens pour élever ses privilèges.
4.1 Le noyau ------------
Le noyau est la caverne d'ali baba de l'attaquant, pour devenir root rien de mieux, il est installé partout et est la cible privilégiée des hackers (full disclosure) et crackers. Une attention particulière doit être apportée au noyau et il doit être mis à jour de facon régulière. Je sais que mettre un noyau a jour c'est rebooter (donc interruption de service de quelques minutes (secondes ?)) et que pour un site web ce n'est pas top. Faites le en heures creuses, mais fait le !
4.2 Les demons --------------
Un démon lancé en root et vulnérable a une faille de type "code execution" aussi bien en remote qu'en local a notre stade donne access aux droits root, et permet donc assez facilement d'obtenir un shell avec les droits root.
Chassez les démons se lancant en root, beaucoups de gens traitent ces problemes sur le net et les méthodes pour limiter les droits d'un démons sont nombreuses et détaillées.
Confiner dans un environnement chroot tous les démons possibles, la aussi les documents techniques sur le sujet affluent.
4.3 Le Honey Pot ----------------
Et oui, cette fois ci dans le role de l'attaquant. Cela se présente simplement.
L'attaquant dispose d'un compte sans pouvoir, et va rechercher tous les fichiers executable sur lesquels il a les droits d'ecriture, et modifier le binaire en question pour pieger l'administrateur. En général lorsqu'on atteins ce niveau "script kiddie+" c'est bien fait, donc indolore. L'administrateur le lance en root, ou avec un compte avec pouvoir et sans se rendre compte, donne un access a l'attaquant (shell root suid caché dans l'arborescence, création d'un compte, etc...).
5. Divers : ========== - ne JAMAIS lancer le "updatedb" de "locate" en root (supprimer si possible) - les répertoire homes sont souvent en 744, les mettre en 700. - Faire un chkrootkit souvent, mais toujours le réinstaller à la main l'attaquant serait trop heureux de le remplacer pour vous faire croire que tout va bien.
Bonjour,
Suite à la discussion "apache2 et awstats", voici quelques petits
conseils, trucs et astuces sur comment monter un serveur web et
"limiter" les risques, j'insiste sur le mot "limiter" :)
Toutes les remarques seront constructives et ces recommandations
repose sur mon expérience de 2 ans dans le domaine de l'administration
réseau. (j'ai appris ce qu'était un DNS il y a deux ans :))
=== Guide de l'administrateur de site Unix en herbe :) ==
1. Environnement :
=================
1.1 Système d'exploitation
--------------------------
Je recommande OpenBSD, et cela n'engage que moi et mes raisons
sont les suivantes :
- confinement chroot par défaut.
- protection de la pile propolice.
- séparation des pouvoirs (nombreux utilisateurs) par défault
- pas de shell pour apache.
Ce n'est pas forcément un système facile à prendre en main, meme
si une excelente documentation existe sur le site à l'adresse
http://www.openbsd.org/faq/fr/index.html
Si sauter le pas vers OpenBSD vous fait peur, alors optez pour
gentoo pour les raisons suivantes :
- gestion des packages très puissante (dépendances, fonctionalités des
programmes, etc...)
- réactivité impressionnante de l'équipe faces aux problèmes de
sécurité.
- apache n'a pas de shell
- sensation de maitriser son système qui donne envie d'aller plus
loin dans la sécurisation.
Debian ressemble beaucoup a gentoo, et est une alternative qui peut
être envisagée avec sérénité aussi.
1.2 Administration
------------------
Administrez par ssh, pas de telnet, ne vous loguez pas en root. Pour
vous faire violence mettez "PermitRootLogin No" dans sshd_config, vous
vous habituerez très vite à ce nouveau mode opératoire :)
2. Droits sur le site :
======================
2.1 PhpMyAdmin
--------------
Souvent il est sympa d'avoir PhpMyAdmin ce qui n'est pas forcément
une bonne idée pour les raisons suivante :
- lecture du fichier config par un intru
- faille de sécurité potentielle
Pour palier a cela pensez a utiliser un fichier .htaccess
2.2 Les dossiers
----------------
Il ne faut pas que le listing de dossier soit activé, cela n'a pas
d'interet, si celui ci est indispensable (par exemple pour certains de
vos clients si vous hébergez) limitez la casse au cas par cas pour
forcer l'attaquant a y aller au tatonnement. L'attaquant se servira de
cette possibiliter de lister pour trouver un fichier contenant des
informations confidentielles (ie. contenant des mots de passes) ou un
fichier/dossier inscriptible.
Le dossier incriptible servira a heberger un shell php, qui sera
utilisable facilement dans un schéma du style :
http://www.monpigeon.com/client3/test/phpshell.php
Mantenant autre chose, vous avez bien placé le dossier en lecture seule,
mais la l'attaquant y trouve un fichier php sur lequel il peut ecrire,
il remplacera le contenu du fichier par son shell php (fera un petit
backup s'il est discret dans /tmp).
Alors protégez vos dossiers mais aussi vos fichiers php, cgi, etc...
3. Le shell :
============
Souvent l'attaquant aura utilisé un exploit de type "remote command
execution", dans un outil tel que AwStat, PhpBB, etc... Il
cherchera un shell potable :
- envoi d'un shell ou reverse shell sur le site
- execution de celui-ci.
Pour l'empécher de télécharger cet exécutable sur le site, retirez
les outils de téléchargement, dont voici une petite liste :
- wget
- lynx (--source >)
- ftp
- links et links2
La solution a mon avis la plus simple est de créer un groupe
"download" dans lequel on rajoutera les utilisateurs en ayant absolument
besoin (par exemple votre compte adminstrateur qui servira pour
télécharger les mises a jour).
Le même probleme se répète avec les compilateurs et outils de
développement, la aussi, créez un groupe "devel" pour les outils
suivants :
- gcc
- g++
- as
- nm
- objdump
- ar
- ht (si pas possibilité de le supprimer)
Autres outils à ne pas laisser a disposition :
- lsof (permet une liste quasi-exhausive de tous les logs)
- nmap
- tcpdump
4. Le compte root :
==================
Bon l'attaquant a réussi a avoir un compte shell, il est sur le système
et dispose maintenant d'une multitude de moyens pour élever ses
privilèges.
4.1 Le noyau
------------
Le noyau est la caverne d'ali baba de l'attaquant, pour devenir root
rien de mieux, il est installé partout et est la cible privilégiée des
hackers (full disclosure) et crackers. Une attention particulière doit
être apportée au noyau et il doit être mis à jour de facon régulière. Je
sais que mettre un noyau a jour c'est rebooter (donc interruption de
service de quelques minutes (secondes ?)) et que pour un site web ce
n'est pas top. Faites le en heures creuses, mais fait le !
4.2 Les demons
--------------
Un démon lancé en root et vulnérable a une faille de type "code
execution" aussi bien en remote qu'en local a notre stade donne access
aux droits root, et permet donc assez facilement d'obtenir un shell
avec les droits root.
Chassez les démons se lancant en root, beaucoups de gens traitent
ces problemes sur le net et les méthodes pour limiter les droits d'un
démons sont nombreuses et détaillées.
Confiner dans un environnement chroot tous les démons possibles, la
aussi les documents techniques sur le sujet affluent.
4.3 Le Honey Pot
----------------
Et oui, cette fois ci dans le role de l'attaquant. Cela se présente
simplement.
L'attaquant dispose d'un compte sans pouvoir, et va rechercher tous
les fichiers executable sur lesquels il a les droits d'ecriture, et
modifier le binaire en question pour pieger l'administrateur. En général
lorsqu'on atteins ce niveau "script kiddie+" c'est bien fait, donc
indolore. L'administrateur le lance en root, ou avec un compte avec
pouvoir et sans se rendre compte, donne un access a l'attaquant (shell
root suid caché dans l'arborescence, création d'un compte, etc...).
5. Divers :
==========
- ne JAMAIS lancer le "updatedb" de "locate" en root (supprimer si
possible)
- les répertoire homes sont souvent en 744, les mettre en 700.
- Faire un chkrootkit souvent, mais toujours le réinstaller à
la main l'attaquant serait trop heureux de le remplacer pour
vous faire croire que tout va bien.
Suite à la discussion "apache2 et awstats", voici quelques petits conseils, trucs et astuces sur comment monter un serveur web et "limiter" les risques, j'insiste sur le mot "limiter" :)
Toutes les remarques seront constructives et ces recommandations repose sur mon expérience de 2 ans dans le domaine de l'administration réseau. (j'ai appris ce qu'était un DNS il y a deux ans :))
=== Guide de l'administrateur de site Unix en herbe :) == 1. Environnement : ================= 1.1 Système d'exploitation --------------------------
Je recommande OpenBSD, et cela n'engage que moi et mes raisons sont les suivantes : - confinement chroot par défaut. - protection de la pile propolice. - séparation des pouvoirs (nombreux utilisateurs) par défault - pas de shell pour apache.
Ce n'est pas forcément un système facile à prendre en main, meme si une excelente documentation existe sur le site à l'adresse http://www.openbsd.org/faq/fr/index.html
Si sauter le pas vers OpenBSD vous fait peur, alors optez pour gentoo pour les raisons suivantes : - gestion des packages très puissante (dépendances, fonctionalités des programmes, etc...) - réactivité impressionnante de l'équipe faces aux problèmes de sécurité. - apache n'a pas de shell - sensation de maitriser son système qui donne envie d'aller plus loin dans la sécurisation.
Debian ressemble beaucoup a gentoo, et est une alternative qui peut être envisagée avec sérénité aussi.
1.2 Administration ------------------
Administrez par ssh, pas de telnet, ne vous loguez pas en root. Pour vous faire violence mettez "PermitRootLogin No" dans sshd_config, vous vous habituerez très vite à ce nouveau mode opératoire :)
2. Droits sur le site : ====================== 2.1 PhpMyAdmin -------------- Souvent il est sympa d'avoir PhpMyAdmin ce qui n'est pas forcément une bonne idée pour les raisons suivante : - lecture du fichier config par un intru - faille de sécurité potentielle
Pour palier a cela pensez a utiliser un fichier .htaccess
2.2 Les dossiers ---------------- Il ne faut pas que le listing de dossier soit activé, cela n'a pas d'interet, si celui ci est indispensable (par exemple pour certains de vos clients si vous hébergez) limitez la casse au cas par cas pour forcer l'attaquant a y aller au tatonnement. L'attaquant se servira de cette possibiliter de lister pour trouver un fichier contenant des informations confidentielles (ie. contenant des mots de passes) ou un fichier/dossier inscriptible.
Le dossier incriptible servira a heberger un shell php, qui sera utilisable facilement dans un schéma du style : http://www.monpigeon.com/client3/test/phpshell.php
Mantenant autre chose, vous avez bien placé le dossier en lecture seule, mais la l'attaquant y trouve un fichier php sur lequel il peut ecrire, il remplacera le contenu du fichier par son shell php (fera un petit backup s'il est discret dans /tmp).
Alors protégez vos dossiers mais aussi vos fichiers php, cgi, etc...
3. Le shell : ============ Souvent l'attaquant aura utilisé un exploit de type "remote command execution", dans un outil tel que AwStat, PhpBB, etc... Il cherchera un shell potable : - envoi d'un shell ou reverse shell sur le site - execution de celui-ci.
Pour l'empécher de télécharger cet exécutable sur le site, retirez les outils de téléchargement, dont voici une petite liste : - wget - lynx (--source >) - ftp - links et links2
La solution a mon avis la plus simple est de créer un groupe "download" dans lequel on rajoutera les utilisateurs en ayant absolument besoin (par exemple votre compte adminstrateur qui servira pour télécharger les mises a jour).
Le même probleme se répète avec les compilateurs et outils de développement, la aussi, créez un groupe "devel" pour les outils suivants : - gcc - g++ - as - nm - objdump - ar - ht (si pas possibilité de le supprimer)
Autres outils à ne pas laisser a disposition : - lsof (permet une liste quasi-exhausive de tous les logs) - nmap - tcpdump
4. Le compte root : ================== Bon l'attaquant a réussi a avoir un compte shell, il est sur le système et dispose maintenant d'une multitude de moyens pour élever ses privilèges.
4.1 Le noyau ------------
Le noyau est la caverne d'ali baba de l'attaquant, pour devenir root rien de mieux, il est installé partout et est la cible privilégiée des hackers (full disclosure) et crackers. Une attention particulière doit être apportée au noyau et il doit être mis à jour de facon régulière. Je sais que mettre un noyau a jour c'est rebooter (donc interruption de service de quelques minutes (secondes ?)) et que pour un site web ce n'est pas top. Faites le en heures creuses, mais fait le !
4.2 Les demons --------------
Un démon lancé en root et vulnérable a une faille de type "code execution" aussi bien en remote qu'en local a notre stade donne access aux droits root, et permet donc assez facilement d'obtenir un shell avec les droits root.
Chassez les démons se lancant en root, beaucoups de gens traitent ces problemes sur le net et les méthodes pour limiter les droits d'un démons sont nombreuses et détaillées.
Confiner dans un environnement chroot tous les démons possibles, la aussi les documents techniques sur le sujet affluent.
4.3 Le Honey Pot ----------------
Et oui, cette fois ci dans le role de l'attaquant. Cela se présente simplement.
L'attaquant dispose d'un compte sans pouvoir, et va rechercher tous les fichiers executable sur lesquels il a les droits d'ecriture, et modifier le binaire en question pour pieger l'administrateur. En général lorsqu'on atteins ce niveau "script kiddie+" c'est bien fait, donc indolore. L'administrateur le lance en root, ou avec un compte avec pouvoir et sans se rendre compte, donne un access a l'attaquant (shell root suid caché dans l'arborescence, création d'un compte, etc...).
5. Divers : ========== - ne JAMAIS lancer le "updatedb" de "locate" en root (supprimer si possible) - les répertoire homes sont souvent en 744, les mettre en 700. - Faire un chkrootkit souvent, mais toujours le réinstaller à la main l'attaquant serait trop heureux de le remplacer pour vous faire croire que tout va bien.
