zulu_Radist Опубликовано: January 18, 2015 at 17:58 Опубликовано: January 18, 2015 at 17:58 привет всем прошу помощи в работе NAS-сервер для агрегации тоннелей pptp, используем accel на сервере пул реалок уже который раз выхватываю интересную дос атаку прет куча трафика с двух каналов по гигосу), валит мне к чертям весь инет канал, причем на адрес который из пула этого сервера, НО этот адрес в данный момент никому не выдан для тоннеля не могу правильно описать задачу но в общем как-то так есть выхлоп tcpdump если он поможет как бороться с таким?
md5 Опубликовано: January 18, 2015 at 18:00 Опубликовано: January 18, 2015 at 18:00 только дампить трафик и смотреть куда че идет. ну а потом зарезать
ttttt Опубликовано: January 18, 2015 at 18:02 Опубликовано: January 18, 2015 at 18:02 Бороться с таким только блэкхолом адреса, свяжитесь с аплинками.
supportod Опубликовано: January 18, 2015 at 18:02 Опубликовано: January 18, 2015 at 18:02 Бороться с таким только блэкхолом адреса, свяжитесь с аплинками. +1
loki Опубликовано: January 18, 2015 at 18:13 Опубликовано: January 18, 2015 at 18:13 Как показывает опыт, особо злостный атакующий после блэкхолинга жертвы, меняет адрес для атаки.
zulu_Radist Опубликовано: January 18, 2015 at 18:14 Автор Опубликовано: January 18, 2015 at 18:14 (изменено) Как показывает опыт, особо злостный атакующий после блэкхолинга жертвы, меняет адрес для атаки. именно это и происходит есть еще варианты? Изменено January 18, 2015 at 18:14 пользователем zulu_Radist
loki Опубликовано: January 18, 2015 at 18:16 Опубликовано: January 18, 2015 at 18:16 Как показывает опыт, особо злостный атакующий после блэкхолинга жертвы, меняет адрес для атаки. именно это и происходит есть еще варианты? А Вы нам дамп приложите, DDoS это или DoS?
zulu_Radist Опубликовано: January 18, 2015 at 18:21 Автор Опубликовано: January 18, 2015 at 18:21 (изменено) вот кусочек 22:54:57.842851 IP 176.111.79.154.36560 > 176.100.63.44.16324: UDP, length 1316 22:54:57.842853 IP 176.111.79.154.36560 > 176.100.63.44.16324: UDP, length 1316 22:54:57.842854 IP 176.111.79.154.36560 > 176.100.63.44.16324: UDP, length 1316 22:54:57.842856 IP 176.111.79.154.36560 > 176.100.63.44.16324: UDP, length 1316 22:54:57.842857 IP 176.111.79.154.36560 > 176.100.63.44.16324: UDP, length 1316 22:54:57.842858 IP 176.111.79.154.36560 > 176.100.63.44.16324: UDP, length 1316 22:54:57.842859 IP 176.111.79.154.36560 > 176.100.63.44.16324: UDP, length 1316 22:54:57.842861 IP 176.111.79.154.36560 > 176.100.63.44.16324: UDP, length 1316 176.100.63.44 мой адрес из пула когда рублю в файрволе адрес атакующего 176.111.79.154 то он либо меняет свой адрес, либо меняет атаку на другой мой адрес жесть какая-то Изменено January 18, 2015 at 18:21 пользователем zulu_Radist
md5 Опубликовано: January 18, 2015 at 18:26 Опубликовано: January 18, 2015 at 18:26 тут же четко видно порт 36560 и протокол UDP зареж порт
loki Опубликовано: January 18, 2015 at 18:29 Опубликовано: January 18, 2015 at 18:29 Если атакующий из одной AS, то рубаните все сети этой AS. Если будут спуфнутыми адресами долбить, то городите synproxy.
alex_o Опубликовано: January 18, 2015 at 18:32 Опубликовано: January 18, 2015 at 18:32 (изменено) АС рубать бесполезно - от входящего мусора не избавит. deny source ip 176.111.79.0/24 proto udp на железяке перед насами (на бордере). Изменено January 18, 2015 at 18:39 пользователем alex_o
LV10 Опубликовано: January 18, 2015 at 18:35 Опубликовано: January 18, 2015 at 18:35 blackhole/фильтра на стороне аплинков. нулить и дискардить трафик у себя смысла не имеет, паразитный трафик все также протаскивается аплинком и отдается в порт.
alex_o Опубликовано: January 18, 2015 at 18:38 Опубликовано: January 18, 2015 at 18:38 blackhole/фильтра на стороне аплинков. нулить и дискардить трафик у себя смысла не имеет, паразитный трафик все также протаскивается аплинком и отдается в порт. Если чел покупает у аплинка больше 1Г, то физика стыка у него скорее всего 10Г. 10Г ДДоС - это редкость. В этом случае достаточно с аплинком договориться о берсте своей полосы временно в связи с ДДоС и зарезать у себя на входе бордера весь паразитный приезжающий мусор. Тогда все, что стоит за бордером будет работать нормально без перегруза портов.
loki Опубликовано: January 18, 2015 at 18:40 Опубликовано: January 18, 2015 at 18:40 АС рубать бесполезно - от входящего мусора не избавит. роут source ip 176.111.79.0/24 прото ЮДП ту нулл на железяке перед насами (на бордере). А каким боком роутинг к протоколам передачи данных относиться, покажите команду полностью )) ? Роут в Null это тот же блэкхолинг, только без передачи маршрута по цепочке аплинку.
LV10 Опубликовано: January 18, 2015 at 18:42 Опубликовано: January 18, 2015 at 18:42 blackhole/фильтра на стороне аплинков. нулить и дискардить трафик у себя смысла не имеет, паразитный трафик все также протаскивается аплинком и отдается в порт. Если чел покупает у аплинка больше 1Г, то физика стыка у него скорее всего 10Г. 10Г ДДоС - это редкость. В этом случае достаточно с аплинком договориться о берсте своей полосы временно в связи с ДДоС и зарезать у себя на входе бордера весь паразитный приезжающий мусор. Тогда все, что стоит за бордером будет работать нормально без перегруза портов. ТС четко указал проблему: "валит мне к чертям весь инет канал"
pavlabor Опубликовано: January 18, 2015 at 18:44 Опубликовано: January 18, 2015 at 18:44 (изменено) Как показывает опыт, особо злостный атакующий после блэкхолинга жертвы, меняет адрес для атаки. именно это и происходит есть еще варианты? Не меняет адрес, просто эта атака организовывается с торента или диси, и там атакующих может быть несколько тысяч. помогает ipfw add 10 deny udp from any not 53 to 176.100.63.44 на 5 минут - час. Блок можно выставлять скриптом, от нагрузки на сервак. Проблема, если натится несколько IP, не реально вычислить кого валят. Изменено January 18, 2015 at 18:47 пользователем pavlabor
ttttt Опубликовано: January 18, 2015 at 18:52 Опубликовано: January 18, 2015 at 18:52 Тут важно еще не делать это ручками, а автоматизировать процесс детекции и блэкхола.
loki Опубликовано: January 18, 2015 at 18:55 Опубликовано: January 18, 2015 at 18:55 Тут важно еще не делать это ручками, а автоматизировать процесс детекции и блэкхола. динамические acl по евенту ?
alex_o Опубликовано: January 18, 2015 at 18:56 Опубликовано: January 18, 2015 at 18:56 АС рубать бесполезно - от входящего мусора не избавит. роут source ip 176.111.79.0/24 прото ЮДП ту нулл на железяке перед насами (на бордере). А каким боком роутинг к протоколам передачи данных относиться, покажите команду полностью )) ? Роут в Null это тот же блэкхолинг, только без передачи маршрута по цепочке аплинку. Вы предлагаете у себя из роут-таблицы выкинуть префиксы AS досера. Это приведет лишь к тому, что вы не сможете слать СВОИ пакеты на досера, но ЕГО пакеты приедут к вам без проблем. Чтобы ддос-трэш не дошел до таргета, надо на каком-либо из хопов в трассе между соурсом и таргетом этот трэш дропать. Если у таргета более одного аплинка, то договариваться с каждым из аплинком о блэкхоле долго и сильно жестоко, да и не каждый из них еще захочет у себя временные костыли лепить. Поэтому проще дропать у себя на бордере. Единственное условие - чтобы каждый из аплинков при этом оставался без пакет-лоса. Если идет атака именно ДДоС, а не ДоС, то у досера соурсов множество в разных АС. Тут надо только дропать фильтрами входящий траф по каким-то критериям.
oksy Опубликовано: January 18, 2015 at 19:01 Опубликовано: January 18, 2015 at 19:01 1. Фильтрация трафика на своем бордере не даст особого результата. Тем более при использовании UDP. Ддосер просто забьет ваш канал и на этом все закончится. 2. Атаки в 10Г бывают, причем часто и ничего тут экстраординарного нету. Для организации атаки протоколом UDP в 10Г многого от ддосера не потребуется. 3. Как уже правильно сказали, резать атаку надо у аплинков с помощью блэкхола, но и тут есть некоторая проблема. Блэкхол у себя нормальный аплинк держать не станет, потому что оно ему тоже не надо платить за трафик ддосовый, следовательно он этот блэкхол должен отдавать своим апстримам и так далее. Ну и вторая сторона блэкхолинга. В блэкхол, если по-взролому, сетями не отправляют. В блэкхол отправляют адреса, то есть /32. Это нужно иметь в веду. 4. Переходим к главному вопросу - детектирование ддоса. Это самый сложный процесс, хотя при такой ситуации, как описана ТС, задача не является невыполнимой. Если вы в состоянии автоматизировать этот процесс, то необходимо договориться с апстримами, чтоб вам предоставили возможность использования блэкхола, а дальше схема простая - детект ддоса, установка анонса адреса нарушителя в определенное комьюнити, которое ваш провайдер принимает от вас в качестве блэкхола. Вобщем, на самом деле, борьба с ддосом, это довольно сложная и наукоемкая задача, но выполнимая, особенно в случае, описанном ТС.
zulu_Radist Опубликовано: January 18, 2015 at 19:02 Автор Опубликовано: January 18, 2015 at 19:02 друзья, все очень круто, спасибо но я думаю надо копать в другую сторону никто не обратил внимание на одну важную вещь адрес на который прет трафик по сути не доступен и надо я так понял дать отлуп что хоста нет, трафик иди нах) бордер у него статик роут что такой то пул адресов за этим насом в момент атаки адрес который подвергается атаке не выдан никакому клиенту, тоннель не поднят с таким внешним адресом, хоста нет! может на НАСе надо ковырнуть или файрвол или sysctl чтобы он говорил епона мать destination host unreachable отвали нафик
KaYot Опубликовано: January 18, 2015 at 19:02 Опубликовано: January 18, 2015 at 19:02 АС рубать бесполезно - от входящего мусора не избавит. роут source ip 176.111.79.0/24 прото ЮДП ту нулл на железяке перед насами (на бордере). А каким боком роутинг к протоколам передачи данных относиться, покажите команду полностью )) ? Роут в Null это тот же блэкхолинг, только без передачи маршрута по цепочке аплинку. Вы предлагаете у себя из роут-таблицы выкинуть префиксы AS досера. Это приведет лишь к тому, что вы не сможете слать СВОИ пакеты на досера, но ЕГО пакеты приедут к вам без проблем. Чтобы ддос-трэш не дошел до таргета, надо на каком-либо из хопов в трассе между соурсом и таргетом этот трэш дропать. Если у таргета более одного аплинка, то договариваться с каждым из аплинком о блэкхоле долго и сильно жестоко, да и не каждый из них еще захочет у себя временные костыли лепить. Поэтому проще дропать у себя на бордере. Единственное условие - чтобы каждый из аплинков при этом оставался без пакет-лоса. Если идет атака именно ДДоС, а не ДоС, то у досера соурсов множество в разных АС. Тут надо только дропать фильтрами входящий траф по каким-то критериям. К сожалению это сработает только только в правильно спроектированных сетях, причем не мелкого размера. С 10g физикой к аплинкам, и без жесткого шейпера.. Если там физика гиговая - никакие заклинания кроме блекхола по комьюниюнити/звонку у аплинка не помогут.
loki Опубликовано: January 18, 2015 at 19:03 Опубликовано: January 18, 2015 at 19:03 Вы предлагаете у себя из роут-таблицы выкинуть префиксы AS досера. Вам показалось, я такого ничего не предлагал. Я только подчеркнул Ваш "трэш" по поводу ip route x.x.x.x/x proto udp =))) Чтобы ддос-трэш не дошел до таргета Ага, нужно его зафильтровать. Блэкхол - самый легкий метод, если аплинк его поддерживает. Если нет, то только комплекс мероприятий.
KaYot Опубликовано: January 18, 2015 at 19:04 Опубликовано: January 18, 2015 at 19:04 друзья, все очень круто, спасибо но я думаю надо копать в другую сторону никто не обратил внимание на одну важную вещь адрес на который прет трафик по сути не доступен и надо я так понял дать отлуп что хоста нет, трафик иди нах) бордер у него статик роут что такой то пул адресов за этим насом в момент атаки адрес который подвергается атаке не выдан никакому клиенту, тоннель не поднят с таким внешним адресом, хоста нет! может на НАСе надо ковырнуть или файрвол или sysctl чтобы он говорил епона мать destination host unreachable отвали нафик Кстати вполне возможный вариант что вы флудите сами себя, смотрели, трафик кругами не бегает от бордера к насу? Правильно таки маршруты /32 анонсировать бордеру, а на нем сделать блекхол на свои сети.
oksy Опубликовано: January 18, 2015 at 19:08 Опубликовано: January 18, 2015 at 19:08 в момент атаки адрес который подвергается атаке не выдан никакому клиенту, тоннель не поднят с таким внешним адресом, хоста нет! НАСРАТЬ на то, что не выдан! Учите матчасть! Для UDP протокола не обязательно, чтоб адрес был доступен! У вас идет классический UDP-флуд!
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВойти
Уже зарегистрированы? Войдите здесь.
Войти сейчас