Бытует мнение, что для взлома финансовых организаций злоумышленники используют все более сложные техники, включая самые современные вирусы, эксплойты из арсенала спецслужб и хорошо таргетированный фишинг. На самом деле, анализируя защищенность информационных систем, мы видим, что подготовить целенаправленную атаку на банк можно с помощью бесплатных общедоступных средств, без применения активного воздействия, то есть незаметно для атакуемых. В данной статье мы рассмотрим подобные хакерские техники, построенные в основном на излишней открытости сетевых сервисов, а также представим рекомендации по защите от таких атак
Шаг 1. Определение целей
В офлайновом мире бывает нелегко выяснить, какие сервисы и сети принадлежат конкретной организации. Однако в интернете существует множество специальных инструментов, позволяющих без особого труда определить сети, подконтрольные интересующим нас компаниям. Для пассивной разведки в рамках сбора статистики по сетевым периметрам финансовых организаций мы использовали:
В данном исследовании не рассматривались такие методы, как активное сканирование, определение версий межсетевого экрана и наличия IPS, определение используемых антивирусов и других средств защиты, а также социальная инженерия. Несколько техник, которые нередко используют хакеры:
Всю эту информацию можно получить и через Unix команду whois. Что использовать — дело вкуса.
Используя собранную информацию об организациях, мы осуществили поиск их адресных диапазонов в базе данных регистратора RIPE, выбирали исключительно российский сетевой сегмент.
Этот этап работ требует большого количества ручного труда, ведь адреса могут быть отданы партнеру, сданы в аренду или не принадлежать искомой организации. Для повышения точности результатов нам пришлось провести дополнительные проверки. Для верификации сетей мы использовали общедоступный онлайн-сервис американского оператора связи Hurricane Electriс, который по IP-адресу сайта может выдать информацию о сети, в которой он располагается. На этом этапе оказался также очень полезен сервис Robtex. Он показывает все связи для указанного доменного имени, это позволило нам найти сети, которые не удалось обнаружить при поиске в базе Ripe. Кроме того, Robtex позволяет увидеть другие сайты, расположенные по данному IP-адресу.
Определение нужных сетей хуже всего автоматизируется, сбор информации о сетях финансового сектора занял у нас два дня. После завершения этого этапа мы получили список вида «организации — сети»
Шаг 2. Выявление доступных сервисов
Для этого можно использовать один из двух наиболее известных инструментов, призванных сделать интернет безопаснее: Shodan или Censys. Они имеют схожие возможности, поддерживают работу с API, а также могут дополнять друг друга. Для полноценного поиска оба сервиса требуют регистрации. Censys более требователен: чтобы снять в нем ограничения на выдачу результатов поиска, придется написать разработчикам, убедить их в этичности исследования и ответственном использовании полученных данных. Аргументом при этом будет сертификат CEH или подробная информация об исследовании.
Мы использовали сервис Shodan, для нас он более привычен и удобен. Процесс автоматизации описан, включая примеры кода на Python, создателем Shodan Джоном Матерли (John Matherly), также известным как @achillean, в весьма удобной форме6 . Более того, есть репозиторий на GitHub7 , где можно познакомиться с официальной библиотекой Shodan для Python.
Пример запроса через веб-интерфейс выглядит вот так:
На примере видно, что на адресе 8.8.8.8 доступен UDP-порт 53, сервис DNS, находящийся в США и принадлежащий Google, а также видна версия операционной системы, используемая на этом IP-адресе. Запросами к Shodan можно выявить гораздо более специфичные сервисы, к которым забывают ограничить доступ из интернета, хотя это следовало бы сделать. Поскольку можно получить различные баннеры и версии этих сервисов, то можно и сопоставить полученные данные с различными базами уязвимостей.
Нам нужно прогнать через Shodan каждый обнаруженный IP-адрес, а их мы собрали около 100 000 — многовато для ручной проверки… Мы написали собственный сборщик информации. Запустили — и спустя неделю работы программы получили картину распределения доступных сервисов в финансовом секторе, абсолютно никак не взаимодействуя с ними! Отслеживать таким способом изменения в инфраструктурах вполне реально. И вот что мы нашли...
Из самого ужасного на периметрах финансовых организаций найдены:
Полученные результаты нас не удивили: чем больше организация, тем больше сервисов размещено на ее сетевом периметре, а с ростом числа сервисов увеличивается вероятность ошибки конфигурации.
Шаг 3. Определение уязвимых сервисов
После нахождения доступных сервисов можно определить степень их защищенности. Уязвимы ли они? Какие уязвимости в них есть? Необходимо проанализировать признаковое пространство, которое отдает Shodan по каждому отдельному узлу. Эта информация имеет следующий вид:
Из всего признакового пространства были выделены поля, по которым может быть найдена информация об уязвимости данного узла. Для этого отлично может подойти связка Product + Product_version либо CPE. В нашем случае мы решили воспользоваться связкой Product + Product_version, а поиск осуществлялся по внутренней базе уязвимостей Positive Technologies.
В сети существует немалое количество общедоступных источников для поиска уязвимостей, вот некоторые из них:
Мы написали простенький скрипт, который довольно быстро обработал все полученные данные по сервисам, сопоставили их с нашей базой уязвимостей (то же самое легко делается и через названные сервисы) и получили следующую статистику распределения уязвимостей по сервисам:
Результаты получились следующие: из общего количества сервисов, найденных Shodan, уязвимости были обнаружены в 5%. Эта цифра мала: для сравнения, по данным наших собственных автоматизированных сканирований периметров, обычно уязвимости встречаются в 20–50% сервисов. Но теоретически процент обнаружения уязвимостей можно увеличить. К примеру, для ROSSSH можно предположить доступность уязвимости ROSSSH Remote Preauth Heap Corruption11. Несмотря на то что уязвимость не новая, вероятность встретить ее в этом сервисе значительно выше нуля. В своих предыдущих исследованиях12 мы говорили, что порядка 30% систем, доступных из интернета, содержат уязвимости старше 5 лет. Похожие цифры в своих исследованиях приводит Cisco13, по данным которой средний срок присутствия известных уязвимостей составляет пять с половиной лет. Эти результаты сопоставимы с нашими, а небольшое отличие обусловлено разными выборками и методами исследований. Схожий метод можно применить и к RDP.
Шаг 4. Поиск эксплойтов
Следующим шагом является поиск эксплойтов для определенных уязвимостей. Воспользуемся поисковиками, описанными выше, или специальными утилитами. Существует свободно распространяемая утилита PTEE14. А еще существует Metasploit, который хоть ничего и не собирает, но…
В нашей компании есть собственная база знаний, где уязвимости уже сопоставлены с эксплойтами. Вот результаты сопоставления:
Это просто объяснить: с ростом инфраструктуры следить за ней все сложнее. Больше узлов — больше старого софта и больше уязвимостей. В крупных компаниях периметр крайне динамичный, мы показывали это в своих предыдущих исследованиях15.
Сколько времени займет поиск уязвимых сервисов, если информация об уязвимости только что появилась на просторах интернета? В нашей системе поиск по заданным уязвимостям занимает менее секунды. Больше времени уходит на анализ полученных результатов, но это тоже довольно быстро: в рамках этого исследования анализ по одной уязвимости занимал не более 15 минут.
Шаг 5. Собственно атака
После обработки информации, полученной на предыдущих шагах, злоумышленник проводит атаку на уязвимые системы с помощью доступных инструментов.
В нашем исследовании не проводились реальные атаки. Но оценить возможности хакеров мы способны. Рассмотрим для примера последнюю часть известного эксплойт-пака, слитого группой The Shadow Brokers. В этом паке присутствовало множество интересных эксплойтов, к примеру набор для взлома SMB, ставший общеизвестным после вирусной эпидемии WannaCry16. В нашей выборке этот эксплойт подошел для 36 систем (данные об исследуемом периметре были собраны до публикации архива с эксплойтами). На тот момент содержащиеся в паке эксплойты были применимы ко всем версиям Windows. Следовательно, их с большой вероятностью можно было взломать. Это и показал WannaCry, но это только вершина айсберга, в паке были и другие интересные эксплойты:
В начале исследования уровень опасности нам казался ниже полученного, но потом пришел WannaCry и не согласился с нами. Причиной высокого уровня опасности стал недостаточный контроль внешнего периметра в организациях. При этом даже после публикации предупреждений и рекомендаций экспертов не произошло значительного повышения уровня защищенности.
Выводы и рекомендации по защите
Подведем итоги. Если использовать обычный сетевой сканер, который ищет уязвимости, у организации могут возникнуть подозрения, что их кто-то «смотрит». Факты сканирований легко выявить и блокировать. Но кто будет отслеживать работу массового поисковика? В этой статье мы продемонстрировали, что:
1) для подготовки целенаправленной атаки на финансовый сектор не требуется особых затрат;
2) подготовка может быть незаметной для атакуемых организаций и для тех, кто их защищает;
3) для реализации атаки необязательно обладать эксплойт-паком от АНБ, хотя и его компоненты тоже попадают в открытый доступ.
Безопасность периметра — один из базовых векторов защиты. Но защищать, не зная, что именно защищаешь, — занятие сложное и бессмысленное. Если вы не знаете границы защищаемого вами периметра, вы можете воспользоваться методами анализа сетей, описанными в этой статье.
Получив представление о том, из чего состоит периметр, займемся его защитой. Достижение максимально безопасных конфигураций информационных систем — трудная задача. Информационная безопасность всегда балансирует между функциональностью системы и ее защищенностью. Ошибки конфигурации присутствуют и в сетевых периметрах: как показывает наше исследование, в интернет выставляется много лишних, в том числе уязвимых, сервисов, что облегчает злоумышленнику возможность проникновения в сеть организации.
Рекомендуемый план по защите периметра может выглядеть следующим образом:
1. Определить те активы, доступ к которым из интернета обоснован.
2. Сервисы без обоснования доступа вывести с периметра.
3. Документировать и внедрить процедуру размещения новых систем на внешнем периметре.
4. Составить ACL, ограничивать доступ к административным интерфейсам, сервисам удаленного доступа, БД и другим важным сервисам минимально возможным списком лиц.
5. Ввести процедуру установки обновлений и определить метрики успешности ее выполнения.
6. Проводить работы по анализу защищенности, такие как пентест и аудит.
7. Определить список лиц, ответственных за активы (как со стороны бизнеса, так и со стороны IT). Это позволит снизить трудозатраты и время реакции при срочном обновлении систем.
8. Для приоритизации устранения уязвимостей — определить значимость активов.
9. Составить план реакции на случай обнаружения критически опасных уязвимостей в системах, расположенных на периметре
Конечно же, следует помнить, что для противодействия угрозам необходим комплексный подход к обеспечению ИБ, а начинать стоит со своих сетевых границ.
Ссылки
1 bgp.he.net
2 apps.db.ripe.net/db-web-ui/#/fulltextsearch
3 robtex.com
4 dnsdumpster.com
5 github.com
6 goo.gl/HpZFyw (media.readthedocs.org)
7 github.com/achillean/shodan-python
8 securitylab.ru/news/410610.php
9 securitylab.ru/news/483790.php
10 cpe.mitre.org
11 securitylab.ru/poc/444271.php
12 habrahabr.ru/company/pt/blog/309072/
13 goo.gl/PYwCwy (cisco.com)
14 habrahabr.ru/company/pt/blog/245885/
15 goo.gl/uvF9VH (ptsecurity.com)
16 goo.gl/Qnin5B (ptsecurity.com)
Источник: ptsecurity.com
Шаг 1. Определение целей
В офлайновом мире бывает нелегко выяснить, какие сервисы и сети принадлежат конкретной организации. Однако в интернете существует множество специальных инструментов, позволяющих без особого труда определить сети, подконтрольные интересующим нас компаниям. Для пассивной разведки в рамках сбора статистики по сетевым периметрам финансовых организаций мы использовали:
- Поисковые системы (Google, «Яндекс», Shodan).
- Отраслевые сайты финансового сектора — banki.ru, rbc.ru
- Whois-сервисы 2ip.ru, nic.ru
- Поисковые системы по базам данных интернет-регистраторов — Hurricane Electric BGP Toolkit1 , RIPE2 .
- Сервис визуализации данных по доменному имени сайта — Robtex3
- Сервисы для анализа доменных зон dnsdumpster4 , domaintools.com.
В данном исследовании не рассматривались такие методы, как активное сканирование, определение версий межсетевого экрана и наличия IPS, определение используемых антивирусов и других средств защиты, а также социальная инженерия. Несколько техник, которые нередко используют хакеры:
- Поиск проектов на GitHub5 . Часто бывает, что на GitHub выложен тестовый проект, бэкап или рабочий код, доступ к которому забывают ограничить или неправильно ограничивают. Исследование таких проектов требует высокой квалификации, но дает практически 100%-ный шанс проникнуть в сеть, используя ошибки исследованного приложения или вшитые учетные данные.
- Сервисы онлайн-проверок на уязвимости, такие как HeartBleed, Poodle, DROWN, ROBOT. Эти сервисы с высокой степенью вероятности позволяют обнаружить конкретные уязвимости, если они есть, но на эти проверки уходит очень много времени.
- Bruteforce DNS. Данная техника является активным вмешательством. Она позволяет перебирать DNS-имена систем, определяя доступные. Это происходит через DNS-запросы к целевому DNS-серверу, при этом трафик можно направить, например, через Google DNS, и с точки зрения атакуемой организации эти запросы будут выглядеть легитимно. Для реализации таких техник обычно используется инструментарий KaliLinux или похожей сборки. К сожалению, на практике DNS-логи не смотрят или даже не ведут их, пока что-нибудь не произойдет.
- банки (с 1-го места по 25-е),
- банки (с 26-го по 50-е),
- банки (с 51-го по 75-е),
- банки (с 76-го по 100-е),
- микрокредитные организации,
- платежные системы,
- страховые компании (с 1-го по 50-е),
- страховые компании (с 51-го по 100-е).
- Netname (сетевое имя, очень полезно при поиске по БД Ripe);
- Descr (описание может быть применено для поиска с использованием фантазии);
- Address (поиск сетей, зарегистрированных на этот же физический адрес);
- Contact (возможен поиск в БД Ripe по людям, которые также могли регистрировать сети);
Всю эту информацию можно получить и через Unix команду whois. Что использовать — дело вкуса.
Используя собранную информацию об организациях, мы осуществили поиск их адресных диапазонов в базе данных регистратора RIPE, выбирали исключительно российский сетевой сегмент.
Этот этап работ требует большого количества ручного труда, ведь адреса могут быть отданы партнеру, сданы в аренду или не принадлежать искомой организации. Для повышения точности результатов нам пришлось провести дополнительные проверки. Для верификации сетей мы использовали общедоступный онлайн-сервис американского оператора связи Hurricane Electriс, который по IP-адресу сайта может выдать информацию о сети, в которой он располагается. На этом этапе оказался также очень полезен сервис Robtex. Он показывает все связи для указанного доменного имени, это позволило нам найти сети, которые не удалось обнаружить при поиске в базе Ripe. Кроме того, Robtex позволяет увидеть другие сайты, расположенные по данному IP-адресу.
Определение нужных сетей хуже всего автоматизируется, сбор информации о сетях финансового сектора занял у нас два дня. После завершения этого этапа мы получили список вида «организации — сети»
Шаг 2. Выявление доступных сервисов
Для этого можно использовать один из двух наиболее известных инструментов, призванных сделать интернет безопаснее: Shodan или Censys. Они имеют схожие возможности, поддерживают работу с API, а также могут дополнять друг друга. Для полноценного поиска оба сервиса требуют регистрации. Censys более требователен: чтобы снять в нем ограничения на выдачу результатов поиска, придется написать разработчикам, убедить их в этичности исследования и ответственном использовании полученных данных. Аргументом при этом будет сертификат CEH или подробная информация об исследовании.
Мы использовали сервис Shodan, для нас он более привычен и удобен. Процесс автоматизации описан, включая примеры кода на Python, создателем Shodan Джоном Матерли (John Matherly), также известным как @achillean, в весьма удобной форме6 . Более того, есть репозиторий на GitHub7 , где можно познакомиться с официальной библиотекой Shodan для Python.
Пример запроса через веб-интерфейс выглядит вот так:
На примере видно, что на адресе 8.8.8.8 доступен UDP-порт 53, сервис DNS, находящийся в США и принадлежащий Google, а также видна версия операционной системы, используемая на этом IP-адресе. Запросами к Shodan можно выявить гораздо более специфичные сервисы, к которым забывают ограничить доступ из интернета, хотя это следовало бы сделать. Поскольку можно получить различные баннеры и версии этих сервисов, то можно и сопоставить полученные данные с различными базами уязвимостей.
Нам нужно прогнать через Shodan каждый обнаруженный IP-адрес, а их мы собрали около 100 000 — многовато для ручной проверки… Мы написали собственный сборщик информации. Запустили — и спустя неделю работы программы получили картину распределения доступных сервисов в финансовом секторе, абсолютно никак не взаимодействуя с ними! Отслеживать таким способом изменения в инфраструктурах вполне реально. И вот что мы нашли...
Из самого ужасного на периметрах финансовых организаций найдены:
- СУБД (ради справедливости отметим, что у некоторых в баннере содержалась запись "is not allowed to connect to this SQL server");
- службы каталогов (по баннерам можно узнать LDAP);
- сервисы, предоставляющие доступ к ФС (такие как SMB и FTP);
- принтеры, которые могут иметь самые драматические уязвимости8 и вообще признаны наименее защищенными устройствами9 . Да-да, уязвимости старые. Но когда вы в последний раз обновляли свои принтеры на периметре?
- небезопасные сервисы удаленного управления, такие как Telnet, RDP;
- сервисы RPC;
- системы виртуализации;
- мультимедийные сервисы.
Полученные результаты нас не удивили: чем больше организация, тем больше сервисов размещено на ее сетевом периметре, а с ростом числа сервисов увеличивается вероятность ошибки конфигурации.
Шаг 3. Определение уязвимых сервисов
После нахождения доступных сервисов можно определить степень их защищенности. Уязвимы ли они? Какие уязвимости в них есть? Необходимо проанализировать признаковое пространство, которое отдает Shodan по каждому отдельному узлу. Эта информация имеет следующий вид:
- IP — уникальный сетевой адрес узла в компьютерной сети, построенной по протоколу IP;
- Port — цифровой номер, являющийся параметром транспортных протоколов (таких как TCP и UDP);
- Protocol — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами;
- Hostname — это символическое имя, присвоенное сетевому устройству, которое может быть использовано для организации доступа к этому устройству различными способами;
- Service — название определенного сервиса;
- Product — название ПО, с помощью которого реализован сервис;
- Product_version — версия определенного ПО;
- Banner — приветственная информация, отдаваемая сервисом при попытке подключения к нему;
- CPE — Common Platform Enumeration10, стандартизированный способ именования программных приложений, операционных систем и аппаратных платформ; OS — версия операционной системы.
Код:
IP: IP-адрес
FADN: -
Proto: tcp
Port: 80
Service: http
Product: Apache httpd
Version: 2.2.16
CPE: cpe:/a:apache:http_server:2.2.16
OS: -
Banner: HTTP/1.1 200 OK Date: Sat, 24 Dec 2016 16:24:42
GMT Server: Apache/2.2.16 (Debian) Accep t-Ranges: bytes
Cache-Control: must-revalidate, no-cache, max-age=0, maxage:0 Pragma: no-cache Expires: Fri, 01 Jan 2010 00:00:00
GMT Content-Length: 3109 Content-Type: text/html
Date: 2017-05-24T16:24:30.930984Из всего признакового пространства были выделены поля, по которым может быть найдена информация об уязвимости данного узла. Для этого отлично может подойти связка Product + Product_version либо CPE. В нашем случае мы решили воспользоваться связкой Product + Product_version, а поиск осуществлялся по внутренней базе уязвимостей Positive Technologies.
В сети существует немалое количество общедоступных источников для поиска уязвимостей, вот некоторые из них:
- SecurityLab.ru;
- БДУ ФСТЕК (bdu.fstec.ru);
- nvd.nist.gov;
- vulners.com;
- cvedetails.com;
- securityfocus.com.
Мы написали простенький скрипт, который довольно быстро обработал все полученные данные по сервисам, сопоставили их с нашей базой уязвимостей (то же самое легко делается и через названные сервисы) и получили следующую статистику распределения уязвимостей по сервисам:
Результаты получились следующие: из общего количества сервисов, найденных Shodan, уязвимости были обнаружены в 5%. Эта цифра мала: для сравнения, по данным наших собственных автоматизированных сканирований периметров, обычно уязвимости встречаются в 20–50% сервисов. Но теоретически процент обнаружения уязвимостей можно увеличить. К примеру, для ROSSSH можно предположить доступность уязвимости ROSSSH Remote Preauth Heap Corruption11. Несмотря на то что уязвимость не новая, вероятность встретить ее в этом сервисе значительно выше нуля. В своих предыдущих исследованиях12 мы говорили, что порядка 30% систем, доступных из интернета, содержат уязвимости старше 5 лет. Похожие цифры в своих исследованиях приводит Cisco13, по данным которой средний срок присутствия известных уязвимостей составляет пять с половиной лет. Эти результаты сопоставимы с нашими, а небольшое отличие обусловлено разными выборками и методами исследований. Схожий метод можно применить и к RDP.
Шаг 4. Поиск эксплойтов
Следующим шагом является поиск эксплойтов для определенных уязвимостей. Воспользуемся поисковиками, описанными выше, или специальными утилитами. Существует свободно распространяемая утилита PTEE14. А еще существует Metasploit, который хоть ничего и не собирает, но…
В нашей компании есть собственная база знаний, где уязвимости уже сопоставлены с эксплойтами. Вот результаты сопоставления:
- 88 из 559 уязвимостей с высоким уровнем риска по шкале CVSS имеют доступные эксплойты;
- 178 из 733 уязвимостей со средним уровнем риска имеют доступные эксплойты;
- 8 из 309 уязвимостей с низким уровнем риска имеют доступные эксплойты.
Это просто объяснить: с ростом инфраструктуры следить за ней все сложнее. Больше узлов — больше старого софта и больше уязвимостей. В крупных компаниях периметр крайне динамичный, мы показывали это в своих предыдущих исследованиях15.
Сколько времени займет поиск уязвимых сервисов, если информация об уязвимости только что появилась на просторах интернета? В нашей системе поиск по заданным уязвимостям занимает менее секунды. Больше времени уходит на анализ полученных результатов, но это тоже довольно быстро: в рамках этого исследования анализ по одной уязвимости занимал не более 15 минут.
Шаг 5. Собственно атака
После обработки информации, полученной на предыдущих шагах, злоумышленник проводит атаку на уязвимые системы с помощью доступных инструментов.
В нашем исследовании не проводились реальные атаки. Но оценить возможности хакеров мы способны. Рассмотрим для примера последнюю часть известного эксплойт-пака, слитого группой The Shadow Brokers. В этом паке присутствовало множество интересных эксплойтов, к примеру набор для взлома SMB, ставший общеизвестным после вирусной эпидемии WannaCry16. В нашей выборке этот эксплойт подошел для 36 систем (данные об исследуемом периметре были собраны до публикации архива с эксплойтами). На тот момент содержащиеся в паке эксплойты были применимы ко всем версиям Windows. Следовательно, их с большой вероятностью можно было взломать. Это и показал WannaCry, но это только вершина айсберга, в паке были и другие интересные эксплойты:
- Esteemaudit (эксплойт для RDP). Мы считаем размещение сервисов RDP на периметре без ACL (access control list) ошибкой. Для трех систем эксплойт мог быть применим, а 31 осталась без подтверждения.
- Набор эксплойтов для веб-серверов. Для 37 систем было построено предположение о применимости эксплойтов, нацеленных на взлом веб-серверов.
- Набор эксплойтов для почтовых серверов. На 13 системах были обнаружены почтовые серверы, версии которых подходили для эксплуатации.
В начале исследования уровень опасности нам казался ниже полученного, но потом пришел WannaCry и не согласился с нами. Причиной высокого уровня опасности стал недостаточный контроль внешнего периметра в организациях. При этом даже после публикации предупреждений и рекомендаций экспертов не произошло значительного повышения уровня защищенности.
Выводы и рекомендации по защите
Подведем итоги. Если использовать обычный сетевой сканер, который ищет уязвимости, у организации могут возникнуть подозрения, что их кто-то «смотрит». Факты сканирований легко выявить и блокировать. Но кто будет отслеживать работу массового поисковика? В этой статье мы продемонстрировали, что:
1) для подготовки целенаправленной атаки на финансовый сектор не требуется особых затрат;
2) подготовка может быть незаметной для атакуемых организаций и для тех, кто их защищает;
3) для реализации атаки необязательно обладать эксплойт-паком от АНБ, хотя и его компоненты тоже попадают в открытый доступ.
Безопасность периметра — один из базовых векторов защиты. Но защищать, не зная, что именно защищаешь, — занятие сложное и бессмысленное. Если вы не знаете границы защищаемого вами периметра, вы можете воспользоваться методами анализа сетей, описанными в этой статье.
Получив представление о том, из чего состоит периметр, займемся его защитой. Достижение максимально безопасных конфигураций информационных систем — трудная задача. Информационная безопасность всегда балансирует между функциональностью системы и ее защищенностью. Ошибки конфигурации присутствуют и в сетевых периметрах: как показывает наше исследование, в интернет выставляется много лишних, в том числе уязвимых, сервисов, что облегчает злоумышленнику возможность проникновения в сеть организации.
Рекомендуемый план по защите периметра может выглядеть следующим образом:
1. Определить те активы, доступ к которым из интернета обоснован.
2. Сервисы без обоснования доступа вывести с периметра.
3. Документировать и внедрить процедуру размещения новых систем на внешнем периметре.
4. Составить ACL, ограничивать доступ к административным интерфейсам, сервисам удаленного доступа, БД и другим важным сервисам минимально возможным списком лиц.
5. Ввести процедуру установки обновлений и определить метрики успешности ее выполнения.
6. Проводить работы по анализу защищенности, такие как пентест и аудит.
7. Определить список лиц, ответственных за активы (как со стороны бизнеса, так и со стороны IT). Это позволит снизить трудозатраты и время реакции при срочном обновлении систем.
8. Для приоритизации устранения уязвимостей — определить значимость активов.
9. Составить план реакции на случай обнаружения критически опасных уязвимостей в системах, расположенных на периметре
Конечно же, следует помнить, что для противодействия угрозам необходим комплексный подход к обеспечению ИБ, а начинать стоит со своих сетевых границ.
Ссылки
1 bgp.he.net
2 apps.db.ripe.net/db-web-ui/#/fulltextsearch
3 robtex.com
4 dnsdumpster.com
5 github.com
6 goo.gl/HpZFyw (media.readthedocs.org)
7 github.com/achillean/shodan-python
8 securitylab.ru/news/410610.php
9 securitylab.ru/news/483790.php
10 cpe.mitre.org
11 securitylab.ru/poc/444271.php
12 habrahabr.ru/company/pt/blog/309072/
13 goo.gl/PYwCwy (cisco.com)
14 habrahabr.ru/company/pt/blog/245885/
15 goo.gl/uvF9VH (ptsecurity.com)
16 goo.gl/Qnin5B (ptsecurity.com)
Источник: ptsecurity.com