Jump to content

Recommended Posts

Posted

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

 

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

Началось все с повышенной нагрузки нашего 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 у себя в транзите?

Posted

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

Posted

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

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

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

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

Posted

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

Posted

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

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

Posted (edited)

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

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

Edited by SLon26
Posted

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

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

 

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

Posted

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

Posted

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

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

Posted

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

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

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

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

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

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

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

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

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

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

Edited by fozz
Posted

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

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

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

Posted

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

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

Posted

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

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

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

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

Posted

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

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

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

 

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

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

 

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

Posted (edited)

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

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

Edited by Alexandr Ovcharenko
Posted

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

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

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

Posted

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

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

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

Posted
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), но...

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

Posted

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

 

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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...