You can remove them in your theme’s functions.php with this
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
// it's best to remove the version number too
remove_action('wp_head', 'wp_generator');
this also removes the version number of your WordPress installation.
[edit] After reading your question again and seeing in what forum you posted I would like this too. Maybe have an option in the wp-admin to include them if you need them.
Thanks!
I actually think that these are OFF by default, but right now on shared hosts like dreamhost we are under constant attack by trolls searching for ‘ways in’ and weaknesses in the wordpress structure, I wonder in general whether wordpress could get a group going to reduce their exposure to being hacked. My issues are about having less structural information information lying around- why create wlwmanifest.xml at all? unless in the installation section someone wants it; Why have xmlrpc.php around to run? If you run it it also gives up info about your structure.
Can’t these be in the initial configuration and if they are not being actively used they are removed in an update?
Thanks,
-Bill Kelly
The readme.txt also gives you info, as do many other places. You’re suggesting something that, in the long run, has no significant benefit.
xmlrpc.php is there, but unused until you turn on the setting (which I thought defaulted to off… it’s off on my sites until I flick it on).
I must have been using a theme with it on, when I ran it as a standalone php program it returned some interesting data about wp-admin. I’ve since used .htaccess to send people looking for it to hell, so without a lot of work I can’t see what the defaults on each of my websites are.
Since thursday afternoon on dream host i’ve had 67 requests for people looking for xmlrpc. At a minimum, it’s part of a probe, /xmlrpc.php?rsd will tell you that this is a wordpress site.
I guess my issue, from seeing dream hosts discussion list, and from my own investigations, wordpress is being probed like NEVER before. Any extra php program on any site becomes a target even if it’s not being used at the time by the user himself. The people who have 100 themes are probably 100 times likelier to be hacked.
I’ve decided that if your doing something on my website that’s unsupported by what a user can do then your ‘bad’. I’ve had 1,254 ‘bad’ commands in 5 days. Many of them directed agains wordpress itself.
My request is to have wordpress developers and community think about installing options at the beginning and providing lots of code before the install but more to the point REMOVING files after the install that were not part of the wordpress process, and that are walking time bombs. Once you decide a theme, can we delete up all the unused themes in one command? Same for any other config options like wlwmanifest.xml and xmlrpc.php, can we not have ANY .php files lying around that are not being actively used?
At a minimum, it’s part of a probe, /xmlrpc.php?rsd will tell you that this is a wordpress site.
Well. Yes. But they also probe for timthumb, which I don’t use, and I get hit for that all the time.
A lot of thought is put into the balance between removing features that don’t benefit ‘anyone’ and ones that are helpful, and WP strives for decisions over options, so … yes. They are aware and it’s kept in mind. But DEFAULT files, ie ones in core, aren’t likely to be removed. xmlrpc.php shows harmless info if your site is secure (i.e. not permissions 777).
As for themes and a mass delete, It’s on the table 🙂
Deleting all but the installed theme should be considered. If you think about the exposure Dreamhost just went through BECAUSE they installed many many themes, some of which had un-updated timthumb php files. What I’m afraid isn’t being understood by WP developers and users is ANY .php file that is sitting in your website is a hacking object whether or not it’s being used! Inherently the more unused .php files on your website, the more risk that there is a hack. So if I have 100 unused themes sitting on my website, that’s a lot of hacking opportunities! Given the apparent abundance of clever programmers who are now hunting for word-press vulnerabilities, most can have the code in hand! It’s really a no brainer to find a weakness when your looking at the source code, it seems that the viability of wordpress is now in question.
From my perspective the combination of cheap hosting and incredible easy of installation has made wordpress the CMS of choice; the dark downside is people with ZERO web experience are installing and using wordpress by the bushel load. Look on the discussion lists for go daddy or dream host and you see people struggling with a hacked site and 1) no ftp tool 2) no telnet or SSH tool 3) no knowledge of unix and no idea what they are doing.
I’d like wordpress to step up to 1) providing WAY less unasked for data (Given the number of HEAD requests lately there must be good stuff by default in the wordpress header) 2) use permissions or file deletion more aggressively to eliminate risk. How about uninstalled themes are owner read only until they are enabled? 3) start providing tools to more effectively clean up a hack.
Deleting all but the installed theme should be considered.
That wouldn’t work for Multisite users. 🙂 I have 4 themes installed for 8 sites, and I’m a small network.
You’re blowing things out of proportion just a bit. At it’s heart, any executable file on a server is dangerous. Period. But the data I can get from a head check on a site only tells me what attacks to try. If I see ‘wordpress’ I know do X, and ‘joomla’ Y and so on. That won’t change unless you’re talking about 100% obfuscation of source, and WordPress won’t do that.
As for security, that’s the host’s bailiwick. We can’t conceivably force people not to be stupid. Permissions is talked about, and the default install, unless you change them, is pretty safe.
Cleaning up a hack… Find me a normal, standard, 100% repeatable hack that has an easy way to clean it up, first. They’re like the common cold.
