| |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FW-1] problems with vrp and ipso 3.7 build 026
looking at the nokia support site, I found this interesting thing :
Resolution 14946: Please explain why IPSO 3.6 does not require a VRRP
Multicast Rule
Subject: Please explain why IPSO 3.6 does not require a
VRRP Multicast Rule
Product Line: IPSO (Operating System)
Category: VRRP
Version: 3.6 Only
Date Modified: 05/06/2003
Description: IPSO 3.6 does not require an explicit VRRP rule
to allow VRRP Multicast packets to be accepted by the gateway. It is
also not possible to block the VRRP traffic with an explicitly defined
rule.
Previous releases of IPSO requires an explicit VRRP rule to allow the
VRRP packets to pass between the gateways. IPSO 3.7 and above will also
require these rules.
Solution:
The following is how VRRP packets are handled in IPSO today:
1. A VRRP packet that originates locally will bypass the firewall
egress
check and get transmitted on the specified interface.
2. A VRRP packet that is received will be processes as follows:
a. If TTL == 255 and the packet is destined locally, the packet
will bypass the FireWall-1 ingress check and be
delivered to the
socket of the ipsrd's VRRP protocol module.
b. If TTL = 255 and the packet is NOT destined locally, the
packet
will bypass the FW-1 ingress check but on the way of
forwarding
it will be given to FW-1 for egress checking. FW-1 will
then make the decision of drop or forward.
c. If TTL < 255, the packet will be given to FW-1 for ingress
checking. FW-1 will then make the decision of drop or
accept. If the packet
is not destined locally, on the way of forwarding it
will again be given to
FW-1 for egress checking. FW-1 will then make the
decision of drop or
forward.
As such using VRRP packets to attack hosts behind the FW won't be
possible because all
received VRRP packets, regardless of their TTL, will at least be
given to the FW for
egress checking before they get forwarded.
The only possible attack is to the gateway itself, with VRRP packets
having TTL=255.
But to have TTL=255, the attacker must have a box connected to the
direct link.
This is fixed in IPSO 3.7 and an explicit rule for VRRP packets must be
defined in the rulebase in order to pass VRRP multicast packets.
Nicolas FIgaro
-----Original Message-----
From: Figaro, Nicolas
Sent: mardi 7 octobre 2003 10:46
To: [email protected]
Subject: [FW-1] problems with vrp and ipso 3.7 build 026
Hi,
I upgraded yesterday evening an IP530 with ipso 3.7 build 026. (the
backup was upgraded a few days ago and works fine).
Today, it looks like the vrrp moves from one nokia box to another. so we
stopped the one that was migrated yesterday.
on the logs, I have a lot of connections accepted by the secondary one
(vrrp is configured for HA, no load balancing).
Has anyone ever experienced this ??
thanks
nicolas figaro
=================================================
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]
=================================================
=================================================
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]
=================================================
|
|
