Hi all,
1) I just want to know how do hacker hack my site if I not change the admin folder name to different name?
2) And does it help If I not change the admin folder name but I create another layer passwoed protest the admin page?
Thank You
(1) Short answer, with difficulty. Inevitably some directory name will be intelligible and guessable. The protections that are at work spring form .htaccess and the token system, among others.
(2) Short answer, helps. If you use the host's (or your own) passwording for /admin/, then the server challenge will require a user/pass before the admin log-in screen even shows. Use a SEPARATE user/pass for passwording the directory itself.
(2) Short answer, helps. If you use the host's (or your own) passwording for /admin/, then the server challenge will require a user/pass before the admin log-in screen even shows. Use a SEPARATE user/pass for passwording the directory itself.
A little extra info on explaining your two points.
1. If you do not change your admin folder's name, it's like letting the attacker know where you are. Further on, some people leave their admin username as the default, that makes things even easier. How hard can we use a brute force attack to get in?
2. It does help with .htaccess as a second layer of defense. However, do note that some people prefer not to have that as it might seem 'irritating' to be entering a password twice to log in.
1. If you do not change your admin folder's name, it's like letting the attacker know where you are. Further on, some people leave their admin username as the default, that makes things even easier. How hard can we use a brute force attack to get in?
2. It does help with .htaccess as a second layer of defense. However, do note that some people prefer not to have that as it might seem 'irritating' to be entering a password twice to log in.
. . . and in the instance of a brute force "dictionary" attack, the replacement name should ideally have no segments that appear in any dictionary in any language. As a practical matter snippets of 2 or few letters would tend to be "guessed" while intermingling numbers and punctuation marks would not dramatically affect the overall odds (all-numbers would drop the odds, such as to 10x10x10x..., or if binary to 2x2x2x2...).
The main advantage in two tiers of passwording /admin/ (or any other sensitive directory) is the impracticality of repeatedly feeding trials to the server, then if that happens to succeed, having to do it a second time. Another, for the sake of admin access, is to limit it to machine addresses that only bona fide admins use. Combining those, two tiers of user/pass plus address matching increases the ante by 256 to the 4th, among the four positions of 0-255 in a quad-decimal address, but that is a mere 4,294,967,296 fold possibilities more. One way to prevent that eventuality practicably is to limit tries; severely. Each user/pass requires a dead match (here twice), address requires a dead match, cutoff requires reconnecting, and if there is no prize to speak of, nobody will really try. A further step can be interposed, to require that if user/pass, user/pass, and quad-decimal are all dead matches, with moreover severely limited tries, then and not at the outset a peculiar 128 bit certificate available only on preauthorized machines must be transmitted and received well nigh instantly. I actually do use those several preventions and others in concert, sometimes followed by a permanent lockout of an address or address range, whether I bother to rename directories absurdly or not. Probing for such antiquated ways in as whereami.cgi or 777 combined with weak or missing .htaccess is simpler and quicker. There is fundamentally no such thing as unhackable; defenses can, however, render hacking so extraordinarily unlikely to succeed as to make minor prizes unattractive. Shopping carts and forums, as popular targets in trying means of intrusion, do not invite the same extent of perverse dedication to intrusion as banking, militaries, spying, and undisrupted webservers or mailservers invite. Shopping carts and forums do invite a measure of perverse mischief that a measure of strong preemptive defense can practicably prevent. Dual passwording of /admin/ (or a comparably sensitive directory) even without renaming it goes most of the way there as to admin access.
The main advantage in two tiers of passwording /admin/ (or any other sensitive directory) is the impracticality of repeatedly feeding trials to the server, then if that happens to succeed, having to do it a second time. Another, for the sake of admin access, is to limit it to machine addresses that only bona fide admins use. Combining those, two tiers of user/pass plus address matching increases the ante by 256 to the 4th, among the four positions of 0-255 in a quad-decimal address, but that is a mere 4,294,967,296 fold possibilities more. One way to prevent that eventuality practicably is to limit tries; severely. Each user/pass requires a dead match (here twice), address requires a dead match, cutoff requires reconnecting, and if there is no prize to speak of, nobody will really try. A further step can be interposed, to require that if user/pass, user/pass, and quad-decimal are all dead matches, with moreover severely limited tries, then and not at the outset a peculiar 128 bit certificate available only on preauthorized machines must be transmitted and received well nigh instantly. I actually do use those several preventions and others in concert, sometimes followed by a permanent lockout of an address or address range, whether I bother to rename directories absurdly or not. Probing for such antiquated ways in as whereami.cgi or 777 combined with weak or missing .htaccess is simpler and quicker. There is fundamentally no such thing as unhackable; defenses can, however, render hacking so extraordinarily unlikely to succeed as to make minor prizes unattractive. Shopping carts and forums, as popular targets in trying means of intrusion, do not invite the same extent of perverse dedication to intrusion as banking, militaries, spying, and undisrupted webservers or mailservers invite. Shopping carts and forums do invite a measure of perverse mischief that a measure of strong preemptive defense can practicably prevent. Dual passwording of /admin/ (or a comparably sensitive directory) even without renaming it goes most of the way there as to admin access.
. . . and be certain to put the /renamed/ in place of /admin/ in both config.php files, then for good measure reinstall vqmod (send up fresh virgin index.php files first, NOT new config.php blanks), and flush both /system/cache/*.* and /vqmod/mods.cache and /vqmod/cache/*.* files. You should flush your browser cache and restart it, as well. The system must consistently see only /renamed/ for /admin/.
Then do the passwording. The passwording will put either .htaccess or another .ht* file in /admin/ or /renamed/.
Then do the passwording. The passwording will put either .htaccess or another .ht* file in /admin/ or /renamed/.
1) If I rename the admin folder, do I have to reinstall Vqmod or I can just go and rename some file in Vqmod?
2) Everytime I adding a new module or theme to my site, do I have to rename the admin folder in the module or theme to the new name before I upload to my site?
3) Do I need to rename any other file that in the module or theme befroe I can upload?
2) Everytime I adding a new module or theme to my site, do I have to rename the admin folder in the module or theme to the new name before I upload to my site?
3) Do I need to rename any other file that in the module or theme befroe I can upload?
(1) After you change /admin/ to /renamed/, there is no file to rename, but in the two config.php files OC and vqmod need to know, and THEN in the admin index.php file vqmod needs to know, what and where /renamed/ is.
After you change /download/ to /renamed_too/, there is no file to rename, but there, too, in the two config.php files OC and vqmod need to know, and THEN in index.php file vqmod needs to know, what and where /renamed_too/ is.
In both cases OC and then in reinstalling itself vqmod will refer to the config.php pair, so those are done before reinstalling vqmod.
(2) You do not need to do any of that after adding a new module or theme.
(3) Module and theme files go into the directories where they belong. When they come inside an /upload/ directory and one of the directories is named /admin/ you will need EITHER to rename /admin/ to /renamed/ in order to match the actual director, OR INSTEAD just to drag the contents of /upload/admin/ into /[OC]/renamed/ in order put the admin files where they belong.
(4) When vqmod installs it reads the config.php pair and rewrites the top portions of virgin copies of the two index.php files, and in part it writes this sort of thing (about three times) into the /admin/ (or /renamed/) index.php file:
Language
$language = new Language($languages[$config->get('config_admin_language')]['directory']);
$language->load($languages[$config->get('config_admin_language')]['filename']);
$registry->set('language', $language);
If you give it a fresh pair of virgin index.php files and run /vqmod/install/index.php, then in a twinkling it will get the directory and language correct on its first try. Its accuracy and precision (correctness an repeatability) in doing that are better than yours -- we mistype and so forth, it does not.
Flushing the /system/ and /vqmod/ caches (as a couple of posts above) erases memory of the prior condition (with /admin/ not yet changed to /renamed/, or of /download/ not yet changed to /renamed_too/. Flushing the browser cache (and for good measure restarting the browser) removes its memory, too.
After you change /download/ to /renamed_too/, there is no file to rename, but there, too, in the two config.php files OC and vqmod need to know, and THEN in index.php file vqmod needs to know, what and where /renamed_too/ is.
In both cases OC and then in reinstalling itself vqmod will refer to the config.php pair, so those are done before reinstalling vqmod.
(2) You do not need to do any of that after adding a new module or theme.
(3) Module and theme files go into the directories where they belong. When they come inside an /upload/ directory and one of the directories is named /admin/ you will need EITHER to rename /admin/ to /renamed/ in order to match the actual director, OR INSTEAD just to drag the contents of /upload/admin/ into /[OC]/renamed/ in order put the admin files where they belong.
(4) When vqmod installs it reads the config.php pair and rewrites the top portions of virgin copies of the two index.php files, and in part it writes this sort of thing (about three times) into the /admin/ (or /renamed/) index.php file:
Language
$language = new Language($languages[$config->get('config_admin_language')]['directory']);
$language->load($languages[$config->get('config_admin_language')]['filename']);
$registry->set('language', $language);
If you give it a fresh pair of virgin index.php files and run /vqmod/install/index.php, then in a twinkling it will get the directory and language correct on its first try. Its accuracy and precision (correctness an repeatability) in doing that are better than yours -- we mistype and so forth, it does not.
Flushing the /system/ and /vqmod/ caches (as a couple of posts above) erases memory of the prior condition (with /admin/ not yet changed to /renamed/, or of /download/ not yet changed to /renamed_too/. Flushing the browser cache (and for good measure restarting the browser) removes its memory, too.
Who is online
Users browsing this forum: No registered users and 8 guests
