Rewrite rules to detect hacker activity

by logging any attempt to access .mdb & .asa files

[jlander]

I have been using Qwerksoft IIsrewrite for over a year to perform a 301 redirect from non-www to www pages and I'd like to add a few rules to help detect hacker activity.

What I want to do is detect people who attempt to directly access any .mdb or .asa file. Their IP will be logged and I'll get an immediate email.

I've already tried this set of rules, but they have had no effect:

RewriteRule global\.asa /directory/trap.asp [L]
RewriteRule \.mdb$ /directory/trap.asp [L]

I'm now thinking of these, but to be honest, these rules are very confusing:

RewriteRule .*global\.asa.* /directory/globalasatrap.asp [L]
RewriteRule .*\.mdb.* /directory/mdbtrap.asp [L]

Should either of these work? Does anyone else use rewrite rules to log hacker attempts and how do you do it?

Any help would be greatly appreciated.

[webdoctor]

What I want to do is detect [snip] be logged and I'll get an immediate email.

What exactly does this do for you? Are you planning to manually follow up on each "hacking" attempt? Most "hacking" attempts will be bots
anyway. You're going to track down each infected PC, and send a full report to [e-mail]? Hmmm...

Wouldn't it be a better use of your time to do something useful? :-)

[jlander]

Actually, I had some guy try to hack my shopping cart last week. First he tried to download those two files and then tried to use sql injection on some of my scripts and login pages. He knew enough about the shopping cart software for me to take him serious.

So, according to you, I should do nothing? (lets assume that my shopping cart is fully updated and every other reasonable effort has been taken to protect it) This will use no bandwidth. Give me a good reason why NOT to do it.

[webdoctor]

You can spend all day trawling through log files.

If your software is fully patched, and your systems are hardened, what't the point in chasing "hackers"?

So, according to you, I should do nothing?

No, you should spend your time on something more productive. This could be site development, or it could be reading up on SQL injection vulnerabilities, or it could be making backups. But how does chasing one hacker help you?

[aspdaddy]

I agree, you should spend as much effort as possible reducing the threat space by hardening the whole system.

If you blocked requests for mdb and asa files over http there would be no need to log access to them.

Give me a good reason why NOT to do it

If a real attack happened the overhead of all the emails generated could cause a DOS attack on your mailserver - if your web server diddnt crash first.

[jlander]

I wish I could say that my site is hacker proof, but I can't. How about yours? I've taken all the precautions I can, and I'll keep up as things change.

But, by observing how this guy tried to hack my site I learned a few things. One thing, it was obvious he knew my shopping cart software very well. This is the kind of guy I need to know about.

Instead of telling me why this is a bad idea, why not try to help me figure it out?

[webdoctor]

I wish I could say that my site is hacker proof, but I can't. How about yours?

Ouch. From where I'm standing you're getting advice but it seems you aren't listening :-(

If you're serious about defending your servers, you need to focus on signal-to-noise. You need to configure your servers to IGNORE the minor stuff and only let you know about the major stuff. Is a request for global.asa (which will be denied) really something worth worrying about?

You could configure your firewall to email you every single time it drops a packet. This is another technique that will fail to help you catch hackers.

Try phoning the FBI and telling them you've caught a hacker red-handed .... requesting global.asa :-)

[Easy_Coder]

Yeah, your not going to be serving out the global.asa file.

Now you mdb file is another story. If your running front page extensions you can shove that db in the _private directory which is not browsable.

Something to consider is moving up to sql server. Access uses the oledb drivers and the oledb drivers require full trust. Out of the box .net has 5 trust levels.

- Full <- loose security
- High
- Medium <- default recommendation for shared servers
- Low
- Minimal <- tight security

You can potentially get into trouble running full trust especially if you're on a shared server.