OVH Community, votre nouvel espace communautaire.

iptables : bloquer des adresses IP


starouille
17/07/2012, 20h09
Citation Envoyé par AnonymousCoward
starouille : Tu as déjà pu tester ipset avec une iptreemap ? Je me demande ce que ca vaut, question performances.

--
AnonymousCoward
C'est une bonne question. Je n'ai jamais eu l'occasion de tester ipset, mais ça a l'air intéressant.

AnonymousCoward
17/07/2012, 19h09
starouille : Tu as déjà pu tester ipset avec une iptreemap ? Je me demande ce que ca vaut, question performances.

--
AnonymousCoward

starouille
17/07/2012, 18h04
D'expérience (j'aurais préféré éviter ces expériences là mais bon )Il faut éviter d'utiliser Iptables pour bannir un ddos important (quand on se base sur les logs bien entendu).

Avoir 20-30K de drop fera planter le serveur (iptables n'est plus efficace...).

Il faut plutôt opter pour les null route. ça peut paraitre moche, mais créer une route bidon pour chaque IP qui attaque, c'est beaucoup plus performant (100K d'IP sans problème ).

nuI
17/07/2012, 17h41
A priori l'attaque est une DDOS contre Apache, donc auth.log et messages ne serviront pas à grand chose.

Et pour du SSH, je pense qu'il vaut mieux faire directement une whitelist d'IP fixes.
A moins qu'il n'y ait des milliers d'utilisateurs par jour en SSH...

TuxNux
17/07/2012, 01h37
Citation Envoyé par Yadutaf
Cette liste est extraite des logs. Je ne suis sûr de rien. Les gars qui se penchent sur la faille disent qu'ils l'ont peut-être trouvée mais pour l'instant il semble qu'ils n'aient pas encore trouvé la solution.
voici un ptit script simple qui traite les fichiers logs,

Code:
#!/bin/sh
BLACKLIST=/var/log/blacklist.log
#on commence par récupérer l'ip des mécréants a partir du log, et création de la blacklist

cat /var/log/auth.log | grep "Failed" | awk -F "from" '{ print $2 }' | awk '{ print $1 }' | sort -u >/var/log/blacklist.log
cat /var/log/auth.log | grep "Illegal" | awk -F "from" '{ print $2 }' | awk '{ print $1 }' | sort -u >>/var/log/blacklist.log
cat /var/log/messages | grep "Shorewall:net2fw:DROP:IN" | awk -F "SRC=" '{ print $2 }' | awk '{ print $1 }' | sort -u >>/var/log/blacklist.log

#pour chaque ip on compte combien il y a eu d'erreurs d'authentification
for i in `cat /var/log/blacklist.log` ; do
  nberreurs1=`cat /var/log/auth.log | grep "Failed" | grep $i | wc -l`
  nberreurs2=`cat /var/log/auth.log | grep "Illegal" | grep $i | wc -l`
  nberreurs3=`cat /var/log/messages | grep "Shorewall:net2fw:DROP:IN" | grep $i | wc -l`
  let nberreurs=$nberreurs1+$nberreurs2+$nberreurs3

#s'il y a eu plus de 3 erreurs et que l'ip n'est pas déjà blacklistée et bien on la blackliste !
if [ "$nberreurs" -ge "3" ]
    then
    if [ "`cat /var/log/blacklist.log | grep $i`" = "" ]
	then
	echo "Blocage de $i..."
        iptables -A INPUT -t filter -s $i -j DROP
    fi
  fi
done
a mettre sur un cron a l'intervalle qu'on veut et bien sur adapter selon son log

Yadutaf
19/04/2012, 09h52
Merci Cybersonic pour ces conseils, je vais étudier ça.

Cybersonic
19/04/2012, 05h12
Citation Envoyé par Yadutaf
Bonne nouvelle, nous avons sans doute trouvé la faille et y avons remédié. Peut-être ...

Par contre, le blocage des IPs ne marche pas. Le serveur continue à être bombardé plusieurs milliers de fois par minute par des adresses IPs différentes. Le fichier de log, qui pesait 43 mb (!) à 16h30, fait 47 mb à 17h35 et la simple page html d'attente ne s'affiche plus. Ça ressemble à du déni de service, non ?
Ton truc que tu explique ressemble à du synflood et fatalement les IPs que tu reçois dans les logs ne t'envoi pas réellement se que tu pense (c'est simplement une seul IP qui se cache derrière tes tonnes d'IPs prise simplement depuis une liste d'IP)
Tu va simplement passé ton temps à bannir des IPs et sans le moindre effet, puisque à tout les coups le gars se cache derrière des milliers d'IPs

pense bien que si sa aurait été en provenance réel de toutes les IPs sa aurait été d'un très gros parc de PC zombie et ta bande passante serait HS et tu n'aurait plus ou rarement l'accès à ton serveur

Malheureusement il existe quelques mauvais softs qui met à la portée du premier venu un large panel d'attaques de types différents.

Si le gars est malin et que tu configure mal ton fail2ban il finira même par te faire bannir les moteurs de recherches qui te sont utiles, des bandes d'IPs bien définie avec pourquoi pas ta propre bande d'IP. Il fut un temps il était même possible d'injecter une vrai/fausse erreur log en y ajoutant des bien défini histoire d'emmerder le monde, corrigé par les récentes versions de fail2ban, mais techniquement c'est toujours possible

et au fait pour les filtres du même genre, il existe des variantes et principalement pour selectionner plusieurs types sans pour autant refaire une ligne ou un filtre (si condition de ban idem)

[[]client []] (File does not exist|script not found or unable to stat): /\S*(\.php|\.asp|\.exe|\.pl)
[[]client []] script '/\S*(\.php|\.asp|\.exe|\.pl)\S*' not found or unable to stat *$
[[]client []] (File does not exist|script not found or unable to stat): .*
et puis n'oublie pas que si comme tu dis avoir des faux négatif ou des liens mort tu peut toujours aussi utiliser la variable ignore, histoire de justement de pas prendre en compte sur ton filtre certains types de fichiers qui ne sont pas dangereux en utilisation

ignoreregex = File does not exist: .*(favicon\.ico|robots\.txt|\.jpg|\.gif|\.png|\.tx t|\.JPG|\.GIF|\.PNG|\.ico|\.html)
Et note aussi que tu peut aussi directement dans la Cfg d'apache exclure du log access ou error certains types d'erreurs ou d'accès pour ne pas venir se mêler dans le filtre (a condition que le type de ligne log à exclure ne te soit pas utile dans un outil stats)

Yadutaf
18/04/2012, 11h33
Effectivement ma règle fonctionne. Une petite faute de frappe qui l’empêchait de fonctionner, peut-être ?

Merci Nowwhat et merci à tous pour m'avoir aidé à sortir de ce mauvais pas !

Nowwhat
17/04/2012, 14h05
Citation Envoyé par Yadutaf
...Mais en attendant, si quelqu'un a une piste ...
Mon "filtre test":
C'est une copie exacte de la tienne Je le nomme 'aaa.conf' dans /etc/fail2ban/filter.d.
Code HTML:
# Fail2Ban configuration file
#
# Bannissement des IP qui recherche des fichiers de types *.jsp.
#
[Definition]
# Option: failregex
# Notes.: 
#
failregex = [[]client []] File does not exist: .*(jsp)
#
# Option: ignoreregex
#
ignoreregex =
Je demande une page qui n'existe pas sur mon serveur:
www.papy-team.org/test.jsp
....
Et baf, j'au un erreur dans le error. log:
Code:
.... 
[Tue Apr 17 13:56:14 2012] [error] [client 90.50.248.128] File does not exist: /var/www/test.jsp
....
Je regex:
fail2ban-regex /var/log/apache2/error.log /etc/fail2ban/filter.d/aaa.conf
qui me donne:

Code:
 
Running tests
=============
Use regex file : /etc/fail2ban/filter.d/aaa.conf
Use log file   : /var/log/apache2/error.log
 
Results
=======
Failregex
|- Regular expressions:
|  [1] [[]client []] File does not exist: .*(jsp)
|
`- Number of matches:
   [1] 2 match(es)
Ignoreregex
|- Regular expressions:
|
`- Number of matches:
Summary
=======
Addresses found:
[1]
    66.249.72.26 (Tue Apr 17 09:16:12 2012)
    90.50.248.128 (Tue Apr 17 13:56:14 2012)
Date template hits:
46 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second
0 hit(s): Year/Month/Day Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/MONTH/Year:Hour:Minute:Second
0 hit(s): Month/Day/Year:Hour:Minute:Second
0 hit(s): Year-Month-Day Hour:Minute:Second
0 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond]
0 hit(s): Day-Month-Year Hour:Minute:Second
0 hit(s): TAI64N
0 hit(s): Epoch
0 hit(s): ISO 8601
0 hit(s): Hour:Minute:Second
0 hit(s): 
Success, the total number of match is 2
However, look at the above section 'Running tests' which could contain important information.
L'IP "90.50.248.128", c'est moi.
Je dirai donc: ton filter me semble correct.

Yadutaf
17/04/2012, 09h54
Merci guiguiabloc. Je vais regarder cela. Ça semble intéressant mais plus compliqué qu'une règle fail2ban bien écrite, non ?

guiguiabloc
16/04/2012, 22h50
Il y a quelques années, j'avais écrit un script basé sur iptables facilitant son approche :
http://sourceforge.net/projects/kharon/

Si tu as un iptables actif, le moyen le plus simple est de créer une nouvelle chaine :

Code:
iptables -N spammeur
iptables -I INPUT 1 -j spammeur
ensuite, a partir de ta liste de bloc CIDR, tu peux générer un script.

Code:
#!/bin/bash
LISTEBAN="nom_duf_ichier_avec_les_ips"
for i in `cat $LISTEBAN` 
do 
echo "/sbin/iptables -A spammeur -s  $i -j DROP" >> cmdban.sh
done
chmod +x cmdban.sh
echo "OK !"
Tu te retrouveras avec un fichier cmdban.sh contenant toutes les ips a bannir qu'il te suffit s'executer sur ton serveur

Code:
cat cmdban.sh
/sbin/iptables -A spammeur -s  129.44.55.66 -j DROP
/sbin/iptables -A spammeur -s  34.77.88.55.4 -j DROP
/sbin/iptables -A spammeur -s  33.55.66.33 -j DROP

Yadutaf
16/04/2012, 12h00
Citation Envoyé par Athar
Avec un petit script shell qui contient ta boucle et que tu fais lancer automatiquement après l'activation du réseau?^^
Merci, c'est fait.

Par contre, j'ai un dernier (?) petit point noir à résoudre. Je voudrais bannir automatiquement, à l'aide de fail2ban, toutes les IP qui cherchent des fichiers monchemin/*.jsp (ce sont de tels fichiers qui ont causé nos problèmes de départ).

Sur une application bien écrite je pourrais appliquer une règle basée sur l'erreur 404 comme on en trouve plein l'Internet. Malheureusement, le script actuel est tellement mauvais qu'il renvoie à tour de bras des "File not found" ... légitimes. D'où un risque certain de faux positifs pour la quasi totalité de nos visiteurs.

J'ai donc écrit le filtre fail2ban suivant :
Code:
# Fail2Ban configuration file
#
# Bannissement des IP qui recherche des fichiers de types *.jsp.
#
[Definition]
# Option: failregex
# Notes.: 
#
failregex = [[]client []] File does not exist: .*(jsp)
#
# Option: ignoreregex
#
ignoreregex =
Le test me renvoie :
Code:
Running tests
=============

Use regex line : /etc/fail2ban/filter.d/apache-jsp
Use single line: /var/log/apache2/error.log

No 'host' group in '/etc/fail2ban/filter.d/apache-jsp'
Cannot remove regular expression. Index 0 is not valid

Results
=======

Failregex
|- Regular expressions:
|  [1] /etc/fail2ban/filter.d/apache-jsp
|
`- Number of matches:
   [1] 0 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Sorry, no match
Je sais qu'il va falloir que je révise mes expressions régulières si je veux progresser ! Mais en attendant, si quelqu'un a une piste ...

Athar
16/04/2012, 01h00
Avec un petit script shell qui contient ta boucle et que tu fais lancer automatiquement après l'activation du réseau?^^

Yadutaf
16/04/2012, 00h07
Merci Athar. Je n'avais pas vu ta réponse avant de poster.

Finalement, j'ai fait une boucle sur mon fichier de blocs à bannir avec :
iptables -I INPUT -j DROP -s xxx.xxx.xxx.x/xx
et la table filters c'est bien remplie.

Maintenant je cherche à finaliser l'opération. C'est-à-dire à m'assurer qu'il démarrera lors de chaque reboot.

Yadutaf
15/04/2012, 23h25
J'ai fini par réussir à entrer mes règles ! Sans doute une faute de frappe mainte fois réitérée.
Plus qu'à relancer le pare-feux et à regarder si ça marche.

Athar
15/04/2012, 23h21
Avec la notation CIDR, a tester:

iptables -t nat -I PREROUTING -i eth0 -s IP/cidr -j DNAT --to 0

Sinon, avec un range d'adresse:
iptables -t nat -I PREROUTING -i eth0 -m iprange --src-range IP_début-IP_fin -j DNAT --to 0

Cela les stop dès l'arrivé sur le serveur, ils n’accèdent donc a rien au final (syntaxe a vérifié, je passe via un iptables-restore de mon fichier qui commence par un *nat et finit par un COMMIT)

Yadutaf
15/04/2012, 22h39
Bonsoir à tous,

Nous avons trouvé et corrigé la faille de sécurité et remis notre site en route . Mais le bombardement continu.
95% des attaques venant du Mexique et du Brésil et l'entreprise n'ayant pour ainsi dire pas de client dans ces pays, je leur ai concocté un petit Deny généralisé dans la htaccess qui fonctionne à merveille et notre ami le pirate, ou tout au moins ses zombies, a droit à une erreur 403 à chaque tentative.

Mais ce n'est pas suffisant car lesdites tentatives sont tellement nombreuses que notre serveur en est très ralenti.

L'idée serait de bloquer ces deux pays grâce à iptables pour que le site tourne correctement et d'affiner ensuite avec fail2ban pour que le bannissement soit moins brutal.

J'ai bien les listes de blocs d'IP à bannir mais, malgrès de nombreuses recherches et lectures, y compris sur le forum OVH, je n'arrive à rien avec iptables. Je suis désolé de demander cela car, normalement, j'aime bien chercher et comprendre avant d'agir mais, là, je n'ai pas le temps alors j'aimerais une "recette clé en main" ou l'adresse d'un tuto pas à pas pour arriver uniquement à cette fin, le blocage complet de pays.

Je vous remercie pour votre aide.

Voici comment se présente ma liste de blocs d'IP :
Code:
12.173.25.8/29
12.173.25.64/27
12.173.25.128/29
12.173.25.176/28
12.173.28.0/24
32.59.1.0/25
46.36.193.225/32
46.36.193.226/31
46.36.193.228/31
46.136.173.0/24
50.22.63.8/29
50.22.63.16/29
50.22.124.208/29
50.22.125.64/27
50.22.125.128/27
50.22.125.192/27
50.22.185.96/29
etc.

Yadutaf
14/04/2012, 20h13
Oui, pas mal. J'essaierai bien quelque chose comme ça lorsqu'on remettra le site en route, sans doute demain. A part sudo sur une Gentoo ...

En attendant, j'ai quand même écrit à OVH pour leur demander si ils peuvent me proposer quelque chose et je vais aussi bloquer le Mexique et le Brésil par le .htaccess pour voir si les attaques diminuent quand même.

Merci pour vos réponses.

cassiopee
14/04/2012, 19h15
Voilà, voilà, là on a beaucoup plus d'infos

Une idée de contre-mesure possible :

J'ai eu l'occasion que de faire ça dans un site web où le pirate s'acharnait
à trouver un phpMyAdmin installé.

Résultat, j'ai écrit un petit bout de code de ce genre :

Code PHP:

  $adresse_ip 
$_SERVER["REMOTE_ADDR"];

  
$cmd "/usr/bin/sudo /usr/sbin/iptables -I INPUT 1 -s $adresse_ip -j DROP";
  
$chaine system($cmd,$retval);

  
// On note dans un fichier de log l'adresse IP bannie

  
$mydate date("Y/m/d H:i:s");
  
$msg "$mydate IP bannie : $adresse_ip\n";

  
$filename "/tmp/ban.log";

  if (!
$handle fopen($filename'a'))
  {
     print 
"Impossible d'ouvrir le fichier ($filename)";
     exit;
  }

  if (
fwrite($handle$msg) === FALSE)
  {
     print 
"Impossible d'écrire dans le fichier ($filename)";
     exit;
  }

  
fclose($handle);

?>
qui peut être sauvé dans "deck/stop.jsp" et "deck/contact.jsp" (*).

De cette façon, toute adresse IP appelant ce script ne fera qu'une seule chose :
se bannir elle-même

Au bout de quelques heures/minutes, l'attaque cessera faute de combattant.

(*) s'assurer au préalable avec un code PHP neutre qu'un script PHP
peut être exécuté avec une extension ".jsp" par le serveur web.

Il faut éventuellement adapter les chemins absolus menant aux commandes
"sudo" et "iptables".

Yadutaf
14/04/2012, 19h06
J'ai fait un sondage sur une dizaine d'adresses. La plupart sont enregistrées au Mexique mais il y en a aussi sur d'autres pays d'Amérique latine (Brésil, Saint-Domingue, ...) et aux Etats-Unis.

Couper le Mexique et Saint Domingue n'est pas très gênant mais le Brésil ou les US si car il y a des clients dans ces deux pays.

Vu aussi des adresses venant du Canada, du Portugal, des Pays-Bas, d'Allemagne, d'Espagne ...

Yadutaf
14/04/2012, 18h41
Citation Envoyé par cassiopee
Tout ça manque de beaucoup de détails pour qu'on puisse t'aider davantage :

1) De quelle genre de "faille" parles-tu précisément ? Sans donner une URL
bien entendu, juste le type/la nature de la faille. Une injection SQL ?
Un script qui mange tout le CPU si on l'appelle X fois par minute ?
Faille du caractère NULL. A priori résolue mais de toute façon le script php incriminé n'est plus en ligne depuis jeudi soir remplacé par une simple page html (voir mon message précédent).
Citation Envoyé par cassiopee

2) Le fichier de log : de quelle application ? Apache ?
Quel genre de connexions ? TCP ? UDP ? Qu'est-ce qui est visé ?
Une URL du site web d'e-commerce ? Est-ce toujours la même URL
qui est appelée ?
Je parle du fichier de log du site /home/log/httpd/monuserdusite-access_log (51Mb à 18h30 soit +4 Mb en 1 heure).
Voici quelques lignes du fichiers de log :
Code:
...
187.92.195.123 - - [13/Apr/2012:03:39:43 +0200] "GET /deck/stop.jsp HTTP/1.0" 404 322 "-" "InetURL:/1.0"
187.113.173.78 - - [13/Apr/2012:03:39:43 +0200] "GET /deck/contact.jsp HTTP/1.1" 404 325 "-" "InetURL:/1.0"
177.119.180.87 - - [13/Apr/2012:03:39:43 +0200] "GET /deck/stop.jsp HTTP/1.1" 404 322 "-" "Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0"
...
91.151.67.1 - - [13/Apr/2012:10:49:14 +0200] "GET /deck/stop.jsp HTTP/1.1" 404 322 "-" "InetURL:/1.0"
187.126.154.178 - - [13/Apr/2012:10:49:14 +0200] "GET /deck/stop.jsp HTTP/1.1" 404 322 "-" "InetURL:/1.0"
177.25.192.58 - - [13/Apr/2012:10:49:14 +0200] "GET /deck/stop.jsp HTTP/1.1" 404 322 "-" "InetURL:/1.0"
187.102.230.236 - - [13/Apr/2012:10:49:14 +0200] "GET /deck/stop.jsp HTTP/1.0" 404 322 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Win32; Trident/5.0)"
177.78.198.110 - - [13/Apr/2012:10:49:14 +0200] "GET /deck/contact.jsp HTTP/1.1" 404 325 "-" "InetURL:/1.0"
187.114.148.158 - - [13/Apr/2012:10:49:15 +0200] "GET /deck/stop.jsp HTTP/1.1" 404 322 "-" "-"
177.40.84.163 - - [13/Apr/2012:10:49:15 +0200] "GET /deck/stop.jsp HTTP/1.1" 404 322 "-" "InetURL:/1.0"

Yadutaf
14/04/2012, 18h28
Citation Envoyé par cassiopee
De quelle genre de "faille" parles-tu précisément ?

Parce que mettre une limite à "tant de connexions par minute" c'est surtout
utile pour limiter une attaque de type DDoS (Distributed Denial Of Service) où
l'attaquant bombarde de requêtes le serveur afin de le mettre hors service.

En principe une faille, mettons de type "injection SQL", ne nécessite
qu'une seule tentative (ou un tout petit nombre) pour rentrer dans le serveur
donc mettre une limite en nombre de connexions par minute ne devrait pas
être utile ?
Je n'avais pas vu que nous avions changé de page donc pas vu ta réponse avant de poster la mienne. A priori, le hacker à utilisé la fameuse faille du caractère NULL de php pour installer au moins 2 fichiers indésirables qui lui permettait de faire du phishing. Nous avons sans doute repéré et corrigé cette faille.

En attendant, nous avons supprimé le script corrompu de notre serveur (donc les fichiers indésirables) pour y installer une simple page html avertissant nos visiteurs que nous sommes en maintenance et qu'ils sont bien aimables d'être aussi patients devant notre notoire incompétence §

Depuis ce moment, il continue à bombarder le site à la recherche de ces deux fichiers mais ne reçoit en retour qu'une erreur 404. En fait cela revient maintenant à une attaque DDoS. Mon idée de blocage automatique de ce matin ne pourra pas marcher car il utilise des milliers d'IP différentes pour attaquer mais chaque IP n'est utilisée qu'1 ou 2 fois par minute.

Ca c'est pour répondre à Cassiopée. Je vais maintenant prendre connaissance des messages suivants qui n'auront pas manqués. Je vous remercie.

cassiopee
14/04/2012, 18h10
Citation Envoyé par Yadutaf
Bonne nouvelle, nous avons sans doute trouvé la faille et y avons remédié. Peut-être ...

Par contre, le blocage des IPs ne marche pas. Le serveur continue à être
bombardé plusieurs milliers de fois par minute par des adresses IPs
différentes. Le fichier de log, qui pesait 43 mb (!) à 16h30, fait 47 mb à
17h35 et la simple page html d'attente ne s'affiche plus. Ça ressemble à du déni de service, non ?
Tout ça manque de beaucoup de détails pour qu'on puisse t'aider davantage :

1) De quelle genre de "faille" parles-tu précisément ? Sans donner une URL
bien entendu, juste le type/la nature de la faille. Une injection SQL ?
Un script qui mange tout le CPU si on l'appelle X fois par minute ?

2) Le fichier de log : de quelle application ? Apache ?
Quel genre de connexions ? TCP ? UDP ? Qu'est-ce qui est visé ?
Une URL du site web d'e-commerce ? Est-ce toujours la même URL
qui est appelée ?

loreleil
14/04/2012, 17h47
Salut,

Rhôoo, dans la pratique, ce que je ferai ...

Dans l'hypothèse que cette ip 31.31.176.0 me tarabuste depuis quelques heures ...

Un p'tit whois m'indique son pays d'origine probable.

Code:
:~# whois 31.31.176.0
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '31.31.176.0 - 31.31.183.255'

inetnum:         31.31.176.0 - 31.31.183.255
netname:         YEMEN-NET-ADSL-POOL8
descr:           YemenNet ADSL POOL
country:         YE
admin-c:         YAA330-RIPE
tech-c:          IIA13-RIPE
status:          ASSIGNED PA
mnt-by:          YEMEN-NET-MNT
source:          RIPE # Filtered

person:         Ibrahim I. Alsaigal
address:        Public Telecommunication Corporation
address:        Airport Street, P.O. Box 17045
address:        Sana'a , YE
phone:          +967 777013002
nic-hdl:        IIA13-RIPE
mnt-by:         YEMEN-NET-MNT
source:         RIPE # Filtered

person:         Yasser A. Al-emad
address:        Public Telecommunication Corporation
address:        Airport Street, P.O. Box 17045
address:        Sana'a , YE
phone:          +967 777011330
fax-no:         +967 1 331350
nic-hdl:        YAA330-RIPE
mnt-by:         YEMEN-NET-MNT
source:         RIPE # Filtered

% Information related to '31.31.176.0/21AS12486'

route:           31.31.176.0/21
descr:           YENENNET Dynamic ADSL IPs
origin:          AS12486
mnt-by:          YEMEN-NET-MNT
source:          RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.6.9 (WHOIS3)

:~#
De là, je cours me rendre ici https://www.countryipblocks.net/country_selection.php et sélectionne le format .htaccess Deny ...

Citation Envoyé par Create Country ACL
# Copyright © 2012 Country IP Blocks LLC
#all rights reserved.
#This list may not be redistributed in any form.
#this list includes network data on the following countries:
#YEMEN

order allow,deny
deny from 31.31.176.0/20
deny from 46.35.64.0/19
deny from 82.114.160.0/19
deny from 89.189.64.0/19
deny from 109.74.32.0/20
deny from 109.200.160.0/19
deny from 131.117.160.0/21
deny from 195.94.0.0/19
allow from all
Liste, que j'intégrerai dans mon fichier .htaccess tout simplement ...


# nano -c .htaccess

[ ligne 1/125984 (0%), col. 1/26 (3%), car. 0/3258870 (0%) ]
Côté iptables ...

Code:
...

########################################################

# création de notre chaîne w00t : utiliser iptables pour bloquer les chaines de caractères (2e partie) >> http://spamcleaner.org/fr/misc/w00tw00t2.html
iptables -N w00t
#echo "-Création de notre chaîne w00t : utiliser iptables pour bloquer les chaines de caractères : [OK]"

# redirige les paquets TCP sur notre chaîne :
iptables -A INPUT -p tcp -j w00t
#echo "-Redirige les paquets TCP sur notre chaîne : [OK]"

# recherche du premier SYN et création de la liste :
iptables -A w00t -m recent -p tcp --syn --dport 80 --set
#echo "-Recherche du premier SYN et création de la liste : [OK]"

# recherche du paquet SYN,ACK et mise à jour la liste :
iptables -A w00t -m recent -p tcp --tcp-flags PSH,SYN,ACK SYN,ACK --sport 80 --update
#echo "-Recherche du paquet SYN,ACK et mise à jour la liste : [OK]"

# recherche du paquet ACK et mise à jour la liste
iptables -A w00t -m recent -p tcp --tcp-flags PSH,SYN,ACK ACK --dport 80 --update
#echo "-Recherche du paquet ACK et mise à jour la liste : [OK]"

# recherche de la signature de DFind dans le prenier PSH+ACK.
# Si elle est présente, on DROP.
# On supprime la liste pour ne pas filtrer les paquets suivants
iptables -A w00t -m recent -p tcp --tcp-flags PSH,ACK PSH,ACK --dport 80 --remove -m string --to 70 --algo bm --string "GET /w00tw00t.at.ISC.SANS." -j DROP
#echo "-Recherche de la signature de DFind dans le prenier PSH+ACK : [OK]"

# 1ere règle sur le paquet + MAJ de la liste :
iptables -A w00t -m recent -p tcp --tcp-flags PSH,ACK PSH,ACK --dport 80 --update -m string --to 70 --algo bm --string "GET /w00tw00t.at.ISC.SANS." -j DROP
#echo "-1ere règle sur le paquet + MAJ de la liste : [OK]"

# 2e règle sur même paquet + suppression de la liste :
iptables -A w00t -m recent -p tcp --tcp-flags PSH,ACK PSH,ACK --dport 80 --remove -m string --to 700 --algo bm --string 'Host: 91.121.x.x' -j DROP
#echo "-2e règle sur même paquet + suppression de la liste  : [OK]"

# vérifie si l'IP est déjà présente dans la liste w00tlist.
# Si c'est la cas, on la rejette immédiatement, met à jour la liste et
# l'attaquant est de nouveau blacklisté pour 6h :
iptables -A INPUT -p tcp -m recent --name w00tlist --update --seconds 21600 -j DROP
#echo "-Vérifie si l'IP est déjà présente dans la liste w00tlist  : [OK]"

# création de la chaine w00tchain qui rajoute l'IP
# à la liste w00tlist et reset la connexion (ne pas oublier le paramètre
# '-p tcp' indispensable pour l'utilisation de '--reject-with tcp-reset') :
iptables -N w00tchain
iptables -A w00tchain -m recent --set --name w00tlist -p tcp -j REJECT --reject-with tcp-reset
#echo "-Création de la chaine w00tchain qui rajoute l'IP à la liste w00tlist et reset la connexion  : [OK]"

# recherche de la signature hexadécimale dans le prenier PSH+ACK.
# Si elle est présente, on renvoie sur w00tchain pour blacklister et
# terminer la connexion.
# On supprime la liste pour ne pas filtrer les paquets suivants :
iptables -A w00t -m recent -p tcp --tcp-flags PSH,ACK PSH,ACK --dport 80 --remove -m string --to 80 --algo bm --hex-string '|485454502f312e310d0a0d0a|' -j w00tchain
#echo "-Recherche de la signature hexadécimale dans le prenier PSH+ACK  : [OK]"
###################################################################################################
########               METTRE ICI LES RÈGLES DE BLOCAGE PERSONNEL
###################################################################################################

...

Yadutaf
14/04/2012, 17h43
Bonne nouvelle, nous avons sans doute trouvé la faille et y avons remédié. Peut-être ...

Par contre, le blocage des IPs ne marche pas. Le serveur continue à être bombardé plusieurs milliers de fois par minute par des adresses IPs différentes. Le fichier de log, qui pesait 43 mb (!) à 16h30, fait 47 mb à 17h35 et la simple page html d'attente ne s'affiche plus. Ça ressemble à du déni de service, non ?

cassiopee
14/04/2012, 13h47
De quelle genre de "faille" parles-tu précisément ?

Parce que mettre une limite à "tant de connexions par minute" c'est surtout
utile pour limiter une attaque de type DDoS (Distributed Denial Of Service) où
l'attaquant bombarde de requêtes le serveur afin de le mettre hors service.

En principe une faille, mettons de type "injection SQL", ne nécessite
qu'une seule tentative (ou un tout petit nombre) pour rentrer dans le serveur
donc mettre une limite en nombre de connexions par minute ne devrait pas
être utile ?

Yadutaf
14/04/2012, 13h18
Cette liste est extraite des logs. Je ne suis sûr de rien. Les gars qui se penchent sur la faille disent qu'ils l'ont peut-être trouvée mais pour l'instant il semble qu'ils n'aient pas encore trouvé la solution.

Freemaster
14/04/2012, 12h59
ceci dit es-tu sur de la légitimité de ces adresse ip ?
avec un outil de spoof ip aléatoire, la source pouvait venir d'une seule... et en bloquant en masse ces ip, tu risques de rendre inaccessible ton e-commerce à des acheteurs potentiels... c'est le patron qui va être content

Yadutaf
14/04/2012, 12h49
Citation Envoyé par Freemaster
...
en gros il a répondu à ta première question, mais pas à la deuxième pour les futures ip qui bombarde
Oui, c'est ça mais c'est un bon début et je l'en remercie. Je vais m'appliquer à l'employer immédiatement.
Cependant cela ne résoudra que très provisoirement mon problème de fond. Si ma deuxième idée était applicable, ce serait plus intéressant. Qu'en pensez-vous ?

Freemaster
14/04/2012, 12h40
liste-ips.txt c'est ta liste de 4200 ip... à créer toi même
tu le mets où tu veux, et adapter le chemin cat /home/toto/liste-ips.txt

en gros il a répondu à ta première question, mais pas à la deuxième pour les futures ip qui bombarde

Yadutaf
14/04/2012, 12h20
Merci nopnop. Cela devrait marcher. Juste une recommandation : où vaut-il mieux placer le fichier liste-ip.txt ? Peux-t'on le mettre dans le home du root ?

nopnop
14/04/2012, 11h50
for ip in $(cat liste-ips.txt ); do iptables -A INPUT -s $ip -j DROP ; done

Yadutaf
14/04/2012, 11h48
Dans iptables, il serait possible de concevoir une règle pour bloquer automatiquement les adresses qui bombardent le port http. Comme cela par exemple :

Code:
iptables -A INPUT -i eth0 -p tcp --dport  -m state --state NEW -m recent --set --name HTTP
iptables -A INPUT -i eth0 -p tcp --dport  -m state --state NEW -m recent --update --seconds 60 --hitcount 10 --rttl --name HTTP -j DROP
Il faudrait cependant trouver le bon seuil, ici 10 tentatives par minutes. Je ne sais pas si c'est une bonne idée.

Yadutaf
14/04/2012, 11h43
Citation Envoyé par AR51Kevinos
.htaccess

deny from all
allow from IP1
allow from IP2
ect...
Dans ce cas, ce serait plutôt le contraire :

allow from all
deny from IP1
deny from IP2
etc...

C'est un site de e-commerce. Si je commence par l'interdire à tout le monde, le patron va me pourrir rapidement, juste avant de se rendre au tribunal de commerce pour le dépôt de bilan !

AR51Kevinos
14/04/2012, 11h05
.htaccess

deny from all
allow from IP1
allow from IP2
ect...

Yadutaf
14/04/2012, 10h42
Bonjour à tous,

Notre site a été compromis et nous avons été obligé de le suspendre en attendant de trouver la faille et d'y avoir remédié.

Cependant j'aimerai pouvoir le remettre en route en bloquant les adresses IP qui servent à notre cher ami pour plomber notre serveur. Ceci me permettra sans doute de remettre le site en route ce qui est vital pour l'entreprise.

Je connais la commande pour bloquer une IP :
iptables -A INPUT -s -j DROP

mais j'ai une jolie petite liste de presque 4200 adresses à envoyer et je me vois mal répéter cette commande autant de fois. Y a-t-il une solution pour envoyer cette liste en une seule commande ? Il est bien évident que ce ne sont pas des adresses contiguës faisant partie du même réseau. Trop simple !

Distribution : release 2 OVH