811
數據庫連接攻擊（類似DDoS）
標簽
PostgreSQL , authentication_timeout , DDoS , 認證SLOT
背景
客戶端請求連接數據庫後，會提示客戶端輸入用戶密碼，如果客戶端不輸入密碼，那麼數據庫服務端會在一個超時時間後，斷開連接。
也就是說，在服務端主動斷開連接前，這個連接實際上需要占用一個SLOT，也就是max_connection中的一個。
https://www.postgresql.org/docs/9.6/static/runtime-config-connection.html
authentication_timeout (integer)
Maximum time to complete client authentication, in seconds.
If a would-be client has not completed the authentication protocol in this much time, the server closes the connection.
This prevents hung clients from occupying a connection indefinitely.
The default is one minute (1m). This parameter can only be set in the postgresql.conf file or on the server command line.
另一個參數是客戶端連接超時參數，與攻擊沒什麼關係，我這裏隻是拿出來給大家了解一下。
https://www.postgresql.org/docs/9.6/static/libpq-connect.html
connect_timeout
Maximum wait for connection, in seconds (write as a decimal integer string).
Zero or not specified means wait indefinitely.
It is not recommended to use a timeout of less than 2 seconds.
攻擊者可以利用這個規則，並發的發起大量連接請求，但是不提供密碼，等待服務端的超時，這樣可以把max_connection的連接都占用掉。
現象
用戶如果連接被占滿，其他正常的請求發起的連接會遇到連接不足的報錯。
53300 too_many_connections
同時在pg_stat_activity中查詢到的count(*)小於實際的max_connection配置，
因為沒有認證成功的連接還不會出現在pg_stat_activity會話中。
防範措施
1、不要暴露監聽端口。
2、如果監聽端口一定要暴露，建議使用源IP鑒權，過濾非法IP，規避大部分攻擊。
3、配置pg_hba.conf，鑒權IP,DB,USER，規避大部分的攻擊。
4、配置用戶、DB級連接限製，即使被攻擊了，也可以保證一部分連接是可以被使用。除非攻擊者知道所有的數據庫名、用戶名，對其進行攻擊。否則就占用不掉所有連接。
相關問題
即使不是DDoS攻擊，用戶也可能遇到類似的問題。
例如在數據庫非常繁忙時，用戶請求響應變慢，用戶的應用程序堆積了很多請求，這些請求需要新建與數據庫的連接，由於本身數據庫非常繁忙響應變慢，加上爆炸性的高並發連接請求使得PG服務端的fork操作變慢，返回auth消息包在此之後（所以造成了類似現象）。
因此用戶如果遇到這樣的詭異問題，pg_stat_activity中顯示的連接數比max_connection小，但是確無法連接數據庫（報too_many_connections的錯誤），那麼可以看看是不出現了DDoS攻擊或者是數據庫繁忙導致。
最後更新：2017-07-03 21:32:17