isnic/proberAnsible과 BATS를 사용하여 여러 관점에서 DNS, 호스트 가용성, 열린 포트 및 TLS 구성을 검증하는 자동화되고 재현 가능한 네트워크 보안 테스트 프레임워크입니다.
이 프로젝트는 Ansible을 사용하여 네트워크 인프라에 대한 보안 가정을 검증하는 BATS 테스트 파일을 생성합니다. 테스트는 Prober가 배포된 프로브 머신("프로버 노드")에서 실행됩니다.
이 도구는 자체 네트워크의 재현 가능하고 자동화된 테스트를 위해 설계되었습니다. 각각 프로브된 네트워크에 대해 다른 관점을 가진 여러 프로버 노드가 테스트를 실행할 수 있습니다. 예를 들어 외부 영역에서의 관점, 내부 영역에서의 관점, DMZ 내부에서의 관점 등이 있습니다.
권한이 없는 네트워크를 프로빙하기 위해 Prober를 사용하는 것은 불법일 수 있습니다.
테스트를 프로버 노드에 배포하는 Ansible 마스터에서:
ansible (당연히!)python*-netaddr (GNU/Linux) / py*-netaddr (FreeBSD)프로버 노드 자체에서:
bashsshnmapdig/kdigtestssl결과(*.tap 파일)를 검토하는 시스템에서는 tappy를 설치하는 것이 좋습니다. 결과는 각 프로버 노드의 로컬 git 저장소(기본적으로 /var/run/prober/results/, 아래 구성 옵션 참조)에 보관되며, 각 스캔 실행이 완료된 날짜로 태그된 커밋이 있어 기록 보관 및 쉬운 비교가 가능합니다.
Ansible은 프로버 노드에 테스트를 생성하는 데 사용됩니다. 프로버 노드는 Prober의 종속성을 설치할 수 있는 모든 FreeBSD 또는 GNU/Linux 호스트일 수 있습니다. 테스트 전용일 필요는 없지만 권장됩니다. 적당한 규모의 네트워크 스캔은 몇 시간이 걸리고 많은 CPU를 사용하며 상당한 트래픽을 발생시킵니다.
네트워크가 다양한 관점(예: 내부 네트워크, DMZ, 인터넷)에서 어떻게 보이는지 확인하기 위해 여러 다른 머신에 Prober를 배포하는 것이 합리적입니다.
프로버 노드의 테스트 디렉토리에는 테스트 실행을 용이하게 하기 위해 run-tests.sh 스크립트가 생성됩니다. 테스트는 <simultaneous_tests_count>개의 테스트가 항상 동시에 실행되도록 보장하는 방식으로 실행됩니다. 이 변수는 프로빙 스캔이 사용하는 리소스와 필요한 대역폭을 제어하는 주요 방법입니다.
그런 다음 테스트 결과는 로컬 git 저장소에 저장되며, 각 실행이 완료된 날짜로 태그된 커밋이 있습니다(일부 긴 프로빙 실행의 경우 시작 날짜와 다를 수 있음).
몇 개의 호스트보다 큰 인프라를 다루는 경우 Mitogen과 같은 도구를 사용하여 테스트 생성을 획기적으로 가속화하는 것이 좋습니다.
Debian 또는 FreeBSD 서버를 프로버 노드로 준비합니다(**prober.example.com**이라고 부르겠습니다). SSH로 접근 가능하고 sudo를 사용할 수 있는지 확인합니다.
예제 인벤토리를 inventories/test/로 복사합니다.
해당 test 인벤토리에서:
group_vars/all.yml을 편집하고 zone_nameserver, zone_domains, address_blocks를 원하는 대로 설정합니다. 여기서는 프로브할 유일한 도메인으로 example.com을 추가한다고 가정합니다.hosts 파일을 편집하고 [prober-nodes] 섹션에 prober.example.com 프로버 노드를 구성합니다. tested_zone을 ****로 설정한다고 가정합니다.이제 프로버 노드에 ssh로 접속하여 /opt/prober/에 생성된 테스트를 검사할 수 있습니다. 만족스러우면 /opt/prober/run_tests.sh를 실행하여 테스트를 실행할 수 있습니다. 결과는 /var/run/prober/results에 저장됩니다.
구성 변수(probers.yml에 정의됨):
tests_directory (기본값: /opt/prober):
프로버 노드에서 테스트 파일(*.bats 파일)이 생성되는 디렉토리입니다.
results_repo_directory (기본값: /var/run/prober/results):
테스트 결과(*.tap 파일) 저장소의 디렉토리입니다. git 저장소가 초기화되고 실제 결과를 위한 tap/ 하위 디렉토리가 생성됩니다. 결과는 git 저장소에 커밋되며, 커밋은 yyyy-mm-dd 형식의 날짜로 태그됩니다(예: 2020년 3월 19일에 완료된 테스트의 결과 커밋은 2020-03-19로 태그됨).
simultaneous_tests_count (기본값: 20):
동시에 실행되는 테스트 수입니다.
prober_dev (기본값: 정의되지 않음):
개발 머신에서 의미 없는 특정 작업(예: 또는 설정)을 건너뜁니다.
영역은 ./data/<zone_name>.yml 파일에 정의되며, 최상위 키는 문자열 "tested_zone_settings"이고 다음과 같은 키를 포함합니다:
name: 파일 이름(확장자 제외)과 일치하는 영역의 이름입니다. 예: "internal", "external", "dmz"default (선택 사항): 이 영역의 모든 호스트에 대한 기본 설정입니다.^" 문자로 시작)default 키, 각 정규식 키 및 각 도메인 키에는 다음과 같은 키가 포함될 수 있습니다:
resolve: 호스트가 관련 IP 주소로 해석되어야 하는지 여부 (bool true/false 또는 문자열 "skip")ping: 호스트가 ping에 응답해야 하는지 여부 (bool true/false 또는 문자열 "skip")ports: 열려 있어도 되는 TCP 및 UDP 포트 목록 (하위 키 "tcp" 및 "udp", 각각 열려 있어도 되는 포트를 정의하는 정수 배열 또는 문자열 "skip") 및 더 깊은 검사를 수행할 TLS 지원 포트 (tls 하위 키, 포트 번호를 키로 하고 TLS 서비스 유형 또는 단어 "skip"을 값으로 하는 딕셔너리)ports: "skip"은 다음과 같은 약어입니다:
TLS 서비스 유형은 가 옵션에 대해 지원하는 모든 것이며, HTTPS 테스트(헤더 포함)의 경우 , 일반 TLS 테스트의 경우 입니다.
: TLS 테스트는 포트가 "" 키에서 열린 것으로 표시된 경우에만 실행됩니다.예제 구성은 여기에서 볼 수 있습니다.
전역 기본값은 probers.yml에 정의됩니다. 그런 다음 각 프로브된 호스트에 대해 결합됩니다. 먼저 관련 영역 기본값과 결합되고, 그 다음 호스트 이름과 일치하는 정규식 키와 결합되며, 마지막으로 특정 호스트 설정과 결합됩니다.
즉, 특정 영역의 특정 호스트 설정은 정규식 일치 키의 설정보다 우선하며, 이는 영역 기본값보다 우선하고, 이는 전역 기본값보다 우선합니다.
ports 키는 특별히 처리됩니다. 구성 상속 체인의 어딘가에 특정 포트가 나열되면, 체인 아래에서 해당 포트를 제거할 수 없으며, 추가 포트 번호를 추가하거나 특정 프로토콜의 모든 포트에 대한 테스트를 완전히 "skip"할 수만 있습니다.
영역 파일은 각 프로버 노드에 설정된 tested_zone 변수에 따라 선택됩니다.
일부 테스트는 IP 주소에 대해 의미가 있습니다. 즉, 해당 IP로 확인되는 도메인/호스트명 수에 관계없이 개별 IP 주소의 맥락에서 의미가 있습니다(예: 특정 포트가 열려 있는지 확인). 예를 들어 a.example.com과 b.example.com이 동일한 IP 주소를 가리킨다고 가정합시다. 위의 예제 구성에서 이는 포트 8080/tcp와 8443/tcp가 모두 열려 있어야 하며, 포트 8443/tcp에서 HTTPS가 예상된다는 의미입니다.
일부 테스트는 특정 도메인/호스트명과 IP 주소 조합의 맥락에서 의미가 있습니다(예: 특정 IP 주소의 특정 도메인 이름에 대해 제시된 TLS 인증서가 유효한지 확인).
이 두 종류의 테스트는 별도의 대상 목록을 생성하여 구현됩니다:
<ip-address> <hostname1> (<hostname2> <hostname3> ... <hostnameN>) 형식입니다.<ip-address> <hostname> 형식입니다.그런 다음 일부 테스트 파일은 첫 번째 목록의 대상에 대해서만 생성되고(예: 열린 포트 테스트), 일부 테스트 파일은 두 번째 목록의 대상에 대해서만 생성됩니다(예: TLS 관련 테스트).
특정 포트가 열려 있지 않으면 일부 테스트는 의미가 없습니다. TLS 관련 테스트는 해당 영역에서 관련 TCP 포트가 open으로 구성된 경우에만 특정 호스트에 대해 생성됩니다.
기본적으로 잘 알려진 TLS 지원 포트 중 하나가 ports.tcp 키에서 열린 것으로 구성된 경우, 해당 포트에 대한 TLS 테스트가 생성됩니다. 잘 알려진 TLS 지원 포트 목록은 default_host_settings 변수에 정의되어 있습니다.
일반적으로 Prober와 다른 유사한 도구 또는 서비스의 차이점은 일반적으로 다음과 같은 조합으로 요약됩니다:
Shodan은 노출된 시스템을 찾기 위해 인터넷을 크롤링합니다. Prober는 필요한 만큼의 다양한 관점에서 인프라에 대한 가정을 검증하기 위해 자체 인프라를 크롤링합니다. 잘 정의된 테스트와 정기적이고 예약된 실행을 통해 결과의 재현성에 중점을 두며, 각 테스트된 가정에 대해 부울 "통과/실패" 결과를 제공하려고 시도합니다(전체 스캔 결과 데이터는 검사 가능).
BitSight는 사용자에게 스캔이 언제 발생할지에 대한 제어나 정보를 제공하지 않으며 원시 스캔 데이터도 제공하지 않고 인프라에 대한 자체의 합리적인 가정 아이디어를 검증합니다. Prober는 인프라에 대한 사용자의 가정을 검증하고, 사용자의 일정에 따라 수행하며, 전체 원시 스캔 데이터를 검사용으로 제공합니다.
Natlas는 Shodan에 더 가까운 것 같습니다(노출된 호스트를 찾기 위해 크롤링하고 쿼리에 응답하여 결과 표시). 하지만 자체 호스팅 기능이 있어 Prober 노드처럼 인프라 내부 및 외부의 다른 위치에서 Natlas Agent를 실행할 수도 있습니다. Prober는 구성에 표현된 대로 자체 인프라에 대한 가정을 검증하기 위해 정기적인 스캔을 실행합니다.
로고는 verry obito, ID의 돋보기; CC-By와 Creative Stall, PK의 네트워크; CC-By를 기반으로 하며, Noun Project를 통해 제공됩니다.
test예제 영역 구성을 data/<tested_zone>.yml(따라서 data/test.yml)로 복사하고 편집합니다. 최소한 tested_zone_settings.name 키에는 tested_zone(즉, test)이 포함되어야 합니다.
DNS 영역을 내보내고 data/<dns_zone>.zone(여기서는 example.com)으로 저장합니다.
플레이북을 실행합니다:
ansible-playbook prober.yml -i inventories/test/ -vvv
이렇게 하면 프로버 노드에 테스트가 생성되고 매일 오전 1시에 실행되는 cronjob이 설정됩니다.
cronzabbixports:
tcp: "skip"
udp: "skip"
tls: "skip"
-t/--starttls"https""tls"tcpskip: 호스트를 완전히 건너뛸지 여부 (부울)