About ten minutes after I sent this email last night I did the math and realized .64 was my broadband subnet ID. :-(
Apparently network IDs count as broadcast rows in the route table, and Charles explanation makes some sense. Sending a packet to a subnet ID "logically" is sending the packet to all machines.... (but we have a broadcast address for that...) But on the other hand we need to avoid DoS. I looked at /proc/sys/net/ipv4, and saw the file icmp_echo_ignore_broadcasts... It has a 0, but I guess the route table is set up so that you could set that to 1 and avoid Ping-of-death. (But on yet the other hand, wouldn't an attacker know that and just send to the subnet ID?) Anyhoo, while I was there I spotted icmp_ratelimit and icmp_ratemask. These files have values 100 and 6168 respectively. Couple of questions raised there: Is the icmp_ratelimit active even if you don't turn on rate limiting in Shorewall? How do I interpret the 6168? As always, thanks in advance. Rick. -----Original Message----- From: Charles Steinkuehler [mailto:[EMAIL PROTECTED] Sent: Sunday, February 27, 2005 2:32 PM To: Tibbs, Richard Cc: [email protected] Subject: Re: [leaf-user] Cannot understand route table output. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tibbs, Richard wrote: | Dear list, | I have a Bering 1.2 firewall. | I have read several man pages for ip route, and they all say ~ | " | local - the destinations are assigned to this host. The packets are | looped back and delivered locally. | | broadcast - the destinations are broadcast addresses. The packets are | sent as link broadcasts. | " | However, several lines in the output below don't make sense, | specifically: | broadcast 192.168.1.0 dev eth1 table local proto kernel scope link | src 192.168.1.254 | broadcast 216.x.y.64 dev eth0 table local proto kernel scope link | src 216.x.y.89 | broadcast 127.0.0.0 dev lo table local proto kernel scope link src | 127.0.0.1 | How are 192.168.1.0, 216.x.y.64 or 127.0.0.0 broadcast addresses? | I can ping 216.x.y.64, and I do not get bazillions of replies (a la | solaris), so it I don't think it can be a broadcast address, IMHO. | | Can anybody explain this to me? <snip> The 'unexpected' entries you're confused about are one of two special addresses for each subnet: the 'all ones' and 'all zeros' (in the host portion) IP addresses, normally reserved for the broadcast and network IP's, respectively. It looks like both of these addresses are handeled symetrically in the local route table, which generally makes sense. After all, what do you think should happen if you ping the broadcast IP for a network? What about pinging the network IP address? Also remember that there are two different kinds of "broadcasts": Link layer and IP layer. An IP layer broadcast looks like any other packet, except it has a pre-agreed-upon broadcast IP in it's header. A link layer broadcast packet is dependent on your physical networking layer, but IIRC for Ethhernet it's all one's in the MAC address field. Sending link-layer broadcast packets to subnet network and broadcast IP's really makes sense, if you think about it. Individual clients can be configured to respond or ignore traffic recieved on these IP's (see /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts on linux boxes, for example). Responses to broadcast pings is typically disabled to prevent 'amplification' used in some DoS attacks (ie: spoof a ping packet to various broadcast IPs with a source IP of the target under attack...in the "good-old-days", you'd get N responses (attack packets) for each packet you send, where N is the number of systems active on the subnet you sent the broadcast packet to), and various other forms of attack (like potentially circumventing firewall rules by sending traffic to a broadcast IP instead of the IP of the actual host). - -- Charles Steinkuehler [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCIiAbLywbqEHdNFwRAtmBAKD7e4S/mAmYDHzsi5Al4to8fGeWIACeLn0q pU7nNZF+vdrNe3AFnDbpNts= =4JEk -----END PGP SIGNATURE----- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click ------------------------------------------------------------------------ leaf-user mailing list: [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
