Googlebot ?

le Sam 24 Sep 2011 09:05

Que doit-on en penser ?

Voici tout d'abord le premier type de messages d'erreurs obtenus ce matin (il y en a eu 2).

PROVENANCE : Pas de moteur reconnu. La connexion est directe.
PAGE : /xL?JxKB@?Jx::8s:Lb$
NAVIGATEUR : Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
HOTE : 66.249.72.201
IP : 66.249.72.201
NOM DE DOMAINE : crawl-66-249-72-201.googlebot.com

Et la seconde série. Il a essayé par 3 fois durant la même minute. Là je soupçonne une tentative de repiquer des adresses électroniques en vue de spams ultérieurs :

PROVENANCE : Pas de moteur reconnu. La connexion est directe.
PAGE : /contact.php
NAVIGATEUR : Microsoft Pocket Internet Explorer/0.6
HOTE : 98.129.217.212
IP : 98.129.217.212
NOM DE DOMAINE : web1.mentornet.com

Et cette série, consistant en une suite de mots (clés ?) en tout cas rencontrés sur la page support.php.

PROVENANCE : Pas de
moteur reconnu. La connexion est directe.
PAGE : /support/accentuation,apprendre
NAVIGATEUR : Java/1.6.0_04
HOTE : 92.85.46.205
IP : 92.85.46.205
NOM DE DOMAINE : 92.85.46.205

le Sam 24 Sep 2011 09:28

ça ressemble à une méthode d'aspiration de données sauf erreur de ma part

le Sam 24 Sep 2011 10:14

Bah pourquoi les trois entrées seraient elles corrèlées ?
En tous cas, la première vient apparemment d'une machine appartenant effectivement à Google, la deuxiême semble d'une société de SEO, c'est peut être une usurpation, et la dernière visite d'un isp roumain.
Qu'en penser ? Aucune idée.

le Mar 27 Sep 2011 08:48

phpDesigner a écrit:PAGE : /xL?JxKB@?Jx::8s:Lb$

Pour cette page, j'ai trouvé : c'était deux tentatives du robot de Google de lire une adresse électronique disponible sur le site, et la protection antispam a alors joué.

Ce matin, c'est encore une bizarrerie avec la tentative d'ouverture de quelque chose de bien précis, mais qui n'a jamais existé. Cet autre IP a essayé ces derniers jours de trouver des éléments d'un CMS ou d'un autre (il y avait une fois Wordpress dans le chemin de la page recherchée, une autre fois c'était un fichier de Joomla), et cette nuit c'est ça :

PROVENANCE : Pas de moteur reconnu. La connexion est directe.
PAGE : /plugins/content/a/img_10082011_214153.cpl?0.81952
NAVIGATEUR : Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.1.16) Gecko/20101130 AskTbATU3/3.9.1.14019 Firefox/3.5.16 (.NET CLR 3.5.30729)
HOTE : 208.50.101.155
IP : 208.50.101.155
NOM DE DOMAINE : 208.50.101.155

PROVENANCE : Pas de moteur reconnu. La connexion est directe.
PAGE : /plugins/content/a/img_10082011_214153.cpl?0.77859
NAVIGATEUR : Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618; Zune 4.0; .NET4.0C; Windows Live Messenger 14.0.8117.0416)
HOTE : 208.50.101.153
IP : 208.50.101.153
NOM DE DOMAINE : 208.50.101.153

le Mar 27 Sep 2011 17:26

Si je puis me permettre malgré mes maigres compétence en la matière,

Je me suis amusé à piégé fut un temps les urls bidons pour les analysés dans mon coin.

J'ai un super gros listing sur le sujet (suffit que je le retrouve).

En faite c'est pas du tout rare de trouver des urls de ce genre car c'est le début d'une attaque en général :

Le Zomb à l'autre bout de la terre recherche sur des NDD au hasard des fichiers de CMS généralement bien connu et bien ciblé, pour vérifier si y'a pas ce CMS d'installer sur le site et si il possède une faille (genre sur un template bien précis ou un "module"), tu aurais une deuxième tentative avec cette fois par exemple des paramètres en URL et tu te retrouverais avec un site vérolé en quelques secondes (je te parle même pas si tu as un FTP partagé par plusieurs domaine, là c'est tous les sites qui prendraient un coup).

Voilà pour info, ci des fois cela peut aider (même un visiteur, car je n'est pas la fausse modestie de vouloir vous apprendre quoi que ce soit), sait on jamais...

A+

le Mar 27 Sep 2011 17:54

Salut Borniol.

Que préconises-tu ?

le Mar 27 Sep 2011 18:23

Et bien,

Pour ma part j'ai privilégié un moteur bien protégé car comme j'utilise un CMS, les sources sont disponible, il est donc plus facile de travailler le code au corps pour y trouver une faille...

Cela dit, honnêtement, si tu est sûr de ta sécurité, tu n'a rien à craindre. Certaine petite chose toutes bêtes comme par exemple ne pas avoir de compte Admin sur un ID 1 car c'est fréquemment celui là qui est visé.

Je pense que ton site est multi-pays (j'ai pas regarder en profondeur, mais je suppose que le logiciel est traduit en plusieurs langues), donc tu peux difficilement virer d'office certains pays dans ton HTACCESS sans finalement perdre un client potentiel, je peux te montrer la liste des pays récurrents qui envoient ce genre d'attaque (pays de l'est et Russie number one, suivit du brésil et de la chine). Ca permet de limiter, dans la mesure où la sécurité de ton site ne serais pas optimum.

Il existe des logiciels qui testes toutes genre de faille XSS dont j'ai carrément oublié le nom qui peuvent t'aider à voir si tout est OK.

EDIT: wapity le logiciel ou un truc comme ça écrit en python.

Après pour le reste, tu peux contempler et admirer la sécurité de ton site face à ses attaques de script kiddy (pour la plupart) qui n'aboutiront jamais.

Pour la petite histoire, il y'a plus de 5 ans, le CMS que j'utilise avais une faille dans le module "jeux flash", faille une fois vue, fût corrigé (ce fut d'ailleurs la dernière faille connut).
MAis tu trouve encore certaine IP qui si il trouve KwsPHP sur ton site teste le module jeux_flash et si il le trouve tente d'utiliser cette faille.... (5 ans après quoi ), bon c'est sûr si l'utilisateur se tien pas informé des MAJ ou si il s'en fout, il le regrettera un jours.

le Mar 27 Sep 2011 18:36

borniol a écrit:(...)
les sources sont disponible, il est donc plus facile de travailler le code au corps pour y trouver une faille...
(...)
Et donc pour la corriger et diffuser la correction avant que d'autres l'exploitent.
C'est l'avantage de l'opensource.

le Mar 27 Sep 2011 18:46

Tout à fait

Surtout que la sécurité du moteur est étudier et surveiller par plusieurs développeurs ce qui évite de passer à coter de certaine failles possible, pas besoin de me prêcher les vertus des CMS je suis déjà conquis.

A+

le Mar 27 Sep 2011 18:53

phpDesigner a écrit:(...)Que préconises-tu ?

Ne pas installer le CMS dans les répertoire standards,
renommer les interfaces de config/setup une fois qu'on a fini de les utiliser,
faire toutes les mises à jour de sécurité aussi vite qu'elles sont publiées,
détecter les tentatives d'attaque répètées et les rediriger en 301 aléatoire,
etc...
Et toujours conserver une série de backups pour réinstaller une machine sure en cas de doute sur la compromission.
Plein de trucs à faire.

En moyenne, sur ma mauvaise debian à la maison qui est sur IP dynamique mais avec un domaine dyndns qui a 7/8 ans, qui ne me sert qu'au webmail, quelques ML, et à des tests, j'ai quand même une 50 aine d'attaques par jour, et je n'ai eu qu'une alerte sérieuse sur toute cette période (heureusement, justement ce jour là, je bossais sur mon apache et j'ai bloqué l'attaque dans la minute en débranchant les cables avant de corriger la faille).
Mais si je faisais attention à tous mes logs, je ne dormirais plus...
D'ailleurs c'est le conseil que je donne à notre IT qui verdit bien trop souvent je trouve.

Toute façon, quand ça passe, c'est dans les premières secondes qu'il faut réagir, et encore: à partir du moment ou c'est passé, tu ne peux plus avoir confiance en la machine, même en patchant la faille il peut y avoir des saletés installées, et il faut donc réinstaller du propre (hors connection si possible) avec la faille bouchée et des nouveaux passwd, et l'ancienne machine ne doit plus servir qu'à l'analyse post mortem.

le Mar 27 Sep 2011 19:32

Merci pour toutes ces réponses. Donc en résumé on ne craint rien.

phpDesigner n'étant pas un CMS, mais un outil permettant de créer aussi bien des CMS (entre autres choses) que des sites Internet, nous ne risquons pas de tomber dans les failles de sécurité des CMS. Qui voudrait s'amuser à aller chercher une faille qui changerait à chaque nouveau site ou application Internet ?

Reste alors la possibilité de failles PHP. Comme PHP est en Open source, s'il y avait un jour un problème avec PHP, on serait de suite informé, probablement plus vite que pour un vulgaire CMS puisque tous les CMS utilisent le PHP, et non l'inverse.

Reste enfin la possibilité de faille JavaScript dans nos écritures. Elles sont toutes bétonnées. Donc là non plus rien à craindre. Les autres langages utilisés : bof.

le Mer 28 Sep 2011 00:59

phpDesigner a écrit:Merci pour toutes ces réponses. Donc en résumé on ne craint rien.
(...)
J'ai pas dit ça moi !
Je dis juste que faut réflechir à sa protection au niveau stratégique, et qu'éplucher en détail les logs ne sert à rien, sauf à réflechir à comment en faire sortir les traces d'attaques dont on s'est déjà protègé pour y repèrer ensuite plus rapidement les nouvelles tentatives.
Un truc aussi: il n'y a pas que le http qui puisse être un point d'entrée sur machine linux, et il faut penser à installer un fail2ban sur tout les ports où écoute un service avec authentification, parcequ'il y a toujours les possibilités de bêtes attaques en brute force.

le Mer 28 Sep 2011 04:42

De toute façon protection ou non, si vraiment ton site intéresse des personnes mal-intentionnées, il sera probablement infecté, spamé, vérolé, vidé, défacé ou Ddossé (si je puis dire). La plupart des grands nom du web y ont tous été un jours victime (même Sony récemment, ou certains sites du gouvernement...).

La surveillance de logs, j'ai arrêté aussi, sinon tu attrape des palpitations toutes les heures...

Bon, par contre j'ai un script de backup journalier, comme ça au moindre problème je nettoie tous et je remets la copie après avoir consulté les logs pour voir ce qui c'est passé et corrigé le problème.

A+

le Mer 28 Sep 2011 08:23

borniol a écrit:(...)
au moindre problème je nettoie tous et je remets la copie
(...)
AMA on ne peut jamais présumer qu'une machine compromise a été nettoyée. En cas de compromission, il faut remonter une machine de zéro et remettre les configs et les sites.

le Mer 28 Sep 2011 08:52

36positions a écrit:J'ai pas dit ça moi !

Mais moi je le dis.

Les sites qui sont attaqués sont logiquement soit des sites utilisant un modèle connu (CMS célèbre, etc.) soit un site visé spécifiquement. Les sites créés avec phpDesigner ne peuvent par construction pas subir le premier point puisque chaque site créé n'obéit qu'aus seuls normes de son webmaster.

Reste la deuxième possibilité. Nous avons pris de nombreuses protections là dessus :
copie journalière de sécurité sur serveur déporté, copie en local, détection des anomalies d'écriture, scan automatique, etc. Nous imaginons mal cependant un concurrent utiliser ces méthodes d'un autre âge. Il aurait beaucoup plus à perdre si ses méthodes étaient détectées. Il préfèrera de loin la méthode financière : nous avons ainsi pu constater des pubs d'un concurrent sur la plupart de nos mots clés...

Non, les liens indiqués proviennent uniquement de notre surveillance automatique des pages 404 dans le cadre du basculement de notre site et du renommage de nos anciennes pages. Cela ne concerne actuellement que 0 à 5 pages par jour, souvent périmées depuis avril ou mai 2011, autrement dit quand nous avions ouvert le site francophone initial.

le Sam 1 Oct 2011 14:36

Tiens ! Dès fois on se demande s'ils croient vraiment qu'une tentative de prise de contrôle comme ça, ça va vraiment marcher... plusieurs essais de ces IP.

PROVENANCE : Pas de moteur reconnu. La connexion est directe.
PAGE : /flashplayer.exe
NAVIGATEUR : Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; GTB6; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 3.0.04506; Media Center PC 5.0; SLCC1; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; Orange 8.0; Windows Live Messenger 14.0.8117.0416)
HOTE : 64.124.203.77
IP : 64.124.203.77
NOM DE DOMAINE : 64.124.203.77.available.above.net

PROVENANCE : Pas de moteur reconnu. La connexion est directe.
PAGE : /tmp/gabi.exe
NAVIGATEUR : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; (R1 1.6); .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.1; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; msn OptimizedIE8;ESXL)
HOTE : 74.217.148.71
IP : 74.217.148.71
NOM DE DOMAINE : 74.217.148.71

le Dim 2 Oct 2011 10:24

Tien,

Trouvé au hasard d'une analyse des liens qui mène ou ont mené vers mon site :

h___/verticalpigeon.com/joomla/

C'est un espèce de moteur de recherche qui cherche pour toi si le site en question est un joomla...

Ce sont peut être tout simplement des "sites" dans ce genre pour la plupart de tes urls...

A+

le Lun 17 Oct 2011 11:26

Ce weekend et particulièrement cette nuit, il y a eu de nombreuses tentatives d'exécution de programmes .exe connus pour faire partie intégrante de chevaux de Troie. Comme si ça pouvait fonctionner !

Et là où on voit que certains ne doutent vraiment de rien, il y a eu également des tentatives d'appropriation de notre compte utilisateur sur différents forums : ils ont juste oublié qu'en général un forum envoie une demande de confirmation.

Ce qui amuse par contre depuis longtemps le plus le chef, c'est de voir dans les profondeurs du classement Google que notre site est parfois référencé par des annuaires... de cul.

Googlebot ?

ça ressemble à une méthode d'aspiration de données sauf erreur de ma part

Salut Borniol.Que préconises-tu ?

borniol a écrit:(...)les sources sont disponible, il est donc plus facile de travailler le code au corps pour y trouver une faille...(...) Et donc pour la corriger et diffuser la correction avant que d'autres l'exploitent.C'est l'avantage de l'opensource.

Tout à fait Surtout que la sécurité du moteur est étudier et surveiller par plusieurs développeurs ce qui évite de passer à coter de certaine failles possible, pas besoin de me prêcher les vertus des CMS je suis déjà conquis. A+

borniol a écrit:(...) au moindre problème je nettoie tous et je remets la copie (...) AMA on ne peut jamais présumer qu'une machine compromise a été nettoyée. En cas de compromission, il faut remonter une machine de zéro et remettre les configs et les sites.

Salut Borniol.

Que préconises-tu ?

borniol a écrit:(...)
les sources sont disponible, il est donc plus facile de travailler le code au corps pour y trouver une faille...
(...)
Et donc pour la corriger et diffuser la correction avant que d'autres l'exploitent.
C'est l'avantage de l'opensource.

Tout à fait

Surtout que la sécurité du moteur est étudier et surveiller par plusieurs développeurs ce qui évite de passer à coter de certaine failles possible, pas besoin de me prêcher les vertus des CMS je suis déjà conquis.

A+

borniol a écrit:(...)
au moindre problème je nettoie tous et je remets la copie
(...)
AMA on ne peut jamais présumer qu'une machine compromise a été nettoyée. En cas de compromission, il faut remonter une machine de zéro et remettre les configs et les sites.