| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
Введение в автоматизацию. Часть 2.
В первой части мы начали выяснять какие сценарии запускаются программой 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 будет хорошей отправной точкой. Для дополнительного чтения почитайте информацию по следующим ссылкам: Давайте кратко пройдемся по пунктам сводки безопасности. Секция «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 (см. Секция «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, то прочитайте статью Теперь давайте оставим сценарий безопасности в покое и двинемся дальше. Следующий сценарий показывает какие почтовые соединения были отвергнуты: # 460.status-mail-rejects daily_status_mail_rejects_enable="YES" # Найти отвергнутые почтовые соединения daily_status_mail_rejects_logs=3 # Сколько журналов проверять Сценарий, выдающий информацию о состоянии DNS сервера, можно безболезненно отключить, если вы не запускаете сервер имен на своей машине. Однако если ваша машина является DNS сервером, то этот сценарий может быть вам полезен, поскольку он выдает информацию о отвергнутых запросах на передачу информации о зонах. Запрос о передаче информации о зонах с машины не являющейся вашим вторичным сервером имен может означать, что кто-то пытается собирать информацию о строении вашей сети. Для дополнительного чтения по обеспечению безопасности серверов имен читайте 11 главу нового издания книги DNS and Bind (см. # 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 (см. Я надеюсь, что эта статья снимет завесу тайны со сценариев, которые идут вместе с вашей FreeBSD. До новых встреч и удачи в использовании BSD (в оригинале «happy BSDing» ;-) - прим. переводчика). |
|
| ||||||||||||||||
|