From owner-freebsd-net Fri Mar 9 15:15:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id D611E37B719 for ; Fri, 9 Mar 2001 15:15:42 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f29NFbw04145; Fri, 9 Mar 2001 15:15:37 -0800 From: "Jonathan Graehl" To: "Freebsd-Net" Cc: "Walter Goralski" Subject: RE: generating SYN packets with /usr/ports/net/nemesis and sh Date: Fri, 9 Mar 2001 15:15:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Replying to self (multiple personality disorder?): Once caveat ... if you're trying to simulate the resource-exhaustion effects of a true SYN flood (rather than simply testing the ability of your firewall / intrusion detection system to react to a flood), then you will need to prevent autogeneration of RSTs by your TCP stack in reply to the TCP SYN ACK replies from the host you are attacking. This could be accomplished either with firewall rules (I haven't done this on FreeBSD, but I believe you use ipfw). It is more easily accomplished with: sysctl -w net.inet.tcp.blackhole=1 (udp.blackhole presumably surpresses generation of ICMP port unreachable when there is nobody listening on a UDP port) Traditionally .blackhole has been used to make port scanners' lives more difficult (they will have to concurrently-initiate/manage/time-out pending probes, or else proceed extremely slowly if using the default TCP connection timeout), but tcp.blackhole can also facilitate an effective SYN flood attack. For several years, most production servers will use tcp syncookies when faced with a flood of syns ... the server, using no local state, sends a SYN ACK with the server initial sequence number chosen to encode various state, and present an unforgeable secret hash, so that SYN ACKs from the initiator can be verified without having to remember anything about the embryonic connection. > #!/bin/sh > i=50000; while [ $i -lt 50100 ]; do nemesis-tcp -S 209.68.199.246 -D > 209.68.199.242 -fS -x $i -y 25; i=$(($i + 1)); done > > ... seems to work fine; a perl script would give a more legible for > loop though > ;) > > -- > Jonathan Graehl > email: jonathan@graehl.org > web: http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message