Я лениво читал http://nfs.sourceforge.net/nfs-howto/ar01s06.html пытаясь понять, почему экспорт localhost был плохим, я добрался до раздела «6.4. Туннелирование NFS через SSH». Все в этом разделе о том, что экспорт localhost является возможной уязвимостью безопасности, поскольку он позволяет другим перенаправлять порт ssh и получать доступ к общему ресурсу, имеет смысл.
Вот мой вопрос, как сохранить ssh-туннели от подрыва безопасности системы, если пользователи могут ssh подключаться к машине, которая может подключаться к серверу NFS? Например, представьте себе компьютеры A (192.168.1.1), B (192.168.1.2) и C (192.168.1.3). Пусть A будет сервером со следующим файлом экспорта:
/home 192.168.1.2(rw)
Как видите, A дает B разрешение на использование общей папки / home. Теперь позвольте C ssh в B с:
$ ssh 192.168.1.2 -L 250:192.168.1.1:2049 -f sleep 60m
$ ssh 192.168.1.2 -L 251:192.168.1.1:32767 -f sleep 60m
Казалось бы, акции A, экспортированные в B, уязвимы для любого, кто может использовать ssh в B. Так ли это? Есть ли способ защититься от этого, кроме как просто убедиться, что любой, кто может войти в B, является очень надежным пользователем?
Проблема, которую вы выделяете, не является недостатком, это особенность! Да, это особенность протокола SSH, и предоставление этой неправильно настроенной службы SSH может использоваться для широкого спектра эксплойтов, таких как:
mysql?]В качестве примера распространенной неправильной конфигурации и проблемы безопасности, установка /sbin/nologin shell для пользователя, не мешает ему создавать туннели ssh с большинством конфигураций по умолчанию для демона OpenSSH!
Согласно вашему вопросу, вам следует избегать NFSv2 / NFSv3 и использовать более безопасный NFSv4, который переходит в другую модель безопасности, где он аутентифицирует отдельных пользователей, а не хост-машины. Или, как альтернатива, запретите SSH-туннелирование для обычных пользователей, правильно настроив службу OpenSSH.
Вы просматриваете очень старый документ, в котором говорится о версии ядра 2.4, вышедшей в 2001 году, за последние 12 лет произошло много изменений. Хотя кое-что осталось прежним.
У меня есть только коробки CentOS 6.x, с которыми по умолчанию используется nfsv4. Чтобы разрешить соединение через промежуточный компьютер, мне пришлось экспортировать файловую систему с insecure устанавливать.
Итак, чтобы ответить на ваш вопрос, используйте nfsv4 и используйте значение по умолчанию secure Режим. Если у вас достаточно прав на B, вы также можете установить
AllowTcpForwarding no
в нем / etc / ssh / sshd_config.
Как всегда в случае с безопасностью, если вы даете людям привилегии, вы должны им доверять.
Этот документ довольно старый (2006 год!). В отсутствие более эффективных механизмов безопасности (например, NFSv4 + GSS) добавление хоста к экспорту означает, что вы неявно доверять этому хосту, его пользователям и процессам.
Перенаправление портов SSH - не единственная ваша проблема, вы можете запретить ее (sshd's AllowTcpForwarding no), но, как sshd_config(5) говорит
Обратите внимание, что отключение пересылки TCP не улучшает безопасность, если пользователям также не запрещен доступ к оболочке, поскольку они всегда могут установить свои собственные серверы пересылки.
Так что добавь в список socat, netcat, SOCKS (OpenSSH тоже поддерживает, но только TCP), OpenSSH tun поддержка туннелей, и даже bash с этими /dev/tcp поддержка, и вы видите проблему ... слишком много, чтобы перечислить.
Если у B есть брандмауэр хоста, который разрешает правила для каждого пользователя (например, Linux / iptables с --uid-owner) вы могли бы заблокировать B, чтобы A мог ему больше доверять. В противном случае попробуйте NFSv4 с GSS и Kerberos, что дает вам доверие для каждого пользователя.
Это легко победить
secureСтраница руководства для exports(5) говорит:
secure
This option requires that requests originate on an internet port
less than IPPORT_RESERVED (1024). This option is on by default.
To turn it off, specify insecure.
Обратите внимание, что по умолчанию это включено.
Любой пользователь, подключающийся с компьютера C к компьютеру B, будет подключаться как обычный пользователь. Соединения NFS, перенаправляемые через SSH, как вы описали, выглядят так, как будто они исходят от процесса, запущенного на B от имени этого пользователя. Это означает, что соединение подлежит обычным мерам безопасности на B, в частности, что обычные пользователи не могут инициировать соединения с портов ниже 1024.
При тестировании на одной из моих систем я вижу следующее:
djs@tuonela:~$ sudo mount -o port=250,mountport=251,tcp localhost:/srv/users /mnt/x -t nfs
mount.nfs: access denied by server while mounting localhost:/srv/users
Конечно, любой, кто может повысить свою учетную запись до root на компьютере B, может обойти эту защиту, поэтому вам необходимо в достаточной степени заблокировать клиентские компьютеры NFS.