LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Hardening mailserver (https://www.linuxquestions.org/questions/linux-security-4/hardening-mailserver-920230/)

tva 12-23-2011 01:20 PM

Hardening mailserver
 
I had this incident while ago where one of users on my mailserver had her account information stolen by worm, or sniffed from unencrypted wlan etc. We noticed that when someone sent some 50000 spam emails one night in just 2 hours. Then we locked her account and examined the source of spam and saw from the logs what had happened. I checked logs and didn't see any bruteforce attempts on her (or anyone elses) account, so I thought that it must have been virus, worm, unencrypted wlan or whatever. What made it worse is that I recently disables spam checking for authenticated users (yes, it was stupid), so every mail got sent.

So, it's very likely to happen again and there I need your advice. How to stop or atleast slow down spammer in those situations? I recently put iptables rules to limit connections to 10/minute/ip on smtp port but that won't stop spam, just slows it down a little. How can I put limits to sent emails on some interval on server, or is there a way to lock down account if it sends too much email in certain amount of time?

Any tips regarding this matter?

Software I use is postfix/amavisd/dovecot. Dovecot provides sasl auth for postfix and it uses same usernames/passwords as users do when reading mail.

travisdh1 12-23-2011 03:17 PM

Have you looked at using the baracuda networks free filter? Just enabling that has made our junk mail problems go from terrible to manageable. (Sorry I don't have time to find the link for you.)

tva 12-24-2011 04:12 AM

I haven't but I'll take a look.
Junkmail isn't that big problem because I do have very efficient filtering, it just wasn't enabled for authenticated users. So what I'm looking for, is more like rate control than filtering, I think. But thanks for reply, I'll check that one for sure.

Noway2 12-28-2011 02:48 PM

Just to clarify, your 'problem' is that someone used one of your user's credentials to sent OUTBOUND email from your server. You are not facing an inbound problem.

Whether or not Postfix will transmit the message will depend upon the permissions you set. For example, you can use permit my networks, permit SASL authenticated etc. Based upon your post I gather that this was an SASL authenticated user. My first question is are you using TLS to encrypt the connection? The Dovecot SASL is performed in plain text. Unfortunately, Postfix does not support hashing but it will support using an encrypted connection. If you are not using it, or allowing connections without it, it would be entirely possible for someone to sniff your user's credentials and use the account to spam from. This would also fit with the lack of brute force log attempts.

Postfix does support some rate limit functions, but off hand I can't think any of them that will do what you want. Really the best thing to do would be to glance through the pages on Postfix.org and read the descriptions. There is an absolute boatload of options that can be used in any of the various recipient and sender checks.

Since you are using Dovecot, you could also incorporate a tool such as Amavis and Spamassassin which will scan outbound mail too and you could block messages based upon a high spam score.

tva 12-28-2011 03:22 PM

Thank you for your reply.

I do have amavisd but it wasn't enabled for sasl-authenticated users. It is now. I use dovecot SASL and pretty much default settings on that, have to check how postfix is configured bur I recall it is not enforcing encryption in any way. I'll check if I find something on Postfix website that suits my needs.

Noway2 12-29-2011 07:42 AM

You can tell if Postfix is using it by the designation of TLS at the end of the authentication line in the log. For example:
Code:

Dec 25 06:45:43 server dovecot: imap-login: Login: user=<me@my.server>, method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=yyy.yyy.yyy.yyy, TLS
Enabling TLS in Postfix is rather easy. You will need to create a certificate, which is straight forward. To use TLS in Posftix, see the following, which goes in main.cf:

Code:

# TLS parameters
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
tls_random_source = dev:/dev/urandom
smtpd_tls_loglevel = 0
smtpd_tls_received_header = no
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.


tva 12-29-2011 04:07 PM

Thanks for reply, I'll check logs tomorrow if I have time. I do have certificate and postfix is configured to use it if other end supports it (starttls) but not sure if there is enforcing.

So I need to check this from my configs (adding link if other people have same problem as I had)
http://www.postfix.org/postconf.5.ht...security_level

Thanks for kicking me to right direction, I'll update later if I manage to find something usefull for rate limiting. If not, I'll mark this solved after few days.

rhbegin 12-29-2011 08:01 PM

If I am not mistaken you can use http://policyd.sourceforge.net/readme.html to enforce emails sent in a specific time interval.

I have been there and had that happen and one of the email servers got blacklisted. I put limits in place to allow 500 emails in 24 hours, unless they are a business and/or need to send out more exceptions can be made.

Barracuda's can be used for outbound filtering as well (with the version 5+ firmware), I recently retired 2 clustered Barracuda's in place for *Watch Guard XCS* devices (a lot better in my opinion and FAST. They can filter inbound and outbound as well (very granular), they are only setup for inbound right now. However, with the policy in place on the email server 'caps' on every account it is easy to find an account that was exploited.

Plus, I would not have ports 110/143 open to the public Internet, you can get an SSL certificate from godaddy for a small amount and put a multi-domain certificate on the server (works GREAT). Then you can utilize the SSL ports and close the others. (Or you could limit the access to non-secure ports with ip chain rules).

Also, in the netfilter rules I have a limit in place on each port coming in, so someone with a dictionary attack and/or DoS attack is futile as it will drop the traffic.

Email servers are a prime target, facing the public Internet and email accounts will get exploited since end users (work for an ISP) will enter their information on malicious websites without batting an eye.

tva 12-29-2011 11:49 PM

Quote:

Originally Posted by rhbegin (Post 4561409)
If I am not mistaken you can use http://policyd.sourceforge.net/readme.html to enforce emails sent in a specific time interval.

I have been there and had that happen and one of the email servers got blacklisted. I put limits in place to allow 500 emails in 24 hours, unless they are a business and/or need to send out more exceptions can be made.

Barracuda's can be used for outbound filtering as well (with the version 5+ firmware), I recently retired 2 clustered Barracuda's in place for *Watch Guard XCS* devices (a lot better in my opinion and FAST. They can filter inbound and outbound as well (very granular), they are only setup for inbound right now. However, with the policy in place on the email server 'caps' on every account it is easy to find an account that was exploited.

Plus, I would not have ports 110/143 open to the public Internet, you can get an SSL certificate from godaddy for a small amount and put a multi-domain certificate on the server (works GREAT). Then you can utilize the SSL ports and close the others. (Or you could limit the access to non-secure ports with ip chain rules).

Also, in the netfilter rules I have a limit in place on each port coming in, so someone with a dictionary attack and/or DoS attack is futile as it will drop the traffic.

Email servers are a prime target, facing the public Internet and email accounts will get exploited since end users (work for an ISP) will enter their information on malicious websites without batting an eye.

Thank you for your reply. I'll check out that program too. As I wrote earlier, I do have SSL certs and some iptable rules to limit incoming connections. We have also thought about going to use external mail filtering device / service (in our case it would be F-Secure PSE) but atleast for now, we handle contentfiltering ourselves. Can't disable ports 110/143 due to some customers.

tva 12-30-2011 03:10 AM

So I checked confs and logs and found out that only fraction of users use TLS encryption when fething their mail. I think I'll inform users that we'll stop using unencrypted connections and put smtpd_tls_auth_only (or similar) configuration in effect. I'll give users a week or so after notifying them and then start using TLS and after that, well, I suppose I'll have to answer to "some" helpdesk calls :)

Also I found something about rate control (first google hit, duh) here http://www.porcupine.org/postfix/doc/rate.html.

rhbegin 12-30-2011 08:23 AM

Since I work at an ISP, I combed through the logs and found the smart phone IP ranges for ATT, Sprint, Verizon (time consuming). What I was battling was weak passwords put in place in the past before a password policy was enforced.

So I allowed all to 110/143 through the ISP ranges, then allowed only the smart phone IP ranges to the 110/143 initially to limit the havoc of breached accounts with 4 character passwords.

What I did next, was migrate the data to a new email server with SSL certificates, allowing the 110/143 only the telco range and everyone else outside of that uses 995 or 993 and 465/25 for outgoing.

With email it is always going to be challenging to keep it secure, I found with the Watch Guard XCS devices (pretty good size units), they handle the volume of email more efficiently than the Barracuda 800's did. (The biggest difference is Denial of Service attacks, a daily event at an ISP) The XCS's chop the connection and drop it, the Barracuda's were taken down on several occasions not good. The entire point of these expensive devices is to withstand all of the brutal assault, but not all environments are the same. I believe there is roughly about 40,000 emails coming in per hour only about 2% is valid. :cry:

The most effective tool I put in place was limiting the amount of email sent in 24 hours, capped it at 500 and a few needed more than that and they have been allowed through policy. Once I locked down the 110/143 ports it cut down a lot on malicious attacks and exploited accounts. Also, I put in a policy to lock accounts not used in 90 days, this way I can weed out the insecure passwords when they call the helpdesk. Weak passwords put in the place in the past, are still a pain, this leads to millions of accounts being exploited daily.

Migrating email servers is about as easy has having dental work performed without your mouth being numbed. Once you are finished, you are mentally wore out with the shear volume of data having to be perfect for all users.

What does your ipchain rule look like for your limiting connections?


*GREAT* find on the postfix link to I am going to save that one!

:)

tva 12-30-2011 05:02 PM

Quote:

Originally Posted by rhbegin (Post 4561719)
What does your ipchain rule look like for your limiting connections?

I'm not using ipchains but iptables, it's about 10 years since I last used ipchains :)

Since ipchains is stateless I don't think this is possible with it.

But anyways this is what I use, pretty much basic logging/dropping script copied from somewhere. LOGDROP table is also used for other logging so thats why there is other protocols listed too. Notice "reverse" order on INPUT table since Insert is used instead of Append.
This only limits incoming connections, can't really limit outgoing too much, atleast not on business hours.

Code:

iptables -N LOGDROP
iptables -A LOGDROP -p tcp -m limit --limit 5/min -j LOG --log-prefix "firewall Denied TCP: " --log-level notice
iptables -A LOGDROP -p icmp -m limit --limit 5/min -j LOG --log-prefix "firewall Denied ICMP: " --log-level notice
iptables -A LOGDROP -p udp -m limit --limit 5/min -j LOG --log-prefix "firewall Denied UDP: " --log-level notice
iptables -A LOGDROP -p icmp -m limit --limit 5/min -j LOG --log-prefix "firewall Denied ICMP: " --log-level notice
iptables -A LOGDROP -j REJECT --reject-with icmp-host-prohibited
iptables -I INPUT -p tcp --dport 25 -m state --state NEW -m recent  --update --seconds 60 --hitcount 10 -j LOGDROP
iptables -I INPUT -p tcp --dport 25 -m state --state NEW -m recent  --set



All times are GMT -5. The time now is 06:50 PM.