[conspire] Web spam and yandex forms

[Rick Moen]

Quoting Akkana Peck (akkana at shallowsky.com):

> I think I'd actually prefer to refuse connections (so it appears
> that there's no web server on the machine, instead of a web server
> that's refusing connection based on IP), maybe at the iptables level.

I'm having a little bit of difficulty articulating why tools like
fail2ban always strike me as a solution to the wrong problem, so I
probably won't fully crack that nut here, but I'll try anyway -- because
the issue isn't just limited to that tool but to "solving the wrong
problem" generally.

In general terms, in technology, a problem's appropriate solution is
one that terminates / prospectively averts (or at least limits or
mitigates) the harm caused -- without unjustifiable cost or
side-effects.  So, for example:  If the problem is that 40 mile rides on
my bicycle leave my arms numb and risk nerve damage to my hands, an
appropriate solution is wearing cycling gloves (with bits of padding)
and putting cork handlebar tape on my dropbars.

Here, the problem was described as "a variety of remote public IPs do
bad things using a Web form", and the remedy (fail2ban) amounts to
"punish each observed-guilty IP with an automated timeout of no
connections to our 80/tcp & 443/tcp allowed".  But did you address the
problem?  The page remains abusable in the same way as before.  Any of
millions of other IPs can do the same dirty deed at any time.
Meanwhile, the IP wasn't actually bad, and its ability to make a socket
wasn't the cause of badness.  

An appropriate solution would be to fix the _page_ so that the bad
action can no longer succeed.  That would end the harm in a direct
and responsive harm-terminating way, and render essentially theological
judgements about what IPs are evil irrelevant and unnecessary.  

For decades, I've heard fail2ban suggested as a response to arbitrary
attackers carrying out probes against security vulnerabilities, and I've
always been the guy saying "Wouldn't it be smarter just to eliminate the
vulnerability?  If you do that, then it doesn't matter if remote
processes probe to look for it."  

In that sense, it's always in my experience been a solution to the wrong
problem, not to the one at hand.

Of course, intelligent people of good will can disagree about what _is_
the problem of concern.  In this case, you said:

> On the other hand, now that I've blocked two IP addresses, I have a
> usable log file again that isn't completely flooded with warnings
> about cyrillic signup attempts.

Et voilà!  (Or, as I suppose a Norwegian would say, "Og der går du!" or
"Sånn!" = "like that!")  You conceive of the problem as "too much junk
in my httpd's log files."

I remember thinking that way, but then I adopted the norm of reading log
files only using grep and kin, not to mention also a well-tuned
logcheck.  Because, in my experience, you'll never prevent a host on a
public IP advertising services from having lots of junk in system
logfiles, and it's smarter to make a focussed view of them readable than
to make the raw log files readable.


> Meanwhile, I wrote a simple ChattyCaptcha class. Python, so it's no
> help if Rick wants a Perl version.

No, that's very cool!  I'll have a look.