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

Если требуется скрыть структуру каталогов и предоставить доступ лишь к конкретным файлам, можно установить права на чтение конкретного файла, но запретить чтение содержимого каталогов по пути его расположения. Для этого нужно выполнить команду chmod 711 <путь к каталогу>. Эта команда установит для группы и остальных пользователей только право execute (исполнение).

Разберём, как работают биты read и execute применительно к каталогам:

➡️ Право read (r) позволяет просмотреть содержимое каталога например, командой ls. Пользователь увидит список файлов и подкаталогов.
➡️ Право execute (x) позволяет:
➡️ сменить рабочую директорию на целевую или следующую по структуре (команда cd);
➡️ получить дополнительную информацию о содержимом (команды du, ls -l и т. д.), если есть доступ к конкретным файлам.

Таким образом, запретив право read, мы не даём вывести список файлов и директорий по пути к файлу. Но, оставив право execute, разрешаем «проходить» через каталоги к целевому файлу - при условии, что пользователь знает полный путь к нему.

Важно: для доступа к такому файлу необходимо точно знать его полный путь - без права read обнаружить его путём просмотра каталогов невозможно.

Кроме того, некоторые команды командной оболочки могут не работать без доступа на чтение каталога. Это связано с различиями в реализации команд - например, поведение cd в оболочке fish-shell может отличаться от классического bash.

Описанная ситуация - пример того, как можно предоставить доступ для работы с каталогом на определённом уровне вложенности. Для более точечного управления доступом можно использовать ACL (Access Control List); об этом мы поговорим в следующих статьях.

Статья на дзен

Попробовал на днях утилиту llmfit, которая значительно облегчила мне подбор подходящих языковых моделей для домашнего сервера/арм.
Раньше я использовал llm-explorer.com для поиска подходящих моделей, но часто сталкивался с трудностями при выборе оптимального баланса между качеством и требуемыми ресурсами.

Теперь достаточно установить llmfit на целевую систему и запустить - утилита сама покажет, какие модели совместимы с вашими характеристиками.

Ключевые возможности:
🟣 Автоопределение характеристик
🟣 Удобный TUI-интерфейс для фильтрации и просмотра моделей
🟣 Подробная информация о каждой модели
🟣 Поддержка работы через API
🟣Интеграция слокальными провайдерами Ollama, llama.cpp, MLX (Apple Silicon)
🟣 Возможность скачивания моделей с HuggingFace
🟣 Подсказки по требуемому железу для конкретной модели
🟣 Вывод результата в JSON
🟣 Настройки позволяющие задать VRAM, размер контекста и т.д.

Важные нюансы:
🟣 База данных моделей обновляется при сборке утилиты
🟣 Для работы с llama.cpp требуется ее локальная установка или настройка алиасов с монтированием директории при условии использования Docker-контейнера

В качестве практики установил:
🟣 nomic-embed-text-v1.5 через Ollama для индексации кода в Qdrant с использованием sourcecraft assystant
🟣 DeepSeek-Coder-V2-Lite-Instruct через llama.cpp для локального использования и изучения

Ссылки:
llmfit: https://github.com/AlexsJones/llmfit
LLM Explorer: https://llm-explorer.com/

В рамках одного проекта появилась потребность на Astra Linux взаимодействовать с внешним Git-репозиторием по HTTPS. Для аутентификации без использования стандартных учётных данных был создан персональный токен доступа.

Возник вопрос о наиболее безопасном способе его хранения. Встроенные механизмы Git, такие как credential.helper store и credential.helper cache, не подходили - первый просто сохраняет данные в открытом виде в файле, а второй, помимо аналогичной проблемы с безопасностью, оказался менее удобным в использовании.

Установка дополнительных пакетов была невозможна. Изучая документацию Git, наткнулся на возможность создания кастомной реализации для предоставления Git учетных данных.

Оставалось найти надёжное место для хранения токена. Решение нашлось в виде GNOME Keyring - компонента, который поставляется из коробки в Desktop-версии системы.

Используемые инструменты:

🟢GNOME Keyring — встроенное хранилище секретов
🟢 Seahorse — графический интерфейс для работы с ключами
🟢 Secret-tool — консольная утилита для взаимодействия с хранилищем

Для начала добавим токен в хранилище:

secret-tool store --label="<описание>" <атрибут> <значение атрибута>

Пример команды:

secret-tool store --label="Git Personal Access Token" git token

После выполнения утилита запросит ввод токена.

Далее подготовим bash-скрипт для получения учётных данных(для удобства у нас доменный пользователь):

#!/bin/bash
echo "username=$USER"
echo "password=$(secret-tool lookup git token)"

Сохраняем файл, например, в ~/.git-credentials.sh

Завершаем нашу настройку конфигурированием credential.helper

git config --global credential.helper "/bin/bash ~/.credentials.sh"

Важные моменты:
🟢 Хранилище должно быть разблокировано (например при входе в систему)
🟢 При блокировке сессии хранилище остаётся доступным

Хочу поделиться своим первым опытом применения настольных игр в тимбилдинге и нетворкинге.

Всё началось с прослушивания подкаста о разговорных ролевых играх "Завтра в прод | Как тимлиду решать проблемы в команде с помощью разговорных ролевых игр". Это меня очень заинтересовало и натолкнуло на мысль поискать готовые решения для корпоративной среды, особенно с IT-составляющей.

В процессе поиска обнаружил следующее:

🟠 Опыт Газпромбанка по использованию игр в IT-команде "Пять настольных игр, в которые играют IT-специалисты Газпромбанка"
🟠 Специализированная игра от сообщества Ever Secure "Elevation of Privilege"
🟠 Услуги по брендированию и разработке игр от "Мосигра" "Корпоративные настольные игры"

Далее наткнулся на серию игр "НЕЗНАКОМЫЕ" (не реклама). Для тестирования приобрёл набор "Для коллег и команд" с 99 карточками в 5 категориях:

🟠 Интересы и предпочтения
🟠 Образование и навыки
🟠 Коллеги
🟠 Идеальная работа
🟠 Опыт, страхи и неудачи

Дополнительно заказал пак "30 новых вопросов и заданий", он позволил поддержать интерес, когда есть участники, игравшие со мной ранее.

Пока попробовал провести игру в 2х форматах:

🟠 Онлайн-игра с друзьями через чат
🟠 Офлайн-встречи с новыми людьми

И я доволен впечатлениями и опытом:

🟠 Высокая вовлечённость участников
🟠 Живые и интересные обсуждения
🟠 Возможность лучше узнать собеседников
🟠 Услышать новые для себя точки зрения, особенно от людей, которые стараются избегать подобного формата.

Сейчас приобрел дополнительные наборы для расширения диапазона вопросов и участников, которые не хотят говорить про работу:

🟠 "Аутентичная коллекция"
🟠 "Дилеммы"

Во время написания поста зашел на официальный сайт "НЕЗНАКОМЫЕ" и нашел, что также присутствуют услуги по:

🟠 Брендированию игр
🟠 Кастомизации наборов
🟠 Созданию индивидуальных решений

Также есть и онлайн-версия игры.

Планирую продолжать эксперименты с игровыми форматами для тимбилдинга и нетворкинга.

Поделитесь своим опытом - какие игры пробовали, может быть, даже создавали собственные?

Как DevOps на CTF пошёл

25 апреля я впервые принял участие в CTF-соревновании.

Всё началось с неожиданного предложения коллеги поучаствовать в AlfaCTF IT-треке. Этот трек был специально создан для участников без глубокого опыта в информационной безопасности и с ограниченным опытом участия в подобных соревнованиях (до 5 CTF).

За неделю до старта мы начали подготовку, используя задания AlfaCTF 2025 в качестве тренировочной базы. Для работы подготовил следующий инструментарий:

🟠 Ghidra - для анализа бинарных файлов
🟠 Burp Suite - для тестирования веб-приложений
🟠 Mitmproxy - для перехвата трафика
🟠 Parrot Linux image - дистрибутив для тестирования безопасности
🟠 Bruno - для работы с API

Соревнование длилось 12 часов и оказалось невероятно напряжённым. Несмотря на то, что лично мне не удалось решить ни одной задачи, благодаря усилиям остальных членов команды мы заняли 105 место из 490 команд-участников.

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

🟠 Binwalk - для анализа бинарных файлов, образов и прошивок
🟠 Apk-mitm - для помощи в инспектировании Android-приложений

Участие в соревновании позволило:

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

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

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

Первоначальная настройка VDS/VPS без головной боли

Периодически приходится арендовать VPS для небольших проектов. И тут возникает дилемма: тратить много времени на ручную настройку не хочется, но и терять контроль над системой, рискуя получить "гостей", тоже мало приятного.

Раньше после покупки сервера верхнеуровневый чек-лист был таким:

🟠 Создание учётной записи и настройка прав доступа (обычно это root для себя любимого)
🟠 Добавление публичного SSH-ключа
🟠 Конфигурация firewall и SSH
🟠 Базовые настройки, повышающие безопасность
🟠 Установка базового софта

Чтобы не тратить время на ручное выполнение этих действий по чек-листу, я пришёл к созданию Ansible-коллекции, включающей все необходимые действия.
linux-collection

На данный момент коллекция включает следующие роли:

🟠 audit - сбор информации о системе с помощью Lynis и OpenSCAP
🟠 bash_profile - настройка приветственного сообщения и prompt string (об этом хочу сделать отдельный пост)
🟠 docker - установка Docker с добавлением пользователей в группу
🟠 package_updates - обновление пакетов
🟠 prepare - первичная подготовка сервера (создание учётной записи, добавление SSH-ключа, смена порта SSH)
🟠 security - различные настройки для обеспечения безопасности

Роль security включает рекомендации собранные из различных источников:

🟠 Базовые рекомендации найденные на просторах интернета
🟠 Советы встречающиеся в новостях и постах
🟠 Рекомендации CIS (Center for Internet Security), ФСТЭК

Отдельно хочу отметить интересный момент. OpenSCAP помог обнаружить слепые зоны в настройке SSH. Например, я был уверен, что достаточно настроить sshd_config, но упустил важный момент: хостинг-провайдеры часто размещают дополнительные ключи и настройки для доступа технической поддержки, о чём провайдер предупреждает в письмах и у себя на сайте. Теперь могу это контролировать в зависимости от задачи.

Сейчас первичная подготовка занимает пару минут, а дальнейшее сопровождение не отнимает много времени.

В ближайших планах:

🟠 роль для постановки на мониторинг(рассматриваю Yandex Monitoring)
🟠 реализация rootless Docker
🟠 добить обработку замечаний от OpenSCAP
🟠 изучить методичку по харденингу Ubuntu 24.04 от автора @bykva
🟠 разобраться с SELinux(все откладывал)
🟠 расширение функциональности

Коллекция в первую очередь ориентирована на RedHat-based дистрибутивы, но и про Debian/Ubuntu стараюсь не забывать.

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

А какие инструменты используете вы для настройки, аудита и мониторинга?

Как защитить сервер прода от себя

Чтобы не стать героем байки про "как я случайно удалил базу на проде", вот несколько способов, которые помогут избежать человеческого фактора при ручных действиях:

🟠 Приветственное сообщение в терминале с указанием окружения:

echo -e "
\033[41m\033[5mWARNING\033[m
\033[1;34mThis is a production server\033[m
"

🟠 Настройка PS1 (prompt string) с подсветкой окружения и имени хоста:

PS1="\@ \[\033[38;5;196m\]PROD\[$(tput sgr0)\]\n[\[$(tput sgr0)\]\[\033[38;5;75m\]\u\[$(tput sgr0)\]@\[$(tput sgr0)\]\[\033[38;5;196m\]\h\[$(tput sgr0)\] \W]\\$ \[$(tput sgr0)\]"

В своей практике я применяю данные методы, размещая необходимые настройки в системном каталоге /etc/profile.d/ или пользовательских файлах .profile для Debian и .bash_profile для Red Hat дистрибутивов при отсутствии прав на запись в /etc ;).

Дополнительные предохранители:

🟠 sudo с паролем - отсутствие NOPASSWD в sudoers на проде будет напоминанием, что находитесь не в тестовом окружении.

🟠 Подтверждение sudo команд - можно создать функцию, которая будет запрашивать подтверждение перед команд с sudo:

sudo() {
    read -rp "⚠️ WARNING: Running a command with superuser privileges! Continue? (y/N): " response
    case "$response" in
        [yY][eE][sS]|[yY])
            command sudo "$@"
            ;;
        *)
            echo "The execution of the command has been canceled."
            return 1
            ;;
    esac
}

Поделитесь своим опытом: какие меры защиты от случайных команд на продакшене вы считаете наиболее эффективными в своей практике?