Intrusion Detection System

[ZiNgA BuRgA]

(02-12-2011 09:22 AM)trialnick Wrote:  I do appreciate your work here ( this is one of my fav mybb forums), I like your review of plugins , but you have to understand that you belong to few people around who can fluently read codes and notice holes in plugins. That's not the case for many of us, so we should find the other way. At that point, you don't have competency to realize how the "ordinary users" think because you aren't part of them. Eg. bulletproof protection plugin was made for wordpress , because they are pretty aware that their users are those who use blogging to write about coffee, school, books , ants and that they aren't coders, designers etc. Hope you get my words now.

I understand what you're trying to say, but that doesn't mean one should take drastic measures which adversely affect user experience.  If you want to take it to an extreme, turning off the server will most likely prevent any attack, but the obvious consequence is no user can use it too.

(02-12-2011 09:22 AM)trialnick Wrote:  The script isn't perfect: that's why one has to search for other queries ...

No IDS system is "perfect".  The idea is simply to maximise detection of attack attempts and minimise effects on users.
A "better" IDS script is one which works better in both of the above.  I don't think a .htaccess blacklist is sufficient to really achieve the aim well - a PHP based IDS mentioned earlier in this thread will most likely have better heuristic capabilities.

(02-12-2011 09:22 AM)trialnick Wrote:  There's the great method to get blind mysql inj in very short way (using floor rand) and such queries should be prevented as well...I'll repeat: I have no idea who and how plugins are made and if I had enough time I'll read the whole code, but this is the shortcut I use (I have no ambition to be a coder ).

SQL injections are usually variables which haven't been "cleaned" by the processing script, for example:

SQL Code

SELECT field FROM table WHERE id={id}

---

If "{id}" is a variable and not cleaned by the script, someone could set {id} to have arbitrary SQL.
Variables are usually placed in the WHERE statement or later, which is why blocking INSERT or SELECT probably isn't terribly useful.