Hacking Ready | InfoSec

Пишем скрипт для автоматической проверки срока действия сервисных API-токенов.

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

Создадим тестовый JWT-токен и запишем его в файл для последующего анализа скриптом.

cat token.txt
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkbWluIiwiZXhwIjoyNTI0NjA4MDAwfQ.signature
EOF


Тестовый JWT-токен с фиксированным временем жизни успешно сформирован.

Напишем Bash-скрипт check_token.sh, который декодирует пейлоад JWT и сравнивает дата-штамп истечения с текущим временем.

cat check_token.sh
#!/bin/bash
TOKEN=$(cat token.txt)
PAYLOAD=$(echo "$TOKEN" | cut -d'.' -f2 | base64 -d 2>/dev/null)
EXP=$(echo "$PAYLOAD" | grep -o '"exp":[0-9]*' | cut -d':' -f2)
NOW=$(date +%s)
DAYS=$(( (EXP - NOW) / 86400 ))
echo "[+] Токен действителен еще $DAYS дней"
EOF
chmod +x check_token.sh


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

Запустим проверки статуса и оставшегося срока действия токена.

./check_token.sh


Скрипт успешно декодировал токен и вывел количество оставшихся дней до истечения.


# проверка (контрольная проверка корректности парсинга даты токена)
./check_token.sh | grep -q "действителен" && echo "Проверка токенов работает"


Ожидаемый вывод: Проверка токенов работает


# cleanup (удаление временных файлов скрипта и токена)
rm -f token.txt check_token.sh


Регулярная валидация сроков действия ключей через cron предотвращает простои критических сервисов и внешних интеграций. Интегрируйте этот скрипт в свой мониторинг для отправки алертов в Telegram при остатке менее 7 дней.

➡️ Hacking Ready | #практика

Разворачиваем локальный сервер централизованного сбора логов Syslog-ng.

Децентрализованное хранение журналов на разных серверах затрудняет расследование инцидентов и позволяет злоумышленникам заметать следы. Поднятие единого сервера Syslog-ng позволяет собирать логи со всей инфраструктуры в реальном времени и защищать их от модификации. Мы развернем и настроим прием лог-событий по протоколу UDP на порту 514.
Установим Syslog-ng в систему с помощью стандартного пакетного менеджера.

sudo apt-get update && sudo apt-get install -y syslog-ng


Пакет Syslog-ng успешно установлен и готов к конфигурированию.

Создадим конфигурационный файл syslog-ng-custom.conf, определяющий прием сетевых логов и их сохранение в отдельные файлы по хостам.

cat syslog-ng-custom.conf
source s_net { udp(ip(0.0.0.0) port(514)); };
destination d_clients { file("/var/log/remote/${HOST}.log"); };
log { source(s_net); destination(d_clients); };
EOF


Конфигурация приема сетевых логов по UDP сформирована и готова к подключению.

Запустим экземпляр Syslog-ng в тестовом режиме с указанием нового файла конфигурации.

sudo syslog-ng -f syslog-ng-custom.conf -F &


Сервер сбора логов запущен в фоновом режиме и прослушивает сетевой порт.


# проверка (проверка прослушивания порта 514 утилитой netstat или ss)
ss -ulpn | grep 514


Ожидаемый вывод: UNCONN 0 0 0.0.0.0:514 0.0.0.0:*


# cleanup (остановка тестового процесса syslog-ng и удаление конфига)
pkill syslog-ng && rm -f syslog-ng-custom.conf


Централизованный сбор логов необходим для корректного проведения расследований и своевременного обнаружения аномалий. Для боевых окружений обязательно используйте протокол TLS поверх TCP вместо открытого UDP-трафика. Выполнять только в изолированной среде / по разрешению.

➡️ Hacking Ready | #практика