Re: NMAP scan problems

[Brandon Enright <bmenrigh () ucsd edu>]

On Sat, 3 Mar 2007 21:12:32 +0200 (GMT+02:00)
Lord Doskias <lorddoskias () abv bg> wrote:

> Hello again, 
>
>
> I think I've got some clues on the problem. I think the isp is blocking
> all "malicious" packets - eg. packets that are not from "established"
> type of connection or that don't seem to establish real one. After all
> nmap is not using "valid" tcp/udp packets. So is there a way to force
> nmap to use valid tcp/udp packets?
>
> -----------------------------------------------------------------
> http://auto-motor-und-sport.bg/ 
> С бензин в кръвта

Nmap *does* use "valid" TCP packets for most of the scan types.  If it
didn't, it would not be able to reliably port scan.  Only the "fancier"
scans like -s[NFX] or -O[12]? use odd TCP packets to derive useful
information.

Starting in 4.01 Nmap sets the TCP MSS option to 1460 for all SYN packets.
This makes an Nmap connect look nearly identical to any other operating
system connect.  If you ISP is filtering is it probably based on a
rate-limit or a behavior detection.  Using -sT (or not running
privileged) stop Nmap from cooking it's own packets and it just uses the OS
Connect() call.

Try:

$ telnet www.google.com 80

If that works (and it should) then try:

$ nmap -sT -P0 -p 80 www.google.com

The two are functionally identical.  Nmap should report port 80 as open.

You can then start experimenting with things like:

# nmap -sS -P0 -p 80 www.google.com

or

$ nmap -sT -P0 -p 1-100 www.google.com


If you get unexpected results from any of these add a --packet-trace to the
command to see what is going on.

Brandon


-- 
Brandon Enright
Network Security Analyst
UCSD ACS/Network Operations
bmenrigh () ucsd edu

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