Re: Windows 7

[Christian Savalas <csavalas () gmail com>]

Hi Rob,

Nice to hear from you again. Btw, you had a good point, that the -e
switch is unnecessary with -sT... overlooked the redundancy. Anyway,
I'll try to speak to each of your presumptions. When iflist is run
while connected wirelessly, the result is this:

************************INTERFACES************************
DEV   (SHORT) IP/MASK           TYPE        UP   MTU  MAC
eth0  (eth0)  (null)/0          ethernet    down 0    00:00:00:00:00:00
eth1  (eth1)  (null)/0          ethernet    up   1500 8C:F5:20:52:41:53
eth2  (eth2)  (null)/0          ethernet    up   1500 8C:F5:20:52:41:53
eth3  (eth3)  (null)/0          ethernet    down 1500 00:26:B9:CF:50:5F
eth4  (eth4)  (null)/0          ethernet    down 1500 00:26:B9:CF:50:5F
eth5  (eth5)  (null)/0          ethernet    up   1500 8C:F5:20:52:41:53
eth6  (eth6)  (null)/0          ethernet    up   1500 8C:F5:20:52:41:53
eth7  (eth7)  (null)/0          ethernet    down 1500 00:26:B9:CF:50:5F
eth8  (eth8)  (null)/0          ethernet    up   1500 8C:F5:20:52:41:53
eth9  (eth9)  (null)/0          ethernet    up   1500 8C:F5:20:52:41:53
eth10 (eth10) 169.254.89.175/16 ethernet    up   1500 00:50:56:C0:00:01
eth11 (eth11) 169.254.176.88/16 ethernet    up   1500 00:50:56:C0:00:08
eth12 (eth12) (null)/0          ethernet    down 1500 F0:7B:CB:8F:71:B7
eth13 (eth13) (null)/0          ethernet    down 1500 F0:7B:CB:8F:71:B7
eth14 (eth14) (null)/0          ethernet    down 1500 F0:7B:CB:8F:71:B7
eth15 (eth15) (null)/0          ethernet    down 0    00:02:76:1E:E4:F6
ppp0  (ppp0)  (null)/0          other       up   1494
ppp1  (ppp1)  (null)/0          other       down 0
lo0   (lo0)   127.0.0.1/8       loopback    up   1500
eth16 (eth16) 192.168.1.133/24  ethernet    up   1500 F0:7B:CB:8F:71:B7
eth17 (eth17) (null)/0          ethernet    up   1500 F0:7B:CB:8F:71:B7
eth18 (eth18) (null)/0          ethernet    up   1500 F0:7B:CB:8F:71:B7
eth19 (eth19) (null)/0          ethernet    up   1500 F0:7B:CB:8F:71:B7
eth20 (eth20) (null)/0          ethernet    up   1500 F0:7B:CB:8F:71:B7
eth0  (eth0)  (null)/0          point2point up   4091
eth1  (eth1)  (null)/0          point2point down 1480
eth2  (eth2)  (null)/0          point2point up   1460
eth3  (eth3)  (null)/0          point2point up   1464
eth4  (eth4)  (null)/0          point2point down 1280
eth5  (eth5)  (null)/0          point2point down 1280
eth6  (eth6)  (null)/0          point2point down 1280
eth7  (eth7)  (null)/0          point2point down 1280


To me, this indicates that eth16 would be the correct adapter. The
story gets even more interesting when you factor in Wireshark's
behavior. While I know getting promiscuous mode to work with a factory
installed wireless card is a pipe dream, I have confirmed that
wireless packet capturing on my own wireless card with Wireshark DOES
indeed work with all other traffic, except for Nmap traffic (without
-sT). Does this point to a problem with Nmap->Winpcap interaction? The
last weirdness I can add to the mystery is that although Wireshark
flawlessly detects non-promiscuous traffic relevant to my wireless
interface, Wireshark shows the wireless interface name as "Microsoft",
whereas my ethernet controller shows up more normally as "Atheros L1C
etc...".

To be continued, I suppose...

Christo

On Fri, Feb 4, 2011 at 1:34 PM, Rob Nicholls <robert () robnicholls co uk> wrote:
> Hi Christo,
>
> I'm glad you had more luck with wired!
>
> WinPcap on Windows has quite a few limitations, so it's possible that this
> is why you're having less success using the wireless interface. The WinPcap
> FAQ states:
>
> Wireless adapters: these adapters may present problems, because they are not
> properly supported by the Windows Kernel. Some of them are not detected,
> other don't support promiscuous mode. In the best case, WinPcap is able to
> see an Ethernet emulation and not the real transiting packets: this means
> that the 802.11 frames are transformed into fake Ethernet frames before
> being captured, and that control frames are not received
>
> When you use -sT you're performing a Connect scan, and on Windows this uses
> the native operating system to send them (if you use --unprivileged it'll
> only use the OS to do the scans, which prevents many Nmap features from
> working properly) so Nmap doesn't have to work out which interface to use as
> it doesn't use WinPcap to send the packets (and this is why -e isn't
> necessary here).
>
> If you do a --packet-trace you'll see the difference in Nmap's output
> between a SYN scan using WinPcap (lots of details about flags and ids) and a
> Connect scan through the OS (it pretty much just says "Operation now in
> progress"). The fact -sT works for you suggests to me that the problem is
> related to WinPcap or your wireless card, although it's possible that Nmap
> is failing to detect your wireless device properly. I suspect you don't need
> to use -Pn when doing a Connect scan with the wireless card.
>
> I assume eth16 appeared to correspond with your wireless card when you ran
> "nmap --iflist"? Did you happen to spot any other interfaces that had
> something like <none> against the WINDEVICE? There have been issues in the
> past where the wrong interface was determined, or the correct interface
> couldn't be correctly tied to the right WINDEVICE, but David's solved most
> of these problems.
>
> I couldn't quickly spot any traffic sent to scanme.nmap.org, so either you
> weren't capturing from the right network adaptor or (much more likely) the
> packets were never sent by Nmap/WinPcap using that adaptor (it's possible
> they were sent to another adaptor, that might not exist/show up in
> Wireshark).
>
> Rob
>
> -----Original Message-----
> From: Christian Savalas [mailto:csavalas () gmail com]
> Sent: 04 February 2011 20:22
> To: Rob Nicholls
> Subject: Re: Windows 7
>
> Hi again,
>
> It's really ironic that after a year of tooling with this I would discover
> new information a few minutes after finally sendig you guys a message! After
> I hit send, I realized I hadn't tried it on a wired ethernet connection for
> two revisions. Lo and Behold, it works...
> Cool! And on the wireless side, I discovered that the addition of the -sT
> switch with -Pn does indeed produce the expected results, but I may as well
> use Superscanner for that ;)
>
> I should have mentioned in my first message that all other Windows net tools
> like ping, tracert work just fine on any address, using the wireless
> interface. And I have indeed visited scanme.nmap.org with a browser.
>
> What's odd is that nmap works fully with ethernet, only partially (tcpip.sys
> style -sT) with wireless. Does this point to the winpcap library? I would
> think so, but then again, Wireshark appears to capture packets.
>
> I got excited about your suggestion to specify the interface explicitly, but
> then I remembered what I discovered about the scan working with the -sT
> switch, with no explicit selection of interface.
> Needless to say, I did try it, with no different results.
>
> The command:
>
> "nmap -d -Pn -e eth16 scanme.nmap.org"
>
> yields the resulting output:
>
> ---------------------------------
> ---------------------------------
>
> Winpcap present, dynamic linked to: WinPcap version 4.1.2 (packet.dll
> version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b
> (20091008)
>
>
>
> Starting Nmap 5.50 ( http://nmap.org ) at 2011-02-04 11:50 Pacific Standard
> Time
>
> PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0)
>
> --------------- Timing report ---------------
>
>  hostgroups: min 1, max 100000
>
>  rtt-timeouts: init 1000, min 100, max 10000
>
>  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>
>  parallelism: min 0, max 0
>
>  max-retries: 10, host-timeout: 0
>
>  min-rate: 0, max-rate: 0
>
> ---------------------------------------------
>
> mass_rdns: Using DNS server 192.168.1.1
>
> mass_rdns: Using DNS server 192.168.1.1
>
> mass_rdns: Using DNS server 192.168.1.1
>
> Initiating Parallel DNS resolution of 1 host. at 11:50
>
> mass_rdns: 0.02s 0/1 [#: 3, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1]
>
> Completed Parallel DNS resolution of 1 host. at 11:50, 0.01s elapsed
>
> DNS resolution of 1 IPs took 0.02s. Mode: Async [#: 3, OK: 1, NX: 0,
> DR: 0, SF: 0, TR: 1, CN: 0]
>
> Initiating SYN Stealth Scan at 11:50
>
> Scanning scanme.nmap.org (64.13.134.52) [1000 ports]
>
> Packet capture filter (device eth16): dst host 192.168.1.133 and (icmp or
> ((tcp or udp or sctp) and (src host 64.13.134.52)))
>
> SYN Stealth Scan Timing: About 14.50% done; ETC: 11:53 (0:03:03 remaining)
>
> SYN Stealth Scan Timing: About 29.50% done; ETC: 11:53 (0:02:26 remaining)
>
>
> "
> "
>
>
> Completed SYN Stealth Scan at 11:53, 203.00s elapsed (1000 total ports)
>
> Overall sending rates: 9.85 packets / s, 433.50 bytes / s.
>
> Nmap scan report for scanme.nmap.org (64.13.134.52)
>
> Host is up, received user-set.
>
> All 1000 scanned ports on scanme.nmap.org (64.13.134.52) are filtered
> because of 1000 no-responses
>
>
>
> Read from C:\Program Files (x86)\Nmap: nmap-payloads nmap-services.
>
> Nmap done: 1 IP address (1 host up) scanned in 203.38 seconds
>
>           Raw packets sent: 2000 (88.000KB) | Rcvd: 0 (0B)
>
> ---------------------------------
> ---------------------------------
>
>
>
>
> As you can see, the host is declared up, with no open ports. And now with
> -Pn removed from the command (nmap -d -e eth16 scanme.nmap.org), I am left
> with this:
>
>
>
> ---------------------------------
> ---------------------------------
>
> Winpcap present, dynamic linked to: WinPcap version 4.1.2 (packet.dll
> version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b
> (20091008)
>
>
>
> Starting Nmap 5.50 ( http://nmap.org ) at 2011-02-04 11:56 Pacific Standard
> Time
>
> PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0)
>
> --------------- Timing report ---------------
>
>  hostgroups: min 1, max 100000
>
>  rtt-timeouts: init 1000, min 100, max 10000
>
>  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>
>  parallelism: min 0, max 0
>
>  max-retries: 10, host-timeout: 0
>
>  min-rate: 0, max-rate: 0
>
> ---------------------------------------------
>
> Initiating Ping Scan at 11:56
>
> Scanning scanme.nmap.org (64.13.134.52) [4 ports]
>
> Packet capture filter (device eth16): dst host 192.168.1.133 and (icmp or
> ((tcp or udp or sctp) and (src host 64.13.134.52)))
>
> Completed Ping Scan at 11:56, 4.39s elapsed (1 total hosts)
>
> Overall sending rates: 1.82 packets / s, 69.28 bytes / s.
>
> mass_rdns: Using DNS server 192.168.1.1
>
> mass_rdns: Using DNS server 192.168.1.1
>
> mass_rdns: Using DNS server 192.168.1.1
>
> Nmap scan report for scanme.nmap.org (64.13.134.52) [host down, received
> no-response]
>
> Read from C:\Program Files (x86)\Nmap: nmap-payloads nmap-services.
>
> Note: Host seems down. If it is really up, but blocking our ping probes, try
> -Pn
>
> Nmap done: 1 IP address (0 hosts up) scanned in 4.75 seconds
>
>           Raw packets sent: 8 (304B) | Rcvd: 0 (0B)
>
> ---------------------------------
> ---------------------------------
>
>
> So strange, because the output seems to have resolved the domain to the ip
> 64.13.134.52, and, beyond that, "ping" works from the command prompt.
>
> Lastly, I have tried capturing packets with Wireshark while running the scan
> with AND without -Pn, but I am by no means an expert on packet analysing. I
> attached the two logs for you, just in case it would help. From my untrained
> eye, I honestly don't see any NMap traffic.
>
> I sincerely appreciate you getting back to me so soon, and I hope to hear
> from you with good news!
>
> All the best,
>
> Christo
>
> On Fri, Feb 4, 2011 at 1:58 AM, Rob Nicholls <robert () robnicholls co uk>
> wrote:
> > Hi Christo
> >
> > On Fri, 4 Feb 2011 01:01:18 -0800, Christian Savalas wrote:
> > > Despite this, regardless of which address I scan, (even
> > > scanme.nmap.org) I am told that 0  hosts are up.
> >
> > If you add -Pn to the Nmap commands you're running, Nmap will assume
> > the host is up and should attempt to scan the host.
> >
> > Are you able to use Windows' built in "ping" utility to ping a remote
> > host over the internet? e.g.
> >
> > > ping scanme.nmap.org
> >
> > Pinging scanme.nmap.org [64.13.134.52] with 32 bytes of data:
> > Reply from 64.13.134.52: bytes=32 time=145ms TTL=50 Reply from
> > 64.13.134.52: bytes=32 time=145ms TTL=50 Reply from 64.13.134.52:
> > bytes=32 time=145ms TTL=50 Reply from 64.13.134.52: bytes=32
> > time=145ms TTL=50
> >
> > This is one of the checks that Nmap tries to determine if a host is
> > up. If you don't get a response then it's possible that your ISP is
> > filtering ICMP traffic.
> >
> > Are you able to view http://scanme.nmap.org using your browser? You
> > should get a white page with a message from Fyodor in black text. If
> > you can see this, then you can access port 80/TCP. This is another
> > port that Nmap will try in order to determine whether a host is up. If
> > you can't see the web page then something bad is happening.
> >
> > Have you tried running Wireshark at the same time as an Nmap scan?
> > This would let you see if packets are sent from or returned to your
> > host. I'd be surprised if Nmap is failing to identify the returned
> > packets, but this might happen if you have teamed NICs, for example.
> >
> > If you add -d to the Nmap command you'll see some debug information,
> > including a line like:
> >
> > Packet capture filter (device eth7): dst host xx.xx.xx.xx and (icmp or
> > ((tcp or udp or sctp) and (src host xx.xx.xx.xx)))
> >
> > If you run "nmap --iflist" you should see a list of interfaces (and
> routes).
> > It's possible that the correct NIC isn't picked up by Nmap and it's
> > trying to send packets over the wrong interface (and getting nothing
> > back). You can use -e to state the correct interface to use, e.g.
> >
> > > nmap scanme.nmap.org -e eth7
> >
> > Starting Nmap 5.51SVN ( http://nmap.org ) at 2011-02-04 09:57 GMT
> > Standard Time Nmap scan report for scanme.nmap.org (64.13.134.52) Host
> > is up (0.15s latency).
> > Not shown: 993 filtered ports
> > PORT      STATE  SERVICE
> > 22/tcp    open   ssh
> > 25/tcp    closed smtp
> > 53/tcp    open   domain
> > 70/tcp    closed gopher
> > 80/tcp    open   http
> > 113/tcp   closed auth
> > 31337/tcp closed Elite
> >
> > Nmap done: 1 IP address (1 host up) scanned in 10.00 seconds
> >
> >
> > Rob
>
>
>
> --
> Christian Savalas
> Marina Pointe Tech Support
> 13600 Marina Pointe Drive
> Marina Del Rey, CA 90292
> +1 (310) 343-2000 (cell)



-- 
Christian Savalas
Marina Pointe Tech Support
13600 Marina Pointe Drive
Marina Del Rey, CA 90292
+1 (310) 343-2000 (cell)
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/