Взломали роутер, логи стёрты: настраиваем центральный syslog-сервер

Несколько недель назад к нам пришли с неприятной историей. У клиента взломали периметровый роутер - Linux-машина, смотрит в интернет, раздаёт NAT. Зашли через брешь в старом демоне, получили рут, погуляли по сети. Когда мы разбирались, что произошло и когда, столкнулись с очевидным: логи на самой машине были стёрты. Не частично - полностью. /var/log/syslog, /var/log/auth.log - пусто. Нечего читать, нечего восстанавливать.

Это не экзотика. Это стандартное поведение при взломе: первое, что делает атакующий после получения доступа, - чистит следы. И если логи лежат на той же машине, которую взломали, они исчезнут вместе со следами.

Почему локальные логи не работают как доказательная база

Схема проста: атакующий зашёл, получил права, запустил > /var/log/syslog или просто снёс файлы. Можно, конечно, ставить права 644 и readonly-флаги через chattr, но это паллиатив. Если у него рут - он и chattr снимет.

Единственный способ сохранить логи от машины, которую могут взломать, - отправлять их в реальном времени куда-то, куда у этой машины нет доступа на запись. Логи ушли по UDP - и всё, они там. Пока атакующий ещё только осматривается, записи уже на другом хосте.

Это и называется централизованным syslog-сервером. Не новая идея, но у нас она до сих пор не была внедрена нигде, кроме одного клиента. После этого инцидента - решили исправить.

Схема

[ роутер / шлюз ]  --UDP 514-->  [ syslog-сервер ]
[ файловый сервер ] --UDP 514-->  [ внутри сети, нет публичного доступа ]
[ рабочие станции ] --UDP 514-->  [ логи пишутся в файлы по IP ]

Syslog-сервер - отдельная машина или виртуалка внутри сети, у которой нет исходящего доступа к роутеру и другим устройствам. Только приём входящих на 514/udp.

Настройка на сервере (Debian)

Используем стандартный syslogd из пакета sysklogd. В /etc/syslog.conf добавляем приём с удалённых хостов:

В /etc/default/syslogd меняем строку запуска:

SYSLOGD="-r -m 0"

Флаг -r включает приём UDP-пакетов на порту 514. Флаг -m 0 отключает периодические метки времени в логах - они только мешают читать.

Затем в /etc/syslog.conf добавляем правило для хранения по файлам:

# Все входящие с удалённых хостов - в отдельную папку
*.* /var/log/remote/all.log

Можно тоньше - разбивать по хостам. Для этого используем $template и ?DynFile в rsyslog, если он установлен. В базовом syslogd придётся написать небольшой скрипт-обёртку или складывать всё в один файл и потом grep по имени хоста.

Перезапускаем: invoke-rc.d sysklogd restart. Проверяем, что слушает 514: netstat -ulnp | grep 514.

Настройка на клиентах

На каждой машине, которая должна отправлять логи, в /etc/syslog.conf добавляем строку:

*.* @192.168.1.50

Символ @ означает UDP, адрес - IP нашего syslog-сервера. Всё. Перезапускаем syslogd - и логи начинают уходить.

Для сетевых устройств типа управляемых коммутаторов и роутеров на Cisco IOS команда такая:

logging 192.168.1.50
logging trap informational

Там тоже UDP syslog, и тоже уходит в реальном времени.

Что сразу вылезло

Когда мы включили приём на сервере и подключили несколько машин, первые же часы показали интересное. Один из серверов слал в логи ошибки авторизации примерно раз в минуту - кто-то перебирал пароли SSH. Без централизованных логов мы бы это не заметили: в /var/log/auth.log на самой машине записи были, но никто туда не смотрел. Когда всё пришло в одно место и стало заметно - картина сразу другая.

Это ровно то, о чём мы писали про мониторинг: данные не решают проблемы сами по себе, но без данных вы вообще не знаете, есть ли проблема.

Что не решает UDP syslog

UDP - ненадёжный протокол. Пакет может потеряться. Если канал перегружен или сервер лежит - часть записей не дойдёт. Для большинства случаев это приемлемо: атакующий не может «перехватить» пакет обратно, он уже ушёл. Но если нужна гарантированная доставка - смотрят в сторону syslog через TCP или более продвинутые решения.

Второй момент - аутентификация нулевая. Любая машина в сети может слать что угодно на 514/udp и это запишется. Syslog-сервер должен быть в закрытом сегменте сети, доступном только для авторизованных хостов. У нас так и сделали: правила на шлюзе блокируют 514/udp снаружи, внутри сети - открыто для нужных хостов.

Итог

Установить это несложно - час работы, если знаешь что делать. Сложнее было убедить себя, что оно нужно, пока ничего не случилось. Как обычно, сначала инцидент, потом правило. Теперь у всех клиентов, где есть Linux на периметре, syslog-сервер идёт в базовую конфигурацию. Роутер взломают - логи останутся.