apache sécurité

In article (Dans l'article)
<patpro-0FCC14.13355329032005@individual.net>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote
(écrivait) :

In article
<fantome.forums.tDeContes-822CD0.12341029032005@news4-4.proxad.net>,
Thomas <fantome.forums.tDeContes@free.fr> wrote:

mais est tu sur que ca me concerne ?

ben non, c'est pas ma machine, je n'ai rien vérifié moi même, je fais
juste des propositions par rapports aux symptômes décrits.

ok,
mais il y a eu une fois où ca a planté pendant que j'etais devant :
il y a eu le gribouillage des logs,
l'ecran n'est pas devenu noir, juste je ne pouvais plus rien bouger sauf
la souris

comment je fais pour savoir si j'ai des pb de perifs usb ?
(j'ai qu'une souris)

si t'as qu'une souris c'est bon. Il y'a par contre des drivers de
modems USB, et des hub USB, qui sont connus pour mettre la pagaille.

c'est expres pour ca que j'ai attendu la freebox non dégroupée pour
m'abonner à free ;-)

au fait je fais fsck à chaque fois que mon ordi plante, en sorte que le
disque soit en bon etat

normalement tu ne dois pas, c'est pris en charge par le système, avec
les options qui vont bien. Il faudra perdre cette habitude avec Panther
ou TIger.

ah bon ???
je croyais qu'il fallait le faire, parce que le systeme ne l'execute
qu'une seule fois, alors qu'on doit l'executer jusqu'à ce que le disque
soit en bon état !

et le "vLi6vLn7/Pq7PP", qu'est ce que c'est puisque c'est normal ???

meme si je suis pas tout à fait certain de ne pas avoir de pb materiel
ou de veille (puisque tu le dis),
je suppose que j'ai des attaques, parce que ce qui est dans les logs je
vois pas d'où ca pourrais venir d'autre

alors si tu raisonnes comme ça, toutes les requêtes que tu ne comprends
pas sont des attaques :)

non,
t'as sans doute pas bien vu les extraits (veux tu les logs entiers ?),

ca n'a absolument pas le format que j'ai demandé (alors que tous les
autres logs, si),
et en plus ca ne se termine pas par un retour à la ligne !!

alors moi je ne demande qu'à apprendre,
techniquement ca peut venir de quoi d'autre que d'une attaque ?

je me met à la disposition des gens qui voudraient reparer cette
nouvelle faille encore inconnue
(sauf que j'ai pas encore compilé apache chez moi, faudra m'apprendre)

Je persiste à penser que c'est une merde dans le fonctionnement de ta
machine et/ou de ton OS, je ne pense pas qu'il s'agisse d'attaque, ou
même d'une faille apache.

ah donc tu penses carrément que ca vient meme pas d'apache, mais soit du
materiel soit de l'OS ?
ca peut modifier les logs de cette facon là ??

Si tu n'as pas des milliers de requetes par jour et que tu as quelques
10n de Go de libre sur ton disque,

hou là, j'ai environ 15 000 logs pour le dernier mois, mais j'ai que 5
Go libres, que je peux pas consommer en entier, bien sur

tu peux lancer apache avec un ktrace
pour suivre son comportement de prêt, mais attends toi dans ce cas à
avoir quelques 10n de Go de log à analyser.

y a des outils pour analyser ca rapidement ?

man ktrace et man kdump pour voir comment ça marche.

ok, des que j'ai 10 min

un petit "démarrage rapide de ktrace" :

$ sudo -s
# apachectl start
# ps -auxwww | grep httpd | grep root | grep -v grep
root 1003 1 0.0 0.1 ?? 1:21PM Ss 28992 1280 ?? 0:00.03 /usr/sbin/httpd

--> 1003 est le PID parent qu'on va suivre.

# ktrace -dip 1003

et la tu laisses tourner pour que le fichier ktrace.out se remplisse
quand tu as ton compte ou que ton disque dur est plein tu désactives
ktrace par cette commande :

# ktrace -C <-- HYPER IMPORTANT, sinon ton disque explose.

est ce que ca gere automatiquement l'espace disponible, en sorte que je
puisse laisser ca tourner qq jours jusqu'à ce que ca plante, et que
j'aies automatiquement les informations sur les dernieres requettes ?

et tu lis le dump avec kdump :

# kdump -f ktrace.out | more

attention, ktrace.out grandi TRES TRES vite, il fait 3Mo chez moi alors
que le serveur n'a reçu que 3 requetes http (deux vers un CGI, une vers
une page d'erreur). Mais c'est un outil très complet qui te montrera
exactement tout ce que fait apache et les process qui dépendent de lui,
ce qu'il lit sur le disque, ce qu'il a en mémoire, ...

Tu peux t'entrainer avec ls par exemple, pour te familiariser avec le
résultat :

ktrace -di ls
kdump -f ktrace.out

je viens d'essayer, je vois le principe :-)


merci bcp pour cette partie :-)
je vais essayer :-)

--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )

"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"

In article (Dans l'article) <424a3b14$0$813$8fcfb975@news.wanadoo.fr>,
Sebastien Vincent <svincent@idems.fr> wrote (écrivait) :

je me met à la disposition des gens qui voudraient reparer cette
nouvelle faille encore inconnue
(sauf que j'ai pas encore compilé apache chez moi, faudra m'apprendre)

Tu as essayé de lancer la requete toi meme voir si ca plante ?
(ca ne devrait pas, comme disais patpro, rien d'alarmant...)

mais je ne sais pas quelle requette fais cette attaque :-)
puisque /visiblement/ le pirate recouvre le log avec n'importe quoi pour
que je saches pas d'où ca vienne

--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )

"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"

In article
<fantome.forums.tDeContes-D9F196.16014031032005@news4-4.proxad.net>,
Thomas <fantome.forums.tDeContes@free.fr> wrote:

mais il y a eu une fois où ca a planté pendant que j'etais devant :
il y a eu le gribouillage des logs,
l'ecran n'est pas devenu noir, juste je ne pouvais plus rien bouger sauf
la souris

ça met quand meme en vrac toute la machine, sauf le driver USB et le
curseur de la souris en gros ?
Dans ces conditions, à partir d'une autre machine sur le même réseau
(ton LAN ou internet), as tu des réponses si tu ping la machine, et si
oui, peux tu t'y connecter en SSH ?

Tu pourrais aussi essayer de laisser la machine en mode console.
Normalement tu tapes juste ">console" dans le champ "login" de la boite
de login, mais là je viens de foutre un OSXServer en vrac en faisant ça,
donc je vais approfondir :)))

au fait je fais fsck à chaque fois que mon ordi plante, en sorte que le
disque soit en bon etat

normalement tu ne dois pas, c'est pris en charge par le système, avec
les options qui vont bien. Il faudra perdre cette habitude avec Panther
ou TIger.

ah bon ???

A partir de panther le FS est journalisé, ça change pas mal la donne.

je croyais qu'il fallait le faire, parce que le systeme ne l'execute
qu'une seule fois, alors qu'on doit l'executer jusqu'à ce que le disque
soit en bon état !

heu, faut vraiment que ça boot plus pour avoir besoin de le faire
plusieurs fois.

alors si tu raisonnes comme ça, toutes les requêtes que tu ne comprends
pas sont des attaques :)

non,
t'as sans doute pas bien vu les extraits (veux tu les logs entiers ?),

inutile, c'est plus sur l'ensemble d'apache et de la machine qu'il faut
se pencher. Les logs en eux même n'apprendront plus rien je pense.

ca n'a absolument pas le format que j'ai demandé (alors que tous les
autres logs, si),
et en plus ca ne se termine pas par un retour à la ligne !!

c'est ce qui me fait penser a un viandage général

alors moi je ne demande qu'à apprendre,
techniquement ca peut venir de quoi d'autre que d'une attaque ?

plantage, au passage, édite /etc/hostconfig pour mettre COREDUMPS à
-YES-, et redémarre pour être sur que c'est bien pris en compte par le
système, et de temps en temps vérifie le contenu de /cores/

ls -l /cores/

ah donc tu penses carrément que ca vient meme pas d'apache, mais soit du
materiel soit de l'OS ?
ca peut modifier les logs de cette facon là ??

rien de spécial dans system.log ?

tu peux éventuellement ajouter dans /etc/syslog.conf la ligne suivante :

*.* /var/log/all.log

et relancer syslogd (en root) :

killall -HUP syslogd

ça mettra tout ce qui se passe au niveau de syslog dans un fichier
unique.

Si tu n'as pas des milliers de requetes par jour et que tu as quelques
10n de Go de libre sur ton disque,

hou là, j'ai environ 15 000 logs pour le dernier mois, mais j'ai que 5
Go libres, que je peux pas consommer en entier, bien sur

ça fait du 50 requêtes par jour, c'est raisonnable. Surtout avec
uniquement du contenu statique, le ktrace.out devrait se remplir moins
vite que dans mon test.

Ce que je te suggère c'est de le tester en live : le matin, tu lances le
ktrace, et toutes les 2-3 h tu surveilles sa taille, si tu vois que ça
tient une journée avec un peu de marge, et bien tu le lances tous les
matin, et tu le fermes tous les soirs jusqu'à ce qu'un plantage soit
intercepté.

Si ça tient pas une journée pleine, tu peux le lancer vers 15h puisque
tu dis que le problème survient souvent à 18h.

Dans le pire des cas, tu peux mettre en place un script (crontab fera ça
très bien) pour faire des ktrace d'une heure toutes les heures en
écrasant le ktrace.out précédent. De la sorte, tu conserves juste les
requêtes précédent le plantage.

y a des outils pour analyser ca rapidement ?

pas que je sache, mais de toute manière, il faudra sans doute te faire
aider avec le résultat.

# ktrace -C <-- HYPER IMPORTANT, sinon ton disque explose.

est ce que ca gere automatiquement l'espace disponible, en sorte que je
puisse laisser ca tourner qq jours jusqu'à ce que ca plante, et que
j'aies automatiquement les informations sur les dernieres requettes ?

quelques jours c'est pas raisonnable :)
quelques heures c'est déja beaucoup (mais tu n'as pas le choix si tu
veux "surprendre" un plantage.
Pour la rotation, vois comme j'ai indiqué plus haut, si ça tient un jour
sans déborder ou si ça nécessite une rotation horaire.


patpro

Thomas wrote:

mais je ne sais pas quelle requette fais cette attaque :-)
puisque /visiblement/ le pirate recouvre le log avec n'importe quoi pour
que je saches pas d'où ca vienne

Ne peux tu pas mettre une autre machine en place? Avec, au hazard :

a) un sniffer, comme ça tu verra passer ce qui fait planter ta machine
si c'est bien un paquet sur le réseau.

b) faire accepter à cette même machine les log de ton apache, en jouant
sur des paramètre supplémentaire du filesystem pour ne permettre que
l'ajout de données au fichier de log par exemple.

C'est assez simple à faire et si le crash n'est pas du à un piratage tu
aura des logs qui pourront d'avantage t'aider.

Eric.

PS : tant qu'à faire débrouille toi pour que tes deux bécanes soient
vraiment à la même heure ; pour les logs c'est plus facile.

--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.