Цикл статей назван "Построение защищённого NAS". Поэтому в данной статье будет рассматриваться повышение уровня защищённости. Также, будут описаны и те инструменты, которые я не использовал, но возможно применить. Кто собирается атаковать систему и как он будет это делать? Обычно, это первый вопрос, на который требуется ответить, прежде чем говорить о безопасности.
По крайне мере, в случае NAS неявно такой ответ уже есть. Но для того, чтобы полностью ответить на данный вопрос, строят модель угроз и модель нарушителя. Компании закладывают этап моделирования угроз в свои циклы разработки.
У Microsoft для этого есть SDL, у людей есть и другие модели. Они предполагают использование определённых методик, таких как STRIDE или DREAD (STRIDE всё-таки более общий и неплохо поддержан инструментально). В STRIDE, например, модель строится от потоков данных и получается обычно большой, тяжёлой и мало понятной. Тем не менее, инструмент предоставляет список потенциальных угроз, что облегчает их рассмотрение. Модель угроз является закрытой информацией, потому что облегчает атакующему анализ системы и поиск слабых мест. Если он получает модель, ему не придётся строить её самостоятельно, ведь аналитики уже обо всём позаботились. Это была минутка рекламы.  Так строят модель серьёзные компании. И если это интересно, я могу как-нибудь описать в отдельной статье. Здесь же я опишу то, что по-английски называется "hardening" и займусь устранением недоработок безопасности, которые были допущены в процессе постройки системы. В основном, поддержание безопасности на данном уровне осуществляется за счёт закрытия известных уязвимостей системы, наблюдения за ней и периодической проверки. Что почитать: Ранее, был установлен zfs-autosnapshot. Он мне неоднократно помогал, т.к. я мог восстанавливать испорченные конфигурации (для Nextcloud, к примеру) из снэпшотов.
Однако, со временем, система начала притормаживать, а снапшотов расплодилось несколько тысяч. Выяснилось, что при создании родительской файловой системы для контейнеров, я забыл выставить флаг com.sun:auto-snapshot=false. В оригинальной статье данная проблема уже исправлена, здесь же я покажу, как избавиться от лишних снэпшотов. Сначала надо выключить zfs-auto-snapshot на родительской файловой системе докера: Теперь удалите неиспользуемые контейнеры и образы: Произведите удаление снэпшотов: И выключите их на всех файловых системах образов: Подробнее возможно почитать здесь. В прошлый раз был создан только один пользователь LDAP, обладающий администраторской ролью. Но большинству сервисов не требуется что-то изменять в базе пользователей. Потому, неплохо бы добавить пользователя только для чтения. Чтобы не заниматься созданием ролей вручную, возможно использовать скрипт инициализации контейнера. Сначала, добавьте в docker-compose.yml настройки для включения пользователя только для чтения: Полный файл под спойлером. Затем, надо сделать дамп и удалить: Чтобы сервер при восстановлении из дампа не ругался на дублирующиеся элементы, в файле надо удалить строки: И восстановить пользователей и группы: В базе появится такой вот зверь: Роли в конфигурации LDAP-сервера для него будут созданы контейнером.
Выполните проверки после восстановления и удалите бэкап: Удобным является разделение пользователей LDAP на группы, аналогичные POSIX группам в Linux.
Например, возможно создать группы, пользователи которых будут иметь доступ к репозиториям, доступ к облаку, либо доступ к медиатеке. Группы легко добавляются в phpLDAPAdmin, и я не буду на этом заострять внимание. Замечу лишь следующее:  В Docker уже почти всё сделано за вас.
По умолчанию он использует ограничение на системные вызовы, которое включено в ядре OMV: Здесь возможно почитать о базовых правилах безопасности Docker чуть подробнее.
Также, если будет включен AppArmor, Docker может интегрироваться с ним и пробрасывать его профили в контейнер. Сеть находится за роутером, но возможно проделать любопытное упражнение, изменив некоторые параметры сетевого стека так, чтобы ОС нельзя было опознать по ответам.
Реальной пользы от этого мало, ведь атакующий будет изучать баннеры сервисов и всё-равно поймёт, что за ОС вы используете. Загрузка настроек из sysctl.conf: И вот... Эти настройки требуется прописать в /etc/sysctl.conf, тогда при каждой перезагрузке они будут читаться автоматически. Более полезна защита от определения версий сервисов, для чего атакующий также может использовать Nmap: Но с маскировкой сервисов не всё гладко: Например, для SSH возможно добавить опцию DebianBanner no в /etc/ssh/sshd_confg. В результате: Лучше, увы, не получится: версия используется SSH для установления того, какие возможности поддерживаются, и сменить её возможно, только пропатчив сервер. Не самая известная техника защиты, позволяющая удалённому пользователю, знающему секрет, подключиться к закрытому порту.
Работа напоминает кодовый замок: все знают, что на сервере работают служебные демоны, но "их там нет", пока не набран код.
Например, для того, чтобы подключиться к серверу SSH, пользователю нужно постучаться на порты UDP 7000, TCP 7007, и UDP 7777.
После этого, с его IP файрволл будет пускать на закрытый TCP порт 22. Подробнее о том, как это работает, возможно почитать здесь. И в руководстве для Debian. Использовать не рекомендую, т.к. обычно достаточно fail2ban. Файрволл я настраиваю через Web GUI OpenMediaVault, что и вам рекомендую.  Открывайте необходимые порты, такие как 443 и 22, остальные — по вкусу. Также, желательно включить протоколирование отброшенных пакетов. Рискуя показаться банальным, я всё-таки напомню, что требуется: Почитать больше возможно, например здесь. Всё это легко делается из интерфейса OpenMediaVault через меню "Сервисы -> SSH".
За исключением того, что порт я не менял на нестандартный, оставив в локальной сети 22, и просто заменив порт в NAT роутера. После того, как это сделано, попытки несанкционированного входа будут производиться гораздо реже. Чтобы ещё улучшить ситуацию, возможно блокировать атакующих с определённых IP после нескольких попыток входа. Для чего могут быть использованы: Я использую fail2ban. Он будет производить мониторинг логов на предмет различных нежелательных действий со стороны определённых IP, и банить их, в случае превышения количества срабатываний: Бан производится через добавление правила файрволла. Через заданное время правило удаляется, и пользователь снова может попробовать авторизоваться. Изначально включен только SSH, но возможно включить контроль логов Web-сервера и других сервисов, хотя бы того же OMV.
А также, вынести наружу логи из контейнеров и натравливать fail2ban на них тоже. Рекомендую добавить сервисы по вкусу.
Подробнее о настройке вы можете почитать, например здесь или на родной Wiki. Маленькая утилита, которую стоит установить для удобства. Подсветит логи и покажет их в красивом виде.
Возможно использовать любую подобную утилиту, главное, чтобы были подсвечены ошибки и проблемные места логов так, чтобы их визуальный разбор был облегчён. Стоит установить и настроить logcheck просто для того, чтобы при выявлении проблем с настройкой, о которых сообщается в логах, вы сразу увидели это в почте.
Он неплохо помогает увидеть, что идёт не так, хотя и требует настройки. Установка: Сразу после установки он будет присылать отчёты. Видно, что здесь много лишнего, и дальнейшая настройка будет сводиться к его фильтрации. Сначала надо выключить hddtemp, который не работает корректно из-за не ASCII символов в названии SSD.
После исправления файла hddtemp, сообщения перестали приходить: Затем, возможно увидеть, что logcheck говорит о блокировании широковещательного трафика файрволом: Следовательно, нужно разрешить широковещательный трафик с роутера и контейнеров: Проверка logcheck: Наконец, становятся видны проблемы: Получается, что SAMBA не запускается. Действительно, анализ показал, что я замаскировал её через systemctl, а OMV пытается её запустить. Logcheck всё-равно будет спамить различными сообщениями.
Вот, например, zfs-auto-snapshot прошёл: В игнор: rrdcached тоже в игнор: Также, желательно убрать zed, если он до сих пор не убран: Ну и так далее. Многие считают, что logcheck достаточно бесполезная утилита.
Это действительно так, если использовать его, как нечто, что поставил и забыл. Тем не менее, если понимать, что logcheck всего-лишь настраиваемый фильтр логов, без эвристик, магии и адаптивных алгоритмов, вопрос о его нужности не возникает. Итеративно, разбирая то, что он присылает и, либо внося это в игнор, либо исправляя, постепенно возможно добиться информативных отчётов. Использовать для анализа автоматизированный инструмент гораздо лучше, чем прогонять логи через те же самые регулярные выражения руками, и часто лучше, чем использовать полноценную систему анализа данных, наподобие Splunk. Про logcheck и его настройку возможно почитать на Wiki Gentoo и здесь. Здесь я сошлюсь на свою же статью "Краткий анализ решений в сфере СОВ и разработка нейросетевого детектора аномалий в сетях передачи данных", в которой есть несколько примеров. Более полный обзор и сравнение подобных IDS вы можете почитать на Wiki. Сложный и большой скрипт для статического анализа известных брешей от RedHat.
Имеется его порт в Debian, который я рекомендую скачать и прогнать хотя бы раз. Процесс работы с данным скриптом примерно такой: Про RkHunter написано слишком много.
Используется давно, широко, до сих пор развивается. Есть в репозитории Debian. Модульный шелл-скрипт, выполняющий аудит системы и обнаружение вторжений.
В чём-то похож на STIG-4.
Может использовать сторонние утилиты для анализа логов, для обнаружения нарушения контрольных сумм. Состоит из большого количества разных модулей. Например, имеется модуль, который обнаруживает сервисы, использующие, удалённые файлы, что бывает, когда в процессе обновления системы библиотеки, используемые сервисом были изменены, но сервис по каким-то причинам не был перезапущен. Есть модули для поиска служебных пользователей, которые более не используются, проверки системы на отсутствие патчей безопасности, проверки umask и т.д. Подробнее в man. Уже лет 10 не развивается (да, не я один забрасываю софт). Типичный HIDS, который может: Плюс, у него есть централизованный мониторинг с Web-интерфейсом и централизованная отправка логов на сервер.
Обычно же его используют для проверки того, не изменились ли системные бинарные файлы между обновлениями.
При обновлении операционной системы база сигнатур перестраивается. Естественно, в идеале, базу надо хранить на другой машине и периодически выполнять оффлайновые проверки. Конечно, база подписана, но при работающей машине, если атакующий перехватывает управление, ему никто не мешает подменить результат выдачи подобных систем. Когда-то давно я использован данную HIDS: это не очень удобно и требует приложения усилий.
Проблема здесь не в Samhain, а в самом классе подобных систем. Почти тоже самое, что и Samhain, но Tripwire — это уже Серьёзный бизнес.
Поддерживается достаточно большой компанией, имеет корпоративную версию. Утилита от автора RkHunter. Частично проприетарная, но имеет бесплатную версию.
На домашней странице есть небольшое сравнение её с несколькими другими системами.
Похожа на Tiger и выполняет примерно ту же самую работу, но в отличие от него, поддерживается автором.
Использовать или нет, решайте сами. В одном из руководств, ссылки на которые приведены в начале статьи, Lynix используется вместе с Tripwire. Название говорит само за себя. Утилита для поиска руткитов.
Вкратце: Имеет достаточно внушительный список обнаруживаемых руткитов. Система для определения повышения привилегий процесса для Linux. Не путайте с системой сборки ninja-build. Запускается, как демон и следит за процессами. Если процесс запускается с нулевыми UID/GID, Ninja записывает сведения о нём в лог, и если он запущен от неавторизованного для этого пользователя, может убить его (процесс, с пользователем придётся разбираться потом, самостоятельно).
Часть исполнимых файлов может быть включена в белый список (например, su).
Авторизованными являются пользователи, которые входят в заданную группу.  Есть в репозиториях Ubuntu, которые легко подключаются в Debian. Не буду останавливаться на этой теме подробно. Тема слишком обширная. Сканеры требуются для того, чтобы проверить защищённость системы, действуя теми же инструментами, что и атакующий.
В случае базовых проверок вполне достаточно Nmap и W3af для Web-сервисов. В Linux реализована избирательная (она же дискреционная) модель доступа.
Но моделей доступа известно около десяти. Из них, кроме дискреционной также распространены ролевая и мандатная. Приведённые ниже системы, в основном, частично реализуют последнюю, местами с зачатками ролевой.  Подробнее о всех трёх возможно почитать в цикле статей "Безопасный Linux" от IBM. В NAS я пока не использовал ни одной из них, но планирую включить AppArmor.
Нельзя сказать, что данные системы очень сильно повышают безопасность, но они сужают поверхность атаки.
Конечно, от выхода из песочницы браузера через баг в системном вызове, с возможностью записи в адресное пространство ядра они не спасут, но от злонамеренных действий в пользовательском пространстве могут помочь. Первый вариант системы мандатного контроля, зависимый от возможностей файловой системы.
Конечно же, ZFS поддерживает списки контроля доступа в полном объёме. Настраивать ACL достаточно муторно и они, скорее, используются для тонкого разграничения доступа, чем для защиты. Но этот механизм модель мандатного контроля доступа вполне реализует. В отличие от EXT систем, в ZFS управление ACL реализуется не через отдельные утилиты setfacl/getfacl, а через стандартные chmod и ls.  Система мандатного контроля доступа на основе путей к файлам. Процессы, которые идентифицируются на основе путей к их исполнимым файлам, передаваемым в системный вызов exec, контролируются системой, при использовании ими системных вызовов open, exec и подобных.
Данным вызовам передаются пути к файлам, с которыми хочет работать процесс.
AppArmor проверяет, разрешён ли процессу доступ по этим путям.
Если нет, то системный вызов будет возвращать ошибку.
Также может устанавливать процессу capabilites. Процессы описываются текстовыми файлами профилей, которые объединены в базу. Имеется режим обучения для быстрого создания профиля, когда процесс анализируется, и в профиль записываются все пути, которые он использовал. Видно, что профиль не обязательно должен описывать всё, т.к. имеет возможность для подключения абстракций. Также, стоит заметить, что пользователь может легко дополнять профиль в отдельном конфигурационном файле (local/bin.ping), не трогая те настройки, которые идут вместе с пакетом. Штатный вариант для многих deb-based систем.
И ещё он интегрируется с firejail, что позволяет усилить изоляцию. Я его использую на рабочих системах, изредка дополняю базу, исправляю правила и отправляю им патчи. Про использование в Debian, есть руководство.  Система мандатного контроля доступа.
Подарок от NSA, про работу с которым в Debian описано в официальном руководстве. Центральным понятием SELinux является модель "принудительного исполнения" (type enforcement).  Все пользователи, файлы, процессы, сетевые ресурсы и прочее имеют SELinux метки. Одним из компонентов метки является "тип". Например, браузер может быть запущен, с меткой firefox_t.
SELinux просто даёт возможность сопоставить метки приложений с метками ресурсов, к которым они имеют доступ. Пример: Что просто даёт возможность браузеру, запущенному, как firefox_t читать и писать в файлы в вашем домашнем каталоге, помеченном, как user_home_t. Пример: Правило даёт типу user_t возможность создавать, читать, писать и удалять файлы с типом user_home_t. Тип user_t, скорее всего, имеет пользователь. Метки, роли и типы составляют контекст безопасности. Важным отличием от подобных AppArmor систем-песочниц, является то, что контекст безопасности, сохраняется при переносе файла между разными файловыми системами. Первое поле — SELinux user. Второе и третье — роль и тип, соответственно. Четвёртое — необязательное поле MLS диапазона. Например, файлы в вашем домашнем каталоге, вероятно помечены, как user_home_t. user_home_t — это тип, и политика будет считать все файлы с данным типом, относящимися к вашему домашнему каталогу. Как становится понятно из вышесказанного, настройка такой системы весьма муторна и требует скрупулёзности.
Но существует обширная база политик. Потому, большинство типовых действий (например, разрешение Самбе шарить домашние каталоги), выполняются несколькими простыми командами. Также, как в AppArmor, имеется permissive режим, в котором приложениям разрешается обращаться к ресурсам, но все обращения логируются.
Это позволяет затем создать профиль для приложения.
Отличием является то, что данный режим включается на всю систему, тогда как в AppArmor его возможно избирательно переключать для конкретных приложений. Небольшое вводное описание по SELinux есть на Хабре.
И чуть более подробное.
Для просветления читать курс от IBM. Сложный и на Debian как-то не прижился. Последний раз, когда я его проверял, он ломал систему.
Вообще, эта система (уже давно не патч к ядру), — наследие Gentoo. У них там всё просто: hardening делается несколькими командами. Впрочем, как и установка ОС. Есть руководство для Debian о том, как использовать симбиоз GrSecurity и PaX. Tomoyo в Debian описан в небольшом руководстве. Система мандатного контроля доступа на основе имён файлов. Похож на AppArmor, но менее распространён. Развивается с 2003 года.
Тот же принцип, тоже есть обучающий режим, сходные инструменты.
Конфигурационные файлы менее структурированы, по сравнению с AppArmor, ну и база профилей меньше. По старой памяти раньше убирали лишнее из /etc/securetty для того, чтобы root мог входить только с определённых терминалов (обычно локальных), но сейчас в этом особого смысла уже нет. Сейчас подобные механизмы безопасности реализуются через PAM, а конфигурацию их возможно найти в /etc/security. Вместо таких сложных пакетов, как Samhain и Tripwire, часто бывает достаточно маленькой утилитки debsums, которая проверяет контрольные суммы установленных бинарников. Статья получилась достаточно объёмной. И хотя многое не рассказано, затягивать её выход больше желания нет. Как всегда, конфигурация и прочее доступны в моём Github репозитории, который постепенно дополняется. Технарь-психопат