На волне хайпа про РЖД я заметил, что много людей, даже из тех, кто "в теме", имеют странное представление о ситуации.

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

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

Эта статья — часть цикла о построении NAS, и написана под конкретный вид системы.

Резервное копирование — вторая основная задача, которую я хотел решить, используя NAS, после системы управления репозиториями.

Решение её затянулось...

Про данную тему уже написана масса статей и даже несколько книг, а в спорах об этом сломано много копий.

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

Одна из досадных проблем, которые встают при создании NAS, заключается в том, что не всякое программное обеспечение может работать с LDAP, а некоторое вообще не содержит механизмов аутентификации.

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

При наличии работоспособного NAS с докером, установка Gitlab не представляет особых сложностей.

Цикл статей назван "Построение защищённого NAS". Поэтому в данной статье будет рассматриваться повышение уровня защищённости. Также, будут описаны и те инструменты, которые я не использовал, но возможно применить.

Всякая система является компромиссом между безопасностью и удобством использования.

В построенном NAS, существовала серьёзная проблема: нельзя было перезагрузить систему, не присутствуя на месте, что понижало уровень доступности данных.

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

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

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

В предыдущей статье было описано проектирование программной платформы NAS.
Настало время её реализовать.

Статьи цикла:

1. Обзор материалов и литературы по NAS. По предложениям пользователей ссылки на материалы будут сведены в отдельную статью.
2. Выбор железа. Описан один из вариантов выбора железа и дан краткий обзор рынка домашних и офисных NAS систем.
3. Установка ОС, на которой будет строиться NAS. В отдельной статье описано дополнение, позволяющее отказаться ото всех файловых систем, кроме ZFS.
4. Проектирование поддерживающей инфраструктуры, которая будет лежать в основе всех сервисов NAS.
5. Реализация поддерживающей инфраструктуры.
6. Механизм аварийной удалённой разблокировки. Требуется для того, чтобы разблокировать систему, не имея к ней физического доступа.
7. Повышение защищённости NAS. Исправление ошибок, допущенных в предыдущих статьях и описание Hardening процесса.
8. Система контроля версий на базе Git. Установка Gitlab в контейнере.
9. Система резервного копирования. От регламента до установки ПО, где в качестве примера используется UrBackup.
10. Персональное облако. Обеспечивает хранение персональных файлов пользователя, обмен файлами между пользователями, а также интеграцию различных сервисов между собой.
11. Сквозная аутентификация контейнеров.
12. Управление файлами.
13. Библиотека.
14. Мультимедийная система 1: музыка.
15. Мультимедийная система 2: медиа сервер.
16. Фронтенд. Интерфейс, позволяющий быстро обращаться к сервисам.
17. Заметки про управление контейнерами.

Допустим, аппаратная часть NAS собрана и на неё установлена ОС, например, как показано здесь. И сейчас у вас есть работающий сервер с Debian, который загружается, подключен в сеть, и вы имеете к нему полный физический доступ.

Теперь надо спроектировать среду, позволяющую легко и безопасно добавлять, удалять прикладные сервисы, а также управлять их работой.

При написании статьи о разработке детектора аномалий я реализовывал один из алгоритмов, который называется "Инкрементальный растущий нейронный газ".

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

Итак, что же такое — алгоритм инкрементального растущего нейронного газа?

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

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

Небольшая заметка, в дополнение к статье о корневом разделе на ZFS.

Как в блогах, так и в журналах есть множество статей о том, как собрать NAS своими руками.
И с первого взгляда кажется, что при наличии прямых рук, свой NAS по всем пунктам бьёт покупное решение.
"Фигак, фигак и в продакшн", — и вот уже быстро, дёшево и качественно реализованное хранилище радует вас высокой производительностью и надёжностью.

Предисловие

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

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

Изучив, какие сейчас имеются ОС для решения данной задачи, я пришёл к выводу, что изо всего многообразия, наиболее развиты, широко используемы и, следовательно, проработаны, FreeNAS на основе FreeBSD и OpenMediaVault на основе Debian, созданный одним из разработчиков FreeNAS.

FreeNAS стабилен, удобен, гибок и вообще хорош, но попытавшись его поставить, вместо FreeBSD bsdinstall, я увидел совершенно урезанный инсталлятор, в котором я могу только выбрать диски и ввести пароль root: даже разметить диски нельзя.
GELI мне понравился больше cryptsetup на Linux, как и BSD-шный parted.
Попытавшись сделать root на шифрованном разделе, я понял, что эта задача нетривиальна, несмотря на то, что они уже используют root на ZFS.
Затем, пообщавшись, с сообществом FreeNAS, которые стали доказывать, что FreeNAS — не ОС, а приложение, я решил установить OMV.

К тому же, Debian — моя основная ОС и с Linux дела обещали быть проще...

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