SMTarPit v0.6.0
 |
|
|
an SMTP tarpit (teergrub)/honeypot
Contents
About SMTarPit (and what ISPs can do)
- How does it work?
- Tarpitting spammers
- Preparation
- Requirements
- Running Example
- Log Example
- Running Processes
- Effectiveness
- SMTarPit Monitor v0.5.0 (GUI)
- SMTarPit Monitor v0.0.1 (CLI)
- Download
- Version History
- Is it legal?
About SMTarPit
I wrote this program because I looked around the Internet for an SMTP Tarpit/Honeypot that was: written in Perl; and, was only an SMTP tarpit/honeypot - I couldn't find one.
SMTarPit is a combined SMTP honeypot and tarpit released under the GPL. It is writen in Perl so it should work on virtually any platform that supports Perl (except Windows). It uses xinetd which looks at port 25 (instructions in the tarball) and when someone calls it, smtarpit is launched and then it chroots itself. It then decides whether there is a man or a machine on the other end and sets about wasting their time.
There are plenty of instructions as to how to configure the program - if Perl is not your first language, you should still be able to see what to do. You will certainly need to put a valid domain name in there but it is all well laid out so that you can install it and run it as a part of xinetd.
If you are an ISP with a tarpitted connection, you can tell which one it is from the fact that the tarpitted connection has a paritcular profile of inactivity and persistancy that no normal SMTP connection has. With this in mind, you can look at your RADIUS logs and take action on the spammer - the one thing that you know from monitoring the connection is that there will be many mails to the same domain from the same source address and that none of them will be solicited as there is in reality nobody to solicit them. Unsolicited bulk email equals spam and with the RADIUS logs, you can notify the authorities and have the spammer arrested and procecuted - or do nothing more than throw them off and let them spam another day. All spam connections are logged by the tarpit.
How does it work?
Every time an incoming call to port 25 happens, xinetd starts a copy of this server. It only has a small memory footprint and doesn't really consume much processor time.
When the server is started, it responds with the usual welcome message and then waits for the client to respond. When the client does respond, it looks at how long it took and tries to work out whether it is a man or machine at the other end (you can adjust this time in the program if you want).
If the server thinks that it is a machine at the other end, it goes into tarpit mode where everything takes a long time. In SMTP, the server response codes have a three figure number and if that is followed by a dash (-), the client has to wait until it receives one with a space after it. This can take an hour or so.
There are time-outs but you can make the response times all different to avoid profiling/finger-printing of the server - SMTarPit can do this automatically. While all of this is going on, the server is just sitting there, asleep. It doesn't take any significant processor time (arguably any at all) and only a few kB in memory. You can limit the number of concurrent servers with xinetd (explanation and example in the program file at the beginning) and impose any other limitations you want.
In other words, this server allows you to tarpit (stall) several spamming processes (up to the limit you define in the program and your xinetd configuration files) for hours at a time with only minor resource consumption on your part. You certainly won't see any bandwidth eaten away by it (50 Bytes per minute on average is typical).
Tarpitting spammers
The idea behind a tarpit for SMTP is that if the spammer has a program that runs 100 processes and sends out 30,000 emails an hour, if you gum up some of those processes by pointing them at a tarpit, you will slow things down.
If you gummed up all of them by having a number of these tarpit servers (if lots of us run them), instead of sending out 30,000/hour, they would have a rate of only 30 to 40 per hour and none of those would be valid emails. To poison the spam mailing list, you just put mailtos around your site (or another site on a virtual server that is full of bogus email addresses) and let them be spidered.
With ony 1,000 email addresses that point to various tarpits, you can add 30 hours to a spam distribution (running 100 processes).
For an example of a spambot honeypot, look at the Sundew honeypot. The version of that honeypot on this server works - I've had spam aimed at email addresses from it. You can create your own (using Sundew or anything else) and put as many or as few on as you like but remember to make them all point to your smtp tarpit.
One spammer had one process gummed up for 489,130 seconds (5 days, 15 hours, 52 minutes and 10 seconds), sending over 60 resets during that time to try to get through. Another tried to send mails to 117 bogus email addresses spidered from my site - each command took just under 40 minutes to complete due to the tarpitting on the server. The current record is 2,670,257 seconds (30 days, 21 hours, 44 minutes and 17 seconds).
Preparation
You need to have bogus email addresses in the spammer's email database. You can do this by having a web server on port 80 with a 1 pixel square link to it from a site that is spidered regularly (you can put the other site into Google's spider list if you want). If it is on the same server, any checks to see that email addresses are genuine will show that they are.
Something else you might consider is all of those phishing attacks. If you click on one (to open on a browser not running scripting, preferable not on Windows either) then, where the opportunity arises, add a tarpitted email address - this will get sold on as a valid email address.
Requirements
You need...
You don't need...
- a computer that runs Perl
- xinetd (you can probably run it with inetd - let me know on that one)
- The computer does not receive any incoming mail (ie, port 25 on the external ethernet card is not used - there are details on how to configure xinetd if you do use port 25 on internally facing cards or on the local host - download it and read the details)
- Port 25 open on the firewall
- there is a domain name pointing to that IP address (even a domestic broadband machine can use this - go to DynDNS.Org to see how to get your own domain name for free)
- root access
You should have (any way)...
- to have Perl in the directory that this program runs in because it doesn't call anything else once it is chrooted (it doesn't before either)
- to run it on a mainframe - a home, broadband machine will do it
- a great, in-depth knowledge of setting up servers as you can follow the instructions in the Perl script file - you can run this on virtually anything
- to run the GUI front end or the CLI front end to run the tarpit
- to spend money
- a firewall that you can configure to point port 25 traffic to your server
- Perl (nothing fancy is needed here, the basic install that comes with your OS should do)
- a 24/7 connection to the Internet
- a machine that you run all of the time
Running Example
In a shell, get the host ip address for "info2.mine.nu"
Open up telnet and point it to the address on port 25. You will get the SMTarPit honeypot/tarpit.
IMPORTANT. Use VRFY for "freshtest@fresh.info2.mine.nu" (copy and paste the following
VRFY <freshtest@fresh.info2.mine.nu>
into telnet to save time) so that I know that you are not a spammer.
Have a play around with it. Try out the different commands and the help. Any address that ends with info2.mine.nu will work until you try sending data.
Example commands...
VRFY <freshtest@fresh.info2.mine.nu>
HELO foo.com
MAIL FROM:<john.doe@bar.com>
RCPT TO:<mike123@home.address.info2.mine.nu>
DATA
RSET
QUIT
You will get a fairly typical response. If you give the first command really quickly (a correct command in less than 7 seconds - at the server end as currently set), it will go into tarpit mode and you will see each command take up a lot of time.
Log Example
The following is representative of the output for one session from the full log...
NEW 32521 123.45.67.89 2004 Nov 12 20:40:15 32521 2004 Nov 12 20:40:15 220 smtp.sulphur.ddd.ttt Sendmail 8.12.9/8.12.1; ready 32521 2004 Nov 12 20:40:15 helo mail.otherdomain.com 32521 -- delta_t = 0 seconds 32521 -- Fast response: selecting tarpit mode 32521 2004 Nov 12 20:42:17 250-smtp.sulphur.ddd.ttt greets mail.otherdomain.com [123.45.67.89] 32521 2004 Nov 12 21:19:19 Wastetime Routine Finish 32521 2004 Nov 12 21:19:19 mail from:<help@help.qwert.com> 32521 2004 Nov 12 21:21:12 250-<help@help.qwert.com> Ok on this server 32521 2004 Nov 12 21:57:59 Wastetime Routine Finish 32521 2004 Nov 12 21:57:59 rcpt to:<asdfg@ddd.ttt> 32521 2004 Nov 12 21:59:30 250-<asdfg@ddd.ttt> Ok on this server 32521 2004 Nov 12 22:35:44 Wastetime Routine Finish 32521 2004 Nov 12 22:35:44 data 32521 2004 Nov 12 22:39:16 552-Requested mail action aborted: exceeded storage allocation 32521 2004 Nov 12 23:17:03 Wastetime Routine Finish 32521 2004 Nov 12 23:17:03 quit 32521 2004 Nov 12 23:17:15 221 smtp.sulphur.ddd.ttt Sendmail 8.12.9/8.12.1; closing connection. 32521 -- duration: 9420 seconds... and this from the quicklog
32521 123.45.67.89 2004 Nov 12 20:40:15 - duration = 9420
Running Processes
This shows how many processes the SMTarPit has had - it is set to a maximum of 35 - handling politely the final 5 up to the 40 in total that the superserver runs. The tarpit is now saturated so I no longer run this. The gap is caused by the log being full.
Effectiveness
This shows how effective the tarpit is by how many hours of spammer's time it has wasted each week. This graph used to be updated automatically every day at 01:30 GMT but the tarpit is just saturated with spammers now so there is no real point in updating the graph.
Breakdown by week . . . Week
StartingT i m e . . . Total
SecondsTotal
(Hours)Longest
(Hours)*Hits
from:<>rcpt
to:4 Apr 2005
16,465,660 4,573 43 4023 9 2,690 11 Apr 2005
19,115,812 5,309 43 8536 42 1,875 18 Apr 2005
16,942,413 4,706 60 6843 105 1,822 25 Apr 2005
20,109,432 5,585 39 8045 554 990 2 May 2005
24,162,991 6,711 49 14144 2,821 416 9 May 2005
22,759,262 6,322 119 12576 1,250 1,031 * A hit is a new connectsion
** 'mail from:<>' is a null sender which is not allowed on this server. (Might be spam.)
Day of week . . .
H
i
t
s
Day Mon Tue Wed Thu Fri Sat Sun Per cent 10 12 12 15 20 19 12 created at: 02:01:13 on Mon 16 thMay 2005 Since the end of 2004, the number of emails to non-existent addresses shot up as the spambot honeypot addresses (seem to have) leaked into the spammer's address databases. In the version 0.5.0 history below, I mention a lot of spammer's time - this is now looking insignificant compared to what is now going on.
Also, on (Friday) 21st Jan 2005, I modified SMTarPit so that it logs connections that have been dropped and the tarpit thus receives a SIGPIPE for. It appears that these non-conforming SMTP programs that the spammers use are in an abundance as the logged number of mails has increased because of that as well.
Note that this latter graph just shows connections and not rcpt to: lines (I have counted over 100 rcpt to: lines in one mail attempt).
Also note that in the case of emails travelling over midnight (or even several days), the mail is credited to the day it starts in - most last only a few hours though.
SMTarPit Monitor v0.5.0 (GUI)
All you need to do is configure the monitor program at the beginning of the source file with the path to your SMTarPit log directory and one or two other bits. Click on the screenshot to see a full-sized screenshot.
Note that you do not need to run the monitor program or even a GUI to run SMTarPit. The SMTarPit Monitor is only a means of studying the tarpit processes and is not needed to make them work.
SMTarPit Monitor v0.0.1 (CLI)
In with SMTarPit is also a CLI-based monitor program (smtpcli) that does pretty much the same as the GUI version above.
All you need to do is configure the monitor program at the beginning of the source file with the path to your SMTarPit log directory and one or two other bits.
Note that you do not need to run the monitor program to run SMTarPit. The SMTarPit Monitor is ony a means of studying the tarpit processes and is not needed to make them work. This monitor program is designed so that it can work over any command line link to the SMTarPit server whether it is a SSH, telnet (if you must) or even a teleprinter over a 300 baud acoustic coupled telephone link. If you need to have crlf at the end of each line instead of just a newline, just type "smtpcli -c" at the command line (no quotes).
This is an example of the output of the smtpcli program from a real session (the operator's input is in blue)...
# ./smtpcli Welcome to SMTarPit Monitor CLI version 0.0.1. Copyright (c)2005 Paul Grosse. All rights reserved. Time: 2005 Mar 9 13:45:19; xinetd is running; 12 SMTarPits running. [S]tatus, [L]ist PIDs, [H]elp, [Q]uit. TP>l SMTarPit PID List... 0 1 2 3 4 5 6 7 8 9 A 6753 10260 10261 12296 12297 12300 12301 14196 14457 14461 B 14555 15167 [S]tatus, [L]ist PIDs, [C]hoose PID, [H]elp, [Q]uit. TP>c Enter Co-ordinates (eg A5 or AC8). [H]elp, [Q]uit. TPEC>>a0 [S]tatus, [L]ist PIDs, [D]etails, [H]elp, [Q]uit. 6753>>d PID ... ... ... ... : 6753 Remote Host ... ... : 64.97.168.33 Start Time. ... ... : 2005 Mar 7 04:22:35 Duration... ... ... : 206,576 seconds (57.4 hours) Server Name ... ... : smtp.silicon.data2.mine.nu Server Type ... ... : Sendmail 8.12.9/8.12.1; HELO... ... ... ... : n066.sc1.cp.net Reaction Time.. ... : 1 second Mode... ... ... ... : Tarpit Sender. ... ... ... : <sylvia.clifton@virgin.net> Number of Recipients: 47 Last Recipient ... : <ashley851@sbhp.info2.mine.nu> Last Updated... ... : 2005 Mar 9 13:45:31 Time Now... ... ... : 2005 Mar 9 13:45:32 [S]tatus, [L]ist PIDs, [D]etails, [R]efresh, H[o]st, [W]hois, [H]elp, [Q]uit. 6753>>o NAME FROM IP ADDRESS... # host 64.97.168.33 33.168.97.64.in-addr.arpa domain name pointer fh1023.dia.cp.net. GET IP ADDRESS FROM NAME... # host n066.sc1.cp.net n066.sc1.cp.net has address 64.97.172.76 [S]tatus, [L]ist PIDs, [D]etails, [R]efresh, H[o]st, [W]hois, [H]elp, [Q]uit. 6753>>w GET NETBLOCK INFORMATION FROM IP ADDRESS... # whois 64.97.168.33 Critical Path Inc. CRITICALPATH-5 (NET-64-96-0-0-1) 64.96.0.0 - 64.99.255.255 Critical Path, Inc.: cluster c001.snv virtual hosts CP-64-97-0-0 (NET-64-97-0-0 -1) 64.97.0.0 - 64.97.223.255 # ARIN WHOIS database, last updated 2005-03-08 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. [S]tatus, [L]ist PIDs, [D]etails, [R]efresh, H[o]st, [W]hois, [H]elp, [Q]uit. 6753>>q SMTarPit Monitor CLI version 0.0.1 quitting. #
Download
Click here to download the tarball...
Name: smtarpit060.tar.gz.
Length: 29,722 Bytes.
MD5 hash: fe4ca7f7a14dd9cebcc45737656e93dc
Version History
0.6.0 Released 14/01/2006 29,722 Bytes
MD5: fe4ca7f7a14dd9cebcc45737656e93dcThis release adds a number of extra features: Note that SMTPMon and SMTPCLI are both bundled with SMTarPit and are unchanged since the previous release of SMTarPit. Note that you do not need to run SMTPMon or SMTPCLI in order to run SMTarPit - these two programs are used only to monitor the tarpit.
- Maximum number of instances - the tarpit will now (if you want) clear out the top few tarpits so that there is some headroom if you might need it. You can set the maximum to 40 but have any tarpit over, say 35, quit politely.
- Added a random element to the mode decision time so that it is more difficult to determine whether or not it is a tarpit - evades server profiling.
- Disallowed Domains - sometimes, the spammers will send you your own IP address as a sending server name (helo/ehlo). This stops that and labels them as a spammer (which we knew any way).
Zombie Killer mode - if you want to run this, this allows you to send a string to the so-called server at the other end. The server at the other end is trying to access what it thinks is a computer resource that, of course, it is not authorised to access. Attempting to send unsolicited email is a criminal offence. Sending a string like this might terminate the zombie process on the remote machine leaving the infected machine's user to get on with his/her email attachment opening (which is most likely how they became infected with their spam server in the first place) and installing and updating their anti-virus and intrusion detection programs. By terminating the zombie process, the tarpit is doing them a service. If it is a proper mail server, it will not be affected by this at all.
- Zombie Killer mode produces a string that is normally just nulls (x00) but in the middle of it, there is by default the 'EICAR-STANDARD-ANTIVIRUS-TEST-FILE' string ('European Institute for Computer Antivirus Research'). Note for anybody that is not familiar with this - this is not a virus and it does not have any virus-like properties. It is just a sequence of printable characters that all anti-virus programs worth anything recognise so that you can check that your AV system is working and do so safely without any risk of infecting. See the EICAR site for more details on this. The reason it is there is so that if the zombie spam sender process saves some sort of log file, the user's AV program will pick it up as 'infected' (albeit with a totally harmless string) and they should take note and at least ask themselves; 'why is this (email server) program on my computer?'. If you don't want to use the EICAR string on your tarpit, the line with it in is around line 630 (depending upon what configuration lines you have added). Just remark that line out by putting a hash mark ('#') at the beginning of it or delete it.
- Spam Sender Labelling mode - if you want to do this, this just lets the server at the other end know that we know it is sending spam (which, of course, is the only reason they bothered to connect in the first place) and kills the connection.
- Alternatively - you can set this so that between certain times of the day - defined using a fuzzy time - it stops any Zombie Killer and Spam Sender Labelling and acts like the normal tarpit. If you have Zombie Killer and Spam Sender Labelling turned off, activating this will have no effect. Note that you can have one turned off and the other on and this will only affect the one that is turned on.
- I've added a small delay in closing the tarpit program after the connection has finished. This stops flooding and overloading your xinetd super server. The image on the right shows a short time set to demonstrate how the fuzzy time transition (between activity modes) changes the behaviour of the tarpit (green is outbount, red is inbound, each sample is the average per second over 30 seconds and each vertical line is 15 minutes). Normally, set the time (in seconds) to 10 times the number of tar pits you are using and the used bandwidth will not be too different.
0.5.5 Released 09/03/2005 27,835 Bytes
MD5: 7c00d1de3bb937a802674685038f591dSMTarPit... SMTPMon (GUI)
- This version of the tarpit (0.5.5) adds 'special IPs' to be treated similarly to the special domains in the previous version. This means that if you have a troublesome spammer that quits early and works from one IP address, you can specify that so that the tarpit runs quicker for just that one - you have to balance how much quicker against losing him/her very quickly.
This version of the GUI monitor (0.5.1) adds a number of features...SMTPCli (CLI)
- Extra Hosts checks - now checks IP address for DNS entry and vice versa, commenting if there is a common IP address in the output
- The interface now has a status bar which is now where the auto-re-list checkbox is, tidying up the row of buttons
- The whois now looks for an abuse address or abuse contact details
- Now, to retreive the information, just click on the PID in the left pane and to update it, click on the PID line in the right pane.
This is a new program (0.0.1), allowing you to monitor the tarpits on a system without a GUI (such as on ssh / telnet or even a teleprinter...Just see the example program output listing above so see what you can expect.
- This is pretty much the same as the GUI monitor except that it runs off a terminal (go on, get that old teletype out of the broom cupboard and give it a go).
- Just type the letter in the square brackets (eg, for [C]hoose, just type a letter c). There is context sensitive help available.
0.5.4 Released 11/02/2005 23,593 Bytes
MD5: 97abe654cc0b9fbd5f903e762389db1dThis release adds a number of special features: Also in this release is the SMTarPit Monitor program. This needs Perl Tk to be installed on your system - the easiest way to find out if it is, is to try running the program. To configure the Monitor, you just need to tell it what you have called your tarpit file (usually 'smtarpit') and also the location of the log file. From it, you can:
- It has an option in the configuration section that allows you to be a little 'naughty' with the mail from: address in that you can specify characters that you will not allow in the mail from: email address. This can be as naughty as not allowing '8' or, perhaps a '_' but whatever you choose you can make them a little bit more paranoid and waste a little more of their time;
- It has a list of special domains. One thing that I have noticed is that some of the aweful email porgrams that the spammers use time-out quickly when compared to proper email programs. If you notice that a particular 'claimed' domain name's email program is failing, you can specify the (partial) domain in this new configuration feature;
- It has a facility to act in a specific way on certain signals:
- If you send the tarpit a SIGUSR1, it will dump the current detailed log buffer contents to the long log file; and,
- If you send it a SIGUSR2, it will save a small file in the log directory which contains information about the current status of that particular tarpit server. This information is formatted so that it makes sense to a human (if you can read UNIX times that is) but this facility is used by the SMTarPit Monitor program.
- see the number and PIDs of tarpits that are running;
- look at the status of each tarpit;
- perform a host or whois to get IP address and netblock information including the abuse address for that netblock; and,
- set it so that it will update the list of PIDs automatically (interval configurable in the program's configuration section.
0.5.3 Released 21/01/2005 17,414 Bytes
MD5: d6261cd49f736a8c01294396b808474c
- This version looks to see how many instances exist as running processes. If it sees more than the limit set in the configuration section, it declines the offer of a connection politely.
- It now saves the log and closes when sent a SIGINT (command line 'kill') and also a SIGPIPE from xinetd if the other end just drops the connection (this happens quite a lot it turns out - they don't get what they want and they don't use 'quit', they just drop the connection).
- You can define the timeout duration in the config section (if they take more than, say, 4 minutes, you drop the connection on them thus precluding them clogging up your processes with idle telnet connections).
- It will time-out itself if it lasts more than a certain time in a loop (config it to last for a week and then just exit if you want, or you could see if you can make it last for a year ;-)) - define in the config section.
- Sender's address is checked using a reasonable set of rules so <> amongst many other email address lines are not permitted.
- It can be configured to dump the buffered log to the log file after a specific time (every hour if you want - default is that it will not - see the config section.
- Date format in the log files now includes the year.
0.5.2 Released 05/01/2005 15,516 Bytes
MD5: 520d770ea5ae9492d13c0fafffaac7ca
- This release allows the client to put additional information after the address in the rcpt to: line such as 'notify=failure,delay'.
0.5.1 Released 13/11/2004 15,463 Bytes
MD5: 011abaee7208383c633e72ecd3611a5a
- This release uses a static table to make sure that the randomly chosen server identity is consistent between calls - varying it could lead to consistency checking in order to determine whether a site runs a tarpit or a normal MTA.
- Also, it has the configuration option of whether you want the detailed log or not. Not doing so means that you just have the small log to go on.
- It also records the remote IP address in both the quick and normal log files.
v0.5.0 Released 11/11/2004 14,993 Bytes
MD5: 27957553bdcc9a5e3feb1052755d16d4This is the first publication of this program. I have been developing and testing it for quite a time - actually running it for several months with reasonable results (wasting a lot of spammer's time).
- The program chroots as soon as it can.
- All of the configuration is at the beginning of the program.
- Help pages for the server are included but these can be disabled or altered depending on your own needs.
Is it legal?
One concern that some people might have is whether or not running a tarpit is legal.
In many situations, you would have to be stopping the email from getting through in order to commit an offence. Using the tarpit though, you are not preventing any mail from getting through to any destination simply becouse there is no 'to' for the mail to get to. Any mail destined for any other address is simply rejected by the tarpit so the spammer knows that that mail hasn't been sent.
Another concern is; 'is it entrapment?' For it to be entrapment, you have to have enticed your victim into a situation.
- Firstly, port 25 being open on a firewall might be enough to entice some people but by investigating that port, they are commiting an offence as they are not authorised to do so.
- Here, the provision of thousands of email addresses that do not exist is not sufficient to turn somebody into a spammer. It if was, there would be no bandwidth left for any legitimate Internet use - the offering for sale of '10 million valid email addresses' doesn't seem to have had that much effect. If somebody did have a case for the presence of thousands of email addresses making a spammer out of them, it would be more likely to succeed if the defence was related to mental health.
- The poisoning of email address lists with bogus ones cannot be a problem because the people who sell these lists claim that they are all valid email addresses that have been checked. As these do not exist, they cannot claim that their business mail is solicited by the recipient.
For the purpose of law enforcement, if it is forseen that under the law of a particular country (perhaps where defence lawyers get paid a lot), using tarpitted addresses could be seen as entrapment, an individual who is identified by the tarpit process (the tarpit signature is recognised by the sys admin who then notes the user) can be prosecuted for sending other spam to other addresses - there should be plenty of evidence.
Have fun.
Paul Grosse
email paul-grosse at ntlworld dot com
