Search on blog
See something? Say something
Today we are going to talk about several ways of reporting such malicious activities as spam distribution and brute force hacking attempts. Just reporting the offence by no means makes the list of prevention measures complete (there are other ways of enhancing online security) but not reporting it does not make that very list complete either, which may turn out to be something we might start to regret one day. On the other hand, making spammers and hackers regret sounds like a way better idea. Before we start, we would like to ask you not to overrate the efficiency of such reporting and not to expect the results to be great. Chances are there will still be spam in your inbox but please don’t get discouraged. We can do our share of the job and let the consequences take care of themselves. It is not much and it is better than nothing.
So how do we know that a Linux server was a target of a brute force attack in the first place? The answer can be found in a log file /var/log/secure (for Debian/Ubuntu – /var/log/auth.log). This file shows the list all SSH connection attempts (successful and unsuccessful), the usernames which the connections were being tried to be established for (or established for), IP addresses of the client hosts and the exact time of each SSH connection attempt. If there are messages about authentication failure and you know for sure it is not you who entered the incorrect password, it means that, unfortunately, the cause for reporting has finally presented itself.
Once you know the attacker’s IP address you can find out the owner organization of the subnet it belongs to and contact it directly. The contact information of the owner is usually available in WHOIS databases. You can either visit http://who.is or ran “whois ip.ip.ip.ip” in Linux, FreeBSD or Mac terminal (where ip.ip.ip.ip is the IP address you need to look up WHOIS information for).
There is no strictly defined form for a brute force attacks report so usually it is enough to state that there was such an attack and enclose the extract from the /var/log/secure.
It has come to my attention that my server has been an object of continuous brute force attack. The attack source IP address (0.0.0.0) belongs to your subnet and therefore I am asking you to assume the measures in order to stop this hacking activity.
The relevant information can be found below.
[root@myserver ~]# cat /var/log/secure
May 23 20:54:56 myserver sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=0.0.0.0 user=root
May 23 20:54:58 myserver sshd: Failed password for root from 0.0.0.0 port 43545 ssh2
May 23 20:54:58 myserver sshd: Received disconnect from 0.0.0.0: 11: Bye Bye
May 23 20:55:05 myserver sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=0.0.0.0 user=root
May 23 20:55:06 myserver sshd: Failed password for root from 0.0.0.0 port 43933 ssh2
May 23 20:55:06 myserver sshd: Received disconnect from 0.0.0.0: 11: Bye Bye
May 23 20:55:08 myserver sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=0.0.0.0 user=root
May 23 20:55:10 myserver sshd: Failed password for root from 0.0.0.0 port 44218 ssh2
May 23 20:55:10 myserver sshd: Received disconnect from 0.0.0.0: 11: Bye Bye
May 23 20:55:12 myserver sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=0.0.0.0 user=root
May 23 20:55:14 myserver sshd: Failed password for root from 0.0.0.0 port 44537 ssh2
May 23 20:55:14 myserver sshd: Received disconnect from 0.0.0.0: 11: Bye Bye
May 23 20:55:16 myserver sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=0.0.0.0 user=root
Keep in mind that usually writing such reports makes sense only if the attack has been carried out from a host with public IP address. If the IP belongs under the range of private IP address space (10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16) there is no need to look far off. It means the attacking host is located inside the local network your server is connected to and all you need to do is to contact the network administrator of your ISP or of your company’s IT Department. And of course running WHOIS queries for private IP addresses does not make much sense either.
When it comes to spam, there are several ways of submitting reports or, to be more precise, several recipients of such complaints. Spam can be reported to Internet Service Provider of the spam sender, to hosting provider the spam is sent from, and to special organizations that collect data on the distributors of unsolicited email and take measures which include blacklisting domains and IP addresses (or excluding them from the white lists), filing spam reports to the abovementioned ISPs and hosting providers, etc. The most popular spam-reporting services are probably SpamCop, SpamAssassin, McAfee. For more information, please visit their websites.
So suppose you received a spam message. What should you do? Here is a short step-by-step guide to help you.
1. Do not follow any links contained in the message. We would not even recommend clicking on “Unsubscribe” links as, although spam might stop coming from the email address you received it from, your address can be “verified”, marked as a real one and added to multitude of other spam mailing lists.
2. Look at the domain name part of the email address. If it is not a well-known email service provider (e.g. Gmail, Hotmail, Yahoo, etc.) – look up the IP address it resolves to and MX records; do WHOIS query for the domain itself, the IP address, the domains set as MX records and the IPs those domains are pointed to. DNS records can either be looked up at http://who.is or by running “dig any domain.com”. At least some WHOIS outputs will yield emails for submitting the report (usually they look like abuse@).
3. Study Internet headers of the email message. If you use MS Outlook, – double-click on the email shortcut, then click File > Properties. The full email header contains the records of the mail user agent (MUA) (also known as email client in more common parlance, which basically is a sender endpoint) and all the mail transfer agents (MTA) the message gets passed through en route to the recipient. MUA IP is not always recorded in the headers but when it is, it makes it possible to track down the spammer. Note that MUA and MTAs are listed in reverse order so the sender’s IP is recorded at the bottom of the header. Once you know the sender’s IP you can WHOIS it.
Also there are plenty of online email headers analyzers which simplify the reading of the header (e.g. https://toolbox.googleapps.com/apps/messageheader/analyzeheader ).
4. Write a report, enclose the spam letter and text of the full header, and send it to the abuse@ addresses you have found when following the steps #1-#3. Here is an example of such a report.
This is to inform you that spam is sent from one of your network hosts. I am asking you to take prompt action in order to stop spam distribution coming from this host.
The relevant information can be found below.
Received: from example.com (184.108.40.206) by
mail.domain.net (10.1.1.243) with Microsoft SMTP Server id 220.127.116.11;
Sun, 26 May 2013 20:00:38 +0300
X-Virus-Scanned: amavisd-new at domain.net
Received: from mail-ee0-s70.google.com (mail-ee0-s70.google.com
[18.104.22.168]) by example.com (Postfix) with ESMTP id
BA6D7B80001 for < jack.exmple.com >; Sun, 26 May 2013 17:00:37 +0000
Received: by mail-ee0-s70.google.com with SMTP id c431so1eek.53
for <jack.exmple.com>; Sun, 26 May 2013 10:00:37 -0700 (PDT)
X-Received: by 10.14.208.131 with SMTP id q3mr6827232eeo.111.1369587637090;
Sun, 26 May 2013 10:00:37 -0700 (PDT)
Received: from JohnPC ([22.214.171.124]) by mx.google.com with
ESMTPSA id e1s94534eem.10.2013.05.26.10.00.35 for
<jack.exmple.com> (version=TLSv1 cipher=RC4-SHA bits=128/128);
Sun, 26 May 2013 10:00:35 -0700 (PDT)
From: John Smith <[email protected]>
To: “Jack Lee” <jack.exmple.com>
Date: Sun, 26 May 2013 20:00:34 +0300
Message-ID: <firstname.lastname@example.org >
X-Mailer: Microsoft Outlook 14.0
Return-Path: [email protected]
Good pharmacy! Cheap pills!
Also it is probably worth mentioning that not every organization you send spam complaints to will reply you back and provide you with the information on the actions it has taken in response to your request. It doesn’t mean they ignored you report, they just may be too busy or not process every report manually. Also it may be a part of their policy not to answer such complaints at all.