Okay,
Made sure the hotfix was applied (it was), then I added the following lines to
the code.def file.
#ifndef ALLOW_NONFIRST_RULEBASE_MATCH
tcp, first or <conn> in old_connections or
(src in firewalled_list, dts in firewalled_list) or
(
#ifndef NO-NONFIRST_RULEBASE_MATCH_LOG
(
<ip_p, src, dst, sport, dport, 0> in logged
) or (
record <ip_p, src, dst, sport, dport, 0> in logged,
set sr10 12, set sr11 0, set sr12 0, set sr1 0,
log bad_conn
) or 1,
#endif
vanish
) ;
#endif
This was located in the Release noted for the Hotfix. Then I rebooted the
machine just for good measure. Everything started up fine, However when I tried
to re-install the rule base I go the following errors:
Standard.W: Security Policy Script generated into Standard.pf
cpp: line 223, Warning: Unexpected text in #control line ignored
#ifndef NO-NONFIRST_RULEBASE_MATCH_LOG
from file C:\WINNT\FW1\4.1\conf\Standard.pf, line 444:
#include "code.def"
Standard:
"C:\WINNT\FW1\4.1\lib\code.def", line 126: ERROR: cannot find <firewalled_list>
anywhere
Compilation Failed.
I made sure I typed everything correctly so there appears to be a problem
somewhere else. Before I made any of these changes I re-enabled PASV FTP in
porperties/services. I figured leave everything as default before proceding.
Any ideas?
Thanks,
Joe
"Stephen Pedersen" <[EMAIL PROTECTED]> on 07/14/2000 10:09:51 AM
To: Joseph Vieira/DMR/CA@DMR-CANADA
cc: [EMAIL PROTECTED]
Subject: Re: [FW1] ftp problem
Checkpoint have added the enforcement of a (0x0a) newline char. at the end of
all
ftp control packets. If the packet doesn't have a newline char, fw-1 sends a
reject
to the server on behalf of the client. This was implemented in v4.0sp6 and
v4.1sp1.
Cert advisory was in Febrary 00.
If the banner for the ftp site is larger than 1 packet (eg exceeds MTU) there
will
be no newline char at the end of the 1st packet.
See url:
http://www.cert.org/tech_tips/ftp_port_attacks.html (some what related)
http://www.checkpoint.com/techsupport/alerts/pasvftp.html
Text from SP6 Release Notes:
Bug Fixes
The following bugs were fixed in this release:
* It was possible to enter more than 8 characters for a FireWall-1 password.
* If the user clicked on Show Policy when a non-gateway object was selected
under
Security Policies on Targets in the Open Security Policy window, the
following
error message would sometimes be displayed:
�Inconsistent information
found.
Verify that your database is intact. Rule X, cannot locate object
usergroup@location.
�
* If FireWall-1 was installed in a directory whose name included embedded
spaces
(for example,
�C:\Program Files\FW
�), then an error message was displayed
when
a Security Policy was installed.
* Querying pseudo rules would return incorrect results.
* Under some conditions, the Log Viewer showed only the first five columns.
* The SMTP Security Server would not add the last mail server
�s name to the
list
of
�Received from
�.
* In the Motif Log Viewer, selecting File�Open from the menu would cause a
core
dump.
* (Windows GUI) In the Log Viewer, selecting Print Preview from the menu and
then
closing the preview while the
�"Getting information from server
� message
was
still displayed would bring up Dr. Watson.
* Connections from virtual interfaces would fail with the following message:
�FW-1: No license for IP Forwarding FW-1: Connection from <IP address>
refused
�.
* Error pages generated by the HTTP Security Server were dated 01-Jan-70.
* Available file descriptors could be exhausted if a large number of
instances of
the HTTP Security Server were running (
�Too many open files
� message in
fwd.log).
* Users with ISAKMP credentials could not be imported to the FireWall-1
database.
* FireWall-1 did not correctly manage the case where more than one RADIUS
server
was installed on the same machine. FireWall-1 always used the RADIUS server
last defined in the GUI. In addition, if the RADIUS servers were defined as
a
group, then FireWall-1 would always try to contact the first RADIUS server
in
the group, even if it went down.
* If the HTTP Security Server was defined as a proxy, then when connecting
with
Internet Explorer 4 or 5 to certain sites that require plug-ins, the
browser
would correctly download the plug-in and then fail. This happened because
the
HTTP Security Server ignored the
�Proxy-Authorization:
� header when the
agent
was not Netscape or Internet Explorer.
* The mail dequeuer would sometimes fail to terminate an open anti-virus
session.
* User Authentication would not work properly if a domain object was defined
in a
previous rule.
* The ahttpd.log file was filling up with the following messages:
�Failed to
get
my socket name on 22: Invalid argument
� and
�get_auth_conn: getsockname(22)
failed: Invalid argument
�.
* (AIX) Running fw ctl install after fw ctl uninstall would fail. Only the
loopback interface was recognized and no Security Policy was installed.
* (HP-UX 10.20) snmpd did not support the -p option.
*
*
*
* The VPN/FireWall Module kernel
�s handling of FTP control connections has
been
modified in the following ways: Kernel handling of FTP control connections
�
checking and enforcing the existence of a new line (i.e., CR/LF) for any
FTP
control connection packets Kernel handling of FTP control connections
�
checking and enforcing that all 227 PASV replies are
�)/newline
�.
*
*
*
* Under rare cirumstances valid packets might traverse the VPN/FireWall
Module
without undergoing the specified address translation. To correct this
problem,
close the GUI Clients, stop the FireWall-Management Station and add the
following INSPECT code to the $FWDIR/lib/code.def file (at the end of the
file,
just before the #endif statement) on the Management Station. After editing,
reinstall the Security Policy. For Version 4.0-based installations, this
code
will also log these events. After this fix is applied, the VPN/FireWall
Module
�s startup behavior may be different. TCP connections established to
the
VPN/FireWall Module before the Security Policy is activated (for example,
TCP
connections launched from startup scripts at boot time) will be dropped.
Options to fix this in order of prefference:
1. Get you supplier to reduce the banner size to 1 packet ( Oracle , NAI)
2. If you are using anonymous ftp, add a "-" before the password (eg. [EMAIL PROTECTED]).
This tell the ftp server not the send the banner. ( ftp.nai.com have this
problem )
3. Disable the ftp newline enforcement. See above URL (This is done on the
manager
so all fw-1 will be effected.)
Steve Pedersen
[EMAIL PROTECTED] wrote:
> Greetings,
>
> I have FW-1 ver 4.0 and 4.1 on NT machine. I was on oralces tech web site
> http://technet.oracle.com/ to down load some software. The web site takes you
> to a page which has a link to their ftp site. When I click on that link I get
a
> read error. I checked the FW logs and it showed that a packet was rejected by
> rule 0 from the ftp server to client machine. In the info section of the log
it
> stated the reason: tried to open other host port.
>
> Now I was downloading stuff from oracle for a month now with no problems until
> last week. Than this happened on my FW (ver 4.0), and I just setup a new FW
> (ver 4.1) and I have the same problem. Anyone know what this problem is and
how
> to fix it?
>
> Thank you,
>
> Joe
>
> I'm using IE and Netscape to download from oracle on both Windows and Linux
> machines.
>
>
================================================================================
> To unsubscribe from this mailing list, please see the instructions at
> http://www.checkpoint.com/services/mailing.html
>
================================================================================
