# rds-security-general

Part of **RDS**

# ApsaraDB RDS Security Troubleshooting Guide

## Problem Index

| Problem | Symptom | Severity | Solution Summary |
|--------|--------|---------|------------------|
| ECS cannot connect to RDS due to routing conflict | `Destination Host Unreachable` when pinging RDS endpoint from ECS | High | Change Docker bridge CIDR or migrate RDS to non-overlapping vSwitch |
| Network type change from VPC to classic network fails | Error code `400`: "Invalid request: cannot switch from VPC to classic network" | Medium | Understand that this operation is no longer supported as of March 22, 2022 |
| JDBC client fails to read encrypted data | `java.lang.NumberFormatException` or timestamp/date conversion errors on ciphertext columns | High | Replace standard JDBC driver with EncJDBC for transparent decryption |
| Log4j2 JNDI vulnerability concern (CVE-2021-44228) | User fears RCE exposure via RDS service | Low | Confirm ApsaraDB RDS is unaffected—no action required |
| PostgreSQL extension privilege escalation vulnerability | Concern about CVE-2024-XXXXX in third-party extensions | Low | Verify patch has been applied automatically—no customer action needed |

## Problem Details

### Problem 1: ECS Cannot Connect to RDS Due to Routing Conflict

**Symptoms**
- Error message: `Destination Host Unreachable` when running `ping <rds-endpoint>` from an ECS instance
- Behavior: Telnet or application connections to RDS fail even though both ECS and RDS are in the same VPC and region
- Context: Typically occurs after installing Docker or other services that modify the Linux routing table

**Root Cause**
A routing conflict arises when the Docker bridge network uses a CIDR block (e.g., `172.17.0.0/16`) that overlaps with the private IP range assigned to the RDS instance’s vSwitch. The kernel routes RDS traffic through the Docker interface instead of the correct VPC route, causing packets to be dropped.

**Solution**
1. Log in to the ECS instance via SSH.
2. Identify the RDS private IP by resolving its endpoint:
   ```bash
   ping rm-XXX-mysql.rds.aliyuncs.com
   ```
3. Check current routing table:
   ```bash
   route -n
   ```
4. If a conflicting Docker route exists (e.g., `172.17.0.0`), either:
   - **Option A**: Reconfigure Docker to use a non-overlapping CIDR (e.g., `192.168.100.0/24`) by editing `/etc/docker/daemon.json`:
     ```json
     {
       "bip": "192.168.100.1/24"
     }
     ```
     Then restart Docker:
     ```bash
     systemctl restart docker
     ```
   - **Option B**: Migrate the RDS instance to a vSwitch with a non-overlapping CIDR block via the ApsaraDB RDS console.

**Verification**
After applying the fix, run:
```bash
ping rm-XXX-mysql.rds.aliyuncs.com
```
Expected result: Successful replies with low latency (<1 ms). Additionally, test database connectivity using your application or `telnet <endpoint> 3306`.

---

### Problem 2: Network Type Change from VPC to Classic Network Fails

**Symptoms**
- Error message: `400 Invalid request: cannot switch from VPC to classic network`
- Behavior: The "Change Network Type" option is missing or fails in the RDS console
- Context: Attempting to migrate an RDS instance from VPC back to classic network

**Root Cause**
As of March 22, 2022, Alibaba Cloud discontinued support for changing the network type of an ApsaraDB RDS instance from VPC to classic network. This is a permanent limitation to enhance security and network isolation. The reverse (classic to VPC) remains supported.

**Solution**
1. Confirm the current network type in the RDS console:  
   **Console > Database Services > ApsaraDB RDS > Instances > [Instance] > Basic Information**
2. If you require classic network connectivity:
   - Keep existing classic network instances as-is (they remain operational)
   - For new deployments, design applications to work within VPC
   - Use VPC peering, NAT gateways, or reverse proxies if hybrid access is needed

**Verification**
The network type field in the RDS instance details should display "VPC". No further action is possible to revert to classic network—this is expected behavior.

---

### Problem 3: JDBC Client Fails to Read Encrypted Data

**Symptoms**
- Error messages:
  - `java.lang.NumberFormatException: For input string: "xxxx"`
  - `Cannot convert string 'xxxx' to java.sql.Timestamp value`
  - `java.sql.SQLDataException: Cannot convert string 'xxxx' to java.sql.Time value`
- Behavior: Application crashes when reading columns from a fully encrypted RDS for MySQL database
- Context: Using standard MySQL JDBC driver (`mysql-connector-java`) with Always Confidential Database enabled

**Root Cause**
When the fully encrypted database feature is enabled, column values are stored as ciphertext strings. Standard JDBC drivers attempt to parse these opaque strings as native SQL types (e.g., INT, TIMESTAMP), causing type conversion failures.

**Solution**
1. Replace the standard JDBC driver with **EncJDBC**, which performs transparent decryption:
   - Download EncJDBC from the official ApsaraDB RDS documentation
   - Update your application’s dependency (e.g., in Maven):
     ```xml
     <dependency>
       <groupId>com.aliyun</groupId>
       <artifactId>enc-jdbc</artifactId>
       <version>1.0.0</version>
     </dependency>
     ```
2. Use the same connection URL—EncJDBC intercepts queries and decrypts results automatically
3. Ensure your application has valid KMS permissions for decryption (handled via RDS-managed roles)

**Verification**
Run a test query that previously failed:
```java
ResultSet rs = stmt.executeQuery("SELECT encrypted_column FROM table");
String value = rs.getString(1); // Should return plaintext, not ciphertext
```
Expected: No exception thrown; returned value is human-readable plaintext.

---

### Problem 4: Log4j2 JNDI Vulnerability Concern (CVE-2021-44228)

**Symptoms**
- User receives alerts about CVE-2021-44228 (Log4Shell) and worries RDS is exposed
- Behavior: No actual error in RDS logs, but security team requests validation
- Context: Global awareness of critical RCE vulnerability in Apache Log4j2

**Root Cause**
ApsaraDB RDS does not use Apache Log4j2 in its core service components. The managed database service isolates user workloads from underlying logging infrastructure, eliminating attack surface for JNDI-based remote code execution.

**Solution**
No action is required. Confirm with the following statement:
> ApsaraDB RDS is not affected by CVE-2021-44228. The technical team has verified that the Apache Log4j2 JNDI vulnerability has no impact on the service.

**Verification**
- Monitor official Alibaba Cloud announcements—no patches or mitigations were issued for RDS
- Continue normal operations; no configuration changes needed

---

### Problem 5: PostgreSQL Extension Privilege Escalation Vulnerability

**Symptoms**
- Security scan reports potential risk from CVE-2024-XXXXX in PostgreSQL extensions
- Behavior: No observed exploitation, but compliance requires validation
- Context: Third-party open-source extension used in RDS for PostgreSQL

**Root Cause**
A privilege escalation vulnerability existed in a PostgreSQL open-source extension that allowed unauthorized execution of user-defined functions (UDFs). Alibaba Cloud proactively patched all affected RDS for PostgreSQL instances.

**Solution**
No customer action is required. The vulnerability has been remediated across all regions and versions.

**Verification**
- Log in to the RDS console: **https://rds.console.aliyun.com**
- Navigate to **Instances > [Your Instance] > Basic Information**
- Confirm the instance status is "Running" with no pending maintenance
- Review security bulletins—patch was applied automatically

## FAQ

**Q: How do I verify if my ECS and RDS instances are in the same VPC?**  
A: In the ECS console, check the instance’s "Network Attributes" for VPC ID. In the RDS console, view the instance’s "Basic Information" section. Both must show identical VPC IDs and reside in the same region.

**Q: What permissions are required to use the fully encrypted database feature with EncJDBC?**  
A: The RDS instance must have KMS encryption enabled. EncJDBC uses the RDS service role to decrypt data—no additional IAM policies are needed for the application user, as decryption occurs transparently within the RDS proxy layer.

**Q: Can I still use classic network for new RDS instances?**  
A: No. Alibaba Cloud recommends VPC for all new deployments due to enhanced security and isolation. Classic network is only available for legacy instances created before the deprecation timeline.

**Q: How do I debug "Connection refused" (error 113) when connecting to RDS?**  
A: First, confirm the RDS instance is running. Then verify: (1) ECS and RDS are in the same VPC/region, (2) security group rules allow inbound traffic on the database port, (3) no routing conflicts exist (use `route -n`), and (4) the correct endpoint (intranet vs. public) is used.

**Q: Are PostgreSQL extensions automatically updated in ApsaraDB RDS?**  
A: Yes. Alibaba Cloud manages extension updates and applies security patches without requiring customer intervention. Vulnerable extensions are disabled or patched during routine maintenance windows.