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에서 발췌)입니다:
--disable-client fwknop 클라이언트 구성 요소를 빌드하지 않습니다.
기본값은 클라이언트를 빌드하는 것입니다.
--disable-server fwknop 서버 구성 요소를 빌드하지 않습니다.
기본값은 서버를 빌드하는 것입니다.
--with-gpgme libgpgme을 사용한 gpg 암호화 지원
[default=check]
--with-gpgme-prefix=PFX GPGME가 설치된 접두사 (선택 사항)
--with-gpg=/path/to/gpg gpgme가 사용할 gpg 실행 파일의 경로를 지정합니다
[default=check path]
--with-firewalld=/path/to/firewalld
firewalld 실행 파일의 경로를 지정합니다
[default=check path]
--with-iptables=/path/to/iptables
iptables 실행 파일의 경로를 지정합니다
[default=check path]
--with-ipfw=/path/to/ipfw
ipfw 실행 파일의 경로를 지정합니다 [default=check
path]
--with-pf=/path/to/pfctl
pf 실행 파일의 경로를 지정합니다 [default=check
path]
--with-ipf=/path/to/ipf ipf 실행 파일의 경로를 지정합니다 [default=check
path]
예시:
./configure --disable-client --with-firewalld=/bin/firewall-cmd
./configure --disable-client --with-iptables=/sbin/iptables --with-firewalld=no
현재 Perl 버전을 사용 중이고 이 버전으로 마이그레이션할 계획이 있다면 몇 가지 알아야 할 사항이 있습니다:
Perl 기반 fwknop의 모든 기능과 특성이 이 구현으로 포팅된 것은 아닙니다. 우리는 C 버전을 가능한 한 가볍고 간결하게 유지하는 것이 중요하다고 생각했습니다. 생략된 대부분의 기능(예: 이메일 알림)은 다른 방법(예: 외부 스크립트를 사용하여 로그 파일을 모니터링하고 적절한 로그 메시지를 기반으로 알림)을 통해 수행할 수 있습니다.
fwknop 구성 및 액세스 파일 지시문과 값에 몇 가지 차이점이 있습니다. 이 중 일부는 상당히 미묘합니다. 해당 파일의 문서와 주석에 주의를 기울여야 합니다.
git에서 이 배포판을 가져오는 경우, autogen.sh 스크립트를 실행하여 autoconf 파일을 생성해야 합니다. 디렉토리나 파일이 누락되었다는 오류가 발생하면 autogen.sh를 다시 실행해 보십시오. 그런 다음 구성을 재생성하려면 autoreconf -i를 실행할 수 있습니다. 어떤 이유로 autoreconf가 작동하지 않으면 autogen.sh 스크립트로 충분합니다.
fwknop 및 fwknopd 매뉴얼 페이지 nroff 소스는 각각의 디렉토리(client 및 server)에 포함되어 있습니다. 이러한 nroff 파일은 'docs' 디렉토리의 asciidoc 소스에서 파생되었습니다. 자세한 내용은 docs의 README를 참조하십시오.