[seagull]

Здравствуйте коллеги!

 

Хочу поделится проблемой.

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

Дальше-больше. Выяснилось, что запросы идут с SRC адресов нашей автономки, но идут они не от нас, а из канала аплинка!

Вот такая вот фигня:

root# tcpdump -i eth1.720 -n src net my.net.144.0/22 and dst net  my.net.144.0/22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.720, link-type EN10MB (Ethernet), capture size 96 bytes
12:24:27.210134 IP my.net.146.33.34180 > my.net.146.1.53: 29732+ A? s164.as.yaowan.com. (36)
12:24:27.237273 IP my.net.146.27.36478 > my.net.146.1.53: 29732+ A? ad.bagtree.com. (32)
12:24:27.258446 IP my.net.146.76.34699 > my.net.146.1.53: 51210+ A? gameres.5173cdn.com. (37)
12:24:27.265979 IP my.net.146.6.42428 > my.net.146.1.53: 29732+ A? ftp2.tianyijue.com. (36)
12:24:27.269163 IP my.net.146.87.37931 > my.net.146.1.53: 51210+ A? web.ccjoy.com. (31)
12:24:27.272409 IP my.net.145.177.39359 > my.net.146.1.53: 51210+ A? images.27.cn. (30)
12:24:27.306448 IP my.net.146.67.36366 > my.net.146.1.53: 29732+ A? s12.astd.wan.360.cn. (37)
12:24:27.307461 IP my.net.145.177.42151 > my.net.146.1.53: 29732+ A? images1.bagtree.com. (37)
12:24:27.358066 IP my.net.146.21.35601 > my.net.146.1.53: 29732+ A? ws1.mbbimg.cn. (31)
12:24:27.382933 IP my.net.145.191.37281 > my.net.146.1.53: 29732+ A? s159.as.yaowan.com. (36)
12:24:27.398015 IP my.net.145.240.35142 > my.net.146.1.53: 29732+ A? www.bagtree.com. (33)

Написал аплинку в ТП, там долго думали. Потом подтвердили, что проблема есть, а левый трафик идет с ТТК, и ему (ТТК) направлено соответствующее письмо. А сегодня приходит ответ, цитирую дословно:

ТТК констатировали факт подмены IP источника, но локализовывать и вообще решать ее отказываются.

Возможно самое простое решение будет заблокировать эти запросы у Вас на Firewall.

К сожалению больше ничем помочь Вам не можем.

Я немного удивлен, честно говоря, таким отношением со стороны ТТК. Ведь мы по сути платим за этот левый трафик.

Скажите, во-первых, что это? Что-то типа DoS/DDoS?

И нормально ли такое отношение со стороны апстримов к подделке SRC у себя в транзите?

[SLon26]

DOS на dns, была уязвимость в dns года полтара назад если помните, могут пытаться "отравить" dns кеш ваш. Или просто dos. Ну а про отношение ттк это называеться рас***яство.

[seagull]

Ну а про отношение ттк это называеться рас***яство.

А вообще интересно, какова политика операторов в смысле фильтрования адресов?

Вот для BGP строятся фильтры, исходя из информации в RIPE, или вручную.

А фильтрует ли кто-нибудь IP SRC адреса на предмет корректности?

[SLon26]

Каждый оператор должен фильтровать на выход своих клиентов, чтобы те не создавали спуфинг. Хотя это и малопопулярно ввиду популярности ddos, в котором можно не заботиться о том что обратный адресс реальный.

[SLon26]

http://tools.ietf.org/html/bcp38

http://tools.ietf.org/html/bcp140

[seagull]

Каждый оператор должен фильтровать на выход своих клиентов, чтобы те не создавали спуфинг. Хотя это и малопопулярно ввиду популярности ddos, в котором можно не заботиться о том что обратный адресс реальный.

Так ведь если все будут фильтровать SRC, тогда это и будет борьбой с DDoS, ведь левые пакеты не будут покидать сеть?

[SLon26]

Ну почему же DDoS подразумивает использование куча зомби машин обычных пользователей, там как бы все равно реальный адрес использовать или левый. Важнее поймать командный центр который управляет ими.

Это скорее помогает от обычной DoS, в которой допустим используется уязвимость удаленной машины и злой дядя хочет скрыть источник.

Изменено 6 апреля, 2011 пользователем SLon26

[fedusia]

Каждый оператор должен фильтровать на выход своих клиентов, чтобы те не создавали спуфинг. Хотя это и малопопулярно ввиду популярности ddos, в котором можно не заботиться о том что обратный адресс реальный.

Так ведь если все будут фильтровать SRC, тогда это и будет борьбой с DDoS, ведь левые пакеты не будут покидать сеть?

 

Да, но так помоему никто не делает, магистралы точно не будут строить prefix-lists они фильтруют по as-set + количество максимальных префиксов от даунстрима.

[st_re]

А что Вам мешает на Вашех бордерах тупо всегда резать входящие с Вашими же IP ? И ТТК тут скорее всего не причем, транзитят трафик с вашими dst к вам. А что там оказался и src ваш же... это чревато такой транзитный трафик давить, я в свое время с ретном намучался, когда они мой исходящий трафик давили по причине что у них бест путь на меня стоит в другую сторону.

[SLon26]

А что Вам мешает на Вашех бордерах тупо всегда резать входящие с Вашими же IP ?

Думаю ему ничего не мешает, как он сказал ему канал жалко который тратиться на эти пакеты.

[st_re]

Там скорее канал тратится на ответы по этим доменам, причем скорее всего больше, чем сами запросы. ктото ддосит оригинальные NSы почкой запросов от таких вот сетей, которые считают что ктото за них должен сделать их антиспуфинг.. интересно они сами то фильтруют на выход чужие src ?

[fozz]

ТТК констатировали факт подмены IP источника, но локализовывать и вообще решать ее отказываются.

Возможно самое простое решение будет заблокировать эти запросы у Вас на Firewall.

К сожалению больше ничем помочь Вам не можем.

Я немного удивлен, честно говоря, таким отношением со стороны ТТК. Ведь мы по сути платим за этот левый трафик.

Скажите, во-первых, что это? Что-то типа DoS/DDoS?

И нормально ли такое отношение со стороны апстримов к подделке SRC у себя в транзите?

Обычно ТТК ставят на всех каналах URPF и такая ситуация должна была просто отсечься у них на роутерах. Странно.

У Вас же хорошей практикой сделать на входящем интерфейсе что-то типа

iptables -A FORWARD -i eth1.720 -s ваша.сеть/22 -j DROP

Изменено 6 апреля, 2011 пользователем fozz

[seagull]

У Вас же хорошей практикой сделать на входящем интерфейсе что-то типа

iptables -A FORWARD -i eth1.720 -s ваша.сеть/22 -j DROP

Да, конечно так и сделал, но сам факт несколько напрягает...

[UglyAdmin]

Поставьте "зеркальное" правило, которое будет резать всё, что идёт от Вас но с чужими source-адресами, посмотрите на порезанные пакеты и больше ничему не удивляйтесь.

ЗЫ. кривого софта хватает...

[disappointed]

Аналогичная ситуация была когда был аплинком сам ТТК, заблокировал такой трафик у себя на бордере.

[fozz]

У Вас же хорошей практикой сделать на входящем интерфейсе что-то типа

iptables -A FORWARD -i eth1.720 -s ваша.сеть/22 -j DROP

Да, конечно так и сделал, но сам факт несколько напрягает...

"это интернет, деточка, здесь могут и нах послать..."

[GFORGX]

По-моему, ерунда по сравнению с ~10 мегабитами 445/tcp из собственных сетей Казахтелекома в канал :)

[ingress]

вы смотрите с позиции своей нескольконогой нетранзитной АС, у вас только есть понятия "аплинк" и "пиринг", максимум "клиент" и то тупиковый.

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

здесь компромисс между масштабируемостью/работоспособностью и безопасностью/миром во всё мире.

 

по моему проблема решится когда все операторы в мире поставят URPF на все интерфейсы всех своих одноногих клиентов.

такого никогда не будет, да это и не 100% решение проблемы, т.к. всё равно найдутся провайдеры-государства которые проанонсят ютуб так что он везде убьётся.

 

p.s. у меня такая проблема была, решил вышеописанным способом.

[vurd]

Была точно такая же проблема. Решилось файрволом на бордере.

[Alexandr Ovcharenko]

С одной стороны, ТТК в данной ситуации абсолютно прав - роутинг должен осуществляться на основании destination-ip. Но с другой стороны, они же ведь дропят трафик с bogons-source-ip. ИМХО, просто им технически сложно создать правило для дропа при destination-ip == source-ip, не на любом железе такое можно сделать. URPF, как уже писали выше, - штука довольно избирательная, а для транзитного оператора совершенно запретная.

Топикстартер, а со своим аплинком не пробовали договориться, чтобы они дропили паразитный для вас трафик?

Изменено 7 апреля, 2011 пользователем Alexandr Ovcharenko

[st_re]

во первых там IP SRC и DST РАЗНЫЕ, в первом сообщении. Да, скорее всего из 1 сети, но вы себе математику предсавляете, чтобы еще послушать анонсы, выбрать все анонсируемые сети и далее матчить, а не попадают ли срц и дст в 1 сеть ? я нет

2. Если ТТК где то и может фильтровать левые SRC, то исключительно на портах своих клиентов (да и то, мелких, как это выглядит при множественном подключении через транзитных операторов, я уже проходил. Хреново оно выглядит.). никакой подобной фильтрации на аплинках итд быть не может.

Спасение утопающих, это сами знаете чье дело. зарежте на бордере входящий со своими SRC и исходящий с не своими SRC. этого за Вас никто не сделает.

[seagull]

Спасение утопающих, это сами знаете чье дело. зарежте на бордере входящий со своими SRC и исходящий с не своими SRC. этого за Вас никто не сделает.

Ага, так и понял...

Суровая правда жизни, в общем ;)

[pliskinsad]

uprf попросите у аплинка.

[DVM-Avgoor]

12:24:27.258446 IP my.net.146.76.34699 > my.net.146.1.53: 51210+ A? gameres.5173cdn.com. (37)
12:24:27.265979 IP my.net.146.6.42428 > my.net.146.1.53: 29732+ A? ftp2.tianyijue.com. (36)
12:24:27.269163 IP my.net.146.87.37931 > my.net.146.1.53: 51210+ A? web.ccjoy.com. (31)
12:24:27.272409 IP my.net.145.177.39359 > my.net.146.1.53: 51210+ A? images.27.cn. (30)

Написал аплинку в ТП, там долго думали. Потом подтвердили, что проблема есть, а левый трафик идет с ТТК, и ему (ТТК) направлено соответствующее письмо.

Я немного удивлен, честно говоря, таким отношением со стороны ТТК. Ведь мы по сути платим за этот левый трафик.

Скажите, во-первых, что это? Что-то типа DoS/DDoS?

И нормально ли такое отношение со стороны апстримов к подделке SRC у себя в транзите?

 

Все точно так же у нас. Пара тикетов в ТТК - никаких результатов, источник не найден.

Да и для ДДоС оно больно уж медленно сыпется, терпимо в общем.

Меня тоже удивило отношение к проблеме со стороны ТТК, сильно не хотят они решать вопросы. Максимум удалось убедить снять стату (вероятно с PE), но...

В общем по итогу фильтруем сами :)

[st_re]

при чем тут ТТК ? Трафик к Вам, скорее всего с их аплинка. Какого они его должны вам не доставлять ? (а что там и СРЦ ваши, то, как бы, случайность.)

 

А ддосят не вас, ддосят того, чьи NSы... на то и расчет, что вам пофиг, а таких вот по миру легион, со всех трафика на НСы столько, что там поплохеет.