13 Отчет о состоянии службы и ее журнал



Pdf просмотр
страница7/12
Дата09.11.2016
Размер5.01 Kb.
Просмотров3109
Скачиваний0
1   2   3   4   5   6   7   8   9   ...   12
# systemctl kill sshd@172.31.0.52:22-172.31.0.4:47779.service
Вот, пожалуй, и все, что вам нужно знать о портировании inetd-служб в systemd и дальнейшем их использовании.
Применительно к SSH, в большинстве случаев схема с inetd-активацией позволяет сэкономить системные ресурсы и поэтому оказывается более эффективным решением,
чем использование обычного service-файла sshd, обеспечивающего запуск одиночной службы без использования сокет-активации (поставляется в составе пакета и может быть включен при необходимости). В ближайшее время я собираюсь направить соот- ветствующий запрос относительно нашего пакета SSH в багтрекер Fedora.
В завершение нашей дискуссии, сравним возможности xinetd и systemd, и выясним,
может ли systemd полностью заменить xinetd, или нет. Вкратце: systemd поддерживает далеко не все возможности xinetd и поэтому отнюдь не является его полноценной заме- ной на все случаи жизни. В частности, если вы заглянете в список параметров конфигу- рации xinetd, вы заметите, что далеко не все эти опции доступны в systemd. Например,
в systemd нет и никогда не будет встроенных служб echo, time, daytime, discard и т.д. Кроме того, systemd не поддерживает TCPMUX и RPC. Впрочем, б´
ольшая часть этих опций уже не актуальна в наше время. Подавляющее большинство inetd-служб не используют эти опции (в частности, ни одна из имеющихся в Fedora xinetd-служб не требует поддержки перечисленных опций). Стоит отметить, что xinetd имеет неко- торые интересные возможности, отсутствующие в systemd, например, списки контроля
48
доступа для IP-адресов (IP ACL). Однако, большинство администраторов, скорее всего,
согласятся, что настройка брандмауэра является более эффективным решением подоб- ных задач
44
, а для ценителей устаревших технологий systemd предлагает поддержку tcpwrap. С другой стороны, systemd тоже предоставляет ряд возможностей, отсутствую- щих в xinetd, в частности, индивидуальный контроль над каждым экземпляром службы
(см. выше), и внушительный набор настроек для контроля окружения, в котором за- пускаются экземпляры. Я надеюсь, что возможностей systemd должно быть достаточно для решения большинства задач, а в тех редких случаях, когда вам потребуются спе- цифические опции xinetd — ничто не мешает вам запустить его в дополнение к systemd.
Таким образом, уже сейчас в большинстве случаев xinetd можно выкинуть из числа обязательных системных компонентов. Можно сказать, что systemd не просто возвра- щает функциональность классического юниксового inetd, но еще и восстанавливает ее ключевую роль в Linux-системах.
Теперь, вооруженные этими знаниями, вы можете портировать свои службы с inetd на systemd. Но, конечно, будет лучше, если этим займутся разработчики из апстрима приложения, или сопровождающие вашего дистрибутива.
12
К вопросу о безопасности
Одно из важнейших достоинств Unix-систем — концепция разделения привилегий между различными компонентами ОС. В частности, службы обычно работают от име- ни специальных системных пользователей, имеющих ограниченные полномочия, что позволяет уменьшить ущерб для системы в случае взлома этих служб.
Однако, такой подход предоставляет лишь самую минимальную защиту, так как си- стемные службы, хотя уже и не получают полномочий администратора (root), все равно имеют практически те же права, что и обычные пользователи. Чтобы обеспечить бо- лее эффективную защиту, нужно поставить более жесткие ограничения, отняв у служб некоторые привилегии, присущие обычным пользователям.
Такая возможность предоставляется системами мандатного контроля доступа (далее
MAC, от Mandatory Access Control), например, SELinux. Если вам нужно обеспечить вы- сокий уровень безопасности на своем сервере, то вам определенно стоит обратить свое внимание на SELinux. Что же касается systemd, то он предоставляет разработчикам и администраторам целый арсенал возможностей по ограничению локальных служб,
и эти механизмы работают независимо от систем MAC. Таким образом, вне зависимо- сти от того, смогли ли вы разобраться с SELinux — у вас появляется еще несколько инструментов, позволяющих повысить уровень безопасности.
В этой главе мы рассмотрим несколько таких опций, предоставляемых systemd, и обсудим вопросы их практического применения. Реализация этих опций основана на ис- пользовании ряда уникальных технологий безопасности, интегрированных в ядро Linux уже очень давно, но при этом практически неизвестных для большинства разработчи- ков. Мы постарались сделать соответствующие опции systemd максимально простыми в использовании, чтобы заинтересовать администраторов и апстримных разработчиков.
Вот краткий перечень наиболее интересных возможностей
45
:
∙ Изолирование служб от сети
44
Прим. перев.: Стоит отметить, что приведенный пример является не единственным случаем, ко- гда возможности брандмауэра Linux дублируются опциями xinetd. Например, количество соединений с каждого хоста может быть ограничено критерием connlimit, а скорость поступления входящих соеди- нений можно контролировать сочетанием критериев limit и conntrack (ctstate NEW). Критерий recent позволяет создать аналог простейшей IDS/IPS, реализованной механизмом SENSORS в xinetd. Кро- ме того, в ряде случаев возможности брандмауэра значительно превосходят функциональность xinetd.
Например, критерий hashlimit, опять-таки в сочетании с conntrack, позволяет ограничить скорость по- ступления входящих соединений с каждого хоста (не путать с критерием connlimit, ограничивающим количество одновременно открытых соединений). Также стоит отметить, что интегрированная в Linux подсистема ipset гораздо лучше подходит для работы с большими списками разрешенных/запрещенных адресов, нежели встроенные механизмы xinetd.
45
Прим. перев.: В приведенном здесь списке не упомянута встроенная в systemd поддержка фильтров seccomp (опция SystemCallFilter=), так как она была добавлена уже после написания исходной статьи,
в выпуске systemd 187.
49

∙ Предоставление службам независимых каталогов /tmp
∙ Ограничение доступа служб к отдельным каталогам
∙ Принудительное отключение полномочий (capabilities) для служб
∙ Запрет форка, ограничение на создание файлов
∙ Контроль доступа служб к файлам устройств
Все эти опции описаны в
man-страницах systemd,
главным образом,
в systemd.exec(5)
46
. Если вам потребуется дополнительная информация, вы можете об- ратиться к ним.
Все эти опции доступны на системах с systemd, вне зависимости от использования
SELinux или любой другой реализации MAC.
Все эти опции не так уж и обременительны, и поэтому их разумнее будет использо- вать даже в тех случаях, когда явная необходимость в них, казалось бы, отсутствует.
Например: даже если вы полагаете, что ваша служба никогда не пишет в каталог /tmp,
и поэтому использование PrivateTmp=yes (см. ниже) вроде бы и не обязательно — луч- ше включить эту опцию, просто потому, что вы не можете знать наверняка, как будут вести себя используемые вами сторонние библиотеки (и плагины для них). В частности,
вы никогда не узнаете, какие модули NSS могут быть включены в каждой конкретной системе, и пользуются ли они каталогом /tmp.
Мы надеемся, что перечисленные опции окажутся полезными как для администра- торов, защищающих свои системы, так и для апстримных разработчиков, желающих сделать свои службы безопасными «из коробки». Мы настоятельно рекомендуем разра- ботчикам использовать такие опции по умолчанию в апстримных service-файлах — это сравнительно несложно, но дает значительные преимущества в плане безопасности.
12.1
Изолирование служб от сети
Простая, но мощная опция, которой вы можете воспользоваться при настройке служ- бы — PrivateNetwork=:
[Service]
ExecStart=...
PrivateNetwork=yes
Добавление этой строчки обеспечивает полную изоляцию от сети всех процессов данной службы. Они будут видеть лишь интерфейс обратной петли (lo), причем полностью изо- лированный от обратной петли основной системы. Чрезвычайно эффективная защита против сетевых атак.
Предупреждение: Некоторым службам сеть необходима для нормальной работы.
Разумеется, никто и не говорит о том, чтобы применять PrivateNetwork=yes к сетевым службам, таким, как Apache. Однако даже те службы, которые не ориентированы на сетевое взаимодействие, могут нуждаться в сети для нормального функционирования,
и порой эта потребность не вполне очевидна. Например, если ваша система хранит учет- ные записи пользователей в базе LDAP, для выполнения системных вызовов наподобие getpwnam() может потребоваться обращение к сети. Впрочем, даже в такой ситуации,
как правило, можно использовать PrivateNetwork=yes, за исключением случаев, когда службе может потребоваться информация о пользователях с UID ≥ 1000.
Если вас интересуют технические подробности: эта возможность реализована с ис- пользованием технологии сетевых пространств имен (network namespaces). При задей- ствовании данной опции, для службы создается новое пространство имен, в котором настраивается только интерфейс обратной петли.
46
Прим. перев.: Начиная с systemd версии 206, значительная часть обсуждаемых здесь настроек вынесена на отдельную страницу systemd.cgroup(5)
. Начиная с systemd 208, эта страница переименована в
systemd.resource-control(5)
50

12.2
Предоставление службам независимых каталогов /tmp
Еще одна простая, но мощная опция настройки служб — PrivateTmp=:
[Service]
ExecStart=...
PrivateTmp=yes
При задействовании этой опции, служба получит свой собственный каталог /tmp, пол- ностью изолированный от общесистемного /tmp. По давно сложившейся традиции, в
Unix-системах каталог /tmp является общедоступным для всех локальных служб и поль- зователей. За все эти годы, он стал источником огромного количества проблем безопас- ности. Чаще всего встречаются атаки с использованием символьных ссылок (symlink attacks) и атаки на отказ в обслуживании (DoS attacks). Использование независимой версии данного каталога для каждой службы делает подобные уязвимости практически бесполезными.
Для релиза Fedora 17
утверждена инициатива, направленная на включение этой оп- ции по умолчанию для большинства системных служб.
Предупреждение: Некоторые службы используют /tmp не по назначению, поме- щая туда сокеты IPC и другие подобные элементы, что само по себе уже является уязвимостью (хотя бы потому, что используемые при передаче информации файлы и каталоги должны иметь предсказуемые имена, что делает подобные службы уязвимы- ми к атакам через символьные ссылки и атакам на отказ в обслуживании). Подобные объекты лучше помещать в каталог /run, так как в нем присутствует строгое разде- ление доступа. В качестве примера такого некорректного использования /tmp можно привести X11, размещающий там свои коммуникационные сокеты (впрочем, в данном конкретном случае некоторые меры безопасности все же присутствуют: сокеты разме- щаются в защищенном подкаталоге, который создается на ранних стадиях загрузки).
Разумеется, для служб, использующих /tmp в целях коммуникации, включение опции
PrivateTmp=yes недопустимо. К счастью, подобных служб сейчас уже не так уж и мно- го
47
Эта опция использует технологию пространств имен файловых систем (filesystem namespaces), реализованную в Linux. При включении данной опции, для службы созда- ется новое пространство имен, отличающееся от иерархии каталогов основной системы только каталогом /tmp.
12.3
Ограничение доступа служб к отдельным каталогам
Используя опции ReadOnlyDirectories= и InaccessibleDirectories=, вы можете ограничить доступ службы к указанным каталогам только чтением, либо вообще запре- тить его:
[Service]
ExecStart=...
InaccessibleDirectories=/home
ReadOnlyDirectories=/var
Добавление этих двух строчек в файл конфигурации приводит к тому, что служба пол- ностью утрачивает доступ к содержимому каталога /home (она видит лишь пустой ка- талог с правами доступа 000), а также не может писать внутрь каталога /var.
47
Прим. перев.: Начиная с systemd 209, поддерживается опция JoinsNamespaceOf= (секция [Unit]),
позволяющая поместить два и более юнитов в одну «песочницу» (пространство имен), в результате чего такие юниты смогут взаимодействовать между собой, как через сетевой интерфейс обратной петли, так и через файлы в каталоге /tmp, при этом оставаясь изолированными от остальной системы. Подробности можно уточнить на странице руководства systemd.unit(5)
51

Предупреждение: К сожалению, в настоящее время опция ReadOnlyDirectories=
не применяется рекурсивно к точкам монтирования, расположенным в поддереве ука- занного каталога (т.е. файловые системы, смонтированные в подкаталогах /var, по- прежнему останутся доступными на запись, если, конечно, не перечислить их все по- именно). Мы собираемся исправить это в ближайшее время.
Механизм работы этой опции тоже реализован с использованием пространств имен файловых систем.
12.4
Принудительное отключение полномочий (capabilities) для служб
Еще одна чрезвычайно эффективная опция — CapabilityBoundingSet=, позволяю- щая контролировать список capabilities, которые смогут получить процессы службы:
[Service]
ExecStart=...
CapabilityBoundingSet=CAP_CHOWN CAP_KILL
В нашем примере, служба может иметь лишь полномочия CAP_CHOWN и CAP_KILL. По- пытки какого-либо из процессов службы получить любые другие полномочия, даже с использованием suid-бинарников, будут пресекаться. Список возможных полномочий приведен на странице документации capabilities(7)
. К сожалению, некоторые из них яв- ляются слишком общими (разрешают очень многое), например, CAP_SYS_ADMIN, однако выборочное делегирование полномочий все же является неплохой альтернативой запус- ку службы с полными административными (рутовыми) привилегиями.
Как правило, определение списка полномочий, необходимых для работы конкретной службы, является довольно трудоемким процессом, требующим ряда проверок. Чтобы немного упростить эту задачу, мы добавили возможность создания «черного списка»
привилегий, как альтернативы описанному выше механизму «белого списка». Вместо того, чтобы указывать, какие привилегии можно оставить, вы можете перечислить, ка- кие из них оставлять точно нельзя. Например: привилегия CAP_SYS_PTRACE, предназна- ченная для отладчиков, дает очень широкие полномочия в отношении всех процессов системы. Очевидно, что такие службы, как Apache, не занимаются отладкой чужих процессов, и поэтому мы можем спокойно отнять у них данную привилегию:
[Service]
ExecStart=...
CapabilityBoundingSet=
CAP_SYS_PTRACE
Наличие символа после знака равенства инвертирует принцип работы опции: следу- ющий за ним перечень привилегий рассматривается уже не как белый, а как черный список.
Предупреждение: Некоторые службы, при отсутствии определенных привилегий,
могут вести себя некорректно. Как уже говорилось выше, формирование списка необхо- димых полномочий для каждой конкретной службы может оказаться довольно трудной задачей, и лучше всего будет обратиться с соответствующим запросом к разработчикам службы.
Предупреждение 2:
Привилегии — отнюдь не лекарство от всех бед.
Чтобы они работали действительно эффективно, возможно, придется дополнить их другими мето- диками защиты.
Чтобы проверить, какие именно привилегии имеют сейчас ваши процессы, вы можете воспользоваться программой pscap из комплекта libcap-ng-utils.
52

Применение опции CapabilityBoundingSet= является простой, прозрачной и удоб- ной альтернативой введению аналогичных ограничений через модификацию исходного кода всех системных служб.
12.5
Запрет форка, ограничение на создание файлов
Некоторые меры безопасности можно ввести при помощи механизма ограничения ресурсов. Как следует из его названия, этот механизм предназначен прежде всего для контроля использования ресурсов, а не для контроля доступа. Однако, две его на- стройки могут быть использованы для запрета определенных действий: с помощью
RLIMIT_NPROC можно запретить службе форкаться (запускать дополнительные процес- сы), а RLIMIT_FSIZE позволяет блокировать запись в файлы ненулевого размера:
[Service]
ExecStart=...
LimitNPROC=1
LimitFSIZE=0
Обратите внимание, что эти ограничения будут эффективно работать только в том слу- чае, если служба запускается от имени простого пользователя (не root) и без привилегии
CAP_SYS_RESOURCE (блокирование этой привилегии можно обеспечить, например, опи- санной выше опцией CapabilityBoundingSet=). В противном случае, ничто не мешает процессу поменять соответствующие ограничения.
Предупреждение: LimitFSIZE= действует очень жестко. Если процесс пытается записать файл ненулевого размера, он немедленно получает сигнал SIGXFSZ, который,
как правило, прекращает работу процесса (в случае, если не назначен обработчик сигна- ла). Кроме того, стоит отметить, что эта опция не запрещает создание файлов нулевого размера.
Подробности об этих и других опциях ограничения ресурсов можно уточнить на странице документации setrlimit(2)
12.6
Контроль доступа служб к файлам устройств
Файлы устройств предоставляют приложениям интерфейс для доступа к ядру и драйверам. Причем драйверы, как правило, менее тщательно тестируются и не так аккуратно проверяются на предмет наличия уязвимостей, по сравнению с основными компонентами ядра. Именно поэтому драйверы часто становятся объектами атаки зло- умышленников. systemd позволяет контролировать доступ к устройствам индивидуаль- но для каждой службы:
[Service]
ExecStart=...
DeviceAllow=/dev/null rw
Приведенная конфигурация разрешит службе доступ только к файлу /dev/null, запре- тив доступ ко всем остальным файлам устройств.
Реализация данной опции построена на использовании cgroups-контроллера devices.
12.7
Прочие настройки
Помимо приведенных выше, простых и удобных в использовании опций, существует и ряд других других настроек, позволяющих повысить уровень безопасности. Но для их использования, как правило, уже требуются определенные изменения в исходном коде службы, и поэтому такие настройки представляют интерес прежде всего для апстрим- ных разработчиков. В частности, сюда относится опция RootDirectory= (позволяющая
53
запустить службу chroot()-окружении), а также параметры User= и Group=, определя- ющие пользователя и группу, от имени которых работает служба. Использование этих опций значительно упрощает написание демонов, так как работа по понижению приви- легий ложится на плечи systemd.
Возможно, у вас возникнет вопрос, почему описанные выше опции не включены по умолчанию. Отвечаем: чтобы не нарушать совместимость. Многие из них несколько отступают от традиций, принятых в Unix. Например, исторически сложилось, так что
/tmp является общим для всех процессов и пользователей. Существуют программы,
использующие этот каталог для IPC, и включение по умолчанию режима изоляции для
/tmp нарушит работу таких программ.
И несколько слов в заключение. Если вы занимаетесь сопровождением unit-файлов в апстримном проекте или в дистрибутиве, пожалуйста, подумайте о том, чтобы восполь- зоваться приведенными выше настройками. Если сопровождаемая вами служба станет более защищенной в конфигурации по умолчанию («из коробки»), от этого выиграют не только ваши пользователи, но и все мы, потому что Интернет станет чуть более безопасным.
13
Отчет о состоянии службы и ее журнал
При работе с системами, использующими systemd, одной из наиболее важных и ча- сто используемых команд является systemctl status. Она выводит отчет о состоянии службы (или другого юнита). В таком отчете приводится статус службы (работает она или нет), список ее процессов и другая полезная информация.
В Fedora 17 мы ввели
Journal
, новую реализацию системного журнала, обеспечива- ющую структурированное, индексированное и надежное журналирование, при сохране- нии совместимости с классическими реализациями syslog. Собственно, мы начали работу над Journal только потому, что хотели добавить одну, казалось бы, простую, возмож- ность: включить в вывод systemctl status последние 10 сообщений, поступивших от службы в системный журнал. Но на практике оказалось, что в рамках классических механизмов syslog, реализация этой возможности чрезвычайно сложна и малоэффек- тивна. С другой стороны, сообщения службы в системный журнал несут очень важную информацию о ее состоянии, и такая возможность действительно была бы очень полез- ной, особенно при диагностике нештатных ситуаций.
Итак, мы интегрировали Journal в systemd, и научили systemctl работать с ним.
Результат выглядит примерно так:
$ systemctl status avahi-daemon.service avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled)
Active: active (running) since Fri, 18 May 2012 12:27:37 +0200; 14s ago
Main PID: 8216 (avahi-daemon)
Status: "avahi-daemon 0.6.30 starting up."
CGroup: name=systemd:/system/avahi-daemon.service
8216 avahi-daemon: running [omega.local]
8217 avahi-daemon: chroot helper
May 18 12:27:37 omega avahi-daemon[8216]: Joining mDNS multicast group on interface eth1.IPv4 with address 172.31.0.52.
May 18 12:27:37 omega avahi-daemon[8216]: New relevant interface eth1.IPv4 for mDNS.
May 18 12:27:37 omega avahi-daemon[8216]: Network interface enumeration completed.
May 18 12:27:37 omega avahi-daemon[8216]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
May 18 12:27:37 omega avahi-daemon[8216]: Registering new address record for fd00::e269:95ff:fe87:e282 on eth1.*.
May 18 12:27:37 omega avahi-daemon[8216]: Registering new address record for 172.31.0.52 on eth1.IPv4.
May 18 12:27:37 omega avahi-daemon[8216]: Registering HINFO record with values ’X86_64’/’LINUX’.
May 18 12:27:38 omega avahi-daemon[8216]: Server startup complete. Host name is omega.local. Local service cookie is 3555095952.
May 18 12:27:38 omega avahi-daemon[8216]: Service "omega" (/services/ssh.service) successfully established.
May 18 12:27:38 omega avahi-daemon[8216]: Service "omega" (/services/sftp-ssh.service) successfully established.
54

Очевидно, это отчет о состоянии всеми любимого демона mDNS/DNS-SD, причем после списка процессов, как мы и обещали, приведены сообщения этого демона в системный журнал. Миссия выполнена!
Команда systemctl status поддерживает ряд опций, позволяющих настроить вывод информации в соответствии с вашими пожеланиями. Отметим две наиболее интересные из них: ключ -f позволяет в реальном времени отслеживать обновление сведений (по аналогии с tail -f), а ключ -n задает количество выводимых журнальных записей (как нетрудно догадаться, по аналогии с tail -n).
Журнальные записи собираются из трех различных источников. Во-первых, это со- общения службы в системный журнал, отправленные через функцию libc syslog().
Во-вторых, это сообщения, отправленные через штатный API системы Journal. И нако- нец, это весь текст, выводимый демоном в STDOUT и STDERR. Проще говоря, все, что демон считает нужным сказать администратору, собирается, упорядочивается и отоб- ражается в одинаковом формате.
Добавленная нами возможность, при всей своей простоте, может оказаться чрезвы- чайно полезной практически любому администратору. По-хорошему, ее стоило реализо- вать еще 15 лет назад.
14
Самодокументированный процесс загрузки
Нам часто приходится слышать жалобы, что процесс загрузки при использовании systemd очень сложен для понимания. Не могу с этим согласиться. Более того, я бе- русь даже утверждать обратное: по сравнению с тем, что мы имели раньше (когда для того, чтобы разобраться в загрузке, нужно было иметь хорошие навыки программиро- вания на языке Bourne Shell
48
), процесс загрузки стал более простым и прозрачным. Но определенная доля истины в этом критическом замечании все же есть: даже опытному
Unix-администратору при переходе на systemd нужно изучить некоторые новые для се- бя вещи. Мы, разработчики systemd, обязаны максимально упростить такое обучение.
Решая поставленную задачу, мы подготовили для вас кое-какие приятные сюрпризы, и предоставили хорошую документацию даже там, где это казалось невозможным.


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   12


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал