Messages etranges

Manu wrote:

Deux "petites" choses étranges aujourd'hui dans mes logs (linux).

D'abord ces deux lignes:
martian source 81.56.208.110 from 192.168.0.250, on dev ppp0
ll header: 45:00:00:38

Premièrement je n'ai pas de device ppp0, et après vérification je n'ai
personnellement compilé le support PPP dans le noyau. Si je me suis fait
attaqué, cette histoire me fait penser à la mise en place d'un tunneling.
C'est facile à vérifier tout de même non ?

Deuxièmement 81.56.208.110 se résoud en perso.guzu.net, qui est
effectivement le nom de ma machine mais pas sa réelle adresse IP. Je
n'est effectivement pas pris la peine de configurer le reverse chez
Free, mais à une époque je l'avais fait mais je suis incapable de me
souvenir si 81.56.208.110 était effectivement mon adresse (dans ce cas
Free a peut-être oublié de supprimer cette association à ma résiliation).
Mouais, pas clair. Manque des infos.

Quelle est l'adresse alors (ifconfig) de l'interface externe, perso.guzu.net
ne correspondant pas à 'adresse mentionnée ?
Et que représente l'adresse 192.168.0.250 ? La patte interne du routeur ou
une autre machine du réseau local ?
Si ce n'est ni l'un ni l'autre, une table de routage et un tcpdump nous
renseigneront sur la destination des paquets vers cette machine.
Un ifconfig -a nous reneignera également sur les interfaces réellement
disponibles.

db

--
email : usenet blas net

Dominique Blas wrote:

Premièrement je n'ai pas de device ppp0, et après vérification je n'ai
personnellement compilé le support PPP dans le noyau. Si je me suis fait
attaqué, cette histoire me fait penser à la mise en place d'un tunneling.

C'est facile à vérifier tout de même non ?

Comment ça ?
J'ai passé un coup de chkrootkit sans succès.

Quelle est l'adresse alors (ifconfig) de l'interface externe, perso.guzu.net
ne correspondant pas à 'adresse mentionnée ?

perso.guzu.net => 82.230.37.160 : ça c'est OK
81.56.208.110 => perso.guzu.net : pas normal, c'est une usurpation ou
une erreur de Free (car 81.56.208.110 fait partie du pool de chez Free).

Mais autant 192.168.0.250 que 81.56.208.110 n'ont rien à faire dans mes
logs surtout que je n'ai pas d'interface ppp0.

Et que représente l'adresse 192.168.0.250 ? La patte interne du routeur ou
une autre machine du réseau local ?

Ça ne représente rien justement. C'est juste dans la plage d'IP du
réseau interne qui se compose de 2 machines maximum (c'est à la maison).

Si ce n'est ni l'un ni l'autre, une table de routage et un tcpdump nous
renseigneront sur la destination des paquets vers cette machine.

Je n'ai pas de trace tcpdump car je viens juste de m'en apercevoir.
Mais je vais pas tarder à sniffer pour voir ce qu'il s'y passe.

Un ifconfig -a nous reneignera également sur les interfaces réellement
disponibles.

Si ça peut te faire plaisir (j'ai supprimé les stats et les infos hard):
eth0 Link encap:Ethernet HWaddr 52:54:00:E4:9B:59
inet addr:82.230.37.160 Bcast:82.230.37.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1

eth1 Link encap:Ethernet HWaddr 00:40:05:40:B9:FA
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

eth2 Link encap:Ethernet HWaddr 00:50:FC:26:76:5C
inet addr:192.168.0.1 Bcast:192.168.0.31 mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

82.230.37.160 : vers Internet (Freebox).
192.168.0.1 : réseau interne
10.0.0.1 : réseau Wifi avec WPA et une clé en TKIP assez longue
(accès aux mêmes services accessibles depuis Internet +
POP3 + accès direct à Internet).

Mais je ne pense pas que cela fasse avancer le schmilblic.
De plus je n'ai pas remarqué de comportements anormaux (signe d'un bon
rootkit :) ). Le volume entrant ou sortant ne semble pas anormal non
plus (mais il est mesuré en local).

Seul un scan réseau pourrait m'aider j'ai l'impression. Vous avez des
conseils à ce niveau là ?

Est-ce que je peut enregistrer toutes les trames avec tcpdump et les
réinjecter facilement dans un utiltaire qui permettrait de trier les
paquets en réunissant les paquets d'une même session TCP, par exemple ?
Et qui disposerait de filtres pour éliminer le bruit lié aux vers et
autre P2P ? Ethereal permet certaines choses mais je n'ai pas regardé
depuis un moment.

Merci.

Manu wrote:

Deux "petites" choses étranges aujourd'hui dans mes logs (linux).

D'abord ces deux lignes:
martian source 81.56.208.110 from 192.168.0.250, on dev ppp0
ll header: 45:00:00:38

Je crois que j'ai super honte sur le coup :)
J'ai fini par trouver l'origine. J'ai un fichier de log qui datait d'il
y a 1 an et qui n'est pas dans la rotation de log. La date dans le
fichier de log ne faisant pas apparaitre l'année je me suis fait eu
(faut bien trouver un coupable :) ).

A+ pour de nouvelles aventures truculentes.

Manu wrote:

Dominique Blas wrote:

Premièrement je n'ai pas de device ppp0, et après vérification je n'ai
personnellement compilé le support PPP dans le noyau. Si je me suis fait
attaqué, cette histoire me fait penser à la mise en place d'un tunneling.

C'est facile à vérifier tout de même non ?

Comment ça ?
J'ai passé un coup de chkrootkit sans succès.

Quelle est l'adresse alors (ifconfig) de l'interface externe,
perso.guzu.net ne correspondant pas à 'adresse mentionnée ?

perso.guzu.net => 82.230.37.160 : ça c'est OK
81.56.208.110 => perso.guzu.net : pas normal, c'est une usurpation ou
une erreur de Free (car 81.56.208.110 fait partie du pool de chez Free).
Ni l'un ni l'autre, la demande a dû être formulée, jadis, d'associer ladite

adresse à ce nom. Ensuite, il y a dû y avoir déménagement (de l'ancien
emplacement à l'observatoire).
S'il s'agit vraiment d'une erreur la reporter à proxad.

Au fait, la seconde ligne du journal qui indique l'adresse MAC source (d'où
provient le paquet qui n'a rien à faire sur l'interface) ; cette adresse
MAC est incomplète dans votre post (il manque 2 octets) et s'agit-il
toujours de la même ?

Mais autant 192.168.0.250 que 81.56.208.110 n'ont rien à faire dans mes
logs surtout que je n'ai pas d'interface ppp0.
Je n'ai pas connaissance que le noyau raconte des conneries et invente des

interfaces dans ses messages.
D'aucuns ont peut-être déjà rencontré ce phénomène. Google ne donne rien à
ce sujet.

Et que représente l'adresse 192.168.0.250 ? La patte interne du routeur
ou une autre machine du réseau local ?
(...)

Un ifconfig -a nous reneignera également sur les interfaces réellement
disponibles.

Si ça peut te faire plaisir (j'ai supprimé les stats et les infos hard):
eth0 Link encap:Ethernet HWaddr 52:54:00:E4:9B:59
inet addr:82.230.37.160 Bcast:82.230.37.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1

eth1 Link encap:Ethernet HWaddr 00:40:05:40:B9:FA
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

eth2 Link encap:Ethernet HWaddr 00:50:FC:26:76:5C
inet addr:192.168.0.1 Bcast:192.168.0.31 mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

C'est tout ? J'ai demandé un ifconfig -a hein ?

Pas une seule interface gre, irlan, sit ?
Et un cat /proc/net/dev donne quoi ?

Mais je ne pense pas que cela fasse avancer le schmilblic.
De plus je n'ai pas remarqué de comportements anormaux (signe d'un bon
rootkit :) ). Le volume entrant ou sortant ne semble pas anormal non
plus (mais il est mesuré en local).
Oui mais ça ... il peut être dormant.

Seul un scan réseau pourrait m'aider j'ai l'impression. Vous avez des
conseils à ce niveau là ?
Commencez par scanner l'interface WiFi.

Est-ce que je peut enregistrer toutes les trames avec tcpdump et les
réinjecter facilement dans un utiltaire qui permettrait de trier les
paquets en réunissant les paquets d'une même session TCP, par exemple ?
Oui, Ethereal ou tethereal en mode texte (qui réclame tout de même les bib

gtk+) mais la syntaxe de filtrage est différente de celle de la bib pcap
(tcpdump).

db

--
email : usenet blas net

Manu wrote:

Manu wrote:

Deux "petites" choses étranges aujourd'hui dans mes logs (linux).

D'abord ces deux lignes:
martian source 81.56.208.110 from 192.168.0.250, on dev ppp0
ll header: 45:00:00:38

Je crois que j'ai super honte sur le coup :)
J'ai fini par trouver l'origine. J'ai un fichier de log qui datait d'il
y a 1 an et qui n'est pas dans la rotation de log. La date dans le
fichier de log ne faisant pas apparaitre l'année je me suis fait eu
(faut bien trouver un coupable :) ).
C'est la raison pour laquelle je suis le seul à t'avoir répondu : ton

message semblait vraiment trop louche à tous les autres contributeurs
potentiels !

db
--
email : usenet blas net

Dominique Blas wrote:

Au fait, la seconde ligne du journal qui indique l'adresse MAC
source (d'où

provient le paquet qui n'a rien à faire sur l'interface) ; cette adresse
MAC est incomplète dans votre post (il manque 2 octets) et s'agit-il
toujours de la même ?

Oui, il manque 2 octets si on parle d'une adresse MAC Ethernet, mais
c'était du PPP...

Je n'ai pas connaissance que le noyau raconte des conneries et invente des
interfaces dans ses messages.

Je ne dis pas le contraire, j'avais seulement fait la supposition d'un
rootkit qui viendrait avec son module capable de faire du tunneling.

C'est tout ? J'ai demandé un ifconfig -a hein ?
Pas une seule interface gre, irlan, sit ?

Nan nan rien de tout ça. J'ai juste retiré la boucle locale.
J'ai épuré mon système.

Oui, Ethereal ou tethereal en mode texte (qui réclame tout de même les bib
gtk+) mais la syntaxe de filtrage est différente de celle de la bib pcap
(tcpdump).

J'en profite pour continuer sur ce sujet.

Supposons que j'ai enregistrer une journée de trafic par tcpdump.
Au cours de l'analyse il y a énormément de bruit (requete netbios, vers,
NTP, ...) et avant une analyse plus pr'ecise je voudrais éliminer un peu
de ce bruit. J'ai l'impression que quelquechose comme:
tcpdump -r traffic -w - udp port 123 | tcpdump -r - -w traffic.clean
est possible pour éliminer le trafic NTP (je peux pas essayer pour
l'instant).

Ensuite avec ethereal je peux marquer suivre un flux et marquer les
paquets pour trier petit à petit le grain de l'ivraie.
Comment faites vous pour analyser un volume moyennement important de
données ? C'est le genre de cas qui peut se présenter lorsqu'on demande
à Snort de logger tout les paquets. On se retrouve avec un volume assez
important de trafic qu'il faut analyser.

Merci

Manu wrote:

Dominique Blas wrote:

Au fait, la seconde ligne du journal qui indique l'adresse MAC
source (d'où

provient le paquet qui n'a rien à faire sur l'interface) ; cette adresse
MAC est incomplète dans votre post (il manque 2 octets) et s'agit-il
toujours de la même ?

Oui, il manque 2 octets si on parle d'une adresse MAC Ethernet, mais
c'était du PPP...
En PPP c'est plus long encore.

Je n'ai pas connaissance que le noyau raconte des conneries et invente
des interfaces dans ses messages.

Je ne dis pas le contraire, j'avais seulement fait la supposition d'un
rootkit qui viendrait avec son module capable de faire du tunneling.
Et créerait justement le nom ppp0 ? A mon avis si le module ppp n'est pas

chargé ce rootkit créerait plutôt une interface Ethernet question de passer
inaperçu.

(...)

Supposons que j'ai enregistrer une journée de trafic par tcpdump.
Au cours de l'analyse il y a énormément de bruit (requete netbios, vers,
NTP, ...) et avant une analyse plus pr'ecise je voudrais éliminer un peu
de ce bruit. J'ai l'impression que quelquechose comme:
tcpdump -r traffic -w - udp port 123 | tcpdump -r - -w traffic.clean
est possible pour éliminer le trafic NTP (je peux pas essayer pour
l'instant).
Euh, la libpcap dispose d'une syntaxe élaborée tout de même hein ?

Si on admet que rien n'a été filtré lors de l'enregistrement une commande du
style
tcpdump -r trafic not port 123
suffit, ou s'il s'agit de supprimer uniquement les communications ayant lieu
sur le udp/123 et ce, quel que soit le sens :
tcpdump -r trafic not ( udp and port 123 )
les paranthèses étant nécessairement échappées si c'est ne ligne de
commande.
Enfin, bon sang, il y a une doc de tcpdump !

db

Ensuite avec ethereal je peux marquer suivre un flux et marquer les
paquets pour trier petit à petit le grain de l'ivraie.
Comment faites vous pour analyser un volume moyennement important de
données ?
Cela dépend pour quoi faire.

S'il s'agit de résultat d'analyse (via libpcap ou autre chose) un jeu de
scripts lançant des tcpdump bien sentis.

Mais s'il s'agit uniquement d'effectuer une évaluation protocolaire on passe
à l'analyseur d flux (Netflow chez Cisco).

db
--
email : usenet blas net