A Security Risk Related to Backups

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 一个关于备份的安全隐患

| username: MuFeng

Using BR for backup on the host where TiUP is deployed does not require any authentication information and directly starts the backup task.

I personally believe this is a significant security risk.

Examples of attack methods:

  1. Using the BR command to perform arbitrary backups, increasing the database’s meaningless load.
  2. Frequently initiating continuous database backups, causing unnecessary consumption of database space and potentially exhausting storage resources.
  3. Maliciously performing data recovery (by specifying incorrect backups on network storage, even correct ones can cause data loss).

PS: By default, all the above communications do not provide authentication and encryption methods. You can enable encrypted transmission for communication between components to ensure data and component security by reading the relevant content in the official documentation under [Reference Guide] → [Security Hardening] → [Enable Encrypted Transmission for Communication Between TiDB Components].

| username: 啦啦啦啦啦 | Original post link

Since you are already able to connect to the TiUP control machine, the entire cluster is already exposed, and even if you want to destroy the cluster, it can’t be stopped.

| username: liuis | Original post link

Makes sense.

| username: Kongdom | Original post link

:thinking: I thought of a situation where the BR command could initiate a backup operation to a cluster managed by another control machine. Because the command only needs to specify the PD node.

| username: MuFeng | Original post link

I deployed BR on an unrelated host, and it can actually back up.
This means that as long as it can communicate with PD, it can back up. :joy:

| username: MuFeng | Original post link

I have tried it. Any host that can communicate with PD can initiate a backup task by deploying BR on it.

| username: tidb菜鸟一只 | Original post link

Does BR not verify user passwords during backups? That is indeed a security risk.

| username: 啦啦啦啦啦 | Original post link

It should be possible to configure certificates.

| username: 我是咖啡哥 | Original post link

This doesn’t really count as a security risk, right? Oracle backups also don’t require a password. By default, it assumes that if you can log into the operating system, you are a trusted user.

| username: 啦啦啦啦啦 | Original post link

Try matching this one.

| username: MuFeng | Original post link

What you mentioned about Oracle is limited to local environments.

| username: MuFeng | Original post link

Do I need to enable these authentications on the PD server?

| username: xingzhenxiang | Original post link

Oracle can also be configured to require a password for login locally.

| username: 啦啦啦啦啦 | Original post link

Yes, SSL authentication should be enabled, but I haven’t used it before~

| username: MuFeng | Original post link

Is this what you’re referring to? 为 TiDB 组件间通信开启加密传输 | PingCAP 文档中心

| username: tidb菜鸟一只 | Original post link

Oracle remote access doesn’t work, it only works locally. However, if it’s local, you can directly use rm -rf *, and backups are no longer a security concern…

| username: 啦啦啦啦啦 | Original post link

Yes, that’s it.

| username: MuFeng | Original post link

Newcomer here, still learning the ropes.
Please excuse me, hahaha.

| username: dba-kit | Original post link

Actually, it’s not quite the same. The PD port is also bound to the dashboard. If you want to access it directly from the external network, you have to expose the PD port, which increases the attack surface.

| username: dba-kit | Original post link

Also, it’s not just BR; pd-ctl also lacks permission verification, which is even more dangerous.