Pourquoi iptables ne bloque-t-il pas une adresse IP?

9

J'ai configuré fail2ban pour surveiller un certain modèle de trafic malveillant que j'obtiens et interdire les adresses IP associées.

Tout semble très bien fonctionner - l'expression régulière correspond au modèle de manière appropriée et l'adresse IP problématique est ajoutée à iptables.

Cependant, lorsque je vérifie les journaux Apache, je reçois toujours des hits de l'adresse IP qui est interdite. C'est comme si iptables ne fonctionnait pas du tout.

Permettez-moi donc de partager quelques détails juste pour confirmer que tout est correctement configuré.

Tout d'abord, je vais effacer et recharger les règles iptables:

$ sudo iptables -F
$ cat /etc/iptables.firewall.rules 
*filter

#  Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

#  Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

#  Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

#  Allow SSH connections
#
#  The -dport number should be the same port number you set in sshd_config
#
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

#  Allow ping
-A INPUT -p icmp -j ACCEPT

#  Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

#  Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT
$ sudo iptables-restore < /etc/iptables.firewall.rules
$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      *       0.0.0.0/0            127.0.0.0/8          reject-with icmp-port-unreachable
   14  1432 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    1    60 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   11  1638 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Maintenant, voici à quoi ressemble la configuration fail2ban:

$ cat /etc/fail2ban/filter.d/apache-xmlrpc.conf 
[Definition]
failregex = .*:80 <HOST> .*POST .*xmlrpc\.php.*
ignoreregex =
$ cat /etc/fail2ban/jail.local 
[apache-xmlrpc]

enabled  = true
port     = http,https
filter   = apache-xmlrpc
logpath  = /var/log/apache2/other_vhosts_access.log
maxretry = 6
$ fail2ban-regex /var/log/apache2/other_vhosts_access.log /etc/fail2ban/filter.d/apache-xmlrpc.conf 

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/apache-xmlrpc.conf
Use log file   : /var/log/apache2/other_vhosts_access.log


Results
=======

Failregex
|- Regular expressions:
|  [1] .*:80 <HOST> .*POST .*xmlrpc\.php.*
|
`- Number of matches:
   [1] 29 match(es)

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

Summary
=======

Addresses found:
[1]
    80.82.70.239 (Sat Jul 13 02:41:52 2013)
    80.82.70.239 (Sat Jul 13 02:41:53 2013)
    80.82.70.239 (Sat Jul 13 02:41:55 2013)
    80.82.70.239 (Sat Jul 13 02:41:56 2013)
    80.82.70.239 (Sat Jul 13 02:41:57 2013)
    80.82.70.239 (Sat Jul 13 02:41:58 2013)
    80.82.70.239 (Sat Jul 13 02:41:59 2013)
    80.82.70.239 (Sat Jul 13 02:42:00 2013)
    80.82.70.239 (Sat Jul 13 02:42:02 2013)
    80.82.70.239 (Sat Jul 13 02:42:03 2013)
    80.82.70.239 (Sat Jul 13 02:42:04 2013)
    80.82.70.239 (Sat Jul 13 02:42:05 2013)
    80.82.70.239 (Sat Jul 13 02:42:06 2013)
    80.82.70.239 (Sat Jul 13 02:42:07 2013)
    80.82.70.239 (Sat Jul 13 02:42:09 2013)
    80.82.70.239 (Sat Jul 13 02:42:10 2013)
    80.82.70.239 (Sat Jul 13 02:42:11 2013)
    80.82.70.239 (Sat Jul 13 02:42:12 2013)
    80.82.70.239 (Sat Jul 13 02:42:13 2013)
    80.82.70.239 (Sat Jul 13 02:42:15 2013)
    80.82.70.239 (Sat Jul 13 02:42:16 2013)
    80.82.70.239 (Sat Jul 13 02:42:17 2013)
    80.82.70.239 (Sat Jul 13 02:42:18 2013)
    80.82.70.239 (Sat Jul 13 02:42:19 2013)
    80.82.70.239 (Sat Jul 13 02:42:20 2013)
    80.82.70.239 (Sat Jul 13 02:42:22 2013)
    80.82.70.239 (Sat Jul 13 02:42:23 2013)
    80.82.70.239 (Sat Jul 13 02:42:24 2013)
    80.82.70.239 (Sat Jul 13 02:42:25 2013)

Date template hits:
0 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
70 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): 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): <Month/Day/Year@Hour:Minute:Second>

Success, the total number of match is 29

However, look at the above section 'Running tests' which could contain important
information.

Comme vous pouvez le voir, j'ai un failregex configuré dans un filtre et le filtre est activé. À l'aide de fail2ban-regex, le filtre trouve une correspondance dans le fichier journal que je surveille. (Je suis actuellement frappé par une adresse IP problématique, ce qui rend les tests assez faciles.)

Alors maintenant, je redémarre fail2ban et j'observe les règles qui prennent effet:

$ sudo service fail2ban restart
 * Restarting authentication failure monitor fail2ban                                                                                                                         [ OK ] 
$ tail /var/log/fail2ban.log -n 50
2013-07-13 02:42:58,014 fail2ban.server : INFO   Stopping all jails
2013-07-13 02:42:58,745 fail2ban.jail   : INFO   Jail 'apache-xmlrpc' stopped
2013-07-13 02:42:59,439 fail2ban.jail   : INFO   Jail 'ssh' stopped
2013-07-13 02:42:59,440 fail2ban.server : INFO   Exiting Fail2ban
2013-07-13 02:43:08,055 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.6
2013-07-13 02:43:08,057 fail2ban.jail   : INFO   Creating new jail 'ssh'
2013-07-13 02:43:08,111 fail2ban.jail   : INFO   Jail 'ssh' uses Gamin
2013-07-13 02:43:08,397 fail2ban.filter : INFO   Added logfile = /var/log/auth.log
2013-07-13 02:43:08,404 fail2ban.filter : INFO   Set maxRetry = 6
2013-07-13 02:43:08,414 fail2ban.filter : INFO   Set findtime = 600
2013-07-13 02:43:08,435 fail2ban.actions: INFO   Set banTime = 600
2013-07-13 02:43:09,277 fail2ban.jail   : INFO   Creating new jail 'apache-xmlrpc'
2013-07-13 02:43:09,277 fail2ban.jail   : INFO   Jail 'apache-xmlrpc' uses Gamin
2013-07-13 02:43:09,283 fail2ban.filter : INFO   Added logfile = /var/log/apache2/other_vhosts_access.log
2013-07-13 02:43:09,286 fail2ban.filter : INFO   Set maxRetry = 6
2013-07-13 02:43:09,289 fail2ban.filter : INFO   Set findtime = 600
2013-07-13 02:43:09,292 fail2ban.actions: INFO   Set banTime = 600
2013-07-13 02:43:09,458 fail2ban.jail   : INFO   Jail 'ssh' started
2013-07-13 02:43:09,792 fail2ban.jail   : INFO   Jail 'apache-xmlrpc' started
2013-07-13 02:43:11,361 fail2ban.actions: WARNING [apache-xmlrpc] Ban 80.82.70.239
$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  244 39277 fail2ban-apache-xmlrpc  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
  101  7716 fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      *       0.0.0.0/0            127.0.0.0/8          reject-with icmp-port-unreachable
 3404  582K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  349 20900 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
   12   720 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
    2    80 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
    2    80 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3331 4393K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-apache-xmlrpc (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       80.82.70.239         0.0.0.0/0           
  244 39277 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       223.4.147.8          0.0.0.0/0           
  101  7716 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Comme le journal fail2ban le montre, le jeu de règles semble être configuré correctement. Vous pouvez déjà voir que l'adresse IP problématique est immédiatement capturée et interdite. La sortie d'iptables montre qu'elle est en fait en train d'être supprimée.

Cependant, j'observe déjà qu'il n'y a pas de paquets perdus pour cette adresse IP qui correspond sous la chaîne fail2ban-apache-xmlrpc. Effectivement, je vérifie les journaux apache:

$ tail /var/log/apache2/other_vhosts_access.log
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:53 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:54 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:56 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:57 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:58 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:59 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:44:00 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:44:02 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"

Non, ça ne se bloque pas! Je peux également le confirmer dans le journal fail2ban:

$ tail /var/log/fail2ban.log
2013-07-13 02:52:30,757 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:37,767 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:44,783 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:51,814 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:58,830 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:53:05,842 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:53:11,858 fail2ban.actions: WARNING [apache-xmlrpc] Unban 80.82.70.239
2013-07-13 02:53:12,910 fail2ban.actions: WARNING [apache-xmlrpc] Ban 80.82.70.239
2013-07-13 02:53:20,118 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:53:27,129 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned

Il réapparaît constamment dans le journal d'apache et donc fail2ban essaie de continuer à l'interdire!

Honnêtement, je ne peux pas comprendre pour la vie de moi pourquoi iptables ne perd pas le trafic de cette adresse IP. L'ordre des règles me semble correct, avec le DROP avant tout.

J'ai Google un tas de résultats où les gens ont un problème similaire, mais il semble toujours revenir à un problème d'interdiction du trafic SSH lorsqu'ils se trouvent sur un port non standard. Dans mon cas, j'essaie simplement d'interdire une adresse IP sur le port http standard 80.

J'espère que je suis en train d'oublier quelque chose de incroyablement simple. Il s'agit d'un VPS exécutant Ubuntu 12.04 sur Linode. Si quelqu'un a des idées, faites-le moi savoir. Merci beaucoup...

EDIT : Voici la sortie deiptables -S

$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-apache-xmlrpc
-N fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-xmlrpc
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j ACCEPT
-A fail2ban-apache-xmlrpc -s 80.82.70.239/32 -j DROP
-A fail2ban-apache-xmlrpc -j RETURN
-A fail2ban-ssh -s 223.4.147.8/32 -j DROP
-A fail2ban-ssh -j RETURN
ubuntu  iptables  fail2ban 
— jsdalton
source
La sortie de iptables -speut nous être plus utile que le format deiptables -L
— Daniel Widrick
@ lVlint67 - J'ai édité ma question pour montrer la sortie de iptables -Spour vous. Faites-moi savoir si cela vous donne un aperçu supplémentaire.
— jsdalton
La dernière entrée du journal Apache est à 02:44:02 et le premier message fail2ban que l'adresse IP a été interdite est à 02:52:30, donc je ne vois aucune preuve que cela ne fonctionne pas. Veuillez fournir le fail2ban.log complet pour la période.
— mgorven
La première interdiction que je vois dans le journal fail2ban était à 2:43 mais j'ai également remarqué des écarts de temps. REMARQUE: l'interdiction se produit dans le So now I restart fail2ban and observe the rules taking effect:bloc
— Daniel Widrick

Réponses:

10

La iptables -ssortie semble correcte et je ne sais pas comment 80.82.70.239/32va any:80sur votre serveur via le pare-feu. Ma première supposition est que vous avez un proxy / équilibreur de charge devant le serveur et Apache enregistre l'en- HTTP_X_FORWARDED_FORtête ou ce que l'on appelle. Si cela s'avère être le cas, vous devrez déplacer votre logique de pare-feu vers le proxy / équilibreur de charge ou vers le bas au niveau de l'application (Apache mathing l'en- FORWARDED_FORtête et refuser l'accès.

D'une manière ou d'une autre:

Le prochain plan d'action que je prendrais, est de capturer la sortie de iptables -svous postée ci-dessus. Désactivez fail2ban et chargez la configuration avec la chaîne fail2ban et l'adresse IP bloquées dans iptables.

Mais faites-le avec la -Arègle suivante comme première règle:

-A INPUT -p tcp --dport 80 -j LOG --log-prefix "HTTP: "

Si vous vous sentez mieux piéger 80 et 443 allez-y. L'idée est que les journaux du PARE-FEU peuvent montrer quelque chose qui nous manque si nous prêtons attention aux paquets provenant de sources suspectes.

— Daniel Widrick
source
3
Vous avez réussi. Je ne sais pas pourquoi je n'y avais pas pensé avant. Apache est en retard Cloudflare et je ne qu'Apache configuré pour enregistrer l'adresse IP HTTP_FORWARDED_FOR. Le trafic réel arrive via le serveur Cloudflare - donc essayer de le bloquer en utilisant fail2ban / iptables ne fonctionnera pas. Je vous remercie!
— jsdalton
Nous utilisons des équilibreurs de charge haproxy sur le campus pour gérer LB et HA, donc je me suis familiarisé avec les petites «bizarreries» que la configuration apporte. Je ne sais pas ce qu'est Cloudflare, mais si vous avez un accès approprié, déplacer l'interdiction vers l'équilibreur de charge peut être possible. ... Si ce n'est pas possible, Apache peut être capable de gérer le blocage avec une certaine méthode mais je ne le connais pas du haut de ma tête.
— Daniel Widrick
@jsdalton Quelle a été la solution avec laquelle vous vous êtes retrouvé. Dans un bateau similaire moi-même en ce moment.
— Jay
@jay Puisque vous devez examiner les en-têtes http, vous cherchez quelque chose appelé filtrage "Layer 7" ou pare-feu. Sinon, vous pouvez essayer de bloquer les tentatives d'équilibreur de charge / proxy si cela est sous votre contrôle.
— Daniel Widrick
1

La sortie d'iptables montre en fait que bien qu'il existe une règle pour l'adresse IP, fail2ban estime que doit être filtré et supprimé, aucun paquet n'est passé par la chaîne xmlrpc fail2ban et a été effectivement supprimé par cette règle. Au lieu de cela, tous les 224 paquets qui sont passés par cette chaîne ont été acceptés.

Cela dit, les règles sont en effet correctes. Cependant, plus de trafic semble avoir été accepté par votre règle d'acceptation du port TCP 80 que par la chaîne de filtrage fail2ban. La raison la plus probable est que le trafic que vous vouliez bloquer est entré alors que la chaîne fail2ban n'était pas encore insérée en entrée (je remarque que vous ne l'avez pas dans vos règles par défaut, ce qui est probablement OK, mais cela signifie que si vous rechargez iptables la chaîne fail2ban ne sera pas en vigueur immédiatement).

Essayez d'exécuter iptables -zà zéro le nombre de paquets et observez à nouveau la sortie de iptables -nvL. La sortie ne doit pas être la même. En outre, envisagez d'enregistrer les règles pour les chaînes fail2ban dans les règles initiales pour iptables ( /etc/iptables.firewall.rules). Enregistrez les règles de délégation comme celle-ci:

fail2ban-apache-xmlrpc  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443

Enregistrez également l'existence des chaînes (comme fail2ban-apache-xmlrpc), mais ne sauvegardez pas les adresses IP réellement interdites.

— Falcon Momot
source
Merci Falcon. C'est probablement parce que j'ai vidé les règles iptables, puis il a fallu quelques instants avant de redémarrer fail2ban et les règles fail2ban-apache-xmlrpc ont été ajoutées. Néanmoins, j'ai essayé de mettre à zéro le nombre de paquets et de revérifier. Le résultat était à peu près le même. Tous les paquets entrant dans les règles fail2ban-apache-xmlrpc sont RETOURNÉS et aucun n'est DROP. J'ai confirmé que mes journaux Apache montrent du trafic entrant toujours sur cette adresse IP qu'il devrait supprimer.
— jsdalton
1

J'ai eu exactement le même problème que le vôtre sur mon propre site Web. Configuration très similaire, pile LAMP, quelques prisons fail2ban fonctionnelles, mais j'ai quand même vu ces adresses IP soi-disant interdites apparaître dans le fichier journal d'accès. Je n'ai aucun proxy / équilibreur de charge devant Apache.

La solution à mon problème était étonnamment simple: déplacez les instructions d'interdiction en haut du fichier de configuration iptables!

— Haidong
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.