🛡️ CẨM NANG TOÀN TẬP: ĐIỀU TRA LOG, PHÁT HIỆN SCAN/DDoS VÀ THIẾT LẬP KHIÊN CHẮN BẢO VỆ VPS BẤT TỬ¶

========================================================================================================
                          CƠ CHẾ NGHẼN HÀNG ĐỢI KHI BỊ TCP SYN FLOOD
========================================================================================================

KẺ TẤN CÔNG (BOTNET)                                           MÁY CHỦ (LINUX VPS)
       │                                                                │
       │─── Gửi hàng loạt gói tin SYN (IP giả mạo/không phản hồi) ────►│
       │                                                                │ [Ghi nhận SYN-RECV]
       │◄── Server gửi lại SYN-ACK và đứng chờ ACK ─────────────────────│ [Chiếm 1 slot trong Backlog]
       │                                                                │
       │    (Kẻ tấn công CỐ TÌNH IM LẶNG, KHÔNG gửi lại ACK)            │
       │                                                                │
       ▼                                                                ▼
 Hàng đợi `tcp_max_syn_backlog` mặc định chỉ có **256 slots**.
 Khi botnet bắn dồn 70 - 100 kết nối không phản hồi:
   -> HÀNG ĐỢI 256 SLOTS BỊ TRÀN 100%!
   -> Kernel Linux buộc phải DROP (vứt bỏ) mọi gói SYN mới từ người dùng thật!
   -> Kết quả: Giáo viên, Quản lý vào web bị quay vòng vòng 15-30s rồi báo lỗi Timeout!
========================================================================================================

# 1. Đếm tổng số kết nối theo từng trạng thái TCP:
ss -ant | awk '{print $1}' | sort | uniq -c

# DẤU HIỆU BẤT THƯỜNG:
# • SYN-RECV > 15: Chắc chắn đang bị SYN Flood hoặc quét port.
# • TIME-WAIT > 500: Lượng request đóng mở liên tục quá nhanh chưa kịp thu hồi port.

# 2. Xem TOP 10 địa chỉ IP đang chiếm nhiều kết nối nhất vào máy chủ:
ss -nt '( sport = :80 or sport = :443 or sport = :22 or sport = :8000 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 10

# 3. Xem danh sách chi tiết các IP đang kẹt ở trạng thái SYN-RECV:
ss -ant state syn-recv

# 1. Xem 10 IP gửi nhiều request nhất trong 1000 request gần đây:
awk '{print $1}' /path/to/access.log | tail -n 1000 | sort | uniq -c | sort -nr | head -n 10

# 2. Xem các đường dẫn (URLs) đang bị cào quét tìm lỗ hổng nhiều nhất:
awk '{print $7}' /path/to/access.log | tail -n 1000 | sort | uniq -c | sort -nr | head -n 15
# (Nếu thấy /.env, /wp-login.php, /phpmyadmin, /shell.php -> Đang bị bot dò lỗ hổng)

# 3. Giám sát luồng truy cập theo thời gian thực (Real-time Stream):
tail -f /path/to/access.log

# 1. Kiểm tra trạng thái bắt trộm của Fail2ban trên cổng SSH:
fail2ban-client status sshd

# 2. Xem 20 lần gõ cửa đòi pass SSH bị từ chối gần nhất:
journalctl -u ssh -n 20 --no-pager | grep -i "failed"

# 3. Xem các IP bị Fail2ban chặn nhiều nhất:
grep "Ban " /var/log/fail2ban.log | tail -n 20

# 1. Bật SYN Cookies chống tràn RAM khi bị flood
net.ipv4.tcp_syncookies = 1

# 2. Tăng dung lượng hàng đợi kết nối nửa mở từ 256 lên 8192 (Gấp 32 lần)
net.ipv4.tcp_max_syn_backlog = 8192

# 3. Tăng sức chứa socket lắng nghe cho Nginx/Uvicorn
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 8192

# 4. Giảm số lần retry SYN-ACK từ 5 xuống 2 (nhả kết nối ma nhanh hơn)
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2

# 5. Thu hồi socket đóng (FIN-WAIT) sau 15s thay vì 60s
net.ipv4.tcp_fin_timeout = 15

# 6. Tái sử dụng kết nối TIME-WAIT an toàn
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_tw_buckets = 1440000

# Sửa trong file systemd: /etc/systemd/system/linux-manager.service
# Sửa: --host 0.0.0.0  ->  --host 127.0.0.1

# Reload và khởi động lại dịch vụ:
systemctl daemon-reload
systemctl restart linux-manager

# Kiểm tra xác nhận socket:
ss -tulpn | grep :8000
# Kết quả mong muốn: 127.0.0.1:8000 (Đã khóa chặt với Internet ngoài)

server {
    listen 80;
    listen 443 ssl;
    server_name professional.shin520.net;

    ssl_certificate     /etc/nginx/ssl/professional.shin520.net/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/professional.shin520.net/key.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

========================================================================================================
                                 MÔ HÌNH PHÒNG THỦ 5 LỚP TOÀN DIỆN CHO VPS
========================================================================================================

           KẺ TẤN CÔNG (DDoS / Botnet)                   NGƯỜI DÙNG THẬT (Quản lý, Giáo viên)
                        │                                                   │
                        ▼                                                   ▼
 ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐
 │ LỚP 1: ĐÁM MÂY BẢO VỆ CLOUDFLARE (WAF & CDN PROXY)                                                  │
 │  • Giấu sạch 100% IP thật của VPS (Kẻ tấn công không biết IP gốc).                                 │
 │  • Hứng trọn các đợt tấn công SYN Flood, Layer 7 HTTP Flood ở tầng biên ngoài biên giới Việt Nam.   │
 │  • WAF Rule: Bật Challenge Captcha với mọi IP nước ngoài truy cập vào /admin hoặc /manager.        │
 └──────────────────────────────────────────────────┬──────────────────────────────────────────────────┘
                                                    │ (Chỉ cho phép Traffic sạch đi qua)
                                                    ▼
 ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐
 │ LỚP 2: TƯỜNG LỬA HỆ ĐIỀU HÀNH (UFW / IPTABLES)                                                      │
 │  • Port 80, 443: Chỉ mở cho traffic hợp lệ.                                                        │
 │  • Port 8000, 8088, 8510: Khóa chặt, BẮT BUỘC bind 127.0.0.1 (chỉ đi qua Nginx reverse proxy).     │
 └──────────────────────────────────────────────────┬──────────────────────────────────────────────────┘
                                                    │
                                                    ▼
 ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐
 │ LỚP 3: BẢO VỆ CỔNG SSH (PORT 22 HARDENING)                                                          │
 │  • Đổi cổng mặc định từ 22 sang một port lạ (Ví dụ: 22022).                                         │
 │  • Tắt đăng nhập bằng mật khẩu (PasswordAuthentication no) -> BẮT BUỘC dùng SSH Key.                │
 │  • Giảm 100% các cuộc tấn công brute-force tự động.                                                 │
 └──────────────────────────────────────────────────┬──────────────────────────────────────────────────┘
                                                    │
                                                    ▼
 ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐
 │ LỚP 4: GIỚI HẠN TẦN SUẤT NGINX (RATE LIMITING & FAIL2BAN)                                           │
 │  • Giới hạn 1 IP tối đa 20 requests/giây (`limit_req_zone`).                                        │
 │  • Cấu hình Fail2ban quét log Nginx: IP nào scan file rác 5 lần liên tiếp -> Ban IP 24 giờ.         │
 └──────────────────────────────────────────────────┬──────────────────────────────────────────────────┘
                                                    │
                                                    ▼
 ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐
 │ LỚP 5: TỐI ƯU KERNEL LINUX (SYSCTL HARDENING)                                                       │
 │  • Hàng đợi `tcp_max_syn_backlog = 8192` nuốt trọn mọi đợt dồn tải.                                │
 │  • `tcp_syncookies = 1` bảo vệ RAM.                                                                 │
 │  • Máy chủ hoạt động êm ái, CPU < 5%, uptime liên tục không bao giờ nghẽn.                          │
 └─────────────────────────────────────────────────────────────────────────────────────────────────────┘
========================================================================================================

# Bước 1: Xem trạng thái tải tổng thể
uptime && free -m

# Bước 2: Xem có bị dội SYN flood không (nhìn cột SYN-RECV)
ss -ant | awk '{print $1}' | sort | uniq -c

# Bước 3: Xem ai đang dội nhiều kết nối nhất
ss -nt '( sport = :80 or sport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 5

# Bước 4: Kiểm tra nhanh log Nginx xem có request lạ không
tail -n 20 /home/trysysshin520net/try-sys.shin520.net/logs/access/access.log