Discussion :

[Beanux]

Bonjour,
comme expliqué dans le titre, mon serveur subit une attaque ddos, donc pas de règles iptables pour y parer, un parfeu matériel y travaille, mais lutte, et mon hébergeur (que j'ai justement choisit pour cela) m'aide énormément, en redirigeant les adresses ip qui me m''attaquent. Pour les détail, c'est un "bête" syn flood en tcp sur un protocole particulier (trop particulier pour être connu, et sur lequel je n'ai pas de possibilité de modification), avec des ping assez régulier pour vérifier l’état du service.

Le soucis n'est pas vraiment la, mais plus dans l'origine de l'attaque. J'ai supposé que c’était a l'origine un réseau botnet (ou quelque chose approchant), mais avec la quantités d'ip, et la quantité de bande passante utilisé (presque 10Gb/s), je me suis interrogé sur d'autre sources potentielles.

Il m'est malheureusement venu a l'idée que cela pourrait venir de serveur en ligne, avec une bande passante élevée, qui enverraient des paquets craftés (en gros de l'ip spoofing, couplé a du ddos). Ce n’est que pur supposition de ma part, mais j'aurais voulu avoir des conseils sur la manière d'identifier la (même) provenance des paquets via OSfingerprinting, ou adresse mac. En gros en analysant les paquets reçus. L'analyse en question ne serais pas forcément faite a la volée à la base, mais servirais déterminer si oui ou non, les paquets provienne d'un nombre restreint de machine ou non, pour ensuite être mise en pratique afin d'identifier les paquets illégitimes des autres


Donc pour résumé mes interrogations sont les suivantes:
Ce type d'attaque est-elle possible?
Si oui, est-il possible de les identifier? pas forcément identifier la source, mais distinguer les bonnes paquets des mauvais.


En vous remerciant d'avance pour l'aide potentiel que vous m'apporterez.

Edit: Après réflexion, les ping pourraient permettre de retracer les ip, vu qu'il faut recevoir une réponse, mais si possible j'aimerais pouvoir avoir des informations sur les questions malgré tout.

[Invité]

Salut,

Le fait que des attaques basées sur de l'IP Spoofing ou du DDoS saturent un lien 10 Gb/s me laisse perplexe...

Quelle est la vitesse d'accès de ton réseau vers ton FAI ? Si c'est par exemple un accès 1 Gb/s, comment un tel accès pourrait saturer un lien 10 Gb/s ?

A moins, effectivement, que les attaques prennent naissance dans ton réseau local. Mais si c'était le cas, ton FAI ne verrait pas les paquets d'attaque transiter sur son infrastrcuture avant d'entrer sur ton réseau local...

L'observation des adresses MAC ne donnera pas grand chose puisque les paquets d'attaque prendront comme MAC adresse la MAC adresse de la dernière gateway qui aura routé les paquets vers ton serveur, que les paquets aient été forgé ou non quelque part en amont de ton réseau.

Il y a un point de détail que je ne comprends pas : tu dis que ton FAI "redirige" les adresses IP qui attaquent et tu veux savoir comment identifier la provenance de ces attaques... Vous avez donc une liste d'adresses IP suspectes non ?

Quant à détecter si un paquet est légitime ou non, c'est très difficile, hormis le cas d'IP Spoofing facilement repérable (l'anti-spoofing est une protection qui devrait accompagner toute ressource exposée au net)... Il faut raisonner en terme de comportement. Par exemple, si une même adresse IP envoie 50 TCP SYN par minute vers ton serveur ou si elle "nmap" en permanence.

J'ai croisé 2 ou 3 fois ce cas de figure, et il y a peu de choses à faire... Il faut dans un premier temps installer des iptables avec la target LOG pour lister les adresses IP sources, analyser les logs et rejeter les tentatives de connexions émanant des adresses IP suspectes en émettant des TCP RST (point important parce que si les TCP SYN sont "silently dropped", l'attaquant peut croire que son objectif de saturation TCP est accompli, en revanche, s'il commence à recevoir des RST, il prend conscience qu'il est démasqué). Puis si les tentatives de connexions sont toujours présentes, alors oui, demander à ton FAI de dropper tout ce qui vient de ces adresses avant que ça n'arrive dans ton réseau.

Steph

[Beanux]

Je me suis mal fait comprendre, les 10Gb/s c’est en gros la quantité de donnée que nous recevons lors d’une attaque, pas celle du débit qui nous est alloué (donc nous bande passante est saturée). La quantité de paquet annoncée, est leur mesure du nombre de paquets a destination de l'ip de mon serveur à l'entrée de leur réseau (qui contient le notre et plusieurs autres).

la redirection des paquet se fait après analyse de leur part justement, puis est redirigée, donc une ip qui envoie des syn de manière abusive, est suspecte.
Pour ce qui est de leur détection des syn malicieux, oui il n'y a aucun problème avec iptables tant le réseau n'est pas saturé et que le système arrive a gérer tous les paquet entrant.

C'est simplement la détection de paquet spoofé ou non qui est problématique, vu que la redirection de paquet ne se fait pas automatiquement, mais faite "manuellement" ip par ip.

[Beanux]

Au final, j'ai opté pour un changement d'hébergeur.

Mais il semblerais qu'il n'y ai pas de solution contre le spoofing sur des ip qui n'appartiennent pas à votre "réseau local", ce qui semble assez préoccupant, et qui permet à n'importe qui de se faire passer pour n'importe qui.

Merci pour l'aide que tu m'as apporté tout de même

[Invité]

Mais il semblerais qu'il n'y ai pas de solution contre le spoofing sur des ip qui n'appartiennent pas à votre "réseau local"

Il en existe mais elles sont restrictives...

1) Bloquer les paquets IP entrants venant de l'Internet qui ont pour sources adresses :

- les adresses RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), - une adresse loopback 127.0.0.0/8,
- une adresse IP Multicast 224.0.0.0/3,
- une adresse APIPA-RFC5735 169.254.0.0/16,

Ces adresses sont communément appelées "bogons" et "martians"

En revanche, si l'attaquant utilise une adresse IP source routée sur l'Internet, ça passera au travers de ces Access-Lists bien sûr.

A noter que certains blocks IP, même s'ils sont en théorie routables dans l'Internet, ne sont pas routés... Cette liste est en constant changement, et l'équipe de Rob Thomas, appelée "Team Cymru", maintient cette liste à des fins de protection contre notamment le spoofing. Pour plus d'infos, cf

http://www.team-cymru.org/

2) Certains constructeurs de routeurs ont également implémenté une fonctionnalité appelée Unicast Reverse Path Forwarding mais c'est toujours très limitatif.

3) Enfin, pour info, dans les années 2000, les RFC 2827 et 3704 avaient été écrites pour donner quelques directions de "bonnes pratiques" concernant les protections contre l'IP Spoofing (ces documents sont également appelés des BCP, pour Best Current Practices).

En résumé, très peu de protections vraiment robustes dès lors que les adresses IP sources usurpées sont routées dans l'Internet.

Steph

[dahtah]

Salut Beanux,

Alors tu as quand meme des solutions:

• Comme le dit IP_Steph, il faut filtrer les adresses non-routables et les bloquer des l'entree du reseau. Une simple access-list fera l'affaire.
• Tu peux utiliser les syn cookies cote serveur. Ca allege la table d'etat necessaire a traquer les connections TCP
• Le plus important; il faut limiter le nombre de connections embryoniques par IP source. En gros tu mets une limite sur le nombre de connection TCP semi-ouverte par une meme IP source. Cela evite qu'une meme IP source puisse t'envoyer un grand nombre de SYN, et force l'attaquant a changer d'IP source. Le seuil adequat depend de ton application.
• Tu peux aussi reduire le timer pendant lequel la pile IP attend un SYN/ACK relatif a un SYN
• URPF est egalement une bonne solution, mais j'ai l'impression que tu ne controles pas le reseau.

Tout ca reduit quand meme grandement l'impact du DDoS. Il y a d'autres solutions, mais elles sont bases au niveau de l'architecture reseau que tu ne semble pas controller.
Je te laisse regarder les parametres sysctl a modifier, ainsi que les regles iptables.

Quant a identifier tes attaquants quant 'adresse source est spoofee, c'est difficile. Si l'attaquant ne fait que forger l'IP source, et ne change pas les characteristiques du paquet, tu peux avoir une vague idee de la source en fonction des attributs du paquet au niveau IP et TCP. Les OS n'utilise pas les memes valeurs par default. Par exemple le TTL permet de determiner la classe d'OS de maniere relativement fiable, de meme que la valeur de l'ISN TCP - les 8 premiers bits de l'ISN sont monotonique sur les distribs Linux pre 2011... Il y a d'autres characteristiques plus avancees si besoin, mais l'effort d'identification est relativement important.

[Invité]

Dahtah,

merci pour les infos complémentaires.

En quoi le TTL peut renseigner sur l'OS ?

Steph

[dahtah]

Salut Steph,

En quoi le TTL peut renseigner sur l'OS ?

La valeur initiale du TTL varie suivant l'OS. Ca te permet de connaitre vaguement le type d'OS ainsi que le nombre de hop entre toi et l'attaquant. Voila une URL un peu ancienne, mais tu comprendras l'idee.

En gros les valeurs initiales n'ont pas trop changees depuis les dernieres releases listees. GNU/Linux => 64, Windows => 128, Cisco => 255...

Bonus: tu peux appliquer a peu pres le meme principe au TCP MSS initial, qui varie aussi suivant les OS.
Si ca t'interesse de comprendre plus en details le "fingerprinting" passif, tu peux regarder plus en details les sources de pOf ou de la db d'OS de nmap.

A+

[Beanux]

Merci pour ces infos dahtah et steph,

j'avais déjà modifié les option via sysctl pour l'attente des syn par la pile. Ainsi que des règles de limitation de nouvelle connexion et de syn par secondes.

Je ne connaissait pas l'urpf, mais comme tu l'as dit, je n'ai qu'une machine, et pas de réseau.

Je n'ai pas pu mettre un place un système qui enregistre les paquets pour analyser la provenance des paquets, ce que je mettraient en place dès mon changement d’hébergeur (avec p0f par exemple). Mais selon certaines circonstances, il sera difficile de faire la différence entre une ferme de serveur, ou un réel réseau botnet

En fait, le problème est que même pour mon hébergeur, cela pose des soucis, il y a des problème de congestions de son réseau, donc au final, une solution de type firewall est insuffisante.


J'ai envisagé une solution pour me protéger, mais je bute encore sur un détail.
L'idée est de créer un vpn, avec une dizaine de passerelles minimum (en gros il faut que la somme de la bande passante des passerelles soit plus grande que celle de l'attaque). Ces entrée redirigent le trafic légitime et le limitent en meme temps (syn/s, new tcp/s, etc) vers le serveur dont le(s) services a protéger sont accessible uniquement par le vpn.
De là, les seul besoin à avoir seraient un firewall statefull, couplé a une limitation des paquets redirigés.

L'ip des passerelles serait obtenu via un dns à répartition de charge.

Pour que ce soit vraiment efficace, il faudrait que les entrée soient sur des réseaux différents (pas le même hébergeur) afin d’éviter qu'une attaque sature le réseau de 2 entrée en même temps.

Mon soucis est le suivant, il est facile de rediriger le trafic d'une passerelles sur le serveur avec iptables, en faisant de la nat. Mais le soucis est comment rediriger le trafic du serveur à destination de telle ip en passant par la même passerelle.

A mon sens ce type de solution serait peut être plus efficace contre le ddos qui exploite la faiblesse d'un réseau Hiérarchique.

ps: tout ceci n'est que de la réflexion et des tentative pour sortir de cette impasse, si cela semble totalement fantaisiste, ou qu'il y a des faiblesses majeurs la dedans, n'hésitez pas.

[dahtah]

Salut Beanux,

Ton idee a plusieurs incovenients selon moi, et de mon avis tu ne changeras rien au probleme:

• Tu vas avoir autant d'IP publique/machine/firewall que de points d'entrees => c'est cher et tres chiant a maintenir
• C'est pas dur pour un attaquant de recuperer les adresses de tes x points d'entrees en recuperant les adresses renvoyees par le dns. Apres flooder 10 adresses avec Y/10 debits compare a flooder 1 adresse avec Y debit, c'est du pareil au meme.
• Ton serveur DNS peut te retourner l'adresse d'un lien sature, vu qu'il n'est pas conscient de la charge sur chaque lien
• Point de detail, mais pas besoin de crypto sur tes liens entre tes points d'entrees et ton serveur si tu fait confiance au reseau, ou si tu as deja de l'encryption au niveau applicatif. Une simple emcapsulation IP in IP ou GRE suffira. Tu perds du volume de transfert inutilement sinon (76 bytes pour ESP en mode tunnel vs 24 bytes poyur GRE)

Je comprends pas trop ton probleme de route pour le traffic retour. Si tu utilises un tunnel, l'@ ip source sera changee en celle du tunnel, donc ton traffic retour prendra le meme chemin vu que tu seras L2 adjacent a travers le tunnel. Il faut par contre que tu fasses du NAT sur source (user => tunnel IP interieur) et destination (adresse publique serveur => address destination du serveur a l'interieur du tunnel).

En bref, pour moi, c'est pas a toi de gerer ca. Ton hebergeur te fournis un service, et doit faire en sorte de gerer ce genre d'attaque basique au niveau infrastructure - via SRTBH, solution dediee (Arbor, Guard...), peu importe. Pour moi ca fait parti du service, et changer pour un hebergeur qui t'apporte ce service semble raisonnable.

Bon courage...

[Beanux]

Tout à fait d'accord pour le fait que l’hébergeur doit gérer ça, mais après 5 hébergeurs différents (tous ayant lâché, mais 2 avec une politique d'aide contre le ddos), les dernières solutions sont hors de prix.

c'est cher et tres chiant a maintenir

Oui, mais ça l'est moins qu'un hébergeur te supportant dans une attaque ddos. Au moins 1000*€ par mois (généralement 3000-4000), alors que dans la solution que j'ai envisagée, le prix de reviens avec 10 passerelles seraient de l'ordre de 500-600€.

Apres flooder 10 adresses avec Y/10 debits compare a flooder 1 adresse avec Y debit, c'est du pareil au meme.

Justement non, la somme de la bande passante des passerelles (quelque chose comme 4GO/s avec 10 passerelles) sera supérieur à celle du serveur (500*Mo/s), et le traffic invalide ne sera pas redirigé, donc le traffic redirigé par les passerelles ne satureras pas le serveur au final (dans l'idéal bien sûr).

Ton serveur DNS peut te retourner l'adresse d'un lien sature, vu qu'il n'est pas conscient de la charge sur chaque lien

Oui c’est un point que je n'ai pas encore travaillé, mais qui pose des problèmes. J'ai envisagé d'essayer de gérer ça sans passer par le dns, mais cela donneraist une cible potentielle sur laquel repose tout le réseau.

Pour la crypto, je verrais ça si (ou quand) je mettrais le service en place, je n'aurais surement pas pensé à ces optimisations

Pour la nat, ma question était stupide au final.... Je n'avais pas tenu compte du changement d'ip.


Mon nouvel hébergeur viens de me donner des accès, je verrais ce que cela donne.

[dahtah]

Oui, mais ça l'est moins qu'un hébergeur te supportant dans une attaque ddos. Au moins 1000*€ par mois (généralement 3000-4000), alors que dans la solution que j'ai envisagée, le prix de reviens avec 10 passerelles seraient de l'ordre de 500-600€.

Interessant. Je connais pas les couts d'hebergement, mais je croyais (naivement) que les couts de protection DDoS etaient beaucoup moins cher. Merci de l'info.

Justement non, la somme de la bande passante des passerelles (quelque chose comme 4GO/s avec 10 passerelles) sera supérieur à celle du serveur (500*Mo/s), et le traffic invalide ne sera pas redirigé, donc le traffic redirigé par les passerelles ne satureras pas le serveur au final (dans l'idéal bien sûr).

Ok, j'avais pas vu ca comme ca. Je comprends mieux ou tu veux en venir.
Un truc qui me gene toujours, c'est que tu vas sans doute avoir qu'une ip/interface par passerelle. Donc ton traffic tunnele en direction du serveur va etre "hairpinned", c'est a dire qu'il va ressortir par la meme interface qu'il est rentre. Donc ta bande passant utile (celle du tunnel), sera directement reduite par le volume d'attaque avant filtrage. Ta bande passante pour l'interface va etre "bp attaque non-filtree"+"bp utile". Si "bp attaque non-filtree" augmente ton volume de donnee utile diminue. Je sais pas si je suis clair... Bien sur si tu as 2 interfaces, et que ton provider fait bien son travail, alors ta solution semble pouvoir marcher.

Oui c’est un point que je n'ai pas encore travaillé, mais qui pose des problèmes. J'ai envisagé d'essayer de gérer ça sans passer par le dns, mais cela donneraist une cible potentielle sur laquel repose tout le réseau.

La je vois pas vraiment comment faire sans rajouter un goulot d'etranglement - type load-balancer, proxy...
A part si tu peux t'interfacer avec ton serveur DNS. Tu peux imaginer avoir quelque chose de type ip-sla - envoi de traffic de test, ping, connection tcp... - et si tu passes au-dessus d'un seuil de latence, tu modifie ta conf DNS. Il faut que le TTL de ton DNS soit tres petit, pour pouvoir forcer des changements rapides.

Mon nouvel hébergeur viens de me donner des accès, je verrais ce que cela donne.

Si tu as le temps, tiens moi au courant. Je serais curieux d'avoir un retour sur ton experience.

Bon courage.

[Beanux]

Longtemps après ...
Au final le nouvel hébergement a été un succès. Spécialisé contre les attaque ddos, ils ont juste une bande passante suffisante pour avoir le temps de null route les ip malveillantes en temp réel.

Les inconvénients sont juste un peu de latence lorsqu'une personne est attaqué sur cet hébergeur.

Au final les attaquants se sont découragés (au vu du cout d'une attaque ddos, ça fini par ne devenir plus rentable du tout). Je n'ai donc pas pu mettre en œuvre le concept mentionné précédemment (seulement testé en environnement virtuel), mais je la garde sous le coude en cas de coup dur.


Je reste convaincu que contre le ddos, ça n’est pas celui qui a la plus grosse bande passante (ça coute trop cher, et on aura toujours meilleur que soi), mais qu'il vaux mieux essayer des systèmes architecturaux décentralisés filtrant.