Многих эта тема обошла стороной, дело привычки берет своё.
ㅤ
Я про docker-compose.yaml. Так вот, в современных дистрибутивах не обязательно называть так файл, достаточно обозвать его compose.yaml и всё будет работать. Но при условии если у тебя не допотопная ОС со старой версией docker’a.

Современный docker давно перешел на compose.yaml.

docker-compose — это отдельный python-инструмент
docker compose — встроенный плагин docker cli

Теперь docker в приоритете ищет файл compose.yaml и только потом старый docker-compose.yaml. И так и так все будет работать. Оно пока на это не ругается, но рано или поздно к этому придут.

Наверное ты уже замечал, что если в yaml указать version: 3.9 оно скажет — ты ебанутый? Я пожалуй это проигнорирую.

Это нужно было указывать раньше, чтобы docker понимал какие поля разрешены и как вообще интерпретировать файл. Теперь это легаси и docker автоматически определяет версию, чтобы избавиться от зоопарка версий: v2, v2, v3.7, v3.9. Получаем один формат → одна логика → меньше гемора.

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

Но опять же если у тебя древняя ОС, выбора особо не будет, придется прописывать версии и поддерживать это наследие.

Пример с version или подстава. Создавалась это не для docker compose, а для docker swarm. В version:3 Docker Compose просто молча игнорировал: mem_limit, cpu_shares, cpus, restart_policy, depends_on. Не было ни ошибок, ни предупреждений. Просто ничего не происходило. Контейнер запускался, но не как ожидалось.

version: "3"
mem_limit: 512m

Хм… 512 говоришь, хуй те! Эй OOM давай к нам, у нас тут пациент!

version:3 — Swarm-спека

Ну и про yaml и yml пару строк. Можно писать так и так, оба варианта равноправны. Но всё же рекомендуется yaml, потому что это полное официальное расширение, так пишется в спецификациях и документациях. Плюсом это единый стиль Kubernetes, GitHub Actions, Helm и т.п.

На сколько помню yml пошел со старых систем, когда было ограничение в 3 символа, опять же наследие прошлого.

Возможно ошибаюсь, поправьте в комментах.

🛠 #docker #linux #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Как тебя вычисляют по шрифтам

Гугловский пробив по кукисам это классика, но это не единственный механизм сопоставления. Сегодня рассмотрим browser fingerprint (fonts).
ㅤ
Пробежимся по кукисам.

Практически на каждом сайте, установлен анальный-зонд с маркировками: Google Analytics, Google Ads, YouTube embed, reCAPTCHA и т.п. То есть страница сайта подгружает внешние скрипты и код с доменов гугла.

Когда ты заходишь на такой сайт, браузер отправляет кукисы в гугол, в них будет информация: твой id (у тебя будет один и тот же для разных сайтов), с какого сайта ты пришел, ip, браузер, время, язык, локация и т.п.

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

Если ты залогинен в гугле и гуляешь в этом же браузере по другим сайтам — гугл это знает. Мало того, при любом звоночке, он без раздумий передаст эту информацию «малдерам».

Звучит как сказка, но у гугла есть статистика сколько они слили данных по таким запросам. И да, когда ты с закрытыми глазами принимал «лицензионное соглашение», в нём все это оговаривалось.

Что же такое fonts fingerprint?

Это как тест ДНК, который даёт до 99% совпадения. Шрифт это как паспорт. У каждого пользователя свой, уникальный набор шрифтов. Даже если ты отключишь кукисы, у гугла есть другие инструменты для слежки: разрешение экранов, шрифты, webgl, canvas, timezone, ip + поведение.

Кстати «режим инкогнито» не спасёт, это — миф. В этом режиме браузер не сохраняет историю, не сохраняет кукисы после закрытия. ВСЁ! Куки это верхушка айсберга, все остальные методы скрыты под капотом.

Fingerprint это корреляция десятков сигналов во времени.

Как работает классический font fingerprint:

Я подготовил страничку, в ней содержится как раз такой детект по шрифтам и канвасу. Открой её в браузере, а потом открой в «инкогнито» и ты сильно удивишься. Шрифты и хеш канваса будут идентичные.

Даже если открыть страницу в другом браузере, Canvas Hash в большинстве случаев будет идентичен. Для чистоты эксперимента, открой страничку в ТОR браузере и ты увидишь, что набор шрифтов поменялся, да и canvas hash протух.

Идея метода: берем текст, рисуем его с базовым шрифтом (serif / sans-serif), тестируемым шрифтом + fallback, сравниваем размеры, если размеры изменились — шрифт установлен в системе.

И по итогу мы имеем паспорт пользователя: шрифты = ОС + язык + софт. Шрифты меняются редко, уникальность очень высокая, не ломаются при включении VPN / Инкогнито.

fonts + canvas + webgl ≈ уникальность > 99%

А чё делать?

Использовать разные браузеры под разные задачи. Один браузер чисто для гугла (но рекомендую вообще снести учетку и сделать чисто под ютуб), второй для сёрфинга, третий для просмотра порнушки.

На рынке много антидетект браузеров, один из лидеров это LibreWolf. Этот браузер (Firefox на стероидах приватности) подсовывает одинаковый виртуальный набор, ломает измерения, возвращает одинаковые размеры, добавляешь шум.

Отключает webgl fingerprint, режет canvas, нормализует timezone, screen size, locale, отключает webrtc leak, блокирует third-party cookies, выключает телеметрию Mozilla, ломает high-entropy сигналы, всегда врёт одинаково.

LibreWolf не делает «рандом», он делает массовую «одинаковость». То есть условно у 100 пользователей, которые пользуются этим браузером, будут идентичные данные. А среди 100 таких пользователей, тебя сложно идентифицировать — ты одинаковый. Чем больше уникальности, тем легче тебя узнать.

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

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

Ну а ты пока переваривай весь этот пиздец. Дальше затрем за Cloudflare и его приколы.

🛠 #security #privacy
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Как быстро скачать файл с сервера
ㅤ
Бывает ситуация, когда тебе нужно быстренько дернуть какой-то файл с сервера, но там нет ни nginx ни т.п. херни. Вспоминать синтаксис scp и ебаться с ключами тоже не хочется. Тем более для такой задачи ставить софт — ну такое себе.

Из ситуации можно выйти проще.

Этот способ в основном используют спец-люди, которые в результате blackbox вектора проникли на север и им нужно утащить жирненькую базу данных. Всё элементарно.

Заходим в любую папку с файлами и запускаем:

python -m http.server 2977

Если питон старый, потрёпанный и сморщенный как хуй, делаем так:

python -m SimpleHTTPServer 2977

Затем курлим файл и скачиваем его к себе на машину:

curl -O http://linuxfactory.ru:2977/bashdays_db.zip

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

Еще бывают случаи когда curl не установлен, но wget есть из коробки:

wget -O bashdays_db.zip http://linuxfactory.ru:2977/bashdays_db.zip

Ну и в конце, когда получил желаемое, не забывай остановить такой веб-сервер. Изучай!

🛠 #security #linux #tricks
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Получаем SSL сертификат на IP адрес.
ㅤ
Вот и случилось, теперь ты можешь сгенерить валидный SSL сертификат для айпишника. Не самоподписанный, а прям настоящий от Lets Encrypt.

Не путать с mkcert, это совсем другое.

Единственный момент, такой серт будет валиден несколько дней (160 часов), поэтому придется почаще его выпускать, сейчас ставят 5 дней для обновления, как золотую середину. НЕ рекомендуется ставить 6, иначе можешь словить граблю. Вообще acme сам всё в кроне должен прописать, но это не точно.

Пока это может делать только acme, все остальные (certbot, angie) совсем скоро к этому придут.

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

Cannot issue for \"192.168.10.91\": IP address is in a reserved address block: [RFC1918]: Private-Use"

Ну оно и логично, спецификации никто не отменял.

Я буду генерить для 178.72.129.181 на котором у меня установлен nginx. Виртуалка прерываемая, так что денег практически не жрет, для тестов в настоящем облаке — милое дело.

Приступим:

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

curl https://get.acme.sh | sh -s email=shubkin@bashdayz.ru

Конфигурируем default в nginx:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    location ~ ^/.well-known/(acme-challenge|pki-validation)/ {
        add_header Content-Type text/plain;
        root /var/www/letsencrypt;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

Создаем структуру папок и релоадим:

mkdir -p /var/www/letsencrypt
mkdir -p /etc/nginx/ssl
nginx -t
nginx -s reload

Выписываем пиздюлей сертификат:

acme.sh --issue --server letsencrypt -d 178.72.129.181 -w /var/www/letsencrypt --certificate-profile shortlived --days 3

Отлично, сертификат получили, устанавливаем:

acme.sh --install-cert -d 178.72.129.181 --key-file /etc/nginx/ssl/ip.key --fullchain-file /etc/nginx/ssl/ip.crt --ca-file /etc/nginx/ssl/ip.ca.crt --reloadcmd "systemctl restart nginx"

Добавляем дополнительный блок в default в nginx:

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    server_name _;
    return 403;
    ssl_certificate /etc/nginx/ssl/ip.crt;
    ssl_certificate_key /etc/nginx/ssl/ip.key;
}

Перезапускаем:

nginx -t
nginx -s reload

И радуемся, теперь у тебя есть валидный SSL на голом айпишнике:

Общее имя (ЦС)  YE1
Организация  Let's Encrypt
Дата выдачи: 29 января 2026 г.
Срок действия: 5 февраля 2026 г.

Дело в шляпе, что сказать? Пиздато! Порой ОЧЕНЬ не хочется привязывать домен, чтобы обзавестись SSL сертификатом, теперь выход есть. Глядишь найдется хак, чтобы сгенерить подобное для 192.168.0.1, но наверное это из оперы моих влажных фантазий.

🛠 #linux #devops #ssl
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Я тут недавно на новогодние праздники затеял переезд на новый периметровый маршрутизатор. Раньше я использовал pfSense, но с недавнего времени он перестал обновляться. Да и скачать его проблематично. В общем решил переехать на opnSense.

🔤🔤🔤🔤🔤🔤🔤

Сразу скажу, что это уже вторая попытка. Первая попытка провалилась из-за регулярных падений и отваливая интернета.

Доходило до того, что пришлось ставить еженочную перезагрузку. Но, скорее всего это была вина не opnSense, а железа. Машина была старая, память не ECCшная. И вот теперь попытка номер два. На мой взгляд довольно успешная.
ㅤ
Все работает, как часы. На мой взгляд - интерфейс гораздо удобнее, чем у pfSense. Логичнее, что ли. Я не использую его на всю катушку - так, несколько WAN, LAN, DMZ и WI_FI. Все разведено физически, без VLAN.

Единственный затык был с настройкой DHCP. Я так и не понял, зачем туда воткнули три DHCP сервера (Dnsmasq, ISC DHCP, KEA DHCP) Может старшие товарищи объяснят. Немного пободавшись, я решил использовать Dnsmasq.

В общем, переезд прошел удачно. opnSense понравился. На мой взгляд, вполне можно использовать так замену pfSense.

Как установить arpwatch я не нашел, поэтому по традиции написал простенький csh-скрипт для оповещения появления в сети новых связок IP+mac.

Но это в следующий раз. Всем стабильных сетей.

🛠 #networks #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Настройка Yubikey + WSL2 + SSH (Часть 1)

TL:DR Настраиваем подключение по ssh к серверам с yubikey, без паролей, физических приватных ключей и смс. Заодно покажу как с помощью хака прокидывать физические USB устройства в WSL машину, авось захочется тебе что-то другое прокинуть и поковырять.

Ставим YubiKey Manager, оно есть под все ОС, я буду ставить на винду и прокидывать ключ в WSL2. Под линукс это все работает из коробки, а вот с виндой + wsl 2— есть проблемы.
ㅤ
Вставляем Yubikey в USB, открываем Manager и проверяем, если всё ок, то ключ появляется. Дополнительно можно проверить в консоли командой: ykman info в ответ получен:

Device type: YubiKey 5 NFC
Serial number: 12345678
Firmware version: 5.7.4
Form factor: Keychain (USB-A)
Enabled USB interfaces: OTP, FIDO, CCID
NFC transport is enabled.

Предварительно в ключ нужно зашить PIN, делается это через тот же Yubikey Manager в разделе Application → FIDO2 → FIDO2 PIN. Забиваем PIN.

PIN можно установить из консоли винды, командой: ykman fido access change-pin. Но если есть морда, то быстрее и приятнее сделать это через морду.

Едем дальше. Прокинуть физический USB в WSL2 не так просто, но есть решение. Называется оно usbipd-win и позволяет прокинуть любую USB железяку внутрь пресловутого WSL2. Скачиваем установщик в разделе Releases и устанавливаем. Рутина.

Дальше еще интереснее. Открываем консоль PowerShell и запускаем:

usbipd list

И видим кучу устройств. Среди всего нужно найти Yubikey, у меня это:

3-2 1050:0407  USB-устройство ввода, Устройство чтения смарт-карт Micros...

Как я это понял? Да банально выткнул ключ из USB, прогнал команду, воткнул и снова прогнал, сравнил что появилось. А появилось именно это устройство, нам нужен его ID, у меня это 1050:0407.

usbipd bind --busid 3-2
usbipd attach --wsl --busid 3-2

Если вылезет ошибка, в большинстве случаев это виндовый фаервол. У меня установлена морда TinyWall, я его на время отключаю. Позже уже добавлю нужные правила.

Нахуя мне фаервол? Хочу держать под контролем софт, который у меня установлен, ну не нравится мне когда что-то утекает без моего ведома, тем более после «гугл приключений».

Так, теперь идем в WSL машину и выполняем sudo lsusb, если всё ок то увидим:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1050:0407 Yubico.com Yubikey 4/5

Кайф! Что-то прокинулось. Но что? Терпение!

У меня в WSL живет ubuntu 24, доставляем необходимые пакеты:

sudo apt install -y yubikey-manager fido2-tools

Проверяем:

sudo ykman info

Device type: YubiKey 5 NFC
Serial number: 12345678
Firmware version: 5.7.4
Form factor: Keychain (USB-A)
Enabled USB interfaces: OTP, FIDO, CCID
NFC transport is enabled.

sudo fido2-token -L

/dev/hidraw1: vendor=0x1050, product=0x0407 (Yubico YubiKey)

Да сучка! Поздравляю, мы успешно прокинули USB железяку в WSL2. Нюансы! Кудаж без них. Сейчас ключ виден только руту, а нам надо обычному юзеру. Хакаем систему!

В WSL машине создаем файл /etc/udev/rules.d/99-yubikey.rules:

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0407", MODE="0660", GROUP="plugdev", TAG+="uaccess"

Не забываем вставить ID вендора и продукта, мы их выше уже получили и знаем.

Применяем:

sudo usermod -aG plugdev $USER
sudo udevadm control --reload-rules
sudo udevadm trigger

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

Теперь можем генерить ключ и подключаться к серверам.

Продолжение будет завтра, всё в один пост не влезло. Завтра рассмотрим генерацию SSH ключей и как пофиксить баги при фрикциях с USB.

🛠 #security #privacy
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Настройка Yubikey + WSL2 + SSH (Часть 2)

Первая часть тут: https://xn--r1a.website/bashdays/1357

Создаём SSH ключ:

ssh-keygen -t ed25519-sk -O resident -C "shuba@bashdays"

Оно запросит у тебя PIN который мы впендюрили в самом начале. Жмем несколько раз Enter и радуемся жизни. Новый приватный ключ создан, записан на Yubikey, публичная же часть ключа упала в ~/.ssh/id_ed25519_sk.pub.
ㅤ

Да, рядом будем лежать файл id_ed25519_sk, но это ничего не меняет, это не приватный ключ, приватный ключ НЕ хранится на диске, он сразу записывается в Yubikey. А то что ты видишь у себя на диске, это дескриптор (handle). Этот файл содержит идентификатор Yubikey ключа, параметры и ссылку на resident key. Приватный ключ физически находится внутри YubiKey и не может быть извлечён.

А дальше по классике. Закидываем публичную часть ключа на нужный сервер и пробуем подключиться:

ssh root@bashdays.ru

Confirm user presence for key ED25519-SK

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

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

Фиксим баги:

После того как ты достанешь ключ из USB и затем воткнешь обратно. Всё к хуям сломается. Вот такая особенность винды и WSL2. Поэтому делаем финт ушами. Пишем powershell скрипт, который будет это фиксить.

Создаем файл YubiKeyAttachToWSL.ps1

$yubiKeyBusId = (usbipd list | Select-String "1050:0407" |
ForEach-Object { $_.Line.Split()[0] })
if ($yubiKeyBusId) {
    usbipd attach --wsl --busid $yubiKeyBusId
    Write-Host "YubiKey attached…"
} else {
    Write-Host "YubiKey not found."
}

Не забываем изменить ID вендора и продукта. Закидываем скрипт в виндовый планировщик с параметрами:

Триггер:

- At log on (при входе в систему)
- On Event (событие USB)
- Log: System, Source: WudfUsbccidDrv, Event ID: 104

Действие:

- Запуск powershell.exe с аргументами -ExecutionPolicy Bypass -File "C:\YubiKeyAttachToWSL.ps1"

Теперь этот скрипт будет запускать при входе в систему ну и если ты будешь тыркать Yubikey туда-сюда в USB портах. Автоматизация ёпта!

Всё! Поставленная задача успешно решена. Что важно, тут не только потыкали Yubikey + SSH, но и научились прокидывать USB устройства в WSL2.

Всё остальное поищешь сам, информации полно. Я показал тебе лишь неочевидные штуки, которые могут загнать в тупик и свести с ума.

Изучай!

🛠 #security #privacy
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

В общем, поставил я себе opnSense и захотелось знать, не гуляют ли у меня в сети какие-нибудь «призраки». Решил написать скрипт для контроля связки IP-mac.

🔤🔤🔤🔤🔤🔤🔤

Первая часть тут: https://xn--r1a.website/bashdays/1356

У меня три подсети 192.168.0.0 = DMZ 192.168.1.0 = LAN, 192.168.2.0 = WIFI. Что творится в сети WIFI, меня не очень интересует, поскольку доступа из неё нет не только к LAN, но и к DMZ. Поэтому наблюдать будем две последние.
ㅤ
И да, у меня там статика. Есть конечно и DHCP, но буквально на пару адресов, на всякий случай.
Скрипт пришлось разбить на две части, потому что у csh не очень красивые переносы очень длинных строк.

#!/bin/csh
#checkarp.sh

set dt=`date "+%s"`
set bot_id=0000000000:AAAAAAAAA1_aaaaaaaaaaaaaaaaaaaaaaa1
set chat_id=1111111111
set text="GATE: Есть изменения arp $dt" 

arp -an| \
  awk -v dt=$dt -f "$0.awk" /dev/stdin "$0.spr" >>"$0.spr"
if ( $status != 0 ) then

  curl -s -X POST https://api.telegram.org/bot$bot_id/sendMessage \
       -F chat_id="$chat_id" -F text="$text" >/dev/null

endif

Этот скрипт сравнивает значения текущих IP и mac, со значениями, сохраненными в файле checkarp.sh.spr.

Если появилась новая связка — отправляется сообщение в телеграм о ВРЕМЕНИ появления(контроля) новых данных в формате UNIXTIME, и новая связка IP-MAC сразу дописываются в справочник spr.

Сами данные в телегу не отправляются — чтобы узнать, что появилось, придется залезть на машину и посмотреть grep/tail. Сделано это специально, чтобы лишний раз не светить инфраструктуру.

Ставим его на cron */15, потому что время жизни arp 20 минут (видно из вывода arp). Работает под обычным пользователем.

#checkarp.sh.awk

    /[0-9a-f]{2}(:[0-9a-f]{2}){5}/{
      if(NF==3){spr[$2 " " $3]}
      else{ if( NF>3 && $0~/192\.168\.[01]\./){gsub(/[()]/, "", $0);  arp[$2 " " $4]}}
    } 
    END{
      ret=0
      for(i in arp){
        seek=0
        for(j in spr){
          if(i==j){
            seek=1; break
          }
        }
        if(seek==0){ret=1; print dt, i}
      }
      exit ret
   }

Основная часть на awk.

1. Анализируем только строки, в которых есть mac.
2. Файлы справочника и вывод arp разделяем по числу полей (в справочнике их три: unixtime ip mac).
3. Из вывода arp убираем все, что не относится к подсетям DMZ и LAN.
4. Тупо сравниваем связки каждый с каждым. (осторожно на больших подсетях, поскольку N^2).
5. Если что-то нашлось - errorlevel=1.

Все можно было бы сделать быстрее и проще, но очень хотелось:

6. Отказаться от временных файлов.(в opnSense нет /dev/shm).
7. Данные дописываются в тот же справочник, из которого читаются. Это можно сделать, потому что на момент анализа (блок END) данные из справочника уже считаны и файл закрыт.

Вопросы и предложения приветствуются.

man arp awk(gawk)

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

UPD: В комментах скрипт на sh

🛠 #networks #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Продолжаем параноить. Сегодня будем создавать шифрованную капсулу времени. То есть зашифрованные данные, невозможно будет расшифровать до какой-то определенной даты.

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

Для реализации желаемого, воспользуемся утилитой под названием tlock.

TLock — это шифрование с отложенным доступом, которое опирается на доверенную аппаратную среду (TEE, чаще всего Intel SGX). Идея всего этого безумия до безобразия простая и красивая:

— данные шифруются сейчас
— ключ не существует в открытом виде
— расшифровка после определённого времени
— даже владелец не может ускорить процесс
ㅤ
Есть TEE (Trusted Execution Environment), работает на drand (League of Entropy) + threshold BLS + Identity-Based Encryption. Дада, Artmoney тут тебе не поможет. Внутри TEE генерируется секрет, считается время, вычисляется ключ.

Ключ == f(секрет, время)

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

Короче это нифига не cron + sleep, timestamp и т.п. Это прям технолоджи!

Устанавливаем:

1. Качаем бинарник для своей ОС: https://github.com/drand/tlock/releases/
2. Кидаем куда удобно, я закинул в /usr/local/sbin

Создаем условный файл:

cd /tmp
echo "hello bashdays" >> bashdays.txt

Шифруем:

tle -e -D 10d -o bashdays.tlock bashdays.txt

Этот файл можно будет расшифровать только через 10 дней. Если сейчас посмотреть файл bashdays.tlock то увидим кучу мусора:

age-encryption.org/v1
-> tlock 26260588 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971
jhUpzCk/LXUTkwghwKbyGH1gZ2BEy3p47X4yf+8qrv7+BIhJvEUK6QsVZNnZupxK
CsP1d2kGQAsy6GfEc544aZURB3zK3999bQbXzuhA0u4JV0J27ZqnjKBdtx2az603
tF54aRojO3OmwC2JNTkO/ObQID2xJTTidpgP8K1AEac
--- pN0y6uBfL8KOcoXKp1U6T0gbrWrgDoCmwJxBZ7LHspw
#�4x�&V����S�&e`�S�`���
z��? �A��%

Попробуем расшифровать:

tle -d -o bashdays.txt bashdays.tlock

И получаем: иди нахуй too early to decrypt: expected round 26260588 > 25972610 current round. Файл можно будет расшифровать только через 10 мать его дней. И пофигу root ты или супер ксакеп, нихуя у тебя не получится проникнуть в эту капсулу времени.

Пример в псевдокоде:

# encryption
ciphertext = TLock.encrypt(
    data=plaintext,
    unlock_time=TIMESTAMP
)

# decryption
if now() >= TIMESTAMP:
    plaintext = TLock.decrypt(ciphertext)
else:
    raise Nope("слишком рано")

- key нигде не лежит
- key нельзя украсть
- key нельзя вычислить заранее

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

Век живи, век учись. Кстати эта технология применяется в крипте, насколько знаю в Ethereum.

Кстати для шифрования бекапов прям прикольная штука, юморная.

🛠 #security #privacy
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

В последних двух моих статьях я рассказывал о том, как я перешел с pfSense на opnSense и попытался заменить arpwatchd самописным скриптом. Здесь я расскажу, с какими «проблемами» пришлось столкнуться.

🔤🔤🔤🔤🔤🔤🔤

Первая статья: https://xn--r1a.website/bashdays/1356
Вторая статья: https://xn--r1a.website/bashdays/1360

Началось с того, что я тупанул. Я знал, что pfSense и opnSense основаны на BSD, и знал, что обычно там отсутствует bash.
ㅤ
И почему-то подумал, что придется писать скрипт на csh (tsch). Я не знаю csh, но принципиальных отличий нет.

Ну, скрипт и скрипт. Небольшие отличия в синтаксисе. if и while присутствуют, значит проблем нет. Это действительно так. Самой большой проблемой стал перенос длинных строк даже в константах:

#!/bin/bash
echo '1
2
3'

#!/bin/csh
echo '1 \
2 \
3'

Это делает однострочники (в моем случае awk) крайне уродливыми. Когда скрипт уже работал, я решил проверить, какие там есть оболочки cat /etc/shells , и с изумлением обнаружил /bin/sh.

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

Были небольшие затыки с программами. Вроде date, как date, но ключики немного не совпадают. Я думал там gawk, но нет, awk. (не нашел разделы BEGINFILE{...} ENDFILE{...}). Но, при большом желании можно обойтись и без них.

Что порадовало, так это наличие man в opnSense. В pfSense его не было. И это очень круто.

Очень жаль, что не нашел ramdisk /dev/shm (в Linux он обычно есть и под него выделено половину оперативки).

Ну, и еще одной проблемой стал редактор vi, который оказался единственным в системе!!!

ed, red, sed не в счет, хотя, если припрет... В pfSense был еще nano.

Я в последнее время использую vim (который начал изучать после рекомендаций Дмитрия Малинина здесь, на BashDays. За что ему спасибо.) Кто еще не начал - ставьте vim, и запускайте vimtutor. Этого будет достаточно, чтобы как-то работать в vi и vim.

Вывод из всего этого - nix это круто. И не важно - Linux или BSD. Они очень похожи, по крайней мере, если знаешь что-то одно - разобраться не проблема. Принципы одинаковые.

Холиваров прошу не устраивать. Просто решил поделиться опытом. Если где-то ошибся - поправьте.

🛠 #networks #linux #bash
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Контекстная конфигурация в git

При работе с git репозиториями, частенько попадаешь в просак с таким:

git config --global user.name
git config --global user.email

Один раз забил свои явки-пароли и затем git при любом коммите или пуше будет подставлять эти данные. То есть в историю коммитов будет забиваться user.name и user.email. Это логично и понятно.
ㅤ
Но если у тебя смешаны личные и рабочие репозитории, начинается цирк с конями. Я тысячу раз комитил в рабочую репу под личным user.name и user.email и получал за это по рукам. Получал конечно сам от себя.

Потому что смешивать личное и рабочее — фуфу!

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

Расчехляем хоумлабу!

У нас будет 2 папки:

mkdir -p ~/projects/personal
mkdir -p ~/projects/work

Настраиваем основной конфиг:

vim ~/.gitconfig

[user]
    name = Roman Shubin
    email = shuba@bashdayz.ru

[includeIf "gitdir:~/projects/work/"]
    path = ~/.gitconfig_work

Нюанс: / в конце work обязателен. Git интерпретирует gitdir: как префикс пути к каталогу .git.

Создаем рабочий конфиг ~/.gitconfig_work

[user]  
  name = Linux Factory
  email = exe@linuxfactory.ru

На этом танцы с бубном закончились, проверяем:

mkdir -p ~/projects/personal/app  
cd ~/projects/personal/app  
git init

git config user.email
git config --show-origin user.email

Ага, видим что для личных проектов будет применяться shuba@bashdayz.ru и берется он из ~/.gitconfig. Последние 2 команды, как раз выводят эту информацию в терминал. Хорошо, теперь:

mkdir -p ~/projects/work/app  
cd ~/projects/work/app  
git init

git config user.email
git config --show-origin user.email

Да твоюж мать! Видим Linux Factory и exe@linuxfactory.ru. Что и требовалось доказать, данные берутся из файла ~/.gitconfig_work.

Всё, мы успешно разделили контекст между личными и рабочими проектами. Таких инклудов ты можешь насоздавать сколько угодно. Самое главное это работает без костылей и каких-то лишних обвесов вокруг git.

Git скрывает очень много интересного и не всегда это очевидно. Такие дела, изучай!

🛠 #devops #linuxfactory #dev
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Фарш обратно не провернёшь
ㅤ
Порой в Bash поделках требуется создать какой-нибудь секрет, для дальнейшей его передачи в CI/CD или куда-то еще. Ежу понятно, это можно сделать «в лоб», но мыж с тобой не волки позорные, поэтому давай сделаем это по всем правилам DevSecOps Best Practice. (* лучшие практики безопасной разработки).

Задача: Создать безопасно секрет, чтобы его не спиздили (например из свапа при форензике).

Форензика — это направление информационной безопасности, связанное с анализом и восстановлением данных для расследования инцидентов

Кто-то извращается со shred и т.п. утилитами, но это избыточно, да и на SSD, Btrfs, ZFS и journal FS оно будет работать хуева и не гарантирует физическое уничтожение данных. Лучше на диск вообще ничего не писать.

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

#!/usr/bin/env bash

set -euo pipefail

SECRET="$(openssl rand -base64 32)"

printf '%s' "$SECRET" | \
openssl enc -aes-256-cbc -salt -pbkdf2 -iter 200000 \
  -in input.txt \
  -out output.enc \
  -pass stdin

unset SECRET

Что тут происходит?

Ничего необычного, генерим 32 случайных байта, кодируем в base64, получаем пароль высокой энтропии, затем через printf передаем пароль (без \n) через pipe в stdin.

Ну и в конце скармливаем какой-нибудь утилите или в CI/CD, куда нужно передать секрет, в моем случае я передал его в openssl.

По итогу секрет, не попадает в history, не лежит на диске и временно находится в памяти. Но важно понимать, что после unset SECRET переменная удаляется только из таблицы переменных, в памяти эта переменная может по-прежнему храниться и быть уязвима к форензике. Поэтому носи это в голове и по возможности перезатирай память например тем же stress.

А еще оно может попасть в swap и это еще хуже, swap это прям как неочищенная «корзина» с удаленными файлами.

На bash этот момент описать наверное не получится, поэтому покажу как сделать на Сиськах. Будем использовать mlock().

#include <sys/mman.h>
#include <string.h>
#include <stdio.h>

int main() {
    char secret[32] = "super_secret_password";

    if (mlock(secret, sizeof(secret)) != 0) {
        perror("mlock failed");
        return 1;
    }

    printf("Secret in locked memory\n");

    // Используем секрет...

    memset(secret, 0, sizeof(secret)); // затираем
    munlock(secret, sizeof(secret));

    return 0;
}

Когда этот код будет вызывать mlock(), указанный диапазон памяти закрепляется в RAM и ядро не имеет права выгружать его в swap.

Получается что сначала mlock() блокирует участок памяти, затирает memset() её перед освобождением и с помощью munlock() снимает блокировку.

Кстати mlock() используют GnuPG, OpenSSH, HashiVault, KeePassXX. Так что вариант надежный, можешь не сомневаться. А еще иногда используется mlockall():

mlockall(MCL_CURRENT | MCL_FUTURE);

Блокируется вся текущая и будущая память процесса, активно применяется демонами в HashiVault.

Такие дела.

Накидай еще своих вариантов в комменты, будет интересно ознакомиться.

🛠 #dev #security #bash
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Вчера в чатике интересный комментарий пролетел:

Если открыть файл в vim, то lsof покажет этот файл открытым. А вот если открыть файл в nano, то lsof не факт, что покажет этот файл открытым. Ну видимо nano не постоянно держит открытым файл.

Давай покопаем глубже и посмотрим что происходит. Расчехляем лабу!
ㅤ
В первом терминале запускаем:

echo "secret data" > test.txt
nano test.txt

Во втором запускаем глазища:

sudo strace -e open,openat,write,close -p $(pgrep nano)

Пока пусто. Теперь в первом терминале нажимаем CTRL+O и смотрим выхлоп во втором терминале:

openat(AT_FDCWD, "test.txt", O_WRONLY|O_TRUNC) = 3  
write(3, "secret data\n", 5) = 5  
close(3) = 0

Получается nano запихивает весь файл в RAM и только после манипуляций с ним производит запись на диск, то есть не держит его постоянно открытым. По этой причине lsof ничего и не показывает.

Теперь идем в vim и повторяем предыдущие команды:

vim test.txt

Но во втором терминале запускаем:

watch -n 0.01 "lsof | grep test.txt"

И сразу же видим что lsof показывает открытые файлы:

vim 6423 user 5u REG 8,48 12288 11148 /tmp/.test.txt.swp
vim 6423 6424 vim user 5u REG 8,48 12288  11148 /tmp/.test.txt.swp

Но это не сам файл test.txt, это его swap версия, то есть создается еще один файл. Если открыть такой файл, то в нем будет мусор:

0000000 3062 4956 204d 2e39 0031 0000 1000 0000
0000010 bfdc 69a7 b9a1 0000 1917 0000 7375 7265
0000020 0000 0000 0000 0000 0000 0000 0000 0000

Этот файл, vim использует для crash recovery, undo history, file already open, incremental writes и т.п. Получается что vim постоянно держит открытый swap, а не исходный файл.

Если выполнить:

lsof -p 6423

То увидим всю подноготную этого процесса включая дескрипторы.

Ну и финт ушами. В первом терминале выполняем:

vim test.txt

Во втором:

mv test.txt test.old

И видим что vim грязно выругался: E211: File "test.txt" no longer available.

А если все то же самое проделать с nano то он даже не пискнет, потому что файл загружен в память и ему похеру что мы физически снесли файл с диска. Можно снова нажать CTRL+O и он даже предложит нам его сохранить со старым именем.

Вот тут уже можно почесать репу, получается nano работает быстрее чем vim? Неа, vim тоже загружает файл в память (buffer ram). А swap файл это всего лишь журнал изменений либо undo-файлы. Swap не заменяет память, он выступает в роле дополнительного инструмента.

Схема для vim такая:

disk file → RAM buffer (vim)
                ↓
            swap file (.swp)

Схема для nano попроще:

disk file → RAM buffer

В nano нет ни рекавери, не другой подобной хуйни-муйни. Ну а по скорости, разницы практически нет (если файлы небольшие), файлы читаются один раз, оба редактора работают в памяти, ну а linux page cache делает чтение еще быстрее.

Если файлы большие, vim все же предпочтительнее, у него более продвинутый механизм по работе с буферами.

Так и живем!

🛠 #debug #strace
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Отдам котёночка в добрые руки 🙃

Пристрою в хорошую команду DevOps-инженера. Ласковый, к инфраструктуре приучен, в продакшене не гадит. С отличием окончил Linux Factory и имеет все необходимые навыки.

Что умеет:
— автоматизировать Linux-сервера через Ansible (roles, порядок, идемпотентность — всё как надо)
— строить CI/CD в GitLab и деплоить конфигурации без шаманства
— Docker, GitLab Runner, Bash/Python для автоматизации
— мониторинг Prometheus + Grafana
— vulnerability management, базовый pentest и security-мышление

Работал с инфраструктурой 35k+ серверов, сокращал подготовку серверов с часов до минут, избавлялся от ручной рутины и наводил порядок в конфигурациях.

Из плюсов:
— думает про безопасность, а не только «чтобы работало»
— автоматизирует всё, что можно автоматизировать
— спокойно относится к продакшену

Котёночек самостоятельный, аккуратный, любит инфраструктуру и CI/CD. Отдаётся в команду, где есть сервера, пайплайны и желание жить без рукоблудия.

Писать сюда: @hydragoozze

🛠 #биржатруда
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

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

🔤🔤🔤🔤🔤🔤🔤

Вы все люди взрослые, но на всякий случай напомню, что использовать sftp с паролем категорически противопоказано. И это важно не клиенту. Это важно серверу. Нужно обязательно использовать ключ. Да, сам ключ может быть без пароля, что фактически превращает ключ в тот же самый пароль, в случае хищения, но для сервера так безопасней.

Обычно для обработки в скрипте используют heredoc, но есть и другой путь, через конвейер.

echo -e "ls\\ncd /tmp\\nget 123.txt\\nbye"|sftp -i keyfile user@host:/path/to/dir

Здесь \\n - это код перевода строки. Не красиво, но работает.

Вот тут есть небольшая тонкость, которую хотелось бы пояснить.

Весь пакет команд будет выполнен, вне зависимости от ошибок. Т.е. если был запрошен переход в каталог, которого не оказалось, а потом команда заливки файла - файл будет залит в текущий каталог, и никто об этом не узнает.

Для решения проблемы есть специальный ключ -b (batch mode) который позволяет читать sftp-скрипт из файла. Чтобы (как в нашем случае) читать stdin, нужно указать -b- , или совсем конкретно -b "/dev/stdin".

При использовании данного ключа, если команда не выполнена, sftp завершается с ошибкой, все дальнейшие команды игнорируются. А эту ситуацию можно обработать стандартными средствами bash.

Но и здесь есть исключения. Если команду указать с префиксом "-", то она переходит в разряд опциональных, и в случае ошибки, sftp-скрипт будет продолжен. Например -get 123.txt. Кроме этого префикса есть еще префикс "@", который подавляет печать(вывод) команды при выполнении. Префиксы равнозначны, могут использоваться в любой последовательности.

Знания почерпнуты из man, при попытке перевести обмен между 1c с ftp на sftp. Если тема интересна, могу привести рабочий скрипт обмена, и рассказать, почему я от него в итоге отказался.

man sftp

Всем кода без багов.

🛠 #linux #bash
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Если человеку отрубить ногу, это не значит что он стал пиратом.
ㅤ
Ай да вкуснятинку я тебе принёс. Пошел хайп на MP3 плееры и музыку в первоначальном виде, то есть без цензуры. Кто не знает, с 1 марта снова закрутили гайки и артистов обременили зацензурить все свои произведения. Теперь большинство песенок либо «запикано», либо смысл полностью изменен.

Поговорка «Из песни слов не выкинешь» заиграла новыми красками. Ладно, к делу.

Soulseek — кросплатформенная софтина для peer-to-peer (P2P) обмена файлами, в первую очередь — музыкой. Она позволяет пользователям напрямую обмениваться файлами между своими компьютерами через пока еще доступный интернет.

Помимо музыки, можно найти массу всего интересного, включая софт.

Помню в начале 2000х было нечто подобное, вроде как «осёл» назывался (eDonkey, eMule).

Суть soulseek — расшарить на компе папку и поделиться со всеми, как в старые добрые.

Можно ничего не шарить и только потреблять. Что прикольно, музло можно сразу качать дискографиями, а не отдельными песнями. И это музло НЕ будет «зацензурено».

Удобно? Да охуенно! Пойду поищу свой старенький digma mp3 плеер, да погружусь в вайб.

А какой у тебя был MP3 плеер? Поделись в комментах если еще помнишь.

UPD: В комментариях есть ссылка на альтернативный клиент на гитхабе. Можно как Self-Hosted решение запустить.

Хорошей тебе рабочей недели. Не болей!

🛠 #soft #services #music
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Вчера работало. Сегодня — Legacy.

Переехать полноценно на linux я пока не смог, оказалось много завязок на винду, но яндекс.браузер был успешно заменен.
ㅤ
Сначала мой выбор пал на ARC, но как оказалось разработчики забили на него хуй. Поэтому коллеги из mastodon посоветовали попробовать ZEN.

Иии он полностью оправдал ожидания. Тем более оно на движке Firefox и отлично кастуется как визуально, так и функционально. А самое главное, в нем нет встроенных ИИ.

Подкупило меня именно наличие WorkSpaces. У меня есть 4 категории вкладок:

1. Все подряд (побегать по сайтам)
2. Self-Hosted (домашние сервера и сервисы)
3. GPT (несколько нейронок)
4. Бухгалтерия (отчетность, диадоки-хуёки всякие)

Раньше я группировал их в «группа вкладок», но теперь навесил workspaces на горячие клавиши «ALT+1, ALT+2…», стало намного удобнее и быстрее переключаться, возникает меньше путаницы.

Дополнительно к workspaces можно создавать папки под вкладки, например нашел что-то интересное, закрывать жалко, но и сейчас нет времени разбираться. Перенес вкладку в папку, она там висит и не тревожит моё внимание. Ну там всякий сплит окон типа терминального tmux.

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

Что по глюкам? Да пока не наблюдаю, тормозов не ощущается, рутокен работает, нет ощущения, что пересел с лексуса на девятку, дальше уже посмотрим.

Присмотрись, возможно зайдет и наконец организуешь свои 100500 открытых вкладок которые жалко закрывать.

🛠 #soft
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Как кубер и докер дебажить???

Ладно, выдеру кусок из будущего сезона LF, s4e18 пусть побудет публичным, ради тебя ничего не жалко.
ㅤ
…

Чуть раньше я уже писал подобный пост для докера «основные методы отладки», но там освещены не все моменты.

Зачастую используются «тулбоксы», это такие специальные docker контейнеры, которые содержат в себе все самые необходимые утилиты для этого самого дебага. Такие «тулбоксы» можно делать самостоятельно, а можно воспользоваться готовыми.

Один из самых популярных, это netshoot, в него включено свыше 50ти консольных утилит на все случаи жизни. Основной упор сделан на диагностику сетевой хуйни.

Например:

kubectl run netshoot --rm -it --image=nicolaka/netshoot

Теперь можно выполнить:

dig service.bashdays.svc.cluster.local  
curl http://service:8080

Или зайти в network namespace pod:

kubectl debug pod/myapp -it --image=nicolaka/netshoot

Короче если какой-то сервис не работает, запускается netshoot делается DNS проверка dig service, проверка TCP nc service 5432, смотрим пакеты tcpdump -i any port 5432 и т.п.

Довольная удобная штука, ничего выдумывать не нужно. Аналогично создаются другие «тулбоксы» со своим содержимым и утилитами.

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

Самое важное здесь, разместить этот образ на РФ серверах, чтобы рядышком был и никакие блокировки бы его не касались. Да и тот же `netshoot` желательно к себе утащить в норку.

Чем еще подебажить:

- k8s-toolbox
- Busybox
- dnsutils
- Network Multitool

А в новых версиях куба активно используют Ephemeral containers, как раз тот самый kubectl debug. Можно внедрить debug container прямо в pod.

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

Ну а теперь давай создадим искусственную проблему и попытаемся её диагностировать с помощью этих самых «тулбоксов».
….

На этом всё, изучай!

🛠 #devops #debug #docker #k8s
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog