Urban

Faut aussi un chown avec le user utilisé par php. Si le repertoire apartient à root (par exemple) et que php se lance en nobody (par exemple également) le 755 ne fonctionnera pas.

Pour vérifier les failles accessible de l'extérieur, nessus. Pour detecter les intrusions snort. Mais dans les deux cas ça génère pas mal de false positive et demande des connaissances en sécu pour l'analyse.

Tu passe par une url en https://... qui pointe vers ta page de login au lieu d'une en http://...

C'est plus ou moins bidon cet article. Déjà ils mélangent un peu vers (qui se recopient via le net en exploitant des failles sur les services ouverts) et virus. Et ensuite ils veulent alarmer en disant que quelques chose est nouveau alors que ça existe depuis toujours. Par exemple slapper qui infectait les linux + apache + mod_ssl il y a quelques années. La parade c'est de minimiser les ports ouverts et de surveiller les upgrades, principalement de apache / mod_ssl / openssl / ssh car il y a souvant des exploits sur ces packages. Tu peux le faire à la main (mais tu peux zaper des trucs par exemple l'article parle du cas de xml pour php) ou en utilisant un outil style nessus pour detecter les mises à jour nécessaire (mais faut un peu connaitre parce qu'il te sort des fausses alertes). Pour ssh tu peux aussi limiter l'ip source si tu as une ip fixe. Le risque de vers est moindre sous d'autres unix mais ça n'empeche pas de patcher également. D'autant qu'il n'y a pas que les vers. Et qu'avant même l'existance du web, il y a déjà eu des problèmes de vers sur le net qui infectaient d'autres os (par exemple le ver de morris qui infectait vax / bsd / sun) Pour ce qui est des attaques php (type sql injection, execution de code, ...), elles peuvent potentiellement fonctionner sur tous les systèmes, et la ça depend de ton code ou des scripts que tu as installé (la aussi faut surveiller les patchs).

Effectivement. Je disais juste que ça n'étais pas à quelques jours pret.

Dans le package source de mysql tu as un répertoire "support-files" Dedans tu trouveras des fichiers de conf tout fait selon tes besoins : my-huge.cnf.sh my-innodb-heavy-4G.cnf.sh my-large.cnf.sh my-medium.cnf.sh my-small.cnf.sh Dans ton cas le dernier est surement ce qu'il te faut, sauf si ça ralenti trop tes pages basée sur sql. Sinon tu auras matière pour t'inspirer

La mise à jour n'est pas super urgente, vu qu'il n'y a pas encore d'exploit de sorti. Par contre il y a des problèmes potentiels de remote execution et de sql injection donc vaut mieux ne pas trop attendre non plus qu'un petit malin sorte l'exploit. D'autant que généralement quelques semaines après ce genre d'exploit, arrive un ver associé (comme Santy l'an dernier).

C'est loin d'être fini, plus des 3/4 du site n'est pas en cache sur google, ou alors en cache avec des anciennes url et les nouvelles sont en duplicate. J'ai mis des 301 mais avec Jagger je n'ai pas eu de gros crawl depuis plus d'un mois (j'ai l'impression que c'est l'inverse sur les gros sites). Mais il est en fin de première page (ou en début de 2eme sur un data J3), et je me dis que c'est plus qu'une question de temps pour continuer de progresser. Je laisse les choses suivrent leur cours maintenant... EDIT: Forcement tu as 1.5M de sites qui repondent pour ta requete phare, je suis dans des domaines moins concurentiels, je crois que ça explique la différence de temps.

En fait ça fait 3 mois que je m'occupe de cela, grace au hub et à d'autres sites, et depuis jagger2 je commence à en voir les résultats.

Sans ssl les mots de passe (et tout le reste) passent en clair sur le réseau, enfin en base64 pour les mots de passe htaccess, mais un base63 decode suffit. Avec ssl il faut également utiliser une système de sécurité par formulaire ou htaccess, mais ça passe en crypté sur le réseau. Si de plus tu as un certificat non self-signé, ça offre une signature numérique. Cela garanti que ton site est bien ton site et non quelqu'un qui se fait passer pour le serveur.

Oui la commande site: fonctionne à nouveau à la mode Jagger3 sur le datacenter donné par Matt Cutts. Et les résultats de recherche sont différents de Jagger3 premier du nom et pour ma part moins farfelus que les résultats en Jagger3 v1.

Le serveur et le switch sont-il configuré de la même manière au niveau speed/duplex ? Parce que les lenteurs sur une interface non chargée ça peut être lié à ça.

J'étais tombé sur ce sujet il y a 2 mois, mais je ne me souvenais plus que la discution était aussi affirmative sur le fait que le user agent en mozilla n'indexe pas. Sur mon site qui est peu crawlé (ce qui me permet de suivre plus facilement ce qu'il se passe, en même temps comportement pour le crawl des gros sites est surement assez différent), Googlebot "normal" crawl la homepage une fois ou deux par jour. Et fait un gros crawl de 50-100 pages tous les 15 jours. Il fait ça de façon méthodique, par profondeur, commence par la structure du site (menu, ...), puis les pages linkées... Parfois il prend regulièrement une page toute les 5 minutes, avec à chaque fois une ip différente. Le Googlebot mozilla utilise la même ip plusieurs jours de suite, et prend quelques pages tous les jours mais des façon visiblement assez aléatoire (il crawl un peu comme slurp je trouve). Enfin ça c'était entre Jagger 1 et avant le début de Jager 3. En temps normal, il crawl très rarement. Comme il prend des pages qui ne sont pas forcement dans l'index, je ne comprend pas trop son utilité.

A ma connaissance, il y a deux agents googlebot connus : - Googlebot/2.1 (+http://www.google.com/bot.html) - Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) Jusqu'a Jagger1, je n'avais pas beaucoup de visites du second. Par contre j'ai eu un bon paquets de requètes avec cet agent entre Jagger1 et le début de Jagger3, depuis j'observe un retour à la normale. Je me demandais à quoi pouvait bien servir cet agent. Je ne le sais bien entendu toujours pas ;-), mais j'ai l'impression qu'il ne sert pas à indexer les pages. En effet, il a pris des pages qui ne sont pas dans l'index google. Quand c'est le googlebot "normal" qui le fait, 2-3 jours après, les pages sont dans l'index. La, les pages ne le sont toujours pas après 15 jours. J'avais déjà vu l'hypothèse qu'il servait à detecter le cloacking (uniquement sur l'agent vu qu'il est sur la même plage d'ip, ce qui n'est pas très malin). Mais dans ce cas pourquoi prendrais-t'il des pages qui ne sont pas encore indexé ? Je me rend compte que mon message aporte plus de questions que de réponses, mais bon ;-)

Pour moi aussi ça a bougé aujourd'hui. Sur le datacenter donné par Matt Cutts (66.102.9.104), mon site qui est en fin de première de façon stable depuis Jagger2 sur google.fr était en page 3 sur 66.102.9.104, et l'ancienne adresse du site (avec 3 fois moins de backlinks et une seule page avec un lien vers le nouveau site) était en page 2 ! Aujourd'hui la bonne adresse se retrouve en page 2. Aussi le résultat de la requete site: qui classait les pages encore hier semble ne plus les classer. Cette requete donne des résultat assez étranges par moments en resortant des pages qui n'existent plus depuis 1 an... Par contre sur google.fr le seul changement depuis le début de Jagger3, c'est a un moment, l'ancienne url qui a remplacé l'actuelle à la même position ! Mais ça ne se produisait pas tout le temps (surement le rrdns) et ça n'est pas resté longtemps.

Salut J'ai 33 ans, j'ai commencé à faire mon premier site perso à l'époque de mygale (il doit y avoir pas loin de 10 ans), je parcours le Hub depuis quelques mois. Je suis plutöt unix / sécurité, et je ne m'étais jamais penché avant cela aux aspects plus "poussés" du webmastering, j'étais plus un "bricoleur du web" qui mélange les css, les mises en page tableaux, et les balises center Mais je me soigne doucement C'est surtout le coté référencement qui m'interesse en ce moment, pour l'instant juste pour le fun.