> -----Original Message-----
> From: Danny H. Cox [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 11, 2001 4:50 PM
> To: 'Mike Burden'; Danny H. Cox
> Cc: [EMAIL PROTECTED]
> Subject: RE: More firewall crashes.
>
> [...]
>
> Q: From you message, it appears that you are running IP Passthrough
> (no NAT) to the DMZ?
>
> A: No, actually using NAT with Alias, tunnels and RAF/OBF
> filter schemes.
In that case, assuming that A.B.C.D is your GNAT Box EXT Address,
A.B.C.E is the Alias that is tunneled to the Webserver, F.G.H.I
is the DMZ (PSN) address of the GNAT Box, and F.G.H.J is the
IP address of the webserver, then:
1. Which address is the destination address of the traffic?
2. Which Interface does the alarm message say that the traffic
is arriving on?
3. Is the source address for the traffic an address that
"belongs" on either your DMZ or PRO?
> Q: Did the firewall stop crashing when you added the filter to block
> traffic directed at the firewall? If so, then you can just change
> your filter to a Block/nolog type (see the DEFAULT filter called
> "Block/nolog stale WWW access" if you don't know how to do that).
>
> A: So far the crashes have ceased. Only been 22 hours so far.
Your simplest solution may be the one I suggested: Change the filter
that you added to a Block/nolog type of filter and just leave it in
place.
> Q: When you said that version 3.1.3 did not seem susceptible to this
> form of crash, did you mean that you dropped back to 3.1.3 to check,
> or that when you were running 3.1.3 at a previous time it didn't do
> this? If the latter, then 3.1.3 might have done the same thing,
> but conditions (like all that Code Red and Nimda traffic) may have
> changed.
>
>
> A: Correct on the 3.1.3. When using it, only had a crash when laplink
> pointed at the DMZ nic. I wish I could eliminate that Laplink
> crap. Never
> went back to that version though.
I'm going to stick to my guns and say that this doesn't tell us
anything about whether the problem existed in 3.1.3, since you
don't know that you were getting the same type of traffic directed
at the GNAT Box while you were running 3.1.3, and unless you
upgraded very recently, the Nimda probably wasn't around much
while you were running 3.1.3.
Did the problem start immediately (i.e., was the time from the
upgrade to the first crash about the same amount of time that
the GNAT Box will run now without your filter)?
Nothing struck me as a problem with your hardware platform --
maybe someone else has experience with a hardware platform that
matches yours more closely.
Mike Burden
Lynk Systems
http://www.lynk.com
(616)532-4985
[EMAIL PROTECTED]
> Q: You also didn't give us much of a clue on what hardware (CPU,
> Memory, NICs) you are using. With more information, some
> combination of factors may strike a note with someone here.
>
>
> A: Hardware environment as follows:
>
> GNAT Box kernel #321: Wed Aug 1 12:38:45 EDT 2001
> [EMAIL PROTECTED]:GBPRO
> Timecounter "i8254" frequency 1193182 Hz
> Timecounter "TSC" frequency 233864276 Hz
> CPU: Pentium/P55C (233.86-MHz 586-class CPU)
> Origin = "GenuineIntel" Id = 0x543 Stepping = 3
> Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX>
> real memory = 67092480 (65520K bytes)
> avail memory = 59187200 (57800K bytes)
> Intel Pentium detected, installing workaround for F00F bug
> md1: Malloc disk
> npx0: <math processor> on motherboard
> npx0: INT 16 interface
> pcib0: <AcerLabs M1541 (Aladdin-V) PCI host bridge> on motherboard
> pci0: <PCI bus> on pcib0
> pcib1: <AcerLabs M5243 PCI-PCI bridge> at device 1.0 on pci0
> pci1: <PCI bus> on pcib1
> pci1: <ATI Mach64-GB graphics accelerator> at 0.0 irq 11
> chip1: <AcerLabs M15x3 Power Management Unit> at device 3.0 on pci0
> isab0: <AcerLabs M1533 portable PCI-ISA bridge> at device 7.0 on pci0
> isa0: <ISA bus> on isab0
> fxp0: <Intel Pro 10/100B/100+ Ethernet> port xxxxxxx mem
> 0xdd800000-0xdd8fffff,0xe7000000-0xe7000fff irq 12 at device
> 9.0 on pci0
> fxp0: Ethernet address
> inphy0: <i82555 10/100 media interface> on miibus0
> inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xb400-0xb47f mem
> 0xdd000000-0xdd00007f irq 5 at device 10.0 on pci0
> xl0: Ethernet address:
> miibus1: <MII bus> on xl0
> xlphy0: <3c905C 10/100 internal PHY> on miibus1
> xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xb000-0xb07f mem
> 0xdc800000-0xdc80007f irq 10 at device 11.0 on pci0
> xl1: Ethernet address:
> miibus2: <MII bus> on xl1
> xlphy1: <3c905C 10/100 internal PHY> on miibus2
> xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> pci0: <AcerLabs Aladdin ATA controller> at 15.0 irq 0
> fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6
> drq 2 on isa0
> fdc0: FIFO enabled, 8 bytes threshold
> fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
> atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
> vga0: <Generic ISA VGA> at port 0x3b0-0x3df iomem
> 0xa0000-0xbffff on isa0
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <3 virtual consoles, flags=0x300>
> ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
> ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
> rb0: <dongle> on ppbus0
> IPsec: Initialized Security Association Processing.
> Mounting root from ufs:/dev/md0c
>
>
>
> From you message, it appears that you are running IP Passthrough
> (no NAT) to the DMZ?
>
> Did the firewall stop crashing when you added the filter to block
> traffic directed at the firewall? If so, then you can just change
> your filter to a Block/nolog type (see the DEFAULT filter called
> "Block/nolog stale WWW access" if you don't know how to do that).
>
> When you said that version 3.1.3 did not seem susceptible to this
> form of crash, did you mean that you dropped back to 3.1.3 to check,
> or that when you were running 3.1.3 at a previous time it didn't do
> this? If the latter, then 3.1.3 might have done the same thing,
> but conditions (like all that Code Red and Nimda traffic) may have
> changed.
>
> You also didn't give us much of a clue on what hardware (CPU,
> Memory, NICs) you are using. With more information, some
> combination of factors may strike a note with someone here.
>
> Mike Burden
> Lynk Systems
> http://www.lynk.com
> (616)532-4985
> [EMAIL PROTECTED]
>
>
>
> -----Original Message-----
> From: Danny H. Cox [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 11, 2001 11:28 AM
> To: Gb-Users@Gta. Com (E-mail)
> Subject: More firewall crashes.
> Importance: High
>
>
> Here is the problem:
>
> My firewall is crashing with predictable results. Support
> told me to buy
> support. I do not have current budget for that. Don't get me
> wrong, I am not
> bashing Support. They are trying to make a living, as we all
> are. Their
> position is not unreasonable.
>
> Also, version 3.1.3 did not seem susceptible to this form of crash.
>
> So, I am at your mercy. Hopefully you can tell me something
> that makes sense
> of this problem.
>
> I have reviewed my configs and found nothing bizarre. Yet, I
> still see the
> 3.2.1 version of Gnatbox Pro crash like clockwork.
>
> The only odd thing I have seen is certain traffic pointed
> directly at the
> firewall DMZ NIC. The destination ports have been 20,21,23 and 80. The
> traffic was not directed through the firewall, but to it. Odd!
>
> RMC and WWW management is OFF!
>
> I added a filter to block traffic to these ports when the DMZ
> nic is the
> destination IP. Since doing so, the firewall logs have been
> going crazy.
> About 30,000 hits in 12 hours. Most to port 80 (about 99.9%).
>
> I believe most of the traffic is originating from "Code Red"
> or "Nimda"
> infected systems looking for a meal.
>
> This traffic appears to have a pattern with respect to time -
> every second
> to third week of the month a dramatic increase in this
> traffic appears.
>
> So far nothing has gotten through. But the crashes are killing me!
>
> Any ideas? Anyone else seeing this type of crap???
>
> Regards,
>
> Danny H. Cox
>
