- безопасность
Количество DDoS-атак в России за 2023 год, по данным StormWall, выросло на 29%. При этом на 46% увеличилось число поддельных доменов, которые мошенники успешно используют для фишинга. Об этом сообщают эксперты F.A.C.C.T.
Оба факта говорят об одном: преступники активнее интересуются российскими веб-ресурсами. Вместе с тем бизнес все чаще стремится усилить свою защиту от возможных атак.
Как выстроить процесс эффективно? Какие меры, инструменты и ресурсы нужны для комплексной защиты сайтов и мобильных приложений? Опытом и рекомендациями делимся в этой и следующей статьях в нашем блоге.
Сегодня обсудим:
- с чего начать работы по защите веб-приложений и причем здесь OSINT,
- как быстро провести анализ инфраструктуры и уязвимостей, какие бесплатные и коммерческие инструменты в этом могут помочь.
План в три шага
К веб-приложениям уже давно относятся не только сайты, но и онлайн-сервисы и мобильные приложения. Проще говоря, речь идет обо всех продуктах компании, с которыми пользователи могут взаимодействовать в Сети.
Чем выше отказоустойчивость веб-приложений и меньше ошибок в их работе, тем ниже возможные финансовые и репутационные потери бизнеса. Аксиома подтверждается множеством успешных хакерских атак. В их числе инциденты с сайтами Сбербанка, РЖД и других крупнейших компаний России.
Но торопиться с подключением решений для безопасности веб-приложений — не лучшая идея. Эксперты рекомендуют сначала тщательно изучить свою инфраструктуру и оценить приоритетные риски, и только потом подбирать меры и средства защиты.
Шаг 1. Разведка на месте
На первом этапе важно определить площадь возможных хакерских атак, а точнее — провести аудит веб-инфраструктуры. Задача масштабная и выглядит как слон, которого проще всего есть по кусочкам.
Разделим работы на шесть блоков. В каждом рассмотрим OSINT-инструменты, которые помогут быстро и удобно собрать всю необходимую информацию.
Составляем карту доменов
Все веб-приложения привязаны к адресам в Сети. Вот почему для начала стоит выяснить, какие домены и поддомены есть в компании, а также для чего именно они используются.
В итоге получится карта доменов компании. Чтобы сэкономить время при поиске веб-адресов, можно воспользоваться специализированными инструментами. Самые известные: DNSdumpster и Amass. Также есть более современный сервис с ML под капотом — SubGPT.
Изучаем историю DNS
Работаем в двух направлениях: исследуем DNS-записи и анализируем контент на домене. Начнем с первого.
Какие IP-адреса были записаны нашим DNS и в какое время — это важная информация. И это подтверждает реальный кейс одного из наших клиентов.
История из практики
Клиент попросил помочь инженеров Nubes с защитой инфраструктуры от DDoS-атак, после чего решил установить специализированное решение — Web Aplication Firewall (WAF).
Обычно инсталляция проходит быстро. В качестве DNS-записи прописывается upstream защиты от DDoS (L7). На его стороне блокируются все входящие подключения с IP-адресами, кроме antiDDoS-сервиса.
В какой-то момент началась атака, и веб-ресурсы компании стали недоступными. При расследовании инцидента выяснилось, что клиент не закрыл доступы в обход DDoS. Злоумышленник нашел старые DNS-записи компании и увидел, что upstream отвечает по постоянному незащищенному IP-адресу. В итоге он просто провел атаку напрямую.
Чтобы не повторить историю этой компании, рекомендуем проверить старые публикации DNS-записей. Например, с помощью сервиса DNS History.
А еще можно подключить инструмент wayback.machine. С его помощью можно увидеть, какие страницы были проиндексированы на протяжении указанного времени. Такие данные особенно полезны, если компания начинает работать с новым доменом или только покупает его. Инструмент позволяет выяснить, какая до этого момента была бизнес-логика в веб-приложении.
Проверяем на спам и malware
Изучаем открытые базы с доменами и IP-адресами, которые засветились в преступных схемах. Можно начать с DNSBL-списков и блэклистов, сформированных по жалобам пользователей и систем.
Часто такую информацию ищут на ресурсе SpamHaus. Если домен попал в его спам-список, то письма с его адресов вряд ли дойдут до адресата: они будут автоматически блокироваться второй стороной. То же самое касается сайтов: за пределами защищенного периметра компании они станут недоступными.
Чтобы проверить домен на присутствие в вирусных базах, можно воспользоваться VirusTotal и его аналогами.
Ищем двойников
Поддельные домены не относятся напрямую к защите веб-инфраструктуры компании. Однако их наличие — угроза для клиентов, которые могут пострадать от фишинга, а это риск для репутации компании.
Для поиска доменов-двойников обычно используют DNStwister, IDN-checker и другие похожие сервисы. Они помогают быстро сгенерировать похожие зарегистрированные домены. Иногда схожие ресурсы оказываются площадками, которые мимикрируют под веб-приложения компании. С их помощью мошенники проводят атаки на потенциальных и реальных клиентов компании-жертвы.
Анализируем код
Пункт важен для компаний, которые самостоятельно разрабатывают веб-приложения под свои нужды. В этом случае рекомендуем проверять все репозитории и код, особенно если они находятся в открытом доступе.
Главное здесь — не пропустить конфиденциальную информацию. К сожалению, человеческий фактор часто приводит к тому, что разработчики оставляют в коде данные для обхода защиты, в том числе API-ключи и пароли от учетных записей.
Чтобы минимизировать риски, стоит ввести регулярную проверку кода и репозиториев. Такую возможность, в частности, предоставляют встроенные сервисы в GIT. Также с этой целью можно использовать Google dorking. Метод позволяет искать информацию на Github с помощью различных ключей.
Следим за TLS-сертификатами
Несанкционированные TLS-сертификаты, полученные в обход компании-жертвы, часто используют в MITM («человек посередине») и других атаках. Поэтому всегда важно держать их выпуск под контролем.
Если в компании выстроены процессы по работе с TLS-сертификатами, то обнаружить угрозу всегда проще. Так можно быстрее обнаружить активность злоумышленника, провести расследование и выяснить, почему произошел инцидент. Обычно причиной становится компрометация инфраструктуры или домена. В любом случае выпуск TLS-сертификата на стороне — весомый повод для его отзыва.
Шаг 2. Оцениваем риски и ищем уязвимости
Теперь можно переходить к следующему этапу — поиску проблем в инфраструктуре.
Рекомендуем начать с приоритизации веб-приложений. Зачастую ресурсы ИБ-инженеров и ИТ-специалистов ограничены. Именно поэтому лучше сфокусироваться на объектах инфраструктуры, которые особенно критичны для бизнеса.
Здесь нужно определить, атаки на какие веб-приложения могут принести больше потерь для бизнеса. В расчет берутся все риски: от финансовых до репутационных.
Также бывают случаи, когда приложение выглядит совершенно некритичным по бизнес-логике, однако оно располагается в защищенном периметре или влияет на работу важнейших сервисов. Этот нюанс тоже стоит иметь в виду.
Затем можно приступать к поиску известных уязвимостей (CVE) и других проблем. Решать задачу рекомендуем с помощью популярных IoT-поисковиков Shodan и Censys. По итогу такого расследования будет понятно, какие службы, IP-адреса и другие моменты в работе веб-приложений могут нести в себе риски для бизнеса.
Далее сканируем инфраструктуру. С этой задачей справляется множество как коммерческих, так и бесплатных решений. К самым популярным opensource-инструментам относятся nmap, OpenVAS. Также есть Nebula со встроенными AI-механизмами. В сервисе можно создавать команды на естественном языке, что заметно упрощает поиск уязвимостей для тех, кто незнаком с языками запросов. Примеры платных решений: Vulners, XSpider, Сканер-BC, MaxPatrol.
Идеальный сценарий — сразу найти уязвимости на всех уровнях. В том числе по угрозам DDoS-атак L7. Для этого подключаем DAST (Dynamic Application Security Testing) — динамическое сканирование безопасности приложений. И здесь на помощь приходят такие бесплатные решения, как ZAP от OWASP, Nuclei, Nikto, DirBaster и уже названный фреймворк Nebula (AI). Среди коммерческих инструментов особенной популярностью пользуется Burp Suite.
Если же компания сама разрабатывает ПО, то будет нелишним провести SAST (Static Application Security Testing) — сканирование кода приложений на безопасность. Выбор утилит и фреймворков для решения этой задачи огромный, причем многие из них поставляются бесплатно. Это как привычные для многих GitHub Advanced Security и OWASP ASST, так и более узкие инструменты, которые специально создаются под разные языки программирования.
Что дальше?
Итак, мы составили карту доменов компании, провели аудит веб-приложений, оценили их критичность для бизнеса. Более того, теперь знаем о рисках всех важных для бизнеса продуктов.
Теперь можно переходить к самой ответственной задаче — выстраиванию безопасности веб-приложений. Что необходимо учесть на этом этапе и какие средства защиты нужно подключить, читайте в следующей статье.