MIRhosting.com: Ну там есть хитрости детекции, на уровне пакетов. как самое простое: discard first packet и смотреть как прилетит второй "первый". Особенно в UDP.
Поэтому, да, для L7 атак совтферный детектор имеет смысл и вполне вероятно что будет работать лучше чем железные решения. Особенно если блочить наверху. Но для volume atack, для поддельных пакетов и всякого синфлуд все же тазиками датацентр на сотни гигабит не прикроешь. Впрочем, удивите )
---------- Добавлено 15.06.2016 в 22:08 ----------
Кстати, Алексей, как показал наш опыт фильтрации когда очень сильно досили white-suite (тут тема была на миллион страниц), и когда у нас еще не было железных решений, а всякие cisco guard и прочие арборы мягко говоря не хотели понимать в чем проблема и тупо блочили все подряд, мы пилили на коленке в авральном режиме свои фильтры. И как показал опыт, freebsd выигрывала линукс минимум в 3 раза по количеству пакетов, на абсолютно идентичном железе.
Так, для сведения, может пригодиться.
L7 DOS - это отдельная тема, там все сложнее. Мне кажется более разумно с ним бороться ближе к приложению, так как можно получить больше полезной информации. По поводу FreeBSD - согласен, у FreeBSD более разумная реализация сетевого стека. Недаром JunOS в той или иной мере основан на FreeBSD.
kxk: alexeyymanikin, Это коммерческая тайна и мы подключены не через одного провайдера иначе мы бы обрушили интернет атаками какие прилетают в нас.
Голословные заявления можно делать любые, 700-7000000 гигабит, разницы особой нет. Большая часть сервисов предоставляет свою статистику тот же cloudfire. Даже у куратора есть много полезных инструментов. Посмотреть через кого прилетают Ваши анонсы, и кому Вы анонсируете свою AS не сложно. По крайней мере AS на которой располагается Ваш сайт явно проигрываем тому же куратору. И нет не слова о том, что эта AS Ваша. На сайте нет информации о юридическом лице, телефона, не одного документа.
По этому данные заявления я не воспринимаю всерьез без подтверждающей информации. Я не спорю Вам очень хочется как то заявить о себе, но делать стоит обосновано.
В общем коллеги давай не будет разводить срач, видимо пользу от данного форума становиться все меньше и меньше.
ENELIS: alexeyymanikin, основная проблема ддоса не в конечном пользователе, а в забитых каналах.
Большинство атак без особых проблем фильтруются на 10гбит канале и немного оттъюненным ядром, драйвером карты. Можно вообще в netmap пустить и рисовать что угодно прозрачно.
Конечно будет замечательно, если Вы поделитесь с обществом, но в итоге для большинства это все равно упрется в деньги, ибо 1гбит канал не выдержит типичной атаки нового времени.
Атаки на канальную емкость нас не сильно беспокоят, https://beget.ru/news/2015/network_2015 год назад емкость наших внешних каналов превышала 90 гигабит, сейчас более 170 гигабит. В качестве граничных маршрутизаторов Juniper MX960 и MX480. Они отлично справляются с задачей фильтрации UDP, ICMP и прочих атак с усилением. Это атаки чуть более низкого уровня - l2-l3. Ну и как бонус - большинство провайдеров уже поддерживает BGP FlowSpec и эти атаки можно фильтровать на стороне аплинка.
---------- Добавлено 15.06.2016 в 18:25 ----------
kxk: ENELIS, +1
Придёт к ТС 20 Гбит амплификации с возможностью геометрического роста и он пожалеет что связался с этими самыми ддосами, на наш статический сайт периодически прилетает и 300 Гбит этой самой амплификации, на клиента недавно мульти-протокольно летело 700Гбит всякого мусора, но рассеив на бордеры и ещё наши фирменные системы не наша сеть, ни клиент (небольшие задержки перед открытием сайта) не пострадали.
А, так идейка хорошая, но без своего BGP бесполезная.
Лично знаком с сетевыми инженерами с retn, beeline, prometay, runnet, науканет - "на клиента недавно мульти-протокольно летело 700Гбит всякого мусора" 700 гигабит ихняя сеть не выдержит в одну точку, суммарный трафик по сети - да вполне.
покажите мне графики провайдера через которого Вы подключены или хотя бы дайте мне их контакты - мне очень интересно с ними пообщаться.
Jurgen's: а когда phpmyadmin почините?
#2002 - Connection refused — Сервер не отвечает (либо локальный сокет сервера MySQL неверно настроен).
mysqli_real_connect(): (HY000/2002): Connection refused
Ошибка при указании соединения для controluser в конфигурации.
Починил данные для доступа
mysqlUser: readonly
mysqlPasswd: readonly
---------- Добавлено 15.06.2016 в 15:11 ----------
Добавил интересную статистику по среднему возрасту доменов на AS, IP, NS серверах. В срезе по определенной дате не очень интересно, но тенденции изменения показательные.
Если возраст уменьшается - значит количество новых доменов увеличивается. Если возраст увеличивается - значит новые домены добавляются медленнее чем удаляются старые.
SQL для выборки TOP самых старых AS
SELECT as_old.asn AS 'AS', Substring(as_list.descriptions, 1, 40) AS 'Descriptions', as_list.country AS 'Country', as_count.count AS 'Count', as_old.old AS 'Old' FROM as_list AS as_list, as_domain_old_count_statistic AS as_old, as_count_statistic AS as_count WHERE as_list.id = as_old.asn AND as_count.date = '2016-06-15' AND as_count.asn = as_old.asn AND as_old.date = '2016-06-15' AND as_old.tld = 'ru' AND as_count.tld = 'ru' ORDER BY as_old.old DESC LIMIT 20;
ТОР 20 самых старых AS (по возрасту доменов в зоне .ru)
ТОР 20 самых молодых AS (по возрасту доменов в зоне .ru)
Явная корреляция между датой основания компании и возрастом доменов на ней
Префиксы закрепляются за AS, в Ripe можно прописывать кому они принадлежат, но в конечном счете владелец IP адресов все равно владелец AS. И это - AS203226 разве на Ваша AS ?
Нет, только данные полученные от ДНС без каких то фильтров.
> проверять все DNS доменов на наличие в них наименования провайдера
Это несколько неправильно. Например, у нас есть домены с нс серверами в старом домене knutov.net и в новом после ребрендинга много лет назад dobrohost.ru. И есть еще два домена с нс серверами, относящимися к нашим вдс, совсем в других доменах. С 1stat можно было отправить список нс серверов и потом всё группировалось правильно.
(был бы проект на перле — я бы дописал нужную функциональность, но увы).
и мой ответ
За списком NS серверов нужно следить — это большая проблема. Опять же Вы правильно сказали — домены на других серверах есть не только у Вас, актуализировать информацию для ТОП 20 будет не очень сложно (далее сложнее), но это в любом случае ручная работа. Постоянно придется обновлять. В данном случае более корректно смотреть по количеству доменов на AS.
В текущей версии сайта — это вывод агрегированных данных из БД. Если есть желание, в понедельник могу набросать интерфейс для сопоставления NS, MX, сетей, AS c провайдером и предоставить его Вам =)
sql = """SELECT asn%s as as_number, count(*) as count FROM domain_history WHERE delegated = 'Y' AND tld = '%s' AND date_start <= '%s' AND date_end >= '%s' GROUP BY asn%s HAVING count(*) > 50 ORDER BY count(*) desc""" % (i, zone, date, date, i)
на AS должно быть 50 доменов.
Для остальных агрегирующих таблиц аналогично, от 50 доменов. Можно и с 10 доменами пересчитать - все данные есть.
У маленьких хостингов нет своих сетей, они берут в аренду IP адреса у тех же дата-центров. У более или менее нормальных - почти всегда есть своя AS и даже если они анонсируют свою AS через сеть ДЦ - в итоге это все равно их адреса и они отображаются в статистике.
Без своей AS невозможно управлять связанностью, балансировать мощные DDOS, оптимизировать маршруты, создавать CDN, решать проблемы плохих маршрутов. Я уже не говорю о банальном переезде в другой ДЦ. Мое мнение у нормального хостинга должна быть своя AS - и если посмотреть любую статистику у всех крупных хостингов есть своя AS. Это один из компонентов качества услуги. Хостинг это комплексное решение, а не аренда сервера в ДЦ и продажа его кусочков.
По поводу статистики statonline.ru они берут значения из базы регистраторов + как то пытаются учитывать посещаемость. Алгоритм для меня не понятный, хотя я общался с человеком создавшим этот сервис.
А какой домен и какие для него указывались NS сервера ? А так же менялись ли они в ближайшее время ?
Ну там есть хитрости детекции, на уровне пакетов. как самое простое: discard first packet и смотреть как прилетит второй "первый". Особенно в UDP.
Поэтому, да, для L7 атак совтферный детектор имеет смысл и вполне вероятно что будет работать лучше чем железные решения. Особенно если блочить наверху. Но для volume atack, для поддельных пакетов и всякого синфлуд все же тазиками датацентр на сотни гигабит не прикроешь. Впрочем, удивите )
---------- Добавлено 15.06.2016 в 22:08 ----------
Кстати, Алексей, как показал наш опыт фильтрации когда очень сильно досили white-suite (тут тема была на миллион страниц), и когда у нас еще не было железных решений, а всякие cisco guard и прочие арборы мягко говоря не хотели понимать в чем проблема и тупо блочили все подряд, мы пилили на коленке в авральном режиме свои фильтры. И как показал опыт, freebsd выигрывала линукс минимум в 3 раза по количеству пакетов, на абсолютно идентичном железе.
Так, для сведения, может пригодиться.
L7 DOS - это отдельная тема, там все сложнее. Мне кажется более разумно с ним бороться ближе к приложению, так как можно получить больше полезной информации. По поводу FreeBSD - согласен, у FreeBSD более разумная реализация сетевого стека. Недаром JunOS в той или иной мере основан на FreeBSD.
alexeyymanikin, Это коммерческая тайна и мы подключены не через одного провайдера иначе мы бы обрушили интернет атаками какие прилетают в нас.
Голословные заявления можно делать любые, 700-7000000 гигабит, разницы особой нет. Большая часть сервисов предоставляет свою статистику тот же cloudfire. Даже у куратора есть много полезных инструментов. Посмотреть через кого прилетают Ваши анонсы, и кому Вы анонсируете свою AS не сложно. По крайней мере AS на которой располагается Ваш сайт явно проигрываем тому же куратору. И нет не слова о том, что эта AS Ваша. На сайте нет информации о юридическом лице, телефона, не одного документа.
По этому данные заявления я не воспринимаю всерьез без подтверждающей информации. Я не спорю Вам очень хочется как то заявить о себе, но делать стоит обосновано.
В общем коллеги давай не будет разводить срач, видимо пользу от данного форума становиться все меньше и меньше.
alexeyymanikin, основная проблема ддоса не в конечном пользователе, а в забитых каналах.
Большинство атак без особых проблем фильтруются на 10гбит канале и немного оттъюненным ядром, драйвером карты. Можно вообще в netmap пустить и рисовать что угодно прозрачно.
Конечно будет замечательно, если Вы поделитесь с обществом, но в итоге для большинства это все равно упрется в деньги, ибо 1гбит канал не выдержит типичной атаки нового времени.
Атаки на канальную емкость нас не сильно беспокоят, https://beget.ru/news/2015/network_2015 год назад емкость наших внешних каналов превышала 90 гигабит, сейчас более 170 гигабит. В качестве граничных маршрутизаторов Juniper MX960 и MX480. Они отлично справляются с задачей фильтрации UDP, ICMP и прочих атак с усилением. Это атаки чуть более низкого уровня - l2-l3. Ну и как бонус - большинство провайдеров уже поддерживает BGP FlowSpec и эти атаки можно фильтровать на стороне аплинка.
---------- Добавлено 15.06.2016 в 18:25 ----------
ENELIS, +1
Придёт к ТС 20 Гбит амплификации с возможностью геометрического роста и он пожалеет что связался с этими самыми ддосами, на наш статический сайт периодически прилетает и 300 Гбит этой самой амплификации, на клиента недавно мульти-протокольно летело 700Гбит всякого мусора, но рассеив на бордеры и ещё наши фирменные системы не наша сеть, ни клиент (небольшие задержки перед открытием сайта) не пострадали.
А, так идейка хорошая, но без своего BGP бесполезная.
Лично знаком с сетевыми инженерами с retn, beeline, prometay, runnet, науканет - "на клиента недавно мульти-протокольно летело 700Гбит всякого мусора" 700 гигабит ихняя сеть не выдержит в одну точку, суммарный трафик по сети - да вполне.
покажите мне графики провайдера через которого Вы подключены или хотя бы дайте мне их контакты - мне очень интересно с ними пообщаться.
а когда phpmyadmin почините?
#2002 - Connection refused — Сервер не отвечает (либо локальный сокет сервера MySQL неверно настроен).
mysqli_real_connect(): (HY000/2002): Connection refused
Ошибка при указании соединения для controluser в конфигурации.
Починил данные для доступа
mysqlUser: readonly
mysqlPasswd: readonly
---------- Добавлено 15.06.2016 в 15:11 ----------
Добавил интересную статистику по среднему возрасту доменов на AS, IP, NS серверах. В срезе по определенной дате не очень интересно, но тенденции изменения показательные.
Если возраст уменьшается - значит количество новых доменов увеличивается. Если возраст увеличивается - значит новые домены добавляются медленнее чем удаляются старые.
SQL для выборки TOP самых старых AS
Substring(as_list.descriptions, 1, 40) AS 'Descriptions',
as_list.country AS 'Country',
as_count.count AS 'Count',
as_old.old AS 'Old'
FROM as_list AS as_list,
as_domain_old_count_statistic AS as_old,
as_count_statistic AS as_count
WHERE as_list.id = as_old.asn
AND as_count.date = '2016-06-15'
AND as_count.asn = as_old.asn
AND as_old.date = '2016-06-15'
AND as_old.tld = 'ru'
AND as_count.tld = 'ru'
ORDER BY as_old.old DESC
LIMIT 20;
ТОР 20 самых старых AS (по возрасту доменов в зоне .ru)
ТОР 20 самых молодых AS (по возрасту доменов в зоне .ru)
Явная корреляция между датой основания компании и возрастом доменов на ней
Префиксы закрепляются за AS, в Ripe можно прописывать кому они принадлежат, но в конечном счете владелец IP адресов все равно владелец AS. И это - AS203226 разве на Ваша AS ?
Нет, только данные полученные от ДНС без каких то фильтров.
Я с Вами соглашусь для больших хостингов более актуально AS.
Но не все сразу стали большими =) Все начинали с малого - один сервер или того хуже как у меня было одна VPS (правда я там только панель делал) =)
Иметь статистику всегда приятно, плюс мотивация. Переместился на 10 позиций вверх - можно отметить =)
Коллеги на хабре появился интересный комментарий
Это несколько неправильно. Например, у нас есть домены с нс серверами в старом домене knutov.net и в новом после ребрендинга много лет назад dobrohost.ru. И есть еще два домена с нс серверами, относящимися к нашим вдс, совсем в других доменах. С 1stat можно было отправить список нс серверов и потом всё группировалось правильно.
(был бы проект на перле — я бы дописал нужную функциональность, но увы).
и мой ответ
В текущей версии сайта — это вывод агрегированных данных из БД. Если есть желание, в понедельник могу набросать интерфейс для сопоставления NS, MX, сетей, AS c провайдером и предоставить его Вам =)
Если есть желание давайте заполним WIKI https://github.com/AlexeyManikin/domain_statistic/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA-%D0%BF%D1%80%D0%BE%D0%B2%D0%B0%D0%B9%D0%B4%D0%B5%D1%80%D0%BE%D0%B2 и далее я перенесу информацию в базу
Вся прелесть открытого кода - можно посмотреть
https://github.com/AlexeyManikin/domain_statistic/blob/master/classes/statistic.py
Если речь идет о AS
WHERE delegated = 'Y' AND tld = '%s' AND date_start <= '%s' AND date_end >= '%s'
GROUP BY asn%s
HAVING count(*) > 50
ORDER BY count(*) desc""" % (i, zone, date, date, i)
на AS должно быть 50 доменов.
Для остальных агрегирующих таблиц аналогично, от 50 доменов. Можно и с 10 доменами пересчитать - все данные есть.
У маленьких хостингов нет своих сетей, они берут в аренду IP адреса у тех же дата-центров. У более или менее нормальных - почти всегда есть своя AS и даже если они анонсируют свою AS через сеть ДЦ - в итоге это все равно их адреса и они отображаются в статистике.
Без своей AS невозможно управлять связанностью, балансировать мощные DDOS, оптимизировать маршруты, создавать CDN, решать проблемы плохих маршрутов. Я уже не говорю о банальном переезде в другой ДЦ. Мое мнение у нормального хостинга должна быть своя AS - и если посмотреть любую статистику у всех крупных хостингов есть своя AS. Это один из компонентов качества услуги. Хостинг это комплексное решение, а не аренда сервера в ДЦ и продажа его кусочков.
По поводу статистики statonline.ru они берут значения из базы регистраторов + как то пытаются учитывать посещаемость. Алгоритм для меня не понятный, хотя я общался с человеком создавшим этот сервис.
Достаточно сравнить http://statonline.ru/dns?order=DESC&rows_per_page=50&sort_field=domains_count&tld=ru&search= - данные по количеству доменов на NS серверах и данные на статистике хостингов http://statonline.ru/metrics/hosting?tld=ru.
С данными по NS явная корреляция, разница в разделегированных доменах.