보안 경계 및 기준선
보안 설정에서는 먼저 두 가지를 확인합니다. 모든 요청이 반드시 fn-knock를 통과하는지, 그리고 게이트웨이가 실제 클라이언트 IP를 받는지입니다. 둘 중 하나라도 충족되지 않으면 인증, 허용 목록 및 지역 규칙이 예상과 다르게 작동할 수 있습니다.
경계부터 확인
fn-knock는 게이트웨이 진입점을 통과하는 트래픽만 제어할 수 있습니다. 다음 상황은 게이트웨이 외부에서 처리합니다.
- 라우터, 클라우드 보안 그룹 또는 Docker에서 서비스의 원래 포트를 공개한 경우
- CDN, 리버스 프록시 또는 터널이 서비스로 직접 연결되는 경우
- 앞단 프록시가 자신의 사설망 주소를 클라이언트 IP로 잘못 전달하는 경우
- 관리 페이지, 데이터베이스 또는 SSH가 별도로 공개된 경우
게이트웨이는 루프백, 사설망, 링크 로컬 및 CGNAT 주소를 로컬 출발지로 판단하고 인증 사전 검사 단계에서 바로 허용합니다. 이 규칙은 세션과 IP 접근 권한보다 먼저 적용됩니다. 따라서 보호된 서비스를 확인할 때는 모바일 네트워크나 다른 실제 인터넷 연결을 사용하고 가정용 Wi-Fi에서만 테스트하지 않습니다.
권장 보안 기준선
- 게이트웨이에 필요한 포트만 외부에 공개하고 관리 진입점은 LAN, VPN 또는 신뢰할 수 있는 리버스 프록시 뒤에만 둡니다.
- 게이트웨이에 정식 HTTPS 인증서를 준비하고 공개하는 각 Host에 올바른 DNS를 설정합니다.
- 복구 가능한 로그인 자격 증명을 두 개 이상 만들고 자주 사용하는 기기에는 패스키도 연결합니다.
- 새 서비스는 기본적으로 “로그인 필요”를 켜고 명확한 필요가 있을 때만 공개합니다.
- 요청 로그와 이벤트 알림을 켜고 정상 트래픽을 관찰한 뒤 WAF, 게이트웨이 스로틀링, 스캐너 또는 차단 목록 규칙을 강화합니다.
- 호스트, fn-knock 및 업스트림 서비스를 정기적으로 업데이트하고 업데이트 전에는 보호된 백업을 내보냅니다.
제어 계층별 역할
| 계층 | 해결하는 문제 | 주요 메뉴 |
|---|---|---|
| 게이트웨이 접근 범위 | 게이트웨이에 접근할 수 있는 지역 또는 CIDR 제한 | 시스템 설정 → 게이트웨이 |
| 매핑 접근 정책 | Host를 공개할지 로그인을 요구할지 결정 | 서브도메인 매핑 |
| 서브도메인 고급 인증 | 출발지 또는 요청 특성에 따라 현재 Host의 임시 자격 증명 발급 | 서브도메인 매핑 → 고급 인증 |
| 인증 및 세션 | ID, 세션 시간, 쿠키 공유 및 자격 증명 범위 확인 | 인증 설정, 세션 및 보안 |
| IP 허용 목록 | 고정 IP/CIDR 또는 로그인한 IP에 접근 권한 부여 | IP 허용 목록 |
| 로그인 백오프 | 같은 출발지에서 계속 실패하는 로그인 시도 지연 | 세션 및 보안 → 로그인 백오프 |
| 게이트웨이 스로틀링 및 크롤러 차단 | 빈번한 리버스 프록시 트래픽을 제한하고 확인된 크롤러 거부 | 시스템 설정 → 게이트웨이 |
| 스캐너 차단 | 비정상 경로 요청을 기준으로 별도의 차단 목록 유지 | 시스템 설정 → 차단 |
| 일반 차단 목록 | 확인된 개별 출발지 IP를 즉시 거부 | 세션 및 보안 → 일반 차단 목록 |
| WAF | 게이트웨이를 통과하는 HTTP 요청 탐지 또는 차단 | 시스템 설정 → WAF |
| SSH 방화벽 | 출발지와 로그인 실패를 기준으로 호스트 SSH 보호 | SSH 보안, 호스트 제어 기능을 지원하는 배포에서만 사용 |
| 호스트 또는 상위 방화벽 | 서비스의 원래 포트와 관리 포트를 제한 | 호스트, 라우터 또는 클라우드 보안 그룹 |
이러한 제어는 서로 보완하며 대신할 수 없습니다. 예를 들어 WAF는 이미 공개된 데이터베이스 포트를 닫지 않으며 허용 목록도 업스트림 서비스 취약점을 해결하지 않습니다. 서브도메인 고급 인증 규칙과 일치하면 현재 Host 전체가 허용되므로 지속적인 경로 단위 제한으로 사용하면 안 됩니다.
실제 클라이언트 IP
CDN, 리버스 프록시 또는 터널에서 온 요청을 올바르게 식별할 수 있는지는 업스트림의 실제 IP 헤더에 달려 있습니다. fn-knock는 일반적인 X-Forwarded-For, X-Real-IP, EO-Connecting-IP 및 Ali-Real-Client-IP 정보를 순서대로 처리합니다.
현재 설정 페이지에는 인바운드 신뢰 프록시 CIDR 목록이 없습니다. 앞단 프록시는 외부 클라이언트가 위조할 수 있는 실제 IP 헤더를 삭제하거나 다시 작성합니다. 127.0.0.1, 192.168.x.x 같은 주소를 잘못 전달하면 인터넷 요청이 로컬 예외로 오인될 수 있습니다. EdgeOne, ESA, Cloudflare 또는 자체 리버스 프록시를 연결한 뒤에는 외부 네트워크에서 요청 로그의 “클라이언트 IP”와 “연결 출발지 IP”를 각각 확인합니다.
관리 영역 분리
관리 페이지에는 인증, 인증서, 프록시, 차단 목록 및 터미널을 변경할 권한이 있으므로 일반 서비스 진입점보다 엄격한 경계를 적용합니다.
- 인증 설정에서 관리 페이지의 접근 가능 범위를 별도로 설정합니다.
- LAN, VPN 또는 신뢰할 수 있는 고정 CIDR로 우선 제한합니다.
- 공개 서비스와 취약한 비밀번호 자격 증명을 공유하지 않습니다.
- 터미널을 사용할 수 있는 플랫폼에서는 서비스 프로세스의 호스트 권한도 고려합니다.
- 두 번째 관리자 자격 증명과 로컬 콘솔 복구 수단을 유지합니다.
- 활성 세션, IP 변경 이력 및 로그인 백오프를 정기적으로 확인합니다.
관리 페이지의 경로를 숨기거나 바꾸는 것은 접근 제어가 아닙니다. 진입점에는 여전히 인증, 네트워크 제한 및 정식 HTTPS가 필요합니다.
업스트림 포트 제한
클라이언트가 리버스 프록시를 우회할 수 없을 때만 리버스 프록시가 보안 경계 역할을 합니다.
- 업스트림 서비스는
127.0.0.1이나 fn-knock만 접근할 수 있는 컨테이너 네트워크에서 우선 수신 대기하도록 설정합니다. - LAN 주소에서 수신 대기해야 한다면 호스트 방화벽으로 게이트웨이 출발지만 허용합니다.
- Docker
ports, 라우터 포트 포워딩, 클라우드 보안 그룹, FRP 및 CDN 오리진 연결을 확인합니다. - 프로토콜 매핑은 TCP/UDP 트래픽을 공개하며 HTTP 인증과 WAF를 거치지 않으므로 별도로 제한합니다.
인터넷에서 공개 주소를 스캔해 서비스의 원래 포트가 실수로 노출되지 않았는지 확인합니다. 같은 LAN에서만 테스트해서는 인터넷 경계가 올바른지 입증할 수 없습니다.
이상 발생 시
- 먼저 요청 로그에서 요청이 게이트웨이에 도착했는지 확인합니다.
- Host, 경로, 업스트림 대상 및 라우트 유형이 예상과 일치하는지 확인합니다.
- 클라이언트 IP가 프록시 주소가 아니라 실제 공인 IP 주소인지 확인합니다.
- 세션, 허용 목록, 로그인 백오프, 스캐너 차단 목록, 일반 차단 목록 및 WAF 로그를 확인합니다.
- 이벤트 센터와 대조해 설정 변경, 로그인, 차단 또는 업데이트가 발생한 시각을 확인합니다.
- 원래 포트가 공개된 것으로 의심되면 라우터, 클라우드 보안 그룹, 컨테이너 포트 및 호스트 방화벽을 차례로 확인합니다.
서비스를 복구할 때는 문제가 발생한 한 계층의 정책만 일시적으로 완화하고 원래 값을 기록합니다. 원인을 확인한 뒤 보안 설정을 복원합니다. 인증, WAF 및 차단 목록을 동시에 꺼서 원인을 찾을 단서를 잃지 않습니다.