2

We just started running our own web server a few months ago on Rackspace (they are great). I use NewRelic (also pretty cool) to monitor server usage and I am getting error alerts that appear to me to be injection attacks? Wondering if anyone can over insight or advice on how to thwart these efforts and get rid of the errors and pesky notifications.

We know for a fact these are not calls or request that our website would make on it's on. I have started going into the access logs and blocking the ip's making the request but they come back later on a different one.

Heres is a sample "MySQL Error":

http://www.ourdomain.com/item.php?fetchitem=46'+and+999999.9)+UnIoN+AlL+SeLeCt+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+and+'1'='1

That url should just be www(dot)ourdomain(dot)com/item.php?fetchitem=46

Another:

http://www.ourdomain.com/item.php?fetchitem=39'+and(%2f**%2fsElEcT+1+%2f**%2ffRoM(%2f**%2fsElEcT+count(*),%2f**%2fcOnCaT((%2f**%2fsElEcT(%2f**%2fsElEcT(%2f**%2fsElEcT+%2f**%2fcOnCaT(char(33,126,33),count(t.%2f**%2ftAbLe_nAmE),char(33,126,33))+%2f**%2ffRoM+information_schema.%2f**%2fsChEmAtA+as+d+join+information_schema.%2f**%2ftAbLeS+as+t+on+t.%2f**%2ftAbLe_sChEmA+=+d.%2f**%2fsChEmA_NaMe+join+information_schema.%2f**%2fcOlUmNs+as+c+on+c.%2f**%2ftAbLe_sChEmA+=+d.%2f**%2fsChEmA_NaMe+and+c.%2f**%2ftAbLe_nAmE+=+t.%2f**%2ftAbLe_nAmE+%2f**%2fwHeRe+not+c.%2f**%2ftAbLe_sChEmA+in(0x696e666f726d6174696f6e5f736368656d61,0x6d7973716c)+and+d.%2f**%2fsChEmA_NaMe+=+%2f**%2fdAtAbAsE()+and+c.%2f**%2fcOlUmN_NaMe+like+0x25656d61696c6164647265737325))+%2f**%2ffRoM+information_schema.%2f**%2ftAbLeS+%2f**%2flImIt+0,1),floor(rand(0)*2))x+%2f**%2ffRoM+information_schema.%2f**%2ftAbLeS+%2f**%2fgRoUp%2f**%2fbY+x)a)+and+'1'='1

It has been suggested to put a limit on port 80 in the iptables but I am afraid of blocking potential real users.

All thoughts and advice in appreciated! Thanks!

3 Answers 3

0

Yes, that's it.

I recommend to detect and block these attacks with ModSecurity.

Sample rules for SQL injection detection from ModSecurity CRS (Core rule set):

https://raw.github.com/SpiderLabs/owasp-modsecurity-crs/master/base_rules/modsecurity_crs_41_sql_injection_attacks.conf

You can clearly see rules containing keywords "select", "union", "all" etc

3
  • Awesome, thanks for the quick responses. We installed ModSecurity but I will take a look at the configuration. Thanks!
    – Nick8675
    Sep 24, 2013 at 21:45
  • You're welcome... Be careful out there: default ruleset is very strict, needs configuration and tuning according to your needs. Without tuning it may block everything.
    – GioMac
    Sep 24, 2013 at 21:47
  • p.s. welcome to serverfault
    – GioMac
    Sep 24, 2013 at 21:47
4

Yes, that's a classic SQL injection attack. Your only real long term defence is to secure the application, though you can ban IPs as required and there are various tools out there which will attempt to automate this.

Ultimately, unless it becomes a DOS attack, they should be relatively harmless if your site is injection proof. That side of things is more StackOverflow, though.

0

classical sqli - scanning; live with it or block it (but not manually :)

if you want to protect from sql-injection-attemps and need a lightweight solution, use nginx + naxsi , if you are able to install and run a reverse-proxy infront of your apache (mod_security can slow down your site quite a bit)

reasons to use naxsi

  • is much more lightweight than mod_security
  • the core-ruleset is stable in sqli-protection
  • writing and maintaining rules is not such a PITA like with mod_security
  • can be extended to block a lot of scanners, skiddos and unwanted access (extended ruleset)
  • learning mode -> run it on a protected instance and generate whitelist-rules for your live-setup
  • you can has the full nginx-power and use the proxy_cache and static - features when on the same host

when NOT to use naxsi:

  • if filtering outgoing traffic is needed (i'd prefer snort here)
  • if multi-stage ingoing filters are needed (i'd prefer snort here)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .