Re: smurf amp nets, the registry (SAR)
On Mon, 15 Jun 1998, D'Arcy J.M. Cain wrote:
It's great that you are doing this but I'm wondering how you determine the number of responses. In particular I see that 194.157.40.0/24 gives 840 dups. That one seems to be fixed but another one, 192.127.30.0/24, is still broken but your probe shows 412 dups. Seems to me that it can't be more than 254. My own test of that network showed a response of 151. Just wondering.
What we do is basically this: ping -c4 network_address ping -c4 broadcast_address Then we log the _highest number of returned packets_ from any of the 3*2 pings we now have stored replies for. The number of _dups_ we record is this count, minus one. Some times the number of dups we see vary wildly depending on when we probe, or where you are probing from. I tend to attribute this to load on the amplifier network (perhaps someone is using them in an attack at this time), or packet-shredding international links that can't take the burst. (That is, if you and I were probing a european amplifier network, I might see slightly more dups than you since I am in Europe). Oh, and by the way! No more than 254 replies, you say. That's because you see it registered in the registry as a /24. I need to point out that there's nothing we do at this point to verify that the prefix lengths of the networks entered into the SAR are actually correct. So something listed as a /24 could be anything - you'll have to look at the actual network number to judge for yourself what it might be. We try to keep the prefix lengths longer so as not to block too much by accident (the probe defaults to /24). In some cases we see that the number of dups returned far exceed the theoretical max of the probed network. In some cases this happens because the prefix length is wrong, but in other cases i am at a loss - the hosts in the probed network actually seems to return more than one response per request. I have no idea why. We saw this with the 193.55.112.0/24 network, for instance (which has now been fixed). Oystein Homelien | oystein@powertech.no PowerTech Information Systems AS | http://www.powertech.no/ Nedre Slottsgate 5, N-0157 OSLO | tel: +47-23-010-010, fax: +47-2220-0333
On Mon, 15 Jun 1998, Oystein Homelien wrote:
the prefix length is wrong, but in other cases i am at a loss - the hosts in the probed network actually seems to return more than one response per request. I have no idea why. We saw this with the 193.55.112.0/24 network, for instance (which has now been fixed).
this could be because a) there could be a 10.0 internal LAN remapped into a normal IP space? b) on some versions of unix, when you open /dev/icmp, you will receive ALL ICMP activity received by the machine, so if your application doesn't look too closely at the pongs (response to a ping :-), it might see response to other pings occurring Paul ---- P Mansfield, Senior SysAdmin PSINet, +44-1223-577577x2611/577611 fax:577600 :r~/humour/signature :wq
On Tue, 16 Jun 1998, Paul Mansfield wrote:
On Mon, 15 Jun 1998, Oystein Homelien wrote:
the prefix length is wrong, but in other cases i am at a loss - the hosts in the probed network actually seems to return more than one response per request. I have no idea why. We saw this with the 193.55.112.0/24 network, for instance (which has now been fixed).
this could be because a) there could be a 10.0 internal LAN remapped into a normal IP space?
Actually this will happen if there's a private network on the same ethernet as a public network. For example, in Cisco parlance, the following config would do it: Ethernet0 ip address 10.0.0.1 255.255.255.0 secondary ip address 193.55.112.1 255.255.255.0 Since the broadcast to 193.55.112.255 gets sent to the all 1's MAC address, all the devices on that LAN respond, some of which are using the private IP space. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com AOL Instant Messenger: Brandon NR ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
participants (3)
-
Brandon Ross -
Oystein Homelien -
Paul Mansfield