Date: Wed, 03 Jan 2007 13:35:53 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Mohamad Babaei <mo.babaei@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Setting another machine as a firewall Message-ID: <459BB139.9080306@infracaninophile.co.uk> In-Reply-To: <5bf3a41f0701030128gd2ce04wb6fe8df882aa80e2@mail.gmail.com> References: <5bf3a41f0701030128gd2ce04wb6fe8df882aa80e2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5CE7D6B77AA1F60D66CEE81E
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Mohamad Babaei wrote:
> i want to set another machine as a firewall for my mail server to preve=
nt
> receiving huge number of spams each day.
> so, how shuold i change my DNS to do this ?
Hmmm... I don't think a firewall is really the right technology to
achieve what you desire. A firewall (in the general usage) is a
piece of software designed to filter network packets, or a machine
whose primary duty is to run such a filter. Packet filters typically
look only at the ethernet and IP headers of any packets. So they
can tell if an incoming packet is headed towards port 25 on your
mail server, but they've got no idea if the payload in that packet
is spam or not. If you want to sound impressive to management you
can say that "firewalls act at layers 2 and 3 of the OSI model, and
this is a layer 4 problem."
Technically the sort of software you need at layer 4 is a proxy
server -- ie. a protocol specific piece of software which can process
the incoming packet streams and respond to the sender exactly as if
it was the ultimate destination, but then apply any restrictions
required by your security policy and then hand-off the content
to the real end-user. Web caches are a classic example of this sort
of thing.
Now, you can do exactly this for e-mail traffic. However, as SMTP
servers, by their nature, are designed for the relaying of mail
traffic, in general you'ld just use another instance of an MTA to
be the firewall proxy server. Obviously you need to think carefully
about the design here: simply making e-mail jump through two copies
of sendmail or exim or whatever won't get you any more security or
protection against spam and just introduces additional points of
failure. Good reasons for adding a mail relay at your border are
such things as:
* we don't want to expose our Exchange server to the internet at
large. because it's a security nightmare.
* we have a large internal network with mailservers at several
sites and we need to route SMTP traffic internally whilst
still presenting a unified e-mail name space to the outside
world.
* we have so much incoming e-mail that we need to share out the
load of spam filtering and providing mailbox services over
a number of machines internally.
The alternative to implementing a proxy mail server on your firewall
is to set the firewall to simply direct e-mail traffic through to your
internal mail server. If your internal networks are routeable from the
internet, then that is just a matter of writing filter rules to allow
the traffic. If you're in the very common position of using NAT on
your firewall then you'll need to add configuration to allow incoming
connections to port 25 to be forwarded to your internal mail server --
'redirection' or 'binat' are commonly heard terms involved with doing
that. Exactly how to do that depends on the firewalling software you're
using and the detail of the way your networks are constructed. (There
are 3 packages available in the base FreeBSD distribution alone capable
of doing this job -- pf, ipfilter or IPFW+natd. pf is what I'd
recommend.)
As far as DNS goes, combining a NAT'ing firewall with a mailserver on
a private interior network leads to another problem: the so-called
'split horizon', where the outside world needs to be able to look up
your mailserver in the DNS and ultimately resolve it to an external
IP address on your NAT gateway, but users on your internal networks
must resolve it to the address of the mailserver on your internal
network. It simply doesn't work for internal machines to attempt
to connect to the public address on the outside of the NAT'ing firewall.
E-mail is a special case here: normally you can fudge such things by
putting the public addresses in the DNS but overriding them locally
by putting the internal addresses in /etc/hosts and setting
nsswitch.conf to prefer lookups from files rather than the DNS (which
is the default setting actually).
However e-mail doesn't co-operate: mail servers insist on using the
global DNS to look up the data they need when sending e-mail. Partly
that's because there's no way of providing an equivalent to the MX
record from within /etc/hosts but mostly it is because both ends of
any e-mail transaction need to have the same idea about how names
resolve to IP numbers. Therefore you will need to make provision in
the DNS for your internal systems to be able to lookup your mailserver
and receive the internal address, while the rest of the world sees the
public address. You can do that either by having a separate internal
DNS server with the local data in it, or by using the 'views' facility
within BIND. See:=20
http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#view_statement_grammar
Now, lets suppose you've chosen to have a border SMTP relay on your
firewall (or, for larger sites, in your DMZ network). Where should
you put the anti-virus and spam filtering function? There or on the
internal mail server? In principal you want it as close to the edge
of your network as you can get it, so that you can reject as much
junk as possible as early as possible. This also means that you can
run your anti-virus and spam filters during the SMTP dialog and reject
messages with a 5xx error before formally accepting them. Otherwise,
technically once a message has passed into your administrative control
you are meant to send a bounce-o-gramme back to the sender if for any
reason the message cannot be delivered. That's fine for things like
a legitimate recipient having an over-full mailbox, but for spam --
all you'll do is end up bombarding innocent third parties whose
addresses the spammers have used to forge the sender address on their
mails. I'm sure you've seen a few such on this very mailing list.
Similarly, your border SMTP relay should "know" what addresses are
valid and what addresses are not, so it can reject messages as
'recipient unknown' at the earliest possible stage. You get this
behaviour for free if all of your mail processing is on one machine.
For more complicated sites, technologies like LDAP are useful for this
purpose: one master list of addresses that is visible network wide and
that all of your mail servers can access. Having a mail system that
will accept messages to any address in a domain is an invitation to be
spammed and spammed and spammed until you don't know which way is up.
If you can't arrange for your border relay to know which the legitimate
addresses are, then your next best option is simply to drop in the
bit-bucket anything to an unrecognised address, but that is nasty
towards any legitimate correspondent who happened to make a typo, and
it does nothing to disabuse the spammers of the idea that their trash is
getting through.
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enig5CE7D6B77AA1F60D66CEE81E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.1 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFm7E+8Mjk52CukIwRCJ1CAJ9EUIsRmR7bN39D5zxPVn4zO2e7JwCfd+5F
uKqbnU1rFvHO0W2TtmgQwmM=
=XMr4
-----END PGP SIGNATURE-----
--------------enig5CE7D6B77AA1F60D66CEE81E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?459BB139.9080306>