Secure AdminCP and Installation [Deleted]

Urgg. I'm confused Adam.. So I changed the htaaccess for forum to 644 and what do I change the admin.php to? Also there is an admindv.php as well. Do I need to do anything with this?
Admin.php you do not change anything. You need to password protect it using htacesss (following my instructions on how to do that)

http://tools.dynamicdrive.com/password/

You will also need a password file. This file should be above public_html or www
 
Maybe it is a good idea just to deny into ACP by name, only by e-mail - this is not public info and cannot be obtained easily. Dunno how to do this, but it give us an additional profit - admin's account will not being blocked when it is brute forced.
 
Maybe it is a good idea just to deny into ACP by name, only by e-mail - this is not public info and cannot be obtained easily. Dunno how to do this, but it give us an additional profit - admin's account will not being blocked when it is brute forced.
At the moment there is no way to do this and even if there was away; an e-mail address is nothing more than a user name when you think of it. And as such can indeed be brute forced (guessed).
 
Hi Adam!


Brute force is not the evil by itself. But it has an aftermath, a bruted account will be locked.
It is for sure impossible to bruteforce if you do not know proper login for it. You can recognize an administrator by indirect signs, and make his account disabled just putting his name into ACP and hitting ENTER button five times or so. It is very useful before attacking. In my scenario it is impossible. No way to block because mapped with admin's acc e-mail is unknown for malefactor.
 
Hi Adam!


Brute force is not the evil by itself. But it has an aftermath, a bruted account will be locked.
It is for sure impossible to bruteforce if you do not know proper login for it. You can recognize an administrator by indirect signs, and make his account disabled just putting his name into ACP and hitting ENTER button five times or so. It is very useful before attacking. In my scenario it is impossible. No way to block because mapped with admin's acc e-mail is unknown for malefactor.
Again, this is currently not possible.

And even with a system in place that limits log-in attempts, it can still be forced in (guessed). All one needs is to try from multiple sources. An automated system or even a collective attack could generate millions of locations.

If you suggest that the account be locked to prevent from any and all sources after failed log-in, then you have just given the attacker an exploit; away to keep you out.
 
There can be billions locations, but if a malefactor have no login this is only ddos, not a brute force. This is the same advise that you gives, but more radical. You said - hide the name, I said - prevent using the name. Maybe my English is so bad...
 
Again, this is currently not possible.

And even with a system in place that limits log-in attempts, it can still be forced in (guessed). All one needs is to try from multiple sources. An automated system or even a collective attack could generate millions of locations.

If you suggest that the account be locked to prevent from any and all sources after failed log-in, then you have just given the attacker an exploit; away to keep you out.

It is not easy with user locks (impossible unless you are willing to wait several years / use easily brute forced passwords for the admin account... in which case you are asking for it). User locks are already available in the ACP area, the Super Admin account is locked regardless of the location for 15 minutes (try the wrong password 5 times, the admin account is the locked for 15 minutes)... This is core functionality, and it's quite a long lock (it would be a tedious exploit to lock this every 15 minutes continuously, but a simple lock of 30 seconds would still significantly reduce the chances of successful brute force and be more human friendly)

However, there a no locks on the front end, so if you don't use CAPTCHA or use QA, it's then possible to brute force the admin account, gain the password and use this password to gain access to the ACP.
Even with CAPTCHA, since most common ones are programatically solved, it's still fairly easy to brute for the admin account.
Hiding or obscuring the Super Administrator username is not really going to stop a malicious user (it does nothing to stop malicious users from figuring it out).

By cycling through the member users (listed on the forum) it possible to use these names as a hit list, progmatically attempting on the ACP area each until the response "incorrect password" is achieved.

Since the Admin area gives a different response when using a non admin account:
The requested user 'testuser' could not be found.
compared to using an incorrect password (with the correct admin account):
Incorrect password. Please try again.

Once you have this response, you know the admin username... you can then use the username to brute force the front end (since there are no user locks here)
If a CAPTCHA is used, the CAPTCHA appears after 5 attempts, if this CAPTCHA is a QA, the user only needs to log the QA Questions and Answers, then the bruteforce can commence without issue
If no CAPTCHA is used, it's possible to brute force without issue.

This I would recommend:
3) Password Protect AdminCP ( admin.php )

It wont stop the Admin account being brute forced, but it will stop anyone using the ACP area.. you could do that, or simply take out the superadmin account from the config.php file once you have finished with the ACP area
I would also strongly recommend user locks (they only need to be small user lockers) on the front end to, particually if you use no CAPTCHA or simple QA CAPTCHA (For the sake of all XF forums, I hope this is applied to the core soon)
 
  • Like
Reactions: R_A
As the Super Admin is usually the founder, or someone close to the start of the site, can't someone sort members by date joined and see who tops the list?
 
As the Super Admin is usually the founder, or someone close to the start of the site, can't someone sort members by date joined and see who tops the list?
You can always register a new user and setup that user as the super admin. I typically change mine and as such my registration date is weeks, months, or years away from when the site was founded
 
You can always register a new user and setup that user as the super admin. I typically change mine and as such my registration date is weeks, months, or years away from when the site was founded

That doesnt stop them from programatically cycling through each of the usernames (from the members area) and waiting for a different response from the ACP area... as soon as they have the "Incorrect password. Please try again." response, they know your superadmin

But password protecting the ACP area is a good call
 
That doesnt stop them from programatically cycling through each of the usernames (from the members area) and waiting for a different response from the ACP area... as soon as they have the "Incorrect password. Please try again." response, they know your superadmin

But password protecting the ACP area is a good call
Which is also what I recommend (it's in the guide).
http://xenforo.com/community/resources/secure-admincp.415/

The general idea is everything you do is 1 more step for security, but with the understanding that nothing is fool proof.

While nothing is 100% hack or crack proof, it's always a good idea to make things just a little harder.
http://xenforo.com/community/resources/secure-admincp.415/
 
Is my redirect non-www to www rule OK? xenforo is in forum subdomain

Code:
RewriteCond %{HTTP_HOST} ^hedonist385\.in$
RewriteRule ^(.*)$ http://www.hedonist385.in/forum/$1 [R=301,L]
 
Is my redirect non-www to www rule OK? xenforo is in forum subdomain

Code:
RewriteCond %{HTTP_HOST} ^hedonist385\.in$
RewriteRule ^(.*)$ http://www.hedonist385.in/forum/$1 [R=301,L]

If you want to redirect all non-www requests to your site to the www URL's, add the following code to your .htaccess file:
Code:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
This will redirect any requests to http://hedonist385.in to http://www.hedonist385.in
 
If you want to redirect all non-www requests to your site to the www URL's, add the following code to your .htaccess file:
Code:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
This will redirect any requests to http://hedonist385.in to http://www.hedonist385.in

My board is not in public_html. Forum is in public_html/forum ...This redirect http://hedonist385.in/forum/ to http://www.hedonist385.in. I add before $1 /forum/ and now working fine. Just in Firefox problem, but I think that be resolved
 
What if someone already uses "Username" with id1, and has himself administrator ?

In vbulletin, I would rename both the admin and mod cp folders. Shame we don't have that here
 
What if someone already uses "Username" with id1, and has himself administrator ?

In vbulletin, I would rename both the admin and mod cp folders. Shame we don't have that here
You can register a new user name and change the user ID value in config.php to match.

The point it not to have the Super Administrator be user ID #1. And every new member gets a user ID. So pick a new name (make a new account) and setup that as your Super Administrator.

Make a few post so its not just some random zero poster, but so no one knows who you are using that account. And then don't use it ever to make any announcements or anything official. Only YOU should know who the Super Administrator is.
 
Top Bottom