> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, June 22, 2005 5:23 PM
> To: [email protected]
> Subject: [rlug] Re: oracle si ipsec
>
> On 6/22/05, Vali Dragnuta <[EMAIL PROTECTED]> wrote:
> > Si esti sigur ca nu crapa procesul pe server ? Daca ai acces la
> > serverul oracle uita-te in loguri/traceuri sa vezi si daca nu cumva
> > procesul respectiv crapa din diverse motive.
>
> pana la urma am contactat adminul din cealalta parte a
> tunelului si este o problema din checkpoint-ul de acolo care
> ii da niste mesaje in loguri cum ca
> "Information: TCP packet out of state: First packet isn't SYN
> tcp_flags: PUSH-ACK ", deci inclin sa
> cred ca respectiva masinarie 'uita' de conexiunea mea dupa un
> anumit timp :)
Ma indoiesc profund, din experienta mea de pana acum, ca un FW-1 'uita'
starile. Spune-i adminului din partea cealalta sa dezactiveze din Global
Properties optiunea "Drop out of state TCP Packets". Din pacate, setarea
asta se aplica global, si deci presupune oarece riscuri ulterioare.
O abordare alternativa ar fi expusa mai jos:
<quote>
IMPORTANT: Before reading about the details of the "Drop out of state
TCP" checkbox, verify log messages do not indicate "SYN packet on
established connection," "Unexpected SYN response," or "Unexpected post
SYN packet". These messages indicate other state problems, which are not
controlled by the checkbox.
When TCP State verification is enabled, SmartDefense makes sure that the
first packet of each TCP connection is a SYN. When disabled, a non-SYN
packet that does not match an existing connection is allowed, but it
still needs to pass the Rule Base. Apart from blocking various network
scanners, this verification is crucial for the following reasons:
a) Allowing a connection to be recorded based on a non-SYN packet may
result in FireWall-1 running the Rule Base match on a server-to-client
packet. In many cases, server-to-client packets do not match the Rule
Base, and are therefore dropped. Moreover, even if a server-to-client
packet matches the Rule Base, the connection is recorded in the reverse
direction, and the service may not be recognized properly. For instance,
if a connection is recorded based on an FTP server-to-client packet, it
will not be recognized as an FTP connection. Therefore, FireWall-1 will
not parse the PORT commands, and data connections may not be able to
start.
b) Various security features require TCP connections to start with a
SYN. Some of them (e.g., Sequence Verifier) will turn themselves off for
non-SYN connections. Others (such as the HTTP Worm Catcher) will drop
each packet that belongs to such connections.
c) If NAT is involved, FireWall-1 will start translating the connection.
Since the connection was there before, it probably was not address
translated. This leads to a disconnection. In the case of hide NAT, even
if the connection was address translated, it is disconnected.
Consequently, before disabling the TCP state checks, validate what
causes FireWall-1 to encounter TCP connections from the middle. In
general, there may be two reasons for this:
1. Long-time idle connections, where the original connection entry may
have expired. In this case there are alternative solutions:
* Configure a longer tim-eout for the service.
** Configure FireWall-1 to REJECT non-SYN packets. This informs the
application the connection was lost, and in most cases the application
will attempt to re-open the connection and recover from the issue. To
configure FireWall-1 to reject a non-SYN packet, set the FireWall-1
kernel global parameter fw_reject_non_syn to 1.
2. In asymmetric routing, FireWall-1 may not encounter all connection's
packets, due to an alternative (possibly backup) link. In this case,
state checks must be disabled. This behavior can be refined for certain
services. Instead of clearing the TCP State checkbox, add an INSPECT
function called "user_accept_non_syn" to the user.def file (located
under $FWDIR/lib on the SmartCenter Server). This script should return a
true value for connections that may be recorded, based on a non-SYN
packet.
EXAMPLE
deffunc user_accept_non_syn() {
( /* allow only non-http connections to start with a non-SYN packet */
(dport!=80, sport!=80) or 0
)
};
</quote>
Incearca astea doua kestii, vezi care rezolva problema.
//ionut
---
Detalii despre listele noastre de mail: http://www.lug.ro/
