If you’re seeing a lot of messages about untrusted TLS connections in your mail log when running postfix like this…
Untrusted TLS connection established to ASPMX.L.GOOGLE.com[220.127.116.11]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
… there’s a pretty easy fix.
This post is as much to help me remember as it is to help other people.
Below is a list (not comprehensive) of the postmaster resource pages for some of the major email providers.
On these sites you can get information about how the provider handles spam, feedback loops, blacklists, whitelists, etc.
Very useful for those managing mailing list servers.
Spammers quite often ‘spoof’, or fake, the from address of an email.
As a result of this, many unsuspecting domain owners are being ‘blamed’ for spam that appears to come from their domain.
Fortunately, there is a relatively easy way to protect your domain from this: Publish DMARC policies.
If you are publishing SPF records and signing your email with DKIM, you can publish DMARC policies that tell receiving mail servers what do with emails that don’t align with the SPF and DKIM information.
SPF policies are DNS records that indicate what mail servers your mail is sent from.
DKIM is a way to add digital signatures to your email so that receiving mail servers can verify it was sent from an authorized source and that it wasn’t modified in transit.
Now what if you have a domain that you NEVER send email from?
Protecting those domains from being used in spam is even easier.
If you run a wordpress blog, you really should be aware that there is a global attack on wordpress blogs going on.
It’s coming from a bot net and is an attempt to find blogs that have their admin account enabled with easy to guess passwords.
I noticed the attack a couple of months ago when, while watching my web server log scrolling by, I noticed a significant number of attempts to use the wp-login.php script from random IP addresses.
A bit of research turned up information on the global attack.
Obviously I wanted to do something about it to protect my server.
Over the holiday weekend, I experienced the ultimate computer security mechanism:
I was using my new Dell Latitude E6420 to do some network reconfiguration when the machine started acting weird with regard to the network.
Since this machine runs Windows 7, I decided to just reboot it to clear the network configuration.
After I restarted the machine I was asked for a password by the BIOS.
The odd thing was … I never set a BIOS password.
This morning the SSH scan detector software that I run (DenyHosts) sent me an email indicating that it had detected a SSH scan and blocked the host.
The host name it reported did not appear to be a dynamic host (like those usually assigned by DSL provider), so did a little digging to identify who owned the system.
I notified Terry about the problem … and they replied …
I just checked the .100 address and found that I had (in an unbelievable amount of stupidity) left a test account on the system, and someone from Italy was actively engaged in running an SSH scan from that account. I contacted their ISP, hopefully they will do something about it. I removed the account, and will be taking the machine down momentarily to be rebuilt after I back some data off of it. How embarrassing. Thanks for letting me know. I suppose it is time for me to install that bridging firewall running snort I’ve been meaning to build… gah!
Glad I could help, Terry. Chalk one up for the good guys.
[tags]ssh, security, linux[/tags]