| |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FW-1] 4.1 packet to tcp 256 gives cookie_length log and kills firewalls
- To: [email protected]
- Subject: [FW-1] 4.1 packet to tcp 256 gives cookie_length log and kills firewalls
- From: Eric Appelboom <[email protected]>
- Date: Tue, 25 Feb 2003 15:11:37 +0200
- Reply-to: Mailing list for discussion of Firewall-1 <[email protected]>
- Sender: Mailing list for discussion of Firewall-1 <[email protected]>
- Thread-index: AcLcz228UmYmTPVPRdm+ZnSOooZFdQ==
- Thread-topic: 4.1 packet to tcp 256 gives cookie_length log and kills firewalls
hi,
Could someone check if this is a old bug or something new.
If I use retina 4.9 to scan our fw-1 4.1 it causes them both to reboot
or halt.
We have a 2 node FW-1 4.1 running Stonebeat Fullcluster 2 on Solaris 5.7
In the case below I scanned the stonebeat virtual interface .50
When retina sends a packet to the virtual interface on tcp 256 one of
the nodes gives the log entry below.
The other node just reboots or halts.
We initialy though this was a Solaris fault but appears to be firewall
related.
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
Below we can see the connections from the scanner.
The system time on fw-1 and log below is 13minutes 11 second ahead
firewall-1 log
Thus the time 15:05:04 above equates to 15:18:15 below.
Feb 24 15:06:48 x.x.x.1 PASS: Close TCP [x.x.x.17/1307]->[x.x.x.50/23]
dur=00:00:33 pkts=3:2 bytes=192:80
Feb 24 15:06:50 x.x.x.1 PASS: Close TCP [x.x.x.17/1384]->[x.x.x.50/8888]
dur=00:00:32 pkts=2:1 bytes=128:40
Feb 24 15:06:50 x.x.x.1 PASS: Close TCP [x.x.x.17/1366]->[x.x.x.50/5000]
dur=00:00:32 pkts=3:2 bytes=192:80
Feb 24 15:06:50 x.x.x.1 PASS: Close TCP
[x.x.x.17/1405]->[x.x.x.50/31337] dur=00:00:32 pkts=2:1 bytes=128:40
Feb 24 15:08:19 x.x.x.1 PASS: Close UDP [x.x.x.17/1309]->[x.x.x.50/53]
dur=00:02:02 pkts=1:0 bytes=46:0
Feb 24 15:08:58 x.x.x.1 PASS: Close UDP [x.x.x.17/3752]->[x.x.x.50/161]
dur=00:10:02 pkts=1:0 bytes=68:0
Feb 24 15:16:17 x.x.x.1 PASS: Close UDP [x.x.x.17/1309]->[x.x.x.50/39]
dur=00:10:02 pkts=1:0 bytes=46:0
Feb 24 15:16:18 x.x.x.1 PASS: Close UDP [x.x.x.17/1309]->[x.x.x.50/42]
dur=00:10:02 pkts=1:0 bytes=46:0
Feb 24 15:16:19 x.x.x.1 PASS: Close UDP [x.x.x.17/1309]->[x.x.x.50/43]
dur=00:10:02 pkts=1:0 bytes=46:0
Feb 24 15:18:25 x.x.x.1 PASS: Close TCP [x.x.x.17/7677]->[x.x.x.50/256]
dur=00:00:07 pkts=2:1 bytes=88:48
Feb 24 15:18:25 x.x.x.1 PASS: Close TCP [x.x.x.17/7535]->[x.x.x.50/89]
dur=00:00:07 pkts=1:1 bytes=48:40
Feb 24 15:18:25 x.x.x.1 PASS: Close TCP [x.x.x.17/7514]->[x.x.x.50/68]
dur=00:00:07 pkts=1:1 bytes=48:40
Feb 24 15:18:25 x.x.x.1 PASS: Close TCP [x.x.x.17/7497]->[x.x.x.50/51]
dur=00:00:07 pkts=1:1 bytes=48:40
Feb 24 15:18:25 x.x.x.1 PASS: Close TCP [x.x.x.17/7487]->[x.x.x.50/41]
dur=00:00:07 pkts=1:1 bytes=48:40
Feb 24 15:18:25 x.x.x.1 PASS: Close TCP [x.x.x.17/7483]->[x.x.x.50/35]
dur=00:00:07 pkts=1:1 bytes=48:40
Feb 24 15:18:25 x.x.x.1 PASS: Close TCP [x.x.x.17/7463]->[x.x.x.50/3]
dur=00:00:07 pkts=1:1 bytes=48:40
Feb 24 15:18:26 x.x.x.1 PASS: Close TCP [x.x.x.17/7530]->[x.x.x.50/84]
dur=00:00:08 pkts=1:1 bytes=48:40
Feb 24 15:18:26 x.x.x.1 PASS: FTP - Close TCP
[x.x.x.17/7474]->[x.x.x.50/21] dur=00:00:08 pkts=1:1 bytes=48:40
Feb 24 15:18:27 x.x.x.1 PASS: Close TCP [x.x.x.17/7511]->[x.x.x.50/65]
dur=00:00:09 pkts=1:1 bytes=48:40
Feb 24 15:18:27 x.x.x.1 PASS: Close TCP [x.x.x.17/7472]->[x.x.x.50/19]
dur=00:00:09 pkts=1:1 bytes=48:40
Feb 24 15:18:28 x.x.x.1 PASS: Close TCP [x.x.x.17/7502]->[x.x.x.50/56]
dur=00:00:10 pkts=1:1 bytes=48:40
Feb 24 15:18:42 x.x.x.1 FILTER: PTF (148) block - notice TCP
[x.x.x.50/259]->[x.x.x.17/7680] xl1 l=0 f=0x12 <----?
Feb 24 15:18:49 x.x.x.1 PASS: Close TCP [x.x.x.17/7688]->[x.x.x.50/282]
dur=00:00:32 pkts=1:0 bytes=48:0
Feb 24 15:18:49 x.x.x.1 PASS: Close TCP [x.x.x.17/7641]->[x.x.x.50/195]
dur=00:00:32 pkts=1:0 bytes=48:0
Feb 24 15:18:49 x.x.x.1 PASS: Close TCP [x.x.x.17/7573]->[x.x.x.50/127]
dur=00:00:32 pkts=1:0 bytes=48:0
Feb 24 15:18:50 x.x.x.1 PASS: Close TCP [x.x.x.17/7882]->[x.x.x.50/526]
dur=00:00:32 pkts=1:0 bytes=48:0
The Firewall-1 is running Build 41617(SP6), Stonebeat Fullcluster 2.0
(Build 2035) patch 05 and Solaris Cluster patch dated 7 Feb.
Our primary node seemed to accept the packet first and it gave
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: one_cookie_length: cookie too small
71c2c0bc
Feb 24 15:05:04 node1 unix: FW-1: cookie_length: problem with cookie
71c2c0bc
The firewall that logs the cookie_length problem halts.
Then if you check the second node at the same time it cpu panicked
similar to thread at
https://www.firewall-1.org/2002-08/msg00001.html
Feb 24 15:03:42 node2 unix: <c402358c
Feb 24 15:03:42 node2 unix: ,85b7
Feb 24 15:03:42 node2 unix: ,89270103
Feb 24 15:03:42 node2 unix: ,35
Feb 24 15:03:42 node2 unix: ,11
Feb 24 15:03:42 node2 unix: ;0
Feb 24 15:03:42 node2 unix: ,4002
Feb 24 15:03:42 node2 unix: ,502ff00
Feb 24 15:03:42 node2 unix: > <0 : =0 22>
Feb 24 15:03:42 node2 unix: FW-1: Warning: modify for a new entry:
Feb 24 15:03:42 node2
Feb 24 15:03:42 node2 unix: <c402358c
Feb 24 15:03:42 node2 unix: ,85b7
Feb 24 15:03:42 node2 unix: ,89270103
Feb 24 15:03:42 node2 unix: ,0
Feb 24 15:03:42 node2 unix: ,11
Feb 24 15:03:42 node2 unix: ;0
Feb 24 15:03:42 node2 unix: ,4002
Feb 24 15:03:42 node2 unix: ,502ff00
Feb 24 15:03:42 node2 unix: > <0 : =0 22>
Feb 24 15:06:42 node2 unix: ^MSunOS Release 5.7 Version
Generic_106541-23 [UNIX(R) System V Release 4.0]
Feb 24 15:06:42 node2 unix: Copyright (c) 1983-1999, Sun Microsystems,
Inc.
Feb 24 15:06:42 node2 unix: Ethernet address = 8:0:20:c8:c:ea
Feb 24 15:06:42 node2 unix: mem = 2097152K (0x80000000)
Feb 24 15:06:42 node2 unix: avail mem =Feb 24 15:06:42 node2 unix: root nexus = Sun Ultra 60 UPA/PCI (2 X
UltraSPARC-II 450MHz)
Feb 24 15:06:43 node2 unix: pci0 at root: UPA 0x1f 0x4000
Feb 24 15:06:43 node2 unix: pci0 is /pci@1f,4000
Feb 24 15:06:43 node2 unix: /pci@1f,4000/scsi@3 (glm0):
Feb 24 15:06:43 node2 Rev. 5 Symbios 53c875 found.
Feb 24 15:06:43 node2 unix: PCI-device: scsi@3, glm0
Feb 24 15:06:43 node2 unix: glm0 is /pci@1f,4000/scsi@3
Feb 24 15:06:43 node2 unix: /pci@1f,4000/scsi@3,1 (glm1):
Feb 24 15:06:43 node2 Rev. 5 Symbios 53c875 found.
What makes it interesting is that the firewall keeps sending the
following.
Feb 24 15:18:42 x.x.x.1 FILTER: PTF (148) block - notice TCP
[x.x.x.50/259]->[x.x.x.17/7680] xl1 l=0 f=0x12
Feb 24 15:19:09 x.x.x.1 FILTER: PTF (148) block - notice TCP
[x.x.x.50/259]->[x.x.x.17/7680] xl1 l=0 f=0x12
Feb 24 15:20:03 x.x.x.1 FILTER: PTF (148) block - notice TCP
[x.x.x.50/259]->[x.x.x.17/7680] xl1 l=0 f=0x12
Feb 24 15:21:03 x.x.x.1 FILTER: PTF (148) block - notice TCP
[x.x.x.50/259]->[x.x.x.17/7680] xl1 l=0 f=0x12
Feb 24 15:21:04 x.x.x.1 PASS: Close TCP [x.x.x.17/9108]->[x.x.x.50/9898]
dur=00:00:34 pkts=1:0 bytes=48:0
Feb 24 15:22:03 x.x.x.1 FILTER: PTF (148) block - notice TCP
[x.x.x.50/259]->[x.x.x.17/7680] xl1 l=0 f=0x14
Feb 24 15:22:09 x.x.x.1 PASS: Close TCP [x.x.x.17/2473]->[x.x.x.50/256]
dur=00:03:51 pkts=15:8 bytes=900:488
Feb 24 15:22:10 x.x.x.1 PASS: Close TCP [x.x.x.17/2474]->[x.x.x.50/259]
dur=00:03:52 pkts=15:8 bytes=900:488
Feb 24 15:22:11 x.x.x.1 PASS: Close TCP [x.x.x.17/2475]->[x.x.x.50/264]
dur=00:03:53 pkts=15:8 bytes=900:488
Feb 24 15:23:06 x.x.x.1 PASS: Close ICMP [x.x.x.17/4]->[x.x.x.50/4]
dur=00:00:12 pkts=1:0 bytes=60:0 <--goodbye
I am not sure if it is related to the RDP bypass vulnrability.
We have not installed the Aggressive IKE Hotfix or OpenSSL Hotfix as
appears unrelated.
I have also revied the following for the same action
Feb 20 03:00:52 node1 unix: BAD TRAP: cpu=2 type=0x31 rp=0x71023cd8
addr=0x100014 mmu_fsr=0x0
Feb 20 03:00:52 node1 unix: BAD TRAP occurred in module "sbif" due to an
illegal access to a user address.
Feb 20 03:00:52 node1 unix: sched:
Feb 20 03:00:52 node1 unix: trap type = 0x31
Feb 20 03:00:52 node1 unix: addr=0x100014
Feb 20 03:00:52 node1 unix: pid=0, pc=0x10274d28, sp=0x71023d68,
tstate=0x4480001e05, context=0x0
Feb 20 03:00:52 node1 unix: g1-g7: 0, 38383934, 2000000, 22, 2, 0,
401ade60
Feb 20 03:00:52 node1 unix: Begin traceback... sp = 71023d68
Feb 20 03:00:52 node1 unix: Called from 10037df0, fp=71023dd8,
args=00 204
Feb 20 03:00:52 node1 unix: Called from 70ee753c, fp=71023e38,
args=000 10274d24 701502d8
Feb 20 03:00:52 node1 unix: Called from 70f01b08, fp=71023ea0,
args=71bd34f4 71bc1428 8 800001 2 14
Feb 20 03:00:52 node1 unix: Called from 70ede144, fp=71023f00,
args=71bc1410 0 0 0 10279fc8 70106540
Feb 20 03:00:52 node1 unix: Called from 70f02614, fp=401ad768,
args=71023f00 70f0163c 71bc1410 0 0 0
Feb 20 03:00:52 node1 unix: End traceback...
Feb 20 03:00:55 node1 unix: panic[cpu2]/thread=401ade60:
Feb 20 03:00:55 node1 unix: trap
Feb 20 03:00:55 node1 unix:
Feb 20 03:00:55 node1 unix: syncing file systems...
Feb 20 03:01:15 node1 unix: panic[cpu2]/thread=40047e60:
Feb 20 03:01:15 node1 unix: panic sync timeout
Feb 20 03:01:15 node1 unix:
Feb 20 03:01:16 node1 unix: dumping to /dev/dsk/c0t0d0s1, offset 65536
Feb 20 03:01:27 node1 unix: ^M100% done: 13657 pages dumped, compression
ratio 3.08,
Feb 20 03:01:27 node1 unix: dump succeeded
eb 20 03:02:46 node1 unix: ^MSunOS Release 5.7 Version Generic_106541-23
[UNIX(R) System V Release 4.0]
Feb 20 03:02:46 node1 unix: Copyright (c) 1983-1999, Sun Microsystems,
Inc
=================================================
To set vacation, Out Of Office, or away messages,
send an email to [email protected]
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
[email protected]
=================================================
|
|
