Hack de mon site

[webcrea]

Re : Hack de mon site

Réglé ne signifie pas que le post disparaîtra, simplement il sera "réglé", tout le monde y aura accès en sachant que la solution a été trouvée

[chabi01]

Re : Hack de mon site

Le sujet a été créé par Mike3184 : Idkrus a juste participé au sujet, il n'en est pas l'auteur et ne peut pas fermer ce sujet si je ne m'abuse...
Cordialement,

[mike3184]

Re : Hack de mon site

Tout ce qu'à dis Idkrus a été fait, je dirais même plus que ça (par exemple, modifier le nom d’accès à la page d'admin). A priori, il n'y a pas eu d'accès admin, mais j'ai quand même changé tous les mots de passe (que je ne connais pas moi même, trop complexe, kee pass se charge de la retenir à ma place).

Je confirme que le mod_security fonctionne en mutu OVH, (j'ai des retours sur les logs). Par ailleurs, je pense que c'est au niveau du blocage IP aesecure que ça coince, un petit retour du dev peu être?

Merci.

Edit: Concernant le mod_security d'OVH, voilà les messages que j'ai dans les logs (dans les errors en fait):

[Mon Jul 21 01:35:10 2014] [error] [client 62.76.184.65] [host www.xxxxx.xxx] no acceptable variant: /****/****/www/libraries/fof/view

IP Russe, qui essaie de touchoter akeeba à priori.

[Mon Jul 21 14:01:46 2014] [error] [client 173.255.225.130] ModSecurity: Access denied with code 403 (phase 2). Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache2/conf/modsecurity/base_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line "65"] [id "960009"] [rev "2.1.1"] [msg "Request Missing a User Agent Header"] [severity "NOTICE"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER_UA"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "www.xxxxx.xxx"] [uri "/modules/mod_weblinks/tmpl/user.php"] [unique_id "U80BKgoAcz8AAAtBnjgAAAIY"]

Intéressant ici car il s'agit du trojan d'origine sur IP US. La requête semble reconnue et bloquée directement par le mod_security (activé chez OVH après l'attaque), enfin, c'est dans les logs erreur, mais je suppose que c'est normal car il s'agit d'un module Apache.

[chabi01]

Re : Hack de mon site

Cavo est en vacances actuellement : il ne pourra pas répondre.
As-tu regardé les logs des blocages dans Aesecure : regarde ce qui a été bloqué et pourquoi...
Cordialement,

[mike3184]

Re : Hack de mon site

Y'a pas grand chose dans le log aesecure pour l'instant.

[PieceOfCake]

Re : Hack de mon site

Si c'est dans le log erreur d'OVH et bloqué par le mod_security, ça ne va même pas jusqu'au .htaccess, bloqué avant donc aucune chance que aesecure puisse le voir, c'est arrêté avant.

Pour les quelques IP que j'ai rajouté dans la section aesecure concernée, je ne les ai plus revu dans mes logs sauf au niveau d'erreur 403

Aesecure ne les jette pas à la poubelle, il n'en a pas les moyens, il provoque une erreur HTTP et la mieux placé est : 'Accès interdit'

Cordialement

[mike3184]

Re : Hack de mon site

Oui c'est ce qu'il semblerait en effet, tant mieux dans ce cas si ça n'arrive même pas au .htaccess c'est que la protection est efficace.

Par ailleurs, pas d'erreur 403 pour les IPs bloquées avec aesecure de mon côté, c'est ça que je comprends pas, à moins que j'ai commis une erreur dans la syntaxe, mais j'ai pourtant bien séparé les IPs par un point virgule comme indiqué.

[PieceOfCake]

Re : Hack de mon site

Si tu n'es pas sûr du blocage effectué par aesecure, tu peux aussi essayer de le faire manuellement (à l'ancienne en quelque sorte)

dans le même fichier .htaccess (et dès le début pas la peine d'attendre), tu ajoutes des lignes :

order allow,deny
deny from 123.45.67.89
deny from 222.333.44.55
deny from 666.666.666.22
allow from all

[mike3184]

Re : Hack de mon site

Ok merci, j'ai configuré comme tu me l'as indiqué, je vais voir si j'ai bien des retours 403 sur ces IPs.

En fait, sur aesecure, c'était plus ou moins la même chose, sauf que "allow from all" était avant les "deny from", et qu'il n'y avait qu'un seul "Deny from" puis toutes les IP ensuite sur une ligne séparées par un espace. Mais au niveau du htaccess, je ne sais pas si ces deux syntaxes sont vraiment différentes. Egalement, le deny avait un "D" majuscule.

[PieceOfCake]

Re : Hack de mon site

Je ne crois pas que .htaccess soit sensible à la casse à ce niveau. Pour le reste, la syntaxe est extrêmement précise, mais j'ai ugrande et totale confiance dans le développeur d'aesecure.

La proposition faite était juste pour te mettre en évidence le fonctionnement

[mike3184]

Re : Hack de mon site

Il semblerait que cette syntaxe fonctionne mieux car j'ai tout un tas d'erreur 403 sur une des IP bloquée dans le log web d'OVH.

Edit: En fait je ne suis pas sûr, l'IP étant Russe, et ayant fait un blocage Geoip RU, ça viens peu être de là.

[PieceOfCake]

Re : Hack de mon site

Il semblerait que cette syntaxe fonctionne mieux car j'ai tout un tas d'erreur 403 sur une des IP bloquée dans le log web d'OVH.

Edit: En fait je ne suis pas sûr, l'IP étant Russe, et ayant fait un blocage Geoip RU, ça viens peu être de là.

Normalement dans le log tu dois voir l'IP de celui qui est bloqué, il est dans la liste du .htaccess (nommément) ou pas.
Les blocages GeoIP ont aussi leur limite, le risque étant de viser trop large

[ldkrus]

Re : Hack de mon site

Merci chabi01

[ldkrus]

Re : Hack de mon site

mike3184,

si je puis me permettre, concernant l'ordre des instructions dans le htaccess, je viens de faire le test et l'ordre est important sinon ça ne fonctionne pas :

order allow,deny
allow from all (en premier)
Deny from 123.45.67.89
Deny from 222.333.44.55
Deny from 666.666.666.22

[PieceOfCake]

Re : Hack de mon site

mike3184,

si je puis me permettre, concernant l'ordre des instructions dans le htaccess, je viens de faire le test et l'ordre est important sinon ça ne fonctionne pas :

order allow,deny
allow from all (en premier)
Deny from 123.45.67.89
Deny from 222.333.44.55
Deny from 666.666.666.22

oui et non, il y a plusieurs solutions et on ne peut pas en rejeter une en en présentant une autre, tout dépend de ce que l'on veut faire et de la compréhension de la directive Order :

Order deny, allow :
Par défaut on rejette, puis on va autoriser ce qui n'a pas été traité (ou ce qui a été mal traité) par les refus.
Order allow, deny :
Par défaut on accepte, puis on va rejeter ce qui n'a pas été traité (ou ce qui a été mal traité) par les autorisations.

Ensuite l'ordre dans lequel sont écrits les directives allow xxxx et deny yyyy n'a plus aucune importance. De fait sans changer l'ordre des déclarations allow et deny, simplement en modifiant la commande order on change ou même inverse le résultat obtenu.

Donc affirmer :

allow from all (en premier)

n'a pas de sens en soi, tu peux aussi bien mettre cette ligne en dernier la directive :

order allow,deny

fera qu'elle sera toujours traitée en premier.

A ce sujet lire, "Apache the definitive Guide" : http://docstore.mik.ua/orelly/linux/apache/ch05_06.htm

Cordialement