SELinux и AppArmor: что делать, если приложение не запускается.
SELinux и AppArmor - это механизмы принудительного контроля доступа (MAC), которые ограничивают возможности процессов на уровне системы, даже если они запущены от root.
Проблемы часто проявляются, когда веб-сервер не может открыть нужные файлы или служба отказывается стартовать. В таких случаях именно эти системы безопасности могут быть причиной сбоя.
Как определить причину:
- Для SELinux можно использовать команды
- Для обоих механизмов стоит проверять логи:
Исправление для SELinux:
Если доступ нужно разрешить, создайте локальный модуль политики с помощью
Так вы добавите разрешение только для конкретного действия, не отключая SELinux полностью.
Исправление для AppArmor:
Отредактируйте профиль приложения в
Отключение SELinux или AppArmor полностью снижает уровень безопасности. Правильнее адаптировать конкретные правила под нужное приложение.
#learn
SELinux и AppArmor - это механизмы принудительного контроля доступа (MAC), которые ограничивают возможности процессов на уровне системы, даже если они запущены от root.
Проблемы часто проявляются, когда веб-сервер не может открыть нужные файлы или служба отказывается стартовать. В таких случаях именно эти системы безопасности могут быть причиной сбоя.
Как определить причину:
- Для SELinux можно использовать команды
ls -Z для файлов и ps -Z для процессов, чтобы увидеть их метки безопасности.- Для обоих механизмов стоит проверять логи:
/var/log/audit/audit.log для SELinux и journalctl для AppArmor. Ищите сообщения об отказе в доступе.Исправление для SELinux:
Если доступ нужно разрешить, создайте локальный модуль политики с помощью
audit2allow:# Найти ошибки и сформировать модуль
grep "avc: denied" /var/log/audit/audit.log | audit2allow -M mymodule
# Установить модуль
semodule -i mymodule.pp
Так вы добавите разрешение только для конкретного действия, не отключая SELinux полностью.
Исправление для AppArmor:
Отредактируйте профиль приложения в
/etc/apparmor.d/ , добавив необходимые разрешения для файлов, сетевых соединений или процессов. После изменений перезагрузите профиль командой:apparmor_parser -r /etc/apparmor.d/имя_профиля
Отключение SELinux или AppArmor полностью снижает уровень безопасности. Правильнее адаптировать конкретные правила под нужное приложение.
#learn
Forwarded from Типичный Сисадмин
Как потерять сервер, просто переподключив сессию. Гайд по потере связности от первого лица 🤙
На Хабре вышел лонгрид, который читается как сценарий ночного кошмара любого админа. Автор, находясь в Москве, полностью потерял управление над своим сервером в Казани, и виной тому стала фатальная цепочка событий... срабатывание фильтров по ключевым словам, собственное губительное любопытство и бюрократический ад регистратора.
Всё началось с того, что автоматика регулятора, судя по всему, начала отрабатывать блокировку по сигнатурам в доменных именах. Автор имел неосторожность держать сервисные поддомены вида😬 ... имея активную, чудом выжившую сессию через Cisco SSL VPN, он решает проверить гипотезу и своими руками разрывает соединение. Обратно, разумеется, его уже не пустило. Классическая ошибка выжившего... никогда не рубите единственный линк, на котором сидите, даже ради диагностики, если у вас нет обходного пути для доступа.
Но дно было еще впереди. Пока Автор пытался пробить стену блокировок, удар в спину нанес регистратор😭 . Причина в несовпадение анкетных данных, которые криво передал партнер-реселлер (перепутанные поля ФИО и адреса). В одну секунду инфраструктура превратилась в ничто... легли NS-сервера, перестала ходить корпоративная почта, отвалились SSL-сертификаты. Процесс восстановления превратился в сюрреализм с требованием подписать кабальные бумаги о возмещении убытков регистратору и бесполезной верификацией через Госуслуги, пока техподдержка отвечала скриптами раз в восемь часов.
Спасло ситуацию только чудо в виде забытой тестовой виртуалки, которая торчала наружу через чистый SSH и не попала под раздачу. Через неё удалось прокинуть туннель с помощью🥳
Итого... получается, использовать в 2026 году слова
Типичный🥸 Сисадмин
На Хабре вышел лонгрид, который читается как сценарий ночного кошмара любого админа. Автор, находясь в Москве, полностью потерял управление над своим сервером в Казани, и виной тому стала фатальная цепочка событий... срабатывание фильтров по ключевым словам, собственное губительное любопытство и бюрократический ад регистратора.
Всё началось с того, что автоматика регулятора, судя по всему, начала отрабатывать блокировку по сигнатурам в доменных именах. Автор имел неосторожность держать сервисные поддомены вида
vpn.domain.ru и vpn-kg.... Система фильтрации, увидев триггер (vpn) в SNI на 443 порту, начала дропать SSL-хендшейки. И здесь админ совершает ошибку, за которую в приличном обществе бьют патч-кордом Но дно было еще впереди. Пока Автор пытался пробить стену блокировок, удар в спину нанес регистратор
REG.RU, внезапно сняв домен с делегирования Спасло ситуацию только чудо в виде забытой тестовой виртуалки, которая торчала наружу через чистый SSH и не попала под раздачу. Через неё удалось прокинуть туннель с помощью
sshuttle и вернуть управление Итого... получается, использовать в 2026 году слова
vpn, proxy или shadowsocks в именах хостов - это уже технический суицид. А критическую инфраструктуру (DNS, почта, шлюзы и тд.) неплохо бы разнести по разным доменам и регистраторам.Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
This media is not supported in your browser
VIEW IN TELEGRAM
Иногда я жалею, что не застал времена DOS. Это было интересное время. Наше поколение может увидеть это только в эмуляторе.
Хотя, возможно, кто-то из подписчиков застал DOS-овые времена.
Хотя, возможно, кто-то из подписчиков застал DOS-овые времена.
🥰4❤1👍1
Монтирование файловых систем через systemd
Многие по инерции продолжают использовать /etc/fstab, хотя systemd давно предоставляет собственный механизм монтирования. Он гибче, безопаснее при загрузке и лучше подходит для современных сценариев - особенно для сетевых и условных ресурсов.
Почему systemd-монтирование практичнее fstab
Пример 1. Локальный диск, монтирование в /mnt/backup
Создаем mount-юнит
Файл
Подготовка устройства
Активация монтирования
После этого диск будет монтироваться как обычный systemd-юнит, без участия fstab.
Пример 2. NFS с автомонтированием через VPN
Для сетевых ресурсов предпочтительнее использовать .automount. Такой юнит подключает ресурс только при обращении и отмонтирует его при простое.
Файл
Файл
Включение автомонтирования
Поведение в итоге:
При загрузке системы NFS не монтируется
При первом доступе к /mnt/backup происходит подключение ресурса через VPN
При остановке openvpn@client.service или простое NFS автоматически отмонтируется
Такой подход дает предсказуемость, ускоряет загрузку и снижает количество проблем с сетевыми хранилищами.
#learn
Многие по инерции продолжают использовать /etc/fstab, хотя systemd давно предоставляет собственный механизм монтирования. Он гибче, безопаснее при загрузке и лучше подходит для современных сценариев - особенно для сетевых и условных ресурсов.
Почему systemd-монтирование практичнее fstab
1) Ленивое монтирование
Ресурс подключается только в момент обращения. При простое может автоматически отмонтироваться по таймауту.
2) Автоматическое создание каталогов
systemd сам создает точку монтирования. Нет необходимости вручную следить за наличием директорий.
3) Отсутствие блокировок при загрузке
Если устройство или сеть недоступны, система не зависает на старте, как это часто бывает с fstab.
4) Четкие зависимости
Можно указать, что монтирование допустимо только после запуска VPN, сети или конкретного сервиса.
Пример 1. Локальный диск, монтирование в /mnt/backup
Создаем mount-юнит
Файл
/etc/systemd/system/mnt-backup.mount[Unit]
Description=Disk for backups
[Mount]
What=/dev/disk/by-uuid/19e2b459-058a-46f8-aadf-b696acb13233
Where=/mnt/backup
Type=ext4
Options=defaults
[Install]
WantedBy=multi-user.target
Подготовка устройства
cfdisk /dev/sdb # разметка диска
mkfs -t ext4 /dev/sdb1 # создание файловой системы
blkid # получение UUID
Активация монтирования
systemctl daemon-reload
systemctl start mnt-backup.mount
systemctl enable mnt-backup.mount
После этого диск будет монтироваться как обычный systemd-юнит, без участия fstab.
Пример 2. NFS с автомонтированием через VPN
Для сетевых ресурсов предпочтительнее использовать .automount. Такой юнит подключает ресурс только при обращении и отмонтирует его при простое.
Файл
/etc/systemd/system/mnt-backup.mount[Unit]
Description=NFS share
[Mount]
What=srv.example.com:/backup/nfs_share
Where=/mnt/backup
Type=nfs4
Options=rw
TimeoutSec=15
Файл
/etc/systemd/system/mnt-backup.automount[Unit]
Description=NFS share
Requires=network-online.target
BindsTo=openvpn@client.service
After=openvpn@client.service
[Automount]
Where=/mnt/backup
TimeoutIdleSec=60
[Install]
WantedBy=graphical.target
Включение автомонтирования
systemctl daemon-reload
systemctl enable --now mnt-backup.automount
Поведение в итоге:
При загрузке системы NFS не монтируется
При первом доступе к /mnt/backup происходит подключение ресурса через VPN
При остановке openvpn@client.service или простое NFS автоматически отмонтируется
Такой подход дает предсказуемость, ускоряет загрузку и снижает количество проблем с сетевыми хранилищами.
#learn
👍4
Forwarded from Типичный Сисадмин
Если в далеком 2018 году попытка заблокировать Telegram напоминала стрельбу из пушки по воробьям, когда вместе с мессенджером ложились подсети Амазона, Гугла и половина умных чайников страны, то в 2026 году мы наблюдаем работу совсем другого уровня. РКН официально подтвердил курс на последовательные ограничения, перестав играть с IP-адресами и перейдя к стратегии QoS, только с обратным знаком
По тактике пользователь должен страдать не от отсутствия связи, а от её качества, и добровольно уйти туда, где картинки грузятся быстро
Философски мы наблюдаем окончательный слом парадигмы глобальной Сети. Интернет, который задумывался как децентрализованная система, устойчивая к ядерному удару, оказался бессилен перед централизацией, получившей контроль над физикой прохождения сигнала. Мы входим в эру Матрицы, где реальность пользователя определяется не его желанием, а политиками на пограничном шлюзе. Большинству, у кого нет навыков туннелирования, предложат синюю таблетку - комфортный, быстрый, но стерильный интранет с отечественными сервисами и веселыми картинками. А красная таблетка...
Некоторым из Сисадминов стоит приготовиться к очередной перестройке инфры. Бизнес не откажется от Телеги... слишком глубоко она проникла в процессы, от алертов мониторинга до чатов продаж... получается, нагрузка на корпоративные шлюзы и каналы вырастет кратно.
Эпоха интернета заканчивается и судя по официальным заявлениям, отката к прежней скорости ждать не стоит
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
😱1
Forwarded from Типичный Сисадмин
Пока хипстеры переписывали свои конфиги на WireGuard, деды из OpenVPN выкатили мажорный релиз 2.7. И судя по чейнджлогу, хоронить классику энтерпрайз-VPN еще очень рано.
Главная киллер-фича - полноценная поддержка Data Channel Offload. Если раньше OpenVPN работал поверх ядра и постоянно переключал контекст процессора (что убивало скорость), то теперь обработку данных можно спихнуть прямо в ядро Linux (модуль
ovpn уже в ядре 6.16).📊 Результат на картинке. Обычный
tun выдает 370 Мбит/с, а новый ovpn-dco 2950 Мбит/с. Прирост почти в 10 раз. WireGuard, ты там как, нормально? Что еще вкусного:
wintun, теперь по дефолту win-dco. Плюс служба теперь запускается без админских прав, что сильно возрадует безопасников Релиз получился монументальный... если у вас корпоративный стандарт всё еще OpenVPN, то жизнь стала сильно лучше. Осталось только дождаться, когда DCO-модуль доедет до стабильных ядер дистрибутивов, и можно будет забыть про тормоза.
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
3 практических метода усилить безопасность MikroTik
Безопасность роутера строится не на одной "магической" настройке, а на комбинации мер: защита управления, минимизация поверхности атаки и контроль входящего трафика. Ниже три рабочих механизма, которые реально снижают риск компрометации.
Многоступенчатая защита от перебора паролей Winbox и SSH
Мгновенный
Автоматизированные брутфорс-боты создают серию TCP-сессий и быстро попадают в финальный
Результат - автоматическая фильтрация массовых атак без постоянного ручного контроля.
Сужение зоны доступа к управлению и отключение лишних сервисов
Каждый активный сервис увеличивает поверхность атаки. Если сервис не используется - он должен быть выключен. Управление устройством не должно быть доступно из произвольных внешних сетей.
Пример базовой минимизации:
Ограничение management только доверенными подсетями резко снижает вероятность удаленной эксплуатации уязвимостей и перебора учетных данных.
Контроль ICMP и базовая защита от перегрузки
Полное отключение ICMP ломает диагностику и мониторинг. Грамотнее ограничить интенсивность входящих запросов. Это уменьшает эффект ping-flood и защищает CPU роутера от избыточной обработки пакетов.
Такой механизм позволяет сохранить доступность диагностики, одновременно снижая нагрузку при простых DoS-попытках.
Эти три подхода закрывают основные векторы атак на публичный MikroTik: перебор учетных данных, избыточно открытые сервисы и примитивные flood-атаки. В совокупности они дают ощутимый прирост устойчивости без усложнения конфигурации.
#learn
Безопасность роутера строится не на одной "магической" настройке, а на комбинации мер: защита управления, минимизация поверхности атаки и контроль входящего трафика. Ниже три рабочих механизма, которые реально снижают риск компрометации.
Многоступенчатая защита от перебора паролей Winbox и SSH
Мгновенный
drop не всегда оптимален. Эффективнее использовать эскалацию блокировок через address-list. Логика простая: каждая новая попытка подключения увеличивает срок изоляции источника.Автоматизированные брутфорс-боты создают серию TCP-сессий и быстро попадают в финальный
blacklist. При этом администратор, ошибившийся один раз, не будет заблокирован на сутки./ip firewall filter
add chain=input protocol=tcp dst-port=22,8291 connection-state=new \
action=add-src-to-address-list address-list=stage1 address-list-timeout=1m
add chain=input protocol=tcp dst-port=22,8291 src-address-list=stage1 \
action=add-src-to-address-list address-list=stage2 address-list-timeout=10m
add chain=input protocol=tcp dst-port=22,8291 src-address-list=stage2 \
action=add-src-to-address-list address-list=blacklist address-list-timeout=1d
add chain=input src-address-list=blacklist action=drop
Результат - автоматическая фильтрация массовых атак без постоянного ручного контроля.
Сужение зоны доступа к управлению и отключение лишних сервисов
Каждый активный сервис увеличивает поверхность атаки. Если сервис не используется - он должен быть выключен. Управление устройством не должно быть доступно из произвольных внешних сетей.
Пример базовой минимизации:
/ip service disable ftp
/ip service disable www
/ip service set winbox address=192.168.88.0/24
/ip service set ssh address=192.168.88.0/24
Ограничение management только доверенными подсетями резко снижает вероятность удаленной эксплуатации уязвимостей и перебора учетных данных.
Контроль ICMP и базовая защита от перегрузки
Полное отключение ICMP ломает диагностику и мониторинг. Грамотнее ограничить интенсивность входящих запросов. Это уменьшает эффект ping-flood и защищает CPU роутера от избыточной обработки пакетов.
/ip firewall filter
add chain=input protocol=icmp limit=5,10 action=accept \
comment="Allow limited ICMP"
add chain=input protocol=icmp action=drop \
comment="Drop excessive ICMP"
Такой механизм позволяет сохранить доступность диагностики, одновременно снижая нагрузку при простых DoS-попытках.
Эти три подхода закрывают основные векторы атак на публичный MikroTik: перебор учетных данных, избыточно открытые сервисы и примитивные flood-атаки. В совокупности они дают ощутимый прирост устойчивости без усложнения конфигурации.
#learn
👀1
Forwarded from Типичный Сисадмин
Пока мир сходит с ума и люди заваливают друг друга розовыми сердечками, нормальные инженеры отмечают настоящий праздник - День компьютерщика. Именно в этот день, 14 февраля 1946 года, человечеству показали ENIAC I. И это был первый реально работающий электронный монстр, который перевернул игру.
Романтика того времени была суровой... машину строили не для лайков в соцсетях, а на деньги американской армии для расчета баллистических таблиц артиллерии и авиации. До появления ENIAC должность Computer (или Вычислитель) занимали живые люди, которым приходилось вручную перемалывать тонны данных. Железный предок весил 27 тонн, жрал 150 кВт энергии и заменил собой целый штат сотрудников, подарив нам ту самую двоичную систему счисления, на которой теперь держится вся наша цифровая цивилизация, которая уже успела докатиться до... ладно, не в этот день
И чтобы два раза не вставать
Так что, коллеги, обнимите сегодня свой сервер (или ноутбук, как Столлман), он греет лучше, чем картонное розовое сердце
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Типичный Сисадмин
Тут в Токио на Linux Plumbers Conference подняли тему, которая болит у каждого, кто хоть раз пытался разобрать 😰
В качестве решения предлагают переходить на компактные форматы типа CTF или SFrame. Идея в том, чтобы облегченные таблицы символов, необходимые для построения стек-трейсов и профилирования, весили мало и всегда были загружены в память вместе с ядром. Представьте мир, где утилиты мониторинга работают сходу, без танцев с бубном и подключения
Идея здравая🥳
Типичный🥸 Сисадмин
vmcore или запустить профайлер на проде. Один участник зачитал доклад о том, что текущий формат отладочной информации устарел и разжирел. Сейчас, чтобы проанализировать дамп ядра, нужно выкачивать сотни мегабайт (а то и гигов) символов в формате DWARF. Это долго, неудобно и часто невозможно в закрытых контурах, где нет доступа к внешним репозиториям В качестве решения предлагают переходить на компактные форматы типа CTF или SFrame. Идея в том, чтобы облегченные таблицы символов, необходимые для построения стек-трейсов и профилирования, весили мало и всегда были загружены в память вместе с ядром. Представьте мир, где утилиты мониторинга работают сходу, без танцев с бубном и подключения
debuginfo-репов. Если индустрия это примет, мы наконец-то перестанем качать гигабайты ненужного ради того, чтобы увидеть одну строчку с адресом функции, которая уронила сервер.Идея здравая
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
Полезные приёмы Bash, которые стоит использовать в скриптах
1. Контроль наличия файлов и каталогов
Конструкция тестирования через
Такая проверка обязательна перед удалением, чтением или изменением файлов. Это снижает риск аварийного завершения скрипта и делает логику предсказуемой.
2. Подстановка значения по умолчанию
Если переменная
Разница вариантов:
Используется для безопасной работы со входными параметрами и переменными окружения.
3. Обход файлов через цикл for
Важно помнить:
-всегда заключать переменные в кавычки
-при работе с произвольными именами лучше использовать
Это защищает от проблем с пробелами и спецсимволами в именах файлов.
4. Чтение файла построчно
Безопасный способ чтения строк.
Такой шаблон обязателен при работе с конфигами, логами и любыми текстовыми данными.
5. Проверка результата выполнения команды
В Bash код возврата
Использование
6. Многострочный ввод через heredoc
Позволяет передать блоку команд заранее заданный текст.
Часто используется для генерации конфигурационных файлов, шаблонов и inline-скриптов.
7. Очистка ресурсов через trap
Команда trap регистрирует обработчик завершения.
Необходимо для удаления временных файлов и корректного освобождения ресурсов.
8. Жёсткий режим выполнения
После включения этой опции Bash завершит выполнение при первой команде, вернувшей ненулевой код выхода.
Что это даёт:
-Любая ошибка прерывает сценарий немедленно.
-Исключается продолжение работы в неконсистентном состоянии.
-Снижается риск повреждения данных из-за "тихих" сбоев.
Обычно включают вместе с:
Ошибка при обращении к неинициализированной переменной. Позволяет отлавливать опечатки и логические дефекты.
Возвращает код ошибки любой команды внутри пайпа, а не только последней. Это критично при использовании конвейеров.
#learn
1. Контроль наличия файлов и каталогов
if [ -f "$file" ]; then
echo "Файл существует"
fi
Конструкция тестирования через
[ ]позволяет проверять разные типы объектов файловой системы.-f - обычный файл-d - директория-x - исполняемый файлТакая проверка обязательна перед удалением, чтением или изменением файлов. Это снижает риск аварийного завершения скрипта и делает логику предсказуемой.
2. Подстановка значения по умолчанию
name=${NAME:-"Гость"}Если переменная
NAME не определена или пуста, будет использовано значение "Гость".Разница вариантов:
${VAR:-value} - только подставляет${VAR:=value} - подставляет и записывает в переменнуюИспользуется для безопасной работы со входными параметрами и переменными окружения.
3. Обход файлов через цикл for
for file in *.txt; do
echo "Обрабатываю $file"
done
Важно помнить:
-всегда заключать переменные в кавычки
-при работе с произвольными именами лучше использовать
for file in *; doЭто защищает от проблем с пробелами и спецсимволами в именах файлов.
4. Чтение файла построчно
while IFS= read -r line; do
echo "Строка: $line"
done < input.txt
Безопасный способ чтения строк.
IFS= отключает автоматическое разбиение по пробелам-r запрещает интерпретацию backslashТакой шаблон обязателен при работе с конфигами, логами и любыми текстовыми данными.
5. Проверка результата выполнения команды
if command; then
echo "Команда прошла успешно"
else
echo "Ошибка"
fi
В Bash код возврата
0 означает успех, любое другое значение - ошибка.Использование
if напрямую с командой - базовый механизм обработки ошибок. Это предпочтительнее, чем анализ вывода.6. Многострочный ввод через heredoc
cat << EOF
Это многострочный текст.
EOF
Позволяет передать блоку команд заранее заданный текст.
Часто используется для генерации конфигурационных файлов, шаблонов и inline-скриптов.
7. Очистка ресурсов через trap
trap 'rm -f /tmp/tempfile' EXIT
Команда trap регистрирует обработчик завершения.
EXIT - выполняется при любом выходе из скриптаINT - перехват Ctrl+CTERM - корректное завершение процессаНеобходимо для удаления временных файлов и корректного освобождения ресурсов.
8. Жёсткий режим выполнения
set -e
После включения этой опции Bash завершит выполнение при первой команде, вернувшей ненулевой код выхода.
Что это даёт:
-Любая ошибка прерывает сценарий немедленно.
-Исключается продолжение работы в неконсистентном состоянии.
-Снижается риск повреждения данных из-за "тихих" сбоев.
Обычно включают вместе с:
set -u
Ошибка при обращении к неинициализированной переменной. Позволяет отлавливать опечатки и логические дефекты.
set -o pipefail
Возвращает код ошибки любой команды внутри пайпа, а не только последней. Это критично при использовании конвейеров.
#learn
👍2
SELinux и AppArmor - что делать, если сервис не запускается или работает некорректно.
SELinux и AppArmor - это механизмы принудительного контроля доступа MAC. Они ограничивают действия процессов независимо от прав пользователя, включая root. Если служба не читает файлы, не открывает порт или падает без очевидной причины, проблема часто связана именно с ними.
В Linux действует двухуровневая модель безопасности:
1) DAC - классические UNIX права и владельцы.
2) MAC - обязательная политика, которая проверяется дополнительно.
Если DAC разрешает доступ, но MAC запрещает, операция будет заблокирована.
SELinux
SELinux использует модель на основе меток. Каждый объект в системе имеет security context:
user:role:type:level
Решение принимается по правилу type enforcement. Если для пары source_type и target_type нет разрешения allow - операция будет отклонена.
Что проверить в первую очередь:
Возможные значения:
Если в
Проверка контекстов:
Тип процесса должен соответствовать типу файлов. Например, процесс
Анализ отказов:
или
Типовые причины:
1) файлы скопированы вручную и потеряли корректный label
2) данные размещены в нестандартном каталоге
3) сервис использует нетипичный порт
4) приложению требуется доступ к сети, не разрешенный boolean
Корректное исправление - восстановление контекста:
Если используется нестандартный путь:
Добавление нестандартного порта:
Проверка и включение boolean:
Создание локального модуля политики:
Этот способ добавляет новое allow правило. Использовать только если невозможно решить проблему через корректные типы или booleans.
Временный перевод в permissive режим для диагностики:
Но это только для диага, не для прода.
AppArmor
AppArmor использует модель на основе путей. Политика задается профилем, который ограничивает доступ к конкретным файлам, каталогам и возможностям ядра.
Проверка статуса:
Поиск отказов:
В логе будет строка вида:
apparmor="DENIED" operation="open" profile="/usr/sbin/nginx"
Решение через complain режим:
Профиль перестает блокировать и начинает только логировать.
Автоматическое добавление правил из логов:
Редактирование профиля вручную:
Добавление правила доступа:
Перезагрузка профиля:
Основные ошибки сисадминов ^_^
1) Полное отключение SELinux или AppArmor вместо анализа причины.
2) Использование
3) Генерация модуля через
4) Оставление системы в
Рабочий алгоритм при отказе сервиса:
1) Проверить режим SELinux или AppArmor.
2) Найти deny в логах.
3) Проверить контексты или профиль.
4) Попробовать восстановить стандартную политику.
5) Добавить точечное разрешение.
6) Только в крайнем случае создавать кастомный модуль.
MAC - это лишь доп слой защиты. Он не должен мешать, а только ограничивать потенциальный ущерб.
Правильная настройка залог нервов, и спокойной смены на работе :)
#learn
SELinux и AppArmor - это механизмы принудительного контроля доступа MAC. Они ограничивают действия процессов независимо от прав пользователя, включая root. Если служба не читает файлы, не открывает порт или падает без очевидной причины, проблема часто связана именно с ними.
В Linux действует двухуровневая модель безопасности:
1) DAC - классические UNIX права и владельцы.
2) MAC - обязательная политика, которая проверяется дополнительно.
Если DAC разрешает доступ, но MAC запрещает, операция будет заблокирована.
SELinux
SELinux использует модель на основе меток. Каждый объект в системе имеет security context:
user:role:type:level
Решение принимается по правилу type enforcement. Если для пары source_type и target_type нет разрешения allow - операция будет отклонена.
Что проверить в первую очередь:
getenforce
Возможные значения:
Enforcing - блокируетPermissive - только логируетDisabled - отключенЕсли в
Permissive сервис начинает работать, причина точно в политике.Проверка контекстов:
ls -Z /path
ps -eZ | grep nginx
Тип процесса должен соответствовать типу файлов. Например, процесс
httpd_t может читать только файлы с httpd_sys_content_t. Если каталог имеет тип default_t - будет отказ.Анализ отказов:
grep "avc: denied" /var/log/audit/audit.log
или
ausearch -m avc -ts recent
Типовые причины:
1) файлы скопированы вручную и потеряли корректный label
2) данные размещены в нестандартном каталоге
3) сервис использует нетипичный порт
4) приложению требуется доступ к сети, не разрешенный boolean
Корректное исправление - восстановление контекста:
restorecon -Rv /var/www/html
Если используется нестандартный путь:
semanage fcontext -a -t httpd_sys_content_t "/srv/site(/.*)?"
restorecon -Rv /srv/site
Добавление нестандартного порта:
semanage port -a -t http_port_t -p tcp 8080
Проверка и включение boolean:
getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on
Создание локального модуля политики:
grep "avc: denied" /var/log/audit/audit.log | audit2allow -M mymodule
semodule -i mymodule.pp
Этот способ добавляет новое allow правило. Использовать только если невозможно решить проблему через корректные типы или booleans.
audit2allow может открыть избыточный доступ.Временный перевод в permissive режим для диагностики:
setenforce 0
Но это только для диага, не для прода.
AppArmor
AppArmor использует модель на основе путей. Политика задается профилем, который ограничивает доступ к конкретным файлам, каталогам и возможностям ядра.
Проверка статуса:
aa-status
Поиск отказов:
journalctl -xe | grep apparmor
dmesg | grep DENIED
В логе будет строка вида:
apparmor="DENIED" operation="open" profile="/usr/sbin/nginx"
Решение через complain режим:
aa-complain /usr/sbin/nginx
Профиль перестает блокировать и начинает только логировать.
Автоматическое добавление правил из логов:
aa-logprof
Редактирование профиля вручную:
/etc/apparmor.d/usr.sbin.nginx
Добавление правила доступа:
/srv/site/** r,
Перезагрузка профиля:
apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx
Основные ошибки сисадминов ^_^
1) Полное отключение SELinux или AppArmor вместо анализа причины.
2) Использование
chmod 777 вместо корректной политики.3) Генерация модуля через
audit2allow без понимания, что именно разрешается.4) Оставление системы в
permissive или complain режиме в продакшене.Рабочий алгоритм при отказе сервиса:
1) Проверить режим SELinux или AppArmor.
2) Найти deny в логах.
3) Проверить контексты или профиль.
4) Попробовать восстановить стандартную политику.
5) Добавить точечное разрешение.
6) Только в крайнем случае создавать кастомный модуль.
MAC - это лишь доп слой защиты. Он не должен мешать, а только ограничивать потенциальный ущерб.
Правильная настройка залог нервов, и спокойной смены на работе :)
#learn
Forwarded from Типичный Сисадмин
Годами мы лепили гостевые SSID, ставили галочку AP Isolation и верили, что юзеры внутри одной подсети изолированы друг от друга. Оказалось - показалось
На симпозиуме NDSS 2026 показали атаку AirSnitch, которая умножает на ноль всю изоляцию Wi-Fi клиентов. Причем делает это не брутфорсом, а фундаментальным обманом логики работы коммутаторов на первом и втором уровнях модели OSI. Уязвимы практически все протестированные железки... Cisco, Ubiquiti, Netgear, D-Link, а также кастомные прошивки OpenWrt и DD-WRT
Суть атаки... Атакующий подключается к точке доступа, подделывая MAC-адрес жертвы. AP обновляет таблицу коммутации, связывая виртуальный порт атакующего с MAC-адресом жертвы. В результате весь входящий трафик начинает литься хакеру. Но чтобы сделать атаку двусторонней и не сбросить жертву окончательно, хакер использует хитрый трюк... он отправляет ICMP-пинг с рандомного MAC-адреса, завернутый в общий групповой ключ сети. Это заставляет точку доступа переключить маршрутизацию обратно на жертву. Постоянно жонглируя этими состояниями, атакующий незаметно встает посередине канала
Самая дичь заключается в том, что атака работает даже за пределами одного BSSID. Злоумышленник может сидеть на гостевом SSID, а ломать клиента из корпоративного SSID, если они обслуживаются одной точкой доступа. В энтерпрайз-сетях ситуация еще хуже, т.к. AirSnitch позволяет перехватывать трафик между пользователями, подключенными к разным физическим точкам доступа, если они делят общую проводную распределительную сеть. Разделение по VLAN помогает далеко не всегда, так как многие вендоры криво реализуют изоляцию между L2 и L3. Исследователи даже продемонстрировали, как с помощью этого метода перехватить RADIUS-пакеты и поднять фейкового двойника корпоративной WPA3-Enterprise сети.
Что со всем этим делать - пока вопрос открытый. Проблема кроется в самой архитектуре обработки фреймов, и некоторые производители железа уже говорят, что починить это программно невозможно и нужны фиксы в Wi-Fi чипах. Патчи будут, но до тех пор любая открытая или слабо защищенная сеть (даже с изоляцией) - это ваши риски уже сейчас
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
😨2
Forwarded from Типичный Сисадмин
🧬 Ученые собрали перезаписываемый жесткий диск из ДНК
Исследователи научились не просто архивировать данные в молекулы ДНК (это умели и раньше в режиме...записал и положил в холодильник на сотню лет), а создали полноценный многоразовый носитель. Теперь эту био-флешку можно стирать и переписывать по кругу, прямо как обычный хард😮
Внутри сплошной киберпанк. Чтобы записать инфу, бинарный код конвертируют в последовательности нуклеотидов (A, C, G, T) с помощью алгоритма frameshift encoding. А для чтения используется сенсор-нанопора... нить ДНК протаскивают через микроскопическое отверстие, электроника замеряет колебания электрического сигнала и расшифровывает их обратно в нули и единицы. По сути, получилась классическая логика контроллера HDD, только на молекулярном уровне.
Профиты технологии очевидны. Плотность записи такая, что в одной пробирке можно унести бэкапы ДЦ среднего гиперскейлера. Плюс нулевое энергопотребление в режиме простоя и срок хранения в несколько столетий. Никакой деградации ячеек, как в SSD, и никаких заклинивших головок.
Однако до коммерческого прода и компактных USB-свистков с ДНК еще пройдут годы. Но перспектива забавная. Походу в будущем придется следить за тем, чтобы полка с бэкапами случайно не мутировала🏥
Типичный🥸 Сисадмин
Исследователи научились не просто архивировать данные в молекулы ДНК (это умели и раньше в режиме...записал и положил в холодильник на сотню лет), а создали полноценный многоразовый носитель. Теперь эту био-флешку можно стирать и переписывать по кругу, прямо как обычный хард
Внутри сплошной киберпанк. Чтобы записать инфу, бинарный код конвертируют в последовательности нуклеотидов (A, C, G, T) с помощью алгоритма frameshift encoding. А для чтения используется сенсор-нанопора... нить ДНК протаскивают через микроскопическое отверстие, электроника замеряет колебания электрического сигнала и расшифровывает их обратно в нули и единицы. По сути, получилась классическая логика контроллера HDD, только на молекулярном уровне.
Профиты технологии очевидны. Плотность записи такая, что в одной пробирке можно унести бэкапы ДЦ среднего гиперскейлера. Плюс нулевое энергопотребление в режиме простоя и срок хранения в несколько столетий. Никакой деградации ячеек, как в SSD, и никаких заклинивших головок.
Однако до коммерческого прода и компактных USB-свистков с ДНК еще пройдут годы. Но перспектива забавная. Походу в будущем придется следить за тем, чтобы полка с бэкапами случайно не мутировала
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔1