Update:
Since this question was asked Joomla StackExchange has been setup and the same questions exists there please add any answers or comments to that question
Original:
I am using Joomla 3.0.3 for a fairly big new client, security is a must. I therefore decided to try change the Administrator URL, normally
example.com/administrator
changed to
example.com/newadminurl
Reason being if the folders aren't where potential hackers expect that is the first hurdle before they can even try anything else.
However that has now meant whenever I go to the new URL it brings up a 403 error. I have tried searching if there is a global config setting I need to change but can't find anything on the web or Joomla site. Anyone know how to change this deep down in the source code?
Step 1. Create a new directory in your root directory (eg. "newadminurl")
Step 2. Create an index.php file in your "newadminurl " directory..
$admin_cookie_code="3429020892";
setcookie("JoomlaAdminSession",$admin_cookie_code,0,"/");
header("Location: /administrator/index.php");
?>
Step 3. Add this to .htaccess of your real Joomla administrator directory
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/administrator
RewriteCond %{HTTP_COOKIE} !JoomlaAdminSession=3429020892
RewriteRule .* - [L,F]
Explanation:
Now, you need to open "http://yoursite.com/newadminurl/" before you open your “administrator” path. Here we have created a cookie that expires at the end of the session and redirect to actual administration page. Your actual “administrator”path is inaccessible until you don’t open on your secret link .
I hope this is what you were looking for.
While there are hacks around that do this, they introduce new security issues as the Joomla! core isn't built to work this way.
In fact the it is common practice both in the core and in 3rd Party extensions and templates to load models, controllers and other assets from /administrator.
The best practise is to secure your site is:
Keep your Joomla! installation up-to-date (the most common cause is outdated installs)
Don't hack core files, if you need extra functionality duplicate the core component and extend that, not the core.
Add a realm password /administrator
A secret word on the /administrator url e.g. /administrator/?s3cr3tpa55w0rd
An ip whitelist that only allows on select IP addresses to access /administrator
Use unique and strong passwords
Don't share passwords even with your significant other...
Enact a password policy on your site.
Keep a tested and regular site backup in an off-server storage location.
Run a file scanner to help you detect a hack so that you're aware of where your last good back was taken.
You can find extensions that do one or several of these things for you in the Access & Security section of the Joomla! Extension Directory (JED), and for integrated backup to cloud or other storage you can't go past Akeeba Backup (and personally for the tiny fee compared to the cost of my time we always go with the Pro versions).
In fact Akeeba's Admin Tools Pro (included in any of their subscriptions) also provides most of the features on that list through it's WAF (web application firewall). The only area not covered is Password Management of which there are several solutions available.
There might be all sorts of dependencies in the core and in third party extension that will hard code the admin path, even though there are platform variables to assist this.
I would recommend that you instead configure your .htaccess to prevent public viewing of your administrator folder and restrict access only to approved IP addresses. This will prevent them from accessing the admin folders, but of course will not protect against attacks which do not require direct access (e.g., some third party app that calls code in an admin folder for the component from the front end).
Note: This goes in the .htaccess file in your administrator folder not the .htaccess in the site root, i.e. [siteroot]/administrator/.htaccess
Here is an example of the .htaccess you may configure:
ErrorDocument 403 http://www.your-ip-is-not-allowed-to-access-this-section.com
Order deny,allow
Deny from all
Allow from X.X.X.X
Where X.X.X.X. if the IP address you want to allow to the admin section. You can specify multiple addresses with multiple Allow from X.X.X.X lines.
Related
My problem is that if I type my domain without any slashes, it shows the complete folder and file structure, so we can say it is not really secure. I've managed to encrypt the folders, but not the main domain. In the cPanel I dont't find where can I make it secure, and invisible. Please don't devalue me for this question, I'm new.
If you want to prevent users from viewing the directory listing, you should select the no indexing option in cpanel. See this link for more information: http://www.inmotionhosting.com/support/edu/cpanel/remove-index-listing.
You can also password protect your domain using .htaccess and .htpasswd
I'm trying to display simple HTML files in a folder on my web site. No ASP.NET, no application, just a virtual directory. I'm getting "Access denied" in the browser when I try to open a web page.
This is through a hosting provider; I have access through FTP and IIS Manager only.
Authorization Rules show Allow - All Users - Inherited.
I'm far from an expert on IIS, and most search results either suggest checking folder permissions in the file system (which I have no direct access to) or are relevant to applications.
How can I diagnose this?
More information:
Through trial and error, I found out the cause, and worked around it with URL Rewrite. I'd still like to know why it's happening (the root cause) and how to change IIS's behavior.
I'm moving my site from Linux hosting to Windows hosting. Some of the old URLs are of the form:
http://www.MYSITE/myblog/index.php/2013/04/29/SOMEFILE.html
The ones I'm moving are HTML files, not PHP files, but I tried to mirror the folder structure.
The problem is in the index.php folder name. No matter what I do, even if I enable directory browsing, IIS won't let me access any files in a folder with that name. If I rename the folder (or even the "extension" part), it all works.
I've scanned through many of the IIS settings and haven't found any mention of forbidding a .php extension. What's going on?
You need to add permission for IIS users.Try adding permission to the folder by adding user
IIS_IUSRS and give required permission .
1.Right click on folder, go to properties
2.Go to security tab
3.Click on Edit, if you don't see IIS_IUSRS in the user list who have permission
4.Click on Add , In the box , add IIS_IUSRS and click on check names, it will
get the qualified name .
5.Click OK and apply
Hopefully it should work then
Through trial and error, I found out the cause, and worked around it with URL Rewrite.
For URLs of the form:
http://www.MYSITE/myblog/index.php/2013/04/29/SOMEFILE.html
The problem is in the index.php folder name. IIS won't let me access any files in a folder with that name. If I rename the folder (or even the "extension" part), it all works.
This is reminiscent of Joomla virtual (SEO) URLs. I'm assuming that you don't really have static files at all, but the CMS program running your site parses this information after the "index.php" as parameters for a database query to create the html page on the fly. In this case, the only file that's really being served by the web server is index.php, and the program includes other php files depending on the parameters entered. You're on the right track though, with creating a small file on the destination server and try to load it, but this means the index.php directory structure is moot.
I need to upload to my server a high sensitive data file to be used by PHP scripts. Please, tell me what's the most secure way and why:
Putting it in a folder not under www root
Putting it under www root but denying access with .htaccess rule
Thank you very much
If you have ftp/sftp/ssh access to this server, there's no reason not to put it outside of the www document root. If you have a hosting service that only grants you access to the www document root, then you'll have to go with the second solution, but the first is much more secure.
Htaccess can be bypassed if there is a vulnerable script on your site. There are tools that, if placed correctly, files inside the document root and be uploaded by a remote attacker or even replaced. For example, there are php "remote file managers" that allows a remote attacker to change permissions, edit, or replace existing files, including your htaccess file. If you're running a site like Wordpress, or some other CMS, that aren't exactly super secure by themselves, that have a lot of third party plugins, those plugins could be vulnerable to attacks, and if you happen to be using one, your htaccess file's access restrictions could be bypassed.
When the sensitive information is outside of the document root, an attacker who has access to the document root won't be able to access these files and vulnerabilities in your scripts are a lot less likely to affect access to these files. There most likely needs to be a system level exploit to be able to gain access to files outside of the docuement root.
I have yet another .htaccess question, simple for you, not so much for me.
Let's say my main site is found at http://domain.com. I do all of my pre-release testing at sandbox.domain.com and sandbox.domain.co. I just realized that Google has gone ahead and indexed my sandbox sites... Ugggh!
The document root folder on my Apache server with the live site is always called ALIVE, and in order to make my sandbox contents live I quickly rename the folders, ie ALIVE->OLDx, SANDBOX->ALIVE.
My goal is to prevent indexers and users from accessing my sandbox pages. I am trying to design a .htaccess file for document root that only allows my ip address when accessed from a sandbox subdomain (sandbox.domain.com), otherwise it allows everyone when accessed from the main domain (domain.com). This would eliminate the process of remembering to update the .htaccess file each time I release a new site.
This doesn't seem too difficult, but I haven't been able to find the right combination. Any pointers in the right direction will be much appreciated!
Create a .htaccess inside each folder (like sandbox):
order deny,allow
deny from all
allow from YOUR IP HERE
I'm relatively new to dotnetnuke and am trying to set up a simple site which will have multiple user groups with their own set of files and then another user that has access to all files.
I'm currently playing with doing this with the "documents" module and hiding the module from all but the everything user and the specific company user. This works fine but the security seems to be just security by obscurity.
If I log in as User A and get access to file A and copy its url. I then log out and log in as user B who can't see that file. If I then put the file url into the browser it seems to download fine.
Can anybody tell me if I am doign something wrong or is there no actual user based security on file downloads? I've tried goign to the actual file manager and making the directories explicitly not viewable to user B (they are secure directories too) but still it persists. Am I missing a permissions option at the file level somewhere or is the security designed to just prevent you finding the right links to the files? I'll admit the links aren't guessable (no sequential ids in the url or anything silly like that) but I'm still a little uncomfortable with the security working like this...
DNN FileManager Module
Hi Chris,
Please check out the FileManager module per above link. You are correct that the current FileManager module does not allow access per user roles. You might check Snowcovered for possible substitutes?
It seems that I was doing something wrong. I was referencing a different version of the file which didn't have any permissions attached to it. It seems also that I don't need to have multiple documents modules since if a file doesn't have read permission it will just be hidden in the list.
So to summarise the DNN Documents module will do role based security to prevent unauthorised users from downloading the file and from seeing it in the documents view.
Documents module provides security for LinkClick.aspx urls that are routed to ASP.NET.
If the actual files reside in the file system under the site's root folder, direct urls to these files are served and secured by IIS.
To prevent unauthorized access to direct urls you can disable anonymous authentication and set up Basic authentication with NTFS permissions, for example.
If don't want to touch IIS and administer Windows accounts, you can't store the files directly under any publicly available IIS folder. Security at the ASP.NET application-level is implemented using file encryption or storing the files outside the public IIS folders, like in the database. DNN File Manager offers both of these options: secure folders in the file system and secure folders in the database.
There are also 3rd party modules to manage file security and sharing, like NukeTransfer.