DComTalk.com

I have a client who has a pix 501. They have only allowed me web
access/PDM to configure it. We are doing offsite email
scanning/filtering for them. I would like to create an access rule on
the pix 501 to only accept email from our server. This way, we're sure
it gets scanned. In the event the offsite service is comprimised, I
can just pull that ACL and the backup MX record will take care of mail.

I added a record on the web page which said more or less, the IP
(source) of the mail filter, with 255.255.255.255 as the mask, to the
internal ip of the mail server, and service smtp was allowed. I
actually just edited their current smtp rule. When I did this, mail
would no longer come through. When I removed the specific IP and went
back to any, mail came right through, AND through that mail filter too.


Any help?

In article <1134658748.267681.63540@g49g2000cwa.googlegroups.com>,
<chip.bell@gmail.com> wrote:

I have a client who has a pix 501. They have only allowed me web
access/PDM to configure it. We are doing offsite email
scanning/filtering for them. I would like to create an access rule on
the pix 501 to only accept email from our server. This way, we're sure
it gets scanned. In the event the offsite service is comprimised, I
can just pull that ACL and the backup MX record will take care of mail.

I added a record on the web page which said more or less, the IP
(source) of the mail filter, with 255.255.255.255 as the mask, to the
internal ip of the mail server, and service smtp was allowed.

That's the error. Unless you are doing VPN work, you need the
external IP of the mail server there.

I
actually just edited their current smtp rule. When I did this, mail
would no longer come through. When I removed the specific IP and went
back to any, mail came right through, AND through that mail filter too.

When you are creating an ACL that is to be applied to the outside,
you have to imagine that address translation has not yet taken place,
so everything has to be written in terms of what the PIX would see
"on the wire" -- the external versions of all the IPs.

Conversely ACL entries to be applied inside are done
before address translation, so you write what would be seen "on the wire" --
the internal versions of all the IPs.

[I don't just write "source" and "destination" IPs there, because
PIX can translate source IPs and destination IPs.]

--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

In article <1134664986.269403.136910@g47g2000cwa.googlegroups.com>,
<chip.bell@gmail.com> wrote:
:Ok, so I would add a rule that says

:source ip of the mail filter -----> public IP of the internal mail
:server?

Yes, and if you happen to be using non-standard ports, you would use
the public port number, not the internal port.
--
Programming is what happens while you're busy making other plans.

Ok, so I would add a rule that says

source ip of the mail filter -----> public IP of the internal mail
server?

BTW, thanks for your help...

In article <1134671027.917287.88310@f14g2000cwb.googlegroups.com>,
<chip.bell@gmail.com> wrote:
:Ok cool. Do I need to make a deny ACL to run to prevent other mail
:servers from connecting?

Everything not permitted is denied, so as long as you have been
restrictive on your other ACL entries and you only permit that
one source to connect to the mail server, then only it will be let
through.

However, if you -have- configured for that kind of protection, then
your plan of just "deleting" the entry if need be and having the
backup MX work, will not work if the backup MX is inside the protected
area.

One thing I have found is that if you have a backup MX configured, then
hosts (especially spammers) will use it even though it is not the
highest priority (lowest MX number). So... if your backup plan is
to allow mail through directly to the inside server without going through
your filtering service, then you would want to -change- the entry
to permit everything instead of permitting just your one host.

As a practical suggestion: I would suggest that instead of directly
coding,

access-list out2in permit tcp host FILTERSERVICE host MAILSYSTEM eq smtp

that instead you code,

object-group network permitted_mailers
network-object host FILTERSERVICE
access-list out2in permit tcp object-group permitted_mailers host MAILSYSTEM eq smtp

If you do that, then instead of having to edit the ACL line, all you
would have to do to allow or disallow the public would be to alter
the object group; e.g., after the above, commanding

object-group network permitted_mailers
network-object any

would have the effect of -adding- "any" to the list of permitted servers, and

object-group network permitted_mailers
no network-object any

would have the effect of removing the public again. That's easier than
showing the access list, finding the line number, removing the old
entry by line number, inserting the new entry by line number...
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

Ok cool. Do I need to make a deny ACL to run to prevent other mail
servers from connecting?

By the way, thank you very much for your help.