SMTP connect-disconnect events, Are they DoS attacks, or broken spambot?

SumGuy · 23 Feb 2014, 10:08 PM

I've been running a mail-server for more than 10 years, using the "quaint" but very reliable and bullet-proof software known as "Post.Office" made by the long defunct "Software.com" company.

So I've come here to ask the following question about remote machines that perform SMTP connections (port 25) to my server that just time-out without anything else appearing to happen.

I see this happen several times a day, but 99.9% of the time it's just a single SMTP connect/timeout pair, repeated maybe 3 or 4 times over a 24 hour period from different IP addresses. Sometimes, instead of a single connect/timeout, it will be a string of maybe a dozen.

Then maybe once every other month I'll see a sequence of hundreds or even a few thousand connects/timeouts - like what happened yesterday morning.

This is on my SMTP server. Here's an example:

------
20140222055948-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22
20140222055951-0500:SMTP-Accept:Connect:[98.190.158.7]
20140222055956-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22
20140222055958-0500:SMTP-Accept:Connect:[98.190.158.7]
20140222060002-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22
20140222060006-0500:SMTP-Accept:Connect:[98.190.158.7]
20140222060010-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22
20140222060013-0500:SMTP-Accept:Connect:[98.190.158.7]
20140222060018-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22
20140222060020-0500:SMTP-Accept:Connect:[98.190.158.7]
20140222060025-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22
-------

The "9:0:22" means

- the time of the total connection (9 seconds)
- the number of messages exchanged (zero)
- the total amount of data transferred (22 bytes)

Between 4:35 am until 8:35 am (exactly 4 hours to the second) my server was answering SMTP connect requests from 98.190.158.7, a total of 2204 attempts which works out to an average of one attempt every 6.5 seconds.

I have no idea what was contained in the 22 bytes that was supposedly transfered - they are not logged.

A graph of the time between connections over the 4 hours shows quite erratic times for the first 1/2 hour, alternating between 3 to 12 connections per second and then nothing for 1 to 2 minutes before repeating. Then during the next 3.5 hours it settles very quickly into a tighter spread of between 2 to 12 seconds between connections.

Also during the first half-hour, the connect-time rises quickly to 80 seconds, then levels off at 120 seconds, and then falls quickly to a rock-solid floor of 9 seconds during the remaining 3.5 hours.

For the first 4 or 5 attempts, the number of bytes transferred was 22, but then drops to 0 during the first 1/2 hour, then goes right back to 22 bytes for the remaining 3.5 hours.

If these were attempts to deliver email to non-existent accounts, or relay attempts to other domains (both of which I've seen happen) they would be indicated as such in the log files (which I don't see here). So what-ever is happening during these connections is not the result of a dictionary attack or a relay attempt.

So I'm wondering what is really going on here.

Is this a DoS attempt on my server from a single IP (98.190.158.7) or from multiple computers - all of which are forging the same IP?

If the IP is being forged - would it cause my server to generate responses aimed at 98.190.158.7 - which would be a way to use my server as DoS tool against 98.190.158.7 ?

Or is this all this a (known) symptom of a broken spam-bot?

SumGuy · 25 Feb 2014, 12:40 AM

Really?

Nobody here has seen these connect/timeout events in their server's log files - or knows what they represent?

Havokmon · 26 Feb 2014, 11:02 PM

Looks to me like someone might be doing user lookups. Trying to determine if your RCPT TO: will validate the email address during the SMTP session.

The other possibility is remote systems running a nmap or portscan on you - but it wouldn't be the same IP over and over.

I'd just block that IP if it continues. If you see it happen more and more, then run something like fail2ban and modify it for short byte events.

23 Feb 2014, 10:08 PM	#1
SumGuy Junior Member Join Date: Feb 2014 Posts: 2	SMTP connect-disconnect events, Are they DoS attacks, or broken spambot? I've been running a mail-server for more than 10 years, using the "quaint" but very reliable and bullet-proof software known as "Post.Office" made by the long defunct "Software.com" company. So I've come here to ask the following question about remote machines that perform SMTP connections (port 25) to my server that just time-out without anything else appearing to happen. I see this happen several times a day, but 99.9% of the time it's just a single SMTP connect/timeout pair, repeated maybe 3 or 4 times over a 24 hour period from different IP addresses. Sometimes, instead of a single connect/timeout, it will be a string of maybe a dozen. Then maybe once every other month I'll see a sequence of hundreds or even a few thousand connects/timeouts - like what happened yesterday morning. This is on my SMTP server. Here's an example: ------ 20140222055948-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22 20140222055951-0500:SMTP-Accept:Connect:[98.190.158.7] 20140222055956-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22 20140222055958-0500:SMTP-Accept:Connect:[98.190.158.7] 20140222060002-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22 20140222060006-0500:SMTP-Accept:Connect:[98.190.158.7] 20140222060010-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22 20140222060013-0500:SMTP-Accept:Connect:[98.190.158.7] 20140222060018-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22 20140222060020-0500:SMTP-Accept:Connect:[98.190.158.7] 20140222060025-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22 ------- The "9:0:22" means - the time of the total connection (9 seconds) - the number of messages exchanged (zero) - the total amount of data transferred (22 bytes) Between 4:35 am until 8:35 am (exactly 4 hours to the second) my server was answering SMTP connect requests from 98.190.158.7, a total of 2204 attempts which works out to an average of one attempt every 6.5 seconds. I have no idea what was contained in the 22 bytes that was supposedly transfered - they are not logged. A graph of the time between connections over the 4 hours shows quite erratic times for the first 1/2 hour, alternating between 3 to 12 connections per second and then nothing for 1 to 2 minutes before repeating. Then during the next 3.5 hours it settles very quickly into a tighter spread of between 2 to 12 seconds between connections. Also during the first half-hour, the connect-time rises quickly to 80 seconds, then levels off at 120 seconds, and then falls quickly to a rock-solid floor of 9 seconds during the remaining 3.5 hours. For the first 4 or 5 attempts, the number of bytes transferred was 22, but then drops to 0 during the first 1/2 hour, then goes right back to 22 bytes for the remaining 3.5 hours. If these were attempts to deliver email to non-existent accounts, or relay attempts to other domains (both of which I've seen happen) they would be indicated as such in the log files (which I don't see here). So what-ever is happening during these connections is not the result of a dictionary attack or a relay attempt. So I'm wondering what is really going on here. Is this a DoS attempt on my server from a single IP (98.190.158.7) or from multiple computers - all of which are forging the same IP? If the IP is being forged - would it cause my server to generate responses aimed at 98.190.158.7 - which would be a way to use my server as DoS tool against 98.190.158.7 ? Or is this all this a (known) symptom of a broken spam-bot?

25 Feb 2014, 12:40 AM	#2
SumGuy Junior Member Join Date: Feb 2014 Posts: 2	Really? Nobody here has seen these connect/timeout events in their server's log files - or knows what they represent?

26 Feb 2014, 11:02 PM	#3
Havokmon Senior Member Join Date: Apr 2003 Posts: 180 Representative of: VFEmail.net	Looks to me like someone might be doing user lookups. Trying to determine if your RCPT TO: will validate the email address during the SMTP session. The other possibility is remote systems running a nmap or portscan on you - but it wouldn't be the same IP over and over. I'd just block that IP if it continues. If you see it happen more and more, then run something like fail2ban and modify it for short byte events.