
Leo
16.01.2017
21:12:56
какое количество запросов в секунду = мешает?

Ivan
16.01.2017
21:12:57
ftp и факсы ещё ip6 переживут

Oleg
16.01.2017
21:13:04
Я таким зафильтровал у себя

Leo
16.01.2017
21:13:09
мне не нравится, что оно просто юзает мою полосу для атаки

Google

Oleg
16.01.2017
21:13:10
Благо их всего 3

Leo
16.01.2017
21:13:20
сколько бы не юзало

Sergey
16.01.2017
21:13:21
это купленная клиентом полоса

Ivan
16.01.2017
21:13:30
У нас в соглашении написано что создает проблемы другим. Т.е. нашел кого то с проблемой, всё, доказал.
Или фигня это?

Maxim
16.01.2017
21:14:40

Leo
16.01.2017
21:14:54
надо, чтобы аплинк тоже не тупил и смотрел, что происходит

Oleg
16.01.2017
21:15:08

Leo
16.01.2017
21:15:11
и мог по запросу рубануть, например, входящий UDP
либо знать, сколько в целом пролетает SYN, чтобы рулить этим параметром
все решения с DDoS, увы, далеко не сразу очевидны
например, что делать, если нам льется UDP, мы его порезали, но DNS-запросы наших пользователей надо как-то сатисфачить?

Google

Leo
16.01.2017
21:16:57
хотя бы на DNS?
молчу про всякие VoIP

Maxim
16.01.2017
21:17:07

Sergey
16.01.2017
21:17:19
rfc 7999 что ли
про блекхоле

Leo
16.01.2017
21:17:22
вернее, вирусни к

Sergey
16.01.2017
21:17:49
https://tools.ietf.org/html/rfc7999

Leo
16.01.2017
21:17:52
ибо как только IPv6 соединится с IoT, мы получим сотни, тысячи слабозащищенных или непропатченых устройств

Ivan
16.01.2017
21:18:00
Что плохого если нат ляжет? Это же благо

Leo
16.01.2017
21:18:03
с прямым доступом в сеть

Maxim
16.01.2017
21:18:13

Ivan
16.01.2017
21:18:19
Нат за которым пяток утюгов iot ложась спасает нас.

Leo
16.01.2017
21:18:42
вот вижу я с 10-15 машин в моей сети трафик вида DNS-запрос <генеренка>.атакуемыйдомен.tld
он не сильно велик с каждой машины по отдельности
но вот мой резольвер в сумме уже льет на NS-сервера атакуемого домена 3-4 мегабита
чо мне в регламенте писать?
“если вы, какашки, начинаете все вместе лить трафик куда-то, без предварительного согласования со мной, то я вас отключу, так и знайте!”
либо другая фигня

Google

Ivan
16.01.2017
21:20:35
Согласен, мутно

Leo
16.01.2017
21:20:42
тупой роутер начинает лить мне 14-15 тыщ запросов в секунду на какой-нить PTR
ну просто он тупой и вот жизн у него не удалась

Maxim
16.01.2017
21:21:03

Ivan
16.01.2017
21:21:15
В ту же тему. мне последнее время приходит много жалоб от всяких контор типа меня ваш клиент сканит. Я проверяю, ну да, было.
Но было типа пару пакетов, чо делать?

Igor
16.01.2017
21:21:36

Ivan
16.01.2017
21:21:38

Alex
16.01.2017
21:21:51
А что, кто-то еще не умеет бороться с SYNflood? Хм.

Leo
16.01.2017
21:21:56

Igor
16.01.2017
21:22:05

Leo
16.01.2017
21:22:18
тада мы приходим к тому, что внутри нашей сети нельзя всех rate limit ировать одинаково

Ivan
16.01.2017
21:22:36
А это интересный вопрос, я даже не понимаю чего они хотят. В письме нет просьбы. есть факт.

Leo
16.01.2017
21:22:54

Maxim
16.01.2017
21:23:23

Igor
16.01.2017
21:25:47

Leo
16.01.2017
21:25:55
для ряда протоколов не подходит
SMTP навскидку

Maxim
16.01.2017
21:26:45

Google

Leo
16.01.2017
21:26:53
я скажу так — посоны из Cisco на это говорят “know your network” и я с ними согласен, я про SYN

Ivan
16.01.2017
21:27:37

Leo
16.01.2017
21:27:41
ну или чуть больше, неважно

Ivan
16.01.2017
21:27:50
И вам проблем не создают, ну пришло там 5 пакетов от каждого

Igor
16.01.2017
21:27:50

Alex
16.01.2017
21:28:25
Чем же SYNcookie для SMTP не подходит? :)))

Leo
16.01.2017
21:28:27
а сервер молчит, пушо экономит мозг

Admin
ERROR: S client not available

Alex
16.01.2017
21:29:08
Понятно, вам пора прочитать, как SYNcookie работает

Leo
16.01.2017
21:29:11
поэтому клиент говорит “хозяин, этот сервер отвечает мне не”
эээээээ

Igor
16.01.2017
21:29:23
а так - в большинстве случаев прокатывает

Leo
16.01.2017
21:29:50
из вики кагбе
Однако проблема возрастает когда теряется финальный ACK-пакет от клиента, а протокол прикладного уровня требует, чтобы сервер был инициатором дальнейшего взаимодействия (например, протоколы SMTP и SSH). В этом случае клиент предполагает, что соединение установлено успешно и ждёт от сервера пригласительный баннер или повторную пересылку SYN+ACK пакета. Однако сервер не будет отправлять такой пакет, т.к. забракует сессию. В конечном итоге клиент тоже сбросить сессию, но для этого может потребоваться много времени.
может Вам почитать, как оно работает?

Maxim
16.01.2017
21:30:30

Google

Leo
16.01.2017
21:30:33
в плохих случаях — это комбинация

Igor
16.01.2017
21:30:48

Leo
16.01.2017
21:31:02
да я просто сказал и повторюсь, что серебряной пули нет

Igor
16.01.2017
21:31:06
понятно что не панацея
ага

Ivan
16.01.2017
21:31:13
Тут надо подстрочник какой то для этой драмы.

Leo
16.01.2017
21:31:17
и что syn-flood тот же нельзя фильтровать сразу только syncookies

Ivan
16.01.2017
21:31:26
А то я так и не понял мякотки, о чем тут Доны спорят.

Leo
16.01.2017
21:31:28
может сработать, да, но отвалится много важного

Alex
16.01.2017
21:31:51
Не, вот это немного другая история - потерянный ACK в трехстороннем рукопожатии. Ну так крутите и другие ручки, например.

Leo
16.01.2017
21:31:59
кратко: DDoS это чудный новый мир, нет готового решения, как “закупили цыску — стало хорошо”

Maxim
16.01.2017
21:32:31

Ivan
16.01.2017
21:32:38
А правильно я понимаю что вот эти ваши synкуки это когда цель атаки какой то отдельный сервер ваш

Igor
16.01.2017
21:32:57
ага

Leo
16.01.2017
21:32:57
да
и если это сервер тупого абонента
то пока мы объясним, как их включать, он ляжет наглухо

Maxim
16.01.2017
21:33:33
Это ж ваши абоненты, они ж вам денежки несут
Так заботу выключать не надо. Аккуратно, нежно. Ведь далеко не каждый изнасилованный таковым является, если степень насилия сменить на согласие путем предварительной подготовки...

Ivan
16.01.2017
21:33:51
И там типа что трафика много чтоль? при syn атаке этйо? Ну погаснет сервер у абона, проблема в сети будет?

Leo
16.01.2017
21:33:51

Ivan
16.01.2017
21:34:36
Про него я понял, ну я за каждый клиентский ип ен переживаю, я переживаю что б меня не положили этим