TOP

Reducing SPAM on your Postfix Mail Server with the Help of Public RBL/DNSBL Black Lists

A few months ago, we wrote about using “grey listing” on your mail server to help reduce SPAM. While, this concept works great in practice, it does have one major flaw that may affect your users if they are using their mail in time critical environments. Since grey listing initially rejects the mail and waits for a second attempt from the sending mail server to deliver the mail (SPAM servers usually only try one attempt) this eliminates the “instant” delivery of your emails. We all know that emails should never be depended on to be delivered instantly, but these days it’s very close to instant, majority of the time.

As a result, we want to share some other methods on how to reduce incoming SPAM to your mail server and users while preserving the quick delivery so many users count on each day. After all, we live in a world where expectations in technology are consistently rising.

Using a publicly available Black List Database, also known as RBL’s or DNSBL’s (DNS Block List, or Real Time Black Hole List) will allow your mail server to connect and verify whether the sending server is known as a SPAM sender. While there are many different types of Black List’s on the Internet, and we cannot guarantee (nor can they) that they are 100% effective in blocking SPAM, we would like to share a list of the common ones that we have used and are effective.

What to look for in a DNSBL Database

What you want to look for is a well maintained project (since this will be making decisions for you in real time) and one that is well known not to have what are called “False Positives.” In all cases, what you want to avoid when implementing an automated system like this, is the rejection of legitimate email.

DNSBL’s Suggested

The DNSBL’s that we have seen to be effective include the following:

  • zen.spamhaus.org
  • xbl.spamhaus.org
  • rbl.spamhaus.org
  • b.barracudacentral.org
  • bl.spamcop.net

DNSBL’s to Avoid

  • blackholes.five-ten-sg.com

Five-ten-sg.com is very prone to listing entire subnets (up to /24 in some cases) rather that listing individual /32 IP addresses. As a result, using this black list is very prone to attracting false positives and it is not up to date. There are many stale records that we have encountered in this database, sometimes including domains such as Apple’s @me.com and Googles @gmail.com. Avoid this database at all costs.

Implementation

Once you have researched which database (or combination of databases) you want to use, implementing it in postfix is as simple as adding one line for each database you want to include in your main.cf file.

Find the following line in your main.cf file:

smtpd_recipient_restrictions =

Add the following to what is already there:

reject_rbl_client pbl.spamhaus.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client xbl.spamhaus.org,

Again, you can use as many databases you like. In the case of spamhaus.org, it’s best to visit their website to see what the criteria is for getting on to the database (some are more strict than others).

Overall, using a DNSBL is effective in helping with reducing the amount of incoming SPAM on the network. It is a database that works in real time, and there are professionals out there who contribute information to these databases daily to help reduce the amount of SPAM on the public internet.

Read More
TOP

Using Email Greylisting to Reduce SPAM

One of the most common problems faced by anyone hosting a mail server in today’s internet world is SPAM. Whether it comes from the outside world to your clients or originating from your clients themselves. Every server administrator will need to deal with this at some point. This article is to clarify what “Greylisting” means, what it will do, what it won’t do and hopefully give you enough information to decide whether or not it’s a good idea for your environment.

In short, Greylisting does two main things. The first, is to temporarily reject the first email received from a non-whitelisted sender, the second is to keep a list of possible spam servers to chose whether or not to reject the first email.

This does sound a little weird at first, but the methodology behind rejecting the first email comes from a basic principle. SPAM servers generally send a lot of mail OUT. The faster the better (in most cases) as Administrators try to shut down these servers through blacklist databases all the time. Since these servers gernerally process a large amount of outgoing mail from potentially old mailing lists or manually created ones in some cases, most spammers don’t always know what email accounts actually exist. Going on this priciple, majority of SPAM server will not try to deliver mail more than once (ie: if it sent mail gets rejected it will not try and resend it). A properly configured mail server will try multiple times before sending it back undelivered.

As a result, Greylisting takes advantage of this by initially denying the message and waiting for the origin server to re-send it. If it receives a second request for the original message then it will accept and deliver it locally.

The most common configuration we use on our networks utilize Postfix mail servers with a plugin called PostGrey.  Although I won’t get into the configuration of PostGrey here, there are many articles online that can help you out.

Is Greylisting Right for You?

The reason you need to ask yourself this question is that it can provide benefits but at a small cost. Since Greylisting initially rejects the first email message, the immediate implications are that you will not get “instant” delivery of your mail. While most providers will never say that email delivery is instant by nature, it’s generally very fast. Normally within 1 minute of it being sent it should be received at the other end.

So if you are running a mail server that forwards messages to blackberrys or various handheld devices, these mobile users need to know that they will not get their messages “instantly” when they are sent by another user.

Also, mail servers can be configured in different ways. While most don’t wait very long to re-send a message, depending on the configuration the message could take up to 10 minutes to be re-sent. So it may not be a good idea to use this on a support or high-availability help-desk style situation.

The good news: You can exclude certain mail accounts from grey-listing. So you can still install and configure PostGrey on your server and specify which mailboxes to not Greylist.

Conclusion

GreyListing is very effective if you understand how it works and behaves. When used correctly it will reduce the amount of SPAM destined to your users by a very large factor (it did for us, but your mileage may vary).  In turn, this will reduce the amount of work other filters that are installed will need to do (IE: spamassassin etc…) thus allowing you to use much less resources for processing mail and limiting it to real mail in most cases.

 

Read More
TOP

Simple Certificate Based SSH Authentication for your VPS

As a sequel to my first blog post (Simple Ways to Secure the SSH Port on your VPS) I am adding a simple tutorial on how you can setup Certificate based SSH authentication.

The reason someone would implement this method is to avoid using plain-text passwords. This way, anyone who does not have the client-side certificate installed in their SSH client will not be able to login to the VPS.

Overview

There are 3 things that we will need to do in order to get this to work:

  1. Create a Public/Private SSH Key on the Client Computer
  2. Create the Public Key file on the VPS (Server)
  3. Disable password based authentication on the Server

I need to stress at this point, do not do step number 3 before you test a login with the SSH key method or you will potentially loose access to the server entirely and will need to open a ticket with your host!

Step 1

Create an SSH Key Pair (Public/Private) on the client. Type the following commands (do not use root as the user):

$ cd ~/.ssh
$ ssh-keygen -t rsa -b 2048

You will be asked: “Enter file in which to save the key (/home/testuser/.ssh/id_rsa):” Press Enter.

You will then be asked: “Enter passphrase (empty for no passphrase):” Type in a passphrase that you will remember. You will need to enter it every time you ssh to your server from now on.

Note: If you do not enter a passphrase in this step, you will not be asked to enter it when you login to the server. This can be good or bad… It’s good because you can just ssh to the server and login automatically without typing a password. It’s bad because anyone who has a copy of this Private Key will be able to login to your server without a passphrase. So make sure you keep this file in a very safe place if you choose not to use a passphrase.

In your .ssh directory you will see the following 2 new files: ‘id_rsa’ & ‘id_rsa.pub’.

Step 2

SSH to your VPS Server, and go to the .ssh directory in the home directory of the user you want to be able to access with the key. Ex: /home/user1/.ssh

Copy the contents of id_rsa.pub (That you generated in Step 1 on the Client Computer) And paste it in the “authorized_keys” file in your ~/.ssh directory on the Server. Ensure that everything is on one line.

Edit /etc/ssh/sshd_config (You need to be root to do this).

Find the following lines:

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Remove the “#” symbols next to each of these three lines and save the file.

Restart sshd

Close the session and login to your server again with the user you created the key for.

This time you should be asked for a passphrase (if you entered one in step 1). If you didn’t enter one in step 1 then it should just login and you should have a console $ under the user you created the key for.

Step 3

Once you have confirmed that SSH Key Authentication is working, edit /etc/ssh/sshd_config and find the following line:

PasswordAuthentication yes

Change the ‘yes’ to ‘no’ and restart sshd.

You will now only be able to login with the user you created the Key for. From now on, whenever you want to SSH to the server you will need to make sure that there is a copy of the Private Key in the users Home Directory on the Client Machine.

Read More
TOP

Simple Ways to Secure the SSH Port on your VPS

One of the most important things to do once your VPS has been created is to secure the standard SSH port.

Since SSH is the main method to communicate with any VPS it is the first target for any non-authorized person trying to gain access.

There are a few different ways to add more security to this vulnerable port. You can choose to do one of the following or all of the following depending on your needs.

Change the common port 22

This is the easiest and quickest starting point. Since the default port is 22, most hackers will scan to see if this port is open to start an attack. Changing it to a non-standard port will make it harder to identify where the SSH service is running.

Steps: Login to your VPS through SSH and type the following as root:

vi /etc/ssh/sshd_config

Scroll until you see:

#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

Press “i” to enter insert mode in vi and then move to the line that says #port 22. Remove the “#” and specify a different port (example: 22122, 3355 etc…) Make it random but within the acceptible tcp range.

Once this is done, press “escape” then colon (:) and then “x”. Hit enter and this will save your changes.

At the command prompt type (On CentOS):

service sshd restart

On other OS’s you may need to type: /etc/init.d/sshd restart

At this point you may loose connectivity because you changed the port! If you didn’t you will need to exit the current session and reconnect to your server using the new port that you specified.

(Optional) at this point, if your VPS has more than one IP address assigned to it, you can specify only one by changing the “ListenAddress 0.0.0.0” to one of your IP addresses. This way, you can only access SSH through the one interface.

Disable root login through SSH

Using the same methods in step 1 edit /etc/ssh/sshd_config and scroll until you see

#PermitRootLogin yes

Remove the “#” symbol and change the “yes” to “no”, save the file and restart sshd service.

Next time you try to login as root it will deny you.

Note: SSH will still allow you to try and login as root if you specify “root” as the username. It will reject the login even though you specify the right password.

IP Restriction

This step may not appeal to the users who are on Dynamic IP addresses. But it is a very effective way to secure the SSH port even more.

IP restriction will reject a user trying to login from a non specified source IP address. This will allow you to control which hosts will have access and which do not.

If you have many users using your VPS who require SSH access, this is not a good idea as you will block their traffic when implementing this method.

In order to specify the incoming IP address you can use the “/etc/hosts.allow” and “/etc/hosts.deny” files.

Edit “/etc/hosts.deny” and add a line with the following:

sshd:*

This will deny all traffic. Once this is completed you will allow your IP address.

Edit “/etc/hosts.allow” and add a line with your ip address:

sshd: <your ip> (Example: sshd:192.168.1.1)

Note: The allow file will get processed first. So if an ip address matches in the allow file first, traffic will be allowed even if it is specified in the deny file.

Once this is completed the only host that will be able to SSH to your VPS will be the one specified in your hosts.allow file.

Read More