Outside the Blur

Internet giants have united to fix a serious problem in the internet DNS addressing system that might have let hackers hijack web traffic

And the interesting thing is that it happened also to me some while ago with a site that I had in administration .

A few months ago I observed a strange behavior by accessing this website. I wanted to access this site and I observed that even if the DNS records are properly set on my name server, I was redirected somewhere else when I was accessing the name address from the browser, to another internet site. At that time I hadn’t known that the entire DNS system has a problem. I observed that the DNS system was corrupted somewhere but I couldn’t specify why and find the reasons. Although, it was obviously to me that something is not alright with the domain addressing space. I checked and rechecked the name server and the records. Still nothing.

Basically the ip to address name mapping had a flow. Some malicious guy was able to redirect by corrupting some name server with another A record which would redirect to somewhere else. And, the strange thing is that I couldn’t find the solution and fix the problem at that time.

I have begun to query all the name servers recursively with the tools that I had, with “dig” and with “nslookup”. I have founded the name server with the problem, but I wasn’t been able to fix the problem because it wasn’t a problem that I could fix. My name server was working fine. All the settings were good.

After a few days I observed that the problem fixed somehow and I was intrigued about all this story.

Now I read about the DNS security hole discovered also by accident by Dan Kaminsky.

The big software and hardware companies worked in secret for months to create a software patch which has now been released to repair the glitch.

But read the entire article here .

I’m glad that the problem was fixed and we can surf now safely the internet. And I want to thanks to the collective effort to fix the problem.

GOOD WORK !

How to protect you sendmail server against spam:

One of the main reasons that your SENDMAIL server could have many unwanted traffic or spam is that in sendmail relaying is enabled by default.
After you install sendmail on your server (it doesn’t matters on which linux distribution ) there are a few things to take care in order to have a robust and secured against spam.

1. Install spamassassin. It’s helping identifying and finding messages containing recognize as spam source by comparing his own white and black list. This is done by making a good white and black list in each of the cases and spamassassin will filter all the mails and it will junk them. I will not cover this. Just run :

spamassassin –h

And you can play there by adding addresses to the black list and white list

2. Verify the content of your access file. It should look something like this :

mail $ cat /etc/mail/access

# Check the /usr/share/doc/sendmail/README.cf file for a description
# of the format of this file. (search for access_db in that file)
# The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc
# package.
# If you want to use AuthInfo with “M:PLAIN LOGIN”, make sure to have the
# cyrus-sasl-plain package installed.
# By default we allow relaying from localhost…
Connect:localhost.localdomain RELAY
Connect:localhost RELAY
Connect:127.0.0.1 RELAY
Connect:yourdomain.com RELAY
Connect:alias.yourdomain.com RELAY

And this is all what it must contain your access file. You can reduce it a little but I tested this configuration and it works fine. It’s secure.

3. Verify the content of relay-domains file :

mail $ cat /etc/mail/relay-domains

yourdomain.com

4. Look for the virtusertable file to contain just the specific information or the aliases to the e-mails addresses that you added to your sendmail. This is important for the good functionality of your server and you must look here to not contain invalid or inexistent addresses because this would also charge your server.

Example:

mail $ cat /etc/mail/virtusertable

first_name1@yourdomain.com first_name1

first_name2@otherdoimain.com first_name2 (this if you have virtual domains on your server, multiple domains)

5. And finally, and the most important think is the sendmail.mc file. This is the file that the administrator must configure and generates the sendmail.cf file. You must not touch the sendmail.cf file. It is automatically generated by sendmail.mc.

Open /etc/mail/sendmail.mc and comment the line:

#FEATURE(`accept_unresolvable_domains’)dnl

Just like here.

By disabling this line sendmail will not accept relaying. Il will consult also the access file and it will not accept the RCPT TO address if the domain has not valid MX records. Now you can restart sendmail service. And that’s all. Now how about a small test ?

How to verify if your mail server is relaying.

This is a very important thing you must verify and it can be done to any kind of mails server: Exim, Postfix, Sendmail, Qmail, MailEnable and so on.

You must login to another computer that has a command prompter or to a linux machine console.

In windows you can do it simple: start –> run –> cmd

In linux any terminal is good. It’s important to have the SMTP port 25 open by your ISP. Any machine that has the port 25 open is very good.

I give you here an example by replacing the ip’s and the domain names for safety. What you must type is with the prompter $, the rest is the reply of the server.

1. $ telnet server_to_test.com 25

Trying 26.26.26.125…

Connected to server_to_test.com (26.26.26.125).

Escape character is ‘^]’.

220 server_to_test.com ESMTP Sendmail 8.14.2/8.14.2; Thu, 3 Jul 2008 14:16:56 +0300

This is good. This means that the server is responding to us. Server_to_test is your server of course. We can go on.

2. $ HELO spam_terrorist.com

250 server_to_test.com Hello the_name_domain_of_your_machine [11.11.11.85] (may be forged), pleased to meet you

may be forged – This message appears if your ip is not resolvable. If your ip has an MX record that it’s not resolvable. Here at the HELO he can put any address he wants.

3. $ RSET

250 2.0.0 Reset state

4. $ MAIL FROM:<spammer@anydomain.com>

250 2.1.0 <spammer@anydomain.com>… Sender ok

This is the domain that it will appear in the header as Received from.

5. $ RCPT TO:<any_mail_you_like@spamdomain.com>

250 2.1.5 <any_mail_you_like@spamdomain.com>… Recipient ok

If this message it appears this means that your server can be used as relay by any spammer. This is not quite good. You must verify the configuration once again. And repeat the test.

Now, personally I disable the relay on my server to show you a negative reply :

6.a $ RCPT TO:<any_mail_you_like@spamdomain.com>

550 5.7.1 <any_mail_you_like@spamdomain.com>… Relaying denied

Now this is good. This means that your server is secured now against spam. But it is still not secured if the sender knows a valid address of your server. But here spamassassin comes in action if you configure the black and white list. It will appear like this:

6.b $ RCPT TO:<valid_mailname@server_to_test.com>

250 2.1.5 <valid_mailname@server_to_test.com>… Recipient Ok

And the spammer can spam that e-mail address. This is why it is very important to keep your e-mail address private as it is possible and to not publish it visibly on every internet site. Spammers have huge lists with e-mails, and they are happy to have others. In fact they are prospering making illegal money from spam.

And finally another possible situation, that it could appear, if he puts your domain to the RCPT and an non existing mailname address :

6.c $ RCPT TO:<non-existing_mailname@server_to_test.com>

550 5.1.1 <non-existing_mailname@server_to_test.com > … User unknown

In the case that you left relaying enabled you’ll never meet this situation.

I think that I covered the important aspects of relaying. I’m open to new suggestions and I hope that this small article helps you in your server administration tasks. Can be used by everybody but is preferable to be at most a medium linux administrator in the case of sendmail.

Enjoy