7

It seems that SonicWall is blocking attemtps to scan its ports. I know it has some ports open, like 443, because if I access using the browser I get a web site. But when I try to use NMap I can't see the port open.

If I try to to a SYN scan against this port I get no-response:

# 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)

If I use a longer timeout I get a reset (edited to include --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)

But the port is open because if I use netcat I connect:

# 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

I have tried other types of NMap scans ACK, FIN, Maimon, Windows, NULL, TCP and XMAS without results.

I have algo tried to change source port to 80 using:

-g 80

What are the correct options for NMap to scan correctly this type of device? What steps could I investigate to discover them?

Improve this question
0

1 Answer 1

Reset to default
6

As far as I know, nmap in Stealth Scan mode issues a normal SYN packet, which should elicit a SYN/ACK response no matter what. The "stealthiness" comes later, when nmap receives the SYN/ACK and instead of acknowledging, tears down the connection with a RST, which prevents the connection being logged on some systems, and ensures it being logged and a We're being stealth scanned! alert triggered in others.

Try first with a vanilla connect scan: -sT instead of -sS. If that works (I don't see why it shouldn't, but then I'd have sworn -sS ought to have worked too), for one you now have "a means of scanning the system". And you can investigate how SonicWall detects the stealth SYN (I found nothing on SonicWall's docs), using something like Nemesis.

The packets are different though. The DF flag wouldn't be reliable on SonicWall's side, nor would the checksum (even if it's curious)... maybe the TCP window value is considered suspicious? Or the packet size?

The Vanilla and Telnet packets are so similar however, that if -sT does not work for you, I'd have to say that you must be doing something wrong.

Stealth Scan:

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

Ordinary 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

Vanilla scan:

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
Improve this answer
2
  • Your point about using a Vanilla scan is valid and your approximation of using a sniffer to find the differences is the answer for me. However I disagree with your affirmation that if a Vanilla scan works a SYN scan should also work. That behaviour of sending RST packets can be detected by some devices and impose a rate-limit for packets coming from the same source. Commented Apr 23, 2013 at 15:22
  • 1
    Sorry, I may have expressed myself badly. I was saying that since telnet works, then a Vanilla scan ought to work. That Vanilla might work and (Stealth) SYN might not, instead, looks like a definite possibility to me. Commented Apr 23, 2013 at 20:28

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.