Введення в автоматизацію. Частина 2., Linux, Операційні системи, статті

Станіслав Лапшанскій

У першій частині ми почали з’ясовувати які сценарії запускаються програмою periodic. У цій частині ми закінчимо наш огляд.

Минулого разу ми зупинилися на сценарії призначеному для системного аккаунтинга. По-замовчуванню системний аккаунтинга виключений, тому, якщо ви не плануєте його включати, забороніть виконання цього сценарію. Якщо ви не знаєте, для чого призначений системний аккаунтинга, зверніться до відповідної сторінки керівництва – man sa, там написано, яка саме ведеться статистика. Якщо ви вирішили включити системний аккаунтинга, подумайте над зміною значення параметра daily_accounting_compress з «NO» на «YES», а так же частіше поглядайте на розмір вільного місця на вашому диску.

# 310.accounting daily_accounting_enable = “YES” # ротувати файли аккаунтинга daily_accounting_compress = “NO” # Стискати ротированной журнали daily_accounting_flags =-q # Параметри для / usr / sbin / sa daily_accounting_save = 3 # Кількість збережених файлів

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

# 320.distfile daily_distfile_enable = “YES” # Щодня запускати rdist

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

# 330.news daily_news_expire_enable = “YES” # Запускати сценарій news.expire

Тепер звернемося до UUCP (Unix to Unix Copy Program – застаріле засіб для передачі файлів між UNIX-машинами. Зараз використовується в деяких відсталих місцевостях 😉 для передачі поштового трафіку – прим. перекладача). Ось три сценарії які мають відношення до UUCP, я зібрав їх разом і розповім про всіх них відразу. Сценарії 340 і 410 можна знайти у частині для щодня виконуваних сценаріїв, а сценарій номер 300 – у щотижневій частини:

# 340.uucp daily_uuclean_enable = “YES” # Запускати сценарій uuclean.daily
# 410.status-uucp daily_status_uucp_enable = “YES” # Перевірка стану uucp
# 300.uucp weekly_uucp_enable = “YES” # Щотижнева чистка uucp

На жаль програми працюють з UUCP протягом багатьох років схильні до різноманітних вразливостям, і, в недавньому минулому, стали предметом для випуску бюлетеня безпеки FreeBSD (див. ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-01:62.uucp.asc). Тому найбільш правильним рішенням буде простий заборону на виконання цих трьох сценаріїв. Взагалі кажучи, якщо ви не маєте потреби у використанні утиліт tip і cu, то UUCP вам не потрібен. У четвертій частини вищеописаного бюлетеня ви знайдете вказівки які файли видалити і як перешкодити їм відновитися при перезбирання вашої системи.

#400.status-disks daily_status_disks_enable = “YES” # Перевірити стан диска daily_status_disks_df_flags = “-k-t nonfs # Параметри до команди df (1)

Ймовірно вам слід відставити сценарій перевірки стану диска включеним, і, щодня переглядати його висновок для того що б переконатися що у вас все ще є вільний дисковий простір. Зауважте, що ви можете змінити параметри запуску програми df, для отримання від неї бажаного результату. Оскільки я не використовую NFS, а так само люблю знати скільки у мене залишилося inodes (грубо кажучи, скільки можна записати ще файлів у файлову систему – прим. перекладача), а так само отримувати все це в легко читається людиною форматі. Тому мої параметри виглядають так:

daily_status_disks_df_flags = “-h-i” # Параметри до команди df (1)

Їх застосування дає мені такий висновок:

Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/ad0s1a 97M 31M 58M 35% 1175 23911 5% /
/dev/ad0s1f 7.5G 1.4G 5.5G 21% 130401 1837725 7% /usr
/dev/ad0s1e 19M 7.3M 11M 41% 950 4104 19% /var
procfs 4.0K 4.0K 0B 100% 68 464 13% /proc
mfs:28 252M 365K 231M 0% 33 65053 0% /tmp
linprocfs 4.0K 4.0K 0B 100% 68 464 13% /usr/compat/linux/proc
Last dump(s) done (Dump ‘>’ file systems):

У той час як по-замовчуванню видається такий результат:

Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad0s1a 99183 31559 59690 35% /
/dev/ad0s1f 7851437 1500679 5722644 21% /usr
/dev/ad0s1e 19815 7462 10768 41% /var
procfs 4 4 0 100% /proc
mfs:28 257703 365 236722 0% /tmp
linprocfs 4 4 0 100% /usr/compat/linux/proc
Last dump(s) done (Dump ‘>’ file systems):

Насамперед сценарій перегляду стану мережі запускає програму netstat. Якщо ви не хочете, що б IP-адреси вирішувалися в їх рядкові еквіваленти поміняйте значення параметра daily_status_network_usedns на «NO». Вирішуй ті самі, чи достатньо корисно вміст виведення цього сценарію для того що б залишити його включеним.

# 420.status-network daily_status_network_enable = “YES” # Перевірити стан мережі daily_status_network_usedns = “YES” # Дозволяти IP-адреси

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

# 430.status-rwho daily_status_rwho_enable = “YES” # Перевірити стан системи

Наступний сценарій виконує команду mailq, за допомогою якої можна дізнатися що зараз знаходиться в поштовій черзі.

# 440.status-mailq daily_status_mailq_enable = “YES” # Перевірка стану поштової системи daily_status_mailq_shorten = “NO” # Короткий висновок

Сценарій видає зведення безпеки, є, мабуть найважливішим і корисним сценарієм який запускає програма periodic. Зверніть увагу, що результати його роботи надсилаються окремим листом, а так само можуть бути послані не суперкористувачеві, а комусь іншому. Параметр daily_status_security_inline повинен залишатися в стані «NO», якщо ви не хочете, що б зведення безпеки видавалася на термінал. У разі необхідності в майбутньому проводити дослідження безпеки системи (наприклад при її зломі – прим. Перекладача), вам може знадобитися наявність довіреної користувача, який буде щодня отримувати і читати зведення безпеки.

# 450.status-security daily_status_security_enable = “YES” # Перевірка безпеки системи daily_status_security_inline = “NO” # Видавати результати на термінал daily_status_security_output = “root” # Хто отримає результат: користувач або файл daily_status_security_noamd = “NO” # Не перевіряти змонтовані amd томи daily_status_security_nomfs = “NO” # Не перевіряти змонтовані mfs томи

Перевіркою поточного стану безпеки займається сценарій / etc / security. Цей сценарій перевіряє ряд добре відомих вразливостей (загальних для всіх UNIX систем – прим. Перекладача), а це означає, що ви повинні повністю переглядати його висновок для того що б бути впевненим у тому, що ваша система не скомпрометована. Якщо ви новачок в забезпеченні цілісності та безпеки системи і деякі з пунктів зведення вам незрозумілі, то читання man security буде гарною відправною точкою. Для додаткового читання почитайте інформацію по наступним посиланням: people.freebsd.org/~jkb/howto.html і www.cert.org/tech_tips/usc20_full.html.

Давайте коротко пройдемося по пунктах зведення безпеки.

Секція «setuid files»

Файли з встановленим атрибутом setuid є однією з найстаріших вразливостей системи UNIX. На щастя FreeBSD зберігає список цих файлів в файлах / var / log / setuid.today та / var / log / setuid.yesterday. При перевірці стану системи, кожну ніч насамперед з’ясовуються відмінності між цими двома файлами. Інформація про нові і змінених файлах з встановленим бітом setuid видається в зведення. Якщо зміни знайшлися, то ви повинні бути впевнені, що «так і має бути» (в іншому випадку є ймовірність що у вашій системі оселився троян – прим. перекладача).

Секція «uids of 0»

По-замовчуванню тільки користувачі root і toor мають UID = 0. UID = 0 означає, що користувач має повноваження супер. Ви повинні ставитися з крайнім підозрою до нових користувачам з UID = 0 (взагалі кажучи я ніколи не бачив щоб в системі були інші користувачі з UID = 0 крім root і toor, так що якщо вони у вас з’явилися, це явна ознака що в системі «хтось побував» – прим. перекладача).

Секція «Passwordless accounts» (Безпарольний користувачі)

Всі ми знаємо що користувачі без паролів це погано. Ця частина зведення покликана показати вам таких користувачів для того що б ви могли виправити ситуацію.

Секція «Packets denied by ipfw» (Пакети відкинуті брандмауером)

Пам’ятаєте, як ми розглядали журнали програми ipfw у статті IPFW Logging (див. www.onlamp.com/pub/a/bsd/2001/06/21/FreeBSD_Basics.html)? (Для тих, хто не пам’ятає, скажу, що стаття присвячена журналлірованію інформації надходить від брандмауера – прим. Перекладача). Ця частина сценарію перевіряє файл / var / log / ipfw.today і видає вам статистику про те, скільки пакетів було відкинуто при спробі пройти через ваш брандмауер.

Секція «ipfw rules that have reached the log limit» (Правила брандмауера за якими був перевищений обсяг журналлірумой інформації)

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

Секції «ipv6 packets denied by ip6fw» і «ipv6 rules which reached ip6fw’s log limit»

Теж що і дві попередні, однак для IPv6.

Секція «Kernel log messages» (Повідомлення ядра)

Ця частина сценарію видасть вам вміст файлу dmesg.today, в якому зберігаються системні повідомлення.

Секція «Login failures» (Невдалі спроби входу в систему)

Секція «tcp_wrapper warning messages» (Повідомлення від tcp wrapper’а)

Якщо ви настроїти tcp wrapper (tcp wrapper – це програма яка займається перевіркою пакетів по деяким простим правилам – прим. Перекладача), то все попереджувальні повідомлення від них будуть відображені в цій частині зведення. Якщо ви не знаєте як конфігурувати tcp wrapper, то прочитайте статтю www.onlamp.com/pub/a/bsd/2001/02/07/FreeBSD_Basics.html (На жаль tcp wrapper’и вкрай малоефективні для захисту мережі – прим. Перекладача).

Тепер давайте залишимо сценарій безпеки в спокої і рушимо далі. Наступний сценарій показує які поштові з’єднання були відкинуті:

# 460.status-mail-rejects daily_status_mail_rejects_enable = “YES” # Знайти відкинуті поштові з’єднання daily_status_mail_rejects_logs = 3 # Скільки журналів перевіряти

Сценарій, який видає інформацію про стан DNS сервера, можна безболісно відключити, якщо ви не запускаєте сервер імен на своїй машині. Однак якщо ваша машина є DNS сервером, то цей сценарій може бути вам корисний, оскільки він видає інформацію про відкинутих запитах на передачу інформації про зони. Запит про передачу інформації про зони з машини не є вашим вторинним сервером імен може означати, що хтось намагається збирати інформацію про будову вашої мережі. Для додаткового читання із забезпечення безпеки серверів імен читайте 11 главу нового видання книги DNS and Bind (див. www.oreilly.com/catalog/dns4/chapter/ch11.html).

# 470.status-named
daily_status_named_enable=”YES” daily_status_named_usedns = “YES” # Сценарій може використовувати DNS запити

Наступний сценарій забезпечує обробку поштового черги програми sendmail, як мінімум раз на день. У виконанні цього сценарію немає ніякої необхідності, оскільки по-замовчуванню sendmail раз в півгодини перевіряє поштову чергу на наявність недоставлених листів і намагається їх відправити.

# 500.queuerun daily_queuerun_enable = “YES” # Запуск обробки поштової черги

Це все щодня виконувані сценарії. Давайте розглянемо по порядку сценарії, які виконуються щотижня. Як і минулого разу ви можете встановити, кому відсилаються щотижневі звіти. По-замовчуванню їх отримує користувач root.

# These options are used by periodic(8) itself to
# determine what to do with the output of the sub-programs
# that are run, and where to send that output. $weekly_output
# might be set to /var/log/weekly.log if you wish to log the
# weekly output and have the files rotated by newsyslog(8)
# # Ці параметри використовуються програмою periodic # Для того що б визначити що робити з виведенням # Виконуваних сценаріїв і куди їх відсилати. Мінлива # $ Weekly_output може дорівнювати “/ var / log / weekly.log”, якщо ви # Хочете журналліровать висновок виконуваних сценаріїв і мати # Штатну можливість їх ротації за допомогою newsyslog.
weekly_output = “root” # Користувач або файл weekly_show_success = “YES” # Показувати висновок сценаріїв з кодом закінчення 0 weekly_show_info = “YES” # Показувати висновок сценаріїв з кодом закінчення 1 weekly_show_badconfig = “NO” # Показувати висновок сценаріїв з кодом закінчення 2

Перший сценарій видаляє всі файли з маскою kvm * ​​в каталозі / var / db. Оскільки я не знайшов у моїй системі жодного файлу з таким ім’ям, я заборонив виконання цього сценарію.

# 120.clean-kvmdb weekly_clean_kvmdb_enable = “YES” # Щотижнева очищення kvmdb weekly_clean_kvmdb_days = 7 # Якщо файл не використовували більше … днів weekly_clean_kvmdb_verbose = “YES” # Показати список вилучених файлів

Наступні два сценарії оновлюють до адекватного стану бази програм locate і whatis. Виконання цього сценарію є причиною «похрюкування» жорсткого диска близько четвертої ранку кожну суботу. Так як я дуже часто використовую команди locate і apropos, я залишив ці сценарії включеними.

# 310.locate weekly_locate_enable = “YES” # Оновлювати базу locate
# 320.whatis weekly_whatis_enable = “YES” # Оновлювати базу whatis

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

# 330.catman weekly_catman_enable = “NO” # Преформатірованіе сторінок man

Наступний сценарій так же відключений. Увімкніть його, якщо хочете знати, які файли у вашій системі мають невірних (неіснуючих) власників.

# 340.noid weekly_noid_enable = “NO” # Шукати нічийні файли weekly_noid_dirs = “/” # Шукати звідси

Останній сценарій з групи виконуваних кожну тиждень, може вас зацікавити, якщо ви маєте часто оновлюється дерево портів. Якщо ви дозволите цей сценарій, то він за тиждень буде порівнювати версії встановлених у вас пакетів з програмним забезпеченням з вмістом файлу / usr / ports / INDEX і надавати вам список пакетів, які слід оновити.

# 400.status-pkg weekly_status_pkg_enable = “NO” # Шукати застарілі пакети

У групі щомісячно виконуваних сценаріїв по-замовчуванню знаходиться тільки один сценарій, проте як завжди ви можете налаштувати кому посилати результати його виконання:

# These options are used by periodic(8) itself to
# determine what to do with the output of the sub-programs
# that are run, and where to send that output. $monthly_output
# might be set to /var/log/monthly.log if you
# wish to log the monthly output and have the files rotated
# by newsyslog(8)
# # Ці параметри використовуються програмою periodic # Для того що б визначити що робити з виведенням # Виконуваних сценаріїв і куди їх відсилати. Мінлива # $ Monthly_output може дорівнювати “/ var / log / monthly.log”, якщо ви # Хочете журналліровать висновок виконуваних сценаріїв і мати # Штатну можливість їх ротації за допомогою newsyslog.
# monthly_output = “root” # Користувач або файл monthly_show_success = “YES” # Показувати висновок сценаріїв з кодом закінчення 0 monthly_show_info = “YES” # Показувати висновок сценаріїв з кодом закінчення 1 monthly_show_badconfig = “NO” # Показувати висновок сценаріїв з кодом закінчення 2
# 200.accounting monthly_accounting_enable = “YES” # Статистика по користувачам системи

Цей сценарій показує статистику збирається командою ac. Якщо ця статистика вам нецікава, вимкніть цей сценарій. Ми розглядали команду ac у статті Monitoring UNIX logins (див. www.onlamp.com/pub/a/bsd/2001/02/14/FreeBSD_Basics.html).

Я сподіваюся, що ця стаття зніме завісу таємниці зі сценаріїв, які йдуть разом з вашою FreeBSD. До нових зустрічей і удачі у використанні BSD (в оригіналі «happy BSDing» 😉 – прим. перекладача).

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*