Prevents brute force cracking of Webshell passwords

Although I have known this kind of tool for a long time, I discovered it was really cool after a try. I thought for a moment, there seems to be no perfect solution for this unreasonable approach. This is like DDOS. You can ignore it, but you cannot ignore it. However, for the existing popular Webshelll password cracking tool, you can take some simple measures to reduce the possibility of being cracked.The first is to increase the password strength.Considering that the current password cracking is mainly performed by loading the dictionary, it is very simple and effective to change the password long and smelly.
The second is to add a judgment mechanism.Generally, attackers will first observe the Webshell when cracking, such as the password submission method (POST or GET) and incorrect password prompt. Configure the attack parameters based on the information. Of course, most of the current webshell password submissions are post. We can add a GET verification, so that the cracking tool becomes invalid. (Because he doesn't know how you verify the GET parameter.) If the previous password verification was written like this

<? Php //... Some code $ pass = "I Am a password"; if ($ _ POST ['pass'] = $ pass) {echo "Login successful !"; //... Some code }//... Some code?>

 

We can change it like this.

<? Php //... Some code $ pass = "I Am a password"; if ($ _ POST ['pass'] = $ pass) {if ($ _ GET ['url'] = "ADmin") {echo "Login successful! "; //... Some code }}//... Some code?>

 

In this way, we can use webshell. php? Url = ADmin. However, attackers can only hold webshell. php in a group. In addition, it can be verified by judging HTTP_REFERER. When a general tool is cracked, it will forge a URL package l with the HTTP_REFERER value of webshell, or some will simply be empty. When we use webshell. php? When the url = ADmin or another page (such as local html) submits a password, the HTTP_REFERER value is another value. In this way, you can determine whether you are logging on. The third one is even more cumbersome, and another verification method.
Leave a POST form on webshell. However, the program does not perform any verification on POST data. Instead, it verifies the submitted cookies. For example

<? Php //... Some code $ pass = "I Am a password"; if ($ _ COOKIE ['admin'] = $ pass) {echo "Login successful !"; //... Some code }//... Some code?>

 

No brute-force cracking tool for Cookie submission has been found yet (but no webshell cmd_^ for password submission using cookies is found), so that the attack can be avoided. It is a little troublesome. If this is the first time you log on to your webshell, you may need to launch a plug-in to modify cookies. Another boring method is useless:

<? Php //... Some code $ pass = rand (,); if ($ _ POST ['pass'] = $ pass) {echo "Login successful !"; Header ('location:/userRpmNatDebugRpm26525557/MyShell.htm ');} // The following is the password verification section $ pass = "I Am a password "; if ($ _ COOKIE ['admin'] ==$ pass) {echo "Login successful! "; //... Some code }//... Some code?>

 

After the code is changed, I guess the password will be cracked, and the Buddy will have to worry about whether the tool he downloaded is correct ...... You must have more and better insights on how to hide the Webshell portal or Webshell itself. In this article, we aim to use a simple method to escape attacks from webshell password cracking tools.