Библиотека сайта rus-linux.net
6. Безопасность и NFS
Я ни коим образом не являюсь экспертом в области компьютерной безопасности. Но у меня есть маленький совет для сознающих безопасность. Но будьте предупреждены: это ни в коем случае не полный список относящихся к NFS проблем, и если вы думаете, что вы обезопасились один раз прочитав и выполнив, все что я даю здесь, то я хочу предать вас.
Этот раздел не должен беспокоить вас если вы находитесь в закрытой сети, где вы доверяете всем пользователям, и никто кому вы не доверяете ни может получить доступ к машинам в сети. Например не должно быть dial-соединения в сеть, и не должно быть никакого способа подключиться к сети, в которой вы не доверяете всем. Вы думаете я параноик? Я не параноик во всех областях. Это базовый совет по безопасности. Безопасный требует наличия тщательного и знающего администратора, который знает где найти информацию о текущих и потенциальных проблемах безопасности.
NFS имеет основную проблему в том, что клиент, если не задано будет доверять серверу и наоборот. Это может быть плохо. Это значит, что если запись администратора сервера NFS взломана, то также легко может быть взломана запись администратора клиентской машины. И наоборот. Существует набор полицейских стратегий для этого, к которым мы вернемся.
Что вам необходимо читать -- это консультационные материалы CERT относящиеся к NFS, большинство текстов приведенных ниже связаны с советами, написанными в выпусках CERT. Смотрите ftp.cert.org/01-README для обновленного списка консультаций CERT. Здесь приведены некоторые относящиеся к NFS консультации:
CA-91:21.SunOS.NFS.Jumbo.and.fsirand 12/06/91
Уязвимость в отношении сетевой файловой системы (NFS) Sun
Microsystems, Inc. (Sun) и программы fsirand. Эта уязвимость
возможна в версиях SunOS 4.1.1, 4.1, and 4.0.3 на всех
архитектурах. Заплатки (Patches) доступны для SunOS
4.1.1. Также доступна начальная заплатка для SunOS 4.1 NFS. Sun
будет обеспечит полные заплатки для SunOS 4.1 и SunOS 4.0.3 позже.
CA-94:15.NFS.Vulnerabilities 12/19/94
Этот консультационный материал обеспечивает измерение
безопасности для охраны против против некоторых дыр в безопасности
в сетевой файловой системе (NFS). Этот материал выпущен в связи с
увеличением случаев взлома машин используя утилиты для
использования уязвимых точек.
CA-96.08.pcnfsd 04/18/96
Этот материал описывает проблемы с безопасностью в программе pcnfsd
(также известной как rpc.pcnfsd). Заплатка для исправления ошибки
прилагается.
6.1 Безопасность клиента
На клиентской стороне мы можем решить, мы не хотим слишком сильно
доверять серверу, это делается несколькими способами с помощью опций
монтирования. Например, мы можем запретить выполнение программ с
установленным битом suid в файловой системе NFS, это делается опцией
монтирования nosuid. Это хорошая идея и вы должны рассмотреть ее,
используя смонтированные по NFS. Это означает что администратор
сервера не сможет сделать программы с установленным
suid-администратора на файловой системе, затем войти на машину клиента
как обычный пользователь и затем используя программу с
suid-администратора стать приобрести также права администратора на
машине клиента. Мы также можем запретить выполнение файлов на
смонтированной файловой системе с помощью опции noexec. Но менее
распространено по сравнению с опцией nosuid, поскольку файловая
система вероятно содержит по крайней мере некоторые скрипты, или
программы, которые необходимо выполнить. Вы можете ввести эти опции в
колонке опций вместе с опциями rsize и wsize, разделенными
запятыми.
6.2 Безопасность сервера: nfsd
на сервере мы можем решить, что мы не хотим доверять администратору клиента. Мы можем сделать это используя опцию root_squash в файле exports:
/mn/eris/local apollon(rw,root_squash)
Теперь, если пользователь с UID 0 на клиенте попытается получить
доступ (чтение, запись, удаление), то файловый сервер выполнит
подстановку UID пользователя `nobody' на сервере. Это означает, что
администратор клиента не сможет получить доступ или изменять файлы,
которые может изменять или иметь доступ только администратор
сервера. Это хорошо и вы должны вероятно использовать опцию
root_squash на всех экспортируемых файловых системах. Вы скажете,
что "Администратор клиента все равно может выполняить команду 'su',
чтобы зайти как любой другой пользователь и получить доступ и изменить
любые пользовательские файлы". На это есть ответ: "Да есть такой
способ, и это работает в Unix и NFS. Это имеет одно важное заключение:
Все важные файлы и программы должны иметь владельцем пользователя
root, а не пользователя bin или другого пользователя
не-администратора, поскольку только администратор клиента не может
получить дочтуп как администратор сервера. С справочной странице NFSd
есть несколько других подобных опций, так что вы можете решить, что вы
(не) доверяете кому-либо со стороны клиента. У вас также имеются опции
для осечения любых диапазонов UID и GID которые вы хотите. Это
описывается в справочной странице Linux NFSd.
root_squash является установленным по умолчанию для Linux NFSd, для
передачи администраторских полномочий для доступа к файловой системе
используйте опцию no_root_squash.
Другая важная вещь, которую необходимо сделать, это проверить, что nfsd проверяет, что все запросы приходят с привелигированного порта. Если он принимает запросы с любого старого порта на клиенте, то пользователь без специальных привелегий может запустить программу, которую легко получить по Internet. Он умеет "говорить" на языке протокола nfs и будет притворяться, что пользователь является любым пользователем, которым он хочет быть. NFSD на Linux делает эту проверку по умолчанию, но для других операционных систем вы должны разрешить эту проверку сами. Это должно быть описано в справочной странице nfsd для вашей операционной системы.
Другая вещь. Никогда не экспортируйте файловую систему для хоста 'localhost' или 127.0.0.1. Доверяйте мне.
6.3 Безопасность сервера: portmapper
Основа portmapper, в соединении с nfsd имеют проблему проектирования, которая делает возможной получить файлы с серверов NFS без каких-либо привелегий. К счастью portmapper под Linux использует относительную безопасность против такой атаки, и может быть сделано более безопасной настройкой списка доступа в двух файлах.
Сначала мы отредактируем файл /etc/hosts.deny. Он должен
содержать строку
portmap: ALL
которая запретит доступ всем. Это может быть слишком решительным, так
что мы снова откроем доступ отредактировав файл
/etc/hosts.allow. Но сначала нам надо определить, что мы туда
поместим. Он должен перечислять все машины, которые должны иметь доступ к
вашему portmapper. Среди множества работающих под Linux систем только
некоторым машинам нужен любой доступ для любой работы. Portmapper
обслуживает nfsd, mountd, ypbind/ypserv, pcnfsd, и 'r' сервисы, такие как
ruptime и rusers. Из них только nfsd, mountd, ypbind/ypserv и возможно
pcnfsd имеют какое-либо значение. Всем машинам, которым необходим доступ к
сервисам на вашей машине должно быть разрешено делать это. Скажем адрес
машины равен 129.240.223.254 и что она находится в подсети 129.240.223.0,
и она должна иметь доступ к сервисам на вашей машине (эти термины введены
HOWTO по сетям, вернитесь к нему и освежите свои знания, если это
необходимо). Затем мы напишем
portmap: 129.240.223.0/255.255.255.0
в hosts.allow. Это тоже самое, что и сетевой адрес, который вы даете
командой route и маска подсети, которую вы даете ifconfig. Для устройства
eth0 на этой машине ifconfig должен показывать
...
eth0 Link encap:10Mbps Ethernet HWaddr 00:60:8C:96:D5:56
inet addr:129.240.223.254 Bcast:129.240.223.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:360315 errors:0 dropped:0 overruns:0
TX packets:179274 errors:0 dropped:0 overruns:0
Interrupt:10 Base address:0x320
...
и netstat -rn должен показывать
Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface ... 129.240.223.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0 ...
(Сетевой адрес находится в первой колонке).
Файлы hosts.deny и hosts.allow описаны в справочных страницах с
теми же именами.
ВАЖНО: Не помещайте ничего кроме IP НОМЕРОВ в строках portmap в этих файлах. Поиск имен машин может вызвать активность portmap, которая вызовет поиск имен машин, которое вызовет portmap, которое вызовет...
Вышеприведенные вещи должны вызвать переключение вашего сервера. Остающаяся проблема в том, что кто-то взломает бюджет администратора (или загрузит MS-DOS) на машине, которой доверяют и использует эти привелегии для посылки запросов на безопасный порт, как любой пользователь, которым он захочет быть.
6.4 NFS и firewall
Очень хорошая идея защитить порты nfs и portmap с помощью firewall на
вашем маршрутизаторе или firewall. Nfsd работает на порту 2049, на обоих
протоколах udp и tcp. Portmapper работает на порту 111, tcp и udp, и mountd
работает на портах 745 и 747, tcp и udp. Обычно. Вы должны проверить номера
портов, используя команду rpcinfo -p.
Если вы хотите использовать NFS сквозь firewall, то есть опции для новых версий NFSd и mountd, для того, чтобы заставить их использовать специфические (нестандартные) порты, которые могут быть открыты в firewall.
6.5 Резюме
Если вы используете hosts.allow/deny, root_squash, nosuid и
привилегированные порты в программном обеспечении portmapper/nfs, то вы можете
избежать известных ошибок в nfs и можете чувствовать себя почти в
безопасности. Но все равно: Когда взломщик имеет доступ к вашей сети, то
он/она может добавить странные команды в ваш файл .forward или
почтовый ящик, когда /home или /var/spool/mail
смонтирован через NFS. По той же причине, вы никогда не должны осуществлять
доступ к вашим личным ключам PGP через nfs. Или по крайней мере вы должны
знать какой риск существует. И знать о нем хотя бы немного.
NFS и portmapper создают комплексную систему и поэтому не полностью невероятно,что новые ошибки будут найдены, либо в основе проекта, либо в реализации, которую мы используем. Также могут быть известные дыры, которые кто-нибудь использует. Но такова жизнь. Чтобы быть в курсе таких вещей, вы должны как минимум читать группы новостей comp.os.linux.announce и comp.security.announce, как абсолютный минимум.
Next Previous Contents