웹사이트 검색

Nmap 및 Tcpdump로 방화벽 구성을 테스트하는 방법


소개

인프라에 방화벽을 설정하는 것은 서비스에 대한 보안을 제공하는 좋은 방법입니다. 만족스러운 정책을 개발했으면 다음 단계는 방화벽 규칙을 테스트하는 것입니다. 방화벽 규칙이 수행하고 있다고 생각하는 대로 수행되는지 여부를 파악하고 인프라가 외부 세계에서 어떻게 보이는지 인상을 받는 것이 중요합니다.

이 가이드에서는 방화벽 규칙의 유효성을 검사하는 데 사용할 수 있는 몇 가지 도구와 기술을 살펴보겠습니다. 이들은 악의적인 사용자가 사용할 수 있는 동일한 도구 중 일부이므로 서버에 요청하여 찾을 수 있는 정보를 볼 수 있습니다.

전제 조건

이 가이드에서는 하나 이상의 서버에 방화벽이 구성되어 있다고 가정합니다. 다음 가이드 중 하나 이상을 따라 방화벽 정책 구축을 시작할 수 있습니다.

  • Iptables
    • Iptables Essentials: 일반 방화벽 규칙 및 명령

    • Ubuntu 22.04에서 UFW로 방화벽을 설정하는 방법
    • UFW 기초: 일반 방화벽 규칙 및 명령

    • Rocky Linux 9에서 FirewallD를 사용하여 방화벽을 설정하는 방법

    DigitalOcean 인프라에서 서버에 대한 추가 외부 계층으로 실행되는 DigitalOcean의 클라우드 방화벽을 구성할 수도 있습니다. 이렇게 하면 서버 자체에 방화벽을 구성할 필요가 없습니다.

    이 가이드에서는 대상을 테스트하려는 방화벽 정책이 포함된 서버를 호출합니다. 대상 외에도 방화벽이 보호하는 네트워크 외부에 있는 테스트할 서버에 액세스할 수 있어야 합니다. 이 가이드에서는 Ubuntu 22.04 서버를 감사 시스템으로 사용합니다.

    테스트할 서버와 평가할 대상이 있으면 이 가이드를 계속 진행할 수 있습니다.

    보안 감사를 위해 제어하는 인프라에 대해서만 이 가이드에 설명된 활동을 수행해야 합니다. 포트 스캐닝을 둘러싼 법률은 많은 관할권에서 불확실합니다. ISP 및 기타 공급자는 포트 스캐닝이 발견된 사용자를 금지하는 것으로 알려져 있습니다.

    방화벽 정책을 테스트하는 데 사용할 도구

    방화벽 정책을 테스트하는 데 사용할 수 있는 다양한 도구가 있습니다. 그들 중 일부는 기능이 중복됩니다. 가능한 모든 도구를 다루지는 않을 것입니다. 대신 감사 도구의 몇 가지 일반적인 범주를 다루고 이 가이드에서 사용할 도구를 살펴보겠습니다.

    패킷 분석기

    패킷 분석기를 사용하여 인터페이스를 통과하는 모든 네트워크 트래픽을 매우 자세하게 관찰할 수 있습니다. 대부분의 패킷 분석기에는 실시간으로 작동하거나, 패킷을 보내거나 받을 때 표시하거나, 패킷 정보를 파일에 기록하고 나중에 처리하는 옵션이 있습니다. 패킷 분석을 통해 대상 컴퓨터가 개방형 네트워크의 호스트로 다시 보내는 응답 유형을 세분화된 수준에서 볼 수 있습니다.

    이 가이드에서는 tcpdump 도구를 사용합니다. 이는 Linux 시스템에서 강력하고 유연하며 유비쿼터스이기 때문에 좋은 옵션입니다. 나중에 분석하기 위해 기록이 필요한 경우 테스트를 실행할 때 이를 사용하여 원시 패킷을 캡처합니다. 다른 인기 있는 옵션으로는 Wireshark(또는 명령줄 사촌인 tshark)와 tcpflow가 있으며 전체 TCP 대화를 체계적으로 구성할 수 있습니다.

    포트 스캐너

    패킷 분석기가 캡처할 트래픽 및 응답을 생성하기 위해 포트 스캐너를 사용합니다. 포트 스캐너를 사용하여 다양한 유형의 패킷을 제작하고 원격 호스트로 전송하여 서버가 허용하는 트래픽 유형을 검색할 수 있습니다. 악의적인 사용자는 종종 이를 악용할 취약한 서비스를 찾기 위한 검색 도구로 사용하므로(먼저 방화벽을 사용하는 이유의 일부) 공격자가 무엇을 검색할 수 있는지 확인하는 데 이 도구를 사용합니다.

    이 가이드에서는 nmap 네트워크 매핑 및 포트 스캔 도구를 사용합니다. nmap을 사용하여 대상 컴퓨터에 어떤 서비스가 있고 어떤 방화벽 규칙이 이를 보호하는지 파악하기 위해 다양한 유형의 패킷을 보낼 수 있습니다.

    감사 시스템 설정

    시작하기 전에 필요한 도구가 설치되어 있는지 확인해야 합니다. Ubuntu의 저장소에서 tcpdumpnmap을 얻을 수 있습니다. apt update를 실행하여 로컬 패키지 목록을 업데이트한 다음 apt install로 설치합니다.

    1. sudo apt update
    2. sudo apt install tcpdump nmap

    다음으로 스캔 결과를 저장할 수 있는 디렉터리를 만듭니다.

    1. mkdir ~/scan_results

    깨끗한 결과를 얻으려면 감사 시스템과 대상 시스템 사이에 열려 있을 수 있는 모든 세션을 종료하십시오. 여기에는 SSH 세션, 웹 브라우저에서 설정했을 수 있는 모든 HTTP(S) 연결 등이 포함됩니다.

    열린 TCP 포트에 대한 대상 스캔

    이제 서버와 파일이 준비되었으므로 대상 호스트에서 열린 TCP 포트를 스캔하는 작업을 시작합니다.

    실제로 nmap이 수행하는 방법을 알고 있는 몇 가지 TCP 스캔이 있습니다. 일반적으로 시작하기에 가장 좋은 방법은 전체 TCP 연결을 실제로 협상하지 않기 때문에 "하프 오픈 스캔\이라고도 하는 SYN 스캔입니다. 이것은 일부 침입 감지에 등록하지 않기 때문에 공격자가 자주 사용합니다. 전체 핸드셰이크를 완료하지 않기 때문입니다.

    패킷 캡처 설정

    스캔하기 전에 테스트에서 생성된 트래픽을 캡처하도록 tcpdump를 설정합니다. 이렇게 하면 필요한 경우 나중에 보내고 받은 패킷을 더 깊이 있게 분석하는 데 도움이 됩니다. SYN 스캔과 관련된 파일을 함께 보관할 수 있도록 ~/scan_results 내에 디렉터리를 만듭니다.

    1. mkdir ~/scan_results/syn_scan

    다음 명령을 사용하여 tcpdump 캡처를 시작하고 결과를 ~/scan_results/syn_scan 디렉토리의 파일에 쓸 수 있습니다.

    1. sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets

    기본적으로 tcpdump는 포그라운드에서 실행됩니다. 동일한 창에서 nmap 스캔을 실행하려면 tcpdump 프로세스를 일시 중지한 다음 백그라운드에서 다시 시작해야 합니다.

    CTRL-Z를 눌러 실행 중인 프로세스를 일시 중지할 수 있습니다.

    Output
    ^Z [1]+ Stopped sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets

    이제 bg를 입력하여 백그라운드에서 작업을 다시 시작할 수 있습니다.

    1. bg

    이번에는 "Stopped\ 레이블이 없고 프로세스가 백그라운드에서 실행될 것임을 나타내는 앰퍼샌드가 있는 유사한 출력 라인을 수신해야 합니다(즉, 더 이상 터미널을 차단하지 않음).

    Output
    [1]+ sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets &

    이제 명령이 백그라운드에서 실행되어 감사 시스템과 대상 시스템 간에 이동하는 모든 패킷을 감시합니다. 이제 SYN 스캔을 실행할 수 있습니다.

    SYN 스캔 실행

    tcpdump가 대상 시스템에 트래픽을 기록하면 nmap을 실행할 준비가 된 것입니다. 다음 플래그와 함께 nmap을 실행할 수 있습니다.

    • -sS: SYN 스캔을 시작합니다. 이것은 기술적으로 스캔 유형이 지정되지 않은 경우 nmap이 수행할 기본 스캔이지만 명시적으로 여기에 포함할 것입니다.
    • -Pn: nmap에 호스트 검색 단계를 건너뛰도록 지시합니다. 호스트가 ping에 응답하지 않으면 테스트를 조기에 중단합니다. 대상이 온라인 상태임을 알고 있으므로 건너뛸 수 있습니다.
    • -p-: 기본적으로 SYN 스캔은 가장 일반적으로 사용되는 1000개의 포트만 시도합니다. 이것은 nmap에게 사용 가능한 모든 포트를 확인하도록 지시합니다.
    • -T4: 이것은 nmap에 대한 타이밍 프로필을 설정하여 약간 덜 정확한 결과의 위험이 있는 테스트 속도를 높이도록 지시합니다. 0이 가장 느리고 5가 가장 빠릅니다. 모든 포트를 스캔하고 있으므로 이를 기준으로 사용하고 잘못 보고되었을 수 있는 포트를 나중에 다시 확인할 수 있습니다.
    • -vv: 이것은 출력의 자세한 정도를 증가시킵니다.
    • --reason: nmap에게 포트 상태가 특정 방식으로 보고된 이유를 제공하도록 지시합니다.
    • -oN: 결과를 나중에 분석에 사용할 수 있는 파일에 기록합니다.

    참고: IPv6를 확인하려면 명령에 -6 플래그를 추가해야 합니다…

    함께 명령은 다음과 같이 표시됩니다.

    1. sudo nmap -sS -Pn -p- -T4 -vv --reason -oN ~/scan_results/syn_scan/nmap.results target_ip_addr

    타이밍 템플릿이 4로 설정되어 있어도 스캔이 65,535개의 포트를 통해 실행되기 때문에 상당한 시간이 걸릴 수 있습니다. 결과는 다음과 같이 인쇄되기 시작합니다.

    Output
    Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2022-12-19 16:54 EDT Initiating Parallel DNS resolution of 1 host. at 16:54 Completed Parallel DNS resolution of 1 host. at 16:54, 0.12s elapsed Initiating SYN Stealth Scan at 16:54 Scanning 198.51.100.15 [65535 ports] Discovered open port 22/tcp on 198.51.100.15 Discovered open port 80/tcp on 198.51.100.15 SYN Stealth Scan Timing: About 6.16% done; ETC: 17:02 (0:07:52 remaining) SYN Stealth Scan Timing: About 8.60% done; ETC: 17:06 (0:10:48 remaining) . . .

    tcpdump 패킷 캡처 중지

    스캔이 완료되면 tcpdump 프로세스를 다시 포그라운드로 가져와 중지할 수 있습니다.

    "foreground\에 대해 fg를 실행하여 백그라운드에서 가져옵니다.

    1. fg

    Ctrl+C를 눌러 실행 중인 프로세스를 중지합니다.

    결과 분석

    이제 ~/scan_results/syn_scan 디렉터리에 두 개의 파일이 있어야 합니다. tcpdump 실행에 의해 생성된 패킷이라고 하는 하나와 nmap.results라고 하는 nmap에 의해 생성된 하나.

    먼저 nmap.results 파일을 살펴보겠습니다.

    1. less ~/scan_results/syn_scan/nmap.results
    # Nmap 6.49BETA4 scan initiated Mon Dec 19 17:05:13 2022 as: nmap -sS -Pn -p- -T4 -vv --reason -oN /home/user/scan_results/syn_scan/nmap.results 198.51.100.15
    Increasing send delay for 198.51.100.15 from 0 to 5 due to 9226 out of 23064 dropped probes since last increase.
    Increasing send delay for 198.51.100.15 from 5 to 10 due to 14 out of 34 dropped probes since last increase.
    Nmap scan report for 198.51.100.15
    Host is up, received user-set (0.00097s latency).
    Scanned at 2022-12-19 17:05:13 EDT for 2337s
    Not shown: 65533 closed ports
    Reason: 65533 resets
    PORT   STATE SERVICE REASON
    22/tcp open  ssh     syn-ack ttl 63
    80/tcp open  http    syn-ack ttl 63
    
    Read data files from: /usr/local/bin/../share/nmap
    # Nmap done at Mon Dec 19 17:44:10 2022 -- 1 IP address (1 host up) scanned in 2336.85 seconds
    

    위의 강조 표시된 영역에는 스캔의 주요 결과가 포함되어 있습니다. SSH 및 HTTP 트래픽을 허용하기 위해 스캔된 호스트에서 포트 22 및 포트 80이 열려 있음을 유추할 수 있습니다. 또한 65,533개의 포트가 닫힌 것을 관찰할 수 있습니다. 또 다른 가능한 결과는 "필터링됨\입니다. 필터링됨은 이러한 포트가 네트워크 경로를 따라 무언가에 의해 중지된 것으로 식별되었음을 의미합니다. 대상의 방화벽일 수도 있지만 중간 호스트에 대한 필터링 규칙일 수도 있습니다. 감사 및 대상 기계.

    대상과 주고받은 실제 패킷 트래픽을 보려면 다음과 같이 packets 파일을 다시 tcpdump로 읽어들일 수 있습니다.

    1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets | less

    이 파일에는 두 호스트 간에 발생한 전체 대화가 포함되어 있습니다. 다양한 방법으로 필터링할 수 있습니다.

    예를 들어 대상으로 전송된 트래픽만 보려면 다음을 입력할 수 있습니다.

    1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'dst target_ip_addr' | less

    마찬가지로 응답 트래픽만 보려면 dstsrc로 변경하면 됩니다.

    1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr' | less

    열린 TCP 포트는 SYN 패킷으로 이러한 요청에 응답합니다. 다음과 같은 필터를 사용하여 이 유형에 대한 응답을 직접 검색할 수 있습니다.

    1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr and tcp[tcpflags] & tcp-syn != 0' | less

    그러면 성공적인 SYN 응답만 표시되며 nmap 실행에서 본 포트와 일치해야 합니다.

    Output
    reading from file packets, link-type EN10MB (Ethernet) 17:05:13.557597 IP 198.51.100.15.22 > 198.51.100.2.63872: Flags [S.], seq 2144564104, ack 4206039348, win 29200, options [mss 1460], length 0 17:05:13.558085 IP 198.51.100.15.80 > 198.51.100.2.63872: Flags [S.], seq 3550723926, ack 4206039348, win 29200, options [mss 1460], length 0

    적합하다고 생각되는 대로 데이터를 더 많이 분석할 수 있습니다. 비동기 처리 및 분석을 위해 모두 캡처되었습니다.

    개방형 UDP 포트에 대한 대상 스캔

    이제 이러한 테스트를 실행하는 방법을 잘 알고 있으므로 비슷한 프로세스를 완료하여 열린 UDP 포트를 검색할 수 있습니다.

    패킷 캡처 설정

    다시 한 번 결과를 보관할 디렉터리를 만듭니다.

    1. mkdir ~/scan_results/udp_scan

    tcpdump 캡처를 다시 시작하십시오. 이번에는 새 ~/scan_results/udp_scan 디렉터리에 파일을 씁니다.

    1. sudo tcpdump host target_ip_addr -w ~/scan_results/udp_scan/packets

    프로세스를 일시 중지하고 Ctrl+Z를 입력한 다음 bg를 실행하여 백그라운드로 전환합니다.

    1. bg

    UDP 스캔 실행

    이제 UDP 스캔을 실행할 준비가 되었습니다. UDP 프로토콜의 특성으로 인해 이 스캔은 일반적으로 SYN 스캔보다 훨씬 오래 걸립니다. 실제로 시스템의 모든 포트를 스캔하는 경우 하루 이상 걸릴 수 있습니다. UDP는 비연결형 프로토콜이므로 응답이 없다는 것은 대상의 포트가 차단되었거나 수락되었거나 패킷이 손실되었음을 의미할 수 있습니다. 이들을 구별하기 위해 nmap은 응답을 얻기 위해 추가 패킷을 재전송해야 합니다.

    대부분의 플래그는 SYN 스캔에 사용한 것과 동일합니다. 실제로 유일한 새 플래그는 다음과 같습니다.

    • -sU: UDP 스캔을 수행하도록 nmap에 지시합니다.

    UDP 테스트 속도 향상

    이 테스트에 걸리는 시간이 걱정된다면 처음에는 UDP 포트의 하위 집합만 테스트하는 것이 좋습니다. -p- 플래그를 생략하여 가장 일반적인 1000개의 포트만 테스트할 수 있습니다. 이렇게 하면 스캔 시간이 상당히 단축될 수 있습니다. 하지만 완전한 그림을 원한다면 나중에 돌아가서 전체 포트 범위를 스캔해야 합니다.

    자체 인프라를 스캔하고 있기 때문에 UDP 스캔 속도를 높이는 가장 좋은 옵션은 대상 시스템에서 ICMP 속도 제한을 일시적으로 비활성화하는 것입니다. 일반적으로 Linux 호스트는 ICMP 응답을 초당 1개로 제한합니다(이는 일반적으로 좋은 일이지만 감사에는 적합하지 않음). 이는 전체 UDP 스캔에 18시간 이상이 걸린다는 것을 의미합니다. 다음을 입력하여 대상 컴퓨터에서 이 설정을 확인할 수 있습니다.

    1. sudo sysctl net.ipv4.icmp_ratelimit
    Output
    net.ipv4.icmp_ratelimit = 1000

    "1000\은 응답 사이의 밀리초 수입니다. 다음을 입력하여 대상 시스템에서 이 속도 제한을 일시적으로 비활성화할 수 있습니다.

    1. sudo sysctl -w net.ipv4.icmp_ratelimit=0

    테스트 후 이 값을 되돌리는 것이 매우 중요합니다.

    테스트 실행

    ~/scan_results/udp_scan 디렉터리에 결과를 작성해야 합니다. 모두 함께 명령은 다음과 같아야 합니다.

    1. sudo nmap -sU -Pn -p- -T4 -vv --reason -oN ~/scan_results/udp_scan/nmap.results target_ip_addr

    스캔이 완료되면 대상 시스템에서 ICMP 속도 제한(수정한 경우)을 되돌려야 합니다.

    1. sudo sysctl -w net.ipv4.icmp_ratelimit=1000

    tcpdump 패킷 캡처 중지

    fg를 실행하여 tcpdump 프로세스를 감사 시스템의 포그라운드로 되돌립니다.

    1. fg

    그런 다음 Ctrl+C를 사용하여 패킷 캡처를 중지합니다.

    결과 분석

    이제 생성된 파일을 살펴볼 수 있습니다.

    결과 nmap.results 파일은 마지막 결과와 유사해야 합니다.

    1. less ~/scan_results/udp_scan/nmap.results
    # Nmap 6.49BETA4 scan initiated Mon Dec 19 12:42:42 2022 as: nmap -sU -Pn -p- -T4 -vv --reason -oN /home/user/scan_results/udp_scan/nmap.results 198.51.100.15
    Increasing send delay for 198.51.100.15 from 0 to 50 due to 10445 out of 26111 dropped probes since last increase.
    Increasing send delay for 198.51.100.15 from 50 to 100 due to 11 out of 23 dropped probes since last increase.
    Increasing send delay for 198.51.100.15 from 100 to 200 due to 3427 out of 8567 dropped probes since last increase.
    Nmap scan report for 198.51.100.15
    Host is up, received user-set (0.0010s latency).
    Scanned at 2022-12-19 12:42:42 EDT for 9956s
    Not shown: 65532 closed ports
    Reason: 65532 port-unreaches
    PORT    STATE         SERVICE REASON
    22/udp  open|filtered ssh     no-response
    80/udp  open|filtered http    no-response
    443/udp open|filtered https   no-response
    
    Read data files from: /usr/local/bin/../share/nmap
    # Nmap done at Mon Dec 19 15:28:39 2022 -- 1 IP address (1 host up) scanned in 9956.97 seconds
    

    이 결과와 이전 SYN 결과의 주요 차이점은 open|filtered로 표시된 포트의 양일 가능성이 높습니다. 이는 nmap이 응답이 없다는 것이 서비스가 트래픽을 수락했음을 의미하는지 또는 전달 경로를 따라 일부 방화벽 또는 필터링 메커니즘에 의해 드롭되었는지 여부를 확인할 수 없음을 의미합니다.

    tcpdump 출력을 분석하는 것도 연결 플래그가 없고 ICMP 응답을 UDP 요청과 일치시켜야 하기 때문에 훨씬 더 어렵습니다.

    보고된 포트 중 하나에 대한 UDP 트래픽을 확인하도록 요청하여 open|filtered로 보고된 포트로 nmap이 전송해야 하는 패킷 수를 확인할 수 있습니다.

    1. sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 22'
    Output
    reading from file /home/user/scan_results/udp_scan/packets, link-type EN10MB (Ethernet) 14:57:40.801956 IP 198.51.100.2.60181 > 198.51.100.15.22: UDP, length 0 14:57:41.002364 IP 198.51.100.2.60182 > 198.51.100.15.22: UDP, length 0 14:57:41.202702 IP 198.51.100.2.60183 > 198.51.100.15.22: UDP, length 0 14:57:41.403099 IP 198.51.100.2.60184 > 198.51.100.15.22: UDP, length 0 14:57:41.603431 IP 198.51.100.2.60185 > 198.51.100.15.22: UDP, length 0 14:57:41.803885 IP 198.51.100.2.60186 > 198.51.100.15.22: UDP, length 0

    이를 "닫힘\으로 표시된 스캔된 포트 중 하나의 결과와 비교하십시오.

    1. sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 53'
    Output
    reading from file /home/user/scan_results/udp_scan/packets, link-type EN10MB (Ethernet) 13:37:24.219270 IP 198.51.100.2.60181 > 198.51.100.15.53: 0 stat [0q] (12)

    먼저 다음과 같이 UDP 패킷을 보내는 모든 포트 목록을 컴파일하여 nmap이 진행하는 프로세스를 수동으로 재구성할 수 있습니다.

    1. sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets "udp" | awk '{print $5;}' | awk 'BEGIN { FS = "." } ; { print $5 +0}' | sort -u | tee outgoing

    그러면 포트에 연결할 수 없다는 메시지를 받은 ICMP 패킷을 확인할 수 있습니다.

    1. sudo tcpdump -nn -Q in -r ~/scan_results/udp_scan/packets "icmp" | awk '{print $10,$11}' | grep unreachable | awk '{print $1}' | sort -u | tee response

    그런 다음 이 두 가지 응답을 받고 어떤 UDP 패킷이 ICMP 응답을 다시 수신하지 않았는지 확인할 수 있습니다.

    1. comm -3 outgoing response

    이것은 대부분 nmap이 보고한 포트 목록과 일치해야 합니다(손실된 반환 패킷의 잘못된 긍정이 일부 포함될 수 있음).

    호스트 및 서비스 검색

    대상에서 몇 가지 추가 테스트를 실행하여 nmap이 실행 중인 운영 체제나 서비스 버전을 식별할 수 있는지 확인할 수 있습니다. 버전 관리 결과를 보관할 디렉터리를 만듭니다.

    1. mkdir ~/scan_results/versions

    서버에서 서비스 버전 검색

    핑거프린팅이라고 하는 프로세스를 통해 대상에서 실행 중인 서비스 버전을 추측할 수 있습니다. 서버에서 정보를 검색하고 데이터베이스의 알려진 버전과 비교합니다.

    tcpdump는 이 시나리오에서 그다지 유용하지 않으므로 건너뛸 수 있습니다. 그래도 캡처하고 싶다면 지난 번에 사용한 프로세스를 따르십시오.

    사용해야 하는 nmap 스캔은 -sV 플래그에 의해 트리거됩니다. 이미 SYN 및 UDP 스캔을 수행했으므로 -p 플래그를 사용하여 확인해야 하는 정확한 포트를 전달할 수 있습니다. 여기에서 22와 80(SYN 스캔에 표시된 포트)을 볼 수 있습니다.

    1. sudo nmap -sV -Pn -p 22,80 -vv --reason -oN ~/scan_results/versions/service_versions.nmap target_ip_addr

    결과 파일을 보면 서비스 응답이 얼마나 "수다스러운\지에 따라 실행 중인 서비스에 대한 정보를 얻을 수 있습니다.

    1. less ~/scan_results/versions/service_versions.nmap
    # Nmap 6.49BETA4 scan initiated Mon Dec 19 15:46:12 2022 as: nmap -sV -Pn -p 22,80 -vv --reason -oN /home/user/scan_results/versions/service_versions.nmap 198.51.100.15
    Nmap scan report for 198.51.100.15
    Host is up, received user-set (0.0011s latency).
    Scanned at 2022-12-19 15:46:13 EDT for 8s
    PORT   STATE SERVICE REASON         VERSION
    22/tcp open  ssh     syn-ack ttl 63 OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0)
    80/tcp open  http    syn-ack ttl 63 nginx 1.4.6 (Ubuntu)
    Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
    
    Read data files from: /usr/local/bin/../share/nmap
    Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
    # Nmap done at Mon Dec 19 15:46:21 2022 -- 1 IP address (1 host up) scanned in 8.81 seconds
    

    여기에서 테스트가 허용된 SSH 프로토콜 버전뿐만 아니라 SSH 서버 버전과 이를 패키징한 Linux 배포판을 식별할 수 있었음을 알 수 있습니다. 또한 Nginx 버전을 인식하고 Ubuntu 패키지와 일치하는 것으로 다시 식별했습니다.

    호스트 운영 체제 검색

    nmap이 소프트웨어의 특성과 응답을 기반으로 호스트 운영 체제를 추측하도록 할 수 있습니다. 이는 서비스 버전 관리와 동일한 방식으로 작동합니다. 다시 한 번 이 테스트에서 tcpdump 실행을 생략하지만 원하는 경우 수행할 수 있습니다.

    운영 체제 감지를 수행하는 데 필요한 플래그는 -O(대문자 "O”)입니다. 전체 명령은 다음과 같습니다.

    1. sudo nmap -O -Pn -vv --reason -oN ~/scan_results/versions/os_version.nmap target_ip_addr

    출력 파일을 보면 다음과 같이 표시될 수 있습니다.

    1. less ~/scan_results/versions/os_version.nmap
    # Nmap 6.49BETA4 scan initiated Mon Dec 19 15:53:54 2022 as: nmap -O -Pn -vv --reason -oN /home/user/scan_results/versions/os_version.nmap 198.51.100.15
    Increasing send delay for 198.51.100.15 from 0 to 5 due to 65 out of 215 dropped probes since last increase.
    Increasing send delay for 198.51.100.15 from 5 to 10 due to 11 out of 36 dropped probes since last increase.
    Increasing send delay for 198.51.100.15 from 10 to 20 due to 11 out of 35 dropped probes since last increase.
    Increasing send delay for 198.51.100.15 from 20 to 40 due to 11 out of 29 dropped probes since last increase.
    Increasing send delay for 198.51.100.15 from 40 to 80 due to 11 out of 31 dropped probes since last increase.
    Nmap scan report for 198.51.100.15
    Host is up, received user-set (0.0012s latency).
    Scanned at 2022-12-19 15:53:54 EDT for 30s
    Not shown: 998 closed ports
    Reason: 998 resets
    PORT   STATE SERVICE REASON
    22/tcp open  ssh     syn-ack ttl 63
    80/tcp open  http    syn-ack ttl 63
    No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
    TCP/IP fingerprint:
    OS:SCAN(V=6.49BETA4%E=4%D=8/27%OT=22%CT=1%CU=40800%PV=N%DS=2%DC=I%G=Y%TM=55
    OS:DF6AF0%P=x86_64-unknown-linux-gnu)SEQ(SP=F5%GCD=1%ISR=106%TI=Z%CI=Z%TS=8
    OS:)OPS(O1=M5B4ST11NW8%O2=M5B4ST11NW8%O3=M5B4NNT11NW8%O4=M5B4ST11NW8%O5=M5B
    OS:4ST11NW8%O6=M5B4ST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120
    OS:)ECN(R=Y%DF=Y%T=40%W=7210%O=M5B4NNSNW8%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+
    OS:%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
    OS:T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A
    OS:=Z%F=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPC
    OS:K=G%RUCK=G%RUD=G)U1(R=N)IE(R=N)
    
    Uptime guess: 1.057 days (since Mon Dec 12 14:32:23 2022)
    Network Distance: 2 hops
    TCP Sequence Prediction: Difficulty=245 (Good luck!)
    IP ID Sequence Generation: All zeros
    
    Read data files from: /usr/local/bin/../share/nmap
    OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
    # Nmap done at Mon Dec 12 15:54:24 2022 -- 1 IP address (1 host up) scanned in 30.94 seconds
    

    이 경우 nmap은 본 서명을 기반으로 운영 체제에 대한 추측이 없음을 알 수 있습니다. 더 많은 정보를 수신했다면 대상 시스템의 서명이 데이터베이스의 운영 체제 서명과 어떻게 일치하는지 나타내는 다양한 백분율을 표시할 것입니다. TCP/IP fingerprint: 줄 아래에서 대상으로부터 nmap이 받은 지문 서명을 볼 수 있습니다.

    운영 체제 식별은 공격자가 시스템에서 유용할 수 있는 악용을 결정하는 데 도움이 될 수 있습니다. 적은 수의 문의에 응답하도록 방화벽을 구성하면 이러한 검색 방법 중 일부의 정확성을 저해하는 데 도움이 될 수 있습니다.

    결론

    방화벽을 테스트하고 내부 네트워크가 외부 공격자에게 어떻게 보이는지 인식하면 위험을 최소화할 수 있습니다. 자체 인프라를 조사하여 찾은 정보는 보안을 강화하기 위해 정책 결정을 재검토해야 하는지 여부에 대한 대화를 열 수 있습니다. 또한 잘못된 규칙 순서 또는 잊어버린 테스트 정책으로 인해 발생할 수 있는 보안의 공백을 밝힐 수 있습니다. 최신 검색 데이터베이스로 정책을 정기적으로 테스트하여 현재 보안 수준을 개선하거나 최소한 유지 관리하는 것이 좋습니다.

    방화벽에 대한 몇 가지 정책 개선 사항에 대한 아이디어를 얻으려면 이 가이드를 확인하세요.