[Raptor00]

Petit script qui peux t'aider, mais qui peux ban aussi de bon clients

cat /home/log/httpd/site_log | grep "POST" > /ddos.log

Puis créer un fichier ddos.php de dans il faut mettre :

error_reporting(1);
ini_set('memory_limit', '-1');

$reqs = file("ddos.log");

foreach ($reqs as $req) {
$ip = explode(" - - ", $req);
$ip_address[$ip[0]]++;
}

arsort($ip_address);
$output = shell_exec('iptables -I INPUT -s $ip -j DROP');

foreach ($ip_address as $ip=>$attack_times) {
print $ip;
}

?>

Puis un coup de putty => php ddos.php

Aussi dans la config apache, c'est changer le Timeout, tu le mais a 3 le temps de l'attaque, ton site restera en ligne, mais les gens qui ont une connexion très lente, auront du mal a joindre ton site.

[kofu12]

Mon site toujours down... ras le bol !!!

120.202.249.202 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0.1"
120.52.27.7 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.1" 502 568 "-" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1"
59.44.49.150 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.1" 502 166 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.02"
113.7.101.139 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.1" 502 166 "-" "Opera/9.80 (Windows NT 5.1; U; en) Presto/2.10.229 Version/11.60"
120.202.249.205 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.1" 502 166 "-" "Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0.1"
58.34.160.49 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.1" 502 568 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11"
183.60.6.172 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20100101 Firefox/12.0"
113.7.101.139 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.1" 502 166 "-" "Opera/9.80 (Windows NT 5.1; U; en) Presto/2.10.229 Version/11.60"
113.7.101.139 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.1" 502 166 "-" "Opera/9.80 (Windows NT 5.1; U; en) Presto/2.10.229 Version/11.60"
120.24.186.91 - - [22/Jun/2016:22:34:19 +0200] "POST / HTTP/1.0" 444 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5"

[sich]

t'es sûr que pour l'ip ovh ce n'est pas le monitoring ?
Sinon ça peut être un autre serveur vérolé.

[buddy]

c'est surement un VPN ou un "robot".

Tu peux bloquer l'adresse si tu veux ...

à taper directement dans le terminal
iptables -I INPUT -s IP_ADRESS -j DROP

[kofu12]

Bonjour,

J'ai modifier le nombre de r/s. J'ai également ajouter des logs avec l'anti spam PHP, et je peux voir qu'une ip ovh flood ma page lol pas très logique

[Rizz]

Bonjour,

Je viens pour vous dire que ce n'est pas concluant.

La personne arrive encore à flood une page en mass.



Pourtant j'ai bel et bien activé -> limit_req_zone $binary_remote_addr zone=limit:10m rate=10r/s;

si tu regarde le lien que j'ai mis au dessus la config est a une requête par seconde avec des piques a 5.
La tu est a 10 r/sec max ... ce qui est au dessus du nombre de requête de ton spammer ( il fait 4 à 6 rquete/s d'apres tes log ..)
so ... tu le descend un peu? essaie a 2 ? 3 ?

[sich]

Fail2ban est ton ami dans ce cas.

[kofu12]

Bonjour,

Je viens pour vous dire que ce n'est pas concluant.

La personne arrive encore à flood une page en mass.

"GET /community/vips HTTP/1.1"

Pourtant j'ai bel et bien activé -> limit_req_zone $binary_remote_addr zone=limit:10m rate=10r/s;

[kofu12]

Bonsoir,

Merci à tous. Le problème à l'air d'être résolu . Je vais attendre 24h avant de crier victoire aussi rapidement. Je vous tiens au courant.

[Rizz]

Pas d'amélioration.. toujours du flood sur la page connexion.

regarde la

http://nginx.org/en/docs/http/ngx_ht...eq_module.html

le rate est peut etre un peu haut a 10r/s

[sich]

Les IP changent ?
As tu fail2ban sur ton serveur ?

Tu peux très bien mettre une détection par fail2ban sur tes logs apaches et si + de 10 connexions à cette page en 5min alors ban de l'ip pour 24H....

[kofu12]

Hello,

Comme tu utilises nginx, tu as aussi la solution suivante qui limite le nombre de requêtes maximum d'un client :

Dans ton http {

limit_req_zone $binary_remote_addr zone=limit:10m rate=10r/s;

Dans ton server {

	location ~* \.php$ {
		limit_req zone=limit burst=5 nodelay;
		try_files $uri =404;
		fastcgi_pass unix:/run/php-fpm/www.sock;
		fastcgi_index index.php;
		fastcgi_buffers 16 8k;
		fastcgi_buffer_size 16k;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include /etc/nginx/fastcgi_params;
	}

Pas d'amélioration.. toujours du flood sur la page connexion.

[sich]

Tu peux ajouter un paquet d'ip à blacklister assez facilement via des listes....
http://feeds.dshield.org/block.txt
http://www.spamhaus.org/drop/drop.txt
http://www.spamhaus.org/drop/edrop.txt
http://lists.blocklist.de/lists/all.txt

Mais il est important pour toi d'adapter tes scripts et de mettre ça en relation avec fail2ban ou ton parefeu...

[Rizz]

Dans tout les cas tu as besoin d'une solution autonome.
Car bon ... quand il va s'apercevoir qu'il te gène plus avec cette ip il en changera ... C'est pas les fournisseurs de vpn gratuit qui manque malheureusement;
Sinon tu as surement de quoi lier l'ip avec un compte non ? tu dois pouvoir le bannir je suppose ?
Sur mon site j'avais meme fini par bannir des range entiers pour eviter les multi ( acces wifi free par exemple ou des IP en provenance de certain pays de l'est + fournisseur de vpn miteux + thor + ..)

[kofu12]

Merci à tous, je vais appliqué c'est paramètres et reviens vers vous afin de vous dire si ce problème est résolu ou non.

[DemonRenard]

Hello,

Comme tu utilises nginx, tu as aussi la solution suivante qui limite le nombre de requêtes maximum d'un client :

Dans ton http {

limit_req_zone $binary_remote_addr zone=limit:10m rate=10r/s;

Dans ton server {

	location ~* \.php$ {
		limit_req zone=limit burst=5 nodelay;
		try_files $uri =404;
		fastcgi_pass unix:/run/php-fpm/www.sock;
		fastcgi_index index.php;
		fastcgi_buffers 16 8k;
		fastcgi_buffer_size 16k;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include /etc/nginx/fastcgi_params;
	}

[sich]

vi donc bloque simplement cette IP.
Pour limiter les dégâts sur un flood d'une page donnée tu as plusieurs solutions... Le cache mysql pour éviter d'interroger mysql à chaque fois... Contrôler à base de l'IP et d'un cache local le dernier chargement de la page par une IP donnée et arrêter le script si le délais est trop court....
Coupler tes scripts perso avec fail2ban pour bannir automatiquement les IP qui font ça...

Si tu utilises cloudflare il faut savoir qu'il ne s'occupera pas de mettre en cache des scripts PHP...

[kofu12]

Oui c'est du flood/spam sur certaines pages comme j'ai pu voir dans les logs apache.

Le mec s'amuse à flood une page qui affiche par exemple la liste des articles sur mon site, ou les utilisateurs VIP

[sich]

de toute façon normalement tu ne devrais pas avoir ce soucis
Sauf si tu as plusieurs centaines de personnes en même temps sur ton site....
Ou si tu as du flood / spam... Mais dans le cas de flood / spam il faut trouver un moyen d'identifier ces personnes et bannir les IP, ça sera + simple...

[kofu12]

essaie aussi de gérer un cache local sous forme de fichier pour éviter de solliciter ta bdd....
Par exemple si tu veux enregistrer le nombre de tentatives par ip, tu peux très bien stocker ça dans un fichier (1 fichier / ip) et tu mets un count dedans pour connaitre les tentatives.... Tu remets à 0 quand la connexion est réussie. Si le nombre de tentatives est trop important tu arrêtes ton script immédiatement sans interroger la bdd...
Mais si tu trouves trop souvent la même ip dans tes logs le plus simple étant encore de directement bloquer cette ip sur le parefeu...

Voir de coupler ton script de login et de comptabilisation des échecs avec un fail2ban pour bannir automatiquement les ip à problème.

Merci pour l'aide, cependant j'ai aucune idée de comment créer ce code.. Mais bon je pense que google est mon ami

[sich]

essaie aussi de gérer un cache local sous forme de fichier pour éviter de solliciter ta bdd....
Par exemple si tu veux enregistrer le nombre de tentatives par ip, tu peux très bien stocker ça dans un fichier (1 fichier / ip) et tu mets un count dedans pour connaitre les tentatives.... Tu remets à 0 quand la connexion est réussie. Si le nombre de tentatives est trop important tu arrêtes ton script immédiatement sans interroger la bdd...
Mais si tu trouves trop souvent la même ip dans tes logs le plus simple étant encore de directement bloquer cette ip sur le parefeu...

Voir de coupler ton script de login et de comptabilisation des échecs avec un fail2ban pour bannir automatiquement les ip à problème.

[kofu12]

Tu peux si les variables de session date_spam et spam n'existe pas dans ton appli. Cela va accelerer la fin du script mais ne reglera probablement pas entièrement ton soucis.

Tu sais tu devrai avoir le même genre de verif sur ta page de login pour t'assurer qu'il n'y a pas de brute force par exemple.
D'ailleurs est ce que la page qui est spam n'est pas celle qui suit le formulaire de connexion ? ( j'ai pas trouvé la lecture du code, y'a pas de

ni d'url de destination pour le formulaire ) Si oui alors tu as un bot qui tente un brute force .

D'accord merci, pour la page de connexion le code de connexion est direction sur la page index.php

[Rizz]

Tu peux si les variables de session date_spam et spam n'existe pas dans ton appli. Cela va accelerer la fin du script mais ne reglera probablement pas entièrement ton soucis.

Tu sais tu devrai avoir le même genre de verif sur ta page de login pour t'assurer qu'il n'y a pas de brute force par exemple.
D'ailleurs est ce que la page qui est spam n'est pas celle qui suit le formulaire de connexion ? ( j'ai pas trouvé la lecture du code, y'a pas de ni d'url de destination pour le formulaire ) Si oui alors tu as un bot qui tente un brute force .

[kofu12]

Un petit bout de code qui compare des dates et incremente le nombre de clic / min et stop le process si au moins 3 demandes /seconde.

if (!isset($_SESSION['date_spam'])) {
    $_SESSION['date_spam']=date('Y-m-d H:i:s');
    $_SESSION['spam']=1;
}
elseif($_SESSION['date_spam']==date('Y-m-d H:i:s')){

    $_SESSION['spam']++;
    if ($_SESSION['spam']>2) {        
        exit();
    }
}
else{
    $_SESSION['date_spam']=date('Y-m-d H:i:s');
    $_SESSION['spam']=1;
} 

Biensur tu peux aussi metttre l'ip dans une bdd au bout de XX spam detecté et la bannir automatiquement si tu est sur que ton ddos ne provient pas d'un ajax mal fouttu ou autre utilisation normale du site.

C'est un petit bout de code que j'avais mis en place pour eviter les clic frénétique sur un jeu que j'ai dev l'année passé.

L'iframe sur ton site c'est voulu ou bien ?
edit : ha ok c'est ta régie AD

Merci, j'ajoute sa sur la page en question?

[madri2]

se baser sur les sessions pour vérifier si une personne flood c'est inefficace, il suffit que le bot ne gère pas les cookies ...

[sich]

Tu es sur quelle distrib ?
Tu devrais mettre en place des sécurités pour éviter le flood sur certains scripts.
Sans oublier de contrôler le nombre de process autorisé sur php.
Sur debian c'est dans /etc/php5/fpm/pool.d/www.conf

[Rizz]

Un petit bout de code qui compare des dates et incremente le nombre de clic / seconde et stop le process si au moins 3 demandes /seconde.

if (!isset($_SESSION['date_spam'])) {
    $_SESSION['date_spam']=date('Y-m-d H:i:s');
    $_SESSION['spam']=1;
}
elseif($_SESSION['date_spam']==date('Y-m-d H:i:s')){

    $_SESSION['spam']++;
    if ($_SESSION['spam']>2) {        
        exit();
    }
}
else{
    $_SESSION['date_spam']=date('Y-m-d H:i:s');
    $_SESSION['spam']=1;
} 

Biensur tu peux aussi metttre l'ip dans une bdd au bout de XX spam detecté et la bannir automatiquement si tu est sur que ton ddos ne provient pas d'un ajax mal fouttu ou autre utilisation normale du site.

C'est un petit bout de code que j'avais mis en place pour eviter les clic frénétique sur un jeu que j'ai dev l'année passé.

L'iframe sur ton site c'est voulu ou bien ?
edit : ha ok c'est ta régie AD

Sinon le liens mot de passe oublié ne semble pas fonctionner.

[kofu12]

Merci de ta réponse.

Pourrait tu m'en dire plus sur comment activé le nombre de x par min?

J'ai environ 800 connectés par jours + des visiteurs

[Rizz]

Perso les VPN qui flood je les ban .. deja l'utilisation d'un VPN c'est à moitié louche.. Ce que tu as c'est probablement un multi avec un bot mal programmé.
Tu peux facilement t'assurer qu'une page n'est pas demandé plus de X fois par seconde. (5 fois par seconde c'est un peu trop . ) .
Ceci dit dans
/etc/php-fpm.d/www.conf
tu trouvera le nombre de process php qui peut tourner en meme temps ( depend de la ram utilisé lors de l'execution du script et de la ram du serveur )
Tu as combien d'utilisateur simultané la dessus ?

[kofu12]

Aucune idée, j'ai très peu de connaissance à ce niveau..
Mais je pense que c'est du flood sur une page en question comme indiqué dans les logs "GET /community/vips HTTP/1.1"

Car lorsque je supprime cette page, c'est repartie

[sich]

ok donc à priori c'est php qui a du mal.
Combien de process php max tu peux avoir sur le serveur ?
Pourquoi php sature ? Pas assez de process ? Process ton long à traiter qui sature le pool ?

@Nowwhat : CF est génial pour distribuer les fichiers fixes.... Image, page de cache en html... En cas de gros pic d'utilisateurs ça fait vraiment du bon taf pour soulager le serveur. Quand il y'a bcp de monde c'est vraiment utile je trouve.

[kofu12]

down ça ne veux malheureusement pas dire grand chose.....
Que se passe t'il exactement ?
Apache down ? MySQL ? Le serveur complet ? Bande passante saturée ? cpu ? Process apache / php au max ?
Des logs quelconques ?

Non ni mysql, ni le cpu n'est touché.

Cependant c'est un flood sur une page en question qui sature certainement la bande passante et cloudflare ne fait pas l'affaire..

logs:

2016/06/20 16:43:00 [error] 17579#0: *537 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"
2016/06/20 16:43:00 [error] 17579#0: *541 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"
2016/06/20 16:43:00 [error] 17579#0: *543 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"
2016/06/20 16:43:00 [error] 17579#0: *545 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"
2016/06/20 16:43:00 [error] 17579#0: *547 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"
2016/06/20 16:43:01 [error] 17579#0: *553 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"
2016/06/20 16:43:01 [error] 17579#0: *555 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"
2016/06/20 16:43:01 [error] 17579#0: *557 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"
2016/06/20 16:43:01 [error] 17579#0: *559 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"
2016/06/20 16:43:01 [error] 17579#0: *563 connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 188.72.114.71, server: hbeta.net, request: "GET /community/vips HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "XXX.XX.XXX.XX"

[Nowwhat]

B... nginx est cloudflare pro)

Cloudfare ? Pourquoi faire ?

[sich]

down ça ne veux malheureusement pas dire grand chose.....
Que se passe t'il exactement ?
Apache down ? MySQL ? Le serveur complet ? Bande passante saturée ? cpu ? Process apache / php au max ?
Des logs quelconques ?

[kofu12]

Bonjour,

Je viens demander de l'aide ici car depuis 2-3 jours, mon serveur dédié (linux avec nginx est cloudflare pro) est toujours down.
Le serveur tourne normalement, mais le site héberger sur celui ci est down 3/4 du temps...

Une attaque DDOS?