Another Guy
Forum Replies Created
-
Forum: Networking WordPress
In reply to: MU multi domain site_url missing httpMika, look closely: there are no HTTP in front of those links.
For a forgiving bot or code checker, those things work. For more strict checkers, the links are all broken (no protocol given) or will end up combined with your base href to create a 404 (as it will point to your site, not the true destination).
Only happens on MU sites, does not happen on stand alone sites.
Forum: Themes and Templates
In reply to: [Sporty] remove unused CSS and JavaMy thought was only when the slider is disabled (not used) that it might be good NOT to include the script into the header. It makes the theme just that little bit faster.
Forum: Networking WordPress
In reply to: MU multi domain site_url missing httpTwo additional notes:
1 – this applies to both thirdlevel.rootdomain.com sites (ie, regular third level on the base domain of the MU site) and other domains http://www.domain.com which are on the MU sites, and
2 – other stand alone wordpress sites on the same server (dedicated, full control, no other users) do no have this issue, and
3 – the issue is the same no matter what theme is used, and appears related only when the wordpress install is set to be MU, and
4 – the problem occurs on an MU install with only the default site (ie, no user sites, just the MU default signup page site).
Forum: Requests and Feedback
In reply to: Is it time to remove Hello.php and Askimet from builds?Jan, your side note is correct, but…
Understand that if there is a file that is (a) commonly installed on EVERY wordpress install, and (b) rarely actually used by the sites in question then it’s a perfect file to overwrite when attempting to hack a system. If you get a plug in that allows writing to files outside of the upload directory, hello.php is a perfect place to land your hack – and most people will never check it until it’s too late. It’s in an executable directory, it’s a file that’s always there, and it’s a file that essentially nobody uses.
Basically, most people would scan your wordpress install and never run across hello.php – so they don’t generally check it for a hack. The result is many hacks are written there.
Almost everything else in wordpress has a use and is commonly used. This piece of legacy code is unused and not required for a normal install.
Askimet is more of a question of a commercial service that not everyone chooses to use. It’s a plug-in, nothing more. No other commercial plug in gets such preferential and repeated distribution, and it adds extra code to every download, and extra steps to remove it from every install that doesn’t use it. It also means that automatic updating is NOT an option, as this unwanted payload will be “updated” back onto the wordpress install each time.
Forum: Fixing WordPress
In reply to: wp-admin based DDOSOh and Marius, a web scraper doesn’t check version 5000 times an hour… 🙂
Forum: Fixing WordPress
In reply to: wp-admin based DDOSCloudflare does not detect it at all, they seem to be focused only on wp-login.php and xmlrpc style things. This is a pure DDoS attack nothing more and nothing less. I log:
ip / cloudflare ip url requested
to a text file, and logged 120MEG of entries in 8 hours – all trying wp-admin and nothing else.
They hit wp-admin, never follow the 302, never actually ask for wp-login.
My guess is that on a weaker server, this sort of thing would be an effective DDoS, on a site with unmodified wp-admin, they would be creating an insanely high load on the system, as each call to that page fires up database connections and checks to see if the user is logged in and such. it’s not heavy duty, but I am pretty sure it would be enough to TANGO DOWN a virtual. it’s also pretty clear (considering they move from one service to another as soon as I block one) that they have a lot of resources to play with. I think if they really tried, they could even take a much larger server down (if it wasn’t protected).
Forum: Fixing WordPress
In reply to: How can i speed up page load?! Windows PlatformThe issue appears to be the “wait” time, which is generally the time required for your server to start sending the page. Generally that time should be measured well under 1 second, and not 9-10 seconds (what I got). Once your page html is loaded, the images and stuff come quickly.
You may want to check things like server load and such. Potentially if this is shared hosting then it may be an issue of not having enough resources to do the job. It may also be a type of virtual hosting where your site is only loaded on demand, so when there aren’t many visitors the next visitor takes a long time for it to load.
The important term from pingdom is “Your website is slower than 88% of all tested websites”. When you look at the waterfall report, you can see all the images load pretty quickly after the initial page load. So there is something stopping the page load or taking too long to process before the initial page starts to load. Performance grade is not how fast it loads, but if it is technically correct (coding wise).
You may want to try similar tests with ALL plug ins and all “extras” turned off. Maybe even set up just a plain html page and see how fast the server itself can deliver a basic page.
Forum: Fixing WordPress
In reply to: How can i speed up page load?! Windows PlatformFirst off, I would say put cloudflare on pause. Before you even worry about performance issues like handling traffic with cloudflare, work on getting your site to answer basic page calls. When I try to access the site without WWW in front of the domain, it times out after 60 seconds. With the WWW, I get a “connection refused by IIS” page.
There in lies potentially some of your other problems. Where are you hosting? Actual server at a hosting company or on your home internet connection?
You can use tools like pingdom to see if your site is loading remotely and to see what is going slow. For the moment, the site is not accessible by the world.
Forum: Fixing WordPress
In reply to: wp-admin based DDOSMarius, the point is that they are NOT trying to brute force the site, they are making no actual attempt to log in, they are not POSTing anything, they are not even hitting wp-login.php – they are particularly using GET on /wp-admin/ and that’s it. They don’t follow the 302 redirect for not being logged in, even though it is generated (the response in apache log is a 302).
If it was a brute force attempt, they would be trying to log in. They are not. That leaves only DDoS as the goal, because nothing else makes sense.
As for Fail2Ban and others, they are not compatible with caching services (I use cloudflare). They would ban the cloudflare addresses and deny normal users the chance to access the site, which would be self-defeating.
Instead I have custom code in both /wp-admin/index.php and wp-login.php which gathers the origin IP (using the cloudflare conversion utility) and uses that to generate a log of failures. The more significant ones I ban with cloudflare. The rest get redirected to sites away from my server, so if they do in fact follow the 302, they don’t get anything indicating wordpress. The code is presented BEFORE any wordpress processing, so that I minimize server load as a result of these “visits”.
Forum: Themes and Templates
In reply to: [raindrops] Background is goneSimilar issue. It is as if the latest upgrade made the theme completely ignore all existing settings. A real problem on a multisite with many users who use it. I have had to downgrade back to try to find a version that works.
Forum: Plugins
In reply to: [WordPress MU Domain Mapping] Does not show all domains on admin pageYup, but in trying to consolidate existing http://www.domain.com sites, that would create a change in base URL which would get google upset.
Forum: Fixing WordPress
In reply to: Possible Security Vunerability: admin-bar.phpJan, I still think you miss the point. People knocking on a door suggests that they think the door may actually open. It is incredibly silly to knock on a door that generates a clear and obvious error message, as your door knocking stands out rather obviously. It’s an error that is written to the apache error.log file on the default settings of a standard LAMP install.
Everything you say is correct, except totally lacking on context. Yes, directly accessing the file generates the error. We know that already. The question is why is it being accessed? Is it a hacking attempt, or is it a bug in wordpress or certain themes that tries to access this file when users are not logged in?
The functionality of wordpress under normal circumstances is clear, and we all understand it (I looked at the code before I even bothered to post). Door knocking this particular file seems a bit off, and having found a cached hack on someone else’s site makes me wonder.
This piece of oddness got my attention, it’s the standard “c99” rootkit being used to specifically attack admin-bar:
[ Moderator note: Link to cached exploit code deleted. If your site is hacked please follow this advice as above. ]
Forum: Fixing WordPress
In reply to: Possible Security Vunerability: admin-bar.phpI understand your points Jan, but I think you are missing context here.
Why this file, and not any others? It’s not generally a file people would access (unless they are logged in) but potentially code added here would be executed by someone with admin level privileges. If they are just testing to see if wordpress exists, there are easier ways. Moreover, as emsi pointed out, these are not files that generally can be modified by a plug in, so it wouldn’t be some simple thing.
Moreover, I did find at least one cached example of this file turned into a rootkit install point. It basically Google caching the page, but there is no current version. So it suggests someone has found a way either to exploit that file directly or to use it as the “exploited file” for some other hack. Either way, it’s worth noting.
I have to ask though: Why is there such a strong resistance to accepting a report of potential hacking activity?
Forum: Fixing WordPress
In reply to: Possible Security Vunerability: admin-bar.php“I don’t see any issue”
In simple terms, if someone is knocking on a particular file on more than one installation, then you have to ask why. You make the assumption of an already hacked wordpress install, my feeling is this is much more an attempt to create a hole, not to profit from it.
I tend to go with Kyle T on this one, it looks like someone has figured out a potential hole, or that a different hack modifies this file to allow for a back door to create a recurring hack. It looks potentially like someone checking to see if an installation has been hacked or modified.
It’s also the first file in that directory, alphabetically.
Forum: Fixing WordPress
In reply to: Possible Security Vunerability: admin-bar.phpThat is all that ends up in the error log at this point, I don’t have full verbose logs on (it would be a machine killer to do that). But looking at it, it appears to be a direct call (as it isn’t attributed to another page), with no referring page.
Looking at the code, it appears to be trying to call a function that has not been loaded, as they are directly calling the admin-bar.php file.