Стаття також доступна російською (перейти до перегляду).

Вступ

• Журнали аутентифікації – різновиди та роль у захисті серверу
• Програмні засоби для перегляду та налаштування журналів ОС Ubuntu
• Внутрішні засоби
• Зовнішні утиліти
• Висновки

Як показала практика, забезпечити більш менш повноцінний захист серверу під управлінням Linux-системи можливо лише із залученням засобів та результатів чіткої фіксації подій, що відбуваються. Особливо це стосується системи аутентифікації користувачів, котра є найбільш вразливим місцем для атак зловмисників. Накопичена в журналах аутентифікації службова інформація дозволяє забезпечити постійний моніторинг відвідувань користувачів та спроб під’єднання до системи і, навіть, організувати надійний її захист у автоматичному режимі. Як це можна зробити – читайте далі.

Журнали аутентифікації – різновиди та роль у захисті серверу

Linux-системи мають доволі потужні можливості ведення логів або журналювання стосовно всіх станів та подій, що відбуваються у системі. Будь-який з журналів може бути віднесений до однієї з категорій:

• Для додатків;
• Повідомлень;
• Для служб;
• Системний.

Вміст кожного з журналів розподілений між кількома файлами, відповідно до спрямування кожної з частин інформації, котрі, зазвичай, зберігаються у каталозі /var/log.

Така структура сприяє більш ефективному впорядкуванню та пошуку потрібних даних як для системи, так і Адміністратора.

Журналювання аутентифікації здійснюється за допомогою системного журналу systemd-journal, у котрому фіксується різнобічна інформація, стосовно будь-яких спроб під’єднання та всіх відвідувань системи зареєстрованими користувачами. Зокрема, це можуть бути наступні дані:

• Час та дата відвідування, або спроби під’єднання;
• Вдалі та невдалі спроби під’єднання;
• Використані механізми аутентифікації при вході;
• IP-адреса, з котрої відбувалося під’єднання або його спроба;
• Ім’я та останні дії кожного зареєстрованого користувача.

Основні логи ОС Ubuntu та їх призначення, які використовуються для потреб аутентифікації:

• /var/log/auth.log або /var/log/secure – фіксація усіх спроб під’єднання та застосованого при цьому методу аутентифікації;
• /var/log/lastlog – фіксуються останні сесії кожного з користувачів;
• /var/log/tallylog – реєструються невдалі спроби під’єднання;
• /var/log/btmp – бінарний журнал для реєстрації невдалих спроб;
• /etc/log/wtmp – бінарний журнал, де реєструються відвідувачів, котрі були останніми.

Слід зазначити, що системою фіксуються спроби під’єднання не лише фізичних користувачів, а й взагалі будь-якого програмного засобу, скрипта чи протоколу, що цілком зрозуміло.

Зібрана інформація може бути використана Адміністраторами для контролю відвідувань, аналізу та прийняття відповідних рішень, щодо захисту системи у ручному чи автоматичному режимі. Наприклад, це може бути блокування невідомих IP-адрес, з котрих були здійснені чисельні спроби під’єднання чи встановлення більш жорстких значень параметрів аутентифікації, наприклад, обмеження часу аутентифікації чи кількості допустимих спроб. Такі налаштування краще робити за допомогою відповідного програмного забезпечення, особливо якщо Адміністратором обслуговується цілий кластер, а не лише один сервер.

Нижче буде розглянуто можливі варіанти внесення змін у налаштування на підставі інформації із журналів аутентифікації. Але спочатку наведемо програмні засоби для роботи із файлами журналів та методи роботи з ними, що також є доволі важливим моментом.

Програмні засоби для перегляду та налаштування журналів ОС Ubuntu

Для можливості безперешкодного використання інформації з журналів аутентифікації необхідно враховувати те, що формати збереження інформації в них можуть бути різними і багато які з них можуть мати значний об’єм. Це означає, що не існує універсального редактору для роботи з такими файлами, а треба підібрати найбільш підходящий редактор, команду чи утиліту для кожного випадку.

У зв’язку з цим, можна умовно виділити дві категорії програмних засобів для роботи з такими файлами: внутрішні та зовнішні (утиліти). Перші фактично є спеціалізованими командами, призначеними для роботи із файлами журналу аутентифікації відповідних форматів. Інші потребують встановлення та є більш універсальними та багатовекторними у тому сенсі, що, по-перше: дозволяють переглядати будь-які журнали, а не тільки аутентифікації; по-друге: можуть бути використані для автоматизації роботи системи захисту, наприклад, як F2B та інші. Сюди також можна віднести спеціалізований засіб LogRotate, про котрий ми вже розповідали раніше та близьку за характеристиками програму sysctl.

Розглянемо по черзі обидві категорії вказаних засобів.

Внутрішні засоби

Можна виділити наступні команди, котрі дозволяють переглядати та фільтрувати інформацію і, навіть, надсилати Адміністратору звіти на її основі:

• less;
• tail;
• last;
• lastlog;
• journalctl;
• logwatch.

Розглянемо їх більш детально.

Команда less. Для прикладу, переглянемо дані про всі спроби автентифікації, розміщені у файлі auth.log. Для цього наберемо у терміналі:

$ sudo less /var/log/auth.log

Ми бачимо, що в результаті її виконання виведена інформація, зокрема, про ім’я користувача чи програмного засобу, що під’єднувався; використаний спосіб аутентифікації; час та дата операції; порт та IP-адреса та інша подібна.

Внутрішня команда less, окрім своїх звичайних можливостей, також дозволяє використовувати однойменну утиліту, котра дає змогу забезпечити посторінковий вивід інформації із файлів значного об’єму, що дуже зручно.

Для виходу з режиму перегляду необхідно натиснути клавішу Q.

Команда tail. Цей засіб також здатний доволі компактно відображати інформацію. Використаємо його для того ж файлу:

$ sudo tail /var/log/auth.log

Формат виводу приблизно співпадає із попередньою командою. Так само переносяться записи, якщо вони не вміщуються у межах однієї строчки.

Команда last. На відміну від попередніх команд, вона не просто відображає вміст вказаного у параметрах запуску файлу, а є спеціалізованим засобом, котрий орієнтований на роботу саме із файлами системи аутентифікації. І, тому, навіть при його запуску вказувати шлях до місцезнаходження файлу не потрібно, тим паче, що ви його можете і не знати.

Так, для перегляду інформації, що до останніх спроб під’єднання до системи, достатньо лише ввести назву команди у командній строчці терміналу:

$ last

Судячи по першій строчці виведених результатів, користувач root й досі знаходиться у системі. Загальний час перебування відвідувачів у системі для вже закритих сеансів визначається значеннями, вказаними через дефіс та виведений у останньому стовпчику.

Ця інформація була взята командою із бінарного файлу /etc/log/wtmp, ро котрий вже йшла мова вище, та виведена нею у доступному для перегляду людиною форматі.

Для отримання більш детальної інформації по команді та її додатковим параметрам можна скористатися довідковою інформацією:

$ man last

Для виходу з режиму перегляду треба натиснути клавішу Q.

Команда lastlog. Дає змогу переглянути вміст однойменного файлу журналу, в якому фіксується інформація з останніх сесій кожного із зареєстрованих користувачів, що є дуже корисним для Адміністратора. Інформація, що виводиться, впорядковується відповідно до записів системного файлу /etc/passwd. Час її виконання залежить від кількості зареєстрованих у системі користувачів і, тому, може бути доволі значним.

Використаємо вказаний засіб для виявлення останніх відвідувачів:

$ lastlog

Звернімо увагу на те, що у списку «відвідувачів» також присутні дані по системним обліковим записам, наприклад, служба syslog, котрі, звісно, не використовуються для прямої реєстрації у системі і, тому, навпроти них зазначено: Never logged in (ніколи не відвідував). Для інших користувачів, зокрема, root, виведений точний час та дата останньої аутентифікації – 13 November 09:56:12.

Команда також може бути використана із додатковими параметрами для деталізації інформації. Для прикладу, виведемо список користувачів, котрі увійшли в систему раніше протягом трьох останніх днів. Для цього введемо:

$ lastlog --before 3

Тепер виведемо список користувачів, котрі реєструвалися в останні два дні:

$ lastlog --time 2

Можна переконатися, що це працює і може бути використане для виконання різноманітних завдань системного моніторингу.

Команда journalctl. Дозволяє переглядати та сортувати дані по рівню помилок, часу та іншим параметрам. Дані беруться із системного журналу systemd-journal. Для прикладу, переглянемо записи, пов’язані із службою SSH:

$ sudo journalctl -u ssh

Тепер переглянемо останні записи журналу у динамічному режимі виводу на екран нових записів при їх фіксації у журналі:

$ sudo journalctl -f

Доречі про додаткові налаштування ssh_config ми вже писали в попередній статті. Ознайомитись з нею Ви можете за посиланням.

Утиліта дозволяє змінювати набір файлів журналу, що використовуються, в залежності від типу затребуваної Адміністратором інформації. Для цього можна використовувати опції --user, --system, --directory та --file. Наприклад, для перегляду лише системної інформації наберемо в терміналі:

$ sudo journalctl --system

Для виходу з режиму перегляду наберемо Q.

Команда logwatch. Контролює журнали, пов’язані із фіксацією невдалих спроб аутентифікації та формує на їх підставі звіти, котрі і відправляються на пошту Адміністратора. Встановлення не потребує. Єдине, що необхідно зробити, вказати або скоригувати адресу електронної скриньки для відправлення звітів. Це можна зробити за допомогою конфігураційного файлу програми logwatch.conf.

Для прикладу, відкриємо конфігураційний файл за допомогою nano:

$ nano /usr/share/logwatch/default.conf/logwatch.conf

Тут також є й інші варіанти налаштувань, котрі дають змогу зробити оповіщення ще зручнішим та оперативним.

Зовнішні утиліти

Існує цілий ряд зовнішніх програмних засобів для роботи із будь-якими журналами, в тому числі й аутентифікації. Деякі з них є найпростішими і, по суті, виконують роль редактора із певними можливостями. Це такі, наприклад, як програма LNAV (Log File Navigator). Але є і більш потужні засоби, котрі дають змогу налагодити автоматичну фільтрацію на вході, як, наприклад, F2B (Fail2Ban). Звісно, що для їх використання спочатку їх треба встановити та, при необхідності, налагодити.

Вкажемо на найбільш відомі програмні засоби, один з котрих є потужним редактором, а інший своєрідним брандмауером для захисту від атак зловмисників:

• LNAV;
• F2B.

Розглянемо їх більш детально.

Утиліта LNAV. По суті, є навігатором по журналам і може водночас працювати із кількома журналами різних форматів, переключаючись між ними. Здатна читати більшість існуючих форматів – dpkg.log, glog, strace, Syslog, Access_log та інші, що робить її певною мірою універсальним засобом.

Спочатку оновимо індекс пакетів у нашій системі:

$ sudo apt update

Тепер встановимо файловий навігатор на нашій машині. Команда інсталяції залежить від типу встановленої ОС. Для лінійки Debian / Ubuntu/ Linux Mint команда буде виглядати наступним чином:

$ apt install lnav

Підтвердимо виділення додаткових 3,752 kB і процес розгортання продовжиться.

Отже, утиліта встановлена – Setting up lnav (0.9.0-2ubuntu1).

Спробуємо переглянути з її допомогою наш файл auth.log. Для цього наберемо в терміналі:

$ sudo lnav /var/log/auth.log

Як можна переконатися, її інформативність та можливості редагування інформації значно вищі, ніж у влаштованих команд. Для виходу з програми натиснемо клавішу Q.

Утиліта F2B. Є потужним засобом для захисту від атак на основі використання даних системних журналів. Дає можливість встановити автоматичні фільтри по багатьом параметрам – IP, кількість спроб під’єднання, час аутентифікації та інших.

Встановимо її у нашій системі Ubuntu 22.04. Для цього введемо у терміналі:

$ sudo apt install fail2ban

Після підтвердження виділення додаткових 2,486 Kb процес продовжиться.

Програма була успішно встановлена – Setting up fail2ban (0.11.2-6).

Для подальшого використання засобу бажано здійснити ряд налаштувань, стосовно ваших потреб. Файл налаштувань із стандартними значеннями параметрів, зазвичай, знаходиться за адресою /etc/fail2ban/jail.conf. Але, враховуючи, що після кожного оновлення програми інформація в файлі автоматично оновлюється, бажано вносити зміни у інший, так званий, локальний файл із назвою jail.local, котрий повинен розміщуватися у тому ж каталозі. Але про це поговоримо трохи пізніше.

Програма дозволяє, зокрема, здійснити наступні види налаштувань:

• Обрати потрібні журнали;
• Налаштувати автоматичне сканування невдалих спроб аутентифікації у системі;
• Вказати час блокування для IP-адрес, котрі були заблоковані;
• Та ще багато чого.

Для прикладу, переглянемо вміст основного конфігураційного файлу програми:

$ nano /etc/fail2ban/jail.conf

Можна побачити, що файл поділений на ізольовані секції, котрі мають назву джейли (jails). Кожна з них відповідає за певний сервіс та може бути використана для захисту від конкретної атаки.

Запустимо програму у якості служби:

$ sudo systemctl start fail2ban

Перевіримо її версію:

$ sudo fail2ban-client version

Перевіримо статус служби:

$ sudo systemctl status fail2ban

Тепер налаштуємо службу таким чином, щоб вона могла самостійно запускатися після кожного перезавантаження системи:

$ sudo systemctl enable fail2ban.service

Тепер перезавантажимо службу rsyslog:

$ sudo service rsyslog restart

Після цього перейдемо до формування нашого локального файлу конфігурації програми. Для цього створимо його за допомогою редактора nano:

$ nano /etc/fail2ban/jail.local

Внесемо значення найбільш важливих для нас параметрів захисту системи у відповідних секціях файлу:

# Fail2Ban LOCAL conf file
 
[DEFAULT]
 
bantime  = 5h
findtime = 7m
maxretry = 3
ignoreip = 127.0.0.1 193.0.207.160
 
# JAILS
 
[sshd]
enabled = true

Тут параметр bantime – встановлює час блокування IP-адреси (у годинах); findtime – інтервал часу для фіксації невдалих спроб під’єднання до системи; maxretry – кількість невдалих спроб протягом інтервалу часу, встановленого у findtime; ignoreip – статичні адреси, котрі є дозволеними, наприклад, адреса ПК Адміністратора. У секції [sshd] ми включили відповідну службу. Значення параметрів, заданих для окремих джейлів будуть мати найвищий пріоритет порівняно із загальними налаштуваннями, що значно підвищує гнучкість всіх налаштувань і, відповідно, усієї системи захисту.

Внесемо вказані дані до файлу та збережемо його.

Тепер перезавантажимо службу fail2ban:

$ service fail2ban restart

Більш детально з можливостями fail2ban Ви можете ознайомитися в нашій статті “Захист сервера за допомогою утіліти fail2ban. Як її налаштувати?”

Висновки

Ми розглянули можливості локального програмного забезпечення щодо управління та контролю системи аутентифікації сервера чи робочої станції. Однак, найбільш повно можливості журналювання проявляються на рівні кластерів, оскільки значно спрощують та пришвидшують управління ними. Для цього існують, так звані інструменти моніторингу, котрі здатні забезпечити централізоване журналювання на рівні кластерів, а не лише локальному і, відповідно, дають змогу організувати автоматизований захист усього кластеру. Однак, їх розгляд виходить за рамки нашої роботи і, тому, ми обмежилися лише повідомленням про їх існування і наявність вказаної можливості.

Додатково Вас можуть зацікавити наступні статті по темі:

• Як включити відмітку часу в історії Bash в Linux
• Централізоване керування логами за допомогою rsyslog
• Як моніторити сервер за допомогою Zabbix?

В дата-центрі FREEhost.UA Ви можете замовити сервер для оренди під будь які завдання. Майже всі конфігурації, які вказані на сайті, є в наявності. Тому налаштований сервер після підтвердження замовлення ми надаємо користувачу на протязі кількох годин. За Вашим бажанням на сервері може бути налаштована обрана Вами ОС з сімейства Linux, або Windows, а також встановлена панель керування.

Підписуйтесь на наш телеграм-канал https://t.me/freehostua, щоб бути в курсі нових корисних матеріалів.

Дивіться наш канал Youtube на https://www.youtube.com/freehostua.

Ми у чомусь помилилися, чи щось пропустили?

Напишіть про це у коментарях, ми з задоволенням відповімо та обговорюємо Ваші зауваження та пропозиції.

Дата: 16.11.2023 Автор: Олександр Ровник #linux#security#ssh#ubuntu

Голосування 1 2 3 4 5