Hum, laisse moi te dire que je ne place pas ceci sur le même plan...
Je parle en connaissance de cause, un copain m'a montré comment on fait.
Comment dire, entre se fabriquer une ferme de zombi et hacker un serveur linux, c'est pas la même chose...
Dans un cas tu dois gravir plusieurs échelons, dans l'autre tu t'attaque a une faille non corrigée (même connue) et tu va zombifier des centaines de machines.
Enfin les serveurs linux ça se craque aussi, mais bon c'est vraiment la faute de l'admin !
J'ai eu l'occasion d'avoir une démonstration sur les dédibox et bien la sécurité y en a pas...
Comme quoi, dans un cas c'est le système qui est pas fiable, dans l'autre c'est la faute de l'admin !
Pour les vecteurs d'attaque, en général l'échelon 1 est uploader un script php ou ruby qui va permettre d'avoir un pseudo-shell.
L'échelon 2 est accéder a un compte ssh, pour ça on va casser en brute force tout les mots de passe dispo dans des htpasswd et autre lisibles
L'échelon 3 on essaye de passer root (sudo, suid, ou kernel vulnérable)
L'échelon 4 on maquille le tout
Bon pour vous protéger :
- NE LAISSEZ JAMAIS LISIBLE par l'user sous lequel les script php tournent les fichiers contenant des mots de passe
- utilisez des mot de passe random pour les accès a la base de donnée sql
- ne jamais utiliser un mot de passe pour le compte unix utilisé dans une base sql (sinon ils auront qu'a faire un coup de john et ils ont l'accès ssh)
- ne pas mettre une pubkey pour ssh dans son home
(si ils obtiennent le compte unix, un accès ftp, pop ou autre c'est game over)
- ne pas mettre de sudo root (ou alors le désactiver automatiquement a la déconnexion)
Bon je vais être honnête, avant je pensais qu'un linux c'était sur, depuis que j'ai vu ça de mes propres yeux j'ai un tout autre avis.
(J'ai notamment fait une opération séparation des privilèges depuis...)
[^] # Re: Pour quel effet...?
Posté par Raphaël G. (site web personnel) . En réponse au journal Colgate-spam ou le piège à spam français. Évalué à 4.
Je parle en connaissance de cause, un copain m'a montré comment on fait.
Comment dire, entre se fabriquer une ferme de zombi et hacker un serveur linux, c'est pas la même chose...
Dans un cas tu dois gravir plusieurs échelons, dans l'autre tu t'attaque a une faille non corrigée (même connue) et tu va zombifier des centaines de machines.
Enfin les serveurs linux ça se craque aussi, mais bon c'est vraiment la faute de l'admin !
J'ai eu l'occasion d'avoir une démonstration sur les dédibox et bien la sécurité y en a pas...
Comme quoi, dans un cas c'est le système qui est pas fiable, dans l'autre c'est la faute de l'admin !
Pour les vecteurs d'attaque, en général l'échelon 1 est uploader un script php ou ruby qui va permettre d'avoir un pseudo-shell.
L'échelon 2 est accéder a un compte ssh, pour ça on va casser en brute force tout les mots de passe dispo dans des htpasswd et autre lisibles
L'échelon 3 on essaye de passer root (sudo, suid, ou kernel vulnérable)
L'échelon 4 on maquille le tout
Bon pour vous protéger :
- NE LAISSEZ JAMAIS LISIBLE par l'user sous lequel les script php tournent les fichiers contenant des mots de passe
- utilisez des mot de passe random pour les accès a la base de donnée sql
- ne jamais utiliser un mot de passe pour le compte unix utilisé dans une base sql (sinon ils auront qu'a faire un coup de john et ils ont l'accès ssh)
- ne pas mettre une pubkey pour ssh dans son home
(si ils obtiennent le compte unix, un accès ftp, pop ou autre c'est game over)
- ne pas mettre de sudo root (ou alors le désactiver automatiquement a la déconnexion)
Bon je vais être honnête, avant je pensais qu'un linux c'était sur, depuis que j'ai vu ça de mes propres yeux j'ai un tout autre avis.
(J'ai notamment fait une opération séparation des privilèges depuis...)