Rick's b.log - 2015/08/19
It is the 21st of November 2024 You are 3.142.250.86, pleased to meet you!

Haters gonna hate and spammers gonna spam

Now let me add an equally naff tech equivalent:

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)

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

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

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

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.

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

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 15h12m43s on 2015/08/19.
is blacklisted, dropping

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

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

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.

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:

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.