Xakep, номер # 063, стор. 063-108-1
Система журналювання подій в подробицях
Залогинься в свою Unix-систему, набери ps waux, якщо це Linux або BSD, або ps -ef, якщо це Solaris або інша реалізація System V. Ти побачиш безліч процесів, кожен з яких щось робить. Наприклад, це може бути crond, inetd, ntpd, sendmail, sshd і ще маса інших демонів, а також процеси ядра системи. І що цікаво - всі вони виводять на стандартні потоки дані, які реєструються системою журналирования. Для чого це потрібно?
Це зроблено для того, щоб власник хоста в будь-який момент часу міг дізнатися, що конкретно робить кожен з них, а якщо щось не працює - з'ясувати, в чому причина. Список - історія життя системи, і часом тільки довгий колупання в / var / log допомагає з'ясувати, чому ж раптом провайдер виставив непомірний рахунок за трафік, і що за клоун всю ніч довбав на все 65535 портів сервера.
Традиційно за ведення журналів подій відповідає демон syslogd. історія якого корінням сягає в інститут Берклі і тамтешню BSD. Syslogd - щось більше, ніж просто демон. Він повинен взаємодіяти з усіма демонами, які запущені в системі, щоб всі вони могли протоколювати події. Взаємодія це відбувається через спеціальний сокет / dev / log. Тому будь-який демон, який бажає залишити пам'ять про себе в журналі подій, просто пише в цей файл з певними аргументами. Системний демон syslogd запускається з сценарій запуску при старті системи.
Як і у будь-якого поважаючого себе демона, у syslogd є свій конфігураційний файл. За замовчуванням це /etc/syslog.conf. проте ніщо не заважає назвати його як завгодно, а потім запускати syslogd з ключем -f /path/to/config.file. Саме на файл конфігурації ми звернемо свою увагу, а про ключик, з якими можна пускати syslogd, можна дізнатися з man syslogd. благо їх небагато.
Кожен рядок syslog.conf складається з двох записів - правила і дії. У правилах вказується, яка підсистема генерує події, а також ступінь подробиці, в діях - що з цими подіями робити. На ділі все просто. Основних підсистем всього дванадцять - auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, syslog, user, uucp, однак на практиці в основному використовують наступні з них: auth - інформація про реєстрацію користувача в системі ( "юзер вася зайшов з другої консолі "), authpriv - інформація про підвищення привілеїв в системі (" юзер вася зробив su на рута на другий консолі "), cron - інформація про виконуються за розкладом завданнях (" о дев'ятій ранку, як зазвичай, скрипт опустив firewall , і інет у користувачів скінчився "), kern - повідомлення ядра (" мережевий інтерфейс перейшов в promiscious mode "), lpr - повідомлення системи друку, m ail - повідомлення поштової системи, і т.д.
Про призначення підсистеми говорить її назва. Хоча вся ця класифікація за великим рахунком умовність. Тут немає ftpd, httpd і т.д. - і не потрібно, так як ці демони самі дбають про те, скільки і куди писати інформації. У загальному ж випадку, це справа програміста - до якого класу віднести свого демона і використовувати при написанні відповідний аргумент для функції openlog (3).
Ступінь подробиці - то кількість інформації, яке буде оброблятися. Існує вісім класів пріоритетів: debug, info, notice, warning, err, crit, alert, emerg, кожний наступний - менш інформативний, ніж попередній. Тобто на рівні debug демон видає величезну кількість повідомлень, за якими можна відновити його роботу у всіх подробицях (тому так і називається - оцінний), рівень notice - оптимальний (демон видає тільки значущі повідомлення), emerg - тільки критичні для роботи системи позначки.
Нарешті, дія - це те, що повинен зробити syslogd, обробляючи повідомлення. Діями можуть бути: запис в файл (/var/log/file.log) - найпопулярніше, заради чого логи і ведуться, але, крім цього, логи можуть передаватися на віддалений хост (запис виду @loghost), перенаправлятися на конвеєр іншим програмам , пересилатися певним користувачам і / або виводитися на консоль (/ dev / console). Під передачею логів на віддалений хост мається на увазі не що інше, як відправка їх на іншу машину, де також запущений syslogd, що прослуховує 514 / udp порт.
Також зручно комбінувати підсистеми і ступінь подробиці, зіставляючи одному з описаних вище дій якийсь шаблон. Запис в кожному рядку конфіга в загальному випадку виглядає як:
Тут точкою поділяється відповідність рівня протоколювання підсистеми, і кільком таким комбінаціям можна зіставити одну дію, розділивши їх крапкою з комою. Зауважу, що в запису подсістема1.уровень1 визначається наступне: "для підсистеми 1 протоколювати всі події рівня 1 і вище". Що логічно, якщо згадати, що рівні йдуть по наростаючій (тут "вище" - значить, менше інформації). Наприклад, запис daemon.notice; kern.emerg / var / log / messages визначає запис в / var / log / messages всіх повідомлень рівня notice і вище від усіх демонів, а також критичні повідомлення ядра (і вище - але вище вже нічого немає) . Якщо ж для якогось демона треба протоколювати тільки події певного рівня, перед рівнем ставлять "=": mail. = Debug. Крім того, кілька підсистем можна перерахувати через кому, зіставивши їм один рівень: mail, news.crit. Також в шаблонах можна використовувати значок "*", який має тут своє звичайне для регулярних виразів значення - "все". *. * /var/log/all.log - вказує писати ВСЕ, що відбувається з системою в /var/log/all.log. Спецсимвол "!", Призначений для інвертування: mail.! = Debug означає все, крім дебага.
І останнє. Якщо рядок "правило - дія" передує назвою програми, то цей рядок відноситься тільки до згаданій програмі. Це дуже зручно, коли потрібно "вицепіть" логи певної програми (не обов'язково демона) в окремий потік для обробки (писати в окремий файл). При цьому ім'я програми повинно починатися з "!", Наприклад, серед діалапщикам популярна наступна конфігурація (всі повідомлення ppp писати в окремий лог-файл):
Журнал роботи в прикладах
Наведу кілька прикладів, що підтверджують, що насправді все дуже просто:
# Всі критичні для роботи системи повідомлення, а також ВСІ повідомлення ядра виводити на / dev / console. Це, як правило, перша фізична консоль (/ dev / ttyv0 у мене в FreeBSD)
# Крім цього, все те, що вище за пріоритетом, також записувати в messages
# Всі повідомлення підсистеми безпеки писати в окремий файл
# Все що стосується аутентифікації - писати в auth.log
# Всі повідомлення пошти відповідних рівнів - в maillog
# Я хочу стежити за роботою cron - тому все його повідомлення пишуться окремо
# Всі критичні повідомлення писати скрізь куди можливо :), щоб вони не залишилися непоміченими
# Всі повідомлення централізовано складаються на сервер протоколювання
# Всі повідомлення моїх улюблених програм я хочу бачити в окремих файлах.
Для того щоб демон syslogd заново перечитав свій конфіг, перезавантажуватися зовсім не обов'язково, достатньо надіслати йому сигнал HANGUP:
Для Linux і FreeBSD:
# Killall -HUP syslogd
Для NetBSD, OpenBSD і Solaris:
# Pkill -HUP syslogd
# Kill -HUP `sed q / var / run / syslogd.pid`
Боремося з пожирачами диска
Грамотно налаштувати syslogd - це ще півсправи. Файли, в які постійно дописується інформація, мають властивість розростатися до непристойних розмірів, і якщо не приділяти цьому належної уваги, в один прекрасний день розділ / var відвалиться, взвизгнув, що зайнято 120% обсягу :). У Linux, де поділ на партіціі не так популярно, і часто можна зустріти один великий кореневий розділ на всю fs (моветон, не роби так ніколи), цей момент можна відстрочити (і надовго), зате коли він настане - настане і кінець всієї файлової системі. На жаль, сам syslogd ніяких обробок файлів не виробляє, тому я розповім про два найпопулярніших підходу управління журнальними файлами: BSD-шний і лінуксовий.
Візьміть у нас в ротацію
Найзручніший спосіб ротації логів - використання newsyslog. Запускається по крону один раз на годину / добу / місяць, він переглядає логи, шукає ті, що потрапили під його правила, і створює нові чисті файли журналу, інкрементного архівуючи старі під ім'ям logfile. де. - цифра, і опціонально стискаючи їх для економії місця. Файл конфігурації за замовчуванням - /etc/newsyslog.conf, складається з наступних основних полів:
1) ім'я балки - повний шлях до файлу журналу, за яким потрібно стежити;
2) владедец: група і права доступу - атрибути створюваного архіву;
3) лічильник - глибина інкрементного архівування;
4) розмір - максимальний розмір файлу;
5) термін - час спрацьовування правила.
Розмір або термін можуть мати значення "*" - це означає, що рішення про створення резервної копії приймається на основі одного з двох аргументів. Розглянемо на прикладі:
/var/log/ppp.log root: network 640 3 100 * Z
Цей рядок говорить про те, що стежити треба за балкою ppp.log, створеному архіву привласнювати права 640, причому власником виставити рута, а групою - network, цю операцію проводити максимум три рази, рішення про створення резервної копії проводити на основі розміру файлу - він не повинен перевищувати 100 Кб, завжди, плюс до всього стискати архів (ключ Z) утилітою bzip2 (compess / gzip в залежності від системи).
Newsyslog. регулярно стартуючи за розкладом, буде дивитися, чи не перевищив ppp.log розмір в 100 Кб, і якщо перевищив - перейменовувати старий лог в ppp.log.0, створюючи новий порожній ppp.log; стисне ppp.log.0 в ppp.log.0.bz2 і присвоїть архіву права 640, власника - root, групу - network. Коли розмір вже нового ppp.log знову перевищить 100 Кб, програма перейменує вже існуючий ppp.log.0.bz2 в ppp.log.1.bz2 і створить новий ppp.log.0.bz2 за тим же алгоритмом. І так далі, поки найстаріший з архівів балки не стане називатися ppp.log.3.bz2 (ми ж вказали лічильник - 3). Після чого він видаляється, а третім стає другий і т.д. Резонне питання: як часто потрібно запускати newsyslog з cron? На незавантаженої машині це можна робити раз в два-три дня, на середньому сервері - раз в день, на завантаженій станції - піде і раз на годину. Newsyslog - дуже зручне і гнучке засіб, і man newsyslog розповість тобі ще багато цікавого.
Рішення від туксодрайверов
Newsyslog штатно йде в поставці Free / OpenBSD, тоді як Logrotate присутній в більшості дистрибутивів Linux. Займається він тим же і з подібною ж періодичністю запускається по крону. Відмінність, як водиться, в конфігурації. Тут головний конфіг /etc/logrotate.conf виглядає приблизно наступним чином:
daily
rotate 1
create
compress
include /etc/logrotate.d
Це означає - займатися обробкою логів кожен день, перелопачувати нові логи один раз перед видаленням старих (глибина інкрементного архівування), створювати новий порожній лог-файл з тим же ім'ям, стискати створені архіви. Лаконічно, правда? Остання директива основна - вказує дивитися все додаткові конфіги, розташовані в каталозі /etc/logrotate.d. У них-то ми і вказуємо специфічні для кожного демона параметри. Наприклад, створимо файл /etc/logrotate.d/httpd:
Тут ми вказали параметри ротації логів апача. Синтаксис секції: шлях до лог-файлу, і в фігурних дужках - параметри його обробки. В один конфиг (у нас - httpd) можна занести як завгодно багато таких секцій. Зручно створити кілька конфігов, в кожному з яких описати правила ротації логів одного конкретного демона (squid, samba, apache). У нашому випадку параметри обробки кожного файлу наступні: займатися обробкою щотижня (не дивлячись на те, що logrotate запускається раз в день), утилізувати новий лог п'ять разів і тільки потім видаляти старі, стискати отримані архіви, нічого не робити з балкою, якщо він і так порожній, і, нарешті, не впадати в паніку, якщо зазначений лог не найден.
Наостанок - парочка рад з управління логами в серйозних мережах. Так як інформація про події дуже важлива при розслідуванні інцидентів, а перше, що роблять хаксори на зламаній тачці - це труть логи, то я настійно рекомендую завести окремий log-сервер, де крім syslogd нічого не буде крутитися (старенький комп'ютер підійде), і все логи з усіх машин централізовано відправляти на нього, адже ти тепер знаєш, як це зробити. Тільки в цьому випадку ти будеш знати всю правду про події в мережі.
Syslog-ng дозволяє обробляти логи з використанням регулярних виразів (хороший для фільтрації окремих повідомлень, форматування журналу протоколу і т.п.), а також вміє передавати логи на віддалений хост по TCP.
Socklog працює спільно з daemontools і qmail. Створено для тих, хто вже замінив bind і sendmail на tinydns і qmail і хоче знайти адекватну заміну і для syslogd.
Msyslog пропонує модульну архітектуру для полегшення написання до сіслогу всяких фішок, в тому числі збереження логів в базі даних, фільтрації на основі регулярних виразів і т.д.
Minirsyslogd - маленький і безпечний демон виключно для прийняття логів з віддалених хостів по мережі.
Часто в конфіг додають новий файл, забувши його при цьому створити (touch /var/log/file.log) або забувши перезапустити syslogd.
Іноді створений лог-файл забувають прописати в newsyslogd / logrotate, в результаті чого він залишається необробленим і розростається.