☰

FTP 로그인 사용자를 단일 디렉토리로 제한하는 안전한 방법

tag-icon • tag-icon ftp file-sharing vsftpd
FTP 로그인 사용자를 단일 디렉토리로 제한하는 안전한 방법

단일 FTP 루트 디렉터리에 여러 사용자 FTP 로그인을 제공해야 합니다. 일부는 쓰기가 가능하고 일부는 읽기만 가능합니다. 나는 그들이 파일 시스템의 해당 디렉토리 위에 아무 것도 보지 않기를 바랍니다. 검색 후(일반적인 문제인 것 같습니다) user_local 구성 옵션을 루트 디렉터리로 정의하고 chroot_local_users 옵션이나 chroot Jail을 사용하여 사용자를 해당 디렉터리로 제한했습니다. 이것은 기본적으로 작동합니다.

내 문제는 이유는 모르겠지만 보안을 위해 chroot 감옥에 의존하는 것이 일반적으로 눈살을 찌푸리게 한다는 것입니다. 가장 중요한 것은 커널 개발 팀(적어도 한 명)에 의해 눈살을 찌푸리는 것입니다.

그렇다면 로그인한 사용자가 chroot Jail 없이 정의된 루트 디렉토리 위의 항목을 볼 수 없도록 제한하려면 어떻게 해야 합니까? (제목에 언급된 질문의 "보안" 부분입니다)

또한 보안상의 이유로(아직 이해하지 못함) 최신 버전에서는 vsftpd사용자의 루트에 쓰기가 허용되지 않으므로 두 가지 옵션이 남습니다. 1. 보안 기능을 비활성화하고 루트에 쓰기 가능한 상태로 두거나 2. root 쓰기 비트를 제거하고 그 안에 쓰기 가능한 하위 디렉터리를 만듭니다. 전자는 불장난이고, 후자는 보기 흉하고 오류가 발생하기 쉽습니다(사용자가 루트 디렉터리에 쓰려고 하면 오류가 발생합니다...). 저는 후자를 선택했습니다.

그렇다면 FTP 서비스를 제공하는 올바른 방법은 무엇일까요? 이는 사용자가 파일 시스템의 관련 없는 부분을 안전한 방법으로 보지 못하게 하는 방법을 의미합니까? FTP는 파일을 배포하는 본질적으로 안전하지 않은 방법입니까? 그렇다면 더 좋은 방법이 있습니까? 이것을 바로잡으려고 노력 중입니다...

답변1

참고: 이 솔루션은 나에게 효과적이었고 설정도 쉬웠습니다. vsFTPd를 사용한다고 가정합니다.

나는 모든 사용자를 홈 디렉토리에 가두고 그들 사이에 "Shared"라는 폴더를 공유했습니다.

  1. 사용자를 집으로 직접 보내기

    $ sudo vi /etc/vsftpd/vsftpd.conf

    이것이 다음 구성인지 확인하십시오.

    anonymous_enable=NO
local_enable=YES
chroot_local_user=YES

    vsftpd를 다시 시작하세요:

    $ sudo service vsftpd restart

  2. 모든 사용자를 위한 공유 폴더를 만들고 "ftp" 권한을 부여하세요.

    $ cd /var/ftp
$ mkdir shared
$ chmod 777 shared/
$ chgrp ftp shared/
$ chown ftp shared/

  3. 투옥된 사용자가 이 공유 폴더에 액세스하도록 허용

    감옥에 갇힌 사용자 Sam을 예로 들어보겠습니다.

    이제 당신이 루트라고 가정합니다.

    $ su - sam
$ cd /home/sam
$ mkdir Shared
$ exit

    이제 루트로 돌아왔습니다.

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

    FTP 그룹에 샘 추가

    $ usermod -a -G ftp sam

    공유 폴더에 다른 사용자를 추가하려면 이 과정을 반복하세요.

이제 Sam은 자신의 홈 폴더에 액세스할 수 있으며 다른 모든 사용자가 액세스할 수 있는 추가 "공유" 폴더를 갖게 됩니다.

답변2

이 문제는 인터넷에 떠도는 문제인데 명확한 해결책을 찾지 못했습니다.

그것이 제가 지금 서 있는 곳입니다(자세한 내용은 업데이트하겠습니다).

근본적인 문제는 http 클라이언트가 단순히 http 서비스 프로세스에 요청을 보내는 것이 아니라 FTP에서 사용자가 로그인하여 파일 시스템을 조작하게 한다는 것입니다.

따라서 정기적으로 로그인하는 경우 FTP 사용자가 시스템에서 사용자에게 권한이 부여된 작업을 수행하는 것을 제한하기가 어렵습니다. FTP 사용자는 하위 수준 분기에서 쓰거나 읽을 수 있도록 보기 액세스를 제한하려는 디렉터리에 대한 실행 권한이 있어야 합니다. 따라서 그의 시청 권한을 제한하는 유일한 간단한 방법은 그를 chroot 감옥에 가두는 것입니다.

Chroot Jail은 단순히 "'/'로 시작하는 경로에 대한 모든 참조가 단일 인수로 전달되고 path"이지만 "현재 작업 디렉터리는 변경되지 않고 그대로 유지되며 상대 경로는 여전히 새 루트 디렉터리 외부의 파일을 참조할 수 있습니다." 소스입니다.http://lwn.net/Articles/252794/

보안 측면에서 이것이 무엇을 의미하는지, FTP 데몬 및 사용자 권한과 관련하여 얼마나 위험한지는 말할 수 없지만 "chroot Jail"의 "Jail"이 잘못된 이름이라는 의미입니다.

Linux에 대한 깊은 이해가 있으면 프로세스 및 사용자 권한을 정의하여 이 보안 컨텍스트에서 chroot를 "사용"할 수 있는 것 같습니다. 그러나 이 문제로 어려움을 겪고 있는 저나 수많은 인터넷 사용자 모두 아직 "달성"하지 못했습니다.

실제로 감옥처럼 작동할 정도로 chroot 감옥을 강화하는 것도 가능합니다. 커널 개발자 Alan Cox의 말을 따르면 "chroot는 보안 도구가 아니며 보안 도구였던 적도 없습니다. 사람들은 chroot의 속성을 기반으로 무언가를 구축했습니다. 하지만 확장(BSD 감옥), Linux 가상 서버)에서는 매우 다릅니다. 이 작업을 수행하기 위해 LSM 모듈을 직접 작성할 수도 있습니다. "아직 "도착"하지 않았지만 이것이 "솔루션"이라고 생각됩니다. " 결국에는 그렇습니다. 배포 FTP 사이트가 이러한 또는 유사한 방식으로 보안을 처리할 것이라는 우려도 있습니다.

현실적으로 지금 할 수 있는 일은 chroot Jail을 사용하는 것뿐입니다. 왜냐하면 내 서버는 우선 순위가 낮은 대상(있는 경우)이고 내 사용자는 기본적으로 신뢰할 수 있기 때문입니다. 내 보안 정책은 사람들이 할 수 있는 피해를 제한하는 것입니다.감옥 휴식. 이를 위해서는 사용자를 가상 사용자로 적절하게 구성하거나 가상 머신에서 전체 서비스를 실행해야 합니다.

학습이 진행됨에 따라 LSM 등을 통해 보안을 위해 chroot() 개념을 시행하기를 희망하며 위의 Alan Cox의 인용문을 기반으로 BSD에 이미 "감옥" 개념이 있다는 점을 언급했기 때문에 아마도 다음을 위해 BSD 사용을 고려할 것입니다. 내 FTP가 필요합니다.

답변3

클라이언트가 sftp를 통해 내 서버에 파일을 보낼 수 있도록 감옥에 갇힌 sftpuser를 만드는 방법은 다음과 같습니다.

  1. SFTP 그룹 생성

    # groupadd sftpusers

  2. SFTP 사용자를 생성합니다:

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

  3. 사용자를 수정하고 사용자를 SFTP 전용으로 만들고 SFTP 감옥에 넣습니다.

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

  4. sshd_config에서 sftp-server 하위 시스템 설정

    /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. SSH를 다시 ​​시작

    # /sbin/service sshd restart

답변4

짧은 대답: 사용필수적인 -또는역할 기반-액세스 제어. 아래 업데이트 2를 참조하세요.

예, FTP는 본질적으로 안전하지 않습니다. sftp와 scp는 일부 불안전한 문제를 해결하지만 파일 시스템의 일부를 숨기는 문제는 해결하지 못합니다. NFS 볼륨이 필요한가요?

~에 따르면vsftpd FAQ, chroot의 문제점은 사용자에게 루트 파일 시스템에 대한 읽기/쓰기 제어권을 제공한다는 것입니다.

vsftpd는 각각 패턴 일치를 사용하여 파일을 숨기고 액세스할 수 없게 만드는 데 사용할 수 있는 설정을 hide_file제공 합니다. deny_file문서에 명시되어 있듯이 이러한 옵션은 "매우 간단하므로 엄격한 액세스 제어에 사용해서는 안 됩니다. 파일 시스템 권한이 우선되어야 합니다."

사용자가 FTP를 통해 수행해야 하는 작업에 따라 vsftpd cmds_allowed또는 cmds_denied.

FTP 데몬을 실행할 수 있습니다~에ㅏ도커컨테이너, 컨테이너에 설치된 호스트 머신의 데이터 디렉터리에서. 사용자는 전체 컨테이너를 볼 수 있지만 호스트에는 다른 어떤 것도 볼 수 없습니다. 아마도 xinetd를 사용하여 생성할 수 있을 것입니다.도킹된각 클라이언트 연결에 대한 vsftpd 프로세스입니다. 그러면 탑재된 데이터 볼륨을 제외한 컨테이너의 모든 내용은 완전히 임시적이며 연결이 닫히면 사라집니다.

고쳐 쓰다:FTP 사용별도의 데이터 연결옮기다. Docker 내에서 FTP 서버를 실행하려면 해당 서버가 여전히 데이터 연결을 협상하고 설정할 수 있는지 확인해야 합니다. 이는 다음을 통해 수행할 수 있습니다.컨테이너 실행--net=host를 사용하거나 컨테이너 내부와 외부 모두에서 추가 네트워크 구성을 사용할 수 있습니다. 위에서 제안한 대로 xinetd를 사용하여 요청 시 docker ftp 컨테이너를 생성하려면 이러한 구성을 각 컨테이너에 대해 즉시 수행해야 합니다.

업데이트 2:Docker는 보안을 보장하지 않습니다. 취약점이 발견되었습니다, 보안은 프로젝트의 주요 목표가 아닙니다. 권한이 없는 사용자로 ftpd를 실행하려면 컨테이너를 사용하는 것이 더 좋습니다.

실제 솔루션은 서버의 액세스 제어 메커니즘을 보완하는 것입니다.갑옷을 적용,SELinux, 또는안전. 나는 이들 중 어떤 것이든 컨테이너, chroot 또는 감옥 없이도 충분한 솔루션이 될 것이라고 믿습니다.

관련 정보