Аудит доступа к файлам linux. Жесткая закалка Linux

Полезные советы

В сегодняшней статье мы познакомим вас с лучшими утилитами аудита безопасности Linux или как говорят наши англоязычные коллеги — Hardening Linux . Итак, тема статьи проверка уровня защищенности Linux-систем и оценка корректности конфигов с точки зрения информационной безопасности. Разумеется, мы не только сделаем обзор программ, но и приведем примеры их использования.

Аудит безопасности Linux собственными силами

Перед системными администраторами, а уж тем более перед аудиторами информационной безопасности часто встают задачи проверить защищенность большого количества хостов за очень короткое время. И конечно, для решения этих задач в Enterprise-сегменте есть специализированные инструменты, к примеру такие, как . Уверен, что все они - от open sources движка OpenVAS до коммерческих продуктов типа Nessus или Nexpose - известны нашему читателю. Но данный софт обычно используется, чтобы искать устаревшее и потому уязвимое программное обеспечение и затем запустить патч-менеджмент . Кроме этого не все сканеры безопасности учитывают определенные специфические особенности встроенных механизмов защиты ОС Linux и других продуктов с открытым исходным кодом. Ну и не в последнюю очередь значение имеет цена вопроса, ведь платные продукты могут позволить себе разве что компании, выделяющие под это дело какие-то бюджеты.

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

Практические аспекты аудита безопасности Linux

Если посмотреть глазами аудитора, то подход к тестированию можно разделить на два типа.

Первый - это соответствие так называемым compliance-требованиям , здесь проверяется наличие обязательных элементов защиты, прописанных в каком-либо международном стандарте или «best practice». Классический пример - требования PCI DSS для платежных ИТ-систем, SOX404 , NIST-800 series, .

Второй - это сугубо рациональный подход, основанный на вопросе «А что еще можно сделать, чтобы усилить защищенность?». Тут нет обязательных требований - только твои знания, светлая голова и умелые руки. К примеру, это обновление версии ядра и/или пакетов приложений, включение , форсирование SELinux, настройка файрвола iptables.

Все, что относится ко второму подходу, принято называть специальным термином Linux hardening , что еще можно определить как «действия, направленные на усиление уровня исходной защищенности ОС (или ПО) преимущественно штатными средствами».

Соответствие compliance-требованиям, как правило, проверяют при подготовке к прохождению обязательного аудита типа PCI DSS или другого сертификационного аудита. Мы же больше уделим внимание Hardening-составляющей. Все крупные вендоры предлагают для своих продуктов Hardening Guidelines - руководства, содержащие советы и рекомендации, как усилить защищенность, учитывая штатные механизмы безопасности и специфику ПО. Так, подобные руководства есть у Red Hat , Debian , Oracle , Cisco .

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

Кстати, у нас уже когда-то была статья про настройку опций Hardening, но в той статье речь шла именно о настройке. Мы же сначала проверим нашу систему с помощью специализированных утилит, то есть проведем аудит безопасности, оценим текущий уровень защиты, а потом уже накрутим туда security option, если в этом будет необходимость. Ну или еще как вариант: если сервер уже настроен с точки зрения безопасности, наши инструменты смогут это проверить и, возможно, подсказать, что же можно сделать еще.

Инструменты аудита безопасности Linux

Lynis - auditing system hardening testing

Установка на macOS:

Инициализация тестов
Результаты тестов из группы System Tool and Boot & Services
Результаты тестов из группы Kernel and Memory & Process auditing
Результаты тестов из группы User and Group & Authentication

Перед аудитом всегда полезно проверить, доступна ли новая версия Lynis:

Если же вы хотите поместить имя аудитора, запустившего тестирование, просто добавьте параметр -auditor :

sudo lynis audit system - c - auditor Daddy

На любом этапе аудита безопасности Linux процесс проверки может быть продолжен (Enter) или принудительно прекращен (Ctrl+C). Результаты выполненных тестов будут писаться в журнал Lynis в каталог /var/log/lynis.log. Учтите, что лог-файл будет перезаписываться при каждом следующем запуске утилиты.

Для тестирования на постоянной основе в автоматическом режиме можно назначить соответствующее задание в планировщик Cron с помощью ключа -cronjob. В таком случае Lynis будет запускаться по заданному шаблону (конфигу) и не будет выводить никаких интерактивных лишних сообщений, вопросов и предупреждений. Все результаты будут сохранятся в лог. К примеру, вот скрипт запуска утилиты с настройками по умолчанию раз в месяц:

#!/bin/sh

AUDITOR = ”automated ”

DATE = $ (date + % Y % m % d )

HOST = $ (hostname )

LOG_DIR = ”/ var / log / lynis ”

REPORT = ”$ LOG_DIR / report - $ { HOST } . $ { DATE } ”

DATA = ”$ LOG_DIR / report - data - $ { HOST } . $ { DATE } . txt ”

cd / usr / local / lynis

. / lynis - c –auditor “$ { AUDITOR } ”–cronjob > $ { REPORT }

mv / var / log / lynis - report . dat $ { DATA }

# End

Сохраните этот скрипт в каталог /etc/cron.monthly/lynis. И не забудьте добавить пути для сохранения логов (/usr/local/lynis and /var/log/lynis), иначе возможна некорректная работа.

Можно посмотреть список всех доступных для вызова команд:

Краткая инструкция по работе с утилитой:

man lynis

Варианты возможных статусов по результатам проверки ограничиваются следующим списком: NONE, WEAK, DONE, FOUND, NOT_FOUND, OK, WARNING .

Пример вывода статусов

Запуск отдельных тестов в Lynis

На практике бывает необходимо провести лишь некоторые определенные тесты. К примеру, если ваш сервер выполняет только функции Mail Server или Apache. Для этого мы можем использовать параметр -tests. Синтаксис команды выглядит таким образом:

Помимо этого, функциональность Lynis расширяют различные дополнения , которые можно дописывать самостоятельно, а можно подкладывать новые в существующую директорию.

Все предупреждения (Warnings) будут перечислены после результатов. Каждое начинается с текста предупреждения, потом рядом в скобках указывается тест, который его сгенерировал. В следующей строке предлагается решение проблемы, если оно конечно существует. По факту последняя строка - это URL-адрес, по которому вы сможете посмотреть подробности и найти дополнительные рекомендации, как устранить возникшую проблему.

Вывод рекомендаций, как устранять найденные проблемы

Профили

Профили, которые управляют аудитом, определяются в файлах с расширением.prf, расположенных в каталоге /etc/lynis. Профиль по умолчанию называется, предсказуемо, default.prf. Разработчики не советуют править его напрямую: любые изменения, которые вы хотите внести в аудит, лучше добавлять в файл custom.prf, находящийся в том же каталоге.

Создаем и редактируем кастомный профиль:

touch / etc / lynis / custom . prf

sudo nano / etc / lynis / custom . prf

В данном файле можно определить список тестов, которые необходимо исключить из аудита Lynis. Например:

FILE-6310: проверка разделов;
HTTP-6622: тест установки nginx;
HTTP-6702: тест установки Apache.

Чтобы исключить какой-то определенный тест, воспользуйтесь директивой skip-test и укажите ID теста. Например, так:

# Is nginx installed?

skip - test = HTTP - 6622

# Is Apache installed?

skip - test = HTTP - 6702

Оценка hardening state

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

Lynis security scan details :

Hardening index : 57 [ ############.........]

Tests performed : 216

Plugins enabled : 0

Итоговая оценка hardening state

Данный результат, выраженный числом, показывает количество пройденных тестов и индекс безопасности системы, то есть hardening index - конечное число, с помощью которого Lynis дает оценку общего уровня безопасности сервера. И очень важно не забывать, что индекс безопасности изменяется в зависимости от количества исправленных предупреждений и выполненных рекомендаций Lynis. Поэтому после исправлений найденных проблем повторный аудит безопасности может показать совсем другое число!

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

Lunar - a UNIX security auditing tool

Примеры запуска команд из CLI:

Просмотр всех параметров запуска Lunar

Запуск Lunar в режиме аудита безопасности, то есть без внесения изменений в систему :

Перечисление тестов:

Запуск в режиме исправления, то есть с внесением изменений в систему :

Пример запуска тестов для web-сервера Apache

Nix Auditor - a CIS Audit made easier

Nix Auditor - это очередной скрипт для проверки, соответствует ли безопасность Linux-систем требованиям показателя CIS. Ориентирован на RHEL, CentOS и прочие RPM-дистрибутивы.

Разработчики заявляют о таких преимуществах Nix Auditor:

скорость сканирования - провести базовую проверку ОС можно менее чем за 120 секунд и тут же получить отчет;
точность проверки - работа Nix Auditor проверена на разных версиях дистрибутивов CentOS и Red Hat;
настраиваемость - исходники с документацией к программе лежат на GitHub, поэтому код легко настраивается в соответствии с типом ОС и набором элементов системы, которые необходимо проверить;
простота использования - достаточно сделать стартовый скрипт исполняемым, и тот уже готов к проверке.

Пример выполнения команд для загрузки утилиты с GitHub-хранилища и последующего запуска скрипта:

git clone https : //github.com/XalfiE/Nix-Auditor.git

cd Nix - Auditor

chmod + x nixauditor

. / nixauditor

Пример вывода информации после запуска Nix Auditor

Loki - Simple IOC and Incident Response Scanner

Утилита Loki - не совсем классический инструмент для проведения аудита Linux, но он отлично подходит для поиска следов взлома, что является , но отчасти можно отнести и к практике аудита.

По заверениям разработчиков, вот такие возможности дает нам Loki - Simple IOC and Incident Response Scanner:

I. Четыре способа выявить взлом:

имена файлов (соответствие регулярному выражению полного пути файла);
проверка в соответствии с правилами Yara (поиск на соответствие сигнатурам Yara по содержимому файлов и памяти процессов);
проверка и анализ хешей (сравнение просканированных файлов с хешами (MD5, SHA-1, SHA-256) известных вредоносных файлов);
проверка обратной связи C2 (сравнивает конечные точки технологического соединения с C2 IOC).

II. Дополнительные проверки:

проверка файловой системы Regin (через -reginfs);
проверка аномалий системных и пользовательских процессов;
сканирование распакованных SWF;
проверка дампа SAM;
проверка DoublePulsar - попытка выявить бэкдор , слушающий порты 445/tcp и 3389/tcp.

Чуть-чуть коснемся того, как программа определяет факт взлома. Типовыми признаками (Indicators of Compromise), свидетельствующими, что компьютер был скомпрометирован (то есть взломан), могут быть:

появление на компьютере вредоноса (вирусов, бэкдоров, крипторов, и так далее), а также хакерских утилит (например, для исследования сети, эксплуатации уязвимостей, сбора учетных данных);
появление неизвестных новых исполнимых и других файлов, даже если они не детектируются антивирусным движком как malware-код;
аномальная сетевая активность (подключение к удаленным хостам, открытие для прослушивания портов неизвестными программами и прочее);
аномальная активность на дисковых устройствах (I/O) и повышенное потребление ресурсов системы (CPU, RAM, Swap).

Перед началом инсталляции нужно доустановить несколько зависимых пакетов. Это colorama (дает расцветку строк в консоли), psutil (утилита проверки процессов) и, если еще не установлен, пакет Yara.

Итак, приступаем. Установка в (предварительно должен быть установлен пакет Yara, который по умолчанию уже установлен в Kali Linux):

cd Loki /

python2 loki - upgrader . py

python2 loki . py - h

Установка в Ubuntu/Debian:

sudo apt - get install yara python - yara python - pip python - setuptools python - dev git

sudo pip2 install -- upgrade pip

sudo pip2 install - U setuptools

sudo pip2 install psutil netaddr pylzma colorama

git clone https : //github.com/Neo23x0/Loki

cd / home / download / Loki

python2 loki - upgrader . py

python2 loki . py - h

Установка в BlackArch:

sudo pacman - S yara python2 - pip python2 - yara

sudo pip2 install psutil netaddr pylzma colorama

git clone https : //github.com/Neo23x0/Loki

cd / home / download / Loki

python2 loki - upgrader . py

python2 loki . py - h

Пример использования

Некоторые опции запуска:

optional arguments :

H , -- help show this help message and exit

В этом материале мы познакомимся с основными утилитами для Linux hardening. На русском языке это называется как-то вроде «проверка уровня защищенности Linux-систем и оценка корректности конфигов с точки зрения ИБ». Разумеется, мы не только сделаем обзор программ, но и приведем примеры их использования.

Сам себе аудитор, или безопасность собственными силами

Перед администраторами, а уж тем более перед аудиторами ИБ часто встают задачи проверить защищенность большого количества хостов за очень короткое время. И конечно, для решения этих задач в Enterprise-сегменте существуют специализированные инструменты, к примеру такие, как сетевые сканеры безопасности . Уверен, что все они - от open sources движка OpenVAS до коммерческих продуктов типа Nessus или Nexpose - известны нашему читателю. Однако этот софт обычно используется, чтобы искать устаревшее и потому уязвимое ПО и затем запустить патч-менеджмент . К тому же не все сканеры учитывают некоторые специфические особенности встроенных механизмов защиты Linux и других open sources продуктов. Ну и не в последнюю очередь значение имеет цена вопроса, ведь коммерческие продукты в состоянии позволить себе разве что компании, выделяющие под это дело бюджеты.

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

Практические аспекты аудита защищенности

Если посмотреть глазами аудитора, то подход к тестированию можно разделить на два типа.

Все, что относится ко второму подходу, принято называть специальным термином Hardening , что еще можно определить как «действия, направленные на усиление уровня исходной защищенности операционной системы (или программы) преимущественно штатными средствами».

Соответствие compliance-требованиям, как правило, проверяют при подготовке к прохождению обязательного аудита типа PCI DSS или другого сертификационного аудита. Мы же больше уделим внимание Hardening-составляющей. Все крупные разработчики предлагают для своих продуктов Hardening Guidelines - руководства, содержащие советы и рекомендации, как усилить защищенность, учитывая штатные механизмы безопасности и специфику софта. Так, подобные руководства есть у Red Hat , Debian , Oracle , Cisco .

INFO

Hardening - это термин из мира ИБ, который обозначает процесс обеспечения безопасности системы (программы) за счет снижения ее уязвимости и, как правило, с использованием только штатных утилит или механизмов защиты.

Sudo apt-get update sudo apt-get install lynis

И для RPM-ориентированных дистрибутивов (предварительно добавив соответствующие репозитории):

Yum install linus -y

Установка на macOS:

$ brew search lynis $ brew install lynis

Чтобы запустить Lynis, достаточно указать хотя бы один ключ. К примеру, для запуска всех имеющихся тестов следует указать ключ -c (check all, проверить все):

# Типовой набор тестов sudo lynis audit system # Полный набор тестов sudo lynis audit system -c # Сканирование удаленного хоста audit system remote

Перед аудитом всегда полезно проверить, доступна ли новая версия Lynis:

Lynis update info && lynis update check

У утилиты Lynis, помимо стандартного, существует еще один режим - непривилегированного запуска :

Lynis audit --pentest

Если же ты хочешь поместить имя аудитора, запустившего тестирование, просто добавь параметр -auditor :

Sudo lynis audit system -c -auditor Daddy

На любом этапе аудита процесс проверки может быть продолжен (Enter) либо принудительно прекращен (Ctrl+C). Результаты выполненных тестов будут писаться в журнал Lynis в /var/log/lynis.log . Учти, что журнал будет перезаписываться при каждом следующем запуске утилиты.

Для тестирования на систематической основе в автоматическом режиме можно назначить соответствующее задание в планировщик Cron с помощью ключа -cronjob . В таком случае утилита будет запускаться по заданному шаблону (конфигу) и не будет выводить никаких интерактивных сообщений, вопросов и предупреждений. Все результаты сохранятся в лог. К примеру, вот скрипт запуска утилиты с дефолтным конфигом раз в месяц:

#!/bin/sh AUDITOR="automated" DATE=$(date +%Y%m%d) HOST=$(hostname) LOG_DIR="/var/log/lynis" REPORT="$LOG_DIR/report-${HOST}.${DATE}" DATA="$LOG_DIR/report-data-${HOST}.${DATE}.txt" cd /usr/local/lynis ./lynis -c –auditor "${AUDITOR}" –cronjob > ${REPORT} mv /var/log/lynis-report.dat ${DATA} # End

Сохрани этот скрипт в каталог /etc/cron.monthly/lynis . И не забудь добавить пути для сохранения логов (/usr/local/lynis и /var/log/lynis), иначе возможна некорректная работа.

Можно посмотреть список всех доступных для вызова команд:

Lynis show commands

Особо любопытные могут глянуть настройки из конфига по умолчанию:

Lynis show settings

Краткий инструктаж по работе с утилитой:

Man lynis

Запуск отдельных тестов в Lynis

На практике бывает необходимо провести лишь некоторые тесты. К примеру, если твой сервак выполняет только функции Mail Server или Apache. Для этого мы можем использовать параметр -tests . Синтаксис команды выглядит следующим образом:

Lynis -tests "Test-IDs"

Если тебе сложно разобраться из-за большого количества идентификаторов тестов, то ты можешь использовать групповой параметр -test-category . С помощью данной опции Lynis запускает идентификаторы только тех тестов, которые входят в определенную категорию. Например, мы планируем запустить тесты брандмауэра и ядра:

./lynis -tests-category "firewalls kernel"

Помимо этого, функциональность Lynis расширяют различные плагины , которые можно дописывать самостоятельно, а можно подкладывать новые в существующую директорию.

Предложения по исправлению (Suggestions)

Все предупреждения (Warnings) будут перечислены после результатов. Каждое начинается с текста предупреждения, потом рядом в скобках указывается тест, который его сгенерировал. В следующей строке предлагается решение проблемы, если оно существует. По факту последняя строка - это URL-адрес, по которому ты сможешь посмотреть подробности и найти дополнительные рекомендации, как устранить возникшую проблему.

Профили

Профили, которые управляют аудитом, определяются в файлах с расширением .prf , расположенных в каталоге /etc/lynis . Профиль по умолчанию называется предсказуемо: default.prf . Разработчики не рекомендуют править его напрямую: любые изменения, которые ты хочешь внести в аудит, лучше добавлять в файл custom.prf , находящийся в том же каталоге.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!

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

Данная услуга включает в себя:

— Анализ версий ПО, установленного на сервере, на предмет соответствия текущим актуальным версиям, лишенных известных проблем с безопасностью. Как правило, для веб-серверов важна актуальность версий следующего ПО: почтовый сервер, веб-сервер, кэширующий веб-сервер (если такой присутствует), интерпретатор языка программирования (на котором написаны сайты, например, PHP), ftp-сервер, веб-приложения (для обеспечения упрощенного доступа к тем или иным настройкам сервера и работе с данными);
— Анализ настроек веб-сервера, настроек сопутствующего ПО на предмет соответствия основным требованиям, предъявляемым к безопасности;
— Анализ настроек операционной системы. По этому пункту идет анализ основных моментов, связанных с потенциальной возможностью для злоумышленника захватить контроль над сервером. Как правило, осматриваются настройки ssh-сервера, опций работы с жесткими дисками;
— Анализ прав доступа к основным файлам и папкам системы, содержащим конфиденциальную информацию. Как правило, в рамках этого пункта идет осмотр основных системных папок, файлов панели управления сервером, директории с резервными копиями, права на папки пользователей;
— На сервере, который находится под подозрением, что он скомпрометирован, и может использоваться злоумышленниками для ведения вредоносных действий, наши специалисты выполнят необходимые меры для того, чтобы очистить его от вредоносных программ, и предотвратить повтор данной ситуации;

Большинство таких корпоративных и многокомпонентных систем как SAP , Oracle DB используют в своей платформе операционную систему базирующийся на Linux . В виду этого к ним обращено такое пристальное внимание со стороны ИТ-аудиторов. Сегодня в статье мы представим вашему вниманию несколько бесплатных инструментов представленных в виде скриптов и использующих штатные механизмы ОС для провидения экспресс аудита конфигурации безопасности.

Ниже описанные системные команды и скрипты применяемые для экспресс аудита опций безопасности систем ОС Linux базируются на рекомендациях по проверке защищенности опубликованными сообществом ISACA в руководстве UNIX/LINUX Operating System Security Audit/Assurance Program .

1.Проверка учетных записей

1.1 Вывести список всех пользователей
Список пользователей хранится в файле /etc/passwdfile. Для получения списка пользователей можно использовать следующий скрипт:

bin/bash
# userslistinthesystem.sh
# count and Lists existing “real” users in the system.
echo “[*] Existing users (sorted alphabetically):”
grep ‘/bin/bash’ /etc/passwd | grep -v ‘root’ | cut -f1
-d’:’ | sort
echo -n “[*] Number of real users found: “
grep ‘/bin/bash’ /etc/passwd | grep -v ‘root’ | wc -l

1.2 Вывести список заблокированных учетных записей
В ходе аудита, необходимо проверить список заблокированных и разблокированных пользователей (accountName ). Для этого подойдет следующая команда:

#!/bin/bash
# passwd –s accountName

1.3 Просмотр статистики по всем пользователям

Аудитор должен убедиться, что команда ac включена в системе, для обзора деятельности пользователей:

#!/bin/bash

Для просмотра активности сеанса подключения пользователя с итогами за каждый день используйте команду:

#!/bin/bash
# ac -d

Для вывода информации, об активности сеанса (в часах) подключения пользователя «user» :

#!/bin/bash
# ac user

1.4 Просмотр активности пользователей
Системные приложения psacct или acct работают в фоновом режиме и отслеживают активность каждого пользователя в системе, а также потребляемые им ресурсы. Для проверки активности пользователей в системе запустите следующий скрипт:

#!/usr/bin/envksh
last -Fa|awk ‘
/wtmp begins/ { next; }
/still logged in/ { next; }
$0 == reboot { next; }
NF > 0 {
if(NR > 1)
printf (“
”);
printf (“ User:t%s
”, $1); # user
printf (“ Start:t%s %s %s %s
”, $3, $4, $5, $6);
if($9 == “down”)
printf (“ End:tshutdown
”);
printf (“ End:t%s %s %s %s
”, $9, $10, $11, $12);
if(substr ($NF, 1, 1) == “(“)
t = $NF;
h = “localhost”;
t = $(NF-1);
h = $NF;
gsub(“[()]”, “”, t);
printf (“ Time On:t%s
”, t);
printf (“Remote Host:t%s
”, h);

2. Проверка парольной политики

2.1 Учетные записи с пустым паролем
В ходе аудита, необходимо убедиться, что в системе отсутствуют или заблокированы учетные записи, позволяющие войти в систему без ввода пароля. Это правило можно проверить командой:

# cat /etc/shadow | awk -F: ($2==””){print $1}’

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

# vi /etc/pam.d/system-auth

2.3 Проверка срока действия пароля

В ходе аудита, необходимо проверить настройку срока истечения действия пароля. Чтобы проверить срок действия пароля необходимо использовать команду change. Эта команда выводит подробную информацию сроке действия пароля, а также о дате его последнего изменения.
Следующая команда служит для просмотра информации о «возрасте» паролей:

#chage -l username

Для изменения срока истечения пароля конкретного пользователя можно использовать команды указанные ниже:

#chage -M 60 username
#chage -M 60 -m 7 -W 7 userName

Параметры (для установки срока действия пароля):
-M – максимальный срок действия в днях.
-m – минимальный срок действия в днях.
-W – настройка предупреждения в днях.

2.4 Использование повторяющихся паролей
Настройки авторизации в систему должны соответствовать парольной политике. Файл содержащий историю паролей находится в /etc/security/opasswd. Для проверки необходимо выполнить следующие шаги:

для RHEL: открыть файл ‘/etc/pam.d/system-auth‘:

# vi /etc/pam.d/system-auth

для Ubuntu/Debian/Linux Mint: открыть файл ‘/etc/pam.d/common-password‘:

# vi /etc/pam.d/common-password

Добавить следующую строку раздел ‘auth’:

auth sufficient pam_unix.so likeauthnullok

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

Password sufficient pam_unix.so nullokuse_authtok md5 shadow remember=6

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

3. Настройки защищенного подключения
Протоколы удаленного подключения к системе Telnet и Rlogin весьма стары и уязвимы, из-за передачи пароля по сети в незашифрованном виде. Для уделенного и безопасного подключения должен использоваться защищенный протокол Secure Shell (SSH). Аудитору так же необходимо убедиться, что опция root login отключен, изменен SSH-порт по умолчанию, удаленный доступ разрешен только для конкретных авторизованных пользователей. Проверяемые настройки находятся в конфигурационном файле SSH:

1. # vi /etc/ssh/sshd_config

3.1 Вход в систему от имени суперпользователя (root login)

В ходе аудита, аудитор должен проверить запрет удаленного входа в систему с правами суперпользователя root.

# PermitRootLogin = yes
3.2 Проверка служебного аккаунта SSH login

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

Check your sshd_config settings (/etc/ssh/sshd_config) are correct one last time.

# PermitRootLogin without-password

# RSAAuthentication = yes

# PubkeyAuthentication = yes

3.3 Проверка списков доступа в DenyHosts и Fail2ban
В ходе аудита необходимо проверить настройки списков доступа DenyHosts и Fail2ban . Это скрипты, используемые для мониторинга и анализа журналов доступа по SSH и защиты от атак путем брутфорса паролей.

Особенности DenyHosts:

сохраняет и отслеживает журналы из файла /var/log/secure , отметив, все успешные и неудачные попытки входа, и фильтрует их.
осуществляет мониторинг неудачных попыток входа
отправляет по электронной почте уведомление о заблокированных хостах и подозрительных попытках входа

Особенности Fail2ban:

Сохраняет и отслеживает журналы из файлов /var/log/secure и /var/log/auth.log , /var/log/pwdfail
высоко настраиваемый и многопоточный
следит за файлами журналов на регулярной основе

4. Проверка системных журналов
В ходе аудита, необходимо убедиться, что запущен демон SysLog , а все значимые события происходящие в системе фиксируются в журналах событий. В ходе аудита также необходимо убедится, что политика хранения журналов событий учитывает требования действующего законодательства и политики безопаности

4.1 Журналы событий в Linux:

/var/log/auth.log – журнал системы авторизации (логины и механизм проверки подлинности).
/var/log/dpkg.log – журнал установки/удаления пакетов с использованием dpkg.
/var/log/yum.log – журнал установки/удаления пакетов с использованием yum.
/var/log/faillog – журнал неудачных попыток входа в систему и их предельного числа для каждой учётной записи.
/var/log/kern.log – журнал ядра, (подробный лог сообщений от ядра Linux).
/var/log/maillog или /var/log/mail.log – журнал почтового сервера.
/var/log/wtmp – журнал входа в систему (время регистрации и продолжительность работы всех пользователей системы).
/var/run/utmp – сведения о пользователях, зарегистрированных в системе в настоящее время.
/var/log/lastlog – записи о предыдущих входах в систему.
/var/log/boot – информация, которая регистрируется во время загрузки системы

5. Защита системных файлов

5.1 Защита загрузчика GRUB

Для защиты системного загрузчика GRUB, администратору необходимо использовать шифрование пароля в MD5 формате :

# grub-md5-crypt

После выполнения команды, администратору необходимо открыть файл /boot/grub/menu.lst или /boot/grub/grub.conf и добавить MD5-пароль:

# vi /boot/grub/menu.lst

# vi /boot/grub/grub.conf

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

5.2 Защита загрузочной директории /BOOT

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

В файле должна присутствовать строка:

LABEL=/boot /boot ext2 defaults,ro 1 2

5.3 Проверка открытых портов и активных соединений

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

#!/bin/bash
if (($(ps -ef | grep -v grep | grep $service | wc -l) > 0))
then
echo “$service is running!!!”
else
/etc/init.d/$service start
Fi

Просмотр сетевых соединений

# netstat -anop
или
# lsof -i(lsof -ni)
или
# iptraf

Прослушиваемые порты
При помощи команды Netstat, можно просмотреть все открытые порты и связанные с ними команды. Пример скрипта:

# netstat–tulpn
A script for port scanning is:
scan() {
if [[ -z $1 || -z $2 ]]; then
echo “Usage: $0 ”
return
fi
local host=$1
local ports=()
case $2 in
*-*)
IFS=- read start end <<< “$2”
for ((port=start; port <= end; port++)); do
ports+=($port)
done
;;
*,*)
IFS=, read -ra ports <<< “$2”
;; *)
ports+=($2) ;;
esac
for port in “${ports[@]}”; do
alarm 1 “echo >/dev/tcp/$host/$port” &&
echo “port $port is open” ||
echo “port $port is closed”
done
}

Межсетевой экран iptables

В ходе аудита, необходимо проверить конфигурацию брандмауэра Linux для предотвращения несанкционированного доступа. Для контроля трафика, в iptables должны быть созданы правила, которые будут фильтровать входящие, исходящие и пересылаемые пакеты с учетом IP адреса и номера TCP/UDP порта.

# iptables -n -L -v --line-numbers

ICMP/broadcast запросы

В ходе аудита, необходимо проверить, что системы настроены на игнорирование ping и широковещательных запросов. Для этого убедитесь, что в файле “/etc/sysctl.conf” добавлены следующие строки:

# игнорировать ICMP запросы:
net.ipv4.icmp_echo_ignore_all = 1
# игнорировать широковещательные запросы:
net.ipv4.icmp_echo_ignore_broadcasts = 1

5.4 Проверка установленных обновлений

В системы должны быть установлены последние обновления:

# yum updates
# yum check-update

6. Проверка автоматически выполняемых заданий CRON

Аудитор должен проверить кому разрешено и запрещено выполнять задания в cron. Доступ к cron контролируется c использованием файлов /etc/cron.allow и /etc/cron.deny.

# echo ALL >>/etc/cron.deny

7. Проверка форсированного режима безопасности SELINUX

В ходе аудита важно проверить статус SELinux . Данный механизм должен быть включен в системе.
Существует три режима SELinux :

Enforcing: политика SELinux включена принудительно. SELinux запрещает доступ, основываясь на правилах политики SELinux.
Permissive: политика SELinux не принудительна. SELinux не запрещает доступ, но запреты журнлируются как действия, которые были бы запрещены, если переключить политику в принудительный режим.
Disabled: SELinux отключен. Используются только дискретные правила DAC.

В ходе аудита, можно использовать следующий сценарий, чтобы проверить состояние SELinux или использовать команды system-configselinux, getenforce или sestatus:

ENABLED=`cat /selinux/enforce`
if [ “$ENABLED” == 1 ]; then
echo “SELinux is enabled, disable? (yes/no):”
read disable
if [ $disable == “yes” ]; then
echo “disabling selinux”
setenforce 0
fi
fi

Скрипт LBSA для проверки основных опций безопасности

LBSA (Linux Basic Security Audit script) - это базовый скрипт аудита конфигурации безопасности Linux-систем. Скрипт должен быть запущен из командной строки с привилегиям root, или в идеале запускаться по расписанию на регулярной основе с помощью планировщика cron для систематической проверки изменений конфигурации.

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

В настоящее редакции (Version 1.0.49), скрипт сканирует следующий опции:

уязвимости в настройках учетных записей
уязвимости в настройках SSH
уязвимости во временных каталогах и каталогов файловой системы загруженной в оперативную память (например, в /tmp, /var/tmp /dev/)
разрешения на файлы, состояние системных директорий
rконфигурацию сервисов DRBD и Hearbeat

Скрипт довольно большой, поэтому мы не стали его помещать на страницу.

Аудит доступа к файлам linux. Жесткая закалка Linux

Аудит безопасности Linux собственными силами

Практические аспекты аудита безопасности Linux

Инструменты аудита безопасности Linux

Lynis - auditing system hardening testing

Запуск отдельных тестов в Lynis

Профили

Оценка hardening state

Lunar - a UNIX security auditing tool

Nix Auditor - a CIS Audit made easier

Loki - Simple IOC and Incident Response Scanner

Сам себе аудитор, или безопасность собственными силами

Практические аспекты аудита защищенности

INFO

Запуск отдельных тестов в Lynis

Предложения по исправлению (Suggestions)

Профили

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте

Популярные статьи

Последние статьи

Разделы

Страницы

Спецпроекты

Контакты