web-dev-qa-db-ja.com

NMapを使用して、すべての試行をブロックしているSonicWallをポートスキャンする方法

SonicWallがポートをスキャンする試みをブロックしているようです。 443のようにいくつかのポートが開いていることはわかっています。ブラウザを使用してアクセスすると、Webサイトが表示されるからです。しかし、NMapを使おうとすると、ポートが開いているのが見えません。

このポートに対してSYNスキャンを行おうとすると、応答がありません。

# nmap -sS -vvv -PN -p443 --reason XXX.XXX.XXX.XXX

Starting Nmap 5.00 ( http://nmap.org ) at 2013-04-22 08:31 CEST
NSE: Loaded 0 scripts for scanning.
Initiating Parallel DNS resolution of 1 Host. at 08:31
Completed Parallel DNS resolution of 1 Host. at 08:31, 0.05s elapsed
DNS resolution of 1 IPs took 0.06s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0, SF: 0, TR: 1, CN: 0]
Initiating SYN Stealth Scan at 08:31
Scanning XXX.XXX.XXX.XXX [1 port]
Completed SYN Stealth Scan at 08:31, 2.01s elapsed (1 total ports)
Host XXX.XXX.XXX.XXX is up, received user-set.
Scanned at 2013-04-22 08:31:35 CEST for 2s
Interesting ports on XXX.XXX.XXX.XXX:
PORT    STATE    SERVICE REASON
443/tcp filtered https   no-response

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 Host up) scanned in 2.15 seconds
       Raw packets sent: 2 (88B) | Rcvd: 0 (0B)

より長いタイムアウトを使用すると、リセットが発生します(-packet-traceを含むように編集

# nmap -sS -vvv -PN -p443 --min-rtt-timeout 30s --packet-trace --reason XXX.XXX.XXX.222

Starting Nmap 5.00 ( http://nmap.org ) at 2013-04-22 10:01 CEST
NSE: Loaded 0 scripts for scanning.
NSOCK (0.0810s) UDP connection requested to XXX.XXX.XXX.111:53 (IOD #1) EID 8
NSOCK (0.0810s) Read request from IOD #1 [XXX.XXX.XXX.111:53] (timeout: -1ms) EID 18
Initiating Parallel DNS resolution of 1 Host. at 10:01
NSOCK (0.0810s) Write request for 45 bytes to IOD #1 EID 27     [XXX.XXX.XXX.111:53]: Y............222.XXX.XXX.XXX.in-addr.arpa.....
NSOCK (0.0810s) nsock_loop() started (timeout=500ms). 3 events pending
NSOCK (0.0810s) Callback: CONNECT SUCCESS for EID 8 [XXX.XXX.XXX.111:53]
NSOCK (0.0810s) Callback: WRITE SUCCESS for EID 27 [XXX.XXX.XXX.111:53]
NSOCK (0.1280s) Callback: READ SUCCESS for EID 18 [XXX.XXX.XXX.111:53] (105 bytes)
NSOCK (0.1280s) Read request from IOD #1 [XXX.XXX.XXX.111:53] (timeout: -1ms) EID 34
Completed Parallel DNS resolution of 1 Host. at 10:01, 0.05s elapsed
DNS resolution of 1 IPs took 0.05s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0, SF: 0, TR: 1, CN: 0]
Initiating SYN Stealth Scan at 10:01
Scanning XXX.XXX.XXX.222 [1 port]
SENT (0.1370s) TCP XXX.XXX.XXX.333:44390 > XXX.XXX.XXX.222:443 S ttl=53 id=3162 iplen=44  seq=1146988289 win=2048 <mss 1460>
RCVD (21.1530s) TCP XXX.XXX.XXX.222:443 > XXX.XXX.XXX.333:44390 RA ttl=128 id=23009 iplen=40  seq=1292449307 win=64240 ack=1146988290 
Completed SYN Stealth Scan at 10:01, 21.02s elapsed (1 total ports)
Host XXX.XXX.XXX.222 is up, received user-set (21s latency).
Scanned at 2013-04-22 10:01:10 CEST for 21s
Interesting ports on XXX.XXX.XXX.222:
PORT    STATE  SERVICE REASON
443/tcp closed https   reset

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 Host up) scanned in 21.15 seconds
       Raw packets sent: 1 (44B) | Rcvd: 1 (40B)

しかし、netcatを使用する場合は接続するため、ポートは開いています。

# nc XXX.XXX.XXX.XXX 443
HEAD / HTTP/1.0

(UNKNOWN) [XXX.XXX.XXX.XXX] 443 (https) : Connection timed out
HEAD / HTTP/1.0
200 OK
Content-Length: 860
Content-Type: text/html
Last-Modified: Tue, 22 Nov 2011 07:45:36 GMT
Client-Date: Mon, 22 Apr 2013 06:34:56 GMT

200 OK
Connection: close
Date: Mon, 22 Apr 2013 06:40:31 GMT
Server: Apache-Coyote/1.1
Content-Length: 1166
Content-Type: text/html
Client-Date: Mon, 22 Apr 2013 06:34:57 GMT
Client-Peer: XXX.XXX.XXX.XXX:80
Client-Response-Num: 1

他のタイプのNMapスキャンACK、FIN、Maimon、Windows、NULL、TCPおよびXMASを結果なしで試しました。

私はアルゴを使ってソースポートを80に変更しようとしました:

-g 80

このタイプのデバイスを正しくスキャンするためのNMapの正しいオプションは何ですか?それらを発見するためにどのようなステップを調査できますか?

7
kinunt

私の知る限り、ステルススキャンモードのnmapは通常のSYNパケットを発行します。これは、何があってもSYN/ACK応答を引き出すはずです。 「ステルス性」は後で発生し、nmapがSYN/ACKを受信すると、確認応答ではなくRSTとの接続を切断します。これにより、一部のシステムで接続がログに記録されなくなり、ログに記録されます。 ステルススキャン中です!他のユーザーでアラートがトリガーされました。

まず、バニラ接続スキャンを試してください:-sT の代わりに -sSthatが機能する場合(機能しない理由はわかりませんが、-sSも機能するはずでした)、今では「システムをスキャンする手段」があります。また、 Nemesis のようなものを使用して、SonicWallがステルスSYNをどのように検出するかを調査できます(SonicWallのドキュメントには何も見つかりませんでした)。

パケットareでも違います。 DFフラグは、SonicWall側では信頼できませんし、チェックサムも(好奇心が強いとしても)信頼できません...多分TCPウィンドウ値が考慮されます疑わしい?それともパケットサイズ?

ただし、VanillaパケットとTelnetパケットは非常に似ているため、-sTはあなたのために機能しません、私はあなたが何か間違ったことをしているに違いないと言う必要があります。

ステルススキャン:

09:20:46.808358 IP (tos 0x0, ttl 41, id 24165, offset 0, flags [none], proto TCP (6), length 44)
    mintaka.33810 > darkstar.77: Flags [S], cksum 0x40ee (correct), seq 3935459869, win 1024, options [mss 1460], length 0
        0x0000:  4500 002c 5e65 0000 2906 a93e c0a8 04c8
        0x0010:  c0a8 0410 8412 004d ea92 5a1d 0000 0000
        0x0020:  6002 0400 40ee 0000 0204 05b4

通常のtelnet:

09:21:14.865468 IP (tos 0x10, ttl 64, id 58002, offset 0, flags [DF], proto TCP (6), length 60)
    mintaka.50911 > darkstar.77: Flags [S], cksum 0x8a57 (incorrect -> 0x9259), seq 331969772, win 14600, options [mss 1460,sackOK,TS val 202741374 ecr 0,nop,wscale 7], length 0
        0x0000:  4510 003c e292 4000 4006 cdf0 c0a8 04c8
        0x0010:  c0a8 0410 c6df 004d 13c9 74ec 0000 0000
        0x0020:  a002 3908 8a57 0000 0204 05b4 0402 080a
        0x0030:  0c15 967e 0000 0000 0103 0307

バニラスキャン:

09:22:25.447135 IP (tos 0x0, ttl 64, id 57087, offset 0, flags [DF], proto TCP (6), length 60)
    mintaka.50912 > darkstar.77: Flags [S], cksum 0x8a57 (incorrect -> 0x8c7e), seq 1141769620, win 14600, options [mss 1460,sackOK,TS val 202759019 ecr 0,nop,wscale 7], length 0
        0x0000:  4500 003c deff 4000 4006 d193 c0a8 04c8
        0x0010:  c0a8 0410 c6e0 004d 440e 0594 0000 0000
        0x0020:  a002 3908 8a57 0000 0204 05b4 0402 080a
        0x0030:  0c15 db6b 0000 0000 0103 0307
6
LSerni