MrGamma

I will just add that I’m watching one site that redirects, via malware, without the website owners knowledge, and none of the top malware scanners, including the googlebot crawler detect it. It’s been like that for weeks/months, and the redirect behavior is not only selective, but over time it’s been changing to where it redirects too, implying the website has unwanted administrators, so to speak.

Hope that helps anyone who discovers their website is redirecting. It is not really considered malware, because there is no distribution of malware I guess, but rather just odd behavior which damages the website.

What you are doing is adding an apache rule.

So effectively what you have done is blocked anything going through apache, which accepts request over port 80, to that specific file only. Or if you are using different web server software, whatever it’s called.

This won’t prevent anything which accesses the filesystem through any one of the other countless files as a part of the wordpress distribution, or 3rd party vendors from causing issues. So, any malware attempting to access your site through any other file, once they gain access to filesystem, they will have effectively circumvented your apache rule.

The only time you would want to block access to a file over port 80 (which is the port which webservers such as apache use), is if the file accepts $_POST, $_GET or other variables from the web, making it a SQL/Shell/whatever attack vector, or in the case it handles $_FILE variables, a file system attack vector. The script itself would have to be not coded well, either not sanitizing the variables, or it otherwise would have to be a script which is resource intensive and when it is run, bogs down the server, which would mean it’s a possible denial of service attack vector.

Did this help at all?

With wordpress specifically, if you are under attack repetitively, it might be a wise move to block access to the entire administration section, and allow only specific people in, until the rest of the security can be figured out.

On poorly configured shared servers, the larger issue might be with file permissions as alluded to in above posts. Should anyone breach any of your neighbors, if your files grant permissions for other groups on the server to access and write to your files, then that would be another way someone could circumvent the apache rule. Typically this should not really be a possibility, but people will share space in any number of strange ways. At the very least, if you are on a shared server, and are not confident that the host it set up right, make sure your file permissions do not allow anyone to write to the file except for the owner, which should be you.

Granting other groups the ability to read your files, is okay. Granting other groups the ability to write to your files, that’s an issue. Your FTP program should allow you to set Read, Write, permissions.

What has prompted you to block access to that file? Is it a file which is being tampered with or written to without your permissions?

Q1: Will using the .htaccess command above stop my script from accessing the wp-config during activation?

Q2: Is there a better way to get the script to use wp-config info?

If you trust the files inside your wordpress distribution, then they absolutely by design must be able to read the files which are also a part of the same distribution.

You might be interested in loading the WP-Config into global variable space using an Include_once command, as opposed to perhaps a file_get_contents command.

In any event, there should be no real need to constantly generate code from “static” variables, which if I am correct, that’s what the wp-config file should be. “Static”, or non-changing variables, or hardcoded ones.

I don’t really use WP, but in english, there is something wrong with your rewrite rules. This line here is the problem.

if ( preg_match("#^$match#", $request_match, $matches) ||
					preg_match("#^$match#", urldecode($request_match), $matches) ) {

The variable $match has something improper in it.

You could probably remove the variable $match but it would probably break something.

Perhaps there is an area inside wordpress where you can type in rewrite rules? if so… that is where the problem most likely can be fixed without having to hack it.

Hope that helps.

preg_match() is a core function of php.

When it throws compilation errors, it basically means that the first parameter that is passed to the function is written incorrectly.

preg_match(“FIRST PARAMETER”,”SECOND PARAMETER”);

Can you open the file in a text editor like Textwrangler or UltraEdit32 and look at the code and fix?

http://php.net/manual/en/function.preg-match.php

I would imagine a plug-in would work for some instances, depending on what you wanted to do.

Technically it’s branching if you start coding in core files which break compatibility with the source, and given the strong following that wordpress currently has, it might be counter productive to branch to another distribution which would eventually require full time development, or would eventually die out.

So Plug-In is probably best for functionality requirements. Looking around, I have seen people make plug-ins to modify the apperance of the admin areas as well.

I just brought it up, because I do remember doing some work, and the end result was that they would not be able to preserve those development changes without redoing them. But that was way back in version 2 or so…

Sometimes it can be expendable… sometimes you don’t want it to be expendable, so… hope that helps.

You are also using Plesk, and on GoDaddy?

Normally the answer is to move to another host isn’t it?

Maybe you are just on an “Unlimited” plan which could be different from a resources “GUARANTEED” plan… so maybe your CPU is being throttled?

http://codex.ww.wp.xz.cn/Using_Permalinks

# Microsoft IIS 7+ web server with the URL Rewrite 1.1+ module and PHP 5 running as FastCGI
# Microsoft IIS 6+ using ASAPI_Rewrite

You are on 7… so… whatever happened between 6 and 7 is your problem most likely…

Again, Hope that helps, but hope it doesn’t send you down the wrong path either…

But, it is probably a server issue, rather than a wordpress issue…

They hot-link from youtube.

When it is removed from youtube it is removed from the other persons website as well. The shell of the video might remain but the video itself is gone.