mrash/fwknop단일 패킷 인증 > 포트 노킹
fwknop은 강력한 서비스 은닉을 위해 SPA(Single Packet Authorization)로 알려진 인증 방식을 구현합니다. SPA는 방화벽 뒤에서 기본적으로 패킷을 차단(default-drop)하는 상태에서 서비스에 대한 원하는 접근을 통신하기 위해 암호화되고 재전송이 불가능하며 HMAC을 통해 인증되는 단일 패킷만을 필요로 합니다. SPA의 주요 용도는 방화벽을 사용하여 SSH와 같은 서비스에 대한 모든 연결 시도를 차단함으로써 취약점(0-day 및 패치되지 않은 코드 모두)의 악용을 더 어렵게 만드는 것입니다. 열린 포트가 없으므로 SPA로 은닉된 모든 서비스는 Nmap으로 스캔될 수 없습니다. fwknop 프로젝트는 Linux, OpenBSD, FreeBSD 및 Mac OS X에서 iptables, firewalld, PF 및 ipfw의 네 가지 방화벽을 지원합니다. 또한 사용자 정의 스크립트를 지원하므로 fwknop이 ipset이나 nftables와 같은 다른 인프라를 지원하도록 확장할 수 있습니다.
SPA는 본질적으로 차세대 Port Knocking(PK)이지만, PK의 핵심 이점을 유지하면서 PK가 보여준 많은 한계를 해결합니다. PK의 한계로는 일반적으로 재전송 공격 방어의 어려움, 비대칭 암호 및 HMAC 방식을 안정적으로 지원하기 어려운 점, 네트워크를 통해 전송되는 PK 시퀀스에 추가 패킷을 스푸핑하여 PK 서버에 대한 DoS 공격을 쉽게 수행할 수 있다는 점(따라서 PK 서버가 클라이언트가 올바른 시퀀스를 모른다고 믿게 만듦) 등이 있습니다. 이러한 모든 단점은 SPA에 의해 해결됩니다. 동시에 SPA는 기본 차단 방화벽 정책 뒤에 서비스를 숨기고, SPA 데이터를 수동적으로 획득하며(일반적으로 libpcap 또는 기타 방법을 통해), SPA 패킷 인증 및 암호화/복호화를 위한 표준 암호화 작업을 구현합니다.
fwknop에서 생성된 SPA 패킷은 암호화 후 인증(encrypt-then-authenticate) 모델에서 HMAC을 활용한 인증 암호화를 사용합니다. HMAC 사용은 현재 선택 사항이지만(--use-hmac 명령줄 스위치로 활성화), 다음 세 가지 이유로 적극 권장됩니다:
위의 마지막 이유는 SPA 패킷이 GnuPG로 암호화된 경우에도 HMAC을 사용해야 하는 이유입니다. HMAC 검사가 먼저 통과되지 않으면 SPA 데이터가 libgpgme 함수를 통해 전송되지 않기 때문입니다. GnuPG와 libgpgme는 비교적 복잡한 코드이므로, HMAC 작업을 통해 잠재적인 공격자가 이 코드와 상호작용할 수 있는 능력을 제한하는 것은 더 강력한 보안 태세를 유지하는 데 도움이 됩니다. SPA 통신을 위한 HMAC을 생성하려면 일반 암호화 키 외에 전용 키가 필요하며, 두 키 모두 --key-gen 옵션으로 생성할 수 있습니다.
fwknop은 SPA 패킷을 Rijndael 블록 암호 또는 GnuPG와 관련 비대칭 암호를 사용하여 암호화합니다. 대칭 암호화 방법을 선택하면 일반적으로 암호화 키가 클라이언트와 서버 간에 공유됩니다(자세한 내용은 /etc/fwknop/access.conf 파일 참조). Rijndael 암호화에 사용되는 실제 암호화 키는 표준 PBKDF1 키 유도 알고리즘을 통해 생성되며 CBC 모드가 설정됩니다. GnuPG 방법을 선택하면 암호화 키는 GnuPG 키 링에서 파생됩니다.
SPA 또는 보안에 취약한 사촌인 Port Knocking(PK)을 사용하는 사람들은 일반적으로 SPA/PK 소프트웨어가 배포된 동일한 시스템에서 실행되는 SSHD에 접근합니다. 즉, 호스트에서 실행되는 방화벽이 모든 들어오는 SSH 연결에 대해 기본 차단 정책을 적용하여 SSHD를 스캔할 수 없도록 하지만, SPA 데몬이 방화벽을 재구성하여 수동적으로 인증된 SPA 클라이언트에게 임시로 접근을 허용합니다:
"SSHD에 접근하기 위한 기본 SPA 사용"
fwknop은 위의 기능을 지원할 뿐만 아니라 NAT(iptables/firewalld 방화벽용)를 강력하게 사용합니다. 결국 중요한 방화벽은 일반적으로 독립형 호스트에 배포되는 것이 아니라 네트워크 간의 게이트웨이입니다. NAT은 이러한 방화벽에서 일반적으로 사용되어(적어도 IPv4 통신의 경우) RFC 1918 주소 공간의 내부 네트워크에 인터넷 액세스를 제공하고, 외부 호스트가 내부 시스템에서 호스팅되는 서비스에 접근할 수 있도록 합니다.
fwknop이 NAT과 통합되므로, 외부 인터넷 사용자는 SPA를 활용하여 방화벽을 통해 내부 서비스에 접근할 수 있습니다. 이는 현대의 전통적인 네트워크에서 많은 응용 분야가 있지만, Amazon AWS와 같은 클라우드 컴퓨팅 환경도 지원할 수 있습니다:
"Amazon AWS 클라우드 환경에서의 SPA 사용"
공식적인 크로스 플랫폼 fwknop 클라이언트 사용자 인터페이스 fwknop-gui
(다운로드, github)
는 Jonathan Bennett이 개발했습니다. NAT 요청, HMAC 및 Rijndael 키(GnuPG는 아직 지원되지 않음), fwknoprc 저장 등 대부분의 주요 클라이언트 측 SPA 모드를 지원합니다. 현재 fwknop-gui는 Linux, Mac OS X 및 Windows에서 실행됩니다 - OS X의 스크린샷입니다:
"Mac OS X에서의 fwknop-gui"
마찬가지로 업데이트된
Android 클라이언트도
사용 가능합니다.
fwknop에 대한 포괄적인 튜토리얼은 여기에서 찾을 수 있습니다:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html
다음은 fwknop 프로젝트에서 지원하는 전체 기능 목록입니다:
tcpdump -w <file> 사용)가 기록한 파일, iptables ULOG pcap 작성기, 또는 --udp-server 모드의 UDP 소켓을 통해 직접 패킷 데이터를 획득할 수 있습니다./etc/fwknop/access.conf 파일을 통해 고유한 대칭 또는 비대칭 암호화 키를 할당받을 수 있습니다.fwknop 프로젝트는 GNU General Public License (GPL v2) 또는 (선택에 따라) 이후 버전의 조건에 따라 오픈 소스 소프트웨어로 출시됩니다. 최신 릴리스는 다음에서 찾을 수 있습니다: http://www.cipherdyne.org/fwknop/
이 README 파일은 2013년 7월에 이루어진 2.5 릴리스 기준 fwknop 프로젝트의 현재 상태를 설명합니다. 현재 Firewall Knock Operator 라이브러리인 libfko와 fwknop 클라이언트 및 서버 애플리케이션이 구현되어 있습니다. 라이브러리는 다른 fwknop 구성 요소가 사용하는 SPA 데이터를 관리하기 위한 API 및 백엔드 기능을 제공합니다. 또한 SPA 기능이 필요한 다른 프로그램에서도 사용할 수 있습니다(예: perl 디렉토리의 FKO perl 모듈, python 디렉토리의 Python 바인딩 참조).
이전 버전의 fwknop(원래 perl 구현 포함)에서 업그레이드하는 경우, fwknop-2.5 이상으로의 원활한 전환을 위해 다음 링크를 읽어야 합니다:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#backwards-compatibility
이 배포판은 빌드 설정을 위해 GNU autoconf를 사용합니다. autoconf 사용에 대한 일반적인 기본 사항은 INSTALL 파일을 참조하십시오.
fwknop에 특화된 몇 가지 "configure" 옵션이 있습니다. 다음은 (./configure --help에서 발췌)입니다: