SQL Injection attack against my server

Originally Posted by astrogeek I have concluded over the past year that the battle is already lost on this front and have been actively changing and adapting my own practices from that point of view.

I understand your attitude -- and it was the relentless spamming of our forum that led to us closing that feature -- but I just can't believe things are that bleak. Perhaps I'm just naive and doomed to have my optimism slowly ground out of me. That linuxquestions.org and various other forums still thrive suggests that it is in fact possible to win the battle -- at least win it enough to run a useful website.

I'm familiar with mod_security and seem to recall that it tends to result in puzzling request failures where it's hard to determine the reason for the failure unless you are aware that modsec is in your machine, rejecting any suspicious requests.

Your thoughts about changing the nature of your business are helpful. On my site, for instance, it's entirely safe to fail any request with the string 'concat' or %20union' or 'information_schema'. Indeed, I can even ban any IP that so much as bothers to attempt a request including such strings. Surely there are some general tactics like this in use?

Originally Posted by sneakyimp ...but I just can't believe things are that bleak.

Neither did I... until I finally did!

Originally Posted by sneakyimp Perhaps I'm just naive and doomed to have my optimism slowly ground out of me.

Any optimisim I had was ground to fine dust over the pas 12-18 months. But I do not believe my own experience was exceptional. It is just in the course of things I came into full frontal contact with the situation which irreversibly changed my outlook. I hope that you can keep some comfortable distance from it, but for most of us I think that distance is accidental at best and subject to rapid, terrifying change.

Originally Posted by sneakyimp That linuxquestions.org and various other forums still thrive suggests that it is in fact possible to win the battle -- at least win it enough to run a useful website.

I have no knowledge of how LQ manages things - they do a remarkable job of it! But in the end, I am sure they have already had great changes forced on them in the last few years, and that will continue.

If Jeremy is reading this thread I would like to solicit some general comments from Him on what it takes to keep the site going as it is, and trending of the slope of the cost and effort curve for the past few years.

Originally Posted by sneakyimp I'm familiar with mod_security and seem to recall that it tends to result in puzzling request failures where it's hard to determine the reason for the failure unless you are aware that modsec is in your machine, rejecting any suspicious requests.

It is a poweful tool, but it takes dedicated effort to understand how to use it effectively. It is definitely not an "install and forget, just works" kind of thing! It puts your hands on the throttle and flight controls, but you have to understand how to fly it! The only way to get out of the puzzling mode is to eat the book, write your own rules and watch the feedback channels closely.

And remember, it is only applicable to one part of a much larger picture.

Originally Posted by sneakyimp Your thoughts about changing the nature of your business are helpful. On my site, for instance, it's entirely safe to fail any request with the string 'concat' or %20union' or 'information_schema'. Indeed, I can even ban any IP that so much as bothers to attempt a request including such strings. Surely there are some general tactics like this in use?

Of course I know nothing of your own site, but SQL injections come in a bewildering variety, some of which do not look at all like SQL! If you look closer, I suspect that you will find these are only a subset of what is there.

In any event, good luck - I hope that your optimism prevails!

After reading into it a little bit it occurred to me that sql injection is similar to zero day exploit.
If you knew about the injection possibility, you would of probably fixed it. In the same way, it doesn't make a whole lot of sense of how to defend against sql injection attacks past "make sure code is securely written originally".

I did notice this if you use mariadb that has a firewall plugin you can use to define rules. It may be useful to minimize injection attacks, even if impossible to stop them entirely. Other mysql servers may have similar firewalls

Actually, in many cases "SQL injection vulnerability" is a fault of (early) PHP, which did not provide the ability to execute SQL queries that contained placeholders.

So I've been periodically scouring my access log for the past month or so. I feel like I might be winning. Server load is normal and obvious SQL injection hacks are getting shut down fairly effectively.

As a matter of curiosity, I'd like to know more about a really lengthy request in the access log recently. What is being attempted here? From my access log:

95.211.172.4 - - [06/Dec/2015:18:41:22 +0000] "POST /path/to/file.php?cat=999999.9'+%2f**%2fuNiOn%2f**%2faLl+%2f**%2fsElEcT+0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39,0x393133353134353632342e39,0x393133353134353632352e39,0x393133353134353632362e39,0x393133353134353632372e39,0x393133353134353632382e39,0x393133353134353632392e39,0x39313335313435363231302e39,0x39313335313435363231312e39,0x39313335313435363231322e39,0x39313335313435363231332e39,0x39313335313435363231342e39,0x39313335313435363231352e39,0x39313335313435363231362e39,0x39313335313435363231372e39,0x39313335313435363231382e39,0x39313335313435363231392e39,0x39313335313435363232302e39,0x39313335313435363232312e39,0x39313335313435363232322e39,0x39313335313435363232332e39,0x39313335313435363232342e39,0x39313335313435363232352e39,0x39313335313435363232362e39,0x39313335313435363232372e39,0x39313335313435363232382e39,0x39313335313435363232392e39,0x39313335313435363233302e39,0x39313335313435363233312e39,0x39313335313435363233322e39,0x39313335313435363233332e39,0x39313335313435363233342e39,0x39313335313435363233352e39,0x39313335313435363233362e39,0x39313335313435363233372e39,0x39313335313435363233382e39,0x39313335313435363233392e39,0x39313335313435363234302e39,0x39313335313435363234312e39,0x39313335313435363234322e39,0x39313335313435363234332e39,0x39313335313435363234342e39,0x39313335313435363234352e39,0x39313335313435363234362e39,0x39313335313435363234372e39,0x39313335313435363234382e39,0x39313335313435363234392e39,0x39313335313435363235302e39,0x39313335313435363235312e39,0x39313335313435363235322e39,0x39313335313435363235332e39,0x39313335313435363235342e39,0x39313335313435363235352e39,0x39313335313435363235362e39,0x39313335313435363235372e39,0x39313335313435363235382e39,0x39313335313435363235392e39,0x39313335313435363236302e39,0x39313335313435363236312e39,0x39313335313435363236322e39,0x39313335313435363236332e39,0x39313335313435363236342e39,0x39313335313435363236352e39,0x39313335313435363236362e39,0x39313335313435363236372e39,0x39313335313435363236382e39,0x39313335313435363236392e39,0x39313335313435363237302e39,0x39313335313435363237312e39,0x39313335313435363237322e39,0x39313335313435363237332e39,0x39313335313435363237342e39,0x39313335313435363237352e39,0x39313335313435363237362e39,0x39313335313435363237372e39,0x39313335313435363237382e39,0x39313335313435363237392e39,0x39313335313435363238302e39,0x39313335313435363238312e39,0x39313335313435363238322e39,0x39313335313435363238332e39,0x39313335313435363238342e39,0x39313335313435363238352e39,0x39313335313435363238362e39,0x39313335313435363238372e39,0x39313335313435363238382e39,0x39313335313435363238392e39,0x39313335313435363239302e39,0x39313335313435363239312e39,0x39313335313435363239322e39,0x39313335313435363239332e39,0x39313335313435363239342e39,0x39313335313435363239352e39,0x39313335313435363239362e39,0x39313335313435363239372e39+and+'0'='0 HTTP/1.1" 302 554 "http://example.com/path/to/file.php?cat=999999.9'+%2f**%2fuNiOn%2f**%2faLl+%2f**%2fsElEcT+0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39,0x393133353134353632342e39,0x393133353134353632352e39,0x393133353134353632362e39,0x393133353134353632372e39,0x393133353134353632382e39,0x393133353134353632392e39,0x39313335313435363231302e39,0x39313335313435363231312e39,0x39313335313435363231322e39,0x39313335313435363231332e39,0x39313335313435363231342e39,0x39313335313435363231352e39,0x39313335313435363231362e39,0x39313335313435363231372e39,0x39313335313435363231382e39,0x39313335313435363231392e39,0x39313335313435363232302e39,0x39313335313435363232312e39,0x39313335313435363232322e39,0x39313335313435363232332e39,0x39313335313435363232342e39,0x39313335313435363232352e39,0x39313335313435363232362e39,0x39313335313435363232372e39,0x39313335313435363232382e39,0x39313335313435363232392e39,0x39313335313435363233302e39,0x39313335313435363233312e39,0x39313335313435363233322e39,0x39313335313435363233332e39,0x39313335313435363233342e39,0x39313335313435363233352e39,0x39313335313435363233362e39,0x39313335313435363233372e39,0x39313335313435363233382e39,0x39313335313435363233392e39,0x39313335313435363234302e39,0x39313335313435363234312e39,0x39313335313435363234322e39,0x39313335313435363234332e39,0x39313335313435363234342e39,0x39313335313435363234352e39,0x39313335313435363234362e39,0x39313335313435363234372e39,0x39313335313435363234382e39,0x39313335313435363234392e39,0x39313335313435363235302e39,0x39313335313435363235312e39,0x39313335313435363235322e39,0x39313335313435363235332e39,0x39313335313435363235342e39,0x39313335313435363235352e39,0x39313335313435363235362e39,0x39313335313435363235372e39,0x39313335313435363235382e39,0x39313335313435363235392e39,0x39313335313435363236302e39,0x39313335313435363236312e39,0x39313335313435363236322e39,0x39313335313435363236332e39,0x39313335313435363236342e39,0x39313335313435363236352e39,0x39313335313435363236362e39,0x39313335313435363236372e39,0x39313335313435363236382e39,0x39313335313435363236392e39,0x39313335313435363237302e39,0x39313335313435363237312e39,0x39313335313435363237322e39,0x39313335313435363237332e39,0x39313335313435363237342e39,0x39313335313435363237352e39,0x39313335313435363237362e39,0x39313335313435363237372e39,0x39313335313435363237382e39,0x39313335313435363237392e39,0x39313335313435363238302e39,0x39313335313435363238312e39,0x39313335313435363238322e39,0x39313335313435363238332e39,0x39313335313435363238342e39,0x39313335313435363238352e39,0x39313335313435363238362e39,0x39313335313435363238372e39,0x39313335313435363238382e39,0x39313335313435363238392e39,0x39313335313435363239302e39,0x39313335313435363239312e39,0x39313335313435363239322e39,0x39313335313435363239332e39,0x39313335313435363239342e39,0x39313335313435363239352e39,0x39313335313435363239362e39,0x39313335313435363239372e39+and+'0'='0" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)"

The attack appends an extremely large hex values that will decode to a "null" value in the hopes of matching the correct number of columns in the table.

says this, found by https://duckduckgo.com/?q=%22union+a...+in+access.log

I can't answer the next question on the grounds I don't know the answer.

block the whole 255.255.0.0 subnet from those IP Addresses if you don't expect any visitors from those areas.

I know they might spoof the IP Address. On my case someone or some organization also tried to hack the FTP. We block the whole /16 subnet from known IPs that tried to hack.

Im a newb but found this interesting and wondering why use md5 instead of pbkdf2 with iterations? I think this makes it so that it keeps generating new hashes but at the cost of more computational power? Also does the overall security problem with everything lie in the UNIX system design? Like could one make a new os thats not based on unix and make it impossible to hack? Also if it helps PfSense has PFblocker which has country block.