더 많은 포트를 스캔하면 nmap이 기하급수적으로 느려집니다.

더 많은 포트를 스캔하면 nmap이 기하급수적으로 느려집니다.

나는 가끔 nmap을 사용하여 호스트를 확인합니다. 예: nmap -sS -p- example.com
그러나 이 명령은 완료되지 않습니다.

그래서 스캔을 작은 부분으로 나누었습니다: nmap -sS -p 0-999 example.com(완료까지 12초)
, nmap -sS -p 1000-1999 example.com(완료까지 14초) 등등. 그것은 지루.

더 넓은 부분을 사용하는 경우: nmap -sS -p 0-3999 example.com
완료하는 데 3분 이상 소요됩니다.

30분이 지나도 아직 nmap -sS -p 0-7999 example.com끝나지 않았습니다 .

따라서:
1000개 포트 -> 12초
4000개 포트 -> 3분
9000개 포트 -> 30분

문제는 무엇입니까?
nmap을 사용하여 호스트의 열린 TCP 포트를 찾는 방법은 무엇입니까?

답변1

Nmap은 각 포트의 상태(열림, 닫힘, 필터링)를 정확하게 찾는 속도를 찾기 위해 최선을 다합니다. 타이밍 시스템은 복잡하며 스캔 속도가 매우 느려질 수 있는 최악의 시나리오가 있습니다. 이러한 상황 중 하나는 대상이 속도 제한 TCP 연결 재설정(RST)인 경우입니다. 이는 포트가 닫힐 때 Nmap이 수신하는 응답입니다. 시스템의 대부분의 포트는 일반적으로 닫혀 있으며 리소스를 절약하거나 검색 시도를 차단하기 위해 대상 운영 체제는 초당 한 번만 RST를 실행하도록 선택할 수 있습니다.

Nmap이 RST 속도 제한을 감지하면 해당 속도와 일치하도록 프로브 속도를 줄여야 합니다. 그렇지 않으면 응답이 수신되지 않기 때문에 닫힌 포트가 "필터링됨"으로 표시될 수 있습니다. 이는 방화벽이 해당 포트에 대한 트래픽을 일관되게 삭제하는 것과 일치합니다. 이러한 속도 저하가 점진적으로 발생하므로 처음 몇 개의 포트는 이후 포트만큼 영향을 받지 않습니다. 또한 닫힌 포트에만 영향을 미치므로 1~1000 사이에서 일반적으로 사용되는 포트는 속도 저하를 일으킬 가능성이 적습니다.

이 문제에 대한 해결 방법이 있지만 정확도가 떨어집니다. 포트 필터링과 포트 닫기의 차이점을 알고 싶지 않다면 이 --defeat-rst-ratelimit옵션을 사용하여 속도 제한 RST가 Nmap의 타이밍에 영향을 미치지 않도록 할 수 있습니다. Nmap은 네트워크에 적합한 속도로 계속해서 전송하고, 삭제된 패킷을 감지하고 필요한 경우 속도를 늦추지만, 닫힌 포트를 필터링된 것으로 표시해 드릴 것입니다. 열린 포트 세트는 대부분의 사람들이 원하는 것과 정확히 동일해야 합니다. 실제로 --open닫혀 있고 필터링된 포트에 대한 정보가 완전히 인쇄되지 않도록 추가할 수도 있습니다.

답변2

-T5스캔 속도를 높이는 옵션을 추가할 수 있습니다 . ~에 따르면nmap 타이밍 및 성능권장 -T4옵션:

항상 -T4를 사용하는 것이 좋습니다. 어떤 사람들은 -T5를 좋아하지만 나에게는 너무 공격적입니다. 사람들은 호스트가 충돌할 가능성이 적다고 생각하거나 일반적으로 예의바르다고 생각하기 때문에 -T2를 지정하는 경우가 있습니다. 그들은 종종 매너가 실제로 얼마나 느린지 깨닫지 못합니다. 스캔은 기본 스캔보다 최대 10배 더 오래 걸릴 수 있습니다. 기본 타이밍 옵션(-T3)을 사용할 때 기계 충돌 및 대역폭 문제가 거의 발생하지 않으므로 일반적으로 신중한 스캐너에 이 옵션을 권장합니다. 이러한 문제를 줄이는 데에는 타이밍 값을 사용하는 것보다 버전 감지를 생략하는 것이 더 효과적입니다.

답변3

-v속도 저하의 원인을 파악하는 데 도움이 되도록 (verbose)로 nmap을 실행해 보세요 .

내 서버 중 하나에서 실행하면 nmap -sS -Pn -v -p 1-9999 myserver.com포트 3000 이후에 다음이 생성됩니다.

Increasing send delay for (ip address) from 0 to 5 due to max_successful_tryno increase to 4
Increasing send delay for (ip address) from 5 to 10 due to 17 out of 55 dropped probes since last increase.
[...]
Increasing send delay for (ip address) from 160 to 320 due to 11 out of 31 dropped probes since last increase.
SYN Stealth Scan Timing: About 17.08% done; ETC: 13:17 (0:02:30 remaining)

이 메시지는 1024 미만의 포트에는 나타나지 않는 것 같습니다.

관련 정보