CheckPoint has always had flaws in it's SMTP security server and dequeuer
(mdq), and many of the other technical issues have been addressed here
before (MX record issues, dequeuing priority, CVP, etc.). Plus with having
to define domain names not only on every mail server, but now on the firewalls
too, it's much easier to either have a properly configured mail server
with anti-virus on there, or create a sandwich of mail servers in front
(or DMZ) and behind the firewalls. Let the entry point mail servers handle
anti-relaying and pass valid email inbound to your company mail server.
I've been down this route before in more than one company and have always
found it better to dump the CheckPoint SMTP server and just build
a properly configured mail system.
(Response to Miles' original post)
Interesting finding...
I tested your data as described below, and I am not convinced
that this "allows relaying". The whole concept of relay restriction
is that some destinations are permitted, and others are not. The
syntax you suggest causes the message to be forwarded to the mail server
defined in the SMTP resource rule (the "permitted destination"), but where
does it go from there? Well, if you're using any mail server I've
ever seen, absolutely nowhere. The firewall has done its job - as
you noted in your original post, the SMTP security server does not forward
to "forbidden" destinations as relay when properly configured. The
destination mail server will drop the request, as it will be unable to
find a user named "fred%hotmail.com" in its local address table.
The blah%blah.com syntax won't be automatically converted
to a valid address by any mail server I know of, much less forwarded, and
even if it was, we're now talking about a problem on the mail server, not
the firewall. As you noted, you can put whatever you want as long
as it ends in @domain.com, but I fail to see the relevance.
Example:
220 CheckPoint FireWall-1 secure SMTP server
helo breakwater.net
250 Hello breakwater.net, pleased to meet you
mail from:<[email protected]>
250 <[email protected]>... Sender ok
rcpt to:<vf^hnhj#$bg()@breakwater.net>
250 <vf^hnhj#$bg()@break... Recipient ok
As with all other security tools, the administrator is
welcome to mis/non-configure their software, but this does not mean that
the vendor has produced a faulty or insecure product.
If anyone has successfully used the firewall-1 SMTP security
server when properly configured as a relay, or accomplished anything with
the data provided by Miles, please post.
Dan Hitchcock
-----Original Message-----
From: Bob Webber/Markham/Contr/AT&T/IJV [mailto:[email protected]]
Sent: Tuesday, October 23, 2001 11:42 AM
To: [email protected]
Subject: Re: [FW-1] CheckPoint FireWall-1 "INSECURE"
SMTP server - BIG
HOL E!!
Hi all:
I think this is only a problem if the mail server that
FW-1 relays to is
configured as an open relay.
I have both eSafe and ISVW in my environment. With either
implementation,
the mail server(s) on the inside that receive the scanned
mail are
configured to only accept mail for one particular domain.
I have heard
about this issue before, and I am unable to duplicate
it on my servers.
(Now if we could only do something about those pointless
out-of-office
replies!)
Regards.
Bob Webber
AT&T Global Network Services
Tel:
Fax:
Notes: Bob Webber/Markham/IBM@IBMCA
Internet: [email protected]
"Logic merely enables one to be wrong with authority"
- Doctor Who
"Firewall-1 (Joe Voisin)" <[email protected]>@beethoven.us.checkpoint.com>
on 10/23/2001 12:29:27 PM
Please respond to Mailing list for discussion of Firewall-1
<[email protected]>
Sent by: Mailing list for discussion of Firewall-1
<[email protected]>
To: [email protected]
cc:
Subject: Re: [FW-1] CheckPoint FireWall-1 "INSECURE"
SMTP server - BIG HOL
E!!
I had the same problem when using a SMTP Scanning relay
(Mcafee)
It was receiving the mail, scanning it and then relaying
it to the mail
servers.
I was blacklisted at orbz.org for nearly a day.
I had to revert back to
using a linux box to answer port 25 connections, then
relay valid mail to
the SMTP scanner which in turn delivers the mail to the
mail servers.
QUITE
a pain in the butt..
I have also tried using the SMTP CVP scanning, but it
does exactly the same
thing. I think it's more an issue with the anti-virus
software than
checkpoint's CVP implementation...
Regardless, I would always prefer to have something a
bit more robust
handling the inbound email. I can't really say
that I would be comfortable
having Exchange server accepting SMTP connections from
the internet...
Joe
======================================================================
Joseph Voisin, Systems and Network Administrator, Engel
Canada Inc.
www.engelmachinery.com | [email protected] |x436
======================================================================
-----Original Message-----
From: Miles D. Oliver [mailto:[email protected]]
Sent: Tuesday, October 23, 2001 10:53 AM
To: [email protected]
Subject: [FW-1] CheckPoint FireWall-1 "INSECURE" SMTP
server - BIG HOLE!!
The Check Point Firewall-1 secure SMTP server will
allow for mail
relaying.
We have setup many installations of Trend Micros
InterScan Viruswall, the
CVP version to scan incoming mail for our customers.
We have recently noticed that many of our customers
have been
'BLACKLISTED' for of e-mail relaying when an SMTP resource
that uses
the Check Point Firewall-1 Secure SMTP server.
Defining a domain or multiple domains in the recipient
field The 'match'
tab for all SMTP resources will only prevent a small
amount of mail
relaying. It only checks against the characters EXPLICLTY
defined in the
recipent field of the match tab.
For example:
220 CheckPoint FireWall-1 secure SMTP server
helo lgi.com
250 Hello lgi.com, pleased to meet you
mail from:<[email protected]
250 <[email protected]>... Sender ok
rcpt to:<[email protected]>
450 Mailbox unavailable.
Mail sent from [email protected] to [email protected],
only the domain will
be checked and relaying will be denied.
However, When the recipient is defined using special
characters such as
the "%" character will allow mail to be relayed.
For Example:
220 CheckPoint FireWall-1 secure SMTP server
helo lgi.com
250 Hello lgi.com, pleased to meet you
mail from:<[email protected]>
250 <[email protected]>... Sender ok
rcpt to:<jane%[email protected]>
250 <jane%hotmail.com@lg... Recipient ok
Mail sent from [email protected] to jane%[email protected]
will allow
the mail to be relayed to [email protected] THROUGH the
Check Point SMTP
secure server.
Big problem... This should not be happening.
We have had to make adjustments to all of our InterScan
Viruswall
implementations with CVP.
We have had to implement a mail server in a DMZ
to accept all mail for
the domain using Sendmail 8.12.1 use its anti-relaying
functions, Change
all
MX records to the Internet and then allow the mail server
to in the DMZ to
then forward mail to the internal mail server through
the firewall to use
the CVP resource, scan the mail, and into to the internal
mail server.
While many should say that it is not a good idea
to have the Check Point
firewall to relay checking' and it should be handled
by a REAL mail server
my question is...
Why does all the documentation that I have
read for configuring using
CVP resources is that the using the firewall should be
the the 'inbound'
point for incoming mail?
I've looked all over Check Point's website for
any information about
mail relaying and there is NOTHING in the Secure Knowledge
base about this
BUG in the SMTP Secure server.
So, In a nutshell, If you are using InterScan
Viruswall or any of the
Other CVP based tools, be prepared to setup an additional
mail server to
initially receive the incoming mail and then forward
it to the firewall to
use your defined SMTP resource.
In my opinion The Check Point SMTP secure server
is INSECURE and does not
work as it should and if it is to be accepting mail to
pass to a CVP
resource for scanning and then delivery to the internal
mail server.
It should NOT allow relaying.
Don't use it unless you are prepared to be 'BLACKLISTED'.
--
Miles D. Oliver
Senior Systems Engineer - CCSA/CCSE
LGI
10450 Shaker Drive Suite 208
Columbia Maryland USA 21046
VOICE
FAX
EMAIL [email protected]
WEB www.lgi.com
===============================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
===============================================
===============================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
===============================================
===============================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
===============================================