HTACCESS Sécu pour Wordpress, Apache 2.2, Mutualisé OVH

normal, le forum utilise Markdown pour le formatage ce qui provoque certains problèmes avec certaines chaines de caractères ou caractères d'échappement.

Essaye avec la syntaxe utilisée d'habitude pour le code, à savoir le texte (ou paragraphe) entouré d'apostrophes inverses (touche 7 du clavier + ALT GR). Et sinon il y a toujours la possibilité d'utiliser pastebin ou autre ;-)

Et sinon c'est quoi le problème/la question à la base ?

Bonjour ppast.dev,

j'aimerais partager mon htaccess à la communauté OVH, pour la sécu de wordpress, sur Apache 2.2, mutualisé, ssl, et en même temps avoir des avis, des conseils, et savoir si ce que j'ai fais est correct.

Et merci pour l'info, je vais essayer de coller le htaccess avec le truc des apostrophes inverses.

Bonjour,

j'aimerais vous partager mon htaccess sécurisé pour wordpress, apache 2.2, sur mutualisé OVH avec le ssl et cdn activé, et avoir vos avis et conseil:


Edit: Bon ben désolé je n'y arrive, ce gestionnaire de forum est vraiment de la ... il détruit tout le texte et en enlève la plupart...

Sinon, si ton fichier **_.htaccess_** n'est pas trop long,
Avec le logiciel de Capture de Windows, tu fais une photo de ce fichier.
Et ensuite tu viens coller la photo ici. :p

Bonjour Gaston Phone,

il n'est pas très long mais un peu quand même, pas génial d'en faire une capture d'écran, tout comme de poster un lien pour pastebin ou autres, ça perd beaucoup de l’intérêt de partager ce htaccess ici.

Quand à OVH qui nous empêche de coller du texte brut pour nous obliger a tout faire en html, n'importe quoi...

Tant pis pour moi et pour tous ceux qui aurait pu être intéressé par ce fichier htaccess, qui me semble très bien mais qui surement mérite quelques légère corrections et ajout.

Bon week-end à tous.

tant pis :-(

Bonjour,

Sinon globalement il faut plutôt sécurisé son site a niveau du code (secu contre les exploits via injection/xss/csrf etc.) qu'au niveau du .htaccess car un .htaccess influence la vitesse de traitement de apache.

Cordialement, janus57

Salut ppast.dev,

j'ai posté le htaccess sur pastebin : https://pastebin.com/0JeS5zbd

Si ça peut t’intéresser, si tu as des rajouts ou des améliorations a faire, bienvenu :)

Bonjour Janus57,

je suis sur mutualisé, et d'après ce que j'ai compris je n'ai pas d'autres possibilité que le htaccess pour faire des modifs sécu et optimisations Apache sur cet hébergement OVH.

Oui ça a l'air pas mal.

J'ai rajouté ça pour interdire d'emblée certains pays douteux, et avec lesquels de toute façon je n'ai pas l'intention de traiter :
`
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE UA BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE SK BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE RO BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE LY BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE IR BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE EE BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE BJ BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE BY BlockCountry
`

J'ai aussi d'autres mesures (https://forum.ovh.com/showthread.php/19263-S%C3%A9curiser-son-site-web-des-attaques-des-pirates-et-hackers trouvées sur l'ancien forum OVH lien ici).

Voici le lien pour la mise en oeuvre : https://pastebin.com/cC51f85w lien pastebin

Salut ppast.dev,

merci pour le partage, j'ai la même config que toi pour le blocage GEOIP, sauf que ma liste est 3 fois plus longue^^

Par contre j'ai essayé les 2 premières règles de ton htaccess, et houa, je ne peux que te conseiller de très vite les enlever. J'utilise le firewall OVH, et dans le log error, avec ces règles, la plupart des visiteurs se font bloquer (client denied by server configuration).

si ces lignes apparaissent dans le log, c'est une tentative d'attaque sur ton site, car sur un mutualisé ovh, faire une requête sur "index.asp" ou "index.jsp" n'a pas de sens ;-)

bah j'ai pas d'erreurs dans mes logs suspectes (hormis les innombrables attaques sur l'admin wordpress ; que je n'ai pas...)

c'est sur "index.htm" ou "index.cgi" et que les visiteurs se faisaient "Client denied by server configuration: /homexxx-xxxx/xxxxxxx/www/index.htm" bloquer, et le pourquoi je ne sais pas, par contre ce ne sont pas des attaques, c'étaient des visiteurs tout ce qu'il y a de plus classique.

Utilises-tu le firewall OVH ?
(ma config c'est php7, CDN, https, et dans .ovhconfig le http.firewall=security, container.image=stable)

ah ben si ta page s'appelle `index.htm`, évidemment ;-) faut adapter le script. Mes pages ont toutes l'extension `.html` donc y'a pas de soucis ; quant à `index.cgi` je n'utilise pas de script cgi donc je ne vois aucune raison de ne pas bloquer ce genre de requêtes.

Non je n'utilise pas le firewall (enfin à vrai dire je sais plus, j'ai un doute, faudra que j'aille vérifier) ; en échange j'ai un htaccess avec des règles validées depuis longtemps (par la personne visiblement très calée qui les a mises sur le forum il y a qq années et par ma propre expérience sur les quelques adaptations que j'ai pu y apporter).

effectivement, le pare-feu n'était pas activé (par défaut il ne l'est pas, de toute façon) ; "à l'époque", quand j'ai mis les règles dans le htacess, je l'ai laissé ainsi pour avoir un certain contrôle sur ce qui est filtré et ce qui ne l'est pas.

Je pense qu'effectivement j'aurai avantage, d'un point de vue sécurité et optimisation, à le laisser activé, en supposant toutefois que les règles qu'il embarque sont remises à jour de temps en temps.

Par contre, comment savoir si dans mon htaccess je n'ai pas des règles supplémentaires (notamment dans les gros pavés sur la fin) qui ne sont pas intégrées dans le pare-feu applicatif, et qu'il faudrait donc laisser dans le htaccess ? Car en mettant en route le pare-feu, il faut que j'enlève les choses en double du htaccess (sinon c'est crétin et contre-performant de faire 2x le même test), je pense sur la détection des injections sql, etc.)

Bonjour,

question bêtes : pourquoi s'amuser à bloquer ce genre de choses via un .htaccess ?
Sachant que :
1 - c'est le bruit de fond de l'internet
2 - cela vous consomme des ressources (apache/cpu ici) sur votre hébergement
3 - cela ne va pas les arrêter et au contraire cela les aide (si vous les bloquer sur tout ce qui n'existe pas ou ne doit pas exister il tomberont forcément sur ce qui existe est on juste à ce concentrer dessus pour éventuellement trouver une faille vu que l'erreur est humaine).
4 - Le mod_security (aka http.firewall=security) est sans doute plus efficace que vos .htaccess car il déjà c'est un WAF, donc conçus pour agir en L7 et donc peu agir sur beaucoup plus de paramètres de vos .htaccess (voir https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project).

Cordialement, janus57

C'est effectivement une bonne question... et je ne me rappelle pas ce qui m'avait faire choisir ce htaccess trouvé sur l'ex forum ovh plutôt que le mod_security. Surtout qu'effectivement, il traite pas mal de menaces...

Vu ! Merci @janus57

Par contre, je laisse dans mon htaccess des règles pour bloquer certains robots à la con (ça évitera, un peu, que les sites se retrouvent dans des annuaires stupides et autres cochonneries sur le net) : https://pastebin.com/JgrfPH7B https://pastebin.com/JgrfPH7B

Bonjour,

cependant petit remarque sur le mod_security : certains CMS peuvent se faire prendre dans les règles (si elle ne sont pas à jour ou que le CMS a fait les choses un peu à l'arrache).
De plus c'est OVH qui a le contrôle sur les règles donc impossible pour le client de savoir le type de règles utilisés (sauf si OVH décide de les publier ou utiliser les règles open source ou que j'ai donné le lien plus haut).

Enfin il faut savoir que plus un .htaccess est long plus les requêtes vont prendre du temps vu que à chaque requête il va analyser le .htaccess pour voir si il y a un match, donc là autant dire qu'avec un .htaccess de plus de 700 lignes "juste" pour bloquer des bots y a pas mal de perte de perf.

P.S. on peu trouver "mieux" (ça va toujours consommer des ressources) : https://perishablepress.com/4g-ultimate-user-agent-blacklist/

Note : je vois que pas mal de personnes bloque des libraire généraliste comme libwww (https://en.wikipedia.org/wiki/Libwww), du coup je me demande pour quelle raison vu que c'est des des choses public/opensource que n'importe qui peut utiliser (pour preuve certains monitoring les utilisent).

Cordialement, janus57

effectivement j'ai réalise la longueur de la liste en faisant la sélection du copier-coller. j'ai tout viré avant ta réponse d'ailleurs, et ne rajouterai que des lignes spécifiques en cas d'attaques avérées de bots... on passe de qq centaines de lignes à 0 maintenant, et une poignée dans quelques mois ;-)

Bonjour,

deuxième note : pour ceux qui ont des serveur ou ont un accès à la config de apache; oublier le fait d'activer le .htaccess et préférez mettre le directives dans le VHost.

Quelques liens pour montrer l'impact potentiel (non applicable en mutu) :
http://simon.net.nz/articles/benchmarking-htaccess-performance/
https://www.fubra.com/blog/2008/01/07/htaccess-vs-httpdconf/
http://www.yapasdequoi.com/apache/2649-les-fichiers-htaccess-a-utiliser-avec-moderation.html

Cordialement, janus57