sink.filesys.net
(on the left) and note that we're eating about 500 days worth of MTA time every week... which is not bad seeing as we've only been going for a short time.
Friday, October 27, 2006
500 Days in a Week
Just taking a look at the stats for
Thursday, October 19, 2006
SlowSpam IRC
If you have any questions about SlowSpam.com, try visiting the #slowspam.com IRC channel at irc://irc.nixhelp.org/slowspam.com. There may be people there that can help.
Yes, it's free!
Just to clear up any confusion about the TarPit service... IT IS FREE! Anyone is free to use it without permission, and without paying us anything. Although if you're about to switch over a very busy domain, please let us know: stu@filesys.net so we can monitor bandwidth usage and bring another server online if required.
Oh, and if you do feel the need to pay for the service, there's a donation button down on the left of the screen... click on it and absolve yourself of guilt.
Oh, and if you do feel the need to pay for the service, there's a donation button down on the left of the screen... click on it and absolve yourself of guilt.
Live Log File
We're now making the live log file from the TarPit available here. The "public" logfile is updated every minute or so. This is an extract of the real log file to remove all of the debugging messages, but shows every single connection.
The file is compressed using gzip and is a space-delimited text file. The fields in the file are:
Please don't automate fetches of the log file too often as bandwidth is at a premium... so make any automation only fetch hourly at most.
The logfile URL is: http://www.filesys.net/slowspam/logfile.txt.gz
The file is compressed using gzip and is a space-delimited text file. The fields in the file are:
time<sp>Close<sp>serial<sp>host<sp>delay<cr>
time
- the system time in milliseconds since 01/01/1970 00:00:00 GMTserial
- sequential number for this run of the tar pithost
- reverse DNS lookup or IP address of the connecting hostdelay
- number of milliseconds spent in the TarPitPlease don't automate fetches of the log file too often as bandwidth is at a premium... so make any automation only fetch hourly at most.
The logfile URL is: http://www.filesys.net/slowspam/logfile.txt.gz
Saturday, October 14, 2006
We're Back!
The TarPit is now back up and running on backup hardware, although at the moment, downloads of the software are unavailable. If you'd like a copy of the software please email: stu@filesys.net
Unfortunately we've lost all of the stats from the old machine so the figures on the site here are started from scratch.
Oh, and if anyone wants to donate a fan assembly for a Sun V20z then it'd be very appreciated! ;-)
Unfortunately we've lost all of the stats from the old machine so the figures on the site here are started from scratch.
Oh, and if anyone wants to donate a fan assembly for a Sun V20z then it'd be very appreciated! ;-)
Ooops
The TarPit is currently down as our server has suffered a hardware failure. A spare part (fan assembly) has been ordered, and in the meantime the service will be moved to a backup machine. Please be patient while this happens.
Friday, October 13, 2006
Statistics
The most popular request that's been made since this site launched is that the statistics from the Tar Pit be made available. Well, I've finally got around to building an automated script to extract the stats from the logs. You'll notice on the left hand side of the screen is a window with the stats inside. These are updated every minute to reflect the current state of the Tar Pit. To see updated stats, just hit refresh on your browser.
Let me know if you'd like any other statistics to be made available.
Let me know if you'd like any other statistics to be made available.
Wednesday, October 11, 2006
Statistics
Stats since: 21st September @ 21:09
Emails blocked: 39901
Hours in Tar Pit: 10572.57 (440.52 days!)
Unique SMTP Hosts: 20126
Wednesday, October 04, 2006
Statistics
Stats since: 21st September @ 21:09
Emails blocked: 25433
Hours in Tar Pit: 6473.15 (269.71 days!)
Unique SMTP Hosts: 12565
Backup MX
Just come across an article that talks about backup MXs and explains quite well the fact that spammers exploit ill-configured low priority mail servers.
http://www.brassy.net/2006/aug/backup_mxs_are_dangerous_and_pointless
http://www.brassy.net/2006/aug/backup_mxs_are_dangerous_and_pointless
Wednesday, September 27, 2006
Statistics
Stats since: 21st September @ 21:09
Emails blocked: 11438
Hours in Tar Pit: 3439.29
Unique SMTP Hosts: 9246
Monday, September 25, 2006
Statistics Update
The Tar Pit has now been running since 21:09 on 21st September and the current stats are as at (13:15 on 25th September):
...that's a lot of SPAM, considering we're only talking about a few domains.
A quote from someone who's using the SMTP Tar Pit at
"I've noticed my spam has dropped right off in the last few days
I reckon you are sucking them all in"
So, it's working... just tell everyone you know about it... we can only beat the spammers is people use tools like this to do so.
Emails blocked: 7449
Hours in Tar Pit: 1995.28
Unique SMTP Hosts: 5961
...that's a lot of SPAM, considering we're only talking about a few domains.
A quote from someone who's using the SMTP Tar Pit at
sink.filesys.net
:"I've noticed my spam has dropped right off in the last few days
I reckon you are sucking them all in"
So, it's working... just tell everyone you know about it... we can only beat the spammers is people use tools like this to do so.
Small Bug?
We're seeing a few JVM crashes when the Tar Pit is running... the error itself seems to be completely random, from SIGSEV's to problems setting socket parameters. So, if anyone is running the Tar Pit code, we recommend wrapping it in an "auto restart" script... such as:
These problems have happened on JVM build 1.5.0-b64, running on Solaris 9 on X86. This script is for Unix-like systems, I'm sure someone will come up with a Windows flavour and post it here.
#!/bin/bash
while [ 1 -eq 1 ]
do
java -cp SMTPTarPit.jar com.slowspam.smtptarpit.Main 25 >> tarpit.log
sleep 60
done
These problems have happened on JVM build 1.5.0-b64, running on Solaris 9 on X86. This script is for Unix-like systems, I'm sure someone will come up with a Windows flavour and post it here.
Friday, September 22, 2006
Day One
We made it through the first day. The SMTP Tar Pit has now been running for 24 hours against a few domains, and has blocked 1276 (suspected) spams, and delayed the spamming machines a total of 17690.34 minutes (294.84 hours).
First 12 Hours
In the first 12 hours of running the SMTP TarPit with just a few domains, it's received attempts to send 408 items of (suspected) spam, and the Tar Pit has kept them waiting for a total of 4900.13 minutes. Looking through the logs, it looks like most of the connections have been from machines on the end of Cable or DNS lines.
So, not bad for a start... let's get a few more domains actively using the Tar Pit and slow down the spam and spammers!
When I get time, I'll put some log file analysis stuff together and get it posting stats here automatically.
So, not bad for a start... let's get a few more domains actively using the Tar Pit and slow down the spam and spammers!
When I get time, I'll put some log file analysis stuff together and get it posting stats here automatically.
Slow Spam
Most people have big problems with the amount of spam that arrives in their Inbox daily. Some have anti-spam software loaded on their PC, others have spam filtering on their own mail servers. While spam filtering software is getting better, there is not a single solution that filters 100% of spam.
This site hopes to provide another tool in the fight against the problem of spam, and the spammers that send it.
OK, so let's get a little technical... most internet domains have DNS entries known as MX records. These records let mail servers know where to send email for that domain. A domain typically has a couple of MX records, a primary one where email is normally delivered to, and a backup that is used in the event of the primary being unreachable. Each MX record has a priority associated with it... this is a number, and the server with the lowest number is considered to be the primary. Servers with higher numbers are only normally used if the primary is not working.
Most mail servers have the ability to provide some level of filtering for spam. But in a multi-server environment it's quite common for the primary to have spam filtering but the backups to have none. This is typically the scenario if you run your own mail server complete with filtering, but rely on your ISP as a backup.
Knowing this, spammers have been able to exploit the fact that low priority mail servers have no filtering, by sending mail directly to them. Spammers use custom software that ignores the normal rules of picking the highest priority servers, instead preferring the lowest priority one. This software can range from modified copies of common MTA agents to custom written "spambots" that infect compromised machines on the internet.
So, what can you do about this? Well, we can start playing them at their own game. The SlowSpam.com website is dedicated to finding ways to slow down, and block spam on the internet. Today we're launching our first tool, an SMTP Tar Pit.
The ideal behind the SMTP Tar Pit is to trap rogue mail servers and prevent them from delivering spam, and to keep them busy for as long as possible, delaying them sending the next message.
To deploy the SMTP Tar Pit you need to be able to modify your domain's DNS record... if you don't know how to do this, find someone to help you. Add in an MX record with a low priority (high number) and point it to sink.filesys.net. This address is a publicly available instance of the SMTP Tar Pit.
So, for example, your DNS MX records may look like:
MX 10 myprimary.com
MX 20 mysecondary.com
MX 90 sink.filesys.net
In the event that a genuine email is tried to be delivered to the TarPit, the sending MTA will timeout, and retry against one of the other mail servers.
If you wish to run your own SMTP Tar Pit, you can download our software from http://filesys.net/slowspam/. The software is written in Java, so should run on most platforms... and the source is included if you want to examine what it's doing, or customize it for your own needs. It's released under the GPL, so please give back any changes you make to the community.
Worried about your email being disclosed to the TarPit? Well, it's certainly possible to write a TarPit that stores any email sent to it... but, this one stores nothing, and never actually sees the email. The most we see from the remote MTA (the sender) is the "HELO" message... we then keep the server busy so it never sends the email. This design allows the TarPit to use minimal network bandwidth, and avoids any privacy concerns as we never receive any details about the emails.
The only thing we log is the IP of the remote MTA, when it connected and when it disconnected. That's it.
We need help in the effort to defeat spammers, and encourage others to run public SMTP Tar Pits - drop us an email, we'll build up a list and post it here.
This site hopes to provide another tool in the fight against the problem of spam, and the spammers that send it.
OK, so let's get a little technical... most internet domains have DNS entries known as MX records. These records let mail servers know where to send email for that domain. A domain typically has a couple of MX records, a primary one where email is normally delivered to, and a backup that is used in the event of the primary being unreachable. Each MX record has a priority associated with it... this is a number, and the server with the lowest number is considered to be the primary. Servers with higher numbers are only normally used if the primary is not working.
Most mail servers have the ability to provide some level of filtering for spam. But in a multi-server environment it's quite common for the primary to have spam filtering but the backups to have none. This is typically the scenario if you run your own mail server complete with filtering, but rely on your ISP as a backup.
Knowing this, spammers have been able to exploit the fact that low priority mail servers have no filtering, by sending mail directly to them. Spammers use custom software that ignores the normal rules of picking the highest priority servers, instead preferring the lowest priority one. This software can range from modified copies of common MTA agents to custom written "spambots" that infect compromised machines on the internet.
So, what can you do about this? Well, we can start playing them at their own game. The SlowSpam.com website is dedicated to finding ways to slow down, and block spam on the internet. Today we're launching our first tool, an SMTP Tar Pit.
The ideal behind the SMTP Tar Pit is to trap rogue mail servers and prevent them from delivering spam, and to keep them busy for as long as possible, delaying them sending the next message.
To deploy the SMTP Tar Pit you need to be able to modify your domain's DNS record... if you don't know how to do this, find someone to help you. Add in an MX record with a low priority (high number) and point it to sink.filesys.net. This address is a publicly available instance of the SMTP Tar Pit.
So, for example, your DNS MX records may look like:
MX 10 myprimary.com
MX 20 mysecondary.com
MX 90 sink.filesys.net
In the event that a genuine email is tried to be delivered to the TarPit, the sending MTA will timeout, and retry against one of the other mail servers.
If you wish to run your own SMTP Tar Pit, you can download our software from http://filesys.net/slowspam/. The software is written in Java, so should run on most platforms... and the source is included if you want to examine what it's doing, or customize it for your own needs. It's released under the GPL, so please give back any changes you make to the community.
Worried about your email being disclosed to the TarPit? Well, it's certainly possible to write a TarPit that stores any email sent to it... but, this one stores nothing, and never actually sees the email. The most we see from the remote MTA (the sender) is the "HELO" message... we then keep the server busy so it never sends the email. This design allows the TarPit to use minimal network bandwidth, and avoids any privacy concerns as we never receive any details about the emails.
The only thing we log is the IP of the remote MTA, when it connected and when it disconnected. That's it.
We need help in the effort to defeat spammers, and encourage others to run public SMTP Tar Pits - drop us an email, we'll build up a list and post it here.
Thursday, September 21, 2006
Slow Spam Coming Soon...
Launching soon... a new tool in the fight against Spam and Spammers.
Watch This Space!
Watch This Space!
Subscribe to:
Posts (Atom)