URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 93971
[ Назад ]

Исходное сообщение
"Оценка методов усиления трафика при организации DDoS-атак"

Отправлено opennews , 10-Фев-14 23:32 
Компьютерная команда экстренной готовности США (US-CERT) опубликовала (https://www.us-cert.gov/ncas/alerts/TA14-017A) обновление отчёта с оценкой эффективности методов усиления трафика. Смысл атаки сводится к тому, что запросы поражённых компьютеров, входящих в состав ботнетов, направляются не напрямую на систему жертвы, а через промежуточный усилитель трафика, путем отправки UDP-пакетов с подставным обратным адресом. Кроме методов усиления через DNS и NTP в отчёте представлен ряд других UDP-служб, которые используются в качестве усилителей трафика:

-  DNS: 28-54 (коэффициент усиления пропускной способности, показывающий во сколько раз приумножается трафик)
-  NTP: 556.9
-  SNMPv2:    6.3
-  NetBIOS:    3.8    
-  SSDP:    30.8
-  CharGEN:    358.8    
-  QOTD:    140.3    
-  BitTorrent:    3.8
-  Kad:    16.3
-  Quake Network Protocol:    63.9
-  Steam Protocol:    5.5

URL: https://www.us-cert.gov/ncas/alerts/TA14-017A
Новость: http://www.opennet.me/opennews/art.shtml?num=39058


Содержание

Сообщения в этом обсуждении
"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено pavlinux , 10-Фев-14 23:32 
Тут только один выход - увеличивать размер команд. Например чтоб запросить список серверов времени, надо отправлять команду:

"O GREAT AND WONDERFUL SERVER, WOULD YOU BE SO KIND AS TO GIVE ME YOUR WONDERFUL LIST OF FAVORITE SERVERS, PLEASE^D".

а он тебе в ответ пару байт: "ХРЕН^D"

  


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 10-Фев-14 23:43 
Даёшь проведение в Сочи нового олимпийского вида спорта - компьютерный пинг-понг!

Берём два игровых сервера, отправляем от имени первого info-запрос второму. Второй отвечает первому, первый отвечает второму и т.д. Выигрывает та пара серверов, что больше трафика сгенерит.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено pavlinux , 10-Фев-14 23:49 
Фейсбук и Инстаграм так работают:
в инстаграм насрал, кто-то пришёл увидел - поделился,
пришли питсот друзей - прошли по сцылке на инстаграмм - насрали, ....


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 10-Фев-14 23:44 
> а он тебе в ответ пару байт: "ХРЕН^D"

Так не усилитель получится, а архиватор. Сразу начнут такие службы для экономии трафика использовать :-)


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 01:47 
>> а он тебе в ответ пару байт: "ХРЕН^D"
> Так не усилитель получится, а архиватор. Сразу начнут такие службы для экономии
> трафика использовать :-)

Написать программу, отвечающую "XPEH", можно и без выхода в сеть :)
Можно даже без сетевых технологий - обычное символьное устройство /dev/xpeh.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Xasd , 11-Фев-14 01:41 
> Тут только один выход - увеличивать размер команд.

а сделать так чтобы подстановка фальшивого обратного адреса не срабатывала -- нельзя?

например если я посылаю ip-пакет в котором обратный адрес указан -- вообще от чужёго пользователя -- то с какой стати мой провайдер станет маршрутизировать такой ip-пакет?

(хотя провайдер может и станет -- но это нарушение. и значит винить в DDoS -- можно смело провайдера который разрешил отправлять ip-пакеты (UDP) с чужим обратным ip-адресом)

ну блин, rp_filter же для чего придумали?


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 01:45 
> а сделать так чтобы подстановка фальшивого обратного адреса не срабатывала -- нельзя?

И открытых SMTP-релеев не было, и чтобы преступники все в тюрьме сидели, ага :)

Бороться-то можно, но паршивые овцы найдутся при любом раскладе.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Xasd , 11-Фев-14 01:50 
> Бороться-то можно, но паршивые овцы найдутся при любом раскладе.

эти "паршивые овци" -- если захотят (или если их взломают) -- могут вообще просто навсего за`DDoS`ить любой сервер -- просто всей своей мощностью через обычные HTTP-GET-запросы :)


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 02:06 
Важно не только наличие каждой овцы по отдельности, но и возможность их одновременного использования в рамках одной операции. С миру по нитке...

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено pavlinux , 11-Фев-14 01:50 
> а сделать так чтобы подстановка фальшивого обратного адреса не срабатывала -- нельзя?

Ты когда письмо пишешь, можешь указать любой адрес отправителя? Можешь!
Марки купил - оплатил. Остальное нипёт.  

> например если я посылаю ip-пакет в котором обратный адрес указан -- вообще от чужёго
> пользователя -- то с какой стати мой провайдер станет маршрутизировать такой ip-пакет?

И чо, теперь я из-за тебя не смогу транзитный канал организовать?


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Xasd , 11-Фев-14 01:53 
>> а сделать так чтобы подстановка фальшивого обратного адреса не срабатывала -- нельзя?
> Ты когда письмо пишешь, можешь указать любой адрес отправителя? Можешь!
> Марки купил - оплатил. Остальное нипёт.

я когда письмо пишу -- то у входящего адресата проверяется SPF-запсь на моём домене. (так что если я укажу фальшивый обратный адрес -- это сразу будет выявлено.. точнее сказать -- если кто-то другой укажет мой адрес в качестве обратного -- то это не прокатит).

это если письмо было электронное.

а если письмо было через "почта роиси" -- то их методы мне не внушают безопасности [и я не рассматриваю их как образец безопасности]. последний раз например получал посылку, тыг мне её когда выдали даже паспорт не спросили.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено pavlinux , 11-Фев-14 01:57 
>>> а сделать так чтобы подстановка фальшивого обратного адреса не срабатывала -- нельзя?
>> Ты когда письмо пишешь, можешь указать любой адрес отправителя? Можешь!
>> Марки купил - оплатил. Остальное нипёт.
> я когда письмо пишу -- то у входящего адресата проверяется SPF-запсь на
> моём домене.

Покажи мне такого смелого админа, который подставит свою жопу, включив
обязательное требование ко входящей почте, как наличие SPF.
  
Говна самовар, а не SPF, особо в restricted режиме!

> последний раз например получал посылку, тыг мне её когда выдали даже
> паспорт не спросили.

Там такие тётки, любой фаервол нервно курит в сторонке.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 02:09 
> Покажи мне такого смелого админа, который подставит свою жопу, включив
> обязательное требование ко входящей почте, как наличие SPF.

Я как минимум одного такого знаю. И что характерно, удача сопутствует мудрым и храбрым - ему за это внеочередную премию дали.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено pavlinux , 11-Фев-14 02:14 
>> Покажи мне такого смелого админа, который подставит свою жопу, включив
>> обязательное требование ко входящей почте, как наличие SPF.
> Я как минимум одного такого знаю. И что характерно, удача сопутствует мудрым
> и храбрым - ему за это внеочередную премию дали.

Угу... Пешиищо! Когда выгонят, за то, что инвестора забанил,
который хотел спросить реквизиты для перевода бабла.  


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 02:16 
> Угу... Пешиищо! Когда выгонят, за то, что инвестора забанил,
> который хотел спросить реквизиты для перевода бабла.

Не поверите, есть конторы, которые работают, а не ждут долларового дождя с небес.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено t28 , 11-Фев-14 13:07 
> их методы мне не внушают безопасности

Ты ни как не можешь понять, что: "The Internet is not about security, The Internet is about connectivity."

Безопасность — это в других сетях.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 13:30 
>> их методы мне не внушают безопасности
> Ты ни как не можешь понять, что: "The Internet is not about
> security, The Internet is about connectivity."

В данном случае (DoS-атаки) security тесно связано с connectivity. Нет первого - не будет и второго.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Xasd , 11-Фев-14 02:00 
 

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено pavlinux , 11-Фев-14 02:05 
>> И чо, теперь я из-за тебя не смогу транзитный канал организовать?

VPN из кетайского филиала, бриджом на провайдера. И пля не провайдерское это собачье дело,
что у меня в сети. Ему платят за канал! Выдал подсеть - дуй, маршутизируй КУДА сказано.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено pavlinux , 11-Фев-14 02:08 
И ваще у меня оптика и MPLS-шланг! Нет там IP! Маркеры банить? :D

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 02:13 
> И ваще у меня оптика и MPLS-шланг! Нет там IP!

Что, совсем нет, даже инкапсулированного? Ну, на нет и суда нет.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено pavlinux , 11-Фев-14 04:11 
А это уже досмотр и вскрытие писем называется, велкам ту 1937!  

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 12:24 
> А это уже досмотр и вскрытие писем называется, велкам ту 1937!  

Тогда и в не инкапсулированном трафике заголовки читать противозаконно - сразу в /dev/null, и никакой маршрутизации.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 11:17 
Да причём тут ты со своим MPLS? MPLS подразумевает что у тебя есть админы которые не будут тупо смотреть на флуд из их сети. Речь же об обычных домашних пользователях или небольших фирмочках с сеткой на 16 которым не нужно гонять транзитный трафик с неизвестным src.

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Xasd , 11-Фев-14 02:11 
> И чо, теперь я из-за тебя не смогу транзитный канал организовать?

если я ТОЛЬКО организовываю точку обмена трафиком. то есть -- если у меня везде ТОЛЬКО чужой транзитный трафик (и нет ни какого друго: нет моего собственного трафика) -- то разумется я ни как не могу проверять обратный адрес отправителя пакетов.

а если вдруг я занимаюсь тем что подключаю клиентские компьютеры к интернету (к точке обмена трафиком) -- то я просто обязан проверять чтобы в заголовоке пакетов (из моей подсети) не было бы фальшифого обратного ip-адреса.

буду ли я делать это с использованием "rp_filter", или делать это без использования "rp_filter" а через свой собственный набор правил фаервола -- совершенно не важно как. главное проверять чтобы от моих клиентов -- в интернет (в точку обмена трафиком) не шло бы всякое говно!

а если я подключаю клиентские компьютеры к интернету, но не проверяю корректность заголовка ip-пакетов -- то значит говно я, а не интернет-провайдер :-) , и из-за меня (такого говна) могут пострадать люди.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 03:59 
> а если вдруг я занимаюсь тем что подключаю клиентские компьютеры к интернету (к точке обмена трафиком) -- то я просто обязан проверять чтобы в заголовоке пакетов (из моей подсети) не было бы фальшифого обратного ip-адреса.

Все это замечательно, но как насчет технических методов контроля за соблюдением данного принципа всеми провайдерами (которые располагаются в разных странах)?


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Xasd , 11-Фев-14 04:21 
вот тут я сел в лужу :-)

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 18:23 
все давно есть. просто никто не читает(ни провайдеры, ни интеграторы, ни законтворцы)
аналогично тому как для endpoint-ов првоов - есть вещи вроде RFC3074 и более суровые.
даже для L2 CMSA-сетей, вроде Эзернета, которым 90% России, обынтернечивающегося - вагон всего есть - EAPOL, 802.1AE, 802.1AR и прочие и прочие(и которых - особенно суров SEND).
только болт клали с прибором и вендоры и провайдеры и юристы на все это, даже в спецслужбах
пока петух жаренный в ж-у не клюнет - не начнут внедрять. DNSSec - двадцать лет не двигался, хотя проблему обзозначили, изначально. к примеру.

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Crazy Alex , 11-Фев-14 05:15 
По-моему, лучше вылизывать техническую реализацию, чем бороться методами "всех запретить". А то тут только повод дай - зарегулируют всё так, что не продохнёшь. А учитывая некоторые особенности бюрократии - в частности, то, что получить по башке за то, что "не проедотвратил" много больше шансов, чем за то, что создал гору неудобств людям - бороться потом замучаемся.

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено nikosd , 11-Фев-14 11:39 
И  приходит к этому провайдеру  клиент  ( крупный  клиент) и говорит:  
мы  у Вас берем  100 мегабит  и   50 мегабит  у  другого провайдера (  как резерв) , так  вот - нам надо чтобы  пропускались у  вас пакеты  с ip_src   второго провайдера, и вообще ,   у нас таких точек  несколько десятков ( вполне  вероятно -  это федеральная сеть) , первый  раз видим  чтобы  провайдер проверял  IP  на выходе.
Мы  мелкие - связались со вторым провайдером, получили добро,   повесили access-list, но вывод - многие   не фильтруют  вообще.
А уж на BGP стыках с мелочью - вообще  фильтры  редкость ( анонсить они  могут только себя, а вот проверять  что у него  включено ip ver sou uni   на интерфейсе  -  или накладывать  лист -  неа )

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено t28 , 11-Фев-14 13:31 
> а если вдруг я занимаюсь тем что подключаю клиентские компьютеры к интернету
> (к точке обмена трафиком) -- то я просто обязан проверять чтобы

Друзья, держитесь подальше от таких ^ ^ "провайдеров". В случае чего — геморрой обеспечен.

У нас клиентское подключение к нескольким провайдерам в датацентре и балансировка исходящего трафика работает с использованием спуфинга. Ни разу я не сталкивался с непропусканием трафика с поддельными IP.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено nikosd , 11-Фев-14 17:50 
Думаю, что  как  только кто - то придет  к вам  со словами  - а вы тут в DDOS  участвовали, сайта name.gov.ru - Ваше мнение  сильно изменится (  и ведь  доказать что это сосед DDOS  устроил не возможно будет) ..  Да и  очень сомнительно что в этом ДЦ честно сдан  СОРМ..
Провайдеры - держитесь подальше  от клиентов, которые хотят чего - то за пределами   нормальной процедуры
P.S. RFC 2267  не более  чем для обсуждения, но почитать стоит.  

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 18:06 
> Да и  очень сомнительно что в этом ДЦ честно сдан  СОРМ..

Немного инсайдерской инфы: СОРМ-2 не работает. Там все попилено. А вот СОРМ-1 (прослушка телефонов) - вполне.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено nikosd1 , 11-Фев-14 21:22 
>> Да и  очень сомнительно что в этом ДЦ честно сдан  СОРМ..
> Немного инсайдерской инфы: СОРМ-2 не работает. Там все попилено. А вот СОРМ-1
> (прослушка телефонов) - вполне.

Me с интересом вспоминает вид ящика в Закрытом  шкафу, логи о том, что ящик  явно работает (есть процедура  проверки), подключение  билинга к API СОРМ и прочие  радости..  
Понимает что это галлюцинация.
СОРМ на Internet можно не сдавать пока:
- у вас нет равного по размеру конкурента со сданным  СОРМ, который толкнет идею своим  деньгополучателям " какого фига  у него конкурентные преимущества".
- никто из сети  провайдера  не сотворил ничего  по настоящему  интересного для спецслужб
- у провайдера  нет больших клиентов, которые  постоянно  кого - нибудь интересуют.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 23:46 
> Me с интересом вспоминает вид ящика в Закрытом  шкафу, логи о том, что ящик  явно работает (есть процедура  проверки), подключение  билинга к API СОРМ и прочие  радости..  

А что делать, если контракт обязывает и подключить, и регламентное ТО проводить... но коробка с радиодеталями работать от этого не начнет.

> - у вас нет равного по размеру конкурента со сданным  СОРМ, который толкнет идею своим  деньгополучателям " какого фига  у него конкурентные преимущества".

Ну что вы, как маленький. В госсекторе все решается не конкурентными преимуществами, а знакомствами и откатами.

> - никто из сети  провайдера  не сотворил ничего  по настоящему  интересного для спецслужб

Такие вещи обычно решаются на уровне сотрудничества с соц. сетями и другими сайтами. Потому что самое интересное, что можно сделать в интернете, а потом за это огрести - призывы "краба на мыло", "вали хачей" и т.д.

Кроме того, существует куда более отработанный подход - оперативные мероприятия. Проще говоря, человеческий фактор. И он пока заруливает все прочие методы.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено t28 , 13-Фев-14 06:51 
> Да и  очень сомнительно что в этом ДЦ честно сдан  СОРМ..

Очевидно, вы из тех, кто на "наг"-е обсуждают как бы быстрее и дешевле подстелиться под бредовые запросы индивидуумов, работающих в органах. Буду рад ошибиться.

Я вас успокою, наше оборудование в ДЦ не расположенном на территории России. В контрактах оговорены все ньюансы (sorry about that) подключения и какая-либо фильтрация — недопустима. Шибко вумные провайдеры сразу пойдут лесом. Таковых, правда, пока не встречалось. Один провайдер систематически несоблюдал SLA — контракт пришлось закрыть (несмотря на вкусные цены за трафик), плюс оплачивал неустойку.

> Провайдеры - держитесь подальше  от клиентов, которые хотят чего -
> то за пределами   нормальной процедуры

Отсутствие фильтрации маршрутизируемых IP — и есть нормальная практика. А вот фильтрация — это пионэрия инфантильных админов, заигравшихся в провайдерство.

> RFC 2267

Вы сами-то читали? Там же английски по белому написано, что такая фильтрация рубит ассимметричный трафик. Будем по каждому чиху фильтр перестраивать? Или предпочитаете клиентов строить? Так в таком случае клиент проголосует ногами/деньгами.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено nikosd , 23-Фев-14 16:09 
>> Да и  очень сомнительно что в этом ДЦ честно сдан  СОРМ..
> Очевидно, вы из тех, кто на "наг"-е обсуждают как бы быстрее и
> дешевле подстелиться под бредовые запросы индивидуумов, работающих в органах. Буду рад
> ошибиться.

Я, уж извините,  работаю в стране где  есть закон ( пусть дурной, но есть), который  следует соблюдать.  

> Я вас успокою, наше оборудование в ДЦ не расположенном на территории России.
> В контрактах оговорены все ньюансы (sorry about that) подключения и какая-либо
> фильтрация — недопустима. Шибко вумные провайдеры сразу пойдут лесом. Таковых, правда,
> пока не встречалось. Один провайдер систематически несоблюдал SLA — контракт пришлось
> закрыть (несмотря на вкусные цены за трафик), плюс оплачивал неустойку.

Приходило к нам нечто, которое хотело много чего  непонятного, в том числе  и отсутвие  фильтрации  на выход , пошло  лесом - кажется  в Нидерланды .. Это не Вы  были ( ДЦ в Москве на  Космодемьянских).

>> Провайдеры - держитесь подальше  от клиентов, которые хотят чего -
>> то за пределами   нормальной процедуры
> Отсутствие фильтрации маршрутизируемых IP — и есть нормальная практика. А вот фильтрация
> — это пионэрия инфантильных админов, заигравшихся в провайдерство.

Каждому  свое -  если  я вижу что с AS  идет то, что  не должно  -  и это мешает - фильтры на бордере  никто не отменял.
>> RFC 2267
> Вы сами-то читали? Там же английски по белому написано, что такая фильтрация
> рубит ассимметричный трафик. Будем по каждому чиху фильтр перестраивать? Или предпочитаете
> клиентов строить? Так в таком случае клиент проголосует ногами/деньгами.

Читал, и именно это есть вопрос обсуждение в RFC  -  что вообще надо, но много пионЭров   уже   так  испортили  логику  сети, ..  хотите  нормально балансить - пользуйте свои  сети  и мультихомед AS в  таком  расладе претензий  быть не  должно.

Ассиметричный трафик  с источниками/получателями   из разных AS -  рубит и правильно делает, надо открутить за такое от сети  провода.. пару  раз половите  где  глюк ( LG  внятного у такого нет)  и кто срубает GRE по дороге, почему не пролазит пакет более  1400 байт,  почему  фаервол клиента  рубит этот пакет   -  поймете.
Фильтры  не сложно перестраивать  автоматом, если  оно надо,   а гадость в ДЦ  держать никто не будет,  блудливые  могут голосовать ногами и иными частями тела.. . Не  стесняюсь  того, что  клиент, который не может закрыть кривой паблик DNS  и NTP ( фильтранули на входе - его не устроило )   проголосовал ногами,  вот с такими  и работайте, нагрузка на CТП  от них  не пропорциональна  деньгам.

Интересно настроить  нормально соурс роутинг на сервере  это  очень сложно или "очень очень" .


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 02:07 
> Ты когда письмо пишешь, можешь указать любой адрес отправителя? Можешь!
> Марки купил - оплатил. Остальное нипёт.

Это не есть хорошо.

> И чо, теперь я из-за тебя не смогу транзитный канал организовать?

Транзитный канал без AS - действительно, лучше не надо.
А если есть AS и клиентские подключения (ДЦ или брасы) - будь добр включать у себя rp filter.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено pavlinux , 11-Фев-14 02:10 
>> Ты когда письмо пишешь, можешь указать любой адрес отправителя? Можешь!
>> Марки купил - оплатил. Остальное нипёт.
> Это не есть хорошо.

Ну попробуй, разошли 10000 писем спама через почтовый ящик. :D


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 02:14 
>>> Ты когда письмо пишешь, можешь указать любой адрес отправителя? Можешь!
>>> Марки купил - оплатил. Остальное нипёт.
>> Это не есть хорошо.
> Ну попробуй, разошли 10000 писем спама через почтовый ящик. :D

А кто сказал, что это не есть хорошо именно из-за спама?


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено PavelR , 11-Фев-14 11:18 

Ага включай "rp_filter" пусть потом клиенты и "клиенты клиентов" страдают из-за потери связи при асимметрии..

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 12:26 
> Ага включай "rp_filter" пусть потом клиенты и "клиенты клиентов" страдают из-за потери
> связи при асимметрии..

Купить у прова трафик и перепродать его владельцам AS? Жадность барыг не знает границ.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено t28 , 11-Фев-14 12:58 
> а сделать так чтобы подстановка фальшивого обратного адреса не срабатывала -- нельзя?

Нельзя.

> например если я посылаю ip-пакет в котором обратный адрес указан -- вообще
> от чужёго пользователя -- то с какой стати мой провайдер станет
> маршрутизировать такой ip-пакет?
> (хотя провайдер может и станет -- но это нарушение. и значит винить

Нарушение чего? И в чём оно выражается?
Я вижу многие просто до сих пор не понимают архитектуру сети The Internet.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 13:28 
> Я вижу многие просто до сих пор не понимают архитектуру сети The Internet.

Нет, это вы не понимаете разницу между транзитными и клиентскими сетями.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено t28 , 11-Фев-14 13:35 
> Нет, это вы не понимаете разницу между транзитными и клиентскими сетями.

Дружище, спуфинг — это архитектурная особенность The Internet, он так устроен. Но вам, видимо, это понимание недоступно.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 18:26 
скорее, юридическая.
и поддержание сего статус-кво, оченно выгодное - оченно продавливается и лоббируется североамериканским правительством.
понятно для чего.
сугубо технически там вагон всего и на L3 есть и на L2.
но не вендряется оно и даже не всегда стандартизируется - именно по Этой причине.
бо, 90% сетевых(и хардвер и не только)компаний, внезапно - Американские :=)

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено t28 , 13-Фев-14 06:59 
> и поддержание сего статус-кво, оченно выгодное -
> оченно продавливается и лоббируется североамериканским
> правительством.
> понятно для чего.

Сетка изначально военного применения. Американская. Имеют право.
Создавайте какой-нибудь RusNet на основе православного протокола — будете там заправлять. Богомерзкий спуфинг-там запрещать, то-сё, пятое-десятое...


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 01:49 
За всякие кваки и битторренты не скажу, но в случае дубовых DNS/NTP/etc легко лечится через iptables -m hashlimit. Использовать такой сервак для усиления, в принципе, еще можно, но в очень ограниченных пределах.

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Xasd , 11-Фев-14 02:24 
 

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Нанобот , 11-Фев-14 13:56 
а можно и вообще ничего не делать. потому что ddos-атаки создают проблемы не ботам, а целям атаки.

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 18:28 
нуда.а убийства людей, суть проблема не не свидетелей или невольных пособников/соучастников а сугубо их жертв. пока не поймают. или не сменят статус на "жертвы".

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 23:48 
> а можно и вообще ничего не делать. потому что ddos-атаки создают проблемы
> не ботам, а целям атаки.

Если вам доставляет удовольствие ощущение, что вас поимели, как уличную девку - то да.
А вот мне эта идея не нравится.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Ed , 11-Фев-14 15:26 
Лучшая зашита от DDoS атак – Link11.de http://www.link11.de/en/ddos_protection.html

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Аноним , 11-Фев-14 16:58 
Это чем они лучше всяких стаминусов, клоудфларе, пролексика, блеклотуса?

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Ed , 11-Фев-14 19:42 
Лучшая DDoS-защита Internet Award 2012,Security-Insider.de Link11 DDoS-Schutz Cloud лучший продукт месяц июль2013

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Ed , 11-Фев-14 20:42 
Link11.de  использует  для фильтрации очень гранулированный фильтр основан на обмано- устойчивой технологии - то есть, они проверяют (не как многие конкуренты через сеть доставки контента CDN) каждый запрос и таким образом можно не только фильтровать большие объемные атаки, но дополнительно гарантировать, что даже сложные атаки отфильтровываются на уровне приложений.

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено angra , 11-Фев-14 21:01 
Остальные не башляют Ed, а значит все они хуже(с точки зрения Ed). Ну а если объективно, то сайт этих ребят ничего кроме маркетоидного булшита не содержит, можно сразу забывать.


"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено Ed , 11-Фев-14 21:11 
angra,булшит это вы! У этих ребят в отличии от многих продавцов ддос защиты, имеется свой ДатаЦентр прям возле главного интернет узла во Франкфурте, и технология защиты от DDoS своя!

"Оценка методов усиления трафика при организации DDoS-атак"
Отправлено t28 , 13-Фев-14 07:01 
> свой ДатаЦентр прям возле главного интернет узла во Франкфурте,

Да-да!  Самый главный, главнее не бывает!