On 2/04/2013 14:08, Sam Varshavchik wrote:
> Mark Constable writes:
>
>> On 04/02/13 09:17, Sam Varshavchik wrote:
>> >> I set up one small VPS as an alternate outgoing mail server for those
>> >> times when our main mailservers gets blacklisted and do not want
>> it to
>> >> handle incoming mail or act as a 2nd MX.
>> >
>> > But how are you getting mail to your backup outgoing server? Probably
>> > by SMTP from your main servers, so you can't really shut down smtp.
>>
>> It's a VPS, as in a virtual private server, not a VPN although I should
>> have considered that option.
>>
>> Main mailserver gets blocked, clients who have issues are advised to
>> change
>> their outgoing mailserver setting to alternate server, they otherwise
>> send
>> normally (ie, authenticated via ports 465/587) and this server relays
>> these
>> messages to the rest of the world from a different source address.
>>
>> I just don't want any mail from the outside world coming back into this
>> server via port 25 and would rather not have port 25 even showing up in
>> a port scan so potential spammers don't even try.
>>
>> Ideally, on this server, I just want to expose ports 22 and 587 and
>> that's
>> all. The port 587 authentication is done via a ssh tunnel back to the
>> main servers MySQL database so even port 3306 is not exposed (either
>> end).
>
> I don't think you need to have your clients change their outgoing mail
> server.
>
> Change your backup mailserver's primary hostname/domainname to some
> dummy, internal label, like 'backup.local'. So, by default, the backup
> mail server won't accept any mail for any real domain. Attempting to
> deliver any mail to it, for any domain, would, by default, get
> rejected as a relaying attempt. You don't need to change the addresses
> or the ports it's listening on, by default. Let it be open. Courier's
> pretty good at ignoring someone banging on its ports. Just the other
> day I watched as someone tried to tried password cracking, via
> authenticated SMTP, with Courier ending up dropping most connection
> altogether, since they quickly exceeded the default setting of four
> connections from the same IP address.
>
> Anyway, just list your primary mail server's IP address in your backup
> server's smtpaccess, with RELAYCLIENT set, so your primary is able to
> connect to your backup server, and relay/smarthost all outgoing mail.
>
> When you want to do that, put your backup server into your primary's
> esmtproutes:
>
> : backup.domain.com
>
> And Courier will then start sending out all outgoing mail through your
> backup server. Your clients can still connect and authenticate to your
> primary, which will forward all of its mail through the backup.
>
> You can have varying levels of security configured. The default would
> be good enough for most simple situations. Short of someone hijacking
> your IP address, the backup MX will only accept mail from your
> primary, because only its IP address has RELAYCLIENT set.
>
> You could even go the full hog, and set up the SECURITY STARTTLS
> Courier-only extension, with a private certificate authority, and
> require the primary and the backup server exchange privately-signed
> certificates, before they'll agree to swap mail. That's going to be
> pretty much as nailed down as it could possibly get – but in all cases
> you'll want RELAYCLIENT set only for your primary's IPs.
There's also the option of playing with iptables, which can do all of
this as well either instead of the above, or in addition to for extra
tightening of the system.
Set your firewall rules like this and you'll achieve the same effects as
what's been discussed so far:
allow all inbound traffic on loopback ("-i lo -j ACCEPT");
accept connections to port 22 and any email input ports from end users
(ie port 587) on all interfaces ("-p tcp --dport 22", etc.);
allow all SMTP traffic from your primary host ("-i <inside interface> -p
tcp -s <primary MX ip> --dport 25");
allow inbound replies to outbound traffic ("-i <outside interface> -m
state --state=ESTABLISHED,RELATED"); and
drop the rest via the INPUT chain policy (":INPUT DROP")
Either then put ":OUTPUT ACCEPT" as the policy for the OUTPUT chain, or
(be careful here so that you don't lock yourself out of the system):
allow all outbound traffic on loopback ("-o lo -j ACCEPT");
allow traffic for existing connections ("-m state
--state=ESTABLISHED,RELATED");
allow all traffic out heading TO port 25, 465 and/or 587 as appropriate
("-p tcp --dport 25", etc.);
allow SSH traffic out ("-p tcp --sport 22");
allow SMTP traffic to primary host ("-o <inside interface> -p tcp -d
<primary MX ip> --dport 25"); and
drop the rest via the OUTPUT chain policy (":OUTPUT DROP").
Typically, I will set my firewall(s) to only allow the traffic I need to
come in to the system, only install packages via apt-get from the Debian
sources and use ":OUTPUT ACCEPT" as I trust myself to not let my servers
become bad netizens without my involvement, and I usually treat traffic
coming in to a firewall system from the LAN in the same way until I
notice bad behaviour from a device on the LAN ("-i <inside interface> -o
<outside interface> -j ACCEPT" and "-m state -i <outside interface> -o
<inside interface> --state ESTABLISHED,RELATED -j ACCEPT").
And to stop the bots who keep trying to knock on port 22 or "address
hunt" on port 25, fail2ban is a very effective tool, but currently I
don't have port 22 open at all as I establish a certificate-based VPN
connection on port 1194 to my home, then I can connect to my servers.
With all of the firewalling done, you can then set Courier to listen on
0.0.0.0:25, 0.0.0.0:465 & 0.0.0.0:587, but use iptables to limit who can
actually get through and on which ports.
Hope this helps (or at least gives you some more food-for-thought).
Cheers,
Tim Lyth
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
