Linux может считаться более безопасной, чем другие версии UNIX. Дело в
том, что по мере роста популярности Linux она становится все более интересной
для хакеров, что приводит к выявлению дырок в защите и их ликвидации.
Открытость системы также весьма способствует процессу устранения ошибок.
Я не специалист по защите системы, но я имел дело с большинством проблем с
ней и я дам советы по обходу наиболее распространенных проблем. Хотя
обновление регулярное обновление системы не дает гарантию, что защиту не
обойдут, все же шансы хакеров сильно уменьшатся.
Хотя есть немало способов ворваться в систему (например, IMAP daemon
exploit), основная угроза исходит все же изнутри.
Связей с внешним миром не так и много, а вот в системе есть
множество команд и утилит, в которых могут быть
ошибки, которые могут использоваться хакером.
По этой причине я избегаю открывать пользователям доступ к оболочке, если
он не абсолютно необходим. Даже если Вы рассматриваете ваших пользователей
как полностью заслуживающих доверия, для взлома системы требуется только,
чтобы один из этих пользователей имел слабый пароль. Получив в систему хакер
непременно будет искать в ней еще дырки (замечание переводчика: точно, я сам
так делаю).
Однако, можно успешно противостоять таким атакам. Детальное рассмотрение
проблем защиты выходит за рамки данного руководства, так что здесь
перечислено только то, что необходимо делать для уменьшения риска:
Обновляйте системные утилиты, программы и ядро:
При обновлении Вы будете уверены, что в системе нет старых программ, дырки в
которых широко известны (замечание переводчика: в свое время был сервер в
нашем университете, на котором стояла система, минимум трехлетней давности.
Я делал с этим сервером много интересных вещей, а еще больше мог бы сделать,
если бы хотел. Потом систему обновили, и 90% моих люков закрылись.).
Подробности по поводу обновления системы см. в разделе
Скачивание и установка обновлений для Red Hat главы 4 и
в разделе Стратегии обновления и поддержки системы
главы 10.
Умное управление паролями:
Следите, чтобы пароли менялись регулярно и были надежными. Если используется
несколькосерверов, не ставьте одинаковые пароли. Иначе хакеру понадобится
вычислить пароль только один раз (замечание переводчика: если пользуетесь
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. Новые версии постоянно
выходят, так что следите за ними! Вам нужны следующие файлы:
Замечание: RPM-файлы для SSH, перечисленные выше, международные версии.
Если Вы проживаете в США или Канаде, Вы можете загрузить американские пакеты
(которые могут иметь более сильные алгоритмы шифрования); эти пакеты имеют
суффикс ``us'' вместо ``i'' после номера версии. Согласно американскому
закону, запрещено экспортировать сильные
crypto-программы вне США или Канады. Когда-нибудь Министерство юстиции США
увидит, к чему привела такая ситуация и удалит это глупое ограничение.
(Red Hat не включает SSH из-за этого, и все мы
страдаем). Замечание переводчика: на сегодняшний день ограничения на экспорт
криптосистем из США уже сняты.
Есть клиенты ssh и под Windows, что дает пользователям данной системы
возможность соединиться по защищенному протоколу с сервером. Клиенты:
Замечание: Если вы перешли на использование 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.
Теперь поправим файл ``
/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 избавит от троянцев.