Voilà, je viens seulement de constater (et c'est honteux), que apache et apache-ssl ont toujours un process qui tourne en root.
L'explication : http://lists.debian.org/debian-security/2001/04/msg00056.html(...)
Or, en Janvier, mon serveur a été piraté suite à une faille dans awstats.
Les attaquants ont ensuite lancés un script en root sur la machine (qui a effacé tous les fichiers contenant la chaine "log" dans le nom".)
Je me demande encore aujourd'hui comment ils sont passés de la faille d'awstats (www-data) au compte root.
Et en lisant ceci, je ne comprend plus trop : si un process apache tourne en root pour lancer d'autres process, il suffit de lui indiquer de lancer un process comme root (ou comme adm, par exemple).
Bref, je ne comprend pas trop ou est la sécurité dans ce cas-ci. Peut-elle des personnes plus compétentes pourraient éclairer ma lanterne ?
Journal User root de apache : une faille ?
21
mar.
2005
# C'est normal
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Email qui a confirmé ce que je pensais :
http://lists.virus.org/freebsd-security-0412/msg00010.html(...)
Bon, maintenant, je ne sais pas si le système est parfait. Le mieux étant d'avoir un système à jour ;-)
Aujourd'hui, les programmes tournent le moins souvent possible en tant que root. Le code ressemble à ça :
J'avais lu ça pour la commande nmap ou ping qui ouvre un socket RAW. J'ai plus les détails en tête.
Après, il faudrait faire progresser Hurd pour avoir un OS qui gêre correctement les droits ;-)
@+ Haypo
[^] # Re: C'est normal
Posté par nikitae . Évalué à 4.
c'est faisable sous bsd et sous linux
ca permet en cas d'attaque réussie de ne donner les droits d'admin qu'à une partie minimale ..
le "pirate" n'obtient plus tous les pouvoirs sur tous l'os
je vais peut-etre trop m'avancer,mais en copiant les log via la crontab,(apres avoir chrooter)
tu as une sauvegarde .
et le pirate en question ne sait pas y accéder.(beaucoup moins facilement, en tout cas)
un moyen d'expliquer le "trou de sécurité" que tu as remarqué, ploum:
-il y a moyen de faire avec ,donc passons à autre chose
ou
-pas moyen de faire autrement..etc
c'est intrinséque à un noyau monolythique.
seul hurd et équivalent pourraient te permettre de faire autrement(mais je sors du sujet)
[^] # Re: C'est normal
Posté par Victor STINNER (site web personnel) . Évalué à 4.
J'ai entendu que chroot n'était pas très fiable, et se contournait "facilement" (encore une fois désolé, j'en sais pas plus). Mais que par contre, "jail" (l'équivalent FreeBSD) est bien plus robuste.
De plus FreeBSD offre aussi systrace pour contrôler les appels systèmes. Tiens, je vois que ça existe aussi pour Linux.
Enfin, la sécurité, c'est toute une science. Plus j'en apprend, plus ça me fait tourner la tête. Dernier article choc : Comment retrouver une clé privée RSA lors d'un chalenge SSL (en réseau local) selon le temps mis par le serveur pour répondre ...
Faut aller voir du côté de SELinux, OpenBSD, TrustedBSD & Cie.
Haypo
[^] # Chroot ..
Posté par ~ lilliput (site web personnel) . Évalué à 4.
http://www.miscmag.com/articles/index.php3?page=1008(...)
voila bonne lecture :)
ma remarque est que tu peux lancer apache sur un port 88888 et faire une regle iptable du port 80 sur le port 88888 ou un proxy (ca mange pas de pain de vérifier les tentative d'overflow par url ou tout autre injection sql... )
voila c t mes 2 sous :)
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Chroot ..
Posté par Sébastien Koechlin . Évalué à 2.
Les distributions n'étant pas prévues pour, il faudra faire attention à modifier le script de démarrage pour lancer apache sous un autre utilisateur et faire attention aux droits d'accès dans les répertoires de logs et aux CGI s'ils étaient exécuté sous l'ID de l'utilisateur propriétaire.
[^] # Re: Chroot ..
Posté par ~ lilliput (site web personnel) . Évalué à 1.
toutes mes excuses ;)
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: C'est normal
Posté par doublehp (site web personnel) . Évalué à 2.
renseigne toi sur vserver/vhost. C est bien plus secure que chroot, ca consomme moins de ressource, et ca a un potentiel de failles de secu bien moindre. C est utilise en prod par Ikoula.
Pour les logs, je voudrais mettre en place un server avec XFS qui ait une archive de son journal sur NFS.
Enfin, si tes logs se font effacer, tu peux toujours arreter bruptalement la machine, et lancer un CD de rescue recovery pour retrouver les inodes suprimes ... ce qui permet a terme de reconstruire les fichiers.
Mais j essaye aussi d imagire un system ou les fichiers ne soient qu inscriptibles ( illisible et inefacables) [cela uniquement pour un user precis] ... mais je manque encore d experience et de knowledge pour dev un truc. -> si vous avez des pistes ...
[^] # Re: C'est normal
Posté par ~ lilliput (site web personnel) . Évalué à 1.
https://linuxfr.org/tips/102.html(...)
je sais qu'il y'a un truc avec le noyeau (genre une option) qui fait que tu peux pas une fois le flag changer remodifier le tag en question sans rebooter.. voila faudrait pousser la recherche un peu plus loin j'ai pas retrouver.. peut etre un howto sur debian sur la secu ..
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: C'est normal
Posté par Nico C. . Évalué à 2.
Mais j essaye aussi d imagire un system ou les fichiers ne soient qu inscriptibles ( illisible et inefacables) [cela uniquement pour un user precis] ... mais je manque encore d experience et de knowledge pour dev un truc. -> si vous avez des pistes ..."
envoyer les logs a un syslogd sur une autre machine.
1er interet : les logs sont deportes
2e interet : les logs sont geres avec les droits que l'on veut comme on veut sans s'occuper des services qui les generent.
[^] # Re: C'est normal
Posté par Nicolas Bernard (site web personnel) . Évalué à 3.
--> risque de perte de paquets donc d'entrées manquantes
--> risque de flooding
Syslog en réseau est intéressant, mais en plus de logs locaux, ou bien on peut utiliser un truc genre socklog, avec authentification par ipsec...
pour ce qui est des flags des fichiers, il y a l'attribut 'a', qui empêche l'écriture ailleurs qu'à la fin, mais c'est ext-dependant. Pour les utilisateurs de *BSD, il y a des options similaires (chflags(1)) qui sont encore plus intéressantes si coupléee avec les securelevels (non changeables même par root sans rebooter en gros). Attention cependant à la rotation des logs!
[^] # Re: C'est normal
Posté par dawar (site web personnel) . Évalué à 4.
-->[]
[^] # Re: C'est normal
Posté par Nicolas Bernard (site web personnel) . Évalué à 3.
[^] # Re: C'est normal
Posté par riri le breton (site web personnel) . Évalué à 1.
L'impression est surement la meilleure forme de logs; avec une bonne vieille imprimante matricielle et du papier au kilomètre, on peut gérer des semaines de logs.
Le seul problème, c'est l'archivage des logs, il faut des placards, des classeurs de rangement par date et/ou par catégorie.
[^] # Re: C'est normal
Posté par ckyl . Évalué à 4.
Reliable delivery for Syslog : http://www.faqs.org/rfcs/rfc3195.html(...)
Peu de démon le supporte pour le moment. Seul un patch FreeBSD pour syslogd existe pour supporter syslog-sign à ma connaissance. Je suis en train d'implémenter le tout dans le cadre d'un projet de fin d'année.
Autrement en attendant tu fais comme tout le monde et tu mets ca dans un tunnel SSL et pas de problème de flood ou d'auth !
Pour finir rapidement
-> chroot : robuste avec grsec
-> vserver : 10K ligne de patch j'aurais pas top confiance :-)
-> jails : des limitations
Et pour le remontage en root de ton user www tu as vu le nombre de failles locales de linux au cours des derniers mois ? Si tu te trouves dans le process une fois qu'il a baisse ses privilèges tu ne peux pas retourner root autrement ca ne servirait a rien.
On peut noter aussi qu'il existe pas mal de solutions pour permettre à une UID de binder un port particulier. Qu'on se le dise le modèle DAC UNIX est mort et à enterrer. Il serait temps de passer à des choses un tantinet plus puissantes, le reveil va être difficile pour quelques uns mais on est plus en 1980 !
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac-porta(...)
http://www.intercode.com.au/jmorris/selinux-networking-lj.html(...)
http://www.grsecurity.net/gracldoc.htm(...)
[^] # Re: C'est normal
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
Concernant ton implémentation de syslog-sign: sur quelle plateforme? ce sera disponible comment? etc.
[^] # Re: C'est normal
Posté par ckyl . Évalué à 2.
Chiant a l'admin, c'est pas encore assez intégré pour être agréable. Limitation sur les IPs et protection assez limité contre les DoS & co. A priori si tu te sers des jails pour virtualiser du service (par exemple donner le root a tes heberges) t'aimerais qu'ils ne puissent pas plomber toute la machine...
Y'a quelques autres problèmes. Pour les liens regarde les posts "récent" sur freebsd-hackers
> sur quelle plateforme? ce sera disponible comment?
Metalog et ca sera dispo quand ca sera pret :-)
J'espère d'ici septembre au plus tard.
Si tu preferes syslogd alors il faut juste patcher, voir http://sourceforge.net/projects/syslog-sec/(...) . Pour syslog-ng y'a rien a ma connaissance.
[^] # Re: C'est normal
Posté par sk . Évalué à 1.
Perso, je reste plutôt partisan de la solution du vserver (c'est simple à mettre en place et ca ouvre pas mal de possibilités au niveau administration).
J'en profite pour lancer une question qui me taraude depuis pas mal de temps. Je sais bien que ports <1024 ne peuvent être ouverts qu'avec les privilèges root, afin déviter que n'importe quel utilisateur puisse lancer les services standards. Cependant, l'impact d'une compromission sur ces services là a des effets plutôt moches (même si maintenant la plupart sont capables d'abandonner les capacités de l'utilisateur root une fois qu'ils se sont initialisés). Pourquoi cette limitation perdure-t-elle ? Est-ce pour une question de conformité POSIX ?
[^] # Re: C'est normal
Posté par ckyl . Évalué à 1.
J'ai pas regardé en détail ce que fait grsec sur ce point. Mais de toute facon les jails FreeBSD on quand meme des problemes pour les rendre reellement utilisables. C'est domage que ca traine depuis si longtemps :-)
> Pourquoi cette limitation perdure-t-elle ?
Le mamouth, l'elephant, la compatibilité. Faut bien voir qu'un système qui à des utilisateurs peut difficilement se permettre de casser 20 ans de compatibilité :-)
Des solutions existent, cf mon post au dessus
> Est-ce pour une question de conformité POSIX ?
Non
http://www.opengroup.org/onlinepubs/009695399/functions/bind.html(...)
# re
Posté par Djouxxx . Évalué à 1.
Donc on a besoin d'être root pour la connexion mais les services actuels sont souvent prévu pour diminuer (dropper) leurs privilèges une fois la connexion établi. Ils passent ensuite la main à un process disposant de moins de droits (sous utilisateur nobody par exemple) pour le reste de la session. Le process écoutant est généralement très simple et donc facile à sécuriser efficacement. Il est donc très difficile de lui faire faire quoi que ce soit de non-prévu.
Il faut voir ce process dédié à la communication réseau comme une couche de sécurité supplèmentaire. C'est très répandu comme concept.
# faille
Posté par Florent Bayle (site web personnel) . Évalué à 2.
Il suffit en général d'aller faire un tour sur http://www.k-otik.com/(...) pour s'en convaincre.
Tiens, par exemple à l'heure actuelle je vois ça sur le site (à peine 4 jours qu'elle est référencée) : "Linux Kernel 2.6.x ISO9660 Filesystem Handler Vulnerability" ["(...) elle pourrait être exploitée par des attaquants locaux afin de conduire des attaques par Déni de Service ou potentiellement obtenir des privilèges élevés."].
C'est pour ça qu'il est absolument indispensable d'avoir une machine toujours à jour.
[^] # Re: faille
Posté par polux14 . Évalué à 2.
Il faut surtout ce tenir au courrant quand on a des services qui tournent sur ses machines et savoir les stoper (ou les corriger a la main) dès qu'une faille est découverte.
[^] # Re: faille
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Et là, grosse grosse erreur, je l'ai pas désinstallé. Du coup je savais même pas que j'avais encore ça sur la machine.
Mais bon, ce genre d'erreur, on le fait une fois dans sa vie...
Mes livres CC By-SA : https://ploum.net/livres.html
# Comment se faire hacker avec awstat
Posté par Mathieu Feulvarc'h . Évalué à 3.
http://blog.metabaron.net(...)
Pour résumer le post que je vais faire aujourd'hui, awstat a un feature (pouvoir mettre a jour les stats a partir d'un browser) que l'on peut supprimer. Le problème est que cette feature est toujours présente même si on l'enlève et permet d'exécuter du code sur la machine.
Mon "envahisseur" a fait un simple wget de son script perl puis il l'a execute ...
[^] # Re: Comment se faire hacker avec awstat
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 4.
/var/log/apache/*.log { weekly missingok rotate 52 compress delaycompress notifempty create 640 root adm sharedscripts prerotate /root/bin/awstats_buildstaticpages.pl \ -config=nicoe.nutellux.ath.cx \ -dir=/home/nicoe/cherrypy/static/stats \ -update endscript Vala ...[^] # Re: Comment se faire hacker avec awstat
Posté par Mathieu Feulvarc'h . Évalué à 1.
PS: on peut se tutoyer non ? :)
[^] # Re: Comment se faire hacker avec awstat
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 2.
PS: on peut se tutoyer non ? :)
Bien sûre, le "vous" n'était là que pour vous mettre dans le même panier ploum et toi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.