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] |
======================================================================
-----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
===============================================
