join example tcpdump file generated by 7plagues.pl ... (192.168.1.2# 7plagues.pl 192.168.1.3 icmp 10) Regard.
Greg Rumple wrote: > Okay I have taken the live box offline, and have built a lab with an > identical configuration, and I actually am able to reproduce the problem > at will now. > > I setup my lab environment to exactly mirror the live site, and I went > at it with the full tcp stream of traffic trying to cause the crash. > And after a good long while (and a lot of packets (was pushing full > 95-97Mbit for the entire period)), there was no issues. I than said > well let's pick up a bunch of DoS tools off of the web and see what I > can send at it (we get a lot of DoS traffic). > > And sure enough, I found a DoS tool that will crash it (with the error I > was getting) like clockwork. I can cause it to crash in as little as 10 > packets (it's an ICMP exploit btw interestingly enough (and rebuilding > the kernel with no INET6 didn't help btw)). > > I also started taking pieces out of the kernel in an attempt to narrow > it down. What I found was it only happens when I use the BIMAP piece of > the puzzle (along with the proxy arp of course). I basically stripped > my system down to the following. > > No ipf rules (so allow everything) > > ipnat.rules > ----------- > bimap fxp0 10.10.2.231/32 -> 1.2.3.231/32 > map fxp0 10.10.2.0/24 -> 1.2.3.70/32 portmap tcp/udp 1025:65000 > map fxp0 10.10.2.0/24 -> 1.2.3.70/32 > > rc.local > -------- > #!/bin/sh > /usr/sbin/arp -S 1.2.3.231 00:50:08:00:6b:b9 pub > /usr/sbin/arp -S 1.2.3.70 00:50:08:00:6b:b9 pub > > Everything else remained the same. > > And if you grab a copy of what is called 7plagues.pl > (http://packetstormsecurity.nl/DoS/7plagues.pl), and look at the icmp > test (the exact test is called riversOfBlood) this is the one that will > kill it (you can isolate it to just that test by editing the file, and > commenting out line 92) and calling it as > > ./7plagues.pl 1.2.3.231 icmp > > And within a few seconds of doing that it will reboot. You can specify > a third parameter to limit the number of packets. I've been able to > cause it in as few as 10 and as many as 100,000. > > If you send the packets at the machines REAL ip (1.2.3.1) it works just > fine, it's just the BIMAP'd address that causes the failure. Upon > reboot, looking at the kernel core dump, it yields EXACTLY the failure I > have been seeing (the va = kbp->next bug where kbp->next points to 0x1). > > Greg > > * Steven Nikkel ([EMAIL PROTECTED]) [030528 07:20]: > > That seems similar to a problem I'm seeing. I'm getting > > "ICMP destination unreachable, host unreachable" packets > > in the middle of connections. A source quence would actually > > make sense in these case. > > > > I'm running IPfilter 3.4.29 on Freebsd 4.7 with nat and ipv6. > > > > On Wed, 28 May 2003, Guido van Rooij wrote: > > > > > Date: Wed, 28 May 2003 14:44:20 +0200 > > > From: Guido van Rooij <[EMAIL PROTECTED]> > > > To: Greg Rumple <[EMAIL PROTECTED]> > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: FreeBSD 4.8 IPFilter/IPNat kernel panic > > > > > > On Wed, May 28, 2003 at 05:41:59AM -0700, Greg Rumple wrote: > > > > > > > > > > > > So far 2 crashs later, the packet in both cases in the ip_natin code > > > > > > (print *ip) is a TCP packet. > > > > > > > > > > DO you have a kernel with Ipv6? > > > > > > > > Yeah I believe the default kernel in 4.8 (I'm using the GENERIC kernel > > > > plus 4 lines added to it) most certanly does have IPv6. I'm not using > > > > it, but you said that doesn't apply. And yes doing an ipfstat -hio6 > > > > shows I have empty rule sets for ipv6 traffic. > > > > > > Hmm..I still wonder if the problem is the same, as with my friends setup > > > it is always an ICMP source quench in combination with NAT. > > > Haven't tracked it down though. > > > > > > -Guido > > > > > > > [EMAIL PROTECTED] > > ------------------------- > > ERROR: Keyboard not attached. Press F1 to continue. > > > > -- > Greg Rumple > [EMAIL PROTECTED]
7plagues.tcpdump.gz
Description: GNU Zip compressed data
