seagull Опубликовано 6 апреля, 2011 · Жалоба Здравствуйте коллеги! Хочу поделится проблемой. Началось все с повышенной нагрузки нашего 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 у себя в транзите? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SLon26 Опубликовано 6 апреля, 2011 · Жалоба DOS на dns, была уязвимость в dns года полтара назад если помните, могут пытаться "отравить" dns кеш ваш. Или просто dos. Ну а про отношение ттк это называеться рас***яство. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 6 апреля, 2011 · Жалоба Ну а про отношение ттк это называеться рас***яство. А вообще интересно, какова политика операторов в смысле фильтрования адресов? Вот для BGP строятся фильтры, исходя из информации в RIPE, или вручную. А фильтрует ли кто-нибудь IP SRC адреса на предмет корректности? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SLon26 Опубликовано 6 апреля, 2011 · Жалоба Каждый оператор должен фильтровать на выход своих клиентов, чтобы те не создавали спуфинг. Хотя это и малопопулярно ввиду популярности ddos, в котором можно не заботиться о том что обратный адресс реальный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SLon26 Опубликовано 6 апреля, 2011 · Жалоба http://tools.ietf.org/html/bcp38 http://tools.ietf.org/html/bcp140 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 6 апреля, 2011 · Жалоба Каждый оператор должен фильтровать на выход своих клиентов, чтобы те не создавали спуфинг. Хотя это и малопопулярно ввиду популярности ddos, в котором можно не заботиться о том что обратный адресс реальный. Так ведь если все будут фильтровать SRC, тогда это и будет борьбой с DDoS, ведь левые пакеты не будут покидать сеть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SLon26 Опубликовано 6 апреля, 2011 (изменено) · Жалоба Ну почему же DDoS подразумивает использование куча зомби машин обычных пользователей, там как бы все равно реальный адрес использовать или левый. Важнее поймать командный центр который управляет ими. Это скорее помогает от обычной DoS, в которой допустим используется уязвимость удаленной машины и злой дядя хочет скрыть источник. Изменено 6 апреля, 2011 пользователем SLon26 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fedusia Опубликовано 6 апреля, 2011 · Жалоба Каждый оператор должен фильтровать на выход своих клиентов, чтобы те не создавали спуфинг. Хотя это и малопопулярно ввиду популярности ddos, в котором можно не заботиться о том что обратный адресс реальный. Так ведь если все будут фильтровать SRC, тогда это и будет борьбой с DDoS, ведь левые пакеты не будут покидать сеть? Да, но так помоему никто не делает, магистралы точно не будут строить prefix-lists они фильтруют по as-set + количество максимальных префиксов от даунстрима. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 6 апреля, 2011 · Жалоба А что Вам мешает на Вашех бордерах тупо всегда резать входящие с Вашими же IP ? И ТТК тут скорее всего не причем, транзитят трафик с вашими dst к вам. А что там оказался и src ваш же... это чревато такой транзитный трафик давить, я в свое время с ретном намучался, когда они мой исходящий трафик давили по причине что у них бест путь на меня стоит в другую сторону. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SLon26 Опубликовано 6 апреля, 2011 · Жалоба А что Вам мешает на Вашех бордерах тупо всегда резать входящие с Вашими же IP ? Думаю ему ничего не мешает, как он сказал ему канал жалко который тратиться на эти пакеты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 6 апреля, 2011 · Жалоба Там скорее канал тратится на ответы по этим доменам, причем скорее всего больше, чем сами запросы. ктото ддосит оригинальные NSы почкой запросов от таких вот сетей, которые считают что ктото за них должен сделать их антиспуфинг.. интересно они сами то фильтруют на выход чужие src ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fozz Опубликовано 6 апреля, 2011 (изменено) · Жалоба ТТК констатировали факт подмены IP источника, но локализовывать и вообще решать ее отказываются.Возможно самое простое решение будет заблокировать эти запросы у Вас на Firewall. К сожалению больше ничем помочь Вам не можем. Я немного удивлен, честно говоря, таким отношением со стороны ТТК. Ведь мы по сути платим за этот левый трафик. Скажите, во-первых, что это? Что-то типа DoS/DDoS? И нормально ли такое отношение со стороны апстримов к подделке SRC у себя в транзите? Обычно ТТК ставят на всех каналах URPF и такая ситуация должна была просто отсечься у них на роутерах. Странно. У Вас же хорошей практикой сделать на входящем интерфейсе что-то типа iptables -A FORWARD -i eth1.720 -s ваша.сеть/22 -j DROP Изменено 6 апреля, 2011 пользователем fozz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 6 апреля, 2011 · Жалоба У Вас же хорошей практикой сделать на входящем интерфейсе что-то типа iptables -A FORWARD -i eth1.720 -s ваша.сеть/22 -j DROP Да, конечно так и сделал, но сам факт несколько напрягает... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 6 апреля, 2011 · Жалоба Поставьте "зеркальное" правило, которое будет резать всё, что идёт от Вас но с чужими source-адресами, посмотрите на порезанные пакеты и больше ничему не удивляйтесь. ЗЫ. кривого софта хватает... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 6 апреля, 2011 · Жалоба Аналогичная ситуация была когда был аплинком сам ТТК, заблокировал такой трафик у себя на бордере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fozz Опубликовано 6 апреля, 2011 · Жалоба У Вас же хорошей практикой сделать на входящем интерфейсе что-то типа iptables -A FORWARD -i eth1.720 -s ваша.сеть/22 -j DROP Да, конечно так и сделал, но сам факт несколько напрягает... "это интернет, деточка, здесь могут и нах послать..." Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 6 апреля, 2011 · Жалоба По-моему, ерунда по сравнению с ~10 мегабитами 445/tcp из собственных сетей Казахтелекома в канал :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 6 апреля, 2011 · Жалоба вы смотрите с позиции своей нескольконогой нетранзитной АС, у вас только есть понятия "аплинк" и "пиринг", максимум "клиент" и то тупиковый. посмотрите с позиции большого оператора и подумайте почему ставить префикслисты, а тем более URPF на своих пиринг-аплинков-клиентов мягко говоря не масштабируемо, а ещё хуже может конективити угрохать при асиметрии потоков, которая сейчас повсеместно. здесь компромисс между масштабируемостью/работоспособностью и безопасностью/миром во всё мире. по моему проблема решится когда все операторы в мире поставят URPF на все интерфейсы всех своих одноногих клиентов. такого никогда не будет, да это и не 100% решение проблемы, т.к. всё равно найдутся провайдеры-государства которые проанонсят ютуб так что он везде убьётся. p.s. у меня такая проблема была, решил вышеописанным способом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 6 апреля, 2011 · Жалоба Была точно такая же проблема. Решилось файрволом на бордере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 7 апреля, 2011 (изменено) · Жалоба С одной стороны, ТТК в данной ситуации абсолютно прав - роутинг должен осуществляться на основании destination-ip. Но с другой стороны, они же ведь дропят трафик с bogons-source-ip. ИМХО, просто им технически сложно создать правило для дропа при destination-ip == source-ip, не на любом железе такое можно сделать. URPF, как уже писали выше, - штука довольно избирательная, а для транзитного оператора совершенно запретная. Топикстартер, а со своим аплинком не пробовали договориться, чтобы они дропили паразитный для вас трафик? Изменено 7 апреля, 2011 пользователем Alexandr Ovcharenko Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 7 апреля, 2011 · Жалоба во первых там IP SRC и DST РАЗНЫЕ, в первом сообщении. Да, скорее всего из 1 сети, но вы себе математику предсавляете, чтобы еще послушать анонсы, выбрать все анонсируемые сети и далее матчить, а не попадают ли срц и дст в 1 сеть ? я нет 2. Если ТТК где то и может фильтровать левые SRC, то исключительно на портах своих клиентов (да и то, мелких, как это выглядит при множественном подключении через транзитных операторов, я уже проходил. Хреново оно выглядит.). никакой подобной фильтрации на аплинках итд быть не может. Спасение утопающих, это сами знаете чье дело. зарежте на бордере входящий со своими SRC и исходящий с не своими SRC. этого за Вас никто не сделает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 7 апреля, 2011 · Жалоба Спасение утопающих, это сами знаете чье дело. зарежте на бордере входящий со своими SRC и исходящий с не своими SRC. этого за Вас никто не сделает. Ага, так и понял... Суровая правда жизни, в общем ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pliskinsad Опубликовано 8 апреля, 2011 · Жалоба uprf попросите у аплинка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 апреля, 2011 · Жалоба 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), но... В общем по итогу фильтруем сами :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 12 апреля, 2011 · Жалоба при чем тут ТТК ? Трафик к Вам, скорее всего с их аплинка. Какого они его должны вам не доставлять ? (а что там и СРЦ ваши, то, как бы, случайность.) А ддосят не вас, ддосят того, чьи NSы... на то и расчет, что вам пофиг, а таких вот по миру легион, со всех трафика на НСы столько, что там поплохеет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...