On 12/27/2011 12:10 AM, Guillaume Barrot wrote:
Imagine 1 million de drones (chaque sur un IP different) qui crache
chacune 10 Kbps (= rien)
1 million de postes hautement previsibles, qui en meme temps vont sur la
meme destination avec le meme protocole ? Le marketing a un nom pour ca :
des "cl
J'ai 2 autres commentaires:
1. Sur filtrer les préfixes plus spécifiques, je ne serais pas chaud à ne pas
avoir de route par défaut. En théorie tu n'en as pas besoin, mais en théorie la
théorie et la pratique sont identiques, alors qu'en pratique elles ne le sont
pas.
Si ton système d'agrégati
>> Michel Py écrit:
>> C'est bien connu, il n'y a rien d'interdit; ce qui est interdit, c'est
>> de se faire piquer ;-) Eh bien récemment ce que j'ai lu, c'est la
>> Gendarmerie qui explique au mec qui a eu un accident en conduisant sans
>> permis comment réparer sa bagnole, et ils vont probableme
> Imagine 1 million de drones (chaque sur un IP different) qui crache
chacune 10 Kbps (= rien)
1 million de postes hautement previsibles, qui en meme temps vont sur la
meme destination avec le meme protocole ? Le marketing a un nom pour ca :
des "clients" (et des bons mêmes, qui obéissent aux sacr
On Mon, 26 Dec 2011 16:44:12 +0100, "Rémi Bouhl"
said:
> Question naïve: on peut spoofer des IP sources si facilement?
Oui. surtout quand tu est le mechant motive...
> Naïvement, je pensais que la quasi-totalité des ISP bloquaient sur leur
> réseau les paquets dont l'IP source ne correspond p
On Mon, 26 Dec 2011 16:35:04 +0100, "Damien Fleuriot" said:
> De plus, on a, fort heureusement, les environnements de dev, préprod et
> recette pour ça ;)
>
> Après est-ce que ça sera testé correctement par le métier, c'est une
> autre histoire...
Surtout quand l'IPv6 tu l'as que sur tes front
On 26 déc. 2011, at 16:34, Thomas Mangin
wrote:
>
> Le multihoming "BGP" est bien sur possible en IPv6 ..
> Donc je ne vois pas ce qu'IPv6 n'a pas qu'IPv4 a.
>
Une possibilité d'avoir une fragmentation de la DFZ beaucoup plus importante,
et du coup avoir du PA only aurait pu permettre de
Les operateurs ont des solutions du type guard/detector ou arbor ou landcop en
plus du B.H
Une discussion avec les SOC permet de reduire impact
Luc Billot
Envoyé de mon iPhone
Le 26 déc. 2011 à 11:52, "Surya ARBY" a écrit :
> C'est tout à fait exact, la granularité du filtrage est le réseau so
Hello,
D'un point de vu plus pratique, un opérateur de transit ne propose pas ce
genre de service en standard.
Nous fournissons des communautés de blackhole ou nous blackholons le
trafic lorsque cela est vraiment ultra justifié. Le blackhole sur un
réseau opérateur impacte l'ensemble de ses autre
Bonsoir Antoine,
Vous êtes juriste ?
Chinois peut-être :-) ?
Si l'on prend un exemple d'une entreprise ayant des échanges commerciaux ou à
caractères confidentiels, je pense qu'elle n'aimerait pas trop que son trafic
fasse un petit tour sur un plate-forme prenant des engagements vagues ou
dép
On 12/26/11 5:46 PM, Pierre Emeriaud wrote:
> 2011/12/26 Surya ARBY
>>
>> Unicast reverse path forwarding est dédié à cet effet et est principalement
>> déployé chez les providers.
>>
>
> corrigez-moi si je me trompe, mais pour moi urpf ne permet de bloquer
> le traffic en entrée uniquement si l
Ca se discute.
Ici, l'OP n'a pas précisé quels liens étaient saturés.
J'assume qu'il parlait de ses propres liens à lui (l'uplink avec ses 2
upstreams) et non pas les liens de ses opérateurs upstream, qui doivent
être un peu plus costauds.
Ainsi, s'il fait dropper par ses upstreams le trafic 80
Correct, URPF devrait surtout etre configure sur les connections des clients
(DSL, etc.)
Il y a des cas ou cela casse le traffic (pour des cas legitimes pour des
configurations non-triviales).
L'avoir sur les liens EBGP ne permet pas de se proteger aussi bien, comme tu le
remarques, mais c'est
2011/12/26 Surya ARBY
>
> Unicast reverse path forwarding est dédié à cet effet et est principalement
> déployé chez les providers.
>
corrigez-moi si je me trompe, mais pour moi urpf ne permet de bloquer
le traffic en entrée uniquement si les @ ne sont pas routables par
l'interface ingress. On p
Bonjour à tous et bonnes fêtes,
Quand l'attaque est à la vitesse des liens, il n'est plus possible de
filtrer avec quoi que ce soit. La cible doit être null routée au niveau
des opérateurs (via une communauté BGP spéciale).
La seule solution qui reste est d'utiliser un CDN couplé à des serveurs
Il ne faut pas oublié aussi les failles potentiel de certain serveur présent
sur Internet.
Les sites de gaming installation maison qui sont souvent utilisés pour générer
des attaques réflectives.
Dans ce cas nous avons un beau paquet UDP avec un source tout à fait légitime
vers une destination
On 12/26/11 12:04 PM, Charles Delorme wrote:
> Bonjour,
>
> Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de
> service depuis dimanche matin 7h heure locale. La très grosse majorité des
> paquets est en udp/80 à destination de nos deux liens, completel
> (213.30.14
C'est tout à fait exact, la granularité du filtrage est le réseau source (on
déploie ça au niveau du premier routeur). Sinon il faut faire de l'ip source
guard.
Après reste à voir l'exploitabilité de la solution.
De : Pierre Emeriaud
À : frnog-t...@frnog.o
'soir,
Le 26 décembre 2011 17:35, Texier, Matthieu a écrit :
> Argument tout a fait recevable et même, pour ce qui est la législation
> Française, juridiquement recevable … sauf erreur de ma part, un trafic
> entré en France n'est pas sensé aller faire un petit tour aux US ou
> ailleurs et reven
Hello,
Le 26 décembre 2011 16:44, François-Frédéric Ozog a écrit :
> A supposer qu'il existe une offre de "firewall virtuel" par abonné avec
> self-provisioning. Quels seraient les services à offrir (à part bien sûr le
> minimum syndical façon blocage de port)
> - blocage d'URL à destination de
Argument tout a fait recevable et même, pour ce qui est la législation
Française, juridiquement recevable … sauf erreur de ma part, un trafic entré en
France n'est pas sensé aller faire un petit tour aux US ou ailleurs et revenir…
Si il y a des juristes dans cette liste de diffusion, ils pourron
Il existe tout un arsenal de contremesures contre les attaques en déni de
service (volumétriques et applicatives).
Tous les éléments que vous donner sont effectivement des contremesures valides
et elles existent en offre managée sous différente forme suivant l'intégration
chez l'opérateur et so
Sans doute pas tous.
Unicast reverse path forwarding est dédié à cet effet et est principalement
déployé chez les providers.
Peut-être simplement que cela ne fait partie du template de conf type de
certains grands ISP.
De : Rémi Bouhl
À : frnog-t...@frnog
J'avais vaguement entendu parler de ce genre d'offre, il me semble
d'ailleurs qu'il existe d'autres acteurs que Prolexic.
Cependant, je trouve dommage de devoir re-router son trafic vers un tiers
(de confiance ?) jouant le rôle d'intermédiaire.
Implémenter une solution plus ou moins automatisée à
Si seulement tous réseaux suivaient BCP 38
http://www.ietf.org/rfc/rfc2827.txt
C'est comme le SPAM, si le filtrage a la source était bien fait, le monde
serait meilleur.
Thomas
On 26 Dec 2011, at 16:04, Matthieu BOUTHORS wrote:
> Bonjour,
>
> bien sur, vu qu'il n'y a pas de 3-Way handshake su
J ai une question qui peut sembler idiote car je ne sais pas quels sont les
services impactés et quelles en sont les utilisations mais rendre les services
down (eteindre tout par exemple, blacklister les ip turcs) ne me semble pas
etre une option ayatolesque.
Ensuite ce n est pas forcement une s
Bonjour,
bien sur, vu qu'il n'y a pas de 3-Way handshake sur l'UDP, il suffit que
le(s) routeur(s) situé du côté de l'attaquant relaient les paquets avec IP
sources spoofées pour qu'ils arrivent sur le serveur de destination. Si le
serveur utilise des services en UDP (eg DNS), il va même traiter l
Bonjour,
Le 26/12/2011 12:27, Damien Fleuriot a écrit :
On 12/26/11 12:04 PM, Charles Delorme wrote:
Bonjour,
Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de
service depuis dimanche matin 7h heure locale. La très grosse majorité des
paquets est en udp/80 à dest
A supposer qu'il existe une offre de "firewall virtuel" par abonné avec
self-provisioning. Quels seraient les services à offrir (à part bien sûr le
minimum syndical façon blocage de port)
- blocage d'URL à destination de hosts, URI, paramètres invalides?
- blocage d'AS? Pays ?
François-Frédéric
>> IPv6 est conçu pour que les machines aient plusieurs IPs.
>
> Zut.
> Je ne savais pas qu'on ne pouvait avoir plusieurs ip que en IPv6, du
> coup j'en mets en IPv4.
:D
>> La solution simple pour le multi-homing est d'avoir un réseau local en
>> IP site-global (je devrais dire adresse locale un
On 12/26/11 2:51 PM, Xavier Beaudouin wrote:
> Hello,
>
> Le 24 déc. 2011 à 01:03, Damien Fleuriot a écrit :
>
>> Et c'est très bien.
>>
>> Tu as un besoin: te connecter en ssh sur une machine sans monter de VPN
>> Tu as une réponse: rendre cette machine joignable en ip6.
>>
>> Très bien.
>>
>>
>
Alexis,
Une des societe specialise est Prolexic, Jay Coley parle souvent de ce qu'il
voit comme attaques a LINX, EFP, GPF, ...
Les informations présentées ne sont normalement pas publiques (Prolexic ne voit
pas de raison de former l'industrie qu'ils combattent).
Un peu d'info dans https://www
Le Mon, Dec 26, 2011 at 01:30:57PM +, Thomas Mangin
[thomas.man...@exa-networks.co.uk] a écrit:
[...]
>
> IPv6 est conçu pour que les machines aient plusieurs IPs.
Zut.
Je ne savais pas qu'on ne pouvait avoir plusieurs ip que en IPv6, du
coup j'en mets en IPv4.
> La solution simple pour le
Si tu as des exemples à citer, je pense que nombre d'entre nous sera
preneur, ne serait-ce qu'à titre informatif.
2011/12/26 Texier, Matthieu
> C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service
> opérateur spécialisé qui donne un engament de SLA associé.
>
> Des opérateu
C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service
opérateur spécialisé qui donne un engament de SLA associé.
Des opérateurs proposent ce type de service et s'appuient pour cela sur une
structure type SoC mettant à disposition des outils et des experts dans le
domaine.
Flow spec, c'est bien beau, mais tant que le client ne peut pas activer
seul le filtrage il est difficile de l'exploiter de façon efficace, les
attaquant étant généralement très réactifs et les services opérateurs lents
à la détente...
Enfin, quels sont les opérateurs à l'exploiter réellement ? Et
Hello,
Le 24 déc. 2011 à 01:03, Damien Fleuriot a écrit :
> Et c'est très bien.
>
> Tu as un besoin: te connecter en ssh sur une machine sans monter de VPN
> Tu as une réponse: rendre cette machine joignable en ip6.
>
> Très bien.
>
>
>
> Maintenant, *moi* j'ai un autre besoin, et une autre
Selon des sources habituellement bien informées l'attaque DoS proviendrait
de hackers nationalistes turcs en prévision de l'examen du projet de loi
déjà adopté par l'Assemblée nationale sur la négation des génocides et
notamment du génocide Arménien. Cette information ne sert toutefois guère à
régl
Voila un réponse qui me semble faire preuve d'expérience :-) !
Sans compter que nos amis attaquants font souvent preuve d'une malice certaine
et emmenant les administrateurs réseaux dans une direction afin de masquer une
autre action mené en parallèle au niveau L7.
Les attaques sont de plus en
Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur
web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections
EBGP ça aide surement beaucoup.
Face a une attaque sur le L7 - la vie devient très dure ...
Thomas
On 26 Dec 2011, at 13:08, Texier, Matthieu
Je rajoute ma pierre à l'édifice au lieu d'ouvrir un autre topic.
Depuis le 23/12, c'est la déferlante, on a rarement vu ça depuis 5 ans
qu'on existe.
DDOS UDP hier sur port aléatoire, non saturé mais qui a bien pourrit les
graph et les soirées de nos clients.
Et aujourd'hui, du scan sévère
>> Sans empiéter sur les plates-bandes du troll en court que je nourrirai
>> demain, force est de constater que l'échec d'IPv6 dans le domaine du
>> multihoming va finir par déboucher par une sélection par le pognon pour
>> opérer dans la DFZ. Pognon pour acheter le routeur monstrueux, tu contin
Oui c'est très bien.
On Dec 26, 2011, at 2:08 PM, Texier, Matthieu wrote:
> L'ideal de ce genre de situation serait d'avoir souscrit à un service de
> détection et de mitigation d'attaque auprès de ses fournisseurs d'accès
> Internet.
>
> Le blackhole BGP étant techniquement une approche valid
Le 26 décembre 2011 14:08, Texier, Matthieu a écrit :
> BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à
> base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé
> dans l'infrastructure du carrier ne puisse vous sortir de cette situation
> san
L'ideal de ce genre de situation serait d'avoir souscrit à un service de
détection et de mitigation d'attaque auprès de ses fournisseurs d'accès
Internet.
Le blackhole BGP étant techniquement une approche valide mais donnant raison
aux attaquants. BGP flow spec n'est applicable que rarement sur
Le 24 décembre 2011 07:19, Michel Py
a écrit :
> Sans empiéter sur les plates-bandes du troll en court que je nourrirai
> demain, force est de constater que l'échec d'IPv6 dans le domaine du
> multihoming va finir par déboucher par une sélection par le pognon pour
> opérer dans la DFZ. Pognon p
On 26 Dec 2011, at 11:27, Alexis Savin wrote:
> Quelques techniques sont pourtant intéressantes à étudier, la plus
> intéressante étant celle du "remote triggered black-hole" pour peu que
> l'opérateur le supporte (http://tools.ietf.org/html/rfc5635).
Au cas ou vous auriez rate la présentation -
IMHO, pour dropper 80/udp, le mieux que tu puisses faire c'est te
rapprocher des NOCs de tes upstreams (completel / GBLX) et leur demander
de le dropper à destination de tes supernets/subnets.
On 12/26/11 12:47 PM, Charles Delorme wrote:
> Merci pour vos suggestions.
>
> Ma priorité est effecti
Oui, il faut bien comprendre que de toute façon, le service est down mais
que l'attaque impacte toute une plateforme, down elle aussi du coup. Ce qui
inclus dans l'exemple, les services mail notamment qui pourtant ne sont pas
visés initialement.
Comme dit précédemment, la priorité est de désengorg
Merci pour vos suggestions.
Ma priorité est effectivement de bloquer le traffic udp/80 en amont de mes
liens. Les équipements en tête de réseau supportent bien la charge mais ce sont
les liens qui saturent.
Damien Fleuriot a écrit :
Bah oui mais du coup il va se couper le service tout seul
Bah oui mais du coup il va se couper le service tout seul, certes
seulement vers l'IP cible mais l'attaque aura réussi.
Vu que la plupart du trafic semble être de l'UDP 80, est-ce qu'il aurait
pas plus rapide de dropper ça par ses upstreams ?
On 12/26/11 12:33 PM, Alexis Savin wrote:
> Il ne s'a
Bonjour,
Le 26/12/2011 07:09, Francois Demeyer a écrit :
> Le 26 déc. 2011 à 06:36, Michel Py a écrit :
>> C'est bien là ou est le problème. On ne demande pas à Mme Michu d'avoir des
>> compétences en informatique ou en réseau. Par contre, quelqu'un qui héberge
>> un serveur dans une colo est ce
Il ne s'agit pas de bloquer les sources, mais le trafic à destination de
l'ip attaquée, le temps que l'attaque cesse.
La priorité lors d'une attaque comme celle-ci est de désengorger ses tuyaux
pour rétablir le plus de services possible.
2011/12/26 Damien Fleuriot
> S'agissant très probablement
S'agissant très probablement d'IPs spoofées, je le vois mal blackholer
200k /32 générées aléatoirement ?
Nan parce qu'au bout d'un moment le routeur upstream va en avoir marre,
déjà, et ensuite au bout d'un moment ça va bloquer des vrais clients
légitimes qui auront eu la malchance que leur IP soi
Bonjour,
Un grand classique, surement déjà vécu par beaucoup ici.
Et malheureusement peu d'options efficaces.
Quelques techniques sont pourtant intéressantes à étudier, la plus
intéressante étant celle du "remote triggered black-hole" pour peu que
l'opérateur le supporte (http://tools.ietf.org/h
On 12/26/11 12:04 PM, Charles Delorme wrote:
> Bonjour,
>
> Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de
> service depuis dimanche matin 7h heure locale. La très grosse majorité des
> paquets est en udp/80 à destination de nos deux liens, completel
> (213.30.14
Nous avons subi ce genre d'attaque également il y a quelques semaines, le
firewall a saturé car les connexions étaient ouvertes très très vites à
priori (peu de logs à cause de la saturation), en tout cas plus vite que ce
que le firewall ne savait traiter.
En bref, 150Mbits/s de trafic inopiné qui
Bonjour,
Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de
service depuis dimanche matin 7h heure locale. La très grosse majorité des
paquets est en udp/80 à destination de nos deux liens, completel
(213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi
Merci pour vos réponses à tous.
A vrai dire, je ne comptais pas upgrader du tout pour le moment (ce n'est
pas du tout prévu).
Pour vous en dire plus, j'ai plusieurs upstream avec des full-view répartis
sur plusieurs routeurs et le nombre de routes commence donc à être trop
élevé pour ma configurati
Bonjour,
Le 26/12/2011 06:36, Michel Py a écrit :
RobOEM a écrit:
En tant qu'utilisateur cependant, je serais bien content
qu'un mec sachant me prévienne d'une brèche sur mon CMS,
même si la solution c'est d'appliquer les patches que je
n'ai pas appliqué depuis 2003.
C'est bien là ou est le p
60 matches
Mail list logo
