Members
  • Total Members: 14176
  • Latest: toxxxa
Stats
  • Total Posts: 42866
  • Total Topics: 16075
  • Online Today: 1580
  • Online Ever: 51419
  • (01. January 2010., 10:27:49)









Author Topic: Some basic step to secure a mailserver!  (Read 6313 times)

0 Members and 2 Guests are viewing this topic.

Pez

  • SCF VIP Member
  • *****
  • Posts: 776
  • KARMA: 117
  • Gender: Male
  • Pez
Some basic step to secure a mailserver!
« on: 02. April 2013., 11:34:30 »
Some basic step to secure a mailserver!

Her is some basic step to secure a mailserver. Offcause you need to take care of the OS securety and patching also.

1. Setup access security to the mailserver software it self for mailusers. Purhaps also that the acess should be encrypted thrue SSL.

2. Setup that only user with valide mail accounts can access the server.

3. Setup graylisting of mails.

4. Reverse DNS lookup check for mail.

5. Setup content barring of mail.

6. Setup blacklist/white list barring.

7. Setup a antivirus mail scanning.

8. Setup SpamAssassin.

9. Learn users to learn the server who is trusted users for incomming mail this so SpamAssasin have a update DB for incoming mails and more secure handling new mails that is not from trusted senders.

10. Prevent unautorized mailrelay.

11. Setup SPF and/or Domainkey.

12. Setup one or more DNSBL.


Some mailsevers use this flow to check mail and ther reability:



click the image to get it larger!

Some expanations of the step.

1. SSL access si not so match to expane this is to encrypt the access and login to thew server. The mathode is different as in all the following expnanation depending of the mailserver software.

2. Set up so only autrized users can access the server remember to disable unused and old mailaccount.

3. Greylisting - Defending you from spam

Greylistingw  is an extremely effective anti-spam technique because the majority of spam sending applications are not real mail transport agents. Spam is sent out in extremely large quantities (often millions of recipients) and queueing messages for retry is usually impractical. Even if the spam software is capable of retrying, there is a relatively small window of opportunity before the IP address becomes blacklisted so it is more cost-effective to move on to other hosts. Similarly, your system is more likely to find the sending IP address on a blacklist if it retries later.

When active, the first time that a particular message is sent to a particular recipient on your system it is rejected with a transient error. To conform to RFC2821 the sending mail transport agent must queue the message and try again later. A later attempt will be accepted.


Greylisting (or graylisting) is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate the originating server will, after a delay, try again and, if sufficient time has elapsed, the email will be accepted.
http://en.wikipedia.org/wiki/Graylisting

4. Perform Reverse Lookup will offer as the HELO a match to the lookup by the remote server you are connecting to.
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

5. Barring is done with a Type 2 Wildcard List.  The contents of the barring lists are used to identify addresses that will be rejected.

The list is read top to bottom.  Each entry alters the barring by including or excluding a range of addresses (to reject). To include an address range, enter a wildcard specification (which may or may not actually include wildcard characters).

To exclude an address range, enter a wildcard specification preceded by a tilde (~).

There are four wildcard characters in a Type 2 Wildcard:

* One or More characters
? One character
$ One alphabetic character (A-Z, any case)
% One numeric character (0-9)

Example (Sender Barring)

*@*%%%%*
*@%%%%*
*@*%%%%
%%%%*@*
*@netcom.com
*@hotmail.com
~myfriend@netcom.com
~myfriend@hotmail.com
spammer@spam.net

Description of the examples

Excludes any address with four sequential numbers in the domain part.
Excludes any address beginning with four sequential numbers.
Excludes anything from NetCom and HotMail, except for myfriend@netcom.com and myfriend@hotmail.com.
Excludes the specific address spammer@spam.net.

Note:

Barring is only effective on the sender and recipient addresses. This is because the barring is designed to take place during the SMTP transaction -- i.e. before download even begins.

Messages stored in Mailtraq will show the sender field in the Return-Path: header.

6. Essentially, sender control is based on a blacklist (list of senders from which mail is refused) and a whitelist (list of senders from which mail is accepted).  If a sender is in both the blacklist and whitelist, the whitelist takes precedence.  Also, the whitelist overrides any decision made by the Anti-Spam system (see the Anti-Spam tab).

7. To set up a depend of the mailserver and the AntiVirus toolkit used so that you need to read depending of the pruduct and what product is available for your mailserver.

8. SpamAssassin is an open-source mail filter project designed to identify spam.  It uses a diverse range of tests and has been shown to be very effective in separating spam from non-spam mail.

Because SpamAssassin integrates multiple techniques and is being continuously updated and extended it has an advantage over other anti-spam systems.

Although SpamAssassin also uses Bayesian statistical techniques to analyse mail, it also tests for many features that are very hard for spam senders to avoid.  The spammer's objective is to spread advertising (or some message) as widely as possible, with as little cost to themselves as possible.  In order to accomplish this the spammer must employ many methods that are not typical of regularly sent mail.  For example, spammers may attempt to obscure the actual message using images or unnecessary HTML markup and SpamAssassin will factor this in when assessing a message.

See the SpamAssassin-tab for information on configuring the SpamAssassin integration.
You can reach this tab from Options | Anti-spam ...

What is SpamAssassin? Read morew ...

  What does SpamAssassin test for? AnswerS ...

http://en.wikipedia.org/wiki/SpamAssassin

9. Not match to talk about just that users should approve mail comming from trusted senders and blacklist mail comming from untrusted senders.

10. Mail relaying is the practice of sending mail to a remote mail host other than direct to the recipient host itself or to the host specified in the Domain Name System (DNS) by the MX resource records for the recipient address.

Until recently, most mail hosts on the Internet freely permitted relaying to ensure that the SMTP mail transport system could route around temporary losses of connectivity and other network related problems. However, unscrupulous junk mailers eventually learned to abuse that trust-based system by offloading their messages onto any mail service which offered them the opportunity of hiding the true origin of their messages. It is becoming exceedingly rare, therefore, to find a mail host which offers to accept mail for delivery to anything other than recipients which it regards as being local to itself.

Uncontrolled mail relaying places the viability of your own mail service at risk. If detected and placed on a black list, many mail destinations may refuse to accept mail directly from your host and may also refuse to deliver mail to your host. Further, whilst it is very easy to get on blacklists, getting removed from blacklists can be inordinately difficult, particularly where private schemes are involved. Consequently, understanding the concept of mail relaying is vital for all responsible Internet mail administrators.

Her is one methode that some mailservers is using:

If mailserver configured Domain Name (or a Domain Alias) is example.com and a local SMTP client (that is a client whose IP address falls within its local LAN firewall) sends a message addressed to user@example.com, Mailtraq delivers the message locally and there is no relaying involved.

If, however, the message from that local client is addressed to a remote domain, for example user@foo.fastraq.com, Mailtraq relays the message onwards. That is an example of authorised relaying.

If a remote mail client (a client whose IP address falls outside Mailtraq's local LAN firewall) sends a message addressed to user@example.com, Mailtraq delivers the message locally and there is no relaying involved.

If, however, the message is addressed to a remote domain, user@foo.fastraq.com as in the first example, mailserver would be performing unauthorised relaying if it accepted the message and attempted to deliver it onwards.

Note the crucial difference between those two examples. Unless SMTP Authentication is enabled in Mailtraq, the IP address of the sending client is the only factor which can be used to discriminate between authorised and unauthorised relaying. For installations where Mailtraq is connected to the Internet, it is very important that relaying is not permitted based on the domain name announced by the connecting client. The SMTP reverse path (as supplied in the SMTP envelope in a parameter to the MAIL command) is trivial to forge and must not be relied upon under any circumstances.

Forward Path Resolution

Where possible, mailserver resolves the ultimate SMTP envelope forward path (i.e. destination domain) even if source routing, for example <@local.host:user@remote.host> or the percent hack, for example , exploits are used and refuses to relay with an appropriate SMTP protocol response, "550 cannot relay for remote.host" or "550 forwarding percent hack is not permitted" respectively.

However, Mailtraq cannot resolve UUCP style bang paths, for example , or the various types of quoted forward paths employed, for example <"user@remote.host"@local.host"> so it treats them as being locally deliverable in accordance with the settings on the Undelivered Mail tab. Note that, although those types of relay exploits are accepted at the SMTP envelope level, the messages to which they are attached are not subsequently relayed out of Mailtraq by default.

To block those types of relay exploits at the SMTP protocol level, add the following three patterns, one per line, to the Bar mail addressed to listing on the Inbox Properties dialog. For clarity, and to avoid barring legitmate mail due to misreading the wildcard patterns, their ASCII equivalents are also provided for information only:-

Pattern ASCII Equivalent
*!* (ASCII 42) (ASCII 33) (ASCII 42)
"*@*" (ASCII 34) (ASCII 42) (ASCII 64) (ASCII 42) (ASCII 34)
"*@*"@* (ASCII 34) (ASCII 42) (ASCII 64) (ASCII 42) (ASCII 34) (ASCII 64) (ASCII 34)

Mailtraq refuses forward paths which match the above patterns with a "550 " protocol response, adding the text string specified by the user in the Message to send when address is barred edit box.

Authorised Relaying

If Mailtraq should accept mail for other domains, that is, act as an MX relay for remote domains, the remote domain should be added to the ‘Always allow relaying to these recipients’ control in the following format:-

*@domain.example.com

Mailserver then accepts mail addressed to that non-local address and places it in the outbox. The outbox MUST contain a suitable custom static route to forward such messages direct to the correct remote destination. If such messages are allowed to be routed normally by Mailtraq, a mail loop has been formed and the messages will eventually bounce.

http://en.wikipedia.org/wiki/Mail_Abuse_Prevention_System

11. SPF (Sender Policy Framework)
Sender Policy Framework (SPF) is an email validation system designed to prevent email spam by detecting email spoofing, a common vulnerability, by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail from a given domain by creating a specific SPF record (or TXT record) in the Domain Name System (DNS). Mail exchangers use the DNS to check that mail from a given domain is being sent by a host sanctioned by that domain's administrators.

http://en.wikipedia.org/wiki/Sender_Policy_Framework

DomainKeys is an e-mail authentication system designed to verify the DNS domain of an e-mail sender and the message integrity. The DomainKeys specification has adopted aspects of Identified Internet Mail to create an enhanced protocol called DomainKeys Identified Mail (DKIM). This merged specification became the basis for an IETF Working Group which guided the specification toward becoming an IETF standard.
 
Both DomainKeys and DKIM were published in May 2007. DomainKeys was issued as a "historical" protocol and DKIM was issued as its standards-track replacement.

http://en.wikipedia.org/wiki/DomainKeys
http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

12. DNSBL A DNS-based Blackhole List (DNSBL) or Real-time Blackhole List (RBL) is a list of IP addresses published through the Internet Domain Name Service (DNS) either as a zone file that can be used by DNS server software, or as a live DNS zone that can be queried in real-time. DNSBLs are most often used to publish the addresses of computers or networks linked to spamming; most mail server software can be configured to reject or flag messages which have been sent from a site listed on one or more such lists. The term "Blackhole List" is sometimes interchanged with the term "blacklist" and "blocklist".
 
A DNSBL is a software mechanism, rather than a specific list or policy. There are dozens of DNSBLs in existence, which use a wide array of criteria for listing and delisting of addresses. These may include listing the addresses of zombie computers or other machines being used to send spam, listing the addresses of ISPs who willingly host spammers, or listing addresses which have sent spam to a honeypot system.
 
Since the creation of the first DNSBL in 1997, the operation and policies of these lists have been frequently controversial, both in Internet advocacy and occasionally in lawsuits. Many email systems operators and users consider DNSBLs a valuable tool to share information about sources of spam, but others including some prominent Internet activists have objected to them as a form of censorship. In addition, a small number of DNSBL operators have been the target of lawsuits filed by spammers seeking to have the lists shut down.

http://en.wikipedia.org/wiki/DNS_Blacklist

Her is some list of DNSBL services:
http://www.declude.com/Articles.asp?ID=97
http://spamlinks.net/filter-dnsbl-lists.htm
http://www.aspnetmime.com/dnsbl.aspx
http://www.sdsc.edu/~jeff/spam/cbc.html

Her is also a reference to Wikipedia regarding Anti-spam techniques.
http://en.wikipedia.org/wiki/Anti-spam_techniques_(e-mail)
Their is two easy way to configure a system!
Every thing open and every thing closed.
Every thing else is more or less complex.

Start Turfing ! http://scforum.info/index.php/topic,8405.msg21475.html#msg21475

Samker's Computer Forum - SCforum.info

Some basic step to secure a mailserver!
« on: 02. April 2013., 11:34:30 »

Pez

  • SCF VIP Member
  • *****
  • Posts: 776
  • KARMA: 117
  • Gender: Male
  • Pez
Re: Some basic step to secure a mailserver!
« Reply #1 on: 02. April 2013., 15:00:35 »
Remember also to NOT set up a auto reply to sender if a mail got blocked due to some reason of the Anti-Spam securety setting. If you do so ther most likly got a mail in loop or in worst case give information to a spammer how to get around that securety level in your mail enviroment.

Do this task as a manual maintenace to check the spam mail and correct the fault spam detection your self or inform known false detected senders what thay need to do for geting wihtlisted.

What I know the most common reason is if you have got a bad learning in the SpamAssassin or if the sender got a listing in the DNSBL that ther postmaster need to fix for ther network.
Their is two easy way to configure a system!
Every thing open and every thing closed.
Every thing else is more or less complex.

Start Turfing ! http://scforum.info/index.php/topic,8405.msg21475.html#msg21475

Samker

  • SCF Administrator
  • *****
  • Posts: 7528
  • KARMA: 322
  • Gender: Male
  • Whatever doesn't kill us makes us stronger.
    • SCforum.info - Samker's Computer Forum
Re: Some basic step to secure a mailserver!
« Reply #2 on: 03. April 2013., 18:39:41 »
Perfect job, thanks pal. :thumbsup:

JennyShepard

  • SCF Newbie
  • *
  • Posts: 2
  • KARMA: 1
  • Gender: Female
Re: Some basic step to secure a mailserver!
« Reply #3 on: 25. November 2013., 10:12:45 »
We are running over email services through a third party service provider so can I still implement these security measures.

Pez

  • SCF VIP Member
  • *****
  • Posts: 776
  • KARMA: 117
  • Gender: Male
  • Pez
Re: Some basic step to secure a mailserver!
« Reply #4 on: 25. November 2013., 12:18:18 »
We are running over email services through a third party service provider so can I still implement these security measures.

Do you rout the mail true the service provider to you own mail server or do you have the mail server at the service provider.

If you have your own mail server you can implement this or parts of this recommendation depending of the mail server software ability to implement this security feature.

If you have a hosted mail server at the service provider then this is a good checklist to see how secure and security aware the service provider is and how good their service is. It is also a good checklist to have if you want to compare different service providers feature if you want to change service provider.

Not I have wrote this in the main view for a help and guide for a postmaster to setup security on a own server. But it is also possible to have as a technical specification when selecting a service provider of a hosted mail server service.

I have not described anything about the client security in the OS and Mail software that also is important. But that differ so match depending of how the network, servers and clients is implemented and what software is selected.

I hope this helped you some way. Other wise please feel free to come back with more question and provide a little more information then I probably can help you more.
Their is two easy way to configure a system!
Every thing open and every thing closed.
Every thing else is more or less complex.

Start Turfing ! http://scforum.info/index.php/topic,8405.msg21475.html#msg21475

Samker's Computer Forum - SCforum.info

Re: Some basic step to secure a mailserver!
« Reply #4 on: 25. November 2013., 12:18:18 »

 

With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Name: Email:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image
Type the letters shown in the picture:
Second Anti-Bot trap, type or simply copy-paste below (only the red letters):www.scforum.info:

Enter your email address to receive daily email with 'SCforum.info - Samker's Computer Forum' newest content:

Terms of Use | Privacy Policy | Advertising