Стратегия безопасности сервера
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'':
Теперь доступ по telnet и ftp разрешен для всех машин в подсетях IP класса C 123.12.41.* и 126.27.18.*, и всех машин внутри доменов mydomain.name и another.name.# 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
Теперь поправим файл ``
/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 |
|
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.
| Назад |
Оглавление | Вперед |
| Server Migration and Scalability Issues | Help! Trouble in Paradise! |
