Re: RE: Discovering network subnets

[hannibal blog <hannibalsec () gmail com>]

hello

thanks for fixing some adressing notions I began to forget.

Finally, it appeared it's a /24 network (X.X.X.0 and X.X.X.255 can't
be hosts). I'm in the broadcast domain, and thanks to (or because of)
CDP (Cisco discovery protocol), I got many informations on routers and
networks.

The output I posted seems to be my testing machine scan although my IP
adress was X.X.X.7, I didn't understand why. I'm using a Knoppix STD
distibution.

Here is an other scan output : nmap X.X.X.0/24 -O

Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 
Warning:  OS detection will be MUCH less reliable because we did not
find at least 1 open and 1 closed TCP port
Host X.X.X.0 seems to be a subnet broadcast address (returned 3 extra
pings).  Still scanning it due to ping response from its own IP.
Interesting ports on 0.0.0.0:
(The 1662 ports scanned but not shown below are in state: filtered)
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 00:06:28:00:00:00 (Cisco Systems)
Device type: router
Running: Cisco IOS 12.X
OS details: Cisco 3600 router running IOS 12.2(6c), Cisco router
running IOS 12.1(5)-12.2(7a), Cisco router running IOS 12.1.5-12.2.13a

Warning:  OS detection will be MUCH less reliable because we did not
find at least 1 open and 1 closed TCP port
All 1663 scanned ports on 0.0.0.4 are: filtered
MAC Address: 00:40:F4:00:00:00 (Cameo Communications)
Too many fingerprints match this host to give specific OS details

#my testing box
Interesting ports on 0.0.0.7:
(The 1661 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
68/tcp   open  dhcpclient
6000/tcp open  X11
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20
Uptime 0.028 days (since Sat Jul  2 12:50:53 2005)


Warning:  OS detection will be MUCH less reliable because we did not
find at least 1 open and 1 closed TCP port
Host 0.0.0.255 seems to be a subnet broadcast address (returned 3
extra pings).  Still scanning it due to ping response from its own IP.
Interesting ports on 0.0.0.255:
(The 1662 ports scanned but not shown below are in state: filtered)
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 00:06:28:00:00:00 (Cisco Systems)
Device type: router
Running: Cisco IOS 12.X
OS details: Cisco 3600 router running IOS 12.2(6c), Cisco router
running IOS 12.1(5)-12.2(7a), Cisco router running IOS 12.1.5-12.2.13a



Any ideas about how nmap deals with X.X.X.0 and X.X.X.225 (network and
broadcast adresses?)

2005/8/23, chad () mr-lew com <chad () mr-lew com>:
>   Let's try to clear this up a bit...
>
> If you have a network mask of 255.255.255.0 (24 bits), then
> the .0 address is your Network ID and can NOT be used as a
> host address. The .255 address will be your broadcast
> address and also can not be used as a host address. This
> makes .1 thru .254 as valid host addresses.
>
> 192.168.1.0/24 - Network ID (All Host bits are 0)
> 192.168.1.1-254 - Host Addresses
> 192.168.1.255 - Broadcast Address (All Host bits are 1)
>
>    You may see some responses from a Cisco router, not
> actually a host address, but it may respond to some of the
> ICMP probes. I am sure some other systems performing routing
> functions may do the same in some circumstances, but in my
> experience they do not answer up with SYN/ACK or RST/ACK for
> port scans.
>
> Now if you have a network mask of 255.255.254.0 (23 bits) or
> anything less than 24 bits for that matter, a .0 can and IS
> a valid host address.
>
> In the example of 10.0.0.0/23 the Network ID would be the
> first 23 bits, making it 10.0.0.0. The first available host
> would have the 32nd bit turned on, making it 10.0.0.1. The
> last available host would have bits 24 thru 31 turned on,
> with the 32nd bit turned off making it 10.0.1.254. This
> would include 10.0.1.0 as a VALID host address.
>
> Where the confusion comes from is crossing the bit boundary.
> You need to look at it in binary to see how it is just the
> next host when going from 10.0.0.255 to 10.0.1.0. Hopefully
> this diagram can help (and won't get butchered in
> delivery) ;)
>
>       1                   1
>       2 6 3 1             2 6 3 1
> 10.0. 8 4 2 6 8 4 2 | 1 . 8 4 2 6 8 4 2 1
> ----------------------------------------
>    NETWORK PORTION  |  HOST PORTION
> --.-. 0 0 0 0 0 0 0 | 0 . 0 0 0 0 0 0 0 0   Network ID
> --.-. 0 0 0 0 0 0 0 | 0 . 0 0 0 0 0 0 0 1   1st Available
> Host
> --.-. 0 0 0 0 0 0 0 | 0 . 1 1 1 1 1 1 1 1   Valid Host
> --.-. 0 0 0 0 0 0 0 | 1 . 0 0 0 0 0 0 0 0   Valid Host
> --.-. 0 0 0 0 0 0 0 | 1 . 1 1 1 1 1 1 1 0   Last Available
> Host
> --.-. 0 0 0 0 0 0 0 | 1 . 1 1 1 1 1 1 1 1   Broadcast Address
>
> Also, Classful addressing was not done away with by CIDR.
> CIDR granted us the ability to better use and
> identify/aggregate our networks. Classful addressing is
> still used today in numerous places (RIPv1 for example), but
> when possible classful addressing is normally preferred.
>
> It was pointed out that RFC 3021 outlines the specific use
> of a 31 bit mask, which would break this model if used. It
> must be pointed out that the RFC outlines this use on point-
> to-point links only. Considering that the system
> was "reported" as having ports 68/tcp, 723/tcp and 6000/tcp
> open, I would be inclined to rule against it being on a
> point-to-point link.
>
> 68/tcp - ??? Could this be some TCP based BOOTP server...
> 723/tcp - OpenMosix File System (curious)
> 6000/tcp - Probably X Windows
>
> I would try to gather some more O/S fingerprinting
> information by generating more ICMP and TCP responses
> (SYN/ACK and RST/ACK) with hping2 and then gather the
> responses with a sniffer to try and use p0f to get a better
> picture.
>
> I would be curious to hear what the final findings are...
>
>
> ------------------------------------------------------------------------------
> FREE WHITE PAPER - Wireless LAN Security: What Hackers Know That You Don't
>
> Learn the hacker's secrets that compromise wireless LANs. Secure your
> WLAN by understanding these threats, available hacking tools and proven
> countermeasures. Defend your WLAN against man-in-the-Middle attacks and
> session hijacking, denial-of-service, rogue access points, identity
> thefts and MAC spoofing. Request your complimentary white paper at:
>
> http://www.securityfocus.com/sponsor/AirDefense_pen-test_050801
> -------------------------------------------------------------------------------