Trying to Keep IPs Out of Virtual Stats Directory

Tried in .htaccess (unsuccessfully)

[EarlW]

I am trying to keep some IPs away from my stats. Denying them via my root .htaccess file keeps them out of everything in the main domain - but they get a 401 when they try to enter the stats area.

I have tried the following, and it doesn't cause any errors, but it doesn't work (tried with my own IP as a test):

<Files /home/USERNAME/logs/DOMAIN.com/http/html/*>
Order Allow,Deny
Deny from 150.70.
Deny from 216.104.15.
Allow from all
</Files>

Suggestions? It's on a hosted server, so I can't actually put anything in the stats directory.

[wilderness]

You should find that you'll be able to add a blank index.html file, which I did for image directories on shared hosting and directories that were above my root hierarchy.

[lucy24]

You don't really have a problem. If a request for stats results in a 401-- meaning that the robot doesn't know your password-- it's still not seeing the files. So you don't need to do anything else.

[EarlW]

Unfortunately, judging by the actions and files they try to access on the main domain, they are up to no good - and over time I am worried that they might be able to hack the password. With access to the stats, they also get access to user names and other info that I would rather keep private.

The other answer would be to keep changing my PW - which is a royal pain. If they get a 403 error, they never get a chance to try usernames/passwords. Not paranoid - just cleaning up after a hacker and trying to close potential security holes.

[wilderness]

"216.104.15." is Trend Micro and present no real threat.

[lucy24]

I don't think you can refer to <Files> that aren't further down the same physical path as your htaccess. Stats generally live in a completely different part of the server; they're just aliased from your userspace so you don't notice it.

If the blank index file doesn't work, you really might want to talk to your host. Yours is probably not the only site that this malign robot is sniffing around. They might be able to 503 it at the gate. I found a string of 503's in my logs once, and the host confirmed that it was a known menace so they blocked it globally. It's very gratifying to think of an evil robot getting hit with a 503 ;)

[EarlW]

@wilderness - Both IP ranges are *supposedly* Trend Micro: some from California and some from Japan. However, even if they are TM, I still don't want them snooping around where they aren't supposed to go, and their crawler is identified as "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" - which is also used by a whole slew of no-gooders.

It seems to me that if they were doing something reputable, they would include an email address and/or URL in their browser identification string.

[wilderness]

the 150.70. and the 216.104.15. ranges are NOT coming on their own, rather they are accompanied by the actual visitor IP and/or log entries. TR just adds to the log mess.

It is this actual visitor and their IP that you need to respond to.

[wilderness]

It seems to me that if they were doing something reputable, they would include an email address and/or URL in their browser identification string.

As much as webmasters would like AV tool and content filters to act the same as SE robots?
It's simply not going to happen, at least until there's an RTC Protocol for AV tools and content filters to abide by (fat chance in hell).

[wilderness]

Ends with 5.1)

is simple.

or even:

Ends with 5.1)
from the two TR ranges

[EarlW]

@wilderness

Ends with 5.1)

is simple.

or even:

Ends with 5.1)

Not sure what you meant there. I have no problem denying the IP ranges from my main domain using the <Files> directive. They get a 403 Unauthorized as they should.

My problem is producing the same results with the virtual directory that points to MYDOMAIN/stats.

[wilderness]

have you tried adding an htaccess to your logs/stats diretory?
are your attempting to do via HTTP or FTP?

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} 5\.1\)$
RewriteCond %{REMOTE_ADDR} ^150\.70\. [OR]
RewriteCond %{REMOTE_ADDR} ^216\.104\.15\.
RewriteRule .* - [F]

[EarlW]

have you tried adding an htaccess to your logs/stats diretory?

Everything is owned by root and does not have write permission. I can't upload anything to that area.

[EarlW]

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} 5\.1\)$
RewriteCond %{REMOTE_ADDR} ^150\.70\. [OR]
RewriteCond %{REMOTE_ADDR} ^216\.104\.15\.
RewriteRule .* - [F]

My .htaccess file works properly - just not for the virtual directory - which is actually located at:

/home/USERNAME/logs/DOMAIN.com/http/html/

... and that is a completely different path than the domain itself:

/home/USERNAME/DOMAIN.com/

An .htaccess file only works for the current directory and the directories beneath it.

[wilderness]

As I explained in my first response, some shared hosts will allow additions to above root hierarchy.

If you have access issues above root hierarchy, and do not have access, than the only alternative is to contact your host for a solution.

[EarlW]

Turns out I'm not the only person who is having problems with these Trend Micro accesses to administrative/hidden files, etc.

[webmasterworld.com ]

[projecthoneypot.org ]

[serverfault.com ]

[forumpostersunion.com ]

Frustrating!