Anyway all this is how it should work, but for some reason you stillThanks for explanation.
get spam through. So we have to figure out what goes wrong.
Here is what we should look into:It is new always. I couldn't find duplicate secrets in the log from the spammer. But I think it is possible to use the same secret multiple times.
1. Your spammer always requests the image. Does he always request it
with the same secret? Or is it a new one each time?
2. You say you can supress the spam by adding a die() in img.php - isYes, a die() stops the processing. Well, it could be stopped by producing an error with e.g. a printf() too.
this really all you do? Because as I said, the image wouldn't be
needed for an attack of the system itself. It would only be needed if
the spammer is actually solving the captcha - either manually or by
OCR.
3. OCR seems unlikely as there should be at least some failuresThere is nothing in the log, at least most errors are produced by me controlled during investigation.
visible in the log.
4. you said the spam does not correspondent to the log entries. howThis is a misunderstanding. Accidentally I deleted the spam post from the last log entries I sent. My fault. At the moment there are 2 small spam posts visible at my page. If needed I can send the corresponding log entries. The spam comes in in waves. Yesterday the attacks slows down a bit. Some numbers from today until round about 9:30am:
much spam did you get? could it be that you only got one spam message
(per IP)?
It could be that the spammer is using some browserI don't think so. If I don't break the processing in img.php all spam comes through.
automation tool. He gets a new IP, enters one spam manually and
records it, then runs a replay attack which now fails. That way the
first manual spam would go through and all others would fail.
It's of course entirely possible that I'm missing some flaw in my
implementation.
Andi
--
splitbrain.org
