How to arrange a DoS attack on the database server in one line
40 Mbps is good traffic for a DoS attack. It was so much that the incoming traffic suddenly increased to one of our servers. The site courageously kept. The time of the start of the burst of abnormally high traffic suspiciously exactly coincided with the time of laying out one major release, which suggested that we doSAM ourselves.
The situation was complicated by the fact that changes in the order of hundreds of different php files got into the release and it was very difficult to view the entire list of changes. tcpdump helped find out that traffic had grown to a PostgreSQL database server. The circle narrowed.
The first assumption was that limit was forgotten in one of the SQL queries and he chooses the entire data set instead of a single line. But how do you know what the request is? PgFouine came to the rescue . Analysis of the database server log for two minutes and here it is - the source of evil!
Here it is - a request without limit `and that has been executed thousands of times. But our source did not have this request! Nowhere, in a single file, he did not meet.
')
The source of the problem was hidden in the php-function pg_field_type , which just simply returned the symbolic name of the type column of the sample result.
The problem has its roots in at least 2005, but so far the official documentation has not added a remark that the php-pgsql library for accessing PostgreSQL makes an additional query to the DBMS choosing a complete list of more than 1000 data types.
Perhaps on a rarely visited website this does not affect the speed at all, but on a loaded project this can create a serious problem. We bypassed the problem by using its analog pg_field_type_oid instead of the function pg_field_type, which returns the internal oid of the data type instead of its symbolic name. Yes, it slightly worsened the readability of the code, but it unloaded the channel to the database server by 40 Mbps.
Perhaps if we used True FastCGI, we would not have this problem, but php was ready for this just a few months ago , and the problem has been around for about 6 years.
Check your source code for the pg_field_type keyword - perhaps you can greatly ease the hard life of your PostgreSQL server.
The situation was complicated by the fact that changes in the order of hundreds of different php files got into the release and it was very difficult to view the entire list of changes. tcpdump helped find out that traffic had grown to a PostgreSQL database server. The circle narrowed.
The first assumption was that limit was forgotten in one of the SQL queries and he chooses the entire data set instead of a single line. But how do you know what the request is? PgFouine came to the rescue . Analysis of the database server log for two minutes and here it is - the source of evil!
select oid,typname from pg_typeHere it is - a request without limit `and that has been executed thousands of times. But our source did not have this request! Nowhere, in a single file, he did not meet.
')
The source of the problem was hidden in the php-function pg_field_type , which just simply returned the symbolic name of the type column of the sample result.
The problem has its roots in at least 2005, but so far the official documentation has not added a remark that the php-pgsql library for accessing PostgreSQL makes an additional query to the DBMS choosing a complete list of more than 1000 data types.
Perhaps on a rarely visited website this does not affect the speed at all, but on a loaded project this can create a serious problem. We bypassed the problem by using its analog pg_field_type_oid instead of the function pg_field_type, which returns the internal oid of the data type instead of its symbolic name. Yes, it slightly worsened the readability of the code, but it unloaded the channel to the database server by 40 Mbps.
Perhaps if we used True FastCGI, we would not have this problem, but php was ready for this just a few months ago , and the problem has been around for about 6 years.
Check your source code for the pg_field_type keyword - perhaps you can greatly ease the hard life of your PostgreSQL server.
Source: https://habr.com/ru/post/110176/
All Articles