is drupal vulnerable under some aspect ?
Or is it in general a secure CMS ?
What about the cron.php. Can it be overloaded ?
thanks
Drupal is relatively secure in general, but vulnerabilities pop up regularly as with any web application now and then. Make sure to monitor the Security advisories and react to any flaws reported there for core and contributed modules you use (you can get these via mail by subscribing to the newsletter on your Drupal.org account pages).
As for cron.php, a default Drupal install does not protect it from being called by anyone directly, thus exposing some DOS risk, but you can shield it pretty easily by limiting access to it via .htaccess rules - see http://drupal.org/node/41049 for some discussion on it (Don't sweat this - cron.php will not expose any data by itself).
Drupal is in general quite safe. Just be sure to check for updates and install them. (You'll get a notice if there's a new update if you log in as an admin to your site.) cron.php is responsible for site maintenance and update checking. Have a look at this thread from the drupal forums http://drupal.org/node/41049 where a similar question was posed.
Drupal is used everywhere and is proven and professional. Anyone can introduce security vulnerabilities if they try hard enough, so make sure you don't do anything stupid.
If a security flaw was exposed in Drupal, the community would have picked it up within hours and probably issue an update within the same day or two. You really have nothing to worry about, and if hackers did want to target a Drupal site, they'd probably choose a higher-profile one.
Drupal has a good security team and community and many new security features are appearing in the next release (7) - but in theory having anonymous users able to call cron.php (in ver 6) is a security risk and presents a minor DDOS risk. But it is easily protected in the .htaccess (as mentioned by Henrik Opel ) - I use that method too with adaptations for other sensitive files . The good news is that it is being protected by a hash in Drupal 7 see Slide 26 in this presentation (http://code4lib.org/files/drupal7-c4l10.pdf)
Related
Running in circles trying to leverage Pantheon's CDN/Varnish edge caching.
Have a Wordpress site uses the WP Simple Pay Lite plugin to process Stripe transactions on one page. That plugin creates a session cookie to allow correct handling of payment success/failure.
That session cookie prevents caching via Varnish. As I understand it, a lot of people run into this with WooCommerce as well, but I'm having a hard time finding a clear solution and Pantheon support is giving me the "this is beyond our support", which is fair, but it seems this would be a very common issue.
Simple Pay's docs specifically mention Pantheon as an exception and refer to using Pantheon's Native Session plugin (which we are), which as I understand it, offloads sessions to the database. The next step isn't really clear to me though as that alone doesn't eliminate the session, only switches how it's handled.
So does anyone have a solid workaround for this site-wide cookie whether through Simple Pay Lite, WooCommerce or otherwise?
If I can't get a better solution working, I suppose I could just move the payment piece to a subdomain, but would love a cleaner solution.
I've done a little looking at selectively loading the plugin only for the one page that uses they payment form, but a lot of the solutions there are pretty generic and I'm not sure my level of expertise is going to get me over the hump.
Bear with me... kind of flailing here.
I have made the case for using WordPress as a CMS for an important project.
IT has challenged me to build out this base WP installation alongside the local (WAMP) served intranet and lock it down the best I can. They will then attack the installation with enterprise level penetration testing software.
I am only privy to a minimum amount of details however some security tools I am up against have been mentioned and will be used in conjunction with enterprise level software:
Kali.org
Tools from darknet.org.uk
Watabo
What I've done:
Wiped all basic WP out-of-the-box data such as Administrator username, changed login page URL, removed ajax calls, leveraged all options within iThemes Security plugin (which is pretty impressive) and a few of my own.
My question is for advanced advice on securing WordPress running 2015 theme and its PHP framework and Database. Proper htaccess configuration and possible pitfalls. Advice on any advanced methods of securing a website where it's likely to fail a pen test.
It's not easy to make a website completely invulnerable, especially if you have chosen Wordpress.
You should update your Wordpress website constantly. It means that you have to follow all the updates and install them immediately. Sometimes it's not easy to do, if everything is working as it should, and the database is not small. Wordpress is the most popular open source CMS in the world and many people want to crack it, write crawlers which are searching vulnerabilities online etc.
Simple steps to increase the security of any website:
Close a port if you don't use it or install firewall, tcpwrapped etc.
Don't use FTP, ever. Use SSH instead.
Don't make rights 777 on the whole folder. Make it 555 and when you need to upload some image or something else change the rights to 777 or 755 (if you do it by ssh). After doing your job change rights back to 555. Nobody couldn't upload payload or other malicious code to your website through the front end if it's not allowed for writing.
Check your website for sql injection vulnerability.
Don't use simple passwords. You could even change your passwords every month.
Don't duplicate passwords.
Regularly update your software.
For back end security you could use some IDS, for example Snort - https://www.snort.org/, but it's not easy to configure properly. Furthermore you should understand how a network works, tcp/ip, attack types and so much more.
Use OpenBSD as your server operating system if you do not understand the information security well. It was created with an emphasis on increased security.
Take some network scanner (for example nmap) and test your server for vulnerabilities.
Finally: I wouldn't recommend to use Wordpress for the reliable security :) and to say more I need to take a look at the website.
My apologies in advance if I am posting it in the wrong forum.
I have a WordPress site. Every couple of days, a new user is added as an "Administrator" as shown below
I have changed my password many times using complex passwords but to no use. I even searched on Google and have read links like this one.
I have also unchecked the option "Anyone can register"
However, I am unable to stop them from registering.
Fortunately, no malicious activity has been noticed (Ex: Deletions/Unwanted posts etc)
Please advise me on what I can do to stop these?
You clearly have a more serious compromise, like an uploaded malicious script or an unpatched vulnerability. You need to rebuild your site from scratch (clean install of the current versions of WP and any plugins and themes, using a known-good database export) ASAP before something really bad happens.
Unfortunately, it's impossible to say what happened without digging through your server. My guess is that somebody exploited a vulnerability and uploaded a script. It could be anything - an hole in the WP core, a plugin, or a theme; a malicious plugin or theme; a stolen password; a breach of another site on the same server; or a number of other things.
Regardless of what happened, the only safe fix is to rebuild the site. If you have data backups, you can achieve this in a few hours.
I strongly recommend installing the security plugin WordFence to help prevent similar problems in the future. (I have no affiliation with WordFence, but use it on a number of sites.)
Finally, you might want to read this discussion on security.stackexchange.com. The consensus in this situation is "nuke it from orbit." Good luck!
Someone is making a SQL injection in your site.
If you want to prevent this in future, you should do some things.
Rebuild your website from scratch.
Install some of the security plugins, like Bulletproof Security, Wordfence, iThemes Security. I suggest you to buy the license of Bulletproof, or use the free version + one of the others. And be careful for the equal settings.
The most common attack are with SQL Injection XSS, Plugin exploits and of course brute-forcing the admin pass. You should upgrade every plugin and Wordpress every time when you see a new version.
Use less plugins. They are one of the main reason for hacked websites. If you use Linux, Ican tell you how to scan your website for vulnerabilities. Or just tell me the url, and I will tell you the results.
Also change your /wp-admin path, there are a lot of bots who search the web and make bruteforce attacks.
Also is important to use different admin username from admin or Admin. And use strong passwords. It's a good practice when you make a new Wordpress installation, to do two more users. The first will be an Author and will post everything in the site, the second you should make with Administration role. After that delete the first admin user and start the new one.
Hackers knows that almost every time the user with id:1 is the admin, so they can try to access again. So in this case your admin will be with id:3, and again don't use username like admin and etc.
Best regards and wish you luck.
Kasmetski
Check index.php, wp-admin/index.php to see if they have been modified. Usually the following line of code is added to the top of the index.php file. A code starting with 'required' is usually added.
The file being ‘required’/’included’ here contains malicious code which is executed along with each run of WordPress. Such code can generate fake pharma pages, Japanese SEO spam pages and other malware infections.
Delete the #require code from the file after comparing it with the contents of the core WP files from it’s GitHub repository.
Check if there are any new files in the root of the server or /wp-admin folder that were not created by you. Some of the files that you may find are:
Marvins.php
db_.php
8c18ee
83965
admin.php
buddy.zip
dm.php
If you find any of the above suspicious files, take a backup and delete them.
Source: https://www.getastra.com/blog/911/fix-wordpress-admin-dashboard-wp-admin-hack/
I am building a web consisting of MediaWiki and phpBB as its subcomponents. Also WordPress may be added in future. My current problem is to choose a single unified authentication method (not to force users to have a special MediaWiki account, a special phpBB account, etc.).
Which approach would you recommend me? The basic limitation is that it is a simple LAMP server (no LDAP database). Possibilities I know about:
Use a decentralized protocol such as OpenID, OAuth 2.0, etc. I would prefer this approach. However, OpenID is not supported by Google any more so OAuth 2.0 would be probably more appropriate.
Use DB of users from phpBB and install some plugin to other subcomponents (MediaWiki extension for phpBB auth.)
Use DB of users from MediaWiki and install some plugin to phpBB.
Use some specialized web application for user credentials management and install plugins both to MediaWiki and phpBB.
I think the main point you already understand: You need one of your new platforms to be the central user store. The problem you know have to find out:
What platform has the plugins to interact with each other? It's possible, that you find plugins, that only works "in one direction", and for mediawiki itself you will find a log of outdated extensions, that maybe won't work anymore with the latest mediawiki versions and updates.
The other point is, that you should think about WordPress now, too. After you selected one central user store you mostly can't change it with a lot of work, so I would check for an integration of WordPress now, too.
Looking at that and a short search i wouldn't prefer MediaWiki to be the central user storage, and i'm not sure, if phpBB is the best solution, too :/
I think one of the best would be to use LDAP, extensions and plugins seems to be supported and working for the latest versions of each software. You yould have a central user store, which could be easily integrated in other applications, too. What is the reason you can't use it, an LAMP stack could handle this, too?
The second solution i would consider to choose is to use Google's user store and access it vi OAuth 2.0. MediaWiki, phpBB and WordPress supports this with plugins and/or extensions.
At the end of the day a login is a login is a login. All the custom fields specific to individual applications can be properly bridged with plug-ins. Make the app that will require the most babysitting your main database and thus login system. In many cases it's the forum, but that really varies by site.
I would caution that many new forum admins eventually want to upgrade from phpBB to something that's more powerful and modern. I was one of those admins. Yes, phpBB is as good as an open-source forum gets, but it just doesn't compete with the commercial forum apps. So keep that in mind if you make phpBB your main database.
Well, with entirely file-based CMS you can easily put the whole directory into version control system to record any changes to the site. The synchronization with the server would be also trivial because it would only involve uploading the files via ftp.
With these benefits in mind, I am a little puzzled about the popularity of databases as the only storage mode, even when the CMS in question is meant to be used by amateurs for small websites.
How does your versioning and synchronization workflow looks like?
What kind of simplified versioning/synchronization workflow would you suggest for a casual, non-tech, WordPress user, to give them the benefit of working locally and encouraging them to have a backup of their site?
Most CMS systems nowadays tend to have some or other backup solution in place to help you. Since Wordpress is a CMS for the masses and also caters for the non-tech population, you're sure to find a plugin that can help you with this. I know it's built-in backup solution just backups posts etc. to XML, but even this does a pretty decent job of restoring over a clean wordpress installation and working fine.
But I found this plugin (which works for Wordpress and Joomla) by asking Google, which most probably is the answer to your question: XCloner
Also in terms of workflow, specifically for Wordpress, don't give the user Admin privileges, but editor or contributor or something, so they can still edit content, etc. but not make changes that could mess up the CMS itself. And maybe this XCloner plugin can do some kind of recurring backup or something. Otherwise, I suggest you move to a LAMP stack hosting environment where you can at least have cron jobs setup to backup your databse and files regularly. Most hosing companies do this in any case at no cost.
Wordpress also keeps revisions of all posts and pages, so if a user doesn't like an update they've made, the full revision history is available. Be sure to check screen options at the top to see that Revisions is checked, if you aren't seeing this option. Kind of a nice built-in.
Can also (depending on host) have scheduled database/file backups through cPanel, in addition to scheduled database backup plugins through WordPress. Some will save remotely or even email the database out.