Практически всяко ръководство за Suricata завършва с инсталиране на Elasticsearch, Logstash и Kibana. За един VPS това е лош съвет: тази връзка иска четири гигабайта памет и постоянен надзор, а вие искахте само да видите какво е уловила IDS за денонощие. Suricata работи отлично и без тях — но има особеност, заради която мнозина я инсталират и след седмица я премахват.
Мината в настройките по подразбиране
Направо от кутията Suricata пише в eve.json над тридесет вида събития: не само известия, а всяка DNS заявка, всяко TLS ръкостискане, всяка HTTP транзакция, ARP, DHCP, поток след поток. Плюс отделен stats.log на всеки осем секунди. Ротация на журналите Suricata при това изобщо не настройва — това е задача на администратора, за която никъде не пише с едри букви.
Цифра от реален сървър: 15 гигабайта за две денонощия — девет в eve.json и почти шест в stats.log. До пълен диск оставаха около пет дни. Трафик на сървъра при това имаше малко; на натоварен възел щеше да става дума за часове.
Проверете при себе си веднага:
sudo du -sh /var/log/suricata/*
Оставете само това, което четете
Ако гледате известия, а не се занимавате с мрежова криминалистика, от eve-log ви трябва точно един вид събития. В /etc/suricata/suricata.yaml намерете блока outputs и в types при eve-log оставете alert, останалото коментирайте. На същото място изключете извеждането на статистика:
- stats:
enabled: no
След промяната — задължителна проверка на конфигурацията, преди рестартирането на услугата:
sudo suricata -T -c /etc/suricata/suricata.yaml -v
Редът има значение: тестът няма да мине, ако правилата още не са изтеглени. Първо suricata-update, после проверката на конфигурацията, после стартирането.
Ротация, която наистина работи
Файлът /etc/logrotate.d/suricata:
/var/log/suricata/*.log /var/log/suricata/*.json {
daily
rotate 7
maxsize 200M
missingok
compress
delaycompress
create 0664 suricata suricata
su suricata suricata
postrotate
systemctl kill -s HUP suricata
endscript
}
Два реда тук не са очевидни и двата са критични.
su suricata suricata — без него logrotate мълчаливо пропуска всички файлове. Директорията /var/log/suricata принадлежи на групата suricata, а не на root, и logrotate смята такава конфигурация за несигурна. Грешка няма да дойде нито по пощата, нито в журнала; просто ще сте убедени, че ротация има, докато не свърши дискът. Единственият начин да се улови това предварително е празен ход:
sudo logrotate -d /etc/logrotate.d/suricata
create 0664 suricata suricata — правата на новия файл. С правата по подразбиране (0640) всеки панел или скрипт, който чете журналите не като root, след първата ротация ще вижда празнота.
Какво да се настрои освен журналите
HOME_NET. Това е описанието на онова, което Suricata смята за „свое“. Стойността по подразбиране изброява всички частни диапазони, а VPS има публичен адрес — в резултат част от правилата не се задействат или се задействат наопаки. Посочете своята мрежа изрично.
Правила. Наборът Emerging Threats Open се изтегля с командата suricata-update, която се слага в cron веднъж дневно. Отделни шумни сигнатури се изключват в /etc/suricata/disable.conf по идентификатор — не се страхувайте да го използвате: наборът е разчетен за корпоративна мрежа и десетина правила на обикновен уеб сървър ще се задействат постоянно и без причина.
Режим. По подразбиране Suricata слуша копие на трафика и само предупреждава (IDS). Режимът на блокиране (IPS, през nfqueue) на единствен сървър е риск преди всичко за вас самите: един фалшив сигнал и сте си затворили достъпа. Започнете с наблюдение и цял месец гледайте какво се улавя.
Как се чете без Kibana
Кратките известия са в /var/log/suricata/fast.log — по един ред на събитие, чете се с око:
sudo tail -50 /var/log/suricata/fast.log
Подробностите са в eve.json, по един JSON обект на ред. Всичко, заради което обикновено се инсталира Kibana, се прави с една команда:
sudo jq -r 'select(.event_type=="alert") | .alert.signature' \
/var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -20
Това са двадесетте най-чести сигнатури. Такъв списък за седмица честно отговаря на въпроса какво изобщо се случва със сървъра и същевременно показва кои правила е време да се изключат.
Защо това, щом вече има Fail2ban
Различни са по природа. Fail2ban чете журналите на приложенията и реагира на неуспешни влизания — тоест на това, което вече е стигнало до услуга. Suricata гледа самия трафик и вижда онова, което няма да го има в журналите: сканиране на портове, опити за експлойти по известни сигнатури, обръщения към управляващи сървъри отвътре на вашата машина. Последното е особено ценно: изходяща връзка към чужд C2 е най-ранният признак, че нещо на сървъра вече работи без ваше знание.
Нормално е да се държат и двата инструмента, те не си пречат. Въпросът е само някой да чете изхода им по-често от веднъж на тримесечие. Как изглеждат същите известия на една страница, с разбивка по категории и източници, показва демонстрацията по-долу.