Re: Destination ports in protocol scan

["Luis MartinGarcia." <luis.mgarc () gmail com>]

On 08/28/2012 03:06 PM, David Fifield wrote:
> Currently, destination ports are set to o.magic_port during protocol
> scan. o.magic_port is set by the -g or --source-port options--so it is
> actually meant to be a source port and not a destination port.
>
> o.magic_port is used as a source port throughout scan_engine.cc,
> including during protocol scan. What this means is that when -g is used,
> protocol probes have the same source and destination ports. Is there a
> reason for this? Wouldn't we be better off using random destination
> ports, or specific ports chosen to be likely to produce a response?
>
> David Fifield

Hi David,

I totally agree. In my opinion, there is no point on choosing some
random destination port number that is likely to be filtered by
middleboxes on the path. According to your "EffectivenessOfPingProbes"
doc, the most common open port is 80, so I think it would make sense to
use that.

Right now when I run a proto scan against nmap, I only get the ICMPv4
protocol.

    Nmap scan report for nmap.org (74.207.254.18)
    Host is up (0.17s latency).
    rDNS record for 74.207.254.18: web.insecure.org
    Not shown: 255 open|filtered protocols
    PROTOCOL STATE SERVICE
    1        open  icmp

    Nmap done: 1 IP address (1 host up) scanned in 41.15 seconds

However, if I change the code to set target port 80, I get TCP also.

    diff --git a/scan_engine.cc b/scan_engine.cc
    index c625eaf..0429d60 100644
    --- a/scan_engine.cc
    +++ b/scan_engine.cc
    @@ -3161,7 +3161,7 @@ static u8 *build_protoscan_packet(const struct
sockaddr_storage *src,
         case IPPROTO_TCP:
           packet = build_tcp_raw(&src_in->sin_addr, &dst_in->sin_addr,
             o.ttl, ipid, IP_TOS_DEFAULT, false, o.ipoptions,
o.ipoptionslen,
    -        sport, o.magic_port, get_random_u32(), get_random_u32(), 0,
TH_ACK, 0, 0, NULL, 0,
    +        sport, 80, get_random_u32(), get_random_u32(), 0, TH_ACK,
0, 0, NULL, 0,
             o.extra_payload, o.extra_payload_length, packetlen);
           break;
         case IPPROTO_ICMP:


    Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-08-28 20:22 CEST
    Nmap scan report for nmap.org (74.207.254.18)
    Host is up (0.17s latency).
    rDNS record for 74.207.254.18: web.insecure.org
    Not shown: 254 open|filtered protocols
    PROTOCOL STATE SERVICE
    1        open  icmp
    6        open  tcp

    Nmap done: 1 IP address (1 host up) scanned in 12.13 seconds


Another thing that could certainly be improved are the payloads for
protocols beyond ICMP, TCP, UDP and SCTP. Currently by default we are
not including any payload in the IP packets (nothing beyond the IP
network layer). At the very list, we should probably add a 20 byte
random payload. Also, it would be interesting to come up with nice
probes for protocols like EIGRP, OSPFIGP, IPv6 over IPv4, IPv4 over
IPv4, etc. These last two could offer some interesting results when
running nmap against a tunneling device. About IPv6, I am not sure if
building some proper extension headers would help, but maybe it's worth
giving it a shot.

Just my $0.02

Best regards,

Luis MartinGarcia.









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