14.3. Надзор: профилактика, обнаружение, сдерживание
Мониторинг является неотъемлемой частью любой политики в области безопасности по нескольким причинам. В частности, цель обеспечения безопасности, как правило, не ограничивается гарантиями конфиденциальности данных, но также включает обеспечение доступности услуг. Поэтому необходимо проверять, что всё работает так, как ожидалось, и своевременно обнаруживать любое девиантное поведение или изменение качества оказываемых услуг. Мониторинговая деятельность может помочь обнаружить попытки вторжения и обеспечить быструю реакцию, прежде чем они приведут к серьёзным последствиям. В этом разделе рассматриваются некоторые инструменты, которые могут быть использованы для мониторинга нескольких аспектов системы Debian. Таким образом, он завершает
Раздел 12.4, «Мониторинг».
14.3.1. Журналы мониторинга с logcheck
Программа logcheck отслеживает файлы журналов каждый час по умолчанию. Он отправляет нестандартные сообщения в файлах журналов на электронную почту администратору для дальнейшего анализа.
Список файлов для мониторинга хранится в /etc/logcheck/logcheck.logfiles; значения по умолчанию работают нормально, если файл /etc/rsyslog.conf не был полностью переделан.
logcheck может работать в одном из трёх более или менее подробных режимов: paranoid, server и workstation. Первый - очень многословный, и, вероятно, его следует ограничить конкретными серверами, такими как брандмауэры. Второй (по умолчанию) режим рекомендуется для большинства серверов. Последний предназначен для рабочих станций (отфильтровывает больше сообщений).
Во всех трёх случаях logcheck, вероятно, следует подгонять, чтобы исключить некоторые дополнительные сообщения (в зависимости от установленных сервисов), если администратор действительно не хочет получать ежечасовые партии длинных неинтересных электронных писем. Поскольку механизм выбора сообщений довольно сложен, изучение /usr/share/doc/logcheck-database/README.logcheck-database.gz необходимо если его сложно читать.
Прилагаемые правила могут быть разделены на несколько типов:
те, которые квалифицируют сообщение как попытку взлома (хранятся в файле каталога /etc/logcheck/cracking.d/);
отменяющие такую квалификацию(/etc/logcheck/cracking.ignore.d/);
классифицирующие сообщение как предупреждение о безопасности (/etc/logcheck/violations.d/);
отменяющие эту классификацию (/etc/logcheck/violations.ignore.d/);
наконец, те, которые относятся к оставшимся сообщениям (рассматриваемым как системные события).
Системное событие всегда сигнализируется, если в одном из каталогов /etc/logcheck/ignore.d.{paranoid,server,workstation}/ не указано, что событие должно быть проигнорировано. Конечно, единственными каталогами, которые принимаются во внимание, являются те, которые соответствуют уровням многословия, равным или превышающим выбранный режим работы.
14.3.2. Деятельность мониторинга
14.3.2.1. В реальном времени
top - это интерактивный инструмент, который отображает список текущих процессов. Сортировка по умолчанию основана на текущем количестве использования процессора и может быть получена с ключом P. Другие способы сортировки включают в себя сортировку по занятой памяти (M ключ), по общему времени процессора (T ключ) и по идентификатору процесса (N ключ). Ключ k позволяет убить процесс, введя идентификатор процесса. Ключ r позволяет изменить приоритет процесса renice.
Когда система кажется перегруженной, top - отличный инструмент, чтобы увидеть, какие процессы конкурируют за время процессора или потребляют слишком много памяти. Например, часто интересно проверить, соответствуют ли процессы, потребляющие ресурсы, реальным сервисам, которые предоставляет машина. Неизвестный процесс, запущенный как пользователь www-data, должен быть выделен и подвергнут исследованию, поскольку это, вероятно, пример программного обеспечения, установленного и выполненного в системе через уязвимость в веб-приложении.
top - это очень гибкий инструмент, и его страница руководства дает подробную информацию о том, как настроить его отображение и адаптировать его к личным потребностям и привычкам.
Графический инструмент gnome-system-monitor похож на top и предоставляет примерно те же функции.
Загрузка процессора, сетевой трафик и свободное дисковое пространство - это информация, которая постоянно меняется. Сохранение истории их изменений часто полезно для определения того, как именно используется компьютер.
Есть много специальных инструментов для этой задачи. Большинство может получить данные через SNMP (Simple Network Management Protocol), чтобы централизовать эту информацию. Дополнительным преимуществом является то, что это позволяет получать данные из сетевых элементов, которые не могут быть компьютерами общего назначения, таких как выделенные сетевые маршрутизаторы или коммутаторы.
Эта книга касается Munin в некоторой степени (см.
Раздел 12.4.1, «Настройка Munin») как части
Глава 12: «Углублённое администрирование». Debian также предоставляет аналогичный инструмент,
cacti. Его развертывание немного сложнее, поскольку оно основано исключительно на SNMP. Несмотря на наличие веб-интерфейса, понимание концепций, связанных с конфигурацией, всё ещё требует определённых усилий. Чтение HTML-документации (
/usr/share/doc/cacti/html/Table-of-Contents.html) должно считаться предварительным условием.
14.3.3. Избегайте вторжений
Атакующие пытаются получить доступ к серверам, угадывая пароли, поэтому всегда должны использоваться надёжные пароли. Даже тогда вы также должны установить меры против атак грубой силы. Атака грубой силы - это попытка войти в несанкционированную систему программного обеспечения, выполняя несколько попыток входа в систему за короткий промежуток времени.
Лучший способ остановить атаку грубой силы - ограничить количество попыток входа, идущих из того же происхождения (same origin), обычно временным запретом IP-адреса.
Fail2Ban - это набор программного обеспечения для предотвращения вторжений, который можно настроить для мониторинга любой службы, которая записывает попытки входа в файл журнала. Его можно найти в пакете fail2ban.
Fail2Ban настроен с помощью простого протокола fail2ban-client, который также читает файлы конфигурации и выдает соответствующие команды конфигурации на сервер fail2ban-server. Он имеет четыре типа файлов конфигурации, все они хранятся в /etc/fail2ban/:
fail2ban.conf. Глобальная конфигурация (например, журналирование).
filter.d/*.conf. Фильтры, указывающие, как обнаруживать ошибки аутентификации. Пакет Debian уже содержит фильтры для многих программ.
action.d/*.conf. Действия, определяющие команды по запрету (banning) и разрешению (unbanning) IP-адресов.
jail.conf. Именно там определены jails, комбинации фильтров и действий.
Давайте посмотрим на конфигурацию sshd в /etc/fail2ban/jail.conf, чтобы лучше понять, как работает Fail2Ban...
[...]
[DEFAULT]
[...]
bantime = 10m
[...]
findtime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban будет проверять неудавшиеся попытки входа sshd с использованием обычных выражений Python, определённых в /etc/fail2ban/filter.d/sshd.conf, в файле журнала sshd, который определяется в переменной sshd_log в файле /etc/fail2bans-common. Если Fail2Ban обнаружит пять неудачных попыток входа в систему в течение 10 минут, он запретит IP-адрес, где эти попытки возникли в течение 10 минут.
Чтобы включить, отключить или настроить “jails“, основной файл конфигурации /etc/fail2ban/jail.conf не должен быть изменён. Вместо этого это должно быть сделано в /etc/fail2ban/jail.d/defaults-debian.conf или в файлах в одном каталоге.
Fail2Ban - это очень простой и эффективный способ защиты от наиболее распространенных атак грубой силы, но он не может защитить от распределённых атак грубой силы, когда злоумышленник использует большое количество машин, рассеянных по Интернету.
Хороший способ обеспечить дополнительную защиту от распределённых атак грубой силы - искусственно увеличить время входа после каждой неудачной попытки.
14.3.4. Обнаружение изменений
Как только система установлена и настроена, и за исключением обновлений безопасности, для большинства файлов и каталогов, как правило, нет причин для разработки, за исключением данных. Поэтому интересно убедиться, что файлы на самом деле не меняются: поэтому любые неожиданные изменения стоит исследовать. В этом разделе представлены несколько инструментов, способных отслеживать файлы и предупреждать администратора, когда происходят неожиданные изменения (или просто перечислять такие изменения).
14.3.4.1. Аудит пакетов с dpkg --verify
dpkg -verify (или dpkg -V) - это интересный инструмент, поскольку он позволяет найти, какие установленные файлы были модифицированы (потенциально злоумышленником), но это следует принимать с толикой недоверия. Для выполнения своей работы он опирается на контрольные суммы, хранящиеся в собственной базе данных dpkg, которая хранится на жёстком диске (они могут быть найдены в /var/lib/dpkg/info/package.md5sums); поэтому основательный злоумышленник обновит эти файлы, чтобы они содержали новые контрольные суммы для подменённых файлов.
Запуск dpkg -V проверит все установленные пакеты и распечатает строку для каждого файла с неудачным тестом. Формат вывода такой же, как и в rpm -V, где каждый символ обозначает тест на некоторые конкретные метаданные. К сожалению, dpkg не хранит мета-данные, необходимые для большинства тестов, и, таким образом, выведет для них вопросы. В настоящее время только тест контрольных сумм может дать «5» на третьем символе (когда он не работает).
# dpkg -V
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster
В приведённом выше образце dpkg сообщает об изменении в файле сервиса SSH, который администратор сделал для упакованного файла вместо использования соответствующего /etc/systemd/system/ssh.service.d/override.conf переопределения (который будет храниться ниже /etc, как и любое изменение конфигурации. В нём также перечислены несколько файлов конфигурации (отмеченных буквой "с" в втором поле), которые были законно изменены.
14.3.4.2. Аудит пакетов: debsums и его лимиты
debsums является предком dpkg -V и, таким образом, в основном устарел. Он страдает от тех же ограничений, что и dpkg. К счастью, некоторые ограничения могут быть отработаны (где dpkg не предлагает аналогичные обходы).
Поскольку данным на диске нельзя доверять, debsums предлагает делать свои проверки на основе файлов .deb вместо того, чтобы полагаться на базу данных dpkg. Чтобы загрузить доверенные .deb файлы всех установленных пакетов, мы можем полагаться на аутентифицированные загрузки APT. Эта операция может быть медленной и утомительной, и поэтому её не следует рассматривать как проактивный метод, который следует использовать на регулярной основе.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
Обратите внимание, что этот пример использует команду grep-status из пакета dctrl-tools, который не установлен по умолчанию.
debsums может часто запускаться как cronjob настройка CRON_CHECK в /etc/default/debsums. Чтобы игнорировать некоторые файлы за пределами каталога /etc, которые были изменены намеренно или которые, как ожидается, изменятся (например, /usr/share/misc/pci.ids), вы можете добавить их к /etc/debsums-ignore.
14.3.4.3. Мониторинг файлов: AIDE
Инструмент AIDE (Advanced Intrusion Detection Environment ) позволяет проверять целостность файла и обнаруживать любые изменения по сравнению с ранее записанным образом действующей системы. Этот образ хранится как база данных (/var/lib/aide/aide.db), содержащая соответствующую информацию по всем файлам системы (отпечатки файлов, разрешения, метки времени и так далее). Эта база данных впервые инициализируется командой aideinit ; она затем используется ежедневно (по сценарию /etc/cron.daily/aide), чтобы проверить, что ничего не изменилось. При обнаружении изменений AIDE записывает их в лог-файлах (/var/log/aide/*.log) и отправляет их администратору по электронной почте.
Многие опции в /etc/default/aide могут быть использованы для настройки поведения пакета aide. Собственная конфигурация AIDE хранится в /etc/aide/aide.conf и /etc/aide/aide.conf.d/ (на самом деле эти файлы используются только update-aide.conf для создания /var/lib/aide/aide.conf.autogenerated. Например, содержимое файлов журнала меняется регулярно, и такие изменения могут быть проигнорированы до тех пор, пока разрешения этих файлов остаются прежними, но как содержимое, так и разрешения исполняемых программ должны быть постоянными. Хотя и не очень сложный, синтаксис конфигурации не полностью интуитивен, поэтому рекомендуется читать aide.conf(5).
Новая версия базы данных генерируется ежедневно в /var/lib/aide/aide.db.new; если все зарегистрированные изменения были законными, их можно использовать для замены исходной базы данных.
14.3.5. Обнаружение вторжений (IDS/NIDS)
suricata (в одноимённом пакете Debian) является NIDS —
Network Intrusion Detection System. Его функция - слушать сеть и пытаться обнаруживать попытки проникновения и/или враждебные действия (включая отказ в обслуживании). Все эти события регистрируются в нескольких файлах в
/var/log/suricata. Есть сторонние инструменты (Kibana/logstash), для лучшего просмотра всех собранных данных.
Настройка suricata включает в себя просмотр и редактирование /etc/suricata/suricata.yaml, очень длинного, потому что каждый параметр обильно прокомментирован. Минимальная конфигурация требует описания диапазона адресов, которые охватывает локальная сеть (HOME_NET parameter). На практике это - все потенциальные цели атаки. Для получения максимальной отдачи прочитайте файл полностью и адаптируйте к ситуации.
В довершение всего, вы должны отредактировать его, чтобы определить сетевой интерфейс. Вы также можете захотеть установить LISTENMODE=pcap, поскольку по умолчанию LISTENMODE=nfqueue требуется дальнейшая конфигурация для правильной работы (сетевый файрвол должен быть настроен для передачи пакетов в определённую очередь пользовательского пространства, управляемую suricata через NFQUEUE цель).
Чтобы обнаружить неверное поведение, suricata нужен набор правил мониторинга: вы можете найти такие правила в snort-rules-default пакете. snort - это исторический предшественник в экосистеме IDS и suricata может переиспользовать его правила.
В качестве альтернативы, oinkmaster (в одноимённом пакете) можно использовать для загрузки наборов правил Snort из внешних источников.
