Re: [nsp] known networks for broadcast ping attacks
On Mon, 11 Aug 1997, some anonymous source wrote:
the program you are referring to is smurf.c which i believe was already discussed on this list.
I knew that...but I'd forgotten the name of the program.
the answer to the problem is the fact that there are hard coded broadcast addresses within the programs. the people who are taking out servers from irc are the idiots who would not know how to change these.
This may be true, but what's to stop the writers of smurf and the other programs from distributing version 2 with all new network addresses? Fixing the 119 networks used to attack FDT will help, but I doubt it will solve the problem. Here's a sorted list of the networks used to attack FDT (pulled from my 1.5mb of tcpdump data which was just a brief sample of the data from our attack Sunday. If any of them belong to you, shame on you. The really interesting ones are the 0.0.0.0 and 255.255.255.255 sources. 18:55:54.836177 0.0.0.0 > 205.229.48.20: icmp: echo reply (ttl 245, id 61586) 18:55:55.816177 255.255.255.255 > 205.229.48.20: icmp: echo reply (ttl 249, id 4 Are these just misconfigured devices on some network from the list below? I suppose for bonus points, I could write a script to get the contact addresses from as many of these as possible and email them a note about how they're being used for network attacks. 0.0.0 4.0.1 4.0.144 4.0.84 38.146.219 128.101.101 128.101.233 128.101.87 128.102.18 128.135.181 128.135.23 128.161.1 128.190.156 129.16.1 129.237.128 129.237.129 129.237.130 129.237.131 129.237.2 129.237.80 129.237.83 129.237.86 129.237.87 129.241.181 129.241.56 129.241.57 129.43.7 130.132.1 130.132.143 130.132.159 131.119.0 131.119.58 134.24.38 134.84.254 136.142.185 136.142.254 137.39.130 137.39.136 137.39.166 137.39.184 144.228.20 144.232.8 160.147.28 163.179.230 165.154.1 166.48.35 170.140.3 170.140.35 170.140.4 170.140.5 170.140.6 192.160.127 192.88.114 192.9.9 193.10.85 198.137.140 198.163.155 198.3.101 198.41.0 198.53.119 198.53.145 198.53.33 198.53.44 198.80.46 199.0.154 199.0.216 199.166.6 199.183.24 199.199.93 199.227.0 199.227.28 199.242.23 204.112.14 204.162.96 204.186.0 204.186.95 204.225.245 204.50.176 204.7.246 204.7.247 204.70.59 204.71.242 205.147.225 205.149.75 205.150.207 205.150.221 205.164.8 205.177.10 205.177.4 205.211.8 205.211.9 205.252.5 205.253.29 206.102.224 206.129.122 206.13.28 206.141.250 206.161.255 206.170.28 206.171.128 206.222.98 206.54.225 206.98.160 207.107.244 207.137.200 207.154.150 207.171.87 207.181.65 207.19.74 207.216.162 207.240.8 207.25.16 207.51.36 207.67.241 207.91.124 209.12.0 209.20.130 209.82.1 255.255.255 ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
On Tue, 12 Aug 1997, Jon Lewis wrote:
This may be true, but what's to stop the writers of smurf and the other programs from distributing version 2 with all new network addresses? Fixing the 119 networks used to attack FDT will help, but I doubt it will solve the problem.
When I type "no ip source route" on a Cisco, what exactly is that doing for me? Is it just disallowing the router itself to generate source-routed packets or is it saying sink all source-routed packets? All this talk of spoofing is getting me a bit confused. What exactly is the difference between source-routing and spoofing? Just trying to understand a bit more, Charles ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com
Charles Sprickman <spork@inch.com> wrote:
On Tue, 12 Aug 1997, Jon Lewis wrote:
This may be true, but what's to stop the writers of smurf and the other programs from distributing version 2 with all new network addresses? Fixing the 119 networks used to attack FDT will help, but I doubt it will solve the problem.
When I type "no ip source route" on a Cisco, what exactly is that doing for me? Is it just disallowing the router itself to generate source-routed packets or is it saying sink all source-routed packets? All this talk of spoofing is getting me a bit confused. What exactly is the difference between source-routing and spoofing?
Just trying to understand a bit more,
Charles
It prevents the Cisco from handling packets with source routing header options set, whether locally generated, or switched. It doesn't prevent the router generating or switching packets with invalid source addresses e.g. packets with source addresses from inside the network entering the router via an external interface - you need to apply access lists to the appropriate interfaces (in the appropriate directions) to prevent this. M.
-----BEGIN PGP SIGNED MESSAGE----- At 05:14 PM 8/12/97 +0100, you wrote:
All this talk of spoofing is getting me a bit confused. What
exactly is
the difference between source-routing and spoofing?
Just trying to understand a bit more,
Charles
[Rtr A] --------- | internet cloud | -----------[Rtr B] ------------------------- |----------[Rtr C] Spoofing: Some hacker connected to Rtr C sends a packet to Rtr B altering the packet so the source address says it came from Rtr B. If your (you are behind B) filters don't block packets from the internet coming from yourself then the hacker is into your network. Source Routing: Hacker is behind C. He finds out that you fully trust A and do no filtering for A. He sends packets to your network via Rtr A. In this case they go from C to A to B but the hacker does not have to be smart enough to alter the packets, he just sets the source route option and he is into your network. So, as protection for others you turn off source routing. As protection for yourself you setup up filters that say "deny all inbound packets coming from my network". As further protection for others you setup filters that say "deny all outbound packets that are Not from my network". If all ISPs were to do this last one then hacking would pretty much stop because hackers would be caught in a second. GK -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBM/CWpG384++etaQJAQGPuwf+KLEpMDdvboWmnnHbHcwsFEHlNCgnKYXL TZM6yZoJPx7TGC0kzm//3hDXVA2MX4gIbFsI96Bf/GBKDArzIjFGwVZHG94vV6uA V9t1szjo6VGSfnfqGdG3TIkl/3yVeHU9WGsYL8OaDRZDvQT17FO8d/xCT74igh85 FtDlMSf/vBY9K8sZb9yEvKaUXI+eIPbcUjqSEfdh3NV8L7mWiBkwWskky87PSIvl 3DpmjhDiJwjhSNslXb8p5pniLeOtp3qdvZzHAKoDfr0/XepXBFH/VQ4JRSAbuvm7 jojUK8DEJfkCvTQ9P022hvvXYAKwjqwgDaOK7R95/WKFETROakLvxg== =FIS/ -----END PGP SIGNATURE-----
participants (4)
-
Charles Sprickman -
Greg Ketell -
Jon Lewis -
Martin Cooper