I'm currently running and installation of Joomla v3.3.3 on a server. It says that there's an update available for v3.5.1. I'd like to know if it's a good idea to update to this version. There are several additional modules used by the website and I'm afraid that the whole frontend will be broken after updating. Are there any security issues? Or am I fine if I'm staying on this version?
its always best to stay up to date as the updates frequently address various security concerns. Its not difficult for a potential attacker to know when a website is built on the various popular frameworks. I can spot a joomla or wordpress site every time.
It is also best practice to backup your website before performing updates.
Myself, I like to create a copy of the entire site and database in another directory or sub domain and test update on that. if all seems good i then create a backup of the live site before installing the update as updates can fail for random reasons.
joomla updating guide
It's a best practice in web development to stay up to date, with updates we have improvements in security, functionality, performance or design.
Some extensions are not compatible with the latest joomla! versions, so you also need check the news for each extension in their websites, also you can check the updates in:
Extensions > Manage > Update > Find Updates Button
If for some reason you have an extension that should not be updated and you see the notification in the back-end, you can disable it in:
Extensions > Manage > Update > Update Sites
Note: Before any change in your site, create a backup. One popular extension to automate your backup process is Akeeba Backup.
Related
I have a hosted page on Microsoft Azure Web Sites (Shared) and have verified that PHP is enabled and working but I am not able to call PHP in an .html document. Is there any way to enable this?
Searched high and low on this one, sorry if it is a duplicate.
This drove me nuts too, documentation in so many areas is poor. I had the same problem last week.
Here is the fix:
On the management console of the site, under configure, scroll to Handler Mappings.
In handler mappings, in the first box, type *.html
In the second box type D:\Program Files (x86)\PHP\v5.4\php-cgi.exe
Save, then restart the instance. It will now process PHP inside HTML files.
One small thing, which I didn't realise till after as well. I instantly assumed, 5.5 is the latest and greatest, so why wouldn't I just update to 5.5 and use that engine. You can, and changing the folder structure to read 5.5 works, however the 5.5 build on Azure doesn't have PDO for SQL Server which makes connecting to a native SQL database a nightmare. So 5.4 is the best build IMO until they include that as well.
Hope this helps.
EDIT: Not sure if this is applicable to shared, I am using a small instance, but logic should be the same I would have thought.
one of my clients complained that she cannot log into her Joomla installation anymore. So I checked the database and saw, that all the user names and passwords (md5 value, I used a rainbowtable to check) are set to "harun". Did anyone ever hear about that? Google doesn't...
Also: what do I need to to now (besides changing passwords)? I'm not that "big" in web-dev and never faced such a problem.
Any help appreciated.
Clearly you have a great deal of cleanup to do....I hope you have a database backup! We had the same kind of thing happen to us a couple of years back, and installed RSFirewall. While attacks still occasionally occur, this wonderful extension has cut the damage by 99% for us. Good luck!
You need to clean up the website and find and fix the point of entry.
1. clean up the website
You could restore from a backup but it can be difficult to determine the exact date the website was compromised.
You could spend days trying to find and fix compromised files yourself.
The best option is probably to use a commercial service like www.myjoomla.com or sucuri.net which cost very little and are usually effective at finding and fixing infected websites. In particular, the myJoomla security tool can identify core Joomla files that have been changed and replace the changed ones with the original files.
2. find and fix the point of entry
Update Joomla to the latest version in the series.
Update all third party extensions to the latest versions.
Update Joomla, FTP/cPanel and Database passwords.
Check the Vulnerable Extensions List at vel.joomla.org to ensure you are not using any vulnerable extensions.
Also see the Official Security Checklist at http://docs.joomla.org/Security_Checklist and https://stackoverflow.com/a/19139389/1983389 and https://joomla.stackexchange.com/a/180/120 for tips on keeping your Joomla website secure.
For long time solution its an suggestion please change your server or host. As you said MD5 are set as "harun" as per my opinion its change by some kid's hacker by sim-link or some local jommala vul. attack . If its sim-link attack then you need to worried about host else if its jommla vul. then simply change the version or update it and make cleanup on your publichtml/ or soo on .And make sure there is no other php script or perl / python script not found on your Host.
Are there any special security measures to take when deploying a Drupal site to a production server?
For instance: I can imaging that we need to remove install.php from the root directory. Are there any more actions?
Or is there maybe a module available which checks the site for "world readiness"
The status report on http://your-site/admin/reports/status will tell you if anything is not quite right.
Under the performance admin page you can turn on various caching settings, but test your site with them turned on before deploying.
There is a book by greggles for securing drupal, which may be worth a look.
Ideally you've tested your code for insecurities before deploying, but configuration can often be missed. There's a mode for analyzing your Drupal site for misconfiguration that would lead to vulnerabilities http://drupal.org/project/security_review
Security Review makes the following checks:
Safe permissions on system files
PHP in comments or nodes
Whether error reporting is on
Unsafe input formats
If private files is on and if the files directory is outside webroot
Allowed upload extensions
Admin permissions granted to untrusted users
In addition to other suggestions, remove update.php also.
I'd also (re)move /scripts from the webroot
It's a minor thing, but you could remove the text files in the root of the distribution which leak the version number. Such as CHANGELOG.txt etc.
I don't remember how safely cron.php protects itself from flood-calling. You may want to look into whether it is worth limiting that to local-only or command-line-only access.
Ensure that .inc files are processed by PHP.
all this answers make you stop thinking after your install is done - but software has a history and after installing drupal you have one more baby to watch - in drupal´s case watch VERY closely! This means you MUST subscribe to the drupal security mailing list and read all mails that are coming form there - be prepared to get many emails. It is good, that the drupal team is providing these informations fast, but it is sad that there are really too many of these mails, what might be related to drupals programming style. be prepared to get up more than once in the middle of the night to update your drupal installation because some extension developer never did understand, why input from the web must be sanitized (yes, these kind of security problems are still happening in the drupal world.)
So "hardening" means "keeping up with updates", in drupals case these come quite often. Think about this if you have many sites and want to deploy to multiple servers - automatic deploymemts will help you save a lot of time.
Here's an excellent rundown for Drupal 7: http://www.madirish.net/242.
Most of its suggestions are relevant to Drupal 6 as well.
You should also remove the Theme registry rebuilding setting.
It rebuilds your theme registry on every pageload, so it makes your site very slow.
I've got a strong background in Linux and OSX, and just left a job where I was architecting systems based on those platforms.
Now I've got a Windows Server running IIS that has a number of different websites that it hosts. Most of them are just a bunch of HTML, JS and Images, with some ASP for some customer tools. (Each website has a different set of customer tools, or they are the same tools, but with minor code changes between them.) I'm also adding a develop web server with the same code, but the 'bleeding edge' stuff.
I need an effective way of managing changes and updates to the overall codebase (henceforth referring to both the images and the html and the asp, for all the sites). When a dev (or webmaster) checks in changes, I want it to show up automatically on the developer server, but should be manually pushed out to the live server. I'd be tempted to just make the websites SVN repositories, but I'd be concerned about the overhead of having the webdeveloper having to log into the server and trigger an SVN update via commandline/tortise (and heaven forbid, manage tags).
Ideally I'd also manage IIS profile settings between the systems, but the major need is to be able to manage the process, and expose it to our ASP developer, and our webmaster, both of which are used to just FTPing up the files to the live site.
So, any recommendations on tools (beyond some SVN hacking with BAT files + teaching the webmaster how to log into the server and do updates) or workflows that would help this out? I even considered an RPM type package (or some Windows equivalent, of course) to manage the live server, but that seems like a bit too much overhead.
First you need to decide how the webmaster knows that the latest in your SCM is ready for deployment (I assume you want some level of acceptance testing after the developer has checked in).
Depending on the above answer you should be able to define the steps to get the "approved" content built and updated on the web server, then it would be a matter of scripting this.
In the end the problem is not the commands to run, but knowing /when/ to run them, and that the last checkin from developers is not necessarily going to work 100% (even without mistakes two concurrent changes, each working, could conflict).
I'm not new to web publishing, BUT I am new to publishing against a web site that is frequently used. Previously, the apps on this server were not hit very often, but we're rolling out a high demand application. So, what is the best practice for publishing to a live web server?
Is it best to wait until the middle
of the night when people won't be on
it (Yes, I can pretty much rely on
that -- it's an intranet and
therefore will have times of
non-use)
Publish when new updates are made to
the trunk (dependent on build
success of course)
If 2 is true, then that seems bad if someone is using that specific page or DLL and it gets overwritten.
...I'm sure there are lots of great places for this kind of thing, but I didn't use the right google search terms.
#Nick DeVore wrote:
If 2 is true, then that seems bad if
someone is using that specific page or
DLL and it gets overwritten.
It's not really an issue if you're using ASP.NET stack (Webforms, MVC or rolling your own) because all your aspx files get compiled and therefore not touched by webserver. /bin/ folder is completely shadowed somewhere else, so libraries inside are not used by webserver either.
IIS will wait until all requests are done (however there is some timeout though) and then will proceed with compilation (if needed) and restart of AppDomain. If only a few files have changed, there won't even be AppDomain restart. IIS will load new assemblies (or compiled aspx/asmx/ascx files) into existing AppDomain.
#Nick DeVore wrote:
Help me understand this a little bit
more. Point me to the place where this
is explained from Microsoft. Thanks!
Try google for "IIS AppDomain" keywords. I found What ASP.NET Programmers Should Know About Application Domains.
We do most of our updates in the wee small hours.
Handy hint, if this is an ASP.NET site, whatever time of the day you roll out, drop in an App_Offline.htm file with a message explaining to users that the site is down for maintenance.
Scott Guthrie has more info here:
http://weblogs.asp.net/scottgu/archive/2006/04/09/442332.aspx