modsecurity avancé : antispam WordPress et phpBB

Message par **Malekal_morte** » 14 août 2015 15:03

Voici un exemple d'utilisation avancée de modsecurity qui explique comment monter un anti-spam au niveau du serveur WEB.
Dans mon cas, ce dernier est utilisé pour bloquer les SPAMs en commentaire sur WordPress et sur le forum.

Ce tutorial est plutôt à destination des administrateurs, si vous avez un WordPress, sachez que des extensions permettent de sécuriser WordPress (comme Wordfense) et notamment bloquer l'accès à certains pays comme le propose ce tutorial.
Dernièrement, des spams pour alphform ont lieu, ce qui m'a saoulé.

Le but ici n'est pas de stopper tous les SPAMS mais de minimiser les plus actifs qui reviennent souvent.
C'est toujours une barrière de plus,qui peut éventuellement facilement contournables, mais ça bloquera probablement les attaques automiques "bidons".

Rappel du fonctionnement du paramètre ARGS et ARGS_NAMES :

http://server.invalid/test.php?arg1=test1&arg2=test2

ARGS_NAMES = "arg1","arg2"
ARGS = "arg1:test1=","arg2:test2"

Voici les règles modsecurity :

Code : Tout sélectionner

<LocationMatch "/(wp-comments-post.php|posting.php)">
        SecRule ARGS_POST "@pmFromFile /etc/modsecurity/spamlist.txt" "phase:2,id:663,t:none,t:lowercase,t:normalizePath,pass,nolog,setvar:tx.spam_count=+1"
        SecRule ARGS_POST "(http|e-mail|skype|icq|gmail|hotmail|live\.fr)" "phase:2,id:664,t:none,t:lowercase,t:normalizePath,pass,nolog,setvar:tx.spam_count=+1"
        SecRule ARGS_POST "@pmFromFile /etc/modsecurity/spamlist_whitelist.txt" "phase:2,id:665,t:none,t:lowercase,t:normalizePath,pass,nolog,setvar:tx.spam_count=0"
        SecRule TX:SPAM_COUNT "@eq 2" "phase:2,id:666,deny,status:403,log,logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',msg:'Blog spam blocked'"
</LocationMatch>

Le principe est d'attribuer une note (+1) lorsqu'une string contenue dans un fichier texte est présente dans la requête POST
La seconde ligne ajoute aussi un +1 si une seconde string est présente (si une adresse WEB ou email est donnée).
Enfin la 3e ligne remet la note à 0, si une string est présente, ceci afin de limiter les faux positifs.
Si la note finale est supérieure à 2 (donc si les deux conditions sont remplies mais pas la troisième), on considère que tentative de SPAM est faite.
On interdit alors la requête pour retourner une erreur HTTP 403 (forbidden) et on longue.

NOTE : il doit être possible de jouer avec les "!ARGS:foo" concernant la whitelist.

Le LocationMatch permet de viser les deux URLS sur lesquelles les POSTS WordPress et PhpBB sont effectués.

ci-dessous la liste des strings de SPAM visés :

Code : Tout sélectionner

adf.ly
id card
mastercard
zohaib
Very interesting
to post
this post
the post
blog posts
extraordinaire post
merveilleuse post
fabuleux post
excellent posts
free download
Dresses
healthy
recipe
fragrance
Gagnerdelargent
prada
courtier
cash
bourse
shoes
shopping
cartier
purchase
longchamp
bitcoin
adidas
glasses
moncler
jersey
skirt
bag
price
sunglasses
givenchy
boutique
valentino
gucci
louboutin
air max
duvet
bags
store
vintage
phantom
maillot
QS3PE5ZGdx
golf
doudoune
veste
soldes
pas-cher
timberland
goose
hermes
replica
air jordan
parajumpers
blouson
coins
vuitton
jacket
prices
backlinks
visit us
drugs
letrozole
discount
mendicantism
gracestone
pas cher
expensive
prospects
opportunity
testosterone
anastrozole
deal
vitton
outlet
Great website
buying
Buy
cheapest 
uggs
ugg
addidas
casino
nike
hydrophilic
sale
viagra
cheap
auto insurance
rx medications

Les mots interdits sans adresse http ou email, ça passe :

Les tests - ici une requête de SPAM on se prend un 403 :

La même avec un mot whitelisté, ça passe :

et hop pour le spam alphform :

Autre problème, des bots qui s'inscrivent sur le site :

ceci malgrè, l'excellent mod Advanced Block MOD qui effectue des vérifications RBL :

Il semblerait d'ailleurs que d'autres forums aient le même souci :

Les bots en questions :

gfrmbsziq
[email protected]
gjsxqdbe
[email protected]
nckvkziez
[email protected]
ziejletvn
[email protected]

Exemple du POST à l'inscription :

username=gjemkojz&email=tjthcghkq%40gmail.com&email_confirm=tjthcghkq%40gmail.com&new_password=Sojdlg123aljg&password_confirm=Sojdlg123aljg&lang=fr&tz=1&agreed=true&change_lang=0&submit=Envoyer&creation_time=1439548229&form_token=8fe1e48c763ff1caf6f0a531007â”‚
52â”‚05e2e1de244a0

On remarque que les pseudos sont une suite de caractères de longueur 8 ou 9
Les emails toujousr de longueur 9 en gmail.com

La règle pour les bloquer :

Code : Tout sélectionner

<Location "/ucp.php">
          SecRule ARGS_POST:username "^[a-z]{8,9}$" "phase:2,id:660,t:none,t:lowercase,t:normalizePath,pass,nolog,setvar:tx.spaminscription_count=+1"
        SecRule ARGS_POST:email "^[a-z]{9}(@|%40)gmail\.com$" "phase:2,id:661,t:none,t:lowercase,t:normalizePath,pass,nolog,setvar:tx.spaminscription_count=+1"
        SecRule TX:SPAMINSCRIPTION_COUNT "@eq 2" "phase:2,id:662,deny,status:403,log,logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',msg:'Spambot Inscription'"
</Location>

hop là, la première requête, on se prend un 403, la seconde passe :

Notez qu'il bien sûr possible de whitelister des IPs sur les règles, exemple ci-dessous où on désactive la règle ID 666 sur les IPs suivantes. :

SecRule REQUEST_HEADERS:x-forwarded-for "@ipmatch xx.xx.xx.0/19" "phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=666"
SecRule REQUEST_HEADERS:x-forwarded-for "@ipmatch xx.xx.xx.xx" "phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=666"

Remplacez REQUEST_HEADERS par REMOTE_ADDR si vous voulez viser l'IP du client.

L'avantage d'ipmatch c'est qu'on peut donner des masques réseaux.
Il est tout à fait possible de parser un fichier texte, comme plus haut avec @pmFromFile, mais les masques ne fonctionneront pas puisque la fonction recherche des strings.

Voila, avec ceci, vous devriez avoir quelques bases ou
La documentations modsecurity : https://github.com/SpiderLabs/ModSecuri ... nce-Manual

Message par **Malekal_morte** » 15 août 2015 11:25

Deux remarques concernant le blocage d'inscription des bots. La première est que la règle modsecurity aurait très bien pu être faites en amont sur Varnish. Et ça, ce n'est pas bien compliqué. La seconde remarque est qu'il est aussi possible de filtrer par la géolocalisation grâce une base GeopIP fourni par la société privée maxmind.com ( lire les conditions d'utilisation )

La base : http://geolite.maxmind.com/download/geo ... ity.dat.gz

En pratique, ci-dessous, on bloque le X-Forwarded-For de certains pays. Le REMOTE_ADDR n'est pas vérifié comme d'habitude car sinon avec Varnish on obtiendrait toujours l'IP de notre propre serveur. Bien sûr, sans Varnish, il faudrait vérifier les deux. Notez ici qu'on "bloque des pays", mais vous pouvez faire l'inverse à savoir "n'autoriser que certains pays".

Code : Tout sélectionner

<Location "/ucp.php">
        SecRule ARGS_POST:username "^[a-z]{8,9}$" "phase:2,id:660,t:none,t:lowercase,t:normalizePath,pass,nolog,setvar:tx.spaminscription_count=+1"
        SecRule ARGS_POST:email "^[a-z]{9}(@|%40)gmail\.com$" "phase:2,id:661,t:none,t:lowercase,t:normalizePath,pass,nolog,setvar:tx.spaminscription_count=+1"
        SecRule TX:SPAMINSCRIPTION_COUNT "@eq 2" "phase:2,id:662,deny,status:403,log,logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',msg:'Spambot Inscription'"

        SecRule REQUEST_HEADERS:X-Forwarded-For "@geoLookup" "phase:1,log,status:403,deny,logdata:'Country Code',chain"
        SecRule GEO:COUNTRY_CODE "@rx (CN|RU|TR|CZ|ID|VE|RO|AE|LV|UA|MD|HU|VE|CO|PS|BR|RS)" "t:none"
</Location>

Je test avec une IP brésilienne et comme attendu le serveur me retourne un 403 sur la page.

Je vérifie ensuite les logs qui me confirme l'action du blocage.

Lire : Apache : Sécuriser son site

Malekal.com forum