I'm getting this daiily in my log and its confusing - because I'm on a Linux box.

scripts/..\\../winnt/system32/cmd.exe not found.

I'm also seeing a log error to a call in my /cgi - one of the stat files

I've never seen these errors before upgrading to 4.6

is someone "Anonymous" ... trying to hack me ... and because of some new improvement to 4.6 --- I'm being advised?

thanks

Comments

torne’s picture

The accesses to cmd.exe are just someone blindly trying to use a Windows exploit against your web server. If mod_rewrite is enabled (to support clean URLs) then all accesses that don't match anything will end up in Drupal, where it will helpfully display the standard Drupal 'page not found' page and log it. It's not new in 4.6, this always happens if mod_rewrite is active. If they show up in the Drupal log as page not found errors, they are by definition not getting anywhere trying, so it's nothing to worry about. There are several ways to filter these out of the logs if you find them annoying: see a previous post on this topic such as this one.

green monkey’s picture

Thank you,

they really aren't a bother in the log. I just wanted to understand them and now I do - thanks again

kbahey’s picture

This is most probably script kiddies or other machines that have been infected by worms trying to look for exploits.

Since you are running Linux, you can ignore the first one.

Did not understand what you mean by cgi stat files.
--
Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

green monkey’s picture

its a new site, so I'm flushing log entries everyday and the /cgi ones came last night -- so I don't have the log entry

I think it was a call to file in /cgi called wsstat ... or something close to that
not sure of the name , but it was to the /cgi-bin

torne’s picture

If it's not the name of a CGI script you have (which it's not, or else drupal wouldn't be handling it) then it's just more script kiddies blindly using exploits. It's quicker for them to just try the exploit and move on to another server if it fails than to check if you actually HAVE whatever piece of software it applies to, if it's the exploitable version, if you have the right OS for it to work, the right DB server..etc - only people intending to break into a specific host care about any of that stuff. The request sent to determine all that info can just as easily contain the exploit, and if it doesn't work, they don't care why not, they just go prod some other server.

sepeck’s picture

It's more likely to be one of the nimda virus variants/decendants than script kiddies. A properly setup IIS system isn't vulnerable to it either.

As I mentioned it, resources for securing IIS.
http://www.microsoft.com/technet/security/prodtech/IIS.mspx

-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide