Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Background: I am a SQL Server DBA. I have inherited about 50 SQL Servers and need to set up various maintenance plans and alerts. To get the full benefit, I'll also need to configure Database Mail to send emails when jobs fail, alert conditions occur, etc. This requires an SMTP server to relay email (hopefully I got the wording correct there). Since each SQL Server is on its own domain, it seems I will have to install the SMTP feature and configure on a server on each domain. I'm thinking I will do this directly on each SQL Server host.

I followed the step-by-step instructions in this MSDN article. Everything there made sense. After sidestepping a couple of anti-virus roadblocks, I've gotten email to flow through.

Question: What are the security ramifications of installing the SMTP feature? In my proof of concept, I configured SMTP to allow relays from 127.0.0.1 and no one else. Is this considered "secure". Are there other things I'm overlooking?

Update 08/21/2014: It turns out my company has existing access to a Microsoft SMTP server. It's a paid service, I'm told. I inferred from this that MS's SMTP server is not an open relay, per se. I connect to it via anonymous authentication, although I'm not sure how MS knows the sender is one of their paying customers (IP address, maybe?). So in the end, I have a single SMTP server, I don't have to maintain it, and I don't have to install and configure the SMTP feature on countless SQL Servers. Thanks, everyone for your input.

share|improve this question

3 Answers 3

smtp has a LONG history of security failures (sendmail, emacs, et al.). So does MS. Frankly, the LAST thing I would ever do is expect an MS machine to keep incoming smtp secure. We usually put an smtp proxy between any Windows machine providing mail and the Internet (e.g. FreeBSD with postfix configured with anti-spam AV and simple forwarding).

That being said...

If your smtp config is "out-going only" (i.e.: a random machine cannot open a connection to ports 25, 587, and/or 465), then you really have not opened yourself up too dramatically to an attack.

The most likely failure mode on any MTA (not just Windows) is a brute-forced password. In such a case, someone has hammered on your network ports attempting to guess a user/password pair. You can defend against this (not easily with Windows) by monitoring the number of failed authentications from a given IP and/or subnet and modify the firewall accordingly (usually x number of bad auths within t time expiring next day or so). You can also subscribe to RBL's (not easily done in Windows) See: http://en.wikipedia.org/wiki/Realtime_Blackhole_List. You can also configure your firewall or NMS to become upset if there are too many outgoing smtp connections (i.e. your smtp has been compromised and the machine has become a spam-fountain sending out +100 message per minute at odd hours) and either block or alert admins. (Also not easily done with Windows.)

Please note that having a spammer guess a password and turn your server into a spam-fountain is simply the most likely failure mode. A much uglier scenario is one where you expose a weak user/password pair to the Internet at large and thereby allow a script-kiddy to capitalize on authorizations into your servers. You need a serious password policy. You need to put any such in-coming smtp in an isolated DMZ on your network. And you need to monitor the firewall exceptions closely (e.g. install snort)

share|improve this answer

We've ran into a similar use case in that some applications do not support authenticated SMTP which we require for our main email system. We would generally recommend that you have one SMTP server and point all of your db servers at that one server though, just for the sake of simplicity. However, if that is not possible and you really have to install it on each db server make sure to review limiting connections and you'll have a few places to do it depending on your network.

Starting with the SMTP virtual server, click on properties of the server and then access. You'll see a few options in there and you are looking for "Connection Control" and "Relay Restrictions". Set those to the IP of the machines that need access if you only have one SMTP server for many db servers, or set it to 127.0.0.1 or localhost as you've already done to limit to just that server if it is getting installed on each db server.

You'll also have to make allowances in Windows Firewall which you can use to further limit access. In your case if you have to install it on each db server, you can block all inbound SMTP traffic and only allow outbound.

share|improve this answer

Here's a slightly different approach:

Rather than install an SMTP server instance in each of your clients infrastructure why not set up a single instance in your infrastructure? You can then configure Database Mail for each client to relay through your SMTP server. Each client needs to allow outbound SMTP anyway so what does it matter if it's outbound from the SQL Server or from an SMTP server?

You'll reduce your administrative overhead and potentially reduce the attack surface by having only a single SMTP instance to secure.

If you lose a client or they take their business elsewhere it's a simple matter for them reconfigure or disable Database Mail. It's also a simple matter for you to reconfigure your SMTP server in the event.

share|improve this answer
    
I like the idea of a single SMTP server..a lot! If that server resides on domain X and I have clients on domains A, B, C... then what? The SMTP server can't "hide" behind a firewall, can it? It has to allow "outside" traffic, including potential malicious activity from hackers. Am I understanding this correctly? –  DMason Aug 7 at 19:54
    
Yes and no. You do have to allow inbound SMTP to reach the server, but this is no different from any other email server. Any domain that accepts email (microsoft.com, ge.com, ibm.com, etc., etc.) has to allow inbound SMTP traffic to reach their email servers, otherwise they couldn't receive email at and for those domains. –  joeqwerty Aug 7 at 21:14
    
The way to reduce the attack surface in your case would be to allow inbound SMTP traffic on your firewall only from the ip addresses of your clients. Additionally, you could configure your SMTP server to only allow authenticated connections/relaying (which would be recommended) and configure Database Mail to authenticate to your SMTP server. –  joeqwerty Aug 7 at 21:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.