- Small. Simple. Secure.
- Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.
- About
- Small
- Simple
- Secure
- Зачем забивать гвозди микроскопом, если есть Alpine Linux?
- Оно нам действительно надо?
- Хочется странного
- Про Alpine
- Приоткроем крышку
- Демоны под крышкой
- А еще
- Национальная библиотека им. Н. Э. Баумана Bauman National Library
- Персональные инструменты
- Alpine Linux
- Содержание
- История
- Особенности
- Установка
- Настройка основного функционала
- DHCP-сервер для локальной сети
- DNS-сервер для локальной сети
- Установка Snort
Small. Simple. Secure.
Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.
About
Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency.
Small
Alpine Linux is built around musl libc and busybox. This makes it smaller and more resource efficient than traditional GNU/Linux distributions. A container requires no more than 8 MB and a minimal installation to disk requires around 130 MB of storage. Not only do you get a fully-fledged Linux environment but a large selection of packages from the repository.
Binary packages are thinned out and split, giving you even more control over what you install, which in turn keeps your environment as small and efficient as possible.
Simple
Alpine Linux is a very simple distribution that will try to stay out of your way. It uses its own package manager called apk, the OpenRC init system, script driven set-ups and that’s it! This provides you with a simple, crystal-clear Linux environment without all the noise. You can then add on top of that just the packages you need for your project, so whether it’s building a home PVR, or an iSCSI storage controller, a wafer-thin mail server container, or a rock-solid embedded switch, nothing else will get in the way.
Secure
Alpine Linux was designed with security in mind. All userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities.
Источник
Зачем забивать гвозди микроскопом, если есть Alpine Linux?
По зову сердца и работе в Digital Design в качестве системного инженера, мне часто приходится сталкиваться с переусложненными программными продуктами и архитектурными конструкциями. Это вызывает страстное желание минимизации и упрощения всего, что попадается под руку, и приводит к восторгу от человеческих решений, просто делающих свою работу , без регистрации и смс .
Так я и познакомился с Alpine Linux.
Этот дистрибутив может вам понравиться по следующим причинам:
- Если вы любите минимализм и инструменты, ориентированные на выполнение поставленной задачи без лишних свистелок и украшений;
- Если вы заметили, что имеющиеся «мэйнстримные» дистрибутивы немного (?) раздуты и избыточны;
- Если вы захотели решить имеющуюся задачу простым способом.
Под «мэйнстримом» я подразумеваю тройку CentOS — Debian — Ubuntu (конечно же, ими мир не заканчивается), да простят меня все верующие в эти замечательные дистрибутивы. При их использовании, периодически, на границе восприятия, возникает колкая мысль – «а может быть можно проще?».
Оно нам действительно надо?
$ holywar mode disable
Неужели для решения вашей небольшой задачи требуется все это:
Замечательная systemd. Система инициализации (уже не совсем), которая может произвести впечатление системы управления шаттлом?
Подсистема журналирования / аудита, построенная на связке вроде journald → rsyslogd + auditd?
Можно догадываться, почему это сделано именно так, но действительно ли для моей простой задачи требуется такая цепочка?
Дублирование функциональности периодического выполнения задач как в systemd, так и в crond?
Сосуществование нескольких подсистем управления сетью в разных сочетаниях: классический networking / networkd / NetworkManager?
Сервисы вида tuned и firewalld?
Локальный почтовый сервис. Вы точно будете его использовать?
Раз уж мы вспомнили про минимализм, можно очень грубо сравнить наши дистрибутивы-лидеры в их минимальном варианте установки:
- Лидером избыточности по дисковому пространству и числу пакетов оказывается Ubuntu 18.04 (2,8 ГБ дискового пространства, 342 пакета, 31 активный сервис systemd, 15 процессов при входе). Семейство systemd тут представлено в максимальном объеме — systemd, networkd, timesyncd, resolved, logind, есть dbus.
- CentOS 7.5.1804 проигрывает по диску и числу пакетов, но лидер по вероятно-избыточным сервисам (1.1 ГБ дискового пространства, 299 пакетов, 34 активных сервиса systemd, 19 процессов при входе, среди которых — NetworkManager, firewalld, tuned, postfix, polkitd, auditd, journald + rsyslogd, dbus).
- Debian 9.4.0 пытались сильно не надувать: 940 МБ, 334 пакета, 25 активных сервисов systemd, 14 процессов при входе. Само собой, тут тоже есть systemd (а также journald, timesyncd и сопутствующий dbus), но без особого фанатизма в части управления сетью.
holywar: cannot change mode to ‘disable’: Permission denied
Хочется странного
От части перечисленного выше можно (попробовать) избавиться вручную, но вдруг все уже придумано за нас? В идеале, от дистрибутива серверной операционной системы общего назначения хочется видеть:
- Как ни странно, загрузчик, который дотянет нас до ядра;
- Само ядро ОС (в рассматриваемом случае — linux);
- Система инициализации, которую ядро запустит по готовности. Желательно, по простоте недалеко ушедшая от топора;
- Минимальный набор процессов, который запустит система инициализации. Ну например:
- Окончательная инициализация устройств и определение дополнительных параметров ядра;
- Обеспечение журналирования (можно с текстовыми журналами? Ну пожалуйста);
- Конфигурация сети (хорошо бы, с меньшим числом управляющих прослоек);
- Синхронизация времени (ntpd / chronyd);
- Несколько локальных консолей;
- Опционально — периодическое выполнение задач (сrond);
- Опционально — удаленный доступ к системе (sshd);
- Хорошо бы еще сохранять и восстанавливать конфигурацию межсетевого экрана.
И на этом почти все, остальное — дело менеджера пакетов. Меньше исполняемого кода и конфигурации – меньше багов, меньше багов – меньше багов. А система все также запущена и доступна по сети. Идея выглядит неплохо, теперь посмотрим, насколько близок к ней дистрибутив Alpine Linux.
Про Alpine
Чем может очаровать Alpine, особенно после CentOS? Отчаянным минимализмом!
Ну и, конечно, отсутствием необходимости сертификации «Linux Systemd Certified Voldemort».
Что сделали авторы:
- Понизили число используемых базовых компонентов;
- Выбрали модули поменьше и попрозрачнее;
- Упростили процесс конфигурирования системы.
- Чрезвычайно лаконичный процесс установки с использованием консольной утилиты setup-alpine;
- В качестве загрузчика взят extlinux из состава проекта syslinux;
- Небольшой инструмент сборки mkinitfs для создания временной файловой системы, используемой при загрузке;
- Система инициализации openrc с определением зависимостей между сервисами, уровнями запуска и щепоткой скриптования;
- Замена стандартной библиотеки GNU libc на более легковесную musl libc;
- Вместо пакета GNU coreutils большинство стандартных системных утилит в несколько урезанном исполнении входят в состав пакета busybox, который может быть Вам знаком по встраиваемым решениям;
- По умолчанию используется командный интерпретатор ash в составе busybox. Само собой, никто не мешает при необходимости поставить bash , ну и systemd ;
- Собственный пакетный менеджер apk и собственная инфраструктура распространения пакетов.
Кроме того, авторы реализовали ряд мер, ориентированных на повышение уровня защищенности базовой системы:
- Применили патчи ядра grsecurity/PaX (про их эффективность мнения расходятся, но все же); Уже нет, спасибо коллеге из комментариев. Как раз 26 июня вышла версия 3.8.0.
- Собрали пакеты с использованием режимов, снижающих вероятность эксплуатации ряда возможных уязвимостей.
В итоге мы получаем систему, снабженную рядом дополнительных механизмов защиты, позволяющую решить имеющуюся задачу и занимающую около 130 МБ. В запущенной системе установлен 41 пакет и выполняется 13 пользовательских процессов, можно стучаться по ssh.
И больше ничего. Осталось добавить то, что нужно вам (да и iptables с возможностью восстановления конфигурации при старте поставьте).
Приоткроем крышку
Обратите внимание – Alpine может пригодиться как учебная площадка при ознакомлении с ОС Linux! Увидеть логику работы компонентов субъективно проще, чем пытаться охватить сходу CentOS или Ubuntu:
- Загрузчик нашей установленной системы прост, его конфигурация влезает в 12 строк:
- Да и в /boot не слишком многолюдно:
- А вот и запущенный загрузчик без модных обоев:
- Ядро загружается, подхватывает initramfs, отрабатывает собственные шаги инициализации и вызывает команду init (которая, на самом деле, тоже идет в составе busybox). Init использует файл /etc/inittab:
- И тут в явном виде прописано, что нужно запустить для инициализации системы:
- Запустить 6 процессов getty, ожидающих на 6 виртуальных консолях локального входа пользователя.
- Запустить систему инициализации openrc для поочередного достижения требуемых уровней инициализации (openrc использует не классические уровни инициализации 0-6, а собственные уровни/группы sysinit — boot — default).
Далее состояние системы зависит от конфигурации openrc, а именно:
- Переменных, заданных в файлах каталога /etc/conf.d;
- Скриптов запуска, находящихся в каталоге /etc/init.d;
- Привязки скриптов запуска к «группам инициализации»:
Осталось прочитать скрипты запуска и обработать их с учетом уровней запуска и зависимостей.
Можем на примере syslog (/etc/init.d/syslog) посмотреть, как выглядит скрипт запуска openrc.
Как видите, это не всегда эти ваши нелюбимые «портянки»:
Переменные, используемые при выполнении скрипта, определяются в соответствующем файле /etc/conf.d/syslog. В нашем случае, в файле определена переменная SYSLOGD_OPTS=»-Z».
Обратите внимание — в скрипте декларативно определены зависимости данного сервиса.
Openrc честно перебирает в заданном порядке скрипты запуска, достигает уровня «default» — и вот она, рабочая система!
Демоны под крышкой
Что же именно скрывается под скриптами запуска openrc? Как ни странно — набор задач и демонов, перечисленных ниже.
Сначала, на уровне sysinit:
- dmesg — выставляется уровень журналирования для сообщений от ядра;
- devfs — монтируется и настраивается /dev;
- mdev — запускается менеджер устройств;
- hwdrivers — загружаются модули устройств на основе информации из /sys и /dev;
Следующим идет уровень boot:
- modules — загружаются модули ядра, перечень которых определен в /etc/modules;
- hwclock — настраиваются аппаратные часы реального времени;
- sysctl — задаются параметры ядра, определенные нами в /etc/sysctl.conf;
- swap — подключается swap-раздел;
- bootmisc — очищаются временные каталоги;
- urandom — настраивается генератор случайных чисел;
- keymaps — инициализируется раскладка клавиатуры;
- hostname — задается имя машины, которое определено в /etc/hostname;
- networking — поиск и инициализация интерфейсов с использованием информации из /etc/network/interfaces;
- syslog — запускается демон журналирования из состава busybox;
И наконец, уровень default:
- chrony — запускается NTP-сервис;
- crond — запускается сервис выполнения задач по расписанию;
- acpid — запускается сервис отслеживания событий питания;
- sshd — запускается сервис удаленного доступа.
Ура, после выполнения этих шагов система готова к работе! Не забудем и про зависимости от перечисленных выше сервисов, которые были заданы в init.d файлах:
- sysfs — монтирование /sys;
- fsck — проверка и исправление файловых систем;
- root — монтирование корневой системы на запись/чтение;
- localmount — монтирование всех файловых систем, перечисленных в /etc/fstab;
- klogd — журналирование событий ядра.
Открываем одну из локальных консолей, где нас поджидает getty, вводим логин, после чего передаем пароль процессу login и получаем доступ к запущенному командному интерпретатору ash (при запуске которого выполняется содержимое файлов /etc/profile, /etc/profile.d/* и
/.profile для подготовки пользовательского окружения).
Ура, никаких дополнительных сущностей (несомненно, полезных в ряде случаев, вроде PAM) — а мы в системе!
Осталось воспользоваться пакетным менеджером apk, и поискать нужные нам для нашей задачи пакеты. (Есть ли они там? Можно оценить это через веб-портал).
А еще
Дистрибутив Alpine не идеален, но его лаконичность меня действительно впечатлила, особенно в роли контейнера (всего 6 процессов — init, 4*getty, syslogd). Для меня он выглядит так, как должна выглядеть минимальная серверная операционная система (прости меня, CentOS!).
Кроме того, он вполне подходит на роль учебной площадки, позволяющей увидеть, из чего состоит современный дистрибутив, не погружаясь сразу в пучину whateverd-сервисов и многократного дублирования функциональности в великолепно-многоуровнево-конфигурируемых-средствах на все случаи жизни.
Источник
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Alpine Linux
Разработчик | Alpine Linux development team |
---|---|
Линейка ОС | UNIX-подобная |
Состояние разработки | Активное |
Исходный код | Open source |
Последний релиз | 3.5.1 / 26 January 2017 года ; 4 years ago ( 2017-01-26 ) [1] |
Целевой маркетинг | Developers, power users |
Доступно в | Многоязычие |
Cистема управления пакетами | APK |
Платформы | x86, x86-64, ARMhf, ARM (Advanced RISC Machine)#AArch64AArch64 |
Ядро (тип) | Монолитное ядро (Linux) |
Пользовательское пространство | BusyBox (GNU Core Utilities опциональны) |
По умолчанию пользовательский интерфейс | CLI (Command Line Interface) |
Официальный веб-сайт | alpinelinux .org |
Alpine Linux — некоммерческий Linux дистрибутив общего назначения, предназначенный для использования опытными пользователями, ценящими безопасность, простоту и эффективность. Девиз проекта — «Small. Simple» Secure.» Основан на musl и BusyBox, по умолчанию использует патчи ядра PaX и grsec, все пакеты компилируются с защитой от переполнения стека.
Содержание
История
Проект первоначально развивался как ответвление от LEAF Project [2] , чьей изначальной концепцией была разработка дистрибутива, который смог бы помещаться на одной 1.44MB дискете, тогда как разработчики пожелали включить более тяжеловесные пакеты (такие как Samba или Squid).
Особенности
- Маленький размер дистрибутива и скромные требования к железу. Alpine Linux ориентирован на использование во встраиваемых или серверных системах, поэтому включает в себя только самые необходимые компоненты.
- Два вида релизов – edge и stable. Edge-релиз постоянно существует в виде rolling release, получая самые свежие обновления по мере выпука пакетов, однако его стабильная работа не гарантируется разработчиками. Stable-релиз представляет из себя сборку последних стабильных версий всех пакетов (обычно раз в полгода) с поддержкой важных обновлений в течение 2 лет.
- Собственная система управление пакетами apk-tools, которая изначально была в коллекции скриптов shell scipts но позже была переписана разработчиками на C. Alpine на данный момент включает в себя такие пакеты как GNOME, Xfce, Firefox, и другие. Однако, некоторые пакеты, такие как KDE, пока ещё не портированы.
- По умолчанию, Alpine Linux во время запуска полностью [загружается в оперативную память].
- Патчи безопасности PaX и grsecurity включены по умолчанию в ядро Alpine Linux, что помогает защите от эксплойтов, похожих на vmsplice local root exploit. [3] Также все пакеты скомпилированы с защитой от переполнения стека.
- musl в качестве стандартной библиотеки языка Си. Первоначально Alpine Linux использовала uClibc вместо традиционной glibc. Однако, несмотря на легкий вес, у нее есть существенный очевидный недостаток — она бинарно несовместима с glibc. Таким образом, все программное обеспечение должно быть перекомпилировано с использованием uClibc для корректной работы. Однако, с 9 апреля 2014 года Alpine Linux использует библиотеку musl libc, которая является частично бинарно совместимой с glibc [4] .
- В качестве системы инициализации Alpine Linux использует OpenRC, в отличие от Debian, Ubuntu, RHEL или CentOS, которые используют systemd. [5]
- У Alpine Linux небольшое, но весьма дружелюбное сообщество, готовое прийти на помощь. Большинство основных разработчиков можно найти на IRC-каналах #alpine-linux или #alpine-devel для обсуждения ошибок или возникших проблем.
Установка
Процесс установки подробно описан на официальной вики проекта.
Также есть видео-инструкция по установке дистрибутива в VirtualBox:
Настройка основного функционала
DHCP-сервер для локальной сети
Данный процесс настройки сетевого протокола для локальной сети представлен в виде нескольких шагов. DHCP предназначен для автоматического присвоения IP-адресов сетевым устройствам. Его настройка на Alpine Linux происходит следующим образом:
1) Определите радиус IP-адресов для использования. Вы должны использовать “Частный радиус IP-адресов”, иначе могут возникнуть проблемы с передачей данных через вашу сеть. Для простой LAN, используйте 192.168.0.100, с маской подсети 255.255.255.0 и количеством хостов 50. Таким образом вы сможете подключить к вашей сети до 50 устройств без каких-либо изменений.
2) Сделайте IP-адрес вашего компьютера 192.168.0.2, с маской подсети 255.255.255.0 (адрес диапазона вашей сети, не входящий в адреса раздачи DHCP сервера).
3) Скачайте tftpd32 с сайта
4) Разархивируйте файл на ваш компьютер и запустите tftpd32.exe.
5) Нажмите на Settings.
6) Выберите вкладку DHCP в окошке Settings.
7) Установите IP pool starting address. Это будет являться первым IP-адресом вашей сети, который раздаст DHCP сервер. (192.168.0.100, если не уверены!)
8) Установите Size of pool на значение, чуть большее чем нужное для планируемых сетевых устройств в вашей сети. (Если сомневаетесь, поставьте 50)
9) Оставьте поле Boot File пустым.
10) Если в вашей сети присутствует DNS сервер или сервер, доступный одной из машин в вашей сети, то укажите его IP-адрес в поле WINS/DNS Server. Если нет или вы не знаете, что это означает, то оставьте поле пустым.
11) Установите маску подсети в Mask. Если вы знаете что это такое, то следуйте схеме адресов данной статьи и поставьте 255.255.255.0.
12) Не изменяйте поля Domain Name и Additional Option.
13) Нажмите на Save.
14) Ваш DHCP сервер готов к работе!
DNS-сервер для локальной сети
Самая стабильная и ресурсо-сберегающая связка, это linux+bind. Установим DNS-сервер Bind9:
Главные настройки находятся в файле (named.conf.options), отредактируем его:
Закомментированная секция forwarders, отвечает за то, куда будет передаваться DNS-запрос на разрешение имени. Вместо 0.0.0.0, нужно указать альтернативный DNS-сервер. Например 213.180.204.3 — yandex, 8.8.8.8 — google. После редактирования должно быть примерно так:
Сохраняем изменения и выходим (:wq). Перезапускаем сервер (sudo reboot) и проверяем:
В данном случае, сервер не является главным в обслуживании этой зоны (ya.ru). Cоздадим зону для сети, чтобы сопоставить ip-адреса компьютерам и сетевым устройствам. Зоны описываются в конфигурационном файле: named.conf.local
Добавим в него секцию:
Сохраняем изменения и выходим (:wq).
Зону мы обозначили, теперь настроим ее:
Редактируем до следующего вида:
Указать в нем адрес:
Сохраняем изменения и выходим (:wq).
Теперь разрешением имен в интернете будут заниматься DNS-сервера, указанные в секции forwarders.
1. Преобразование внутри сети:
2. Разрешение имен в интернете:
Установка Snort
Snort – облегченная система обнаружения вторжения . Snort обычно называют “обгегченным” NIDS, — потому что это он разработан прежде всего для маленьких сетей. Основной сайт для Snort — http://www.snort.org. Snort распространяется согласно лицензии GNU GPL. После загрузки архива, разархивируем его в каталог snort-1.7:
После загрузки libpcap, разархивируйте его подобным образом. Войдите в каталог libpacp, и выполните следующие шаги:
Теперь, мы компилируем Snort. Войдите в каталог, в котором находится Snort, и выполните следующие команду:
Snort теперь установлен на вашей машине. Создайте директорию, в которой Snort будет хранить файлы регистрации:
Источник