[darkgrue]

Here's an example of Security wierdness at my site. The IP's page is about 6 pages of blank banned IP's. Can't remove them, can't figure out what to do with them. The "details" link just brings up a page with a blank area (the rest of the page appear to render correctly including side blocks, headers and footers) where presumably the details would be.

Do I have a table with corrupt entries that needs to be cleaned out (and how would I do that), or is something else wrong?

[NanoCaiordo]

what about footer debug infos?

[darkgrue]

NanoCaiordo wrote:

what about footer debug infos?

Oh, uh, right!

PHP:

<?php
admin/modules/security.Warning line 286: inet_ntop() [function.inet-ntop]: Invalid in_addr value

and

PHP:

<?php
admin/modules/security.Warning line 311: inet_pton() [function.inet-pton]: Unrecognized address 
Notice line 319: Undefined variable: result

for IP's and Details, respectively. It would seem that the source table had bad data in it? (Pehaps as a result of running the old, broken CVS code at some point?)

[NanoCaiordo]

Bad data into the database table is, for sure, the source of the problem.

What i don't understand is why you got bad data in it and what is the 'broken CVS code' that you a referring to.

Does the problem still persist?

If so check that the ipn field, in cms_security table, is varbinary type (always been varbinary so for sure it will still be but we never know).

[darkgrue]

NanoCaiordo wrote:

Bad data into the database table is, for sure, the source of the problem.

Hmmn, I suspected as much.

NanoCaiordo wrote:

What i don't understand is why you got bad data in it and what is the 'broken CVS code' that you a referring to.

I was running the CVS code when the Security module was still being worked out. At one point I recall the module was acknowledged as being broken (to be fair, it was CVS code, and still be worked on). In any case, I did use the code at different stages of its development, so I guess it's not much of a surprise it's gotten bad data into the table.

NanoCaiordo wrote:

Does the problem still persist?

If so check that the ipn field, in cms_security table, is varbinary type (always been varbinary so for sure it will still be but we never know).

Table schema's good, I think.

I ran a TRUNCATE TABLE cms_security, which cleaned out all the blank entries (although now I think there may be a problem with the default theme template for that page, I don't know it's handling an empty list gracefully).

[NanoCaiordo]

TRUNCATE TABLE was a bit to aggressive, you have lost all user-agents ips, referrers and mail domains as well.

However you could get all install/sql/data/agents.php's data and run a custom script to insert the original data back.

If empty data was because an old CVS bug, see how you go now and let us know.

[darkgrue]

I re-ran the install/sql/data/agents.php script, so my table's back in order.

I think the IP's being wrong was the old CVS code causing problems. So I'll give it another shot, see what happens.

Documentation, and a possible problem with the template still stand out as needing work ATM though. =)

EDIT: I re-enabled Flood protection to see how it worked out, within a few minutes, I got a message from one my users saying that the flood protection was triggering repeatedly for them, so I had to turn it off again. It would seem that a straigt-up clicks-per-minute rate is not granular enough, regardless of how it's set.

I believe it also breaks the Web metaphor, for lack of a better term. One of the points of hyperlinks are that you can move through the heirarchy, backwards and forwards, quickly. If the interface now forces you to slow down significantly, the usability's going to drop through the floor. There are plenty of reasons that a user would legitimately fire off a salvo of requests, and I suspect trying to moderate the user's behavior in this way isn't going to work out well.

Not necessarily apropos to this, but I've recently come under attack from a linkspam botnet that was sending only the POST command of a forum posting (no GETs at all), so it was posting spam about at the rate of a post every 15 minutes. "Flooding" in one sense, but far too low and slow to be caught by any rate-limiting feature (even one strictly limited to posting).

I'm not sure that the feature really hasn't been overcome by events. If the rate's set high enough that it won't catch natural short-attention-span human browsing, your server's probably already too crippled by the amount of traffic to even process the checks to see if flooding is happening. Too low, and you have to browse like a granny to keep from triggering it (and alienate your users). It's not protecting from the linkspam.

So I guess the question is, what is Flood protection supposed to protect against in terms of current threats, and is it effective against it, or is it an idea that is just OBE?