mailto: blog -at- heyrick -dot- eu

You are not reading my b.log using HTTPS. You can switch to HTTPS by clicking here.

Haters gonna hate and spammers gonna spam

I have a friend running a mail server, and he is frequently looking for new ways to deal with spam login attempts - including recently IP-blocking an entire country (not that the crap from that country didn't justify such actions).
Thing is, as horribly naff (and broken English) as the phrase is, there is a logic to:
haters gonna hate
If you have never come across the phrase before, it is saying that offensive hating jerkwad trolls are... offensive hating jerkwad trolls. And that it's just how they are wired, and yeah, they are probably offensive hating jerkwad people (coupled with an unhealthy dose of insecurity as most try to be anon). Sounds like stating the obvious, but sometimes it needs to be pointed out so that people who are feeling upset by the offensive hating jerkwadness of it all can lighten up and stop caring so much about the opinions of somebody whose guiding light in life is to be a troll. Yeah, productive, that. Who needs to listen to a troll? I would value the opinion of the dog crap that I stepped in more than the opinion of an internet troll.

Now let me add an equally naff tech equivalent:

spammers gonna spam

Think about it carefully. It costs little to get connected to the internet. Most connections these days are not dial-up on demand, but are always on. You don't pay by the kilobyte, you don't pay buy the minute, you don't pay by the mile. The capacity is vast. Not unlimited as city folk will tell you, but vast. Vast enough that it probably goes unnoticed that people's compromised PCs may be trying to break into your mail server. I could write a small program to try a dictionary-based attack on your server. Does the root@ account exist? Right - aardvark, aback, abacus, abaft, abandon... If I made a small module, it wouldn't be hard to get it to fetch a small wordlist from a server and then try your account maybe once every ten seconds. Hide that in one of my programs, it could find itself passed around the thousands tens of RISC OS users in short order.
That's pretty much how it works, at a very basic level.

Do they do it to annoy you? Do they do it to mess with you? No, they simply do it because they can.

To give you an idea, I am running a small server that I'm developing. It sits behind a No-IP redirect, but it is an Orange France dynamic IP address. And these, my friend, are probed regularly. If Cartman gets lots of anal probes from aliens, I get lots of login probes from the Chinese (and others, but mostly Chinese).
For most of my readers, this is new. I've not mentioned it before as I want to have something to show you before I show you. For very few readers, they already know. Point is, it isn't publicised, yet it gets "attacked", frequently.

Here's my current list of IP bans:

Blacklist
16++ IP addresses have been blacklisted, the most recent 16 are recorded.
  42.234.240.155   (3)
  110.246.45.82    (3)
  78.157.20.247    (3)
  171.123.51.63    (3)
  111.37.47.172    (3)
  119.202.103.86   (3)
  123.162.85.224   (3)
  104.175.80.226   (3)
  122.94.219.215   (3)
  27.40.151.186    (3)
  27.219.58.185    (3)
  112.241.123.206  (3)
  121.57.151.141   (3)
  110.241.233.236  (3)
  112.87.181.181   (3)
  175.167.179.235  (3)
  (note: the blacklist table only holds 16 entries)
Note the "16++" in the description line. This is because there have been more than 16 banned IP addresses, but since the same address doesn't call back (that I've noticed), it is less waste of resources to just record the last 16 and let older ones fall off of the list.

Did you notice the "(3)" afterwards?

Let me explain how an IP address gets itself banned. Ready?

Connection is pending
Port 0 is available.
Accepting connection on port 0.
Accepted as socket 22.
Connection is from ip address 111.37.47.172 at 15h11m22s on 2015/08/19.
Login task started - port 0, socket 22
This means that the IP address 111.37.47.172 has connected to the server and is being treated as port #0 by the server.
Connection is pending
Port 1 is available.
Accepting connection on port 1.
Accepted as socket 23.
Connection is from ip address 111.37.47.172 at 15h11m35s on 2015/08/19.
Login task started - port 1, socket 23
This means that the same IP address has connected again. This time the server has allocated port #1 to this connection.
Login task deregistered - port 0.
Connection is pending
Port 0 is available.
Accepting connection on port 0.
Accepted as socket 22.
Connection is from ip address 111.37.47.172 at 15h11m47s on 2015/08/19.
Login task started - port 0, socket 22
The first line indicates that the first connection gave up. As there was no information from the login task, it is clear that the remote machine didn't try to send anything. Sometimes I see "echo -e //"(etc) and "cisco:<ipaddress>" tried as login names, but usually there is no response at all. That's because my server doesn't look like a Unix shell login, nor does it look like a mail server, or any other sort of server that might want to be compromised.
Login task deregistered - port 1.
Connection is pending
Port 1 is available.
Accepting connection on port 1.
Accepted as socket 23.
Connection is from ip address 111.37.47.172 at 15h11m59s on 2015/08/19.
Login task started - port 1, socket 23
Login task deregistered - port 0.
Connection is pending
Port 0 is available.
Accepting connection on port 0.
Accepted as socket 22.
Connection is from ip address 111.37.47.172 at 15h12m12s on 2015/08/19.
Login task started - port 0, socket 22
Login task deregistered - port 1.
Rinse and repeat.
Connection is pending
Port 1 is available.
Accepting connection on port 1.
Accepted as socket 23.
Connection is from ip address 111.37.47.172 at 15h12m25s on 2015/08/19.
is firebombing, dropping
Now the server is getting annoyed. There is no reasonable justification for attempting five connections in 50 seconds. Too many connections too close together and the server will blacklist the IP address. When that happens, the server will response with a polite message explaining to the user why they have just been booted off.
Login task deregistered - port 0.
Finally, the connected port #0 (the last attempt that was allowed) disconnected.

Connection is pending
Port 0 is available.
Accepting connection on port 0.
Accepted as socket 22.
Connection is from ip address 111.37.47.172 at 15h12m43s on 2015/08/19.
is blacklisted, dropping
The first time after being blacklisted. The server, still polite, will inform the user why they have not been able to access it. It isn't the same message as before, this is a follow-on message explaining why access to the server is not being granted.

Connection is pending
Port 0 is available.
Accepting connection on port 0.
Accepted as socket 22.
Connection is from ip address 111.37.47.172 at 15h13m10s on 2015/08/19.
is blacklisted, dropping
The second time now. Repeat previous message in case the user is a bit dense.
Connection is pending
Port 0 is available.
Accepting connection on port 0.
Accepted as socket 22.
Connection is from ip address 111.37.47.172 at 15h13m41s on 2015/08/19.
is blacklisted and persistent, dropping hard on attempt 3
And finally the third time. The "dropping hard" means that the server will not respond politely. If the IP address matches, the connection is discarded without mercy.
Funnily enough, the 'bots don't try a fourth time. That's why all the entries end with "(3)".

Do I get respite? Do I hell...

Connection is pending
Port 0 is available.
Accepting connection on port 0.
Accepted as socket 22.
Connection is from ip address 83.248.59.74 at 15h30m15s on 2015/08/19.
Login task started - port 0, socket 22
Connection is pending
Port 1 is available.
Accepting connection on port 1.
Accepted as socket 23.
Connection is from ip address 78.180.190.15 at 15h30m32s on 2015/08/19.
Login task started - port 1, socket 23
Login task deregistered - port 0.
Login task deregistered - port 1.
Yup, barely a quarter hour passes and some other twat's computer has a go. The one described above was from Beijing (China), this one is from Izmir (Turkey).
Rinse and repeat. All day. All night. Always.

 

However, I accept that "this happens" (replace "this" with another applicable four letter word containing the same letters) and that I should take reasonable steps to minimise the effects (blacklist 'em) while not being too harsh that it might blacklist legitimate users - consider somebody trying to attempt from patchy mobile coverage. The logical response is "don't", but we've all done it, right? The whole "I know this signal is pitiful and barely works but please let me log in and check my emails right now because my entire life absolutely depends upon it".
Been there.
Done that.
And as such, it is a balance to not be hardship to legitimate users while keeping the offensive hating jerkwads away. It can't be done. The best that can be done is to minimise the impact of the offensive hating jerkwads. If it means tying up one of the login tasks for a minute (until it times itself out on no input), until it happens enough to trip the blacklist, then so be it.
It is much more work to block entire countries. They aren't harming anything. Even if they did understand how to log in, three incorrect guesses and you're out. I have not coded it yet, but I plan to add a system where if the user is booted three times (nine guesses), for a short while every guess will be treated as a wrong guess - even the correct password.

Beyond that? Beyond dissuasive actions and damage limitation? There is no "beyond that". It will happen, it will keep happening, and it will only get worse, in much the same way as Web 2.0 sucks much more than Web 1.0 ever did.

The thing that surprises me? I'm surprised that people running servers that get hit upon by these foreign machines don't have a small process that will attempt to probe the machine (akin to nmap) to see if it is something that is known to have vulnerabilities, and to then attempt to crash said machine. Hard on the unsuspecting user, certainly, but if their computer starts crashing they might realise that something is wrong? Plus it'll be like a community service for everybody. Right now I am 90.32.4.122. Once the bot has given up on me, I am sure it will try 90.32.4.123, and onwards.

 

 

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

Gavin Wraith, 20th August 2015, 20:46
My knowledge of how the internet works is limited, and based on "Internetworking with TCP/IP" Vol I by Douglas Comer and Vol II by Comer and Stevens, which date back to 1991. No doubt much has changed since. In the light of what we now know (and did not then) about spam, DOS attacks and other discourtesies, how should networking protocols be adapted to cope? At the moment there is little that an individual user can do, beyond complaining to her ISP or maintainers of blacklists. Her defences are limited to her own node on the internet. But might it not be possible to extend TCP/IP to include some automatic responses to certain behaviours? Maybe this is what W3C is up to betimes?
Mick, 22nd August 2015, 16:56
Curbing attempts to discover passwords is one thing, limiting damage to maintain a good mail reputation if they do gain relay access is another. However most connections I get are doing neither, but trying to send their crap to my few internal mailboxes. Some addresses they know of already, others they try to find by dictionary attack or occasional brute force. With the latter, I can't sit back and let that happen. Far better to ban offending IPs for a period of time. With dictionary attacks, I often see the sender address from a domain that exists with a mailbox name repeated as the sender name at one of my domains eg MAIL FROM tfgft@validdomain.net RCPT TO tfgft@mydomain.net. Seeing as the mailbox name changes each time (it could be tfgfd next time), providing it passes other tests, my server will try to validate the sender address of each attempt. If 100 attempts are made (that passed), my server would make 100 probes. Can you see if I were to allow that to happen, I'd start to look like a SPAMMER myself? SPAM is a problem, and is getting worse. So far today it has been quiet with only 126 barred in the last 24 hours. If they weren't barred, I'd see a log full of SPAM attempts from a good proportion of those. Left unchecked, they'd go on for hours. I like the way you block for your viewdata. Just right for now.

Add a comment (v0.11) [help?] . . . try the comment feed!
Your name
Your email (optional)
Validation Are you real? Please type 23414 backwards.
Your comment
French flagSpanish flagJapanese flag
Calendar
«   August 2015   »
MonTueWedThuFriSatSun
     12
456789
1112141516
18202123
24262729
31      

(Felicity? Marte? Find out!)

Last 5 entries

List all b.log entries

Return to the site index

Geekery

Search

Search Rick's b.log!

PS: Don't try to be clever.
It's a simple substring match.

Etc...

Last read at 20:55 on 2024/04/25.

QR code


Valid HTML 4.01 Transitional
Valid CSS
Valid RSS 2.0

 

© 2015 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.

 

Have you noticed the watermarks on pictures?
Next entry - 2015/08/22
Return to top of page