Syslog - це повноцінна система реєстрації подій, написана Еріком Оллманом (Eric Allman). Багато постачальників користуються нею для управління інформацією, яку генерують ядро і системні утиліти.
Система Syslog виконує дві найважливіші функції: вона звільняє програмістів від стомлюючої механічної роботи по веденню журнальних файлів і передає управління реєстрацією в руки адміністратора. До появи Syslog кожна програма могла сама вибирати політику реєстрації, а у системних адміністраторів не було можливості контролювати, яка інформація і де саме зберігається.
Дана система відрізняється високою гнучкістю. Вона дозволяє сортувати повідомлення за джерелами і ступеня важливості ( "рівню серйозності" в термінології системи Syslog) і направляти їх в різні пункти призначення: в журнальні файли, на термінали користувачів і навіть на інші машини. Однією з найцінніших особливостей цієї системи є її здатність централізувати процедуру реєстрації подій в мережі.
Система Syslog складається з трьох компонентів:
- syslogd - демон, який здійснює реєстрацію (його конфігураційний файл називається /etc/syslog.conf);
- openlog (), syslog (), closelog () - бібліотечні функції, які передають повідомлення демона syslogd;
- logger - команда призначеного для користувача рівня, яка приймає реєстраційні повідомлення від інтерпретатора команд.
За сигналом "відбій" (HUP, сигнал 1) демон syslogd закриває свої та файли реєстрації, перечитує конфігураційний файл і знову запускає процес реєстрації. Якщо змінюється файл syslog.conf. потрібно послати демона syslogd сигнал HUP, інакше зміни не вступлять в силу. Сигнал TERM призводить до завершення роботи демона.
Демон syslogd записує свій ідентифікатор процесу (PID) в файл /var/run/syslog.pid (в деяких системах - в файл /etc/syslog.pid). Це полегшує передачу демона сигналів із сценаріїв. Наприклад, наступна команда видає сигнал відбою:
% Kill -HUP '/ bin / cat /var/run/syslog.pid'
Спроби стиснути або замінити файл реєстрації, який був відкритий демоном syslogd для запису, нерозумні і призводять до непередбачуваних наслідків. Деякі постачальники пропонують заготовку сценарію (часто вона знаходиться в каталозі / usr / lib / newsyslog), призначення якої - ротація журнальних файлів. Покращена версія сценарію, що називається rotz. доступна на Web-сайті www.admin.com.
Конфігурація демона syslogd
Дії демона syslogd залежать від вмісту файлу /etc/syslog.conf. Це текстовий файл щодо простого формату. Порожні рядки і рядки. починаються зі знака решітки (#), ігноруються. Базовий формат цього файлу такий:
селектор <Таb> дія
забезпечує збереження повідомлень, що надходять від поштової системи, в файлі / var / log / maillog. Поля селектор і дію повинні бути розділені одним або декількома знаками табуляції; прогалини не використовуються в якості роздільників і стають невидимими помилками, які буває дуже важко відстежити. Один із способів внесення таких помилок - операції вирізання і вставки тексту при роботі з багатовіконний графічним інтерфейсом.
Селектор позначає програму ( "засіб" в термінології системи Syslog), яка посилає реєстраційне повідомлення, і рівень серйозності цього повідомлення. Формат селектора такий:
Імена засобів і рівні серйозності слід вибирати зі стандартного списку значень; програми не можуть становити власних списків. Є кошти, визначені для ядра, для групи загальних програм і для локальних програм. Все інше проходить під загальним ім'ям "user" (тобто користувач).
Селектори можуть містити ключові слова * і none, які позначають відповідно "все" і "нічого". Селектор може включати групу засобів, розділених комами. Допускається також поділ за допомогою символів крапки з комою.
У загальному випадку селектори об'єднуються методом логічного АБО; для повідомлення, відповідного кожному з селектор, буде виконуватися дія, вказане в однойменному полі. Селектор рівня none означає виключення перерахованих в ньому коштів незалежно від того, що зазначено в інших селекторах цього ж рядка.
Нижче наведені приклади селекторів:
У табл. 11.2 перераховані допустимі імена засобів. У більшості версій системи Syslog визначено 18 засобів (в самої останньої версії - 21). Окремі імена зарезервовані для майбутнього використання.
Демон syslogd сам видає повідомлення про тимчасові мітки, які реєструються, якщо в файлі syslog.conf для них вказаний селектор із засобом "mark". Тимчасові місця допомагають точно визначити, коли машина вийшла з ладу: не просто "сьогодні вночі", а "між 3:00 і 3:20 ночі". Це дуже корисно для виправлення несправностей, які виникають регулярно. Наприклад, в декількох організаціях системи таємничим чином сбоілі, поки не виявилося, що прибиральниці пізно ввечері включали пилососи, відключаючи при цьому комп'ютери.
Коли система сильно завантажена, інші зареєстровані повідомлення часто містять досить багато тимчасових міток. Але так буває не завжди, особливо в ранкові години.
Рівні серйозності перераховані в порядку убування важливості в табл. 11.3.
На відміну від загальноприйнятої схеми класифікації повідомлень, FreeBSD дозволяє вибирати повідомлення на підставі імені програми, від якої вони надходять, а не розпливчасто-невизначеного імені кошти. На жаль, демон syslogd не володіє інформацією про програми, тому змушений переглядати повідомлення на предмет того, чи починаються вони з імені програми та двокрапки. Наприклад, повідомлення
буде розпізнано як надійшла від демона named. У файлі syslog.conf секції, які стосуються повідомленнями, які надходять від конкретних програм, передує знаком оклику і ім'ям програми. Наприклад, рядки:
змушують демона syslogd посилати всі повідомлення демона named в файл /var/log/named.log.
Розподіл повідомлень на підставі імен програм - не найкращий спосіб управління реєстрацією. Він базується на певних правилах формування повідомлень, яким слідують далеко не всі програми.
Аргументи командного рядка демона syslogd можна помістити в файл /etc/rc.conf. щоб вони автоматично активізувалися під час початкового завантаження системи. наприклад:
syslogd_flags = "- a 128.138.192.0/20 -а * .cs.colorado.edu"
У цій конфігурації не дуже багато інформації зберігається локально. Слід врахувати, що якщо комп'ютер netloghost вимкнений або недоступний, реєстраційні повідомлення будуть безповоротно втрачені. На цей випадок можна створювати локальні копії важливих повідомлень.
В організації, де інстальований великий обсяг локального програмного забезпечення, невиправдано багато повідомлень може реєструватися за допомогою засобу "user" на рівні "emerg". У показаному прикладі така ситуація свідомо виключається за допомогою виразу user.none в першому рядку.
Друга і третя рядки служать для пересилання всіх важливих повідомлень на центральний реєстраційний сервер; повідомлення підсистеми друку і університетської системи доступу за картками направляються в інше місце. Четвертий рядок організовує відправку локальної реєстраційної інформації також на центральний комп'ютер. У п'ятому рядку реєстраційна інформація системи доступу за картками відправляється на центральну машину boulder. Останні два рядки забезпечують зберігання локальних копій повідомлень про помилки принтера і реєстраційних повідомлень програми sudo.
Центральний реєстраційний вузол
Це приклад для комп'ютера netloghost - центрального високонадійного реєстраційного вузла мережі середнього розміру, що включає 400-500 машин.
# Файл syslog.conf факультету обчислювальної техніки
# Для головного реєстраційного вузла
Реєстраційні повідомлення, що надходять від локальних профамм і демонів syslogd по мережі, записуються в зазначені вище файли. У деяких випадках вихідна інформація кожного засобу записується в окремий файл.
Центральний реєстраційний комп'ютер генерує мітки часу для кожного одержуваного повідомлення. Це час не завжди збігається з часом відправки повідомлення. Якщо в системі реєструються комп'ютери, розташовані в різних часових поясах, або системний годинник не синхронізовані, інформація про час виявляється недостовірною.
Приклад вихідної інформації системи Syslog
Нижче показаний фрагмент одного з журнальних файлів, скопійований з головного реєстраційного вузла факультету обчислювальної техніки університету штату Колорадо. На цей комп'ютер надходить реєстраційна інформація приблизно з двохсот машин.
Dec 18 15:12:42 avl8.cs.colorado.edu sbatchd [495]: sbatchd / main: ls_info () failed: LIM is down; try later; trying.
Dec 18 15:14:28 proxy-l.cs.colorado.edu pop-proxy [27283]: Connection from 128.138.198.84
Dec 18 15:14:30 mroe.cs.colorado.edu pingem [271]: maltese-office.cs.colorado.edu has not answered 42 times
Dec 18 15:15:05 schwarz.cs.colorado.edu vmunix: Multiple softer-rors: Seen 100 Corrected Softerrors from SIMM J0201
Dec 18 15:15:05 schwarz.cs.colorado.edu vmunix: AFSR = 0x4c21, AFARO =
0x87ffdd30, AFAR1 = oxb8f8a0
Dec 18 15:15:48 proxy-l.cs.colorado.edu pop-proxy [27285]: Connection from 12.2.209.183
Dec 18 15:15:50 avl8.cs.colorado.edu last message repeated 100 times
У цьому прикладі представлена інформація, що надійшла з кілька машин (avl8. Proxy-1. More і schwarz) і від кількох програм: sbatchd, pop-proxy, pingem і vmunix (ядра). Зверніть увагу на останній рядок, в якій йдеться про повідомленні, повторюючи 100 раз. Щоб скоротити обсяг журнальних файлів, система Syslog зазвичай намагається об'єднувати дублюються повідомлення і замінювати їх резюмує рядком. Однак комп'ютер, з якого був узятий цей файл, приймає реєстраційні повідомлення від безлічі інших комп'ютерів, тому дане конкретне повідомлення може трохи збити читача з пантелику. Воно посилається на попереднє повідомлення від комп'ютера avl8. а не на попереднє повідомлення в журнальному файлі.
Рекомендуємо регулярно переглядати свої журнальні файли. Встановіть, яке їх стан є нормальним, щоб в разі відхилення від норми відразу помітити це. А ще краще встановити програму обробки журнальних файлів, таку як swatch. яка буде робити те ж саме автоматично (див. параграф 11.6).
Розробка схеми реєстрації для конкретної організації
Для невеликої організації достатньою буде така конфігурації системи реєстрації, при якій важливі системні помилки і попередження зберігаються в окремому файлі на кожному комп'ютері. В основному так було до появи системи Syslog. Файл syslog.conf можна адаптувати для кожної конкретної машини.
У великій мережі необхідна централізована реєстрація. Такий підхід дозволяє контролювати інформаційні потоки і - якщо пощастить - приховувати одержувані в результаті перевірки дані від імені, який зламав систему захисту будь-якого комп'ютера в мережі. Хакери часто змінюють системні журнальні файли, щоб замести сліди; якщо реєстраційну інформацію відразу ж приховати, то підробити її буде набагато важче. Пам'ятайте, однак, про те, що кожен може викликати систему Syslog і створити реєстраційні записи, нібито надіслані будь-яким демоном або утилітою. Крім того, система Syslog користується протоколом UDP, який не є надійним, тому що не гарантує доставку повідомлень. Наявний в мережі брандмауер повинен забороняти зовнішнім вузлів передавати повідомлення демона syslogd.
Як сервер-реєстратора вибирайте стабільно працюючу машину, краще таку, доступ фізичних осіб до якої обмежений і добре контролюється і де мало зареєстрованих користувачів. Інші комп'ютери мережі можуть користуватися базовим конфігураційним файлом, який зберігається на центральному вузлі. Таким чином, потрібно вести лише дві версії файлу syslog.conf. Це забезпечує повноту реєстрації, не перетворюючи її в кошмар для адміністратора.
У деяких дуже великих організаціях вважають за необхідне ввести в ієрархію реєстрації додаткові рівні. На жаль, поточна версія системи Syslog зберігає ім'я машини-відправника тільки для однієї пересилання. Якщо машина-клієнт відправляє реєстраційні дані машині-серверу, яка пересилає їх ведучому комп'ютера, то останній буде розглядати ці дані як надійшли від сервера, а не від клієнта.
Програми, що використовують систему Syslog
Проект microG випустив збірку LineageOS з альтернативної реалізацією сервісів Google
В рамках збірки LineageOS for microG підготовлений варіант платформи LineageOS (продовження розвитку CyanogenMod), в якому пропонується альтернативна вільна реалізація сервісів Google.
Фонд СПО повідомив про витік даних користувачів через забутої резервної копії
Фонд вільного ПЗ попередив про інцидент, в результаті якого в публічному доступі виявилася деяка що не підлягає розголосу інформація, пов'язана з проектом Defective By Design, включаючи.
Сформовано коригувальний реліз спеціалізованого браузера Tor Browser 7.0.9, орієнтованого на забезпечення анонімності, безпеки і приватності. Браузер побудований на кодової базі Firefox і.
Проти організації Software Freedom Conservancy поданий позов про відкликання торгової марки
Організація Software Freedom Conservancy (SFC) повідомила про отримання позову про відкликання торгової марки, ініційованому організацією Software Freedom Law Center (SFLC). У позові стверджується, що торгова.