Yaleks: Новая: {{цикл/Безопасность}} == Ограничить в обслуживании! == ''ЧАСТЬ 2: Лишние сервисы в вашей машине могут рабо...

2008-07-29T14:46:07Z

Новая: {{цикл/Безопасность}} == Ограничить в обслуживании! == ''ЧАСТЬ 2: Лишние сервисы в вашей машине могут рабо...

Новая страница

{{цикл/Безопасность}}

== Ограничить в обслуживании! ==
''ЧАСТЬ 2: Лишние сервисы в вашей машине могут работать на врага. Д-р '''Крис Браун''' ищет их и отстреливает, отгоняя злоумышленников.''

Снова здравствуйте, и добро пожаловать на второй урок по
безопасности Linux. В прошлом месяце мы обсуждали важные
вещи, касающиеся паролей, и я показал вам, как защититься
от некоторых эксплойтов этапа загрузки, дающих привилегии root. Я
также объяснил, как использовать sudo для контроля над повышением
привилегий пользователей, не разглашая администраторский пароль.
В этом месяце мы научимся отключать в системе ненужные сервисы,
ужесточим права доступа к файлам и познакомимся с некоторыми
инструментами, включая Bastille, которые помогут нам в этом.

В недалеком прошлом, устанавливая Unix-систему, я обнаруживал, что практически каждый сетевой сервис по умолчанию был
запущен. Telnet, FTP и rlogin? Да, все включены. NFS и NIS? Работают.
Запускались даже такие тривиальные сервисы, как Chargen, ECHO и
Daytime. Unix-система как бы говорила: «Смотрите, как много сервисов, разве это не здорово?» Конечно, Интернет в то время был поспокойнее, прямо-таки Хоббитон в киберпространстве. Сейчас это скорее
поле битвы, больше похожее на Мордор – в результате в установках
Linux-систем по умолчанию не включены никакие сетевые сервисы,
кроме sshd. Это пример соблюдения важного принципа: не запускайте
сервисы, которые вам не нужны.

=== Часть 1: Просмотр запущенных сервисов ===
[[Изображение:Img 85 82 2.jpg|thumb|Рис. 1 Проверка открытых портов на моем ноутбуке с помощью lsof.]]
Самый непосредственный способ проверить, какие сервисы запущены на вашей машине – запрос открытых TCP и UDP-портов, который
можно сделать командой lsof -i. На рис. 1 показан пример вывода
этой команды, выполненной на моем ноутбуке; должен признаться, я
не очень в курсе, что именно там понаписано. Ну, portmap – это RPC-демон, необходимый для работы службам NFS и NIS, а master – агент
доставки почты postfix, а cupsd – что-то насчет печати. Но зачем здесь
какие-то процессы http2 (Apache)?

Угадать назначение всех этих таинственных демонов – задача не из
легких. Проверьте, есть ли man-страница для сервиса или посмотрите
иерархию запущенных процессов. Например, pstree показывает, что hp
и hpijs на рис. 1 – потомки cupsd, и, значит, имеют отношение к печати.
Вот соответствующий фрагмент вывода:
<pre>
$ pstree |head
init─┬─acpid
├─cron
├─cupsd─┬─foomatic-rip───foomatic-rip─┬─foomatic-rip
│ │ └─sh───gs─┬─hpijs
│ │ └─sh───cat
│ └─hp
</pre>
Вред от работы ненужных сервисов невелик, однако теоретически
их можно использовать как лазейку в вашей системе. Ошибка типа
переполнения буфера способна помочь вредителю заставить сервер
выполнять произвольный код. Такие атаки довольно часты и, как ни
печально, почти так же часто успешны.

{{Врезка
|Заголовок=Скорая помощь
|Содержание=На сервисы
вроде Telnet
и FTP, некогда
рабочие лошадки
Интернета,
сейчас смотрят
косо, поскольку
они принимают
пароль и имя
пользователя
по сети в виде
открытого текста.
Как ни смешно,
анонимный
FTP – и тот гораздо
безопаснее, как
раз потому, что
не требует для
соединения имени
пользователя
и пароля.
|Ширина=250px}}
Например, из-за уязвимости по переполнению буфера в ProFTPd-сервере можно было захватить root-привилегии, скачивая особым
образом составленные файлы в ASCII-режиме. Уязвимость была найдена в сентябре 2003 года и давно исправлена; однако дыры постоянно обнаруживаются в Skype, Adobe Reader, ядре Linux и других
компонентах.

Отключив ненужные сервисы, вы значительно снизите вероятность успеха подобных атак. Сообщество Open Source очень быстро
устраняет найденные уязвимости, но это вам поможет, только если
вы установите исправленную версию. Фактически, абсолютное большинство атак происходит на те компоненты, для которых заплатки уже
доступны; тем умнее будет подписаться на рассылки по обновлениям
безопасности вашего дистрибутива, например, Up2date от Red Hat, и
регулярно их применять. Под «регулярно» я понимаю не каждые три
месяца (даже три дня могут оказаться роковыми). Атакующие не станут
дожидаться вашего очередного ежеквартального обновления.

=== Часть 2: Отключение ненужных сервисов ===
А как их отключить? В Fedora или Red Hat Linux вы можете остановить
сервис httpd так:
<source lang="bash">service httpd stop</source>
В SUSE эквивалентной командой будет
<source lang="bash">service apache2 stop</source>
Это всего лишь остановит сервис «здесь и сейчас», а на самом
деле нужно предотвратить его запуск во время загрузки системы. Вы
можете сделать это программой chkconfig. Например, чтобы отключить автоматический запуск Fedora или Red Hat, выполните следующую команду:
<source lang="bash">chkconfig --del httpd</source>
В SUSE такой командой будет:
<source lang="bash">chkconfig --del apache2</source>
Chkconfig управляет сложным набором символических ссылок для
загрузки сервисов на различных уровнях запуска (runlevel). Команда
<source lang="bash">chkconfig --list</source>
покажет вам статус всех сервисов, управляемых подобным образом, а
также выведет их уровень запуска.
Отключение ненужных сервисов – это один из способов оградить
ваш черный ход от плохих парней. А лучше вообще удалить ненужные
сервисы: нет программы – нет проблемы, даже если кто-то все-таки
проник в вашу систему. Не нужен вам, например, инструментарий разработчика (компилятор С и т.д.), так и не устанавливайте его: глядишь,
руткит в вашей системе и не скомпилируется. Если вы настраиваете
сетевой сервер, незачем устанавливать Х-сервер и графическое рабочее окружение; и т.д.

==== Меньше – лучше ====
На моей тестовой Fedora Core 5, когда я запускаю графический рабочий
стол и вхожу в систему, вкалывает уже более 20 дополнительных процессов. Некоторые из них запущены от имени root. Знаю ли я, что они
делают? Нет. Знаю ли я, что им можно доверять? Нет. Даже если работа каждого из них в отдельности безопасна, могу ли я быть уверен, что
их комбинация не создает побочных эффектов? Нет. И никто не может.
Смысл прост: чем меньше сервисов установлено и запущено, тем меньше шансы злоумышленника на обнаружение уязвимости.

{{Врезка|center|
|Заголовок=Ограничение на вход в систему от имени root
|Содержание=В прошлом месяце мы обсудили опасности входа в систему от имени
суперпользователя и призвали к использованию команды su для получения прав root только при необходимости. Вы можете пойти дальше и
сделать невозможным вход в систему суперпользователя, оставив единственным способом получения root-привилегий команду su. Это легко
сделать для программы login: Linux допускает сессии root только в терминалах, перечисленных в /etc/security. Если этот файл пуст, зайти как
root из терминала будет невозможно. (Будьте осторожны! Если файл
удалить, то войти в систему как root вы сможете отовсюду).

Отключение входа под root в KDE и Gnome немножко сложнее.
Обычно в конфигурационном файле есть параметр вроде AllowRootLogin
или AllowRoot, который должен быть установлен в значение false, но
найти его нелегко [проще воспользоваться графическими утилитами
настройки KDM/GDM, – прим. ред.]. Очевидное преимущество – предотвращение входа напрямую как суперпользователя. Другое преимущество использования su – su оставляет записи в /var/log/messages или
/var/log/secure, так что вы сможете выяснить, кто что делал от лица
root и когда.

Вы также можете ограничить использование su определенными группами. Группы wheel и root обычно для этого и используются, однако вы
можете определить любую группу:
<source lang="bash">chgrp wheel /bin/su
chmod 4550 /bin/su</source>
Комбинирование этих методов приводит к интересной ситуации. Даже
если кто-нибудь подслушает пароль в кафетерии, он не сможет получить
права суперпользователя, потому что напрямую от root заходить в систему нельзя, и через su получить права тоже не удастся, пока пользователь
не в нужной группе.

Если вы решите применять эти приемы, убедитесь, что добавили хотя
бы одного пользователя в группу wheel. Иначе вы сами не сможете получить администраторский доступ и вам придется загружаться с какогонибудь LiveCD для исправления ситуации.
|Ширина=}}

=== Часть 3 Системные инструменты ограничения прав ===
Есть несколько утилит, специально спроектированных для укрепления безопасности вашей системы (как правило, для отключения
ненужных компонентов и «ужесточения» прав доступа к файлам) и
предлагающих более систематический подход, нежели чисто «ручной». Bastille – одна из лучших подобных программ. Bastille не только укрепляет защиту, она еще и поможет разобраться, как работают
системы безопасности. На время написания статьи последняя версия
(3.0.9) была доступна по адресу http://prdownloads.sourceforge.net/Bastille-linux/Bastille-3.0.9-1.0.noarch.rpm (ее можно взять с нашего
диска).

Bastille написана на Perl, так что вам потребуется интерпретатор
этого языка и библиотеки Perl-Tk или Perl-Curses для пользовательского интерфейса (возможно, в вашем дистрибутиве эти пакеты устанавливаются по умолчанию). После установки просто запустите Bastille с
опцией -х для интерактивной графической сессии или с опцией -а для
оценки безопасности вашей системы.

[[Изображение:Img 85 84 1.jpg|thumb|Рис. 2 Один из многих разделов вопросника Bastille. Да, он сероват, но безопасность не в красоте.]]
Интерактивная сессия учинит вам допрос о ваших опциях по безопасности. На рис. 2 показан один разделов этого допроса – все разделы сгруппированы в 15 категорий, перечисленных слева. Вас спросят,
«Хотите ли вы отключить r*-утилиты?», «Хотите ли вы ограничить
срок жизни паролей?» и многое другое. При первом запуске вы, возможно, затруднитесь ответить на некоторые вопросы. В этом случае
лучшим выходом будет сделать себе чашечку кофе, возможно, устроить срочное совещание, и все-таки решить, чего вы хотите. Это часть
процесса определения политики безопасности, и это важный шаг по
защите вашей машины. Кстати, Bastille не сделает ничего до тех пор,
пока вы не ответите на все вопросы и не подтвердите изменения.

[[Изображение:Img 85 84 2.jpg|thumb|Рис. 3 Главное назначение отчетов Bastille – затруднить атаки на вашу систему, а заодно это неплохой инструмент обучения администраторов.]]
Также вы можете запустить Bastille в оценочном режиме (опция -а):
никаких изменений она делать не будет, лишь выведет отчет в виде
HTML-страницы и покажет его в браузере. Вы можете видеть пример
такого отчета на рис. 3. Каждая позиция в отчете также является ссылкой на более подробное объяснение.

==== Мастер безопасности SUSE ====
{{Врезка
|Заголовок=Права доступа к файлам в SUSE
|Содержание=
{{{!}}
!Права доступа
!Уровень безопасности
{{!}}-
{{!}}Permissions {{!}}{{!}}Простейший набор прав. Более мягкие права доступа, нежели те, что указаны в этом файле, не просто небезопасны, а уже надпись на могиле!
{{!}}-
{{!}}Permissions.easy {{!}}{{!}}Довольно мягкие права для использования в настольных системах с одним пользователем.
{{!}}-
{{!}}Permissions.secure {{!}}{{!}}Более безопасный набор прав для многопользовательских или сетевых систем. Вот комментарий из файла: «Главная задача этих прав – заставить простые вещи, вроде смены паролей или использования сетевых программ, правильно работать для непривилегированного пользователя».
{{!}}-
{{!}}Permissions.paranoid {{!}}{{!}}Очень безопасный набор прав. Похож на предыдущий вариант, однако SUID и SGID-биты сбрасываются. Эти настройки подходят для сетевых сервисов или межсетевых экранов, в которые обычным пользователям делать нечего.
{{!}}-
{{!}}Permissions.local {{!}}{{!}}Это специальный файл для добавления прав на дополнительные программы. По умолчанию он пуст.
{{!}}}
|Ширина=300px}}
Теперь давайте рассмотрим мастер безопасности, встроенный в
SUSE Linux. Этот компонент, входящий в YaST, тоже предназначен
для укрепления системы. Он дает возможность привести в порядок
множество опций и настраивает соответствующие файлы конфигурации. Для его запуска выберите пункт Локальная безопасность (Local
Security) из секции Безопасность и пользователи (Security and Users)
конфигуратора YaST. На первом экране мастер спросит вас, не хотите ли вы применить один из трех готовых шаблонов безопасности.
В порядке увеличения безопасности они выглядят так: домашний
компьютер (Home Workstation), сетевая рабочая станция (Networked
Workstation) и сетевой сервер (Network Server). Если хотите, можете
просто выбрать один из этих профилей и нажать Finish. Это, конечно,
довольно тупой способ настройки безопасности системы, но уж точно
лучше, чем ничего.

Для более тонкой настройки выберите Custom Settings и нажмите Next. Это перенесет вас в первый из пяти шагов, где вы можете
установить различные настройки (однако, как и в случае с Bastille,
вы должны знать, чего вы хотите). Вы можете включить и отключить
проверку качества паролей, о которой мы говорили в первой части
в [[LXF84:Безопасность|LXF84]] (вы ведь читали первую часть?). Можете выбрать метод
шифрования пароля и другие параметры. Можете контролировать
задержку после неудачной попытки входа в систему (увеличение
этой задержки, несомненно, замедлит ручной подбор пароля, но
таким способом пытаются проникнуть в систему разве что самые
простодушные злодеи). Вы можете настроить действие системы по
нажатию Ctrl+Alt+Del и указать, какие пользователи могут завершать
работу системы.

Также возможно проконтролировать, какие . (текущие каталоги)
должны быть включены в пути поиска для супер- и других пользователей. Зачем это надо? Допустим, вы зашли в оболочку и запускаете
какую-нибудь обычную программу, вроде cp. Какая программа запустится? Ответ такой: любой файл с именем cp, который оболочка первым найдет в путях поиска. Вы надеетесь, что это cp, расположенная
в директории /bin. Однако если включить . (текущий каталог) в путь
поиска (особенно перед /bin), есть реальная опасность, что запускаемая команда cp – одна из тех, что злоумышленник подкинул вам в
текущую директорию. Таким способом можно запускать любые программы с вашими правами. Если вы суперпользователь, последствия
могут быть особенно серьезными. По этой причине разумно не включать . в пути поиска. Захочется запустить какую-нибудь программу,
находящуюся в текущей директории – явно введите ./myprog вместо
myprog.

На последнем шаге вы можете выбрать, как жестко система будет
обращаться с правами доступа к файлам. Тут есть три варианта: простой, безопасный и параноидальный. На самом деле этот экран – всего
лишь интерфейс к программе chkstat, которая проверяет (и при необходимости подправляет) права доступа и владельца ключевых системных файлов. Программа читает один или более permission-файл в
директории /etc (см. врезку внизу справа). Синтаксис каждой строки в
этих файлах такой:
<pre>имя файла владелец:группа режим</pre>
Например, вот несколько строк из файла /etc/permissions.secure:
<pre>/usr/bin/passwd root:shadow 4755
/usr/bin/crontab root:trusted 4750
/etc/fstab root:root 644
/var/spool/fax/archive fax:uucp 700</pre>
Права доступа (режим) указываются в восьмеричном виде.
Восьмеричное значение 4000 устанавливает SUID-бит (см. врезку
вверху справа), другие три цифры отвечают за права чтения, записи и
выполнения для владельца, группы и всех остальных.

Для запуска chkstat с настройками из файла permissions.secure
(например), просто укажите имя файла в качестве аргумента. На моей
тестовой системе команда выглядит так:
<pre># chkstat /etc/permissions.secure</pre>
В моем случае на экран ничего не выводилось. Однако запустив chkstat с настройками из permissions.paranoid, вы увидите массу
предупреждений, в основном о файлах конфигурации, доступных не-суперпользователям, и о программах с установленным SUID-битом.

Запуск chkconfig с опцией --set велит программе исправлять любые
проблемы автоматически. Давайте нарочно сделаем права доступа
на один из системных файлов слишком слабыми и перезапустим
программу:
<source lang="text" line="GESHI_NORMAL_LINE_NUMBERS">
# chmod 666 /etc/fstab
# chkstat /etc/permissions.secure
Checking permissions and ownerships – using the permissions files /etc/permissions.secure
/etc/fstab should be root:root 0644. (wrong permissions 0666)
# chkstat --set /etc/permissions.secure
Checking permissions and ownerships – using the permissions files /etc/permissions.secure
setting /etc/fstab to root:root 0644. (wrong permissions 0666)
# ls -l /etc/fstab
-rw-r--r-- 1 root root 670 Oct 11 09:35 /etc/fstab
</source>
В первой строке я сменил права доступа к файлу /etc/fstab. В строках 2–4 я запустил chkstat, и он сообщил о проблеме. В строках 5–7 я
снова запустил chkstat, с опцией --set, и в строках 8–9 убедился, что
chkstat корректно решил проблему.

Давайте свяжем это с настройками привилегий из YaST. YaST устанавливает в /etc/sysconfig/security строку вроде этой (вариант для
профиля ‘easy’):
<pre>PERMISSION_SECURITY=”easy local”</pre>
Строка велит chkstat запускаться с файлами permissions.easy и
permissions.local. Программа chkstat запускается Suseconfig, скриптом,
который YaST использует для применения проделанных изменений.
Это значит, что права доступа к файлам будут проверяться каждый раз,
когда вы измените что-либо в YaST.

Есть и другие утилиты для подобных целей. Я планировал рассказать о Titan, который особенно популярен в Solaris, но он выглядит
бледно после выпуска Sun Security Toolkit от JASS. Есть еще Sussen,
сканер уязвимостей, основанный на OVAL ((Open Vulnerability and
Assessment Language). Это один из новоиспеченных C#/Mono-проектов,
о котором я надеюсь рассказать на следующих уроках. На сегодня все;
храните безопасность до следующего месяца!

{{Врезка|source|
|Заголовок=SUID-программы
|Содержание=В основе увеличения привилегий в Linux стоят
SUID-программы. Идея состоит в запуске программы с правами владельца исполняемого
файла, а не того, кто производит запуск. Это
поведение зависит от SUID-бита, который
является частью прав доступа к файлу.

Один из лучших примеров такой программы – /usr/bin/passwd. SUID-бит можно обнаружить в выводе ls -l:
<pre>ls -l /usr/bin/passwd
-r-s--x--x 1 root root 21944 Feb12 08:15 /usr/bin/passwd</pre>
В позиции четвертого символе вместо х стоит s. Обратите внимание, что файлом владеет
root. Поэтому программа может записывать
новый хэш в shadow-файл, прав на запись [и
чтение, – прим. ред.] в который у обычного
пользователя быть, конечно же, не должно.
Программа sudo, рассмотренная месяц назад,
также является SUID-программой – чтобы позволить запускать программы под другими
идентификаторами. (Если программа запускается с привилегиями root, она может сменить
текущий ID на любой.)

SUID-программы, особенно принадлежащие
root – всегда возможная уязвимость. Можно
ли верить, что такая программа делает только
то, что нужно? А вдруг она приписывает данные к файлам? Как грамотный системный
администратор, будьте бдительны по поводу
любых SUID-программ. Их можно найти так:
<source lang="bash">find / -perm +4000 -user root</source>
Установить SUID-бит можно таким образом:
<source lang="bash">chmod u+s filename</source>
а удалить
<source lang="bash">chmod u-s filename</source>
Вся идея SUID-бита запатентована дедушкой Unix, Деннисом Ричи [Dennis Ritchie].
Номер патента США – 4135240; он был выдан
16 января 1979 года.
|Ширина=}}

LXF85:Безопасность - История изменений

Yaleks: викификация

Yaleks: Новая: {{цикл/Безопасность}} == Ограничить в обслуживании! == ''ЧАСТЬ 2: Лишние сервисы в вашей машине могут рабо...