[sf-lug] unauth services, spamvertising, stolen firepower, oh my!

[Michael Paoli]

unauth services, spamvertising, stolen firepower, oh my!

Ah, yes.  Once upon a time, one didn't get much more than the
occasional "doorknob jiggle" - mostly just the occasional probe to see
if one reasonably secured things - and finding things reasonably secure,
the jiggler of door knobs would go onto the next address/port to try,
and would soon be doing the doorknob jiggle somewhere else entirely.

That was then, this is now.  In general now, if it's open, it'll be
found, and generally in rather short order.  Stolen firepower?  The
bad guys/gals/forces are pretty much awash in it.  So much so they can
well afford to be highly wasteful in its usage, and often are very much
so.  And so many of 'em out there, they don't need to worry much about
taking great efforts to hide - most of their "attacks" are frequent,
and "noisy".  It's probably mostly only (much) higher value targets that
they even bother to try and be particularly stealthy about it.  I think
they presume that most of their targets are something probably not all
that valuable, but that they can add to their bot arsenal to attack yet
more targets ... but they'll also check, and if they can do anything at
all useful - spamvertise, steal credit card or personal data,
ransomware it if the target might actually care and cough up money ...
leverage contacts for more targeted phishing (spear phishing) attacks
...

Looking at logs (at least occasionally - much of the automated stuff
should/does do the bulk of that - but for one reason or another there's
occasionally reason to look in more detail) ... tends to be relatively
disheartening.  *So* much 'firepower' directed, so regularly, and ...
most of it utterly wasted - not even at all effective at what they're
attempting - and so damn uncoordinated - same stupid irrelevant
exploits tried over and over and over and over again (well, generally
highly irrelevant to me and my systems anyway) ... so wastefully
inefficient.  But, with most all that firepower being stolen -
"cost"/waste isn't a significant concern of the attackers and their
botnets, as they're pretty much awash in firepower - especially
quantity and bandwidth, anyway.  Uhm, intelligence and organization?
Uhm, not quite so much so.

So, e.g. wiki, still rather amazes me how much bot cr*p gets thrown at
it - all really waste of everyone's resources.  Ditto for the various
more general web attacks, and yes, likewise, really pretty much any
port that's open, and heck, even all the trying of all the ports that
aren't even open.  Years ago I started using fail2ban.  Not so much
that I *needed* it.  But it was to reduce the annoyance factor - the
spinning rust was much noisier when the dictionary attacks were being
run against ssh ... the pattern in noise was quite regular and annoying
after a while, ... and ... the practical solution to that - fail2ban -
cut 'em off quite early in their crud, and makes for much quieter
spinning rust.  With SSD, no longer a noise factor ... but still helps
cut down on the clutter and volume of utter cr*p that otherwise ends
up in logs, so, e.g., can often keep consumed log space from exploding
out of control.  So, yes, I do still find fail2ban useful in those
regards.  It won't do so much with attackers with huge bot nets that
change source IPs with damn near every single attempt ... but thus far
I don't see a lot of that out there - but I'm sure it's probably used -
and more slowly and stealthily - against higher value targets ... and
I'm sure that'll eventually work its way down to the not-as-interesting
targets.

And so it goes, ... it does tend to be an ongoing escalation war.
<sigh>  Internet is no panacea for avoiding all things bad.  So long as
there are humans, and they are mostly as they are, there will likely
continue to be significant "bad" in the mix.  "Oh well" - freedom, free
will, tends to include some "bad" in the mix.

And ... backup, backup, backup.  Yes, too bad regarding what happened to
wiki on that other LUG.  They ought have known better, and yes, were
forewarned :-).  There's a whole lot else that can go wrong besides
wiki history overflowing/expiring - e.g. major admin booboo, theft of
system or drive, minor catastrophe (e.g. plumbing, electrical)
destroying drive, etc.  And don't do like one stupid company did -
production and backups all hosed at same time - as they had them all
online, and all could be altered/destroyed, simultaneously, from (or
via) one single account, and, you know, Mr. Murphy and his laws ...
guess what happened to them.  Thus also, the rules for offsite backups,
etc.  They didn't learn that lesson on proper handling of that, until
all their key data and backups were toast.  I remember a case, many
moons ago, customer devastated 'cause they lost their data -
unrecoverable read errors ... on a floppy, ... one floppy, years of
work, no backup.  About a $0.59 investment in a 2nd floppy diskette and
occasionally doing and checking backup, would've saved 'em from that
great loss ... but they didn't know better, so they ended up learning
the very hard way.  Experience is one helluva teacher, but folks tend
to remember the lessons taught by experience.  Advice, often being
inexpensive, or even free, folks tend to often far to easily dismiss
(and likewise often overrate expensive advice).  Folks ought heed good
advice - but many don't ... or only do so after experience painfully
reinforces the lesson.  Then we have the option of pointing out the
"Told you so."  ;-)

Oh, and for *some* contexts, unauthenticated editing/commenting *can* be
okay - particularly if reasonably watched, and typically more
limited/controlled contexts/exposures (e.g. anonymous editing is
permitted on Wikipedia, and perhaps slightly amazingly, even sort of
kind of mostly works) ... but for your more typical wiki opened to the
Internet on today's Internet ... that's a no-go.  Yep, I had one bloody
unimportant page so exposed, and that would auto-revert after a bit of
time if not changed, and ... they f*cked it up.  Can't play nice?  You
don't get to play.


> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] SF-LUG (& BALUG) SSL/TLS certs renewed, etc.  
> (thanks to	https://letsencrypt.org/)
> Date: Sun, 1 May 2016 16:49:51 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
> [The dokuwiki playground:]
>
>> Anyway, changed the permissions - no more editing by unauthenticated
>> users.  That should prevent them from (ab)using it, and once it goes
>> that approximately 25 mintutes without being used at all, it revert and
>> drop all their spamvertizing.
>
> I know it's just the playground, and intending no criticism, but the
> writing's been on the wall for a couple of decades that _any_ unauth
> Internet service on _any_ port will get comment spammed on an ongoing
> basis.  This gives you an idea of how much (mostly) stolen firepower
> the spamvertisers can afford to waste.
>
> I saw this a long time ago when Santa Cruz Linux User Group (which no
> longer exists) set up a wiki, left it completely defenseless with no
> authentication required in the name of maximal user friendliness.
> Several people put some signficant work into building its content after
> it went up -- and then the admin ignored what was going on with the
> wiki, for about a week.
>
> Within that week, a comment bot found it and started mindlessly
> submitting pages revisions.  The admin noticed, went to revert to the
> last non-spam page versions, and then got a second shock:  So many
> spam-comment page rewrites had been made to each page that the last
> non-spam page revision was no longer in the wiki history.  So, the
> entire wiki had to be abandoned and taken down, as they'd lost
> everyone's work.
>
> The admin had decided to forego backups because, hey, the whole version
> history is there, so what could go wrong?
>
> (You'll never guess who tried to warn him that unauthenticated editing
> was a bad idea.)