Я ни коим образом не являюсь экспертом в области компьютерной безопасности. Но у меня есть маленький совет для сознающих проблему безопасность. Но будьте предупреждены: этот список ни в коем случае не является полным списком проблем относящихся к 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). Заплатка для исправления ошибки
прилагается.
На клиентской стороне мы можем решить, что мы не хотим слишком сильно
доверять серверу. Это делается несколькими способами, используя опции
монтирования. Например, мы можем запретить выполнение программ с
установленным битом suid в файловой системе NFS, это делается опцией
монтирования nosuid. Это хорошая идея и вы должны рассмотреть ее,
используя смонтированные через NFS файловые системы. Это означает, что
администратор сервера не сможет сделать программы с установленным
suid-администратора на файловой системе, затем войти на машину клиента как
обычный пользователь и используя программу с suid-администратора приобрести
также права администратора на машине клиента. Мы также можем запретить
выполнение файлов на смонтированной файловой системе с помощью опции
noexec. Но она применяется реже по сравнению с опцией nosuid,
поскольку файловая система может содержать по крайней мере некоторые
скрипты, или программы, которые необходимо выполнять. Вы можете ввести эти
опции в колонке опций вместе с опциями rsize и wsize, разделяя их
запятыми.
На стотоне сервера мы можем решить, что мы не хотим доверять администратору клиента. Мы можем сделать это указав опцию 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 является установленной по умолчанию для NFSd в Linux,
для передачи администраторских полномочий для доступа к файловой системе
используйте опцию no_root_squash.
Другая важная вещь, которую необходимо сделать, это проверить, что nfsd проверяет, все ли запросы приходят с привелигированного порта. Если он принимает запросы с любого старого порта на клиенте, то пользователь без специальных привелегий может запустить программу, которую легко получить по Internet. Он умеет "говорить" на языке протокола nfs и будет притворяться, что пользователь является любым пользователем, которым он хочет быть. NFSD на Linux делает эту проверку по умолчанию, но для других операционных систем вы должны разрешить эту проверку сами. Это должно быть описано в справочной странице nfsd для вашей операционной системы.
Другая вещь. Никогда не экспортируйте файловую систему для машины с именем 'localhost' или 127.0.0.1. Доверяйте мне.
Основа 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 по
сетям, вернитесь к нему и освежите свои знания, если это необходимо). Для
этого мы напишем в файле hosts.allow
portmap: 129.240.223.0/255.255.255.0
Это тоже самое, что и сетевой адрес, который вы даете командой 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) на машине, которой доверяют и использует эти привелегии для посылки запросов на безопасный порт, как любой пользователь, которым он захочет быть.
Очень хорошая идея защитить порты nfs и portmap с помощью firewall на
вашем маршрутизаторе. Nfsd работает на порту 2049, используя оба
протокола -- udp и tcp. Portmapper работает на порту 111, tcp и udp, а
mountd работает на портах 745 и 747, tcp и udp. По умолчанию. Вы должны
проверить номера используемых портов, используя команду rpcinfo -p.
Если вы хотите использовать NFS сквозь firewall, то есть опции для новых версий NFSd и mountd, для того, чтобы заставить их использовать нестандартные порты, которые могут быть открыты в firewall.
Если вы используете 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.