Re: anyone aware of this?

[kx <kxmail () gmail com>]

Mike,
  If you are on an ethernet LAN you may be able to try this technique
for scanning your own Windows machine:

http://seclists.org/nmap-dev/2006/q1/318

David Fifield and Fyodor has done some UDP payload development and
ping probe testing:

http://seclists.org/nmap-dev/2009/q2/490
http://seclists.org/nmap-dev/2009/q3/22

David and Fyodor,
  Would you still have the testing framework available to see the
performance of certain UDP probes improves when the source port
matches the dest port?

kx

On Fri, Oct 23, 2009 at 4:31 AM, mike <dmciscobgp () hotmail com> wrote:
> to all:
>
> not sure if this has ever been brought up. i have read everywhere that you cannot scan yourself via loopback on 
> windows because of the windows ip/stack anomoly. i have been testing this on my machine (XP/SP2) and have found that, 
> yes you CAN scan loopback but ONLY with a full connect() -sT scan. you will have some ports show up as filtered if 
> you set your time delay to high. if you set it to slow you will get open live ports to respond with the appropriate 
> syn-ack and the closed ports will have a "connection-refused". when packet-trace option is present, you will see 
> something along the lines of this as output:
>
> CONN (1.3400's) TCP localhost > 127.0.0.1:135 => Unknown error
>
> i am at a different machine and can't copy the full output at the moment, so i am simply showing the packet IS sent. 
> the syn-ack was received for 135 tcp being open on my scan test. like i said, not sure if this was ever made aware to 
> anyone
>
>
> also, i wanted to ask if this is next idea is either implemented now or will be in the future (is it needed?) as we 
> know, most UDP services must usually have a protocol thrown at it for us to get some data back (and mainly it has to 
> be the EXACT protocol in many cases). there are services such as IPSEC and RIP that will only speak to you if the 
> source port is the same as the destination. does nmap allow for this as a default behavior for it's scanning 
> technique? if not, does anyone agree this should be added? why not just have the default behavior for nmap (at least 
> when it comes to a UDP scan) simply set the source port to match the destination? at least then, when pushing data, 
> you will at least be adherring to the rules these ports speak and are looking for. this would be almost a guarantee 
> of us getting something back. i understand we have scripts in place, but that is mainly after-the-fact. i want to be 
> able to set out a simple scan and have my source ports match whateve
>  r destination i am probing. if not in making this a full feature static wise, someone should at least allow the 
> option to be present to users, i feel
>
> thank you for hearing my thoughts
>
>
> m|ke
>
> _________________________________________________________________
> New Windows 7: Find the right PC for you. Learn more.
> http://www.microsoft.com/windows/pc-scout/default.aspx?CBID=wl&ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_pcscout:102009
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/