로그인 검사 두 개는 두 가지 요소가 아닙니다: VPN과 RADIUS

VPN 게이트웨이에 두 번째 인증 백엔드를 추가하는 것은 두 번째 요소를 추가하는 것처럼 느껴집니다. 보통은 두 번째 검사를 추가하는데, 이는 실패 방식이 다른 별개의 대상입니다. 둘 다 성공해야 하는지, 각각 무엇을 증명하는지, 하나를 사용할 수 없을 때 무슨 일이 일어나는지는 세 가지 별개의 결정입니다. 이를 잘못하면 게이트웨이는 시연에서는 더 엄격하고 장애 시에는 더 약해집니다.

두 번째 백엔드가 실제로 증명하는 것

로컬 계정 조회는 이름이 데이터베이스에 존재하고 비밀번호가 그것과 일치했음을 증명합니다. RADIUS 교환은 RADIUS 서버가 받은 속성에 대해 Access-Accept를 반환했음을 증명합니다. 어느 진술도 요소 유형을 언급하지 않습니다, 왜냐하면 둘 다 지식을 검증하기 때문입니다. 그리고 NIST 디지털 신원 지침은 서로 다른 요소 유형과 그 인증자를 세며, 서버나 프롬프트가 아닙니다.

두 시스템이 참여하는 정당한 설계가 있습니다. 중앙 서비스가 사람을 인증하는 동안 게이트웨이는 그 계정이 이 터널에 대한 권한이 있는지 독립적으로 확인합니다. 그것은 인증 옆의 권한 부여이며, 이를 두 요소라고 부르면 정책 검사와 소유 증명을 혼동하는 것입니다.

RADIUS는 하나를 검증하는 것 앞에 있을 때 실제 두 번째 요소를 운반할 수 있으며, 예를 들어 푸시 승인이나 하드웨어 토큰입니다. 봉투는 사용자가 어떤 인증자를 제시했는지 알려주지 않으므로 게이트웨이 라벨이 아니라 백엔드 정책을 읽으십시오.

AND, OR, 대체는 서로 다른 제품입니다

구현을 비교하기 전에 요구 사항에서 둘 다가 무엇을 의미하는지 정하십시오. AND 정책은 명명된 모든 검사를 통과해야 하고, OR 정책은 성공하는 것을 받아들이며, 대체는 선언된 실패 조건에서만 두 번째를 시도합니다. 이 셋은 장애 시 반대로 행동하며, 보통 검토가 의도한 것은 그중 하나뿐입니다.

구성 화면에 백엔드 항목을 두 개 추가해도 제품이 어떤 정책을 구현하는지는 드러나지 않습니다. 일부 게이트웨이는 플러그인을 순서대로 연결하고 첫 거부에서 멈추는데, 이는 모든 플러그인이 필수일 때만 AND입니다. 다른 제품은 로컬 계정을 재정의로 취급하여 중앙 장애를 우회로 바꿉니다. 신뢰할 수 있는 답은 배포하는 빌드에 대해 실행하는 경로별 문서화된 부정 테스트입니다.

대체는 무언가 고장 났을 때 계속 작동하도록 존재하기 때문에 가장 의심받아 마땅합니다. RADIUS에 도달할 수 없을 때마다 로컬 비밀번호를 받아들이는 대체는 중앙 정책을 두 번째의 더 약한 문으로 바꾸었습니다.

OpenVPN의 이중 검사는 구체적인 사례입니다

커뮤니티 OpenVPN 2.6은 둘 다 활성화되면 클라이언트 인증서와 구성된 auth-user-pass-verify 스크립트를 모두 요구합니다. 이는 인증서 검증과 자격 증명 스크립트 사이의 문서화된 AND이며, 정말로 두 번의 검사입니다. 그래도 스크립트가 비밀번호만 검증할 수도 있으므로 자동으로 두 종류의 요소는 아닙니다.

이 조합은 연결 질문도 열어 둡니다. 인증서는 보통 장치를 식별하고 자격 증명은 사람을 식별하며, 기본 흐름에서 둘 다 같은 주체를 가리키도록 요구하는 것은 없습니다. 어떤 쌍이 허용되는지 결정한 뒤 그 매핑을 검증 스크립트 안이나 이후 권한 부여 단계에서 강제하십시오.

인증서 전용 모드는 PIN으로 보호될 수도 있고 아닐 수도 있는 키로 뒷받침되는 단일 검사입니다. PIN은 키 없이는 사용할 수 없을 때만 같은 자격 증명을 지식 더하기 소유로 바꿉니다. 키를 디스크에 암호화하지 않고 두면 두 번째 부분은 파일 권한으로 줄어듭니다.

어플라이언스 공급업체는 종종 웹 콘솔 뒤의 PAM 모듈이나 RADIUS 플러그인 같은 자체 배관을 만듭니다. 커뮤니티 동작은 이중 검사가 어떻게 보이는지에 대한 참조이며, 어플라이언스가 그것들을 어떻게 결합하는지에 대한 설명이 아닙니다.

자체 게이트웨이에서 조합을 확인하십시오

콘솔 요약을 신뢰하기 전에 구성을 읽으십시오. 정책을 결정하는 줄은 인증서 모드, 자격 증명 스크립트, 플러그인 순서입니다.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep은 인증서가 필요한지와 그 뒤에 어떤 스크립트가 실행되는지를 보여 주며, 순서는 이름이 시사하는 것보다 중요합니다. 인증서 덤프는 게이트웨이가 볼 신원을 제공하며, 연결 매핑에 필요한 CN과 일련번호도 포함합니다. RADIUS 테스트는 부정 사례로, 잘못된 비밀번호는 Access-Reject를, 올바른 것은 Access-Accept를 내야 합니다. 거부된 자격 증명이 여전히 세션을 만든다면, 스크립트는 인증 경로에 전혀 없습니다.

그다음 실험실 인스턴스에서 필수 백엔드를 멈추고 유효한 자격 증명으로 연결하여 장애 사례를 실행하십시오. 예상 결과는 거부이며, 그 밖의 것은 아무도 문서화하지 않은 대체 정책입니다.

요구 사항을 부정 사례로 작성하십시오

쓸 만한 요구 사항은 증명, 그것을 제시할 수 있는 계정, 검증자가 없을 때의 결과를 명시합니다. 장치 신원과 사람 신원 사이에 허용되는 짝짓기도 밝힙니다. 이는 구매 주문서의 제품 이름보다 정확하며 테스트할 수 있습니다.

수용에는 부적격한 로컬 계정, 빠진 필수 증명, 유효하지 않은 두 번째 요소, 도달할 수 없는 필수 백엔드라는 네 가지 거부가 포함되어야 합니다. 각 거부에는 다른 것과 구분되는 로그 줄이 필요하며, 그렇지 않으면 다음 사건은 추측으로 시작합니다. 게이트웨이, RADIUS 서버, 디렉터리가 서로를 탓하므로 어느 구성 요소가 각 결정을 했는지 기록하십시오.

플러그인이나 펌웨어를 변경한 뒤 네 가지 거부를 다시 실행하십시오. 비용이 적게 들고, 그것들이 보호하는 정책은 공격자가 가장 먼저 조사하는 부분입니다.