Глава 12. Стратегия безопасности сервера

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

Я не специалист по защите системы, но я имел дело с большинством проблем с ней и я дам советы по обходу наиболее распространенных проблем. Хотя обновление регулярное обновление системы не дает гарантию, что защиту не обойдут, все же шансы хакеров сильно уменьшатся.

Хотя есть немало способов ворваться в систему (например, IMAP daemon exploit), основная угроза исходит все же изнутри. Связей с внешним миром не так и много, а вот в системе есть множество команд и утилит, в которых могут быть ошибки, которые могут использоваться хакером.

По этой причине я избегаю открывать пользователям доступ к оболочке, если он не абсолютно необходим. Даже если Вы рассматриваете ваших пользователей как полностью заслуживающих доверия, для взлома системы требуется только, чтобы один из этих пользователей имел слабый пароль. Получив в систему хакер непременно будет искать в ней еще дырки (замечание переводчика: точно, я сам так делаю).

Однако, можно успешно противостоять таким атакам. Детальное рассмотрение проблем защиты выходит за рамки данного руководства, так что здесь перечислено только то, что необходимо делать для уменьшения риска:

• Обновляйте системные утилиты, программы и ядро: При обновлении Вы будете уверены, что в системе нет старых программ, дырки в которых широко известны (замечание переводчика: в свое время был сервер в нашем университете, на котором стояла система, минимум трехлетней давности. Я делал с этим сервером много интересных вещей, а еще больше мог бы сделать, если бы хотел. Потом систему обновили, и 90% моих люков закрылись.). Подробности по поводу обновления системы см. в разделе Скачивание и установка обновлений для Red Hat главы 4 и в разделе Стратегии обновления и поддержки системы главы 10.

• Shadow passwords: Лучше всего их использовать, благо переход к ним прост ! Подробности в разделе Пароли в Linux & формат файла Shadow главы 6.

• Умное управление паролями: Следите, чтобы пароли менялись регулярно и были надежными. Если используется несколькосерверов, не ставьте одинаковые пароли. Иначе хакеру понадобится вычислить пароль только один раз (замечание переводчика: если пользуетесь Windows, не ставьте в качестве пароля пользователя для входа в сеть Microsoft свой пароль для Linux: в Windows пароли пользователей вскрыть не проблема).

• Используйте secure shell (ssh): Поставьте ``ssh'' вместо ``telnet''. Telnet передает все данные (и пароли тоже) открытым текстом и открытый порт для telnet будет первым местом, куда попробует залезть хакер (замечание переводчика: если на вашей рабочей станции кто-то поставил троян, перехватывающий ввод с клавиатуры, никакой ``ssh'' не поможет.).

  Ssh предоставляет зашифрованный и сжатый обмен данными, что куда лучше telnet-связи. Можно запустить сервер ssh (для беззопасных входящих соединений) и клиент (для исходящих безопасных соединений) под Linux. Двоичный пакет RPM можно взять на ftp://ftp.replay.com/pub/replay/redhat/i386. Новые версии постоянно выходят, так что следите за ними! Вам нужны следующие файлы:

  • ssh-1.2.27-5i.i386.rpm. Основной пакет.

  • ssh-clients-1.2.27-5i.i386.rpm. Клиенты для исходящих соединений.

  • ssh-extras-1.2.27-5i.i386.rpm Некоторые удобные perl-скрипты.

  • ssh-server-1.2.27-5i.i386.rpm Сервер для входящих соединений.

  Замечание: RPM-файлы для SSH, перечисленные выше, международные версии. Если Вы проживаете в США или Канаде, Вы можете загрузить американские пакеты (которые могут иметь более сильные алгоритмы шифрования); эти пакеты имеют суффикс ``us'' вместо ``i'' после номера версии. Согласно американскому закону, запрещено экспортировать сильные crypto-программы вне США или Канады. Когда-нибудь Министерство юстиции США увидит, к чему привела такая ситуация и удалит это глупое ограничение. (Red Hat не включает SSH из-за этого, и все мы страдаем). Замечание переводчика: на сегодняшний день ограничения на экспорт криптосистем из США уже сняты.

  Есть клиенты ssh и под Windows, что дает пользователям данной системы возможность соединиться по защищенному протоколу с сервером. Клиенты:

  “TeraTerm Pro” клиент

  http://hp.vector.co.jp/authors/VA002416/teraterm.html

  “TTSSH” клиент

  http://www.zip.com.au/roca/download.html

  “Cryptlib” клиент

  http://www.doc.ic.ac.uk/ci2/ssh

  “Putty” клиент

  http://www.chiark.greenend.org.uk/sgtatham/putty.html

  Замечание: Если вы перешли на использование ssh, позаботьтесь о его установке на всех ваших серверах. Наличие пяти защищенных и одного незащищенного сервера ничего хорошего не принесет, особенно если вы используете один и тот же пароль на нескольких серверах.

• Ограничьте доступ к внешним сервисам: Отредактируейте файлы ``/etc/hosts.allow'' и ``/etc/hosts.deny'' и ограничьте доступ с удаленных систем. В приведенном ниже примере ограничивается доступ к telnet и ftp. Сначала правим файл ``/etc/hosts.allow'':

  # hosts.allow in.telnetd: 123.12.41., 126.27.18., .mydomain.name, .another.name in.ftpd: 123.12.41., 126.27.18., .mydomain.name, .another.name

  Теперь доступ по telnet и ftp разрешен для всех машин в подсетях IP класса C 123.12.41.* и 126.27.18.*, и всех машин внутри доменов mydomain.name и another.name.

  Теперь поправим файл `` /etc/hosts.deny'':

  # hosts.deny in.telnetd: ALL in.ftpd: ALL

• Запретите все лишние сервисы: Подправьте файл ``/etc/inetd.conf '', и запретите (используйте символ комментария ``#'') все сервисы, в которых нет необходимости (если используете ssh, можно закрыть даже сервис ``telnet''). После правки файла наберите от имени root: `` /etc/rc.d/init.d/inet restart'' для перезапуска демона inetd с новыми параметрами сервисов.

• Поставьте систему проверки безопасности: Попробуйте пакет ``Tripwire'' (см. http://www.tripwiresecurity.com) который может обнаруживать попытки атаки, и пакет ``Abacus Sentry'' (см. http://www.psionic.com/abacus), который может помочь в их отражении.

• Будьте внимательны: Время от времени перетрясайте систему на предмет всяких несоответствий (записи в файле паролей, странности в системных журналах, подозрительные процессы в системе, странные настройки программ). Не пренебрегайте сообщениями пользователей о странных явлениях в системе (замечание переводчика: известный мне администратор пренебрег моим предупреждением о том, что в сети университета работает какой-то хакер, за что был быстро и строго наказан тем самым хакером...).

• Устанавливайте и обновляйте системные утилиты, используя ``RPM'', вы можете хотя бы проверить целостность пакета командой:

  rpm --verify -a > /tmp/rpm-audit.txt

  Данная команда проверит базу данных RPM вашей системы и покажет какие файлы изменились. Например:

  S.5....T /bin/ls S.5....T /usr/bin/du ......G. /dev/tty5 .....U.. /dev/vcs5 .....U.. /dev/vcsa5 S.5....T c /etc/lynx.cfg S.5....T c /etc/sendmail.cf

  В данном примере есть список из семи файлов, четыре из которых изменились. Краткая проверка покажет законны ли изменения в файлах /etc/lynx.cfg и /etc/sendmail.cf.

  Однако, заметьте, что изменились два исполняемых файла. С чего бы вдруг? Причем, они очень часто используются: это же команды ``ls'' и ``du''. Вероятней всего, это троянцы. Восстановление их из резервной копии или пакета RPM избавит от троянцев.

  (Подробно ``RPM'' рассмотрен в разделе Использование Red Hat Package Manager (RPM) главы 10.)

По поводу безопасности системы посмотрите хороший ресурс “Securing RedHat 5.x” доступный на http://redhat-security.ens.utulsa.edu. Еще один отличный сайт по Linux crypto и смежному софту находится на http://replay.com/redhat.