Fighting bad URIs, spammers and php shells is a personal experience
I suppose all web programmers go the same way to one degree or another. I build on my personal experience. For me, at the beginning of the comprehension of this science, the creation of the site was in the first place. Only after a considerable time, I realized that the sites also opened. After reading how this is done, I was surprised at how much simply because of inexperience to turn my website into a “passing yard” and began to pay some attention to security. At least I began to filter the input parameters of the pages.
At the second stage, I was surprised to find that there are such animals as PHP-shell. Kaspersky helped me with this when he blocked access to my much beloved site. The next revelation was that not only you can be opened, but also hosting. In this case, shells appear on your site with surprising regularity, and they don’t know where they are from, of course, what they want. For example, they edit .htaccess files and close their editing for everyone, including the owner.
All these revelations at one time took a huge number of Saturdays and Sundays and demanded the transition to rewriting urls, creating a comprehensive system for analyzing input parameters for suspicious words and expressions (here, by the way, I suffered some fiasco), creating a log of parameters transmitted by the post, system, notifications about suspicious events occurring on the site, and, finally, permission to run only scripts with a specific prefix in the name so that no other script such as template.php or wso2.php is launched.
')
What you need to keep in mind and what can be done to create a relatively secure site?
A modern website created in PHP usually has a fairly extensive file structure. It definitely has executable scripts, modules or classes that are included with the include / require instruction, .css and .js files, and page cache. These files for simplicity and restrict.
I think the question asked in the subtitle, I will answer in the affirmative and it is very useful. Thus, for example, PHP include files are not intended to request them for processing by the server and output to the browser. In folders of this type, we have a special .htaccess file in which we prohibit anyone from accessing anything.
In folders with .css and .js files, we cannot afford this, but in these folders we can restrict access by type, which is not bad either. The following is a ban on access to any files except files with the extension .js
It is worth noting that, in my experience, such a restriction practically does not affect the real security of the site and is, so to speak, only one tick in the general list of tasks. I myself do not use these methods, and this will be discussed below. But, on the other hand, effort is also required for this, so why not? Again, if some crazy robot acts against you, he will shove like a tractor and spoil everything. If you know that in the folder you only have files with certain extensions, it will be easier to detect a malicious newcomer.
Personally, I went a little further. My .css and .js files are compressed and cached, so the folders where the sources are located can be closed from everyone in a row. The requested caches themselves are in a rather deeply buried folder where the robot may not reach. By the way, I have only one executable script for the whole site. But more on that later.
Here, by the way, is a good method to really improve the security of your site. The fact is that a malicious robot searches for folders on the site with certain names. The same applies to files. Therefore, as one of the measures to increase security, this is changing the names of folders and files to something non-standard. It is worth inventing something of your own and give the names at least prefixes. Prefixes definitely help from robots. If you want to try to make it difficult and manual hacking, then I advise you to go ahead and give the folders and main files their own names (Peter, Masha, etc.). Not many young hackers will figure out where you are lying. Although the hackers involved in burglary of boredom, it is not known what kind of mess can be in my head. But there is definitely a chance! The main thing is not to get confused. Also a considerable chance.
This is what I can not understand. There is a file that everyone knows what is called, and in which in open form lies exactly what the hacker needs. Why is this done? This, in my opinion, is some sort of wrecking. I highly recommend encrypting the data for access to the database on all my websites and place them in a completely non-standard named file, which is barred from network access and is read-only. Of course, we need to work on optimizing the decryption speed, but this is also quite solvable. At least XOR is pretty fast (link to Vernama’s Cipher at the end of the article). The main thing is to have a key of good length and hide it better. You can create a really confusing and very efficient decryption algorithm and make the hacker spend many hours on your site before they find the key and the algorithm for using it. You see malicious activity in time, thanks to your own logging-notification system, stop the activity of the attacker and change keys, passwords, turnout and so on. Therefore, downloading your scripts and dealing with them before losing consciousness can be unproductive for a hacker.
Very important topic. First of all, I’ll say that public hosting can really be opened and on your site, out of place, there will be a file with the conditional name template.php . Suppose that your wonderful system of logging and notifications after some time, for example, after 10 minutes, will determine the appearance of such a new file in such a folder and send you an email about it. It would seem great! But the shell may in 10 minutes of this on the site mess up that the site will be out for a few hours. Passed through. We know what we are talking about.
And this extremely significant security vulnerability of most engines sin. For example, make a file with any name, for example my_template.php , place in it
Next, place it in the root of your site on WordPress and call it (script). And it will probably work! Show you your hello!
This is the evolution of the methods of dealing with this evil. But I do not work on free (and paid) engines and it's easier for me!
At first, I made such an Url rewriting, in which only files with a certain prefix could be launched. It works as follows. On your site itself, without any suspicious calls, a malicious file appears without a prefix. You remain in ignorance. Next is an attempt to access this freshly mounted file. It does not have a prefix, and it does not start, and you immediately receive a letter about it without delay. Go to the site, see the shell, block the IP from which it was requested, write a letter to the hosting and raise all the employees on the ears. All, as it ends well. The link to the article, in which I described the problem in a “highly artistic and at the same time entertaining” form, and I will point out the solutions in the basement.
There is a replanting of the shell, passing through a more intelligent, but for us, a safer algorithm. It is known that access logs are stored on hosts for a limited time, most often a week. The attacker sends you a post-file on the site - a shell script and leaves it for a little more than a week. The logs in which the vulnerability was visible disappear and you cannot determine the vulnerability that was used. But in our case we, in a matter of minutes, receive an alert about the appearance of a stranger in the file structure of our site, so this seemingly sophisticated method of replanting is more preferable and desirable for us.
The described system did not last long and was successfully replaced. As a result, I came to the following scheme, which today I consider close to ideal.
We delete from .htaccess all URL-rewriting rules that were there and leave only one rule, which any file sends to one separate executable script of your site. It has a special, unlikely name, at least a prefix. This script REQUEST_URI understands what it came, does all sorts of seo-rewriting and decides which script to transfer control to. The control is not transferred by rewriting, of course, but by including the file with the require instruction. As a result, access on your site is allowed to everyone, but only one executable php script is executed. All other scripts are in a separate daddy and protected from requests over the network and can be protected by the instruction Deny from all . And may not be.
By the way, this scheme is used in some engines. But there everything is controlled by a mega-script index.php with 10 thousand lines and more, and this scheme is implemented not at all for the sake of security, but in order to make it easier to close the code from plundering.
Here is a rule in my .htaccess
Please note that we are missing absolutely certain files that we definitely have, and all requests without exception are translated into the dispatch script, and not php scripts alone. By the way, both robots.txt and sitemap.xml can be generated in the dispatcher and sent as a script. And you can pictures ...
It is recorded in the " bad ur log ". I occasionally view this log in order to determine if I have any prohibited Uri, and whether it is necessary to make a redirect. The bad uri log has established itself as one of the most useful and entertaining tools in the admin area. We immediately see who is breaking, where is breaking, and that, in general, today is interesting for hackers. Of course, wp-admin and wp-config come first . There is something to think fans of free engines.
The log of bad uris includes uri of the form /very-bad-uri-script.php or / very-bad-uri-folder / . But if uri looks like / existent-folder / very-bad-uri-folder / , this uri may not be included in the log. In this case, at best, in the error log we will see a line of the type File does not exist: / existent-folder / very-uri-folder /
If we have disabled everything for everyone for the / existent-folder , then there will be an error like client denied by server configuration .
Both are not very convenient. The fact is that the call that enters the error log no longer falls into the access log, and we will not see any details. The most annoying thing is that we will not receive any letter in case of suspicious activity on the site. Such a nuisance is due to the fact that either the .htaccess file is missing from the / existent-folder or url rewriting is not included. To prevent this from happening, we firstly need to allow access to this folder for everyone, that is, erase our line Deny From All , and secondly, enable URL-rewriting.
Any requested file is sent straight to the bad uri log with all possible details. A line about this event goes to the access log and does not go to the error log. We receive a letter from the alert system, but, of course, if we programmed this functionality.
The above .htaccess is suitable for replacing the functionality " Deny from all ". In case we need to skip something, for example, js scripts or style sheet, then we need to either allow the request of certain file types, or, better, specify special names or prefixes for scripts. Well, or list the files to be skipped explicitly. But, I'm afraid, this is too hard in the sense of productivity of both the programmer and the server.
From time to time, but with surprising regularity, attacks occur on the site. Among these attacks, there are those, when from a certain IP go pinging of login pages and user registration, sending letters through the form and receiving announcements. This is a mail server. They work most often in a pair with “clean” IP, which are not used for attacks, but are used only for calling. To determine the essence of IP involved in spam, I myself use and strongly promote the site projecthoneypot.org .
It was extremely easy to fight such spammers. You just need to implement all these forms of Ajax and all. This alone is quite enough. For greater security, you can prohibit the php-backend call, if it does not come from the site.
Very voluminous traffic comes from questionable bots. Why doubtful? Because I do not know if these bots are useful for the site and why they go to my site and call urls that have fallen into disuse many years ago. In general, the appearance of a long time ago killed urls is in itself a compromising action for the bot. Such bots most often do not use the robots.txt file or use it in the opposite direction, that is, for them the existence of a list of prohibited addresses for viewing is a reason for them to break. However, these bots honestly tag themselves in user agents. Of these, I can name 199.192.207.146 with an agent
There are also bots masquerading as good ones, but they seem not to be like that. For example, 176.31.182.56 with an agent
Finally, I really do not like bingbot . He is extremely sloppy. He likes to break into the site for non-existent urles. It would be nothing if you do not think about where and in which bases he takes these URLs and why does he not remove them from the base? It is clear that I do not block this beast, despite my attitude towards it.
But there are attacks not aimed explicitly at spam. Requests can pour at a speed of a few pieces per second and are complete nonsense. Often corrupted and corrupted requests to the site itself, and often attacks on the engines, of which WP leads. A series of requests can usually be from 100 to 200 pieces in one series per day. Why break to the engines - of course, probably. Why should I try to get a site response for a warped, and often completely unreadable URL, I do not understand. But the fact is that a lot of requests with high speed slow down the site itself and its hosting neighbors and it is worth fighting with them.
By the way, what is an “unreadable URL”? And that's what!
Please do not really try to access this site on my site, because in this case your IP will be marked dangerous and it will be affected in rights.
First, the url has a length of more than 255 characters and had to be cut off. Secondly, at least everything that comes after the word “Result:” and is decoded (windows 1251), but still represents nonsense. There is a suspicion that this XoviBot / 2.0 URL is requesting , and in comparatively large quantities and always the same.
But how to fight? And is it worth blocking everything? If this process is difficult to fight, maybe you can lead it, or somehow adapt to it differently?
I, unfortunately, do not know what is the circulation of bad IP in nature, and whether the bad can become good, and the good can become bad. Therefore, if I block, I do it in manual mode. If IP affiliation from a country where my Russian-language site is most likely not to be read, and the activity is too hard, I block these IPs. Leave the rest.
In my security system, there is not only a bad uri log, but also an IP log that ever caused a bad uri. Spam, dangerous, blocked and unblocked IP, as well as bots, are counted in this list.
When entering from a blocked IP, the client gets to a special page where he is invited to click on the button and unlock the IP. Button Ajax. The lock entry is automatically changed to “unlocked IP”. I have about 20 blocked IPs now. Was at least one of them unlocked by the user? Not. Was not. Often there are visits from the already blocked IP? No, vanishingly rare.
For all clients coming from IP, which are somehow marked, the additional processing of their requests is never performed. The presence of a mandatory backslash is not checked for them, they are not checked for the list of redirects, the conversion of SEO addresses does not work for them. If the requests are not completely good, then he immediately, without delay, displays a short farewell.
But lately I have been thinking about how to improve the blocking system. It might be useful, when detecting a series of a stream of requests from a certain IP, to block it for an hour. I am only afraid that I have already optimized the processing of bad uri in such a way that the blocking of IP and the output of the standard farewell are approximately the same in processing time.
The above are fairly simple steps that can seriously increase the security of any site. I have a question - why these simple things are not included, it seems, in one engine? Neither paid nor free?
At the second stage, I was surprised to find that there are such animals as PHP-shell. Kaspersky helped me with this when he blocked access to my much beloved site. The next revelation was that not only you can be opened, but also hosting. In this case, shells appear on your site with surprising regularity, and they don’t know where they are from, of course, what they want. For example, they edit .htaccess files and close their editing for everyone, including the owner.
All these revelations at one time took a huge number of Saturdays and Sundays and demanded the transition to rewriting urls, creating a comprehensive system for analyzing input parameters for suspicious words and expressions (here, by the way, I suffered some fiasco), creating a log of parameters transmitted by the post, system, notifications about suspicious events occurring on the site, and, finally, permission to run only scripts with a specific prefix in the name so that no other script such as template.php or wso2.php is launched.
')
What you need to keep in mind and what can be done to create a relatively secure site?
Should I put files of different types in separate folders?
A modern website created in PHP usually has a fairly extensive file structure. It definitely has executable scripts, modules or classes that are included with the include / require instruction, .css and .js files, and page cache. These files for simplicity and restrict.
I think the question asked in the subtitle, I will answer in the affirmative and it is very useful. Thus, for example, PHP include files are not intended to request them for processing by the server and output to the browser. In folders of this type, we have a special .htaccess file in which we prohibit anyone from accessing anything.
Deny from all In folders with .css and .js files, we cannot afford this, but in these folders we can restrict access by type, which is not bad either. The following is a ban on access to any files except files with the extension .js
Deny from all <FilesMatch "\.js$"> Allow from all </FilesMatch> It is worth noting that, in my experience, such a restriction practically does not affect the real security of the site and is, so to speak, only one tick in the general list of tasks. I myself do not use these methods, and this will be discussed below. But, on the other hand, effort is also required for this, so why not? Again, if some crazy robot acts against you, he will shove like a tractor and spoil everything. If you know that in the folder you only have files with certain extensions, it will be easier to detect a malicious newcomer.
Personally, I went a little further. My .css and .js files are compressed and cached, so the folders where the sources are located can be closed from everyone in a row. The requested caches themselves are in a rather deeply buried folder where the robot may not reach. By the way, I have only one executable script for the whole site. But more on that later.
Should I call folders in a non-standard way?
Here, by the way, is a good method to really improve the security of your site. The fact is that a malicious robot searches for folders on the site with certain names. The same applies to files. Therefore, as one of the measures to increase security, this is changing the names of folders and files to something non-standard. It is worth inventing something of your own and give the names at least prefixes. Prefixes definitely help from robots. If you want to try to make it difficult and manual hacking, then I advise you to go ahead and give the folders and main files their own names (Peter, Masha, etc.). Not many young hackers will figure out where you are lying. Although the hackers involved in burglary of boredom, it is not known what kind of mess can be in my head. But there is definitely a chance! The main thing is not to get confused. Also a considerable chance.
The config.php file , which contains the password of access to the database in open form
This is what I can not understand. There is a file that everyone knows what is called, and in which in open form lies exactly what the hacker needs. Why is this done? This, in my opinion, is some sort of wrecking. I highly recommend encrypting the data for access to the database on all my websites and place them in a completely non-standard named file, which is barred from network access and is read-only. Of course, we need to work on optimizing the decryption speed, but this is also quite solvable. At least XOR is pretty fast (link to Vernama’s Cipher at the end of the article). The main thing is to have a key of good length and hide it better. You can create a really confusing and very efficient decryption algorithm and make the hacker spend many hours on your site before they find the key and the algorithm for using it. You see malicious activity in time, thanks to your own logging-notification system, stop the activity of the attacker and change keys, passwords, turnout and so on. Therefore, downloading your scripts and dealing with them before losing consciousness can be unproductive for a hacker.
Security running php scripts
Very important topic. First of all, I’ll say that public hosting can really be opened and on your site, out of place, there will be a file with the conditional name template.php . Suppose that your wonderful system of logging and notifications after some time, for example, after 10 minutes, will determine the appearance of such a new file in such a folder and send you an email about it. It would seem great! But the shell may in 10 minutes of this on the site mess up that the site will be out for a few hours. Passed through. We know what we are talking about.
And this extremely significant security vulnerability of most engines sin. For example, make a file with any name, for example my_template.php , place in it
<?php echo 'hi!'; Next, place it in the root of your site on WordPress and call it (script). And it will probably work! Show you your hello!
This is the evolution of the methods of dealing with this evil. But I do not work on free (and paid) engines and it's easier for me!
At first, I made such an Url rewriting, in which only files with a certain prefix could be launched. It works as follows. On your site itself, without any suspicious calls, a malicious file appears without a prefix. You remain in ignorance. Next is an attempt to access this freshly mounted file. It does not have a prefix, and it does not start, and you immediately receive a letter about it without delay. Go to the site, see the shell, block the IP from which it was requested, write a letter to the hosting and raise all the employees on the ears. All, as it ends well. The link to the article, in which I described the problem in a “highly artistic and at the same time entertaining” form, and I will point out the solutions in the basement.
There is a replanting of the shell, passing through a more intelligent, but for us, a safer algorithm. It is known that access logs are stored on hosts for a limited time, most often a week. The attacker sends you a post-file on the site - a shell script and leaves it for a little more than a week. The logs in which the vulnerability was visible disappear and you cannot determine the vulnerability that was used. But in our case we, in a matter of minutes, receive an alert about the appearance of a stranger in the file structure of our site, so this seemingly sophisticated method of replanting is more preferable and desirable for us.
The described system did not last long and was successfully replaced. As a result, I came to the following scheme, which today I consider close to ideal.
We delete from .htaccess all URL-rewriting rules that were there and leave only one rule, which any file sends to one separate executable script of your site. It has a special, unlikely name, at least a prefix. This script REQUEST_URI understands what it came, does all sorts of seo-rewriting and decides which script to transfer control to. The control is not transferred by rewriting, of course, but by including the file with the require instruction. As a result, access on your site is allowed to everyone, but only one executable php script is executed. All other scripts are in a separate daddy and protected from requests over the network and can be protected by the instruction Deny from all . And may not be.
By the way, this scheme is used in some engines. But there everything is controlled by a mega-script index.php with 10 thousand lines and more, and this scheme is implemented not at all for the sake of security, but in order to make it easier to close the code from plundering.
Here is a rule in my .htaccess
RewriteCond %{REQUEST_URI} !^/sitemap\.xml$ RewriteCond %{REQUEST_URI} !^/favicon\.ico$ RewriteCond %{REQUEST_URI} !^/apple-touch-icon(?:\-precomposed)?\.png$ RewriteCond %{REQUEST_URI} !^/robots\.txt$ RewriteCond %{REQUEST_URI} !^/pref_dispatch\.php$ RewriteRule ^.*$ /pref_dispatch.php [L] Please note that we are missing absolutely certain files that we definitely have, and all requests without exception are translated into the dispatch script, and not php scripts alone. By the way, both robots.txt and sitemap.xml can be generated in the dispatcher and sent as a script. And you can pictures ...
What happens to the url, which does not pass the check in the dispatcher?
It is recorded in the " bad ur log ". I occasionally view this log in order to determine if I have any prohibited Uri, and whether it is necessary to make a redirect. The bad uri log has established itself as one of the most useful and entertaining tools in the admin area. We immediately see who is breaking, where is breaking, and that, in general, today is interesting for hackers. Of course, wp-admin and wp-config come first . There is something to think fans of free engines.
How to make so that bad uri gathered from all folders, and not just from the root of the site?
The log of bad uris includes uri of the form /very-bad-uri-script.php or / very-bad-uri-folder / . But if uri looks like / existent-folder / very-bad-uri-folder / , this uri may not be included in the log. In this case, at best, in the error log we will see a line of the type File does not exist: / existent-folder / very-uri-folder /
If we have disabled everything for everyone for the / existent-folder , then there will be an error like client denied by server configuration .
Both are not very convenient. The fact is that the call that enters the error log no longer falls into the access log, and we will not see any details. The most annoying thing is that we will not receive any letter in case of suspicious activity on the site. Such a nuisance is due to the fact that either the .htaccess file is missing from the / existent-folder or url rewriting is not included. To prevent this from happening, we firstly need to allow access to this folder for everyone, that is, erase our line Deny From All , and secondly, enable URL-rewriting.
RewriteEngine on RewriteBase / RewriteRule ^.*$ /badurl/ [L] Any requested file is sent straight to the bad uri log with all possible details. A line about this event goes to the access log and does not go to the error log. We receive a letter from the alert system, but, of course, if we programmed this functionality.
The above .htaccess is suitable for replacing the functionality " Deny from all ". In case we need to skip something, for example, js scripts or style sheet, then we need to either allow the request of certain file types, or, better, specify special names or prefixes for scripts. Well, or list the files to be skipped explicitly. But, I'm afraid, this is too hard in the sense of productivity of both the programmer and the server.
Attacks and blocking malicious IP
From time to time, but with surprising regularity, attacks occur on the site. Among these attacks, there are those, when from a certain IP go pinging of login pages and user registration, sending letters through the form and receiving announcements. This is a mail server. They work most often in a pair with “clean” IP, which are not used for attacks, but are used only for calling. To determine the essence of IP involved in spam, I myself use and strongly promote the site projecthoneypot.org .
It was extremely easy to fight such spammers. You just need to implement all these forms of Ajax and all. This alone is quite enough. For greater security, you can prohibit the php-backend call, if it does not come from the site.
Very voluminous traffic comes from questionable bots. Why doubtful? Because I do not know if these bots are useful for the site and why they go to my site and call urls that have fallen into disuse many years ago. In general, the appearance of a long time ago killed urls is in itself a compromising action for the bot. Such bots most often do not use the robots.txt file or use it in the opposite direction, that is, for them the existence of a list of prohibited addresses for viewing is a reason for them to break. However, these bots honestly tag themselves in user agents. Of these, I can name 199.192.207.146 with an agent
Mozilla / 5.0 (compatible; MJ12bot / v1.4.5; http://www.majestic12.co.uk/bot.php?+)or 185.53.44.90 with agent
Mozilla / 5.0 (compatible; XoviBot / 2.0; + http: //www.xovibot.net/)The IP in the examples above is real, but it is clear that these bots have more than one IP address.
There are also bots masquerading as good ones, but they seem not to be like that. For example, 176.31.182.56 with an agent
Mozilla / 5.0 (compatible; Googlebot / 2.1; + http: //www.google.com/bot.html)By the action of this IP on my site, I have very big doubts that this is really Googlebot.
Finally, I really do not like bingbot . He is extremely sloppy. He likes to break into the site for non-existent urles. It would be nothing if you do not think about where and in which bases he takes these URLs and why does he not remove them from the base? It is clear that I do not block this beast, despite my attitude towards it.
But there are attacks not aimed explicitly at spam. Requests can pour at a speed of a few pieces per second and are complete nonsense. Often corrupted and corrupted requests to the site itself, and often attacks on the engines, of which WP leads. A series of requests can usually be from 100 to 200 pieces in one series per day. Why break to the engines - of course, probably. Why should I try to get a site response for a warped, and often completely unreadable URL, I do not understand. But the fact is that a lot of requests with high speed slow down the site itself and its hosting neighbors and it is worth fighting with them.
By the way, what is an “unreadable URL”? And that's what!
http://-.ru/bulletin_board/ad_add/+++++++++++++++++++++++++++++++++++++Result:+%ED%E5+%ED%E0%F8%EB%EE%F1%FC+%F4%EE%F0%EC%FB+%E4%EB%FF+%F0%E0%E7%EC%E5%F9%E5%ED%E8%FF;+Result:+%ED%E5+%ED%E0%F8%EB%EE%F1%FC+%F4%EE%F0%EC%FB+%E4%EB%FF+%F0%E0%E7%EC%E5%F9%E5%ED%E8_cutted Please do not really try to access this site on my site, because in this case your IP will be marked dangerous and it will be affected in rights.
First, the url has a length of more than 255 characters and had to be cut off. Secondly, at least everything that comes after the word “Result:” and is decoded (windows 1251), but still represents nonsense. There is a suspicion that this XoviBot / 2.0 URL is requesting , and in comparatively large quantities and always the same.
But how to fight? And is it worth blocking everything? If this process is difficult to fight, maybe you can lead it, or somehow adapt to it differently?
I, unfortunately, do not know what is the circulation of bad IP in nature, and whether the bad can become good, and the good can become bad. Therefore, if I block, I do it in manual mode. If IP affiliation from a country where my Russian-language site is most likely not to be read, and the activity is too hard, I block these IPs. Leave the rest.
In my security system, there is not only a bad uri log, but also an IP log that ever caused a bad uri. Spam, dangerous, blocked and unblocked IP, as well as bots, are counted in this list.
When entering from a blocked IP, the client gets to a special page where he is invited to click on the button and unlock the IP. Button Ajax. The lock entry is automatically changed to “unlocked IP”. I have about 20 blocked IPs now. Was at least one of them unlocked by the user? Not. Was not. Often there are visits from the already blocked IP? No, vanishingly rare.
For all clients coming from IP, which are somehow marked, the additional processing of their requests is never performed. The presence of a mandatory backslash is not checked for them, they are not checked for the list of redirects, the conversion of SEO addresses does not work for them. If the requests are not completely good, then he immediately, without delay, displays a short farewell.
But lately I have been thinking about how to improve the blocking system. It might be useful, when detecting a series of a stream of requests from a certain IP, to block it for an hour. I am only afraid that I have already optimized the processing of bad uri in such a way that the blocking of IP and the output of the standard farewell are approximately the same in processing time.
Summary
The above are fairly simple steps that can seriously increase the security of any site. I have a question - why these simple things are not included, it seems, in one engine? Neither paid nor free?
Links
Source: https://habr.com/ru/post/264017/
All Articles