나는 가끔 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분 이상 소요됩니다.
그리고 nmap -sS -p 0-7999 example.com30분이 지나도 끝나지 않습니다.
따라서:
1000개 포트 -> 12초
4000개 포트 -> 3분
9000개 포트 -> 30분
뭐가 문제 야?
nmap을 사용하여 한 호스트에 대해 열려 있는 TCP 포트를 어떻게 찾을 수 있습니까?
답변1
Nmap은 모든 포트의 상태(열림, 닫힘 또는 필터링됨)를 정확하게 찾을 수 있는 속도를 찾기 위해 최선을 다합니다. 타이밍 시스템은 복잡하며 스캔 속도가 매우 느려질 수 있는 최악의 시나리오가 있습니다. 이러한 경우 중 하나는 대상이 포트가 닫힐 때 Nmap이 받는 응답인 속도 제한 TCP 연결 재설정(RST)인 경우입니다. 시스템의 대부분의 포트는 일반적으로 닫혀 있으며 리소스를 절약하거나 검색 시도를 방해하기 위해 대상 OS는 초당 한 번만 RST를 실행하도록 선택할 수 있습니다.
Nmap이 RST 속도 제한을 감지하면 해당 속도에 맞게 프로브 속도를 줄여야 합니다. 그렇지 않으면 방화벽이 해당 포트에 대한 트래픽을 삭제하는 것과 마찬가지로 응답이 수신되지 않았기 때문에 닫힌 포트가 "필터링됨"으로 표시될 수 있습니다. 이러한 속도 저하 동작은 점진적으로 발생하므로 처음 몇 개의 포트는 이후 포트만큼 영향을 받지 않습니다. 또한 닫힌 포트에만 영향을 미치므로 1~1000 사이에서 일반적으로 사용되는 포트는 속도 저하에 기여할 가능성이 적습니다.
이 문제에 대한 해결 방법이 있지만 정확도가 떨어집니다. 필터링된 포트와 닫힌 포트 사이의 차이를 아는 데 관심이 없다면 --defeat-rst-ratelimit속도 제한 RST가 Nmap의 타이밍에 영향을 미치지 않도록 하는 옵션을 사용할 수 있습니다. Nmap은 네트워크에 적합한 속도로 계속 전송하여 삭제된 패킷을 감지하고 필요한 경우 속도를 늦추지만 닫힌 포트를 필터링된 것으로 표시하는 데 매우 만족합니다. 열린 포트 세트는 정확히 동일해야 하며 이는 대부분의 사람들이 원하는 전부입니다. 실제로 --open닫힌 포트와 필터링된 포트에 대한 정보가 모두 인쇄되는 것을 방지하기 위해 추가할 수도 있습니다.
답변2
-T5스캔 속도를 높이는 옵션을 추가할 수 있습니다 . 에 따르면nmap 타이밍 및 성능옵션을 사용하는 것이 좋습니다 -T4:
항상 -T4를 사용하는 것이 좋습니다. 내 취향에 비해 너무 공격적이지만 어떤 사람들은 -T5를 좋아합니다. 사람들은 호스트가 충돌할 가능성이 적다고 생각하거나 일반적으로 예의바르다고 생각하기 때문에 -T2를 지정하는 경우가 있습니다. 그들은 종종 -T 예의가 실제로 얼마나 느린지 깨닫지 못합니다. 스캔은 기본 스캔보다 10배 더 오래 걸릴 수 있습니다. 기본 타이밍 옵션(-T3)에서는 기계 충돌 및 대역폭 문제가 거의 발생하지 않으므로 일반적으로 신중한 스캐너에 권장됩니다. 버전 감지를 생략하는 것은 이러한 문제를 줄이기 위해 타이밍 값을 사용하는 것보다 훨씬 더 효과적입니다.
답변3
(verbose) 를 사용하여 nmap을 실행하면 -v속도가 저하되는 이유를 파악하는 데 도움이 됩니다.
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 아래에 나타나지 않는 것 같습니다.