ÜberhackerII, Chapter 9: Ethernet Exploration,
continued...
On the other hand, some networks are set up carelessly. They
will let you broadcast ping them from the outside, which causes
all the computers on that LAN to return your pings out to the
Internet - amplifying each of your broadcast pings by the total
number of responding computers. If you spoof your IP address to
be that of some victim computer, this flood of returning pings
might crash the victim. In the chapter on denial of service attacks,
you will learn more about these so-called "smurf amplifiers."
We'll find out whether our guesses about broadcast addresses
are good by trying to use these to map all the IP addresses and
Ethernet devices on a LAN:
~ > ping -c 2 207.66.999.255
PING 207.66.999.255 (207.66.999.255): 56 data bytes
--- 207.66.999.255 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
Looks like this test failed. "100% packet loss." So
what do I do? Email Carolyn Meinel to ask her why it didn't work?
Hey, I'm Carolyn Meinel! OK, (working in this case with Sun OS
4.1) I'll try giving this command:
~> ping -c 5 207.66.999.255
This causes it to send five broadcast packets instead of one,
giving it a better chance to work. No good. All five pings go
to bit heaven. OK, next I set the broadcast address to 207.66.255.255.
That doesn't work, either.
This probably means these IP addresses are not physically located
on the same LAN with my shell account. Or they could be isolated
from returning my broadcast pings by an Ethernet switch (a good
defense against hackers). So I try the next prospect for a broadcast
address, setting it to send two packets:
~> ping -c 2 198.59.255.255
PING 198.59.255.255 (198.59.255.255): 56 data bytes
64 bytes from 198.59.212.141: icmp_seq=1 ttl=238 time=275 ms
--- 198.59.255.255 ping statistics ---
2 packets transmitted, 1 packets received, 50% packet loss
round-trip min/avg/max = 64/275/275 ms
This time we only got one computer to talk back. If we didn't
know about the arp (Address Resolution Protocol) program, we would
still be in the dark. (Actually, with this LAN sometimes I get
lots of pings back and other times I get very few.) However, by
next using arp, we get:
~> arp -a
sks.foobar.com (198.59.999.33) at 0:10:4b:28:56:a5
omen.foobar.com (198.59.999.66) at 0:80:ad:72:23:15
chevy.foobar.com (198.59.999.18) at 0:20:af:32:97:b9
oro.foobar.com (198.59.999.19) at 0:c0:5:1:34:c7
news.foobar.com (198.59.999.244) at 8:0:20:23:2:a5
dragon.foobar.com (198.59.999.4) at 8:0:20:21:cd:74
cobra.foobar.com (198.59.999.245) at 8:0:20:d:71:5
chili.foobar.com (198.59.999.6) at 8:0:20:22:d8:d3
buick.foobar.com (198.59.999.246) at 0:20:af:32:97:b8
nash.foobar.com (198.59.999.247) at 0:5:2:80:a7:3b
rio.foobar.com (198.59.999.8) at 0:c0:5:1:c:35
bolo.foobar.com (198.59.999.248) at 0:c0:5:1:8b:62
zia.foobar.com (198.59.999.9) at 0:c0:5:1:10:83
? (198.59.999.105) at 0:c0:5:1:4c:17
admin.foobar.com (198.59.999.250) at 8:0:20:1d:62:d1
oso.foobar.com (198.59.999.10) at 0:c0:5:1:4c:17
olds.foobar.com (198.59.999.26) at 0:40:5:61:d0:b3
puerta.foobar.com (198.59.999.11) at 0:c0:5:1:10:7e
bofh.foosite.org (198.59.999.251) at 0:60:67:9:1b:11
mail.fulakos.com (198.59.999.107) at 0:c0:5:1:c:35
poqito.foobar.com (198.59.999.12) at 8:0:20:c:29:43
mail.foosite.com (198.59.999.108) at 0:c0:5:1:8b:62
kcam.foobar.com (198.59.999.28) at 8:0:20:1d:74:29
poco.foobar.com (198.59.999.13) at 8:0:20:1a:55:88
Fu-gwy.foobar.com (198.59.999.254) at 0:0:c:3:f0:c1
tessa.foobar.com (198.59.999.63) at (incomplete)
taco.foobar.com (198.59.999.15) at 0:60:8:2e:bf:db
If you get this to scroll up your screen, you will probably be
cheering and clapping your hands just like I did. Hmm, I think
I'll email the sysadmins at this ISP and suggest that they disable
the arp command for ordinary users. This gives out a gold mine
of information that the wrong person could misuse. (Note: they
did disable it.)
Why not just give the arp -a command without doing a broadcast
ping first? By using the broadcast first you get the network talking.
That puts all the live hosts into the arp table on your computer.
The problem is, the arp table will drop the record of a host on
its LAN if a certain amount of time goes by without any traffic
going to or from that computer. With the broadcast ping you get
the computers talking and that puts them into the arp table.
Klemencic says, "Another way to determine your netmask is
to look at the routing table on your computer. On Windows, issue
the route print and look a link that has your IP address as the
gateway and a Network Destination that corresponds to that of
your IP address as the Network Destination. You should find the
netmask defined properly in this table, providing the network
admins are not doing something tricky like splitting your netmask
logically out of a bigger netmask on the router. Also, on Unix,
issue the command netstat -rn to get similar output. However,
in the Unix output, simply find the network number that corresponds
to your IP address and read the mask from the Genmask field."
More --->>
