Блог компании ddos-guard

Хостинг с полноценной защитой от DDoS-атак миф или реальность

24.09.2020 18:11:15 |

Автор: admin

THUMB

За первые два квартала 2020 года количество DDoS-атак выросло почти в три раза, при этом 65% из них приходится на примитивные попытки нагрузочного тестирования, которые без труда отключают беззащитные сайты небольших интернет-магазинов, форумов, блогов, СМИ.

Как выбрать защищенный от DDoS-атак хостинг? На что обратить внимание и к чему подготовиться, чтобы не оказаться в неприятном положении?

(Прививка от серого маркетинга внутри)

Доступность и разнообразие инструментов проведения DDoS-атак вынуждает владельцев онлайн-сервисов принимать соответствующие меры для противостояния угрозе. Задуматься о защите от DDoS стоит не после первого отказа, и даже не в комплексе мер по повышению отказоустойчивости инфраструктуры, а еще на этапе выбора площадки для размещения (хостинг провайдера или дата-центра).

DDoS-атаки классифицируют в зависимости от принадлежности протоколов, уязвимости которых эксплуатируются, к уровням модели взаимодействия открытых систем (OSI):

канальный (L2),
сетевой (L3),
транспортный (L4),
прикладной (L7).

С точки зрения систем защиты, их можно обобщить до двух групп: атаки уровня инфраструктуры (L2-L4) и уровня приложения (L7). Это связано с последовательностью выполнения алгоритмов анализа трафика и вычислительной сложностью: чем глубже смотрим в IP-пакет, тем больше требуется вычислительных мощностей.

Вообще, задача оптимизации вычислений при обработке трафика в режиме реального времени это тема для отдельного цикла статей. А сейчас давайте просто представим, что есть некоторый облачный провайдер с условно неограниченными вычислительными ресурсами, который может обеспечить защиту сайтов от атак на уровне приложений (в том числе бесплатно).

3 главных вопроса для определения степени защищенности хостинга от DDoS атак

Давайте посмотрим в условия оказания услуги защиты от DDoS-атак и Соглашение об уровне сервиса (Service Level Agreement, SLA) хостинг-провайдера. Находятся ли в них ответы на следующие вопросы:

какие технические ограничения заявляет поставщик услуги?
что происходит, когда заказчик выходит за рамки ограничений?
как хостинг-провайдер выстраивает защиту от DDoS-атак (технологии, решения, поставщики)?

Если вы не нашли эту информацию, то это повод либо задуматься о серьезности поставщика услуг, либо организовать базовую защиту от DDoS (L3-4) своими силами. Например, заказать физическое подключение к сети специализированного провайдера защиты.

Важно! Нет смысла обеспечивать защиту от атак уровня приложений с помощью Reverse Proxy, если ваш хостинг-провайдер не способен обеспечить защиту от атак уровня инфраструктуры: сетевое оборудование будет перегружено и станет недоступным, в том числе и для проксирующих серверов облачного провайдера (рисунок 1).

Рисунок 1. Прямая атака на сеть хостинг провайдера

И пусть вам не пытаются рассказывать сказки о том, что реальный IP-адрес сервера скрыт за облаком провайдера защиты, а значит атаковать его напрямую невозможно. В девяти случаях из десяти атакующему не составит труда найти реальный IP-адрес сервера или хотя бы сети хостинг-провайдера, чтобы положить целый ЦОД.

Как действуют хакеры в поисках реального IP-адреса

Под спойлерами несколько методов поиска реального IP-адреса (приводятся в ознакомительных целях).

Метод 1: Поиск в открытых источниках

Начать поиск можно с онлайн-сервиса Intelligence X: он ищет информацию в даркнете, на платформах для обмена документами, обрабатывает данные Whois, утечки общедоступных данных и многие другие источники.

Если по каким-то признакам (HTTP-заголовки, данные Whois и др.) удалось определить, что защита сайта организована с помощью Cloudflare, то начать поиск реального IP можно со списка, который содержит порядка 3 миллионов IP-адресов сайтов, расположенных за Cloudflare.

С помощью SSL-сертификата и сервиса Censys можно найти много полезного, в том числе и реальный IP-адрес сайта. Чтобы сформировать запрос по вашему ресурсу, перейдите во вкладку Certificates и введите:

_parsed.names: имясайта AND tags.raw: trusted

Для поиска IP-адресов серверов, пользующихся SSL-сертификатом, раскрывающийся список придется перебирать вручную с несколькими инструментами (вкладка Explore, далее выбираем IPv4 Hosts).

Метод 2: DNS

Поиск по истории изменения DNS-записей старый, проверенный способ. Предыдущий IP-адрес сайта может дать понять, на каком хостинге (или в каком дата-центре) он располагался. Среди онлайн-сервисов по удобству использования выделяются ViewDNS и SecurityTrails.

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

Если ничего, кроме имени старого DNS-сервера нет, то с помощью специальных утилит (dig, host или nslookup) можно запросить IP-адрес по доменному имени сайта, например:

_dig @имя_старого_dns_сервера имясайта

Метод 3: email

Идея метода в том, чтобы с помощью формы обратной связи / регистрации (или любым другим способом, позволяющим инициировать отправку письма) получить письмо на свою электронную почту и проверить заголовки, в частности поле Received.

В заголовке письма часто находится реальный IP-адрес MX-записи (сервер обмена электронной почтой), который может стать отправной точкой для поиска других серверов цели.

Инструменты для автоматизации поиска

Софт для поиска IP за щитом Cloudflare чаще всего работает по трем задачам:

сканирование неправильной настройки DNS, используя DNSDumpster.com;
сканирование по базе данных Crimeflare.com;
поиск поддоменов методом перебора по словарю.

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

Кроме того, существуют утилиты, предназначенные только для поиска поддоменов с помощью перебора по словарю и поиска в открытых источниках, например: Sublist3r или dnsrecon.

Как поиск происходит на практике

Для примера возьмем сайт seo.com, использующий Cloudflare, который найдем с помощью известного сервиса builtwith (позволяет как определять технологии / движки / CMS, на основе которых работает сайт, так и наоборот искать сайты по используемым технологиям).

При переходе по вкладке IPv4 Hosts сервис покажет список хостов с использованием сертификата. Чтобы найти нужный, ищите IP-адрес с открытым портом 443. Если он перенаправляет на нужный сайт, то задача выполнена, в противном случае необходимо добавить в заголовок Host HTTP-запроса доменное имя сайта (например, *curl -H "Host: имя_сайта" *https://IP_адрес).

В нашем случае поиск по базе Censys ничего не дал, идем дальше.

Поиск по DNS проведем через сервис https://securitytrails.com/dns-trails.

Перебирая адреса упомянутым в списках DNS серверов утилитой CloudFail, находим рабочие ресурсы. Результат будет готов уже через несколько секунд.

Используя только открытые данные и простые инструменты, мы определили реальный IP адрес веб-сервера. Остальное для атакующего дело техники.

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

Как хостинг-провайдер строит свою защиту

Собственная система защиты с фильтрующим оборудованием (рисунок 2).
Требует наличия:
1.1. Оборудования для фильтрации трафика и лицензии на программное обеспечение;
1.2. Штатных специалистов для его поддержки и эксплуатации;
1.3. Каналов доступа в интернет, которых будет достаточно для приема атак;
1.4. Значительной предоплаченной канальной полосы для приема мусорного трафика.

Рисунок 2. Собственная система защиты хостинг провайдера
Если рассматривать описанную систему как средство защиты от современных DDoS атак в сотни Gbps, то такая система будет стоить очень больших денег. Обладает ли хостинг-провайдер такой защитой? Готов ли он оплачивать мусорный трафик? Очевидно, что такая экономическая модель для провайдера убыточна, если в тарифах не предусмотрено дополнительных платежей.
Reverse Proxy (только для веб сайтов и некоторых приложений). Несмотря на ряд преимуществ, поставщик не гарантирует защиту от прямых DDoS-атак (см. рисунок 1). Хостинг-провайдеры зачастую предлагают такое решение как панацею, перекладывая ответственность на провайдера защиты.
Услуги специализированного облачного провайдера (использование его сети фильтрации) для защиты от DDoS атак на всех уровнях OSI (рисунок 3).

Рисунок 3. Комплексная защита от DDoS атак с помощью специализированного провайдера
Решение предполагает глубокую интеграцию и высокий уровень технической компетентности обеих сторон. Передача услуг по фильтрации трафика на аутсорс позволяет хостинг-провайдеру снизить цену добавочных сервисов для заказчика.

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

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

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

Подробнее..

Категории: Информационная безопасность , Хостинг , Блог компании ddos-guard , Хостинг-провайдер , Ddos-защита , Reverse proxy

Обидеть хостера каждый может. Должен ли провайдер отвечать за контент своих клиентов?

15.02.2021 16:13:26 |

Автор: admin

Сабж

Российский хостинг-провайдер (далее хостер) Макхост был оштрафован в ноябре 2020 года за то, что предоставлял услуги сайтам. Там любой желающий мог приобрести, казалось бы, безобидный товар плюшевого персонажа знаменитого мультсериала Свинка Пеппа.

Гендиректор Макхоста сказал в интервью Коммерсанту следующее: Присужденная сумма такова, будто хостинг-провайдер сам продавал эти игрушки и наживался, но никаких доходов от игрушек провайдер не получал, доходы от хостинга каждого сайта находятся в пределах 500 рублей в месяц.

В то же время, основной закон в сфере блокировки информации ФЗ N 149 содержит исчерпывающие основания для блокировки, а процедура урегулирования таких конфликтов предусмотрена только в отношении владельца сайта. Но никак не в отношении хостера.

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

Русские хакеры vs американский демократический строй

Наша компания предоставляет сетевой сервис по защите от DDoS-атак. И, к сожалению, мы тоже столкнулись с трудностями из-за действий клиента, пусть и немного иного характера.

История берет начало в ноябре 2020 года. Американский кибераналитик Брайан Кребс обратился к подписчикам в твиттере со следующими словами:

После чего нам написал представитель сети американских дата-центров CoreSite, где располагался наш узел фильтрации трафика. Суть обращения проста для продолжения работы с датацентром в ЛосАнджелесе нам было необходимо перестать обслуживать домены, определенным образом связанные с ХАМАС.

Мы предполагаем, что некое третье лицо (заказчик сервиса) воспользовалось нашим бесплатным сервисом для подключения доменов, так или иначе связанных с ХАМАС.

Это лицо может быть одновременно и владельцем и администратором сайта, а может быть и сторонним заказчиком. Эти данные скрыты. Причем установить связь заказчика сервиса с указанным доменом невозможно - для этого потребовалось бы чуть ли не собственная разведывательная служба.

7 января 2021 года нас ошарашило очередное письмо от CoreSite. Американская сторона решила в одностороннем порядке завершить с нами сотрудничество. Партнеры обуславливали решение тем, что мы водили их вокруг пальца и не прекратили обслуживать доменные имена, связанным с ХАМАС. Только через пару дней в сети мы обнаружили причину расторжения контракта с CoreSite исследование Брайана Кребса, опубликованное 5 января.

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

Среди них печально известный имиджборд 8chan и портал, посвященный популярной теории заговора QAnon. Особое внимание приковано к 8chan, ведь, по данным Кребса, сторонники Дональда Трампа обсуждали там организацию разгрома Капитолия, произошедшую 6 января 2021. Вскоре и с VanwaTech было прекращено сотрудничество, о чем в статье рассказали журналисты The Guardian.

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

После того, как ситуация приобрела мировой масштаб, на нас обрушился шквал запросов СМИ со всех краев земного шара: журналистам было интересно, есть ли в этой истории пресловутый русский след, и как в этом замешана наша компания.

На этом чудеса, как говорится, не закончились. История, которая получила еще бОльшую огласку, случилась с нами на пару со скандальной социальной сетью Parler.com. О нашей связи с ними, кстати, тоже писал Кребс, но уже заранее запросив наш комментарий.

Часть истории о нас и Parler вы могли читать в постах @alizar http://personeltest.ru/aways/habr.com/ru/news/t/538004/ и @AnnieBronson http://personeltest.ru/aways/habr.com/ru/news/t/538728/.

Журналисты Reuters усмотрели наш IP-адрес в А-записях Parler, тут же решив, что мы предоставляем социальной сети услуги хостинга. Коллеги связали это с фактом расторжения сотрудничества Parler с хостингом Amazon, а также с удалением социальной сети из магазинов приложений Google и Apple.

Мы снова начали отстаивать правду перед всем миром, но уже не только перед журналистами, но и перед экспертами и рядовыми читателями. Об этом, кажется, не слышал только глухой. Федеральные СМИ, профильные YouTube-каналы и даже Редакция Пивоварова все эти средства коммуникаций так или иначе обозначали нашу компанию как фигуранта этого неоднозначного дела. Мы сказали мировому сообществу, что мы услуг хостинга Parler не предоставляем, а лишь защищаем сайт от DDoS-атак это наша первоочередная задача.

Собственно, хостинг

В связи с тем, что многие не понимают, как работает закон в отношении хостера, мы попытаемся приоткрыть завесу тайны. Хотя, не такая уж это и тайна.

Юридическая сторона вопроса. Section 230 крик души сетевого нейтралитета

Начнем с сетевого нейтралитета. Его суть здорово описана законодателями из Соединенных Штатов в так называемой Section 230. В переводе на русский язык нормативный акт звучит примерно так:

Ни провайдер, ни пользователь интерактивного компьютерного сервиса не считаются издателем или носителем какой-либо информации, предоставленной другим провайдером информационного контента.

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

По словам экспертов, закон не делает хостеров нейтральными, наоборот, Section 230 приспосабливает их к современным интернет-реалиям. Специалисты считают, что закон подтолкнул хостеров выстраивать собственные отношения с клиентами и внедрять модерацию контента.

Хостер и право. Россия

Отечественное законодательство относится к хостерам, владельцам сайтов и судопроизводству по этим вопросам несколько иначе.

ФЗ N 149 Об информации, информационных технологиях и о защите информации - этот закон регулирует права на поиск, передачу, распространение, производство и защиту информации.

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

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

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

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

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

1 февраля 2021 года вступил в силу закон, согласно которому социальные сети должны самостоятельно выявлять и блокировать запрещенный контент.

Однако, нужно обратить внимание, что данный закон применим к социальным сетям, в которых имеются российские пользователи, численность которых должна соответствовать установленным законом пределам, а также находится в перечне специального реестра Роскомнадзора. На текущий момент, тот же Parler, как американская социальная сеть под эти требования не попадает.

Интересно будет вспомнить материал РБК, написанный спустя год после появления на свет закона о безопасности информационной инфраструктуры России (ФЗ N 187). За 12 месяцев существования правового акта, судебные иски подавали исключительно к хостерам, а ответчики лишь трижды явились на слушания по делам.

А что Amazon?

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

Преподаватель Гарвардского юридического факультета Эвелин Доук ожидает, что между сайтами и хостерами разгорятся новые конфликты изза высказываний в интернете.

Она считает, что социальная сеть неподходящее место для модерации контента. Также Доук упомянула, что компания Amazon приводит 98 материалов спорного содержания в судебных документах по делу о Parler.

Это меня даже слегка рассмешило, сказала она в интервью американскому изданию WRVO. Amazon вообще выходит в интернет? 98 материалов или около того не так уж и много. Я имею в виду, в Amazon вообще видели, что размещается на Amazon?

Иными словами, эксперт не видит логики в действиях Amazon, однако существует и другая сторона вопроса. Может ли тот же Amazon будучи хостером отслеживать все, что происходит на сайтах клиентов? Мониторинг незаконных клиентов займет столько пар рук и зарплат, сколько не может позволить себе даже такой гигант, как Amazon. Не говоря уже о провайдерах, обслуживающих сайты за 500 рублей в месяц.

Что делать, если к тебе пришли за объяснениями?

От подобных ситуаций не застрахован ни один провайдер. Поэтому мы собрали ряд советов, которые сделают проще жизнь коллег:

Отнеситесь внимательно к сообщениям, которые приходят на ваш официальный (юридический) почтовый адрес. Это могут быть абьюзы, просьбы, различные решения компетентных органов, либо поддельные документы, не имеющие под собой оснований.

Осуществляйте внимательную фильтрацию этих запросов на предмет их правомерности. Если имеются сомнения в подлинности документов или их достаточности, или полномочий того или иного лица или государственного органа предоставляйте соответствующий ответ. Если у вас есть специальный человек на эти задачи прекрасно, если нет штурмуйте hh.ru.
Действуйте по принципу сетевого нейтралитета и следуйте по пути закона стран пребывания вашей компании;
Будьте лояльны, не рубите с плеча. Если на клиента поступила жалоба или решение ведомства, не спешите его отключать. Проведите беседу, выясните причины проблемы и попросите ее решить в установленный срок;
Теперь про обращения СМИ:

Если вдруг у вас нет отдельной почты для обращений СМИ заведите ее. Не помешает;

Наша PR-служба советует не прятаться от СМИ и давать развернутые и честные комментарии. Если вы не отвечаете на запросы журналистов, вы попросту рискуете прослыть негодяем не только для них, но и для общественности;

Имейте за пазухой подробный пресс-релиз произошедшего в виде официального документа. Опубликуйте его на сайте, если есть возможность. Это поможет вам тратить меньше времени на ответы СМИ. В зависимости от течения истории, документ можно всегда отредактировать;

Анализируйте каждое слово, сказанное вами в инфополе, ведь это поле минное;
Ознакомьтесь с аналогичными ситуациями, в которых побывали ваши коллеги по цеху. Не стесняйтесь интересоваться у них, какой был план действий, как это отразилось в СМИ, и какие репутационные и финансовые риски понесли эти компании в результате своих действий;
Проработайте план Б по работе с клиентами. А вдруг и вас нежданно-негаданно попросят освободить стойку в дата-центре?

Finita la commedia

Мы считаем, что суд над контентом клиентов это не задача хостера. Вот причины:

Клиент может предоставить хостеру нерелевантные данные при регистрации имена, номера телефонов и почтовые адреса;

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

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

И нам кажется, что на этом наша история еще не окончена.

А теперь примите участие в нашем опросе и выразите свое мнение о том, должен ли хостер или провайдер быть членом жюри в этом безграничном пространстве контента. Обсудим вместе!