From owner-freebsd-questions@FreeBSD.ORG Wed Jan 3 13:36:29 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BB0016A407 for ; Wed, 3 Jan 2007 13:36:29 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.187.76.162]) by mx1.freebsd.org (Postfix) with ESMTP id 746E313C458 for ; Wed, 3 Jan 2007 13:36:27 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from [IPv6:::1] (localhost.infracaninophile.co.uk [IPv6:::1]) by smtp.infracaninophile.co.uk (8.13.8/8.13.8) with ESMTP id l03DZwxP095747; Wed, 3 Jan 2007 13:35:59 GMT (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <459BB139.9080306@infracaninophile.co.uk> Date: Wed, 03 Jan 2007 13:35:53 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 1.5.0.9 (X11/20061223) MIME-Version: 1.0 To: Mohamad Babaei References: <5bf3a41f0701030128gd2ce04wb6fe8df882aa80e2@mail.gmail.com> In-Reply-To: <5bf3a41f0701030128gd2ce04wb6fe8df882aa80e2@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5CE7D6B77AA1F60D66CEE81E" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Wed, 03 Jan 2007 13:36:14 +0000 (GMT) X-Virus-Scanned: ClamAV 0.88.7/2410/Wed Jan 3 12:58:16 2007 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_TESTING,NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-questions@freebsd.org Subject: Re: Setting another machine as a firewall X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2007 13:36:29 -0000 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--