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 :
Voici les règles modsecurity :http://server.invalid/test.php?arg1=test1&arg2=test2
ARGS_NAMES = "arg1","arg2"
ARGS = "arg1:test1=","arg2:test2"
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>
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 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 :
Exemple du POST à l'inscription :gfrmbsziq
[email protected]
gjsxqdbe
[email protected]
nckvkziez
[email protected]
ziejletvn
[email protected]
On remarque que les pseudos sont une suite de caractères de longueur 8 ou 9username=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
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>

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. :
Remplacez REQUEST_HEADERS par REMOTE_ADDR si vous voulez viser l'IP du client.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"
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