Атаки Direct-to-Origin: игра в обход

Атаки Direct-to-Origin: игра в обход

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

 

 

 

 

1. Атака Direct to Origin?

2. Способы определения исходного IP-адреса

2.1. История IP-адреса

2.2. Дополнительные домены в другой зоне

2.3. Поддомены

2.4. DNS-записи

2.5. Временное разоблачение

2.6. SSL-сертификаты

2.7. Чувствительные файлы

2.8. IP-адрес в содержимом ресурса

2.9. Исходящие соединения

3. Защита от раскрытия IP-адреса

 

 

Развитие интернета вещей и стабильный прирост слабо защищенных сетевых устройств отрицательно влияет на безопасность глобальной сети. Одной из самых разрушительных и в то же время простой в исполнении и дешевой угрозой для веб-сайта является атака отказа в обслуживании (DDoS). Примером этому служит ноябрьская волна атак на топ-10 российских банков: «Альфа-Банк», «Банк Москвы», «Росбанк» и «Сбербанк».

По данным компании Imperva Incapsula, с начала 2015 года до начала 2016 года количество DDoS-атак на клиентов сервиса выросло на 94% на прикладном уровне и на 141% на сетевом. Стоит отметить, что любая on-premise система защиты становится бесполезна, когда огромный объем входящего трафика превышает производительность активного оборудования интернет-провайдера или полностью заполняет полосу пропускания канала связи. Недавние события, связанные с DDoS-атаками на блог известного журналиста Брайана Кребса и DNS-сервис Dyn.com, превысившими 600 Гбит/с и 1 Тбит/с соответственно и вызвавшими сильные перебои в работе этих ресурсов, наглядно это демонстрируют. Конечно, можно запросить увеличение пропускной способности, но часто ресурсы провайдера ограничены, либо это вовсе невозможно из-за ограничений, накладываемых физическим каналом связи. Более того, когда один клиент интернет-провайдера находится под DDoS-атакой, из-за перегрузки канала и сбоев оборудования могут пострадать и другие клиенты. Дело доходит даже до того, что провайдер может полностью отключить веб-сайт клиента, находящегося под атакой. Поэтому вполне логичным решением данной проблемы может стать подключение специализированного облачного поставщика услуг безопасности (Cloud-based Security Provider — CBSP). CBSP маршрутизирует весь трафик до защищаемого ресурса через свои прокси-сервера, очищая его от паразитного и подозрительного трафика. Некоторые CBSP дополнительно предоставляют услуги межсетевого экрана защиты приложений (Web Application Firewall — WAF), таким образом обеспечивая защиту не только от DDoS, но и от других векторов атаки.

Выходит, подключаясь к CBSP, получаем иммунитет к DDoS, SQL-инъекциям, XSS-атакам, сканирующим ботам и можем спать спокойно? Нет.

 

Атака Direct to Origin?

Злоумышленники не стоят на месте и для осуществления атаки на ресурс применяют способы обхода защиты CBSP. Это гораздо проще, чем пытаться прорваться сквозь стену анализаторов и фильтров вредоносного трафика. В большинстве случаев, CBSP обеспечивает безопасность путем сокрытия исходного IP-адреса защищаемой системы за доменным именем и направлением всех данных через свои прокси-сервера. Тем не менее, если злоумышленник сумеет определить сокрытый IP-адрес ресурса, то это даст ему возможность полностью обойти защиту CBSP и атаковать непосредственно саму систему. Ситуация усугубляется еще и тем, что администраторам защищаемого ресурса в большинстве случаев не известно, произошло ли уже раскрытие IP-адреса и насколько их система уязвима к атаке на данный момент. По данным, собранным различными исследователями, от 30% до 98% веб-сайтов (в зависимости от используемого CBSP), входящих в рейтинг Alexa TOP 1 million, раскрывают IP-адрес сервера как минимум одним способом. В этой статье мы рассмотрим способы обнаружения исходного IP-адреса системы злоумышленником и меры по защите от них.

 

Способы определения исходного IP-адреса

История IP-адреса

 

Рисунок 1. История изменений IP-адреса домена доступна каждому

История изменений IP-адреса домена доступна каждому

 

Для подключения защиты своего ресурса к CBSP необходимо внести изменения в DNS-записи веб-приложения (A, CNAME или NS), после чего доменное имя начнет возвращать IP-адрес CBSP вместо исходного IP-адреса защищаемой системы. Однако если такой ресурс продолжает использовать свой прежний IP-адрес, злоумышленник может найти его в базах данных истории доменных имен. Некоторые компании специализируются на ведении истории конфигурации DNS доменных имен в целях маркетинга, иногда предоставляя доступ к этим данным всем желающим. Кроме того, злоумышленники довольно часто выбирают ресурс свой целью задолго до начала использования им защиты и, таким образом, изначально обладают информацией об IP-адресе жертвы.

Дополнительные домены в другой зоне

Часто бывает так, что у компании есть несколько доменов для разных стран, например для России в зоне .ru и международный в зоне .com. И часто они ссылаются на один и тот же веб-сервер, для экономии ресурсов и облегчения работы администраторам сайта. При этом, когда заходит речь о защите домена, к CBSP могут подключить только один или несколько, оставив малопосещаемые без защиты, в целях экономии средств. Этим и может воспользоваться злоумышленник, вычислив IP-адрес исходного сервера.

Поддомены

 

Рисунок 2. Поддомены, которые чаще всего позволяют раскрыть IP-адрес

Поддомены, которые чаще всего позволяют раскрыть IP-адрес 

 

Для корректной работы с трафиком CBSP используют информацию о домене из заголовков HTTP-запросов. На этом этапе возникают сложности при работе с некоторыми другими протоколами, например FTP или SSH, которые не передают информацию о домене назначения. Есть два способа решения этой проблемы: во-первых, можно напрямую указывать IP-адрес при работе с такими протоколами. Такой способ менее универсален и, как следствие, не удобен. Во-вторых, можно использовать поддомены вида ftp.example.com, которые ссылаются на исходный IP-адрес ресурса. Данный способ более удобен, но он оставляет злоумышленнику шанс узнать сокрытый IP-адрес. Хотя поддомены напрямую не видны при запросах к DNS-записям основного доменного имени, злоумышленник может воспользоваться атакой с перебором по словарю популярных имен поддоменов и найти используемые, а с ними и IP-адрес ресурса.

DNS-записи

После организации процесса защиты A-запись DNS-ресурса начинает ссылаться на IP-адрес CBSP. Но в других DNS-записях могут остаться следы исходного IP-адреса. Например, для работы протокола SMTP в условиях защиты требуется установление прямого соединения с почтовым сервером. Для этого предусмотрено наличие ссылающейся на исходный IP-адрес MX-записи в DNS, которая и может быть обнаружена злоумышленником. Сюда же относится указание IP-адреса в TXT-записи при использовании механизма Sender Policy Framework (SPF). Механизм SPF используется для борьбы с подделкой электронных писем путем сравнения IP-адреса отправителя со списком одобренных адресов. Наконец, если ресурс доступен по протоколу IPv6, а CBSP не предоставляет инструкций для смены AAAA-записи, то ресурс подвергается риску прямой атаки через его IPv6-адрес.

Временное разоблачение

Для проведения технического обслуживания веб-серверов или отладки приложений администраторы ресурса могут временно приостановить защиту ресурса у CBSP, таким образом какое-то время его доменное имя будет ссылаться на исходный IP-адрес. Злоумышленник, который тщательно следит за ресурсом, может заметить изменение в DNS и узнать его исходный IP-адрес. В результате последующее возобновление использования защиты от CBSP уже никак не спасет от атаки. Чем больше времени ресурс находится без защиты, тем больше вероятность раскрытия его исходного IP-адреса.

SSL-сертификаты

 

Рисунок 3. Определение IP-адреса жертвы при помощи SSL-сертификата 

 

Если администрация ресурса хочет продолжать использовать HTTPS находясь под защитой CBSP, у них есть два пути: позволить CBSP выпустить сертификат для их домена, либо передать приватный ключ от своего собственного. Эти действия позволяют обеспечить защищенное соединение между пользователями ресурса и CBSP. Также защищаемый ресурс может использовать собственный SSL-сертификат для защиты соединения между собой и CBSP. Но проблема в том, что SSL-сертификат содержит доменное имя ресурса и, при сканировании злоумышленником диапазона IP-адресов и получении их SSL-сертификатов, может выдать его соответствие IP-адресу определенного доменного имени. На сегодняшний день имеется возможность произвести сканирование всего пространства адресов IPv4 по выбранному порту менее чем за один час.

Чувствительные файлы

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

IP-адрес в содержимом ресурса

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

Исходящие соединения

Несмотря на то, что все входящие соединения веб-сервера перенаправляются через инфраструктуру CBSP, исходящие соединения устанавливаются сервером напрямую с клиентом, таким образом раскрывая ему свой IP-адрес. Злоумышленник может попытаться заставить сервер соединиться с ним, например, путем загрузки файла на сервер через URL или используя механизмы проверки внешнего содержимого типа PingBack.

 

Защита от раскрытия IP-адреса

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

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

При использовании поддоменов нужно выбирать для них нестандартные имена, которые сложнее угадать перебором или по словарю (например, getmail5 вместо mail). Но полноценную защиту в такой ситуации может дать только настройка перенаправления трафика сразу на нужный порт со стороны CBSP, если защищаемый ресурс имеет уникальный IP-адрес, либо полный отказ от использования поддоменов.

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

Сразу после начала защиты ресурса с помощью CBSP и смены необходимых DNS-записей следует убедиться, что в DNS не осталось указаний на предыдущий IP-адрес. Если необходимо использовать MX-запись или механизм SPF, рекомендуется заранее перенести почтовый сервер на отдельный выделенный IP-адрес. Также в случае проведения технических работ и временного отключения защиты следует задуматься о профилактической смене IP-адреса ресурса.

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

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

 

Источник: Protosecurity

 

Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru