Results 1 to 9 of 9

Thread: BuYS - Question on NMap (-sU -sT) Share/Save - My123World.Com!

  1. #1
    ... I am no Expert b0nd.g4h@gmail.com b0nd's Avatar
    Join Date
    Jul 2010
    Location
    irc.freenode.net #g4h
    Posts
    744

    BuYS - Question on NMap (-sU -sT)

    Ok, I take the opportunity to shoot the next one. This one also goes under NMap...

    What part of following scan would get you in pain and why?

    nmap -sU -sT -p U:1-1024,T:1-1024 -sV 192.168.1.1
    PM me if you wish to answer or just leave the msg "PASS...." if you have gone through it but do not wish to answer.

    Thanks
    [*] To follow the path: look to the master, follow the master, walk with the master, see through the master,
    ------> become the master!!! <------
    [*] Everyone has a will to WIN but very few have the will to prepare to WIN
    [*] Invest yourself in everything you do, there's fun in being serious

  2. #2
    Security Researcher fb1h2s's Avatar
    Join Date
    Jul 2010
    Location
    India
    Posts
    616
    Blog Entries
    32
    Pass

    I dont get the problem
    Hacking Is a Matter of Time Knowledge and Patience

  3. #3
    ... I am no Expert b0nd.g4h@gmail.com b0nd's Avatar
    Join Date
    Jul 2010
    Location
    irc.freenode.net #g4h
    Posts
    744
    Quote Originally Posted by fb1h2s View Post
    Pass

    I dont get the problem
    And I appreciate you for that fb1.

    Ok, so far only 2 PM's and one PASS though thread has 47 views so far.

    Hint: Focus on the timing part of scan. Prashant and Abhay, you might wish to re-think
    [*] To follow the path: look to the master, follow the master, walk with the master, see through the master,
    ------> become the master!!! <------
    [*] Everyone has a will to WIN but very few have the will to prepare to WIN
    [*] Invest yourself in everything you do, there's fun in being serious

  4. #4
    Garage Addict 41.w4r10r's Avatar
    Join Date
    Jul 2010
    Location
    Pune
    Posts
    338
    Blog Entries
    3
    Pass, dont know

  5. #5
    Super Commando Dhruv abhaythehero's Avatar
    Join Date
    Sep 2010
    Location
    Lucknow/Pune,India
    Posts
    466
    Blog Entries
    2
    Tried second time. PM Sent.
    In the world of 0s and 1s, are you a zero or The One !

  6. #6
    Garage Member
    Join Date
    Sep 2010
    Location
    Chennai
    Posts
    83
    Blog Entries
    1
    Sent u a pm b0nd!!Awaiting your reply!!

  7. #7
    ... I am no Expert b0nd.g4h@gmail.com b0nd's Avatar
    Join Date
    Jul 2010
    Location
    irc.freenode.net #g4h
    Posts
    744

    Replies and answer

    Guys, thanks for giving it a thought and taking a little pain. Your participation is always appreciable!

    By Prashant

    As far as I know, -sT and -sV seems to get us in pain for the following reasons:

    -sT :- It completes a TCP connection so will be displayed in the log file of applications when examined

    -sV :- It opens sessions with the remote applications, which will often display in an application’s log file

    This was the limited knowledge I know ! Plz correct me if I m wrong.

    Regards,
    t3rm!n4t0r

    1st Reply by Abhay (before hint was given):
    the -sT part will do full TCP handshake and hence you will be in the application log.

    the -sU part of the scan requires root privileges .

    Hence , there can be pain due to either or both !
    2nd reply by Abhay (after hint was given):
    Okay second try >>

    the -sV or version detection only uses open ports to scan for available versions. So it has to get output from another -sS , -sT , -sU etc scan ...

    -sS scan can get open ports very quickly. But UDP scan -sU thinks a port to be open if it has'nt replied by non reachable ICMP signal.
    Hence -sV has to go ahead and check a lot more ports that weren't open actually.This takes much time ( 50 secs when I scanned localhost ).Hence the pain ...
    Reply by sebas_phoenix:
    well i guess that performing a udp scan would be more consuming given the basic fact that with tcp we are guaranteed to receive 'host reachable' in case host is reachable or 'host unreachable' in case host is dead, in case the packet is lost during transmission , tcp facilitates the retransmission automatically...Consider udp, there is no way to know whether the port is closed or not since not much closed ports reply to udp requests.Also assuming the port is open , the reply may be lost . Since UDP by itself doesnt guarantee retransmission, we need to do a lit bit of overhead work or we may get a lot of false positives....
    Well, all are correct at respective place but as I emphasized on the timing issue, the real pain is running UDP scan with Version determination as correctly attempted by Abhay in second attempt.

    Most of the time the UDP result for the port scan comes as OPEN/FILTERED and the scanner would continue to do the version scan though the port could be filtered in fact. So eventually it takes hell lot of time if both the -sV and -sU parameters are used in the scan and hence not advisable to do so if the number of ports to be scanned is considerably high (in this case even the default count of 1000 ports would be too high).

    Questions/doubts are welcome.

    Following is the result when I tested against my virtual machine. Just 162 UDP ports were scanned and the time difference is noticeable.
    root@bt:~# time nmap -sU -p U:1-162 192.168.96.128

    Starting Nmap 5.35DC1 ( http://nmap.org ) at 2011-03-17 10:16 SGT
    Nmap scan report for 192.168.96.128
    Host is up (0.0059s latency).
    Not shown: 159 closed ports
    PORT STATE SERVICE
    123/udp open ntp
    137/udp open netbios-ns
    138/udp open|filtered netbios-dgm
    MAC Address: 00:0C:29:4A:FF:79 (VMware)

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

    real 0m7.204s
    user 0m0.067s
    sys 0m0.010s


    root@bt:~# time nmap -sU -p U:1-162 -sV 192.168.96.128

    Starting Nmap 5.35DC1 ( http://nmap.org ) at 2011-03-17 10:16 SGT
    Stats: 0:01:19 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan
    Service scan Timing: About 66.67% done; ETC: 10:18 (0:00:37 remaining)
    Nmap scan report for 192.168.96.128
    Host is up (0.0056s latency).
    Not shown: 159 closed ports
    PORT STATE SERVICE VERSION
    123/udp open ntp Microsoft NTP
    137/udp open netbios-ns Microsoft Windows NT netbios-ssn (workgroup: WORKGROUP)
    138/udp open|filtered netbios-dgm
    MAC Address: 00:0C:29:4A:FF:79 (VMware)
    Service Info: Host: WINDOWS-XP; OS: Windows

    Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
    Nmap done: 1 IP address (1 host up) scanned in 84.83 seconds

    real 1m24.850s
    user 0m0.150s
    sys 0m0.007s

    root@bt:~#
    PS: -sT was included just to distract attention
    [*] To follow the path: look to the master, follow the master, walk with the master, see through the master,
    ------> become the master!!! <------
    [*] Everyone has a will to WIN but very few have the will to prepare to WIN
    [*] Invest yourself in everything you do, there's fun in being serious

  8. #8
    Garage Member
    Join Date
    Sep 2010
    Location
    Chennai
    Posts
    83
    Blog Entries
    1
    @B0nd : nice one..informative...And i have a question...
    Most of the time the UDP result for the port scan comes as OPEN/FILTERED and the scanner would continue to do the version scan though the port could be filtered in fact.
    Why does it happen, eventhough most of the hosts send a Icmp_port_unreach message if the corresponding udp port is closed. Also why is udp scan not able to differentiate between open/filtered ports???

  9. #9
    ... I am no Expert b0nd.g4h@gmail.com b0nd's Avatar
    Join Date
    Jul 2010
    Location
    irc.freenode.net #g4h
    Posts
    744
    Quote Originally Posted by sebas_phoenix View Post
    @B0nd : nice one..informative...And i have a question...


    Why does it happen, eventhough most of the hosts send a Icmp_port_unreach message if the corresponding udp port is closed. Also why is udp scan not able to differentiate between open/filtered ports???
    Ok, to the best of my memory when NMap does UDP scanning, it assumes the port to be open when it doesn't receive anything in return.

    Now there could be two reasons for not receiving anything:
    1. Port is OPEN
    2. Port is Filtered by firewall and hence the packet was dropped

    So Open/filtered is the result we see.

    Beyond this, I too would need to refer the working of UDP and NMap

    Rgds
    [*] To follow the path: look to the master, follow the master, walk with the master, see through the master,
    ------> become the master!!! <------
    [*] Everyone has a will to WIN but very few have the will to prepare to WIN
    [*] Invest yourself in everything you do, there's fun in being serious

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •