Re: Trace and reality differs

["Hans Nilsson" <hasse_gg () ftml net>]

OK, you are right of course, I didn't think it through but I understand
now. Of course my computer can't send the packets without doing an ARP
request (or knowing the MAC statically). And nmap can really only show
what it passes to the operation system and not what the operating system
does with it.

Perhaps there could be a static ARP option in nmap so you could sniff
the network for one day collecting ARP and IP combinations and then pass
that to nmap in a file.

Or there could be a "monitor scan" where nmap listens to the network
traffic and initiates a scan against targets (targets that are in your
scope) that reveal themselves by sending traffic. That way nmap wouldn't
have to scan hosts that aren't up like with the static ARP method. You
could interactively abort the scan at an arbitrary time because it's
unlikely that all the targets in your scope will be sending network
traffic.


Anyways I tried your idea, I didn't add the MAC to the adress table but
I used the Nemesis tool to edit and send a previous nmap packet that was
sent.

So I set the destination MAC to be the broadcast adress
(FF:FF:FF:FF:FF:FF) and interestingly the (open) port that previously
replied with a syn/ack from a regular nmap scan now replied with a
rst/ack (often I got first a rst/ack and then also a syn/ack). A closed
port that previously responded with fin/rst/ack now also responded with
a fin/rst/ack.

So that might be worth looking into deeper. If you could specify custom
MAC/IP pairs to nmap you could have the option to use a wildcard like "*
FF:FF:FF:FF:FF:FF" so you'd never have to make ARP-requests and also you
could perhaps find strange settings like computers with ARP turned off.


If someone wants to experiment I did this with nemesis:
nemesis ethernet -d eth0 -H aa:bb:cc:dd:ee:ff -M FF:FF:FF:FF:FF:FF -P
pac.bin -T 2048

Where aa:bb:cc:dd:ee:ff is your MAC (or whatever if you want to try and
spoof). The pac.bin file is a standard syn-scan packet that I sniffed
from nmap but I had to remove the ethernet portion of the packet, that
is the first 14 bytes. Because AFAIK nemesis can not accept a complete
packet and send, you have to manually specify at least one level, in
this case the ethernet level.

Anyways thanks for your response
/Hans

On Fri, 16 Jan 2009 00:41:05 -0800, "Fyodor" <fyodor () insecure org> said:
> On Thu, Jan 15, 2009 at 08:49:40PM -1100, Hans Nilsson wrote:
> > Hello, I was just trying a scan as follows:
> > nmap --send-ip -oA log -T2 -sS -n -P0 --randomize-hosts -p 139
> > 231.211.XXX.122-124 --max-retries 0 -vvvvv --packet-trace
> >
> > (on a local network with the latest stable version)
> > Now the output nmap gives me claims that it sends three syn packets to
> > port 139 but according to my packet sniffing nmap still does it's
> > arp-ping and only scans the host that replies to it. The reason I used
> > --send-ip is because I don't want to use the ARP-ping,
>
> With your command, Nmap is no longer doing the ARP ping.  Nmap just
> hands the IP packet to your OS to send because you requested
> --send-ip.  Then Nmap prints that packet in the packet trace logs.
> But your OS still needs to do an ARP request because it can't send a
> packet to the target without a destination MAC address.  Since the
> target is down or otherwise not responding to the ARP request, your OS
> can't send the packet.
>
> If you really want the packets to be sent, you can try adding a static
> entry to your system ARP table.  Maybe you can even get away with
> adding a broadcast MAC address to the table (I don't know if that
> works).
>
> > to work like that. And anyways the claimed packet trace I'm getting from
> > nmap doesn't fit with reality.
>
> The Nmap packet trace only shows the packets Nmap sends or delivers to
> the OS as well as the packets it receives.  Since packets can be
> dropped or blocked at various points along their path, sniffer results
> at any given point may differ.  So sniffing is definitely still useful
> in addition to Nmap's --packet-trace when trying to figure out what is
> really going on.
>
> Cheers,
> -F
-- 
  Hans Nilsson
  hasse_gg () ftml net

-- 
http://www.fastmail.fm - IMAP accessible web-mail


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org