Я праздно читал 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, является очень надежным пользователем?

answer

Вы просматриваете очень старый документ, в котором говорится о версии ядра 2.4, вышедшей в 2001 году, за последние 12 лет произошло много изменений. Хотя кое-что осталось прежним.

У меня есть только коробки CentOS 6.x, с которыми по умолчанию используется nfsv4. Чтобы разрешить соединение через промежуточный компьютер, мне пришлось экспортировать файловую систему с помощью insecureset.

Поэтому, чтобы ответить на ваш вопрос, используйте nfsv4 и secureрежим по умолчанию . Если у вас достаточно прав на B, вы также можете установить

AllowTcpForwarding no

в нем / etc / ssh / sshd_config.

Как всегда в случае с безопасностью, если вы даете людям привилегии, вы должны им доверять.

Проблема, которую вы выделяете, не является недостатком, это особенность! Да, это особенность протокола SSH, и предоставление этой неправильно настроенной службы SSH может использоваться для широкого спектра эксплойтов, таких как:

  • Обход межсетевых экранов хоста
  • Обход ограничений IP
  • Службы удаленного доступа, которые прослушивают только интерфейсы localhost [ mysql?]

В качестве примера распространенной неправильной конфигурации и проблемы безопасности, установка /sbin/nologinоболочки для пользователя не мешает ей создавать туннели ssh с большинством конфигураций по умолчанию для демона OpenSSH!

В соответствии с вашим вопросом вам следует избегать NFSv2 / NFSv3 и использовать более безопасный NFSv4, который переходит в другую модель безопасности, где он аутентифицирует отдельных пользователей, а не хост-машины. Или, как альтернатива, запретите SSH-туннелирование для обычных пользователей, правильно настроив службу OpenSSH.

Этот документ довольно старый (2006 год!). В отсутствие более совершенных механизмов безопасности (например, NFSv4 + GSS) добавление хоста к экспорту означает, что вы безоговорочно доверяете этому хосту, его пользователям и процессам.

Перенаправление портов SSH - не единственная ваша проблема, вы можете запретить ее (sshd's AllowTcpForwarding no), но, как sshd_config(5)говорится

Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.

Так что добавьте в список socat, netcatSOCKS (OpenSSH поддерживает это тоже, но только TCP), tunподдержку туннелирования OpenSSH и даже bashс его /dev/tcpподдержкой, и вы увидите проблему ... слишком много, чтобы перечислить.

Если у B есть брандмауэр хоста, который разрешает правила для каждого пользователя (например, Linux / iptables с --uid-owner), вы можете заблокировать B, чтобы A мог ему больше доверять. В противном случае попробуйте NFSv4 с GSS и Kerberos, что дает вам доверие для каждого пользователя.

Это легко победить

  1. убедитесь, что ваш экспорт отмечен secure
  2. запрещение корневого доступа к компьютеру B с компьютера C

На странице руководства 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.

При тестировании на одной из моих систем я вижу следующее:

[email protected]:~$ 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.