Как просканировать сетевой периметр сервиса с помощью open source-инструментов

∘ARTICLES 31.03.22 31.03.22 231
Бесплатные курсына главную сниппетов

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

Периметр любой сети — первый эшелон защиты, отправная точка построения системы защиты информации. Цель этого текста — показать подход, позволяющий провести инвентаризацию доступных «снаружи» и потенциально уязвимых сервисов. Мы оценим их уровень защищенности и выработаем план по повышению безопасности сетевого периметра.

К концу статьи мы повысим уровень защищенности от статуса «не знаю, как настроен сетевой периметр» до «опубликованы минимально необходимые сервисы с учетом необходимых настроек безопасности». В работе будем использовать бесплатное программное обеспечение.

Чек-лист для оценки защищенности вашей сети — под катом.

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

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

Мы же предлагаем более дешевый, но не менее эффективный способ настроить подобную систему самостоятельно.

Целевое состояние


Сетевой периметр в безопасности. Что мы подразумеваем под этим состоянием, к чему придем в завершение текста:


План работ


Анализ текущего состояния сети пройдет по следующим шагам:


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

Источниками информации об используемых белых сетях могут выступить:

  1. Составленный и поддерживаемый в актуальном состоянии план сетей (или карта сети при наличии).
  2. Физический доступ к оборудованию. Необходимо проверить, как оно скоммутировано с другим сетевым оборудованием и иными хостами (например, серверами).
  3. Конфигурация пограничного оборудования. Здесь необходимо проанализировать настройки интерфейсов (назначенные IP-адреса и маски сетей), таблицу маршрутизации, правила трансляции адресов, запущенные сервисы и ACL оборудования.
  4. DNS-записи. Их список будет особенно полезным на этапе сканирования веб-приложений.
  5. Договор с провайдером. В нем также можно найти информацию об арендованных белых IP-адресах.

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

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

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

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

Требуемый состав ПО для сканирования, которое нужно установить на сервер, следующий:


Есть несколько вариантов подготовки тестового хоста. Вы можете: 


sudo apt update && sudo apt upgrade && sudo apt install nmap nikto -y


Сканирование белых сетей с помощью nmap
Перед этим необходимо проанализировать возможное влияние сканирования на работающие сервисы.

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

До сканирования следует выполнить следующие действия:


Сбор информации о портах и сервисах, доступных из интернета


Здесь и далее в примерах команд мы будем использовать IP-адреса x.x.x.x и DNS-имена servicename.test. При воспроизведении инструкции используйте определенный вами пул IP-адресов (в виде диапазонов или сетей) и DNS-имен веб-приложений.

Итак, у нас есть установленный сканер nmap, а белый IP-адрес добавлен в список исключений IDS/IPS. Интенсивность сканирования — количество запросов в единицу времени — можно регулировать, установив один из параметров ниже. Чем выше показатель, тем больше грузится сеть и ресурсы, к которым обращается сканер, также повышается вероятность обнаружения со стороны IDS.

Параметр Описание
-T0,-T1 Оба режима используются для обхода IDS, время сканирования будет сильно увеличено.
-T2 Снижает интенсивность сканирования, чтобы потреблять меньше ресурсов и меньше нагружать сеть.
-T3 Режим устанавливается по умолчанию.
-T4 Режим повышает интенсивность сканирования. Актуален, если вы используете быструю и надежную сеть.
-T5 Режим предполагает, что вы готовы пожертвовать точностью ради скорости.

Далее стоит определиться со списком сканируемых портов. По умолчанию nmap сканирует первую тысячу портов.

Если после анализа настроек NAT и Firewall у вас есть полный список опубликованных портов, можно в параметрах сканирования указывать конкретные значения — например, -p 80, 443, 1194. Если такой информации нет, можно явно указывать все порты ( -p 0-65535). В таком случае сканирование будет идти долго, но можно будет получить полную картину по опубликованным портам.

Статусы портов в результатах сканирования с помощью nmap могут быть следующими:

Статус Описание
open Приложение активно принимает соединения TCP, дейтаграммы UDP или ассоциации SCTP на этом порту.
closed Закрытый порт доступен (он принимает и отвечает на зондовые пакеты nmap), но его не прослушивает ни одно приложение.
filtered Nmap не может определить, открыт ли порт, потому что фильтрация пакетов не позволяет его зондам достичь порта. Фильтрация может осуществляться с помощью выделенного брандмауэра, правил маршрутизатора или программного обеспечения брандмауэра на хосте.
unfiltered Нефильтрованное состояние означает, что порт доступен, но nmap не может определить, открыт он или закрыт.
open|filtered Nmap помечает порты таким состоянием, когда не может определить, открыт порт или отфильтрован. Это происходит для типов сканирования, при которых открытые порты не дают ответа. Отсутствие ответа может также означать, что пакетный фильтр отклонил зонд. Таким образом, nmap не знает наверняка, открыт порт или фильтруется.
closed|filtered Это состояние используется, когда nmap не может определить, закрыт порт или фильтруется.

На данном этапе все готово к началу сканирования. Ниже опишем несколько вариантов сканирования с записью результатов в файл nmap.txt.

Список открытых портов


Запустим команду: 

$ sudo nmap x.x.x.x --open -T4 -p 0-65535 -v > nmap.txt

Пример результата сканирования
Starting Nmap 7.01 ( nmap.org ) at 2022-03-21 19:01 UTC
Initiating ARP Ping Scan at 19:01
Scanning x.x.x.x [1 port]
Completed ARP Ping Scan at 19:01, 0.20s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 19:01
Completed Parallel DNS resolution of 1 host. at 19:01, 0.01s elapsed
Initiating SYN Stealth Scan at 19:01
Scanning x.x.x.x [65536 ports]
Discovered open port 22/tcp on x.x.x.x
Discovered open port 80/tcp on x.x.x.x
Warning: x.x.x.x giving up on port because retransmission cap hit (2).
SYN Stealth Scan Timing: About 23.45% done; ETC: 19:03 (0:01:41 remaining)
SYN Stealth Scan Timing: About 46.57% done; ETC: 19:03 (0:01:10 remaining)
SYN Stealth Scan Timing: About 70.16% done; ETC: 19:03 (0:00:39 remaining)
Completed SYN Stealth Scan at 19:04, 172.36s elapsed (65536 total ports)
Nmap scan report for x.x.x.x
Host is up (0.00018s latency).
Not shown: 65516 closed ports, 18 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
MAC Address: FA:16:3E:2B:29:0B (Unknown)

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 172.64 seconds
Raw packets sent: 129144 (5.682MB) | Rcvd: 129090 (5.164MB)

В результате сканирования обнаружены два открытых порта: 22/TCP, 80/TCP. 18 портов фильтруется, остальные закрыты. Первичное обнаружение открытых портов и работа по ним позволяет существенно сократить время более углубленного сканирования. Продолжая сканирование, будем указывать эти порты.

Список открытых портов с версиями приложений


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

$ sudo nmap x.x.x.x -p 22,80 -sV -O -v > nmap.txt

Пример результата сканирования
Starting Nmap 7.01 ( nmap.org ) at 2022-03-21 19:05 UTC
Nmap scan report for x.x.x.x
Host is up (0.00026s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp open http nginx 1.14.0 (Ubuntu)
MAC Address: FA:16:3E:2B:29:0B (Unknown)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.2 — 4.0 (96%), Linux 2.6.32 — 3.10 (96%), Linux 2.6.32 (96%), Linux 3.4 — 3.10 (95%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 2.6.32 — 2.6.35 (94%), Linux 2.6.32 — 3.5 (94%), Linux 2.6.32 — 3.13 (93%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at nmap.org/submit.
Nmap done: 1 IP address (1 host up) scanned in 11.55 seconds

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

На основании информации о версиях ОС, ее ядра, а также версиях ПО можно понять, является ли используемые ОС и ПО устаревшими и есть ли в них известные уязвимости. За последней информацией можно обратиться к ресурсу CVE.

Комплексное сканирование


Nmap позволяет использовать скриптовый движок NSE — Nmap Scripting Engine. С его помощью можно существенно увеличить объем получаемой информации за счет применения множества разнообразных проверок, написанных на языке lua и добавленных в базу скриптов nmap. Дополнительную информацию о применении NSE можно найти здесь.

Рассмотрим пример сканирования с помощью скриптов категории vuln.

Запустим расширенное сканирование следующей командой: 
$ sudo nmap x.x.x.x -T4 -A -p 22,80 --script “vuln” -v > nmap.txt

Пример результата сканирования
Starting Nmap 7.01 ( nmap.org ) at 2022-03-21 19:11 UTC
NSE: Loaded 114 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 19:11
Completed NSE at 19:11, 10.00s elapsed
Initiating NSE at 19:11
Completed NSE at 19:11, 0.00s elapsed
Initiating ARP Ping Scan at 19:11
Scanning x.x.x.x [1 port]
Completed ARP Ping Scan at 19:11, 0.20s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 19:11
Completed Parallel DNS resolution of 1 host. at 19:11, 0.01s elapsed
Initiating SYN Stealth Scan at 19:11
Scanning x.x.x.x [2 ports]
Discovered open port 22/tcp on x.x.x.x
Discovered open port 80/tcp on x.x.x.x
Completed SYN Stealth Scan at 19:11, 0.20s elapsed (2 total ports)
Initiating Service scan at 19:11
Scanning 2 services on x.x.x.x
Completed Service scan at 19:11, 6.01s elapsed (2 services on 1 host)
Initiating OS detection (try #1) against x.x.x.x
Retrying OS detection (try #2) against x.x.x.x
NSE: Script scanning x.x.x.x.
Initiating NSE at 19:11
Completed NSE at 19:12, 60.60s elapsed
Initiating NSE at 19:12
Completed NSE at 19:12, 0.00s elapsed
Nmap scan report for x.x.x.x
Host is up (0.00029s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-cross-domain-policy: ERROR: Script execution failed (use -d to debug)
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-fileupload-exploiter:
|_http-frontpage-login: false
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.

| http-vuln-cve2011-3192:
| VULNERABLE:
| Apache byterange filter DoS
| State: VULNERABLE
| IDs: CVE:CVE-2011-3192 OSVDB:74721
| The Apache web server is vulnerable to a denial of service attack when numerous
| overlapping byte ranges are requested.
| Disclosure date: 2011-08-19
| References:
| cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
| seclists.org/fulldisclosure/2011/Aug/175
| nessus.org/plugins/index.php?view=single&id=55976
| cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
|_ osvdb.org/74721
MAC Address: FA:16:3E:2B:29:0B (Unknown)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.2 — 4.0 (96%), Linux 2.6.32 — 3.10 (96%), Linux 2.6.32 (96%), Linux 3.4 — 3.10 (95%), Linux 3.1 (94%), Linux 3.2 (94%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 3.3 (94%), Linux 2.6.32 — 2.6.35 (94%), Linux 2.6.32 — 3.5 (94%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 8.038 days (since Sun Mar 13 18:17:44 2022)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT ADDRESS
1 0.29 ms x.x.x.x

NSE: Script Post-scanning.
Initiating NSE at 19:12
Completed NSE at 19:12, 0.00s elapsed
Initiating NSE at 19:12
Completed NSE at 19:12, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at nmap.org/submit.
Nmap done: 1 IP address (1 host up) scanned in 82.18 seconds
Raw packets sent: 86 (8.808KB) | Rcvd: 68 (7.540KB)

В результате сканирования найдена уязвимость веб-сервера Apache cve2011-3192, более подробную информацию о ней можно также найти здесь.

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

Запустим следующую команду для сканирования веб-приложения, в котором необходимо авторизоваться для доступа к содержимому сайта: 

$ sudo nmap --script http-enum servicename.test -v > nmap.txt

Пример результата сканирования
Starting Nmap 7.60 ( nmap.org ) at 2022-03-21 06:41 PDT
NSE: Loaded 1 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 06:41
Completed NSE at 06:41, 0.00s elapsed
Initiating Ping Scan at 06:41
Scanning servicename.test (x.x.x.x) [4 ports]
Completed Ping Scan at 06:41, 0.20s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 06:41
Completed Parallel DNS resolution of 1 host. at 06:41, 0.00s elapsed
Initiating SYN Stealth Scan at 06:41
Scanning servicename.test (x.x.x.x) [2 ports]
Discovered open port 80/tcp on x.x.x.x
Discovered open port 443/tcp on x.x.x.x
Completed SYN Stealth Scan at 06:41, 0.20s elapsed (2 total ports)
NSE: Script scanning x.x.x.x.
Initiating NSE at 06:41
Stats: 0:03:17 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE: Active NSE Script Threads: 1 (0 waiting)
Completed NSE at 06:45, 218.38s elapsed
Nmap scan report for servicename.test (x.x.x.x)
Host is up (0.18s latency).
rDNS record for x.x.x.x: servicename.test

PORT STATE SERVICE
80/tcp open http
443/tcp open https
| http-enum:
| /robots.txt: Robots file
|_ /remote/: Potentially interesting folder

NSE: Script Post-scanning.
Initiating NSE at 06:45
Completed NSE at 06:45, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 219.19 seconds
Raw packets sent: 6 (240B) | Rcvd: 3 (132B)


В результате видны каталоги и файлы сайта, которые доступны без авторизации.

Промежуточные итоги


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


Возможности nmap не ограничиваются приведенными примерами. Для более широкого сканирования, например, можно использовать иные категории скриптов. Более полную информацию можно найти на сайте.

Сканирование веб-приложений с помощью Nikto
У нас есть список доступных белых IP-адресов и открытых в интернет портов. Также мы выяснили, какие сервисы доступны «снаружи», какие у них версии операционных систем и программного обеспечения. На данном этапе предлагаем провести сканирование опубликованных веб-приложений с помощью инструмента Nikto.

Nikto — сканер уязвимостей веб-серверов с открытым исходным кодом. Он выполняет всесторонние тесты, выявляя следующие уязвимости:


Nikto не может работать в скрытом режиме. Адрес, с которого будет производиться сканирование, необходимо добавить в исключения IPS, чтобы он не был заблокирован в ходе тестирования.

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

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

Самый простой запуск сканирования с сохранением результата в html-файл выглядит так: 

$ sudo nikto -host servicename.test -o result.html -Format htm

Параметр Назначение
-host servicename.test целевой объект сканирования
-ssl использование ssl
-Tuning 2490ab расширенное сканирование, а именно:
2 — поиск миcконфигов и/или файлов по умолчанию
4 — поиск уязвимостей инъекций (XSS/Script/HTML)
9 — поиск уязвимостей SQL-инъекций
0 — возможность загрузки файлов на сервер
a — отсутствие аутентификации
b — определение версий ПО
-o result.html файл для записи результата
-Format htm формат записи результата (html)
-Display V расширенный вывод сканирования
-C all сканировать все cgi-dirs

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

$ sudo nikto -host servicename.test -ssl -Tuning 2490ab -o result.html -Format htm

В результате сканирования получаем html-файл с подробно описанными результатами.

Рассмотрим часть отчета, чтобы понять принцип анализа результатов сканирования:


В каждом из блоков отчета содержится:


Информацию о соответствии записей OSVDB и CVE можно найти по ссылке.

В примерах указаны следующие описания:

Uncommon header 'x-frame-options' found, with contents: SAMEORIGIN

Информацию по данному описанию можно найти, например, на данном ресурсе. И кастомизировать параметр заголовка HTTP по результатам анализа.

Uncommon header 'x-robots-tag' found, with contents: none

Аналогично стоит проанализировать информацию по второму отмеченному в отчете заголовку, основываясь, например, на информацию ресурса. После тут тоже стоит кастомизировать параметр заголовка HTTP.

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

Меры по повышению уровня защищенности периметра
Итак, по результатам сканирований у нас есть следующая информация:


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

Чек-лист повышения уровня защищенности информационной безопасности
Убедитесь, что вы можете поставить галочку напротив каждого из пунктов. Если нет, подумайте, как это исправить.

1. Вы используете актуальные версии ОС и ПО


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

2. У вас есть понимание цели каждого опубликованного в интернет порта


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

3. Используете более безопасные версии протоколов


Например, HTTPS вместо HTTP, SMTPS вместо SMTP, FTPS вместо FTP, SSH вместо TELNET, SNMPv3 вместо SNMP первой и второй версий.

4. Не публикуете порты для управления устройствами и хостами


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

5. Используете reverse-proxy в DMZ для публикаций веб-приложений


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

6. Используете Port-Forwarding для проброса портов


7. Используете решения IDS/IPS


Можно использовать open source-решения (Suricata, Snort) или, например, обеспечить защиту сервисов через провайдера.

8. Используете WAF


Решения класса Web Application Firewall являются наилучшим вариантом для обеспечения безопасной публикации веб-приложений.

9. Используете фильтрацию GeoIP


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

Ранее мы подробно описывали, как реализовать подобную фильтрацию. Также ее можно осуществить с помощью параметров nginx.

Также многие Firewall поддерживают этот функционал — например, UserGate и pfSense (можно установить на виртуальный или выделенный сервер).

10. Используете fail2ban для сервисов, где настроена авторизация


Для SSH, например, можно найти информацию о настройке fail2ban здесь.

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


Реализация возможна, например, с помощью nginx в качестве обратного прокси-сервера для публикации ресурсов.

12. Используете защиту от DDoS


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

13. Настроили регулярное сканирование белых IP-адресов


Регулярное внешнее сканирование ресурсов поможет поддерживать уровень ИБ на высоком уровне. Можно развернуть свой хост для сканирования, как было описано в тексте, или, например, воспользоваться соответствующей услугой в каком либо Аттестованном периметре ЦОД.

14. Отслеживаете информацию о новых уязвимостях


Актуальную информацию можно получать, например, из следующих источников — список новых уязвимостей ПО или БДУ, а также на сайтах вендоров конкретных решений.

15. Авторизация на хостах происходит под непривилегированной учетной записью с дальнейшим повышением прав


16. По возможности используете SSH-ключи для авторизации


17. Используете сложные пароли, если есть возможность использовать только пароли


Например, пароли со следующими характеристиками: длина не менее 12 символов с алфавитом, содержащим строчные, заглавные буквы, цифры, спецсимволы.

18. По возможности используете двухфакторную аутентификацию


19. Настроили логирование и мониторинг ИБ


Необходимо настроить сбор логов межсетевого экрана, систем обнаружения и предотвращения вторжения, логи сервисов и ОС. Для более эффективного реагирования должна быть настроена корреляции всей собранной информации. Для мониторинга информационной безопасности можно использовать open source-решение, например Wazuh, или воспользоваться «коробочным» решением, существующим на рынке.

Заключение
Итак, теперь вы можете провести базовую «инвентаризацию» своего сетевого периметра с помощью доступных инструментов, не требующих серьезных затрат.

 

➕

👉 "Magnificent Seven" Guide to Great Password Security and High-Value ‘Admin’ Password Security

Управление ключами шифрования и безопасность сетиУправление ключами шифрования и безопасность сети 528 страниц · 2016 · 48.09 MB · русский by Фороузан Б.А.
Тестирование на проникновение с помощью Kali Linux 2.0Тестирование на проникновение с помощью Kali Linux 2.0 348 страниц · 2015 · 24.11 MB · русский by Милосердов А. Гриднев Д.
Лаборатория хакераЛаборатория хакера 239 страниц · 2016 · 33.51 MB · русский by Бабин Сергей Александрович
Информационная безопасность. Защита и нападение.Информационная безопасность. Защита и нападение. 434 страницы · 2017 · 91.43 MB · русский by Бирюков А.А.
Анализ пакетов: практическое руководство по использованию Wireshark и tcpdump для решения реальных проблем в локальных сетяхАнализ пакетов: практическое руководство по использованию Wireshark и tcpdump для решения реальных проблем в локальных сетях 450 страниц · 2019 · 79.44 MB · русский by Крис Сандерс
Компьютерные сети. Принципы, технологии, протоколыКомпьютерные сети. Принципы, технологии, протоколы. 5-е издание 996 страниц · 2016 · 48.08 MB · русский by Виктор Олифер & Наталия Олифер
Компьютерные сети: нисходящий подходКомпьютерные сети: нисходящий подход 912 страниц · 2016 · 7.94 MB · русский by Джеймс Куроуз & Кит Росс
 
на главную сниппетов
Курсы