Recommended UFW settings for mailserver with postfix/dovecot
I am setting up a simple server to serve up websites and also serve as a mailserver all together. The mail service will be small just used by me to administer mail for my personal sites and I'm just using Thunderbird from my local machine to connect. I followed a tutorial for setting up mail with mysql and using virtual users, aliases and domains Link to tutorial. I have not yet set up spamassasin.
I am curious what the recommended ufw settings are for securing mail. Right now I just have the following configuration:
To Action From
-- ------ ----
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
Dovecot Secure IMAP ALLOW Anywhere
Postfix Submission ALLOW Anywhere
22/tcp ALLOW --my home ip--
Postfix ALLOW Anywhere
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
Dovecot Secure IMAP (v6) ALLOW Anywhere (v6)
Postfix Submission (v6) ALLOW Anywhere (v6)
Postfix (v6) ALLOW Anywhere (v6)
I have fail2ban to jail anything that fails 5 login attempts with the following services:
Status
|- Number of jail: 4
`- Jail list: dovecot, postfix, postfix-sasl, sshd
I am wondering if there are some other recommended settings that I should be using to further secure the mail ports.
I do get what I can only assume are bots trying to find email addresses. Like so:
Sep 13 14:17:42 webserver postfix/submission/smtpd[25008]: connect from unknown[173.214.174.60]
Sep 13 14:17:42 webserver postfix/submission/smtpd[25008]: lost connection after CONNECT from unknown[173.214.174.60]
Sep 13 14:17:42 webserver postfix/submission/smtpd[25008]: disconnect from unknown[173.214.174.60] commands=0/0
Sep 13 14:17:44 webserver postfix/submission/smtpd[25008]: warning: hostname vps276013.trouble-free.net does not resolve to address 173.214.174.60: Name or service not known
Sep 13 14:17:44 webserver postfix/submission/smtpd[25008]: connect from unknown[173.214.174.60]
Sep 13 14:17:44 webserver postfix/submission/smtpd[25008]: Anonymous TLS connection established from unknown[173.214.174.60]:
TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Sep 13 14:17:44 webserver postfix/submission/smtpd[25008]: NOQUEUE: reject: RCPT from unknown[173.214.174.60]: 554 5.7.1 <[email protected]>: Recipient address rejected: Access denied; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<int-vm.domain>
Sep 13 14:17:44 webserver postfix/submission/smtpd[25008]: lost connection after RCPT from unknown[173.214.174.60]
Sep 13 14:17:44 webserver postfix/submission/smtpd[25008]: disconnect from unknown[173.214.174.60] ehlo=2 starttls=1 mail=1 rcpt=0/1 commands=4/5
Sep 13 14:17:57 webserver postfix/submission/smtpd[25008]: warning: hostname vps276013.trouble-free.net does not resolve to address 173.214.174.60: Name or service not known
Sep 13 14:17:57 webserver postfix/submission/smtpd[25008]: connect from unknown[173.214.174.60]
Sep 13 14:17:57 webserver postfix/submission/smtpd[25008]: Anonymous TLS connection established from unknown[173.214.174.60]:
TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Sep 13 14:17:57 webserver postfix/submission/smtpd[25008]: NOQUEUE: reject: RCPT from unknown[173.214.174.60]: 554 5.7.1 <[email protected]>: Recipient address rejected: Access denied; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<int-vm.domain>
Sep 13 14:17:57 webserver postfix/submission/smtpd[25008]: lost connection after RCPT from unknown[173.214.174.60]
Sep 13 14:17:57 webserver postfix/submission/smtpd[25008]: disconnect from unknown[173.214.174.60] ehlo=2 starttls=1 mail=1 rcpt=0/1 commands=4/5
Sep 13 14:18:24 webserver postfix/smtpd[25012]: warning: hostname vps276013.trouble-free.net does not resolve to address 173.214.174.60: Name or service not known
Sep 13 14:18:24 webserver postfix/smtpd[25012]: connect from unknown[173.214.174.60]
Sep 13 14:18:24 webserver postfix/smtpd[25012]: lost connection after CONNECT from unknown[173.214.174.60]
Sep 13 14:18:24 webserver postfix/smtpd[25012]: disconnect from unknown[173.214.174.60] commands=0/0
Sep 13 14:18:30 webserver postfix/smtpd[25012]: warning: hostname vps276013.trouble-free.net does not resolve to address 173.214.174.60: Name or service not known
Sep 13 14:18:30 webserver postfix/smtpd[25012]: connect from unknown[173.214.174.60]
Sep 13 14:18:32 webserver postfix/smtpd[25012]: NOQUEUE: reject: RCPT from unknown[173.214.174.60]: 554 5.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=SMTP helo=<int-vm.domain>
Sep 13 14:18:32 webserver postfix/smtpd[25012]: lost connection after RCPT from unknown[173.214.174.60]
Sep 13 14:18:32 webserver postfix/smtpd[25012]: disconnect from unknown[173.214.174.60] helo=1 mail=1 rcpt=0/1 commands=2/3
Sep 13 14:18:48 webserver postfix/smtpd[25012]: warning: hostname vps276013.trouble-free.net does not resolve to address 173.214.174.60: Name or service not known
Sep 13 14:18:48 webserver postfix/smtpd[25012]: connect from unknown[173.214.174.60]
Sep 13 14:18:48 webserver postfix/smtpd[25012]: NOQUEUE: reject: RCPT from unknown[173.214.174.60]: 554 5.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=SMTP helo=<int-vm.domain>
Sep 13 14:18:48 webserver postfix/smtpd[25012]: lost connection after RCPT from unknown[173.214.174.60]
Sep 13 14:18:48 webserver postfix/smtpd[25012]: disconnect from unknown[173.214.174.60] helo=1 mail=1 rcpt=0/1 commands=2/3
Sep 13 14:22:08 webserver postfix/anvil[25010]: statistics: max connection rate 3/60s for (submission:173.214.174.60) at Sep 13 14:17:57
Sep 13 14:22:08 webserver postfix/anvil[25010]: statistics: max connection count 1 for (submission:173.214.174.60) at Sep 13 14:17:42
Sep 13 16:19:45 webserver postfix/smtpd[2177]: warning: hostname zg-0823b-39.stretchoid.com does not resolve to address 192.241.228.172: Name or service not known
Sep 13 16:19:45 webserver postfix/smtpd[2177]: connect from unknown[192.241.228.172]
Sep 13 16:19:45 webserver postfix/smtpd[2177]: disconnect from unknown[192.241.228.172] ehlo=1 quit=1 commands=2
Sep 13 16:23:05 webserver postfix/anvil[2179]: statistics: max connection rate 1/60s for (smtp:192.241.228.172) at Sep 13 16:19:45
Sep 13 16:23:05 webserver postfix/anvil[2179]: statistics: max connection count 1 for (smtp:192.241.228.172) at Sep 13 16:19:45
Sep 13 16:23:05 webserver postfix/anvil[2179]: statistics: max cache size 1 at Sep 13 16:19:45
I don't really know what I'm looking at here and I don't know if this is normal or something to worry about. Its my understanding that postfix/smtpd is incoming mail so idk if this is just probing for email addresses or what.
If there's anyone out there with some experience doing this that can steer me in the correct direction to make a fairly secure mail service. Also let me know if there are anything in the logs I need to worry about.
Any help is appreciated.
What you're seeing in the logs is spammers attempting to use your mail server to send their messages. It would obviously be very bad if they succeeded at this, but it's very common for online mail servers to get a lot of random attacks aiming at them. The mere fact that there are incoming attacks on your mail server is not at all surprising, so what you care about is not whether they're being made, but rather to ensure that they don't succeed.
We can see two different attacks being attempted by the spambots in your logs, so I'll take those in turn.
Attacks trying to use your mail server as a relay
Postfix can act as an email relay, receiving emails from servers all over the Internet, then delivering them to the appropriate destinations. You need to have this functionality enabled to some extent, because you want to receive emails addressed to your mail server. This means that you can't use a firewall like ufw to save your mail server from this sort of attack; you could legitimately receive a connection from any other mail server on the internet, and it's hard for ufw to know which IP addresses are mail servers.
This sort of connection arrives on port 25 (both for legitimate and malicious connections), and will be received by postfix/smtpd.
Normally, your best way of preventing this type of attack is to configure your mail server to refuse to relay any messages to outside addresses; you want it to deliver email addressed to you, but not to relay email addressed to anyone else. We can see a number of "relay access denied" messages in your logs, so the mail server is probably correctly secure against this sort of attack already.
However, it's very important to make sure that your mail server is not an open relay and cannot be made to act as one. If you want peace of mind that it's configured correctly in this respect, you should use an open relay checker; in my experience, this open relay checker is the most comprehensive at trying to find exploits that might cause your mail server to relay a message it shouldn't (the output you want is "Relay NOT Accepted" after every attempt). If a tool like that can't figure out how to get your mail server to relay a message, then most likely the spammers won't be able to either.
If the log lines showing failed attempts to relay bother you, then although you won't be able to configure ufw to reject the attempts, you may be able to configure fail2ban to block further attempts for a while, after the first few fail. On recent versions of Ubuntu, the configuration for the postfix jail has fairly permissive settings by default. You can make them more restrictive, blocking a wider range of attacks against Postfix, by adding mode = aggressive to the relevant section of the jail file in the fail2ban configuration. For example:
[postfix]
enabled = true
mode = aggressive
This is unlikely to have much of an impact, though, because email relays can't be "brute forced" to relay a message; either they're configured to allow it, or they aren't. So the vast majority of spambots will naturally give up trying after one or two relay attempts fail, and thus they'll never reach enough failed attempts to trigger fail2ban.
Attacks trying to submit email via your mail server
In addition to acting as an email relay for emails that are already "in the email system", Postfix can also act to allow email submission of emails that do not come from a mail server; a legitimate user who wants to send email will get their email client to connect to Postfix, tell it the message they want to send, and Postfix will then send it to the recipient's mail server. Obviously, if you want to be able to send email, you have to configure your system to allow this.
This sort of connection usually arrives on port 587 (again, for both legitimate and malicious connections; this is probably what is listed as "Postfix Submission" in your ufw configuration), and will be be received by postfix/submission/smtpd.
If a spambot were capable of submitting email via your mailserver, then it would, in effect, be able to send spam that looked like it came from you (with all the appropriate headers). That would obviously be a problem. As such, it's important that the submission port does not relay messages from anyone that it doesn't identify.
Lines in your logs like … submission … NOQUEUE: reject: … Recipient address rejected: Access denied worry me a bit, because I don't see any random attacks getting that far in my own configuration (I only have one line like that in my own logs, and it was for an email I was trying to send legitimately, but in a situation where a misconfiguration meant that my password couldn't be verified). However, you probably nonetheless still have a fairly secure configuration in this respect: the attempt to submit the email was rejected, presumably because the spambot did not authenticate with a valid username/password pair for your system.
My guess about the difference in configuration between your system and mine is that mine has -o smtpd_tls_auth_only=yes in the submission section of master.cf; this requires the email software that's sending the email to send the username and password only over TLS (and will hide the fact that a username and password is required until it does). In my experience, this is fairly effective in reducing attempts by spambots to brute-force my email password; most of them don't want to try to set up a TLS connection for each password attempt (and some of the spambots that try are using outdated TLS libraries and can't figure out how). Of course, you should only set that setting if you have your own email client configured to use TLS!
Anyway, you say that this is a personal mail server; are you going to be the only person who ever sends email via the server, and will it always be from the same IP? If so, then your firewall rules are more permissive than they need to be. ufw is currently set to allow access to the "submission" port from "Anywhere". If you're the only person who should ever be submitting email to be sent elsewhere, then there's no reason to allow anyone else to attempt this, and you can set the firewall rules more restrictively, allowing connections only from your IP.
Because this is the sort of attack in which brute-forcing a password could be helpful (because it's only your username/password that protects the submission port at the moment), fail2ban can also help. Setting the postfix jail to use a more aggressive configuration seems to have made a big difference to my mail server, greatly reducing the number of attempts that random password-bruteforcing attempts can make.
Extra security: protecting against attacks on your email inbox
The logs you've posted don't show any attempts to attack Dovecot. In my experience, these attacks are rare; spambots are normally more interested in sending mail than they are in reading your mail. Nonetheless, you do see the occasional random attack on Dovecot. (One reason for this may be that most people use the same password for sending email and reading their email, so if a spambot can brute-force the password to your email inbox, it can then attempt to use the same password to submit email.)
If your mail server is only intended for the use of one person, then just as only one person should ever be sending email, only one person should ever be reading email. As such, it makes sense from a security point of view to lock down Dovecot's port (usually IMAP) in the same way that you would lock down the Postfix submission port, restricting access to IMAP to only the IPs from which you would read your email.