Безопасный способ ограничить зарегистрированных пользователей FTP единственным каталогом

Другой возможный, если общий ответ (который может быть неправильным/невозможным, я действительно надеюсь на обратную связь):

Создайте отдельный раздел для действия как корень для пользователей FTP. Имейте только соответствующие каталоги в этом корневом разделе. Используйте ACL для удаления, выполняют полномочия для всех пользователей FTP для всех каталогов на других разделах. Установите FTP-сервер на регулярном разделе, так, чтобы раздел пользователя FTP не был загроможден с программными файлами.

Таким образом, пользователи FTP будут только видеть корень нового раздела, который я могу структурировать так изящно, как я выбираю.

Этот вопрос на всем протяжении Интернета без ясного решения, которое я нашел.

Таким образом, вот то, где я стою на этом теперь (я обновлю, как я узнаю больше).

Кажется, что фундаментальная проблема состоит в том, что FTP имеет пользователей, входящих в систему и управляющих файловой системой, в противоположность http клиенту, просто отправляющему запросы к http сервисному процессу.

Так, очень трудно ограничить пользователя FTP от выполнения вещей, которые его пользователь имеет права сделать в системе, был он для входа в систему регулярно. Пользователи FTP должны иметь, выполняют права для каталогов вне того, где мы хотим ограничить его доступ представления так, чтобы он мог записать или читать из своего более низкого ответвления уровня. Таким образом, единственный простой способ ограничить его доступ представления состоит в том, чтобы посадить его в chroot тюрьму.

Тюрьма Chroot не безопасна, потому что она только "изменяет поиски пути для процесса и его детей так, чтобы любая ссылка на запуск пути '/' эффективно имела новый корень, который передается как отдельный аргумент, предварительно ожидаемый на путь", но "текущий рабочий каталог оставлен без изменений, и относительные пути могут все еще относиться к файлам за пределами нового корня". источник http://lwn.net/Articles/252794/

Что это означает в контексте защиты и как опасный, который действительно является относительно прав демона и пользователя FTP, которые я не могу сказать, но это действительно означает, что 'тюрьма' в 'chroot тюрьма' является неправильным употреблением.

Кажется, что с глубоким дескриптором на Linux, это возможно путем определения процесса и пользовательских прав... для 'использования' chroot в этом контексте защиты, но ни я, ни бесчисленные интернет-жители, борющиеся с этим еще, не 'там'.

Также возможно укрепить chroot тюрьму туда, где это действительно ведет себя как тюрьма - Чтобы заключить разработчику ядра Alan Cox в кавычки, "chroot не и никогда не был средствами обеспечения безопасности. Люди создали вещи, основанные на свойствах chroot, но расширились (тюрьмы BSD, Linux vserver), но они очень отличаются. Вы могли, вероятно, записать себе модуль LSM, чтобы сделать это также". Я еще не 'там', но я действительно подозреваю, что это в конце - решение, и я также рисковал бы этим, FTP-сайты распределения обрабатывают безопасность вдоль этих или подобных строк.

В сущности все, что я могу сделать теперь, является использованием chroot тюрьма, полагаясь, который мой сервер является низкоприоритетной целью, если один вообще, и что мои пользователи в основном защищены. Моя стратегия безопасности должна будет ограничить ущерб, который можно нанести, если они действительно убегают из тюрьмы. Который влечет за собой пользователей конфигурирования соответственно, возможно виртуальных пользователей и возможно выполнение целого сервиса в виртуальной машине.

В то время как я прогрессирую в своих исследованиях, я надеюсь укрепить chroot () понятие через LSM и т.п. для безопасности, и я действительно отмечаю, что согласно кавычке Alan Cox выше BSD уже имеет понятие 'тюрем', таким образом, я был бы, мог бы изучить BSD для моих потребностей FTP.

Вот то, как я создал заключенный в тюрьму sftpuser для клиентов в sftp файлы к моему серверу:

1. Создайте sftpgroup

   # groupadd sftpusers
   

2. Создайте sftpuser:

   # useradd -g sftpusers -d /incoming/client1 -s /sbin/nologin \
         client1srs passwd client1srs
   

3. Измените пользователя и сделайте пользователя sftp onluy и вставьте sftp тюрьму

   # usermod -g sftpusers -d /incoming -s /sbin/nologin client1srs
   

4. Подсистема sftp-сервера установки в sshd_config

   Измените/etc/ssh/sshd_config и прокомментируйте:

   # #Subsystem       sftp    /usr/libexec/openssh/sftp-server
   

5. Затем добавьте следующее:

   Subsystem       sftp    internal-sftp
   

6. Укажите каталог Chroot для группы

   Добавьте следующие строки в конце/etc/ssh/sshd_config:

   Match Group sftpusers
          ChrootDirectory /sftp/%u
          ForceCommand internal-sftp
   

7. Создайте корневой каталог SFTP

   # mkdir /sftpdir/client1srs/incoming
   # chown client1srs:sftpusers /sftpdir/client1srs/incoming
   

8. Перезапуск sshd

   # /sbin/service sshd restart
   

Краткий ответ: используйте обязательный- или ролевой- контроль доступа. См. Обновление 2 ниже.

Да, ftp по своей сути небезопасен. sftp и scp устраняют часть этой небезопасности, но не проблему сокрытия частей файловой системы, которая беспокоит вас. Может быть, вам нужен том NFS?

Согласно vsftpd faq проблема с chroot заключается в том, что он дает пользователю контроль чтения / записи над тем, что становится корневой файловой системой.

vsftpd предоставляет настройки hide_file и deny_file , которые можно использовать, чтобы скрыть файлы и сделать их недоступными соответственно с использованием сопоставления с образцом. Как указано в документации, эти параметры «очень просты и не должны использоваться для серьезного контроля доступа - предпочтительнее использовать разрешения файловой системы»

. В зависимости от того, что вашим пользователям нужно делать по ftp, вы также можете быть может повысить безопасность вашего сайта, ограничив активность пользователей ftp с помощью vsftpd cmds_allowed или cmds_denied .

Вы можете запустить демон ftp внутри контейнера docker с каталогом данных с хоста, смонтированного в контейнере. Пользователь будет видеть весь контейнер, но ничего больше с хоста. Можно было бы использовать xinetd для создания dockerized vsftpd процесса для каждого клиентского соединения. Тогда все в контейнере, кроме смонтированного тома данных, будет полностью эфемерным и исчезнет, ​​как только соединение будет закрыто.

Обновление: FTP использует отдельное соединение для передачи данных . Чтобы запустить FTP-сервер внутри докера, нужно убедиться, что он все еще может согласовывать и устанавливать соединение для передачи данных. Это можно сделать, запустив контейнер с параметром --net = host или, возможно, с дополнительной конфигурацией сети как внутри, так и вне контейнера. Чтобы порождать docker ftp-контейнеры по требованию с помощью xinetd, как я предлагал выше, такую ​​конфигурацию необходимо выполнять на лету для каждого контейнера.

Обновление 2: Docker не является гарантией безопасности. Обнаружены эксплойты , и безопасность не является основной целью проекта. Вероятно, лучше всего будет использовать контейнер для запуска ftpd от имени непривилегированного пользователя.

Реальное решение - дополнить механизм контроля доступа на вашем сервере с помощью AppArmor , SELinux или GrSecurity . Я считаю, что любое из них должно быть достаточным решением без контейнеров, chroot-файлов или тюрем.

Примечание. Это решение хорошо работает для меня и легко настроить. Предполагая, что вы используете VSFTPD.

Я заключил в тюрьму всех пользователей своим домашним каталогам и поделился папкой, называемой «разделяемым» между всеми из них.

1. Пользователи тюремного заключения в свой дом напрямую

    $ sudo vi /etc/vsftppd/vsftpd.conf
    

   Убедитесь, что это следующая конфигурация:

    Anonymous_Enable = NO
   local_eanable = Да
   chroot_local_user = да
    

   Перезапуск VSFTPD:

    $ Sudo Service VSFTPD Перезагрузка
    

2. Создайте общую папку для всех пользователей и дать разрешения FTP

    $ CD / VAR / FTP
    $ MKDIR Shared
    $ Chmod 777 Shared /
    $ Chgrp FTP Shared /
    $ Chown FTP Shared /
    

3. Разрешить пользователям пользователям иметь доступ к этой общей папке

   , давайте возьмем пример jailed User Sam:

   , предполагая, что вы в данный момент Root.

    $ SU - Сэм
    $ CD / Home / Sam
    $ MKDIR Shared
    $ выйти
    

   Теперь вы вернулись в root.

    $ mount -o bind / var / ftp / shared / home / sam / shared
    

   Добавить SAM к FTP-группе

    $ usermod -a -g ftp sam
    

   Повторите процесс, чтобы добавить другие пользователи в папку «Общая».

Теперь SAM будет иметь доступ к своей собственной домашней папке и будет иметь дополнительную «общую» папку, к которой могут быть предоставлены все остальные пользователи.