VPN 주소에 고정된 NFS 내보내기: 그것이 증명하지 않는 것
내보내기 규칙은 패킷이 어디서 왔는지만 확인합니다. AUTH_SYS는 로컬 UID를 주장하고 Kerberos는 사용자를 인증합니다. 파일 서비스에 어느 쪽이 필요한지 결정하십시오.
호스트가 디렉터리를 VPN 주소로 내보내고, 마운트가 성공하면 설계는 인증된 것으로 기록됩니다. 그 규칙이 실제로 제약하는 것은 패킷이 어디서 오는 것처럼 보이는가입니다. 파일 작업을 이끄는 사람이 정말 자신이 주장하는 사람인지는 NFS 보안 플레이버에 달려 있으며, 이런 내보내기의 대부분에서는 아무도 이를 기본값에서 바꾸지 않았습니다.
하나의 요청에 세 가지 신원이 나타날 수 있습니다
VPN 피어는 클라이언트 인증서나 피어 키 같은 등록된 신원을 지닙니다. 안쪽 IP 패킷은 출발지 주소를 지닙니다. 파일 작업은 해당 NFS 메커니즘이 제공하는 사용자 자격 증명을 지닙니다. 주소를 세 가지 모두의 대리로 취급하는 설계는 검증해야 했던 부분을 조용히 가정해 버린 것입니다.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
그 세 줄을 적는 것이 이 연습의 전부입니다. 내보내기가 안전한지에 대한 논의의 대부분은 각 통제가 어느 줄에 사는지 분명해지면 무너집니다.
주소 소유권은 구현 세부 사항입니다
게이트웨이는 수락된 피어에 터널 주소를 할당하거나 그를 위해 라우팅된 서브넷을 승인할 수 있습니다. 그런 다음 구현이 안쪽 출발지가 다른 클라이언트에 속한 패킷을 거부하는지는 그 구현의 속성이며, 가정하기보다 확인할 가치가 있습니다.
전통적인 Community OpenVPN 사용자 공간 서버 코드는 예를 들어 패킷이 TUN 장치를 통해 전달되기 전에 다른 클라이언트와 연결된 출발지를 거부할 수 있습니다. 이는 실제 가치가 있는 주소 소유권 확인이며, 어떤 계정이 작업을 수행하는지에 대해 아무 말도 하지 않으므로 여전히 NFS 사용자 인증은 아닙니다.
출발지 변환은 그것마저 침식합니다. NAT 게이트웨이는 모든 클라이언트를 하나의 주소로 보여줄 수 있고, 그 시점에 내보내기 규칙은 그 뒤에 있는 사람들을 구별할 수 없습니다. 그러면 규칙의 겉보기 정밀성은 다이어그램이 유지하는 허구가 됩니다. 내보내기가 중요하다면, 누가 누구로 계산되는지를 번역자가 결정하게 두지 말고 주소 지정을 명시적으로 유지하십시오.
내보내기를 신뢰하기 전에 보안 플레이버를 읽으십시오
Red Hat의 NFS 지침은 AUTH_SYS를 통해 로컬 UNIX UID와 GID를 사용하는 sec=sys을 Kerberos 모드와 구분합니다. krb5는 사용자 인증을 추가하고, krb5i은 무결성 보호를 추가하며, krb5p는 트래픽에 대한 개인정보 보호를 추가합니다.
AUTH_SYS 자격 증명에는 호출자의 UID와 그룹 ID 같은 필드가 들어 있으며, RFC 5531은 이 플레이버가 그 자체로는 보안을 제공하지 않고 외부 보호에 의존한다고 분명히 경고합니다. VPN 안에서 실행해도 전송에 대한 보호를 제공할 뿐 패킷 내부의 주장은 아무것도 바꾸지 않습니다.
exportfs -v
showmount -e nfs.example.internal클라이언트 목록을 읽기 전에 그 출력에서 플레이버를 읽으십시오. 제한된 것처럼 보이는 내보내기가 주소로만 제한되어 있는 동안 모든 호출자는 여전히 원하는 UID를 주장하고 있을 수 있습니다.
모델을 고른 다음 권한을 유지하십시오
실제로 관리하는 클라이언트에 맞는 파일 서비스 인증 모델을 고르십시오. Kerberos는 뒤에 신원과 서비스 배포를 필요로 하므로 마운트 옵션 하나를 바꾸는 것은 이전이 아니며 Kerberos 도메인, 주체, keytab이 존재할 때까지 단순히 실패합니다.
두 모델 모두에서 인증된 주체가 무엇을 할 수 있는지 제약하는 내보내기 권한과 파일 시스템 권한 부여를 유지하십시오. 인증은 누가 묻는지 알려주고, 권한 부여는 답이 예여야 하는지를 결정합니다. 이 둘을 하나의 설정으로 합치는 것이 이전이 예전 구성보다 더 많이 부여하게 되는 경로입니다.
주소 규칙을 본래 목적에 사용하십시오
서비스를 승인된 경로와 출발지로 제한하는 것은 여전히 가치가 있으며, VPN 엔드포인트와 NFS 서버가 같은 머신을 공유할 때 호스트 입력 정책도 포함됩니다. 트래픽을 전달하는 규칙은 다음으로 향하는 요청을 관장하지 않습니다: 같은 호스트에서 로컬로 실행되는 서비스. 이 간극은 사적인 것이었어야 할 내보내기의 놀라운 수를 설명합니다. 터널 규칙이 그것을 덮는다고 가정하지 말고 로컬 입력 정책을 명시적으로 확인하십시오.
다른 인터페이스나 출발지 변환을 하는 게이트웨이가 예기치 않게 규칙을 만족할 수 없는지 확인하고, 그것을 주소를 위조하면 작동하는 마운트가 보장된다는 주장이 아니라 출처를 확립할 이유로 다루십시오.
하나가 아니라 세 가지 수용 사례를 실행하십시오. 승인된 클라이언트가 승인된 사용자로 행동하는 경우로 시작하고, 그다음 한 번도 승인되지 않은 피어에서 반복하고, 그다음 승인된 사용자가 아직 허용되지 않은 일을 시도하십시오. 그런 다음 승인된 클라이언트가 침해되면 무엇이 바뀌는지 물으십시오. 전송 인증은 그 머신의 모든 프로세스를 신뢰할 수 있게 만들지 않기 때문에, 도난당한 인증서와 호기심 많은 로컬 계정은 서로 다른 통제가 필요한 서로 다른 문제입니다.