Trong thế giới thực, điều này thật nực cười. Nhưng trong thế giới lập trình Web và API, tình huống này xảy ra thường xuyên đến mức nó trở thành “cơn đau đầu” kinh niên của giới bảo mật. Nó được gọi là IDOR (Insecure Direct Object Reference) hay BOLA (Broken Object Level Authorization).

Nếu bạn là một Backend Developer, và bạn tin rằng chỉ cần có Authentication (Đăng nhập) là hệ thống đã an toàn, thì bài viết này sẽ thay đổi tư duy lập trình của bạn. Chúng ta sẽ không chỉ nói về bề nổi, mà sẽ đi sâu vào bản chất kiến trúc của lỗi này.

1. Bản chất kỹ thuật của IDOR

IDOR (Insecure Direct Object Reference) không chỉ là một lỗi code, nó là một lỗi về thiết kế Logic (Business Logic Flaw).

Trong danh sách OWASP API Security Top 10, IDOR chính là bản chất của lỗ hổng số 1: API1: 2023 Broken Object Level Authorization (BOLA).

Hiểu sâu hơn, IDOR xảy ra khi 3 điều kiện sau hội tụ:

1. Direct Reference: Ứng dụng để lộ mã định danh nội bộ (Internal Identifier) của đối tượng (như Database Primary Key, Filename) trực tiếp ra ngoài URL hoặc Body request.
2. User Input: Ứng dụng tin tưởng và sử dụng trực tiếp đầu vào này để truy vấn dữ liệu.
3. Missing Authorization: Ứng dụng bỏ qua bước kiểm tra quyền truy cập tại thời điểm truy xuất đối tượng.

Sai lầm phổ biến: Nhiều Dev nhầm lẫn giữa Authentication (Bạn là ai?) và Authorization (Bạn được làm gì?). IDOR xảy ra khi bạn đã qua cửa Authentication, nhưng hệ thống quên kiểm tra Authorization ở mức độ đối tượng (Object-level).

2. Giải phẫu cơ chế tấn công

Hãy mổ xẻ một HTTP Request để thấy IDOR có thể lẩn trốn ở đâu. Không chỉ ở URL Parameter, nó có thể nằm ở Header hoặc Body.

Kịch bản: Ứng dụng Chat cho phép người dùng tải lại lịch sử chat.

Request bình thường:

GET /api/v1/messages/history HTTP/1.1
Host: example.com
Cookie: session_id=abc123xyz...
X-User-ID: 1005  <-- IDOR tiềm ẩn ở Header

1. Hacker quan sát: Thấy Header X-User-ID: 1005 được gửi kèm mỗi request.
2. Thử nghiệm: Hacker dùng Postman hoặc Burp Suite để chặn request, sửa X-User-ID thành 1006.
3. Kết quả: Server, thay vì lấy ID từ session an toàn (Server-side), lại tin tưởng lấy ID từ Header (Client-side) để query database SELECT * FROM messages WHERE user_id = 1006.
4. Hậu quả: Hacker đọc được toàn bộ tin nhắn của người dùng 1006.

IDOR có thể xuất hiện ở:

• URL Path: /users/100/profile
• Query Params: /invoices?id=100
• Body (JSON/XML): POST /api/change-password với body {"user_id": 100, "new_pass": "..."}

3. Tại sao IDOR lại là “Sát thủ thầm lặng”?

IDOR nguy hiểm vì tính “hợp lệ” về mặt cú pháp của nó.

• Vượt mặt WAF (Web Application Firewall): Các tường lửa thường chặn các ký tự lạ như ' OR 1=1 -- (SQL Injection) hay <script> (XSS). Nhưng với IDOR, payload chỉ là một con số: id=1006. Đối với WAF, đây là một con số hoàn toàn sạch và hợp lệ.
• Khó phát hiện bằng Automation Tool: Các máy quét (Scanner) không hiểu ngữ cảnh nghiệp vụ. Nếu máy quét gửi id=1006 và nhận về 200 OK, nó đánh dấu là “Thành công”. Nó không biết rằng dữ liệu trả về đó không thuộc về người đang gửi request. Chỉ có con người (Pentesters) hoặc Unit Test được viết kỹ lưỡng mới phát hiện ra.
• Hệ quả dây chuyền: IDOR thường là bước đệm để leo thang đặc quyền (Privilege Escalation), dẫn đến việc chiếm đoạt toàn bộ hệ thống (Account Takeover).

Sự nguy hiểm của IDOR nằm ở chỗ nó là một lỗ hổng logic, không phải lỗ hổng cú pháp. Các công cụ quét bảo mật tĩnh (SAST) truyền thống thường thất bại trong việc phát hiện IDOR vì chúng không thể hiểu ngữ cảnh “ai sở hữu cái gì” trong một ứng dụng cụ thể. Điều này dẫn đến một nghịch lý: trong khi các lỗ hổng kỹ thuật như SQL Injection đang giảm dần nhờ các framework hiện đại, IDOR vẫn tồn tại dai dẳng và chiếm tỷ lệ cao trong các chương trình săn lỗi nhận thưởng (Bug Bounty), đặc biệt là trong các lĩnh vực y tế, chính phủ và dịch vụ chuyên nghiệp.

4. Phân loại IDOR chuyên sâu.

4.1. Leo thang đặc quyền ngang (Horizontal Escalation)

Đây là dạng phổ biến nhất. Người dùng A truy cập dữ liệu của Người dùng B có cùng vai trò.

• Ví dụ: Xem đơn hàng, tải hóa đơn, xem ảnh riêng tư.
• Rủi ro: Rò rỉ thông tin cá nhân (PII Breach), vi phạm GDPR/CCPA.

4.2. Leo thang đặc quyền dọc (Vertical Escalation)

Người dùng thường (User) tìm cách gọi các API dành riêng cho Quản trị viên (Admin/Manager).

• Ví dụ:
  • Hacker tìm thấy API: POST /api/users/1001/roles.
  • Hacker gửi request với body: {"role": "ADMIN"}.
  • Nếu Backend không check xem “người gọi API này có phải là Super Admin không”, Hacker lập tức trở thành Admin.

4.3. IDOR trên File tĩnh (Static File IDOR)

Tên file thường dễ đoán.

• Ví dụ: https://example.com/uploads/receipts/receipt_001.pdf.
• Hacker viết script lặp từ 001 đến 9999 để tải toàn bộ hóa đơn của hệ thống.

5. Dẫn chứng thực tế: Khi “Ông lớn” cũng mắc sai lầm

5.1. McDonald’s & sự cố McHire (7/2025)

Link: https://research.cgu.edu/icdc/2025/07/01/mcdonalds-july-2025-breach/

Bối cảnh: Hệ thống bị ảnh hưởng là McHire, nền tảng tuyển dụng toàn cầu của McDonald’s, được vận hành bởi đối tác công nghệ bên thứ ba là Paradox.ai. Paradox.ai cung cấp giải pháp chatbot AI tên là “Olivia” để tự động hóa quy trình phỏng vấn, thu thập thông tin ứng viên và lên lịch làm việc. Sự phụ thuộc vào bên thứ ba này đã mở rộng bề mặt tấn công của McDonald’s ra ngoài hạ tầng kiểm soát trực tiếp của họ.   

Nguyên nhân chính
Sự cố xảy ra do kết hợp 2 lỗi nghiêm trọng:

1. Xác thực yếu (Weak Authentication)
   • Một tài khoản admin thử nghiệm của Paradox.ai dùng mật khẩu “123456”, không có MFA.
   • Tài khoản này tồn tại từ 2019, không bị vô hiệu hóa dù có quyền truy cập production.
2. Lỗ hổng IDOR (Missing Object Level Authorization)
   • API backend cho phép truy xuất hồ sơ ứng viên bằng applicant_id.
   • Không kiểm tra quyền truy cập → chỉ cần đổi ID là đọc được dữ liệu của bất kỳ ứng viên nào.
   • Từ 1 tài khoản → mở rộng ra 64 triệu hồ sơ toàn cầu.

Tác động

• Rò rỉ PII: tên, email, số điện thoại, địa chỉ nhà.
• Lộ dữ liệu nhạy cảm: log chat với AI (tính cách, sở thích, thông tin cá nhân).
• Lộ token phiên → có thể giả danh ứng viên.
• Nguy cơ cao cho social engineering, lừa đảo, chiếm tài khoản.

Sự kết hợp giữa quản lý tài khoản kém (tài khoản ma, không MFA) và thiếu kiểm soát quyền API (IDOR) tạo ra “cơn bão hoàn hảo” cho rò rỉ dữ liệu quy mô toàn cầu – một xu hướng cực kỳ đáng báo động trong năm 2025

5.2. Mozilla Firefox Accounts – Lỗ hổng xóa tài khoản (5/2025)

Link: https://hackerone.com/reports/3154983

Bản chất sự cố

• Lỗ hổng IDOR nghiêm trọng trong API xóa tài khoản (/v1/account/destroy).
• Cho phép xóa vĩnh viễn tài khoản người khác mà không cần tương tác từ nạn nhân (zero-click).
• Ảnh hưởng trực tiếp đến Integrity (toàn vẹn) và Availability (sẵn sàng) của dữ liệu.

Nguyên nhân kỹ thuật

• Lỗi Session Misbinding: backend không kiểm tra phiên làm việc có khớp với tài khoản bị xóa hay không.
• API tin vào payload JSON (email, authPW) thay vì session của người gửi request.
• Đây là dạng IDOR ghi/xóa, nguy hiểm hơn IDOR đọc dữ liệu.

Kịch bản khai thác

1. Kẻ tấn công tạo tài khoản Firefox, đăng nhập bằng SSO (Google).
2. Chặn request xóa tài khoản của chính mình.
3. Đổi email trong payload thành email nạn nhân (cũng dùng SSO, chưa set mật khẩu).
4. Gửi request → hệ thống xóa tài khoản nạn nhân.

Tác động

• Mất vĩnh viễn dữ liệu: mật khẩu đã lưu, lịch sử duyệt web, tab, sync data.
• Không thể khôi phục, không cần nạn nhân click hay xác nhận.
• Được đánh giá Critical trên HackerOne.

Bài học cốt lõi: IDOR không chỉ gây rò rỉ dữ liệu (read) mà còn có thể phá hủy dữ liệu (write/delete) nếu backend không ràng buộc chặt chẽ giữa session và đối tượng tài nguyên.

5.3. GitLab – Lỗ hổng Machine Learning Model Registry (2024–2025)

Link: https://hackerone.com/reports/2528293

Bối cảnh

• GitLab triển khai Machine Learning Model Registry để quản lý phiên bản mô hình AI.
• Lỗ hổng được báo cáo từ 5/2024, vá và công bố kéo dài sang 2025, cho thấy độ phức tạp của bảo mật trên nền tảng lớn.
• Sự cố ảnh hưởng trực tiếp đến tài sản trí tuệ AI (model weights, biases).

Nguyên nhân kỹ thuật

• GitLab dùng ID tịnh tiến (1,2,3,…) cho model_id thay vì UUID ngẫu nhiên.
• API tải/xem mô hình không kiểm tra quyền truy cập dự án (Missing Object Level Authorization).
• Đây là IDOR điển hình + thiết kế API kém an toàn.

Cách khai thác

• Kẻ tấn công chỉ cần tài khoản GitLab miễn phí.
• Lặp ID từ 1 → hàng triệu để liệt kê và tải mô hình của dự án khác.
• Không cần brute-force, không cần quyền dự án.

Tác động

• Rò rỉ mô hình ML độc quyền của doanh nghiệp.
• Nguy cơ mất bí mật thương mại, thiệt hại kinh tế lớn trong bối cảnh AI là tài sản cốt lõi.
• Lỗ hổng có thể bị khai thác tự động, quy mô lớn (enumeration).

Bài học cốt lõi: Không dùng ID tịnh tiến cho API công khai. Nó biến IDOR từ lỗ hổng tiềm ẩn thành thảm họa có thể khai thác hàng loạt, đặc biệt nguy hiểm với tài sản AI.

6. Ngăn chặn IDOR hiệu quả (Best Practices)

Khi một tài khoản test có thể mở khóa 64 triệu hồ sơ, một email có thể xóa tài khoản người khác, và một con số tăng dần có thể làm bay cả mô hình AI, thì rõ ràng vấn đề không nằm ở “hacker quá giỏi” — mà ở chỗ chúng ta cần chặn IDOR cho đúng cách.

“Đừng bao giờ tin tưởng Client”. Dưới đây là chiến lược phòng thủ đa lớp (Defense in Depth).

Lớp 1: Kiểm soát truy cập tại tầng Data (Data-Layer Authorization)

Đây là chốt chặn cuối cùng và quan trọng nhất. Mọi câu lệnh truy vấn liên quan đến dữ liệu người dùng phải kèm theo điều kiện về chủ sở hữu.

❌ Code rủi ro (Spring Data JPA):

// Controller
public Order getOrder(@PathVariable Long id) {
    return orderRepo.findById(id); // Chỉ tìm theo ID đơn hàng
}

✅ Code an toàn (Repository Pattern):

// Repository
// Luôn gắn kèm userId vào câu query
@Query("SELECT o FROM Order o WHERE o.id = :id AND o.owner.id = :currentUserId")
Optional<Order> findByIdAndOwner(@Param("id") Long id, @Param("currentUserId") Long userId);

// Service Layer
public Order getOrder(Long id, User currentUser) {
    return orderRepo.findByIdAndOwner(id, currentUser.getId())
        .orElseThrow(() -> new ResourceNotFoundException("Order not found or access denied"));
}

Lớp 2: Kiểm soát truy cập tại tầng Controller (Method-Level Security)

Sử dụng các Annotation bảo mật của Framework (như Spring Security) để chặn ngay từ cửa vào.

✅ Ví dụ với Spring Security (@PreAuthorize):

@GetMapping("/invoices/{id}")
// SpEL: Chỉ cho phép nếu user hiện tại là chủ sở hữu của invoice có id này
@PreAuthorize("@securityService.isOwner(authentication, #id)") 
public Invoice getInvoice(@PathVariable Long id) {
    return invoiceRepo.findById(id);
}

Cách này giúp code business logic sạch hơn, tách biệt logic bảo mật ra khỏi logic nghiệp vụ.

Lớp 3: Làm khó Hacker bằng UUID (Obfuscation)

Thay vì dùng Auto-Increment Integer (1, 2, 3), hãy dùng UUID (Random String: a0eebc99-9c0b...) hoặc các thuật toán băm ID (như Hashids).

• Lợi ích: Chặn đứng tấn công kiểu liệt kê (Enumeration Attack). Hacker không thể viết vòng lặp for (i=0; i<1000; i++) để quét dữ liệu.
• Cảnh báo: UUID KHÔNG THỂ THAY THẾ được Lớp 1 và Lớp 2. Nếu hacker bằng cách nào đó biết được UUID của nạn nhân, IDOR vẫn xảy ra nếu thiếu Authorization check. UUID chỉ là “lớp sương mù”, không phải “bức tường thép”.

Lớp 4: Kiểm thử tự động (Automated Security Testing)

Đừng đợi Pentester tìm lỗi. Hãy viết Test Case cho IDOR.

• Unit Test: Tạo 2 user (Alice, Bob). Đăng nhập bằng Alice, cố gắng request dữ liệu ID của Bob. Assert rằng kết quả trả về phải là 403 Forbidden hoặc 404 Not Found.

7. Kết luận

IDOR không phải là một lỗi kỹ thuật phức tạp, nhưng nó phản ánh sự thiếu sót trong tư duy thiết kế hệ thống.

Hãy nhớ nguyên tắc vàng: Mọi request truy cập dữ liệu đều phải trả lời được hai câu hỏi:

1. Người dùng này là ai? (Authentication)
2. Dữ liệu này có phải của họ không? (Authorization)

Nếu thiếu câu hỏi số 2, chúng ta đang mở toang cánh cửa “phòng 102” cho bất kỳ ai cầm chìa khóa “phòng 101”.

The post IDOR – Lỗ hổng “ngây thơ” nhưng chí mạng trong kiến trúc phần mềm? appeared first on Tomoshare.

Yêu cầu
・Docker đã cài đặt
・Docker Compose đã cài đặt
・Quyền quản trị hệ thống
・Domain đã trỏ về IP server
・Port 80 và 443 mở và trỏ về server

Thiết lập Nginx Webserver với Let’s Encrypt trên Docker
Quy trình thiết lập gồm các bước sau:・Tạo Docker Compose file
・Cấu hình Nginx server
・Tạo script setup SSL
・Chạy Certbot client
・Tự động gia hạn certificate

Bước 1: Tạo cấu trúc thư mục và .env

Tạo các thư mục cần thiết trong dự án:

mkdir -p docker/nginx/etc/nginx/templates
mkdir -p docker/nginx/etc/nginx/conf
mkdir -p docker/nginx/certs

Cấu trúc thư mục:

docker/
└── nginx/
    ├── setup-ssl.sh
    ├── entrypoint.sh
    ├── etc/nginx/
    │   ├── nginx.conf
    │   ├── conf/
    │   └── templates/
    │       ├── default.conf.template
    │       ├── https.conf.template
    │       └── upstream.conf.template
    └── certs/              # Thư mục chứa certificates (gitignored)

File Structure
・entrypoint.sh: Script tự động generate nginx configs từ templates
・setup-ssl.sh: Script tạo SSL certificate trên host (chạy ngoài container)
・templates/: Nginx config templates
・https.conf.template: HTTPS config cho domain
・upstream.conf.template: PHP-FPM upstream config
・certs/: Thư mục chứa Let’s Encrypt certificates trên host (gitignored, mounted vào container)

Environment Variables

Bước 2: Tạo Dockerfile cho Nginx

Tạo file docker/Dockerfile với multi-stage build:

FROM nginx:1.28.0-alpine as nginx

WORKDIR /var/www/html
COPY docker/nginx/ /
COPY docker/nginx/entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chmod +x /usr/local/bin/entrypoint.sh

EXPOSE 80 443

ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]
CMD ["nginx", "-g", "daemon off;"]

Bước 3: Tạo Docker Compose file

Tạo file docker-compose.yml để chạy Nginx với HTTPS:

services:
  nginx:
    build:
      context: .
      dockerfile: docker/Dockerfile
      target: nginx
    environment:
      ENABLE_BASIC_AUTH: "${ENABLE_BASIC_AUTH-false}"
      PHP_FPM_HOST: app
      PHP_FPM_PORT: 9000
      ENABLE_HTTP_LOCALHOST: "false"
      ENABLE_HTTPS: "true"
      HTTPS_DOMAIN: "${HTTPS_DOMAIN-example.com}"
    ports:
      - "${DOCKER_NGINX_EXTERNAL_PORT-8000}:80"
      - "${DOCKER_NGINX_HTTPS_PORT-8443}:443"
    depends_on:
      - app
      - certbot
    volumes:
      - ".:/var/www/html"
      - "./docker/nginx/certs:/etc/letsencrypt"

  certbot:
    image: certbot/certbot:latest
    volumes:
      - "./docker/nginx/certs:/etc/letsencrypt"
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

  app:
    build:
      context: .
      dockerfile: docker/Dockerfile
      target: app
    volumes:
      - ".:/var/www/html"
    environment:
      PHP_OPCACHE_VALIDATE_TIMESTAMPS: 1
    command: ["development"]

Giải thích:
webserver (nginx): container Nginx với HTTPS
certbot: container tự động gia hạn certificate
app: container Laravel application
Volume ./docker/nginx/certs:/etc/letsencrypt: chia sẻ certificates giữa containers

Bước 4: Tạo file cấu hình Nginx

4.1. Tạo template HTTP (cho Let’s Encrypt validation)
Tạo file docker/nginx/etc/nginx/templates/default.conf.template:

server {
    listen 80;
    server_name _;

    root /var/www/html/public;
    index index.php;

    client_max_body_size 40m;

    access_log /dev/stdout;
    error_log /dev/stderr;

    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    proxy_hide_header X-Powered-By;

    charset utf-8;

    location = /health {
        return 200 'OK!';
        add_header Content-Type text/plain;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    location / {
        auth_basic $basic_auth;
        auth_basic_user_file /etc/nginx/.htpasswd;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        set $path_info $fastcgi_path_info;
        fastcgi_index index.php;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        fastcgi_pass php-fpm;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Lưu ý: Block location ~ /\.(?!well-known).* chặn các file ẩn nhưng cho phép .well-known để Let’s Encrypt validate.

4.2. Tạo template HTTPS
Tạo file docker/nginx/etc/nginx/templates/https.conf.template:

# HTTPS server for ${HTTPS_DOMAIN}
server {
    listen 443 ssl;
    http2 on;
    server_name ${HTTPS_DOMAIN};

    root /var/www/html/public;
    index index.php;

    # SSL configuration
    ssl_certificate /etc/letsencrypt/live/${HTTPS_DOMAIN}/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/${HTTPS_DOMAIN}/privkey.pem;

    client_max_body_size 40m;

    access_log /dev/stdout;
    error_log /dev/stderr;

    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    proxy_hide_header X-Powered-By;

    charset utf-8;

    location = /health {
        return 200 'OK!';
        add_header Content-Type text/plain;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    location / {
        auth_basic $basic_auth;
        auth_basic_user_file /etc/nginx/.htpasswd;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        set $path_info $fastcgi_path_info;
        fastcgi_index index.php;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        fastcgi_pass php-fpm;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

# Redirect HTTP to HTTPS for ${HTTPS_DOMAIN}
server {
    listen 80;
    server_name ${HTTPS_DOMAIN};

    location / {
        return 301 https://$host$request_uri;
    }
}

Giải thích:
Server block đầu: HTTPS trên port 443 với HTTP/2
Server block thứ hai: redirect HTTP → HTTPS
Security headers: HSTS, X-Frame-Options, X-Content-Type-Options

Bước 5: Tạo Entrypoint script

Tạo file docker/nginx/entrypoint.sh để tự động generate config từ template:

#!/bin/sh
set -e

# Set BASIC_AUTH_VALUE based on ENABLE_BASIC_AUTH
if [ "$ENABLE_BASIC_AUTH" = "true" ]; then
    export BASIC_AUTH_VALUE="Administrator's Area"
else
    export BASIC_AUTH_VALUE="off"
fi

# Generate map config from template
envsubst '$$BASIC_AUTH_VALUE' < /etc/nginx/templates/map.conf.template > /etc/nginx/conf.d/map.conf

# Generate upstream config
envsubst '$$PHP_FPM_HOST $$PHP_FPM_PORT' < /etc/nginx/templates/upstream.conf.template > /etc/nginx/conf.d/upstream.conf

# Generate nginx configs from templates
if [ "$ENABLE_HTTP_LOCALHOST" = "true" ]; then
    envsubst '$$PHP_FPM_HOST $$PHP_FPM_PORT' < /etc/nginx/templates/localhost.conf.template > /etc/nginx/conf.d/server-localhost.conf
fi

# Handle HTTPS setup
if [ "$ENABLE_HTTPS" = "true" ] && [ -n "$HTTPS_DOMAIN" ]; then
    # Create directories if they don't exist
    mkdir -p /etc/letsencrypt/live/${HTTPS_DOMAIN}

    if [ -f "/etc/letsencrypt/live/${HTTPS_DOMAIN}/fullchain.pem" ]; then
        envsubst '$$PHP_FPM_HOST $$PHP_FPM_PORT $$HTTPS_DOMAIN' < /etc/nginx/templates/https.conf.template > /etc/nginx/conf.d/server-https.conf
    fi
fi

# Execute the main command
exec "$@"

Script này:
・Tạo config từ template dựa trên biến môi trường
・Chỉ tạo HTTPS config nếu certificate tồn tại
・Dùng envsubst để thay thế biến

Bước 6: Tạo script setup SSL

Tạo file docker/nginx/setup-ssl.sh để tạo certificate trên host:

#!/bin/bash
set -e

# Get script directory and project root
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
PROJECT_ROOT="$(cd "${SCRIPT_DIR}/../.." && pwd)"

# Configuration
DOMAIN="${HTTPS_DOMAIN:-example.com}"
CERT_DIR="${PROJECT_ROOT}/docker/nginx/certs"

echo "Setting up SSL certificate for ${DOMAIN} on host..."
echo "Certificate will be saved to: ${CERT_DIR}"

# Create directories on host
mkdir -p "${CERT_DIR}"

# Check if certificate already exists
if [ -f "${CERT_DIR}/live/${DOMAIN}/fullchain.pem" ]; then
    echo "Certificate already exists for ${DOMAIN}"
    echo "Location: ${CERT_DIR}/live/${DOMAIN}/"
    exit 0
fi

cd "${PROJECT_ROOT}"

# Request certificate using docker (certificate saved on host, mounted into container)
echo "Requesting certificate (port 80 must be available)..."
docker run --rm \
    -v "${CERT_DIR}:/etc/letsencrypt" \
    -p 80:80 \
    certbot/certbot certonly \
    --standalone \
    --agree-tos \
    -d "${DOMAIN}"

echo ""
echo "Certificate created successfully on host!"
echo "Location: ${CERT_DIR}/live/${DOMAIN}/"
echo "Files: fullchain.pem, privkey.pem"
echo ""
echo "Certificate will be automatically mounted into nginx container."
echo "You can now run: docker-compose up -d"

Lưu ý: Script này chạy trên host, không trong container. Certificate được lưu trên host và mount vào container.

Bước 7: Chạy Certbot để lấy certificate

7.1. Test với dry-run (khuyến nghị)
Trước khi lấy certificate thật, test với --dry-run:

chmod +x docker/nginx/setup-ssl.sh

# Test với dry-run
docker run --rm \
    -v "$(pwd)/docker/nginx/certs:/etc/letsencrypt" \
    -p 80:80 \
    certbot/certbot certonly \
    --standalone \
    --dry-run \
    --agree-tos \
    -d your-domain.com

Lưu ý: Thay your-domain.com bằng domain của bạn.

7.2. Lấy certificate thật

Nếu dry-run thành công, chạy script để lấy certificate:

HTTPS_DOMAIN=your-domain.com ./docker/nginx/setup-ssl.sh

Hoặc dùng domain mặc định:

./docker/nginx/setup-ssl.sh

Quá trình:

1. Script kiểm tra certificate đã tồn tại chưa
2. Nếu chưa, chạy Certbot với –standalone mode
3. Certbot bind port 80 để Let’s Encrypt validate
4. Certificate được lưu tại ./docker/nginx/certs/live/your-domain.com/
   
   Lưu ý:
   ・Đảm bảo port 80 mở và trỏ về server.
   ・Nếu Nginx đang chạy trên port 80, tạm dừng trước khi chạy script.

Bước 8: Khởi động Docker Compose

Sau khi có certificate, khởi động services:

docker-compose up -d

Kiểm tra containers đang chạy:

docker-compose ps

Kiểm tra logs:

docker-compose logs nginx
docker-compose logs certbot

Bước 9: Kiểm tra HTTPS

Truy cập domain qua HTTPS:

curl -I https://your-domain.com:8443

Hoặc mở trình duyệt và truy cập: https://your-domain.com:8443

Bạn sẽ thấy:

・Certificate hợp lệ (không có cảnh báo)

・Tự động redirect HTTP → HTTPS

・Security headers được áp dụng

Bước 10: Gia hạn certificates

Let’s Encrypt certificates có thời hạn 90 ngày. Có 2 cách gia hạn:

10.1. Tự động gia hạn (đã cấu hình)

Service certbot trong docker-compose.yml tự động gia hạn mỗi 12 giờ:

certbot:
  image: certbot/certbot:latest
  volumes:
    - "./docker/nginx/certs:/etc/letsencrypt"
  entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

Certbot chỉ gia hạn khi certificate sắp hết hạn (trong vòng 30 ngày).

10.2. Gia hạn thủ công

Nếu cần gia hạn ngay:

docker run --rm \
    -v "$(pwd)/docker/nginx/certs:/etc/letsencrypt" \
    certbot/certbot renew

Hoặc trong container:

docker-compose exec certbot certbot renew

Sau khi gia hạn, reload Nginx để áp dụng certificate mới:

docker-compose exec nginx nginx -s reload

Hoặc restart container:

docker-compose restart nginx

Troubleshooting

Lỗi: “Port 80 is already in use”

Nguyên nhân: Port 80 đang được sử dụng bởi service khác.

Giải pháp:

# Kiểm tra process đang dùng port 80
sudo lsof -i :80

# Tạm dừng Nginx nếu đang chạy
docker-compose down

# Sau đó chạy lại setup-ssl.sh
./docker/nginx/setup-ssl.sh

Lỗi: “Failed to obtain certificate”

Nguyên nhân:
・Domain chưa trỏ về IP server
・Port 80 bị firewall chặn
・Let’s Encrypt không thể truy cập domain

Giải pháp:

# Kiểm tra DNS
nslookup your-domain.com

# Kiểm tra port 80
curl -I http://your-domain.com

# Kiểm tra firewall
sudo ufw status

Lỗi: “Nginx không load HTTPS config”

Nguyên nhân:
・Certificate chưa tồn tại
・Biến môi trường chưa đúng
・Volume mount sai

Giải pháp:

# Kiểm tra certificate
ls -la docker/nginx/certs/live/your-domain.com/

# Kiểm tra biến môi trường
docker-compose config

# Kiểm tra volume mount trong container
docker-compose exec nginx ls -la /etc/letsencrypt/live/

Tổng kết

Sau khi hoàn thành các bước trên, bạn đã:
・Thiết lập Nginx với HTTPS trên Docker
・Cấu hình Let’s Encrypt SSL/TLS certificates
・Tự động gia hạn certificates
・Redirect HTTP → HTTPS
・Áp dụng security headers

The post Hướng dẫn từng bước thiết lập Let’s Encrypt SSL/TLS cho Nginx trên Docker. appeared first on Tomoshare.

Mở đầu: Nỗi đau của Developer

Bạn đang phát triển một ứng dụng local, mọi thứ chạy mượt mà ở localhost:3000. Nhưng vấn đề nảy sinh khi:

• Bạn cần test Webhook từ các dịch vụ bên ngoài như ZaloPay, Stripe, Telegram (các bên này bắt buộc phải có HTTPS).
• Khách hàng muốn xem demo ngay lập tức, nhưng bạn chưa kịp deploy lên server.
• Bạn chán ngấy cảnh dùng Ngrok bản free vì tên miền bị đổi liên tục sau mỗi lần restart.

Giải pháp tối ưu nhất hiện nay chính là Cloudflare Tunnel.

1. Cloudflare Tunnel là gì?

Cloudflare Tunnel (trước đây là Argo Tunnel) là công cụ giúp bạn kết nối máy chủ local (hoặc máy ảo) ra internet mà không cần mở port (port forwarding) trên router.

Thay vì cho phép người lạ truy cập trực tiếp vào IP của bạn (rất rủi ro), Tunnel tạo một đường hầm bảo mật (outbound connection) từ máy bạn đến mạng lưới Cloudflare Edge. Từ đó, Cloudflare sẽ “public” ứng dụng của bạn ra ngoài bằng một tên miền HTTPS xịn xò.

Tại sao nên dùng Cloudflare Tunnel thay vì Ngrok?

2. Mô hình hoạt động

Hãy tưởng tượng luồng dữ liệu sẽ đi như sau:

User Browser -> Cloudflare Edge (HTTPS) -> Cloudflared (trên máy bạn) -> Localhost (3000, 8080…)

Bạn có thể chạy nhiều dịch vụ cùng lúc qua một đường hầm duy nhất:

• api.domain.com -> trỏ về localhost:3000
• admin.domain.com -> trỏ về localhost:8080

3. Chuẩn bị “đồ nghề”

Trước khi bắt đầu, bạn cần:

1. Tài khoản Cloudflare (đăng ký miễn phí).
2. Một tên miền (Domain) đã thêm vào Cloudflare.
   • Lưu ý: Freenom hiện tại không ổn định. Bạn nên mua các domain giá rẻ như .xyz, .dev, .click (chỉ khoảng 1-2$/năm) tại Namecheap hoặc Hostinger để dùng lâu dài.
3. Máy tính (Linux/Mac/Windows) để chạy tool.

4. Hướng dẫn triển khai chi tiết (Step-by-step)

Bước 1: Cài đặt cloudflared

Công cụ cloudflared là cầu nối giữa máy bạn và Cloudflare.

Trên Linux (Ubuntu/Debian):codeBash

curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o cloudflared.deb
sudo dpkg -i cloudflared.deb

Trên Windows:
Tải file .msi mới nhất từ GitHub chính chủ: Cloudflare Downloads
(Mở PowerShell dưới quyền Administrator để chạy các lệnh sau này).

Bước 2: Đăng nhập Cloudflare

Chạy lệnh sau để xác thực:codeBash

cloudflared tunnel login

Trình duyệt sẽ bật lên, bạn hãy chọn tên miền muốn sử dụng và bấm Authorize.

Bước 3: Tạo Tunnel

Đặt tên cho tunnel của bạn (ví dụ: my-local-server):codeBash

cloudflared tunnel create my-local-server

Sau khi tạo xong, Cloudflare sẽ sinh ra một Tunnel ID và file credentials (thường nằm ở ~/.cloudflared/).

Bước 4: Cấu hình định tuyến (Routing)

Đây là bước quan trọng nhất để map domain về localhost.
Tạo file config.yml trong thư mục ~/.cloudflared/ (hoặc cùng thư mục chạy tool) với nội dung:codeYaml

tunnel: <TUNNEL-NAME-HOẶC-ID>
credentials-file: /duong/dan/den/file/json/credentials.json

ingress:
  # Service 1: API Backend
  - hostname: api.namdevlabs.com
    service: http://localhost:3000

  # Service 2: Webhook test (ZaloPay, Stripe)
  - hostname: hook.namdevlabs.com
    service: http://localhost:5678

  # Service 3: Dashboard Admin
  - hostname: admin.namdevlabs.com
    service: http://localhost:8080

  # Rule cuối cùng bắt buộc: Trả về 404 nếu không khớp domain nào
  - service: http_status:404

Bước 5: Gắn DNS cho Subdomain

Bạn cần báo cho Cloudflare biết subdomain nào sẽ đi vào tunnel này.codeBash

# Cú pháp: cloudflared tunnel route dns <TUNNEL_NAME> <SUBDOMAIN>
cloudflared tunnel route dns my-local-server api.namdevlabs.com
cloudflared tunnel route dns my-local-server hook.namdevlabs.com

Lệnh này sẽ tự động tạo bản ghi CNAME trên Cloudflare Dashboard.

Bước 6: Kích hoạt Tunnel

Chạy tunnel với file config vừa tạo:codeBash

cloudflared tunnel run my-local-server

Mẹo: Nếu file config không nằm ở vị trí mặc định, dùng flag –config:
cloudflared tunnel –config /path/to/config.yml run

 Xong! Bây giờ bạn có thể truy cập https://api.namdevlabs.com và thấy nó trỏ thẳng về localhost:3000 của bạn với HTTPS xanh mượt.

5. Mẹo nâng cao cho Pro Developer

• Chạy ngầm (Service Mode): Để tunnel tự chạy khi khởi động máy (dành cho server home lab):codeBashsudo cloudflared service install sudo systemctl start cloudflared
• Bảo mật Zero Trust: Bạn sợ người lạ vào link demo? Vào Cloudflare Dashboard -> Zero Trust, bật tính năng yêu cầu đăng nhập bằng Email/Google trước khi truy cập vào domain.
• Debug lỗi: Nếu không truy cập được, hãy thêm flag –loglevel debug khi chạy để xem log chi tiết.

6. Tổng kết

Cloudflare Tunnel thực sự là một vũ khí lợi hại trong bộ công cụ của developer. Nó giúp bạn:

1. Tiết kiệm tiền: Không tốn phí server staging.
2. Tiết kiệm thời gian: Không cần deploy để demo.
3. An toàn: Không mở port, hạn chế tấn công DDoS.

Hy vọng bài viết giúp bạn giải quyết được bài toán đau đầu về Webhook và Demo. Chúc bạn code vui!

The post Đưa Localhost lên Internet miễn phí với Cloudflare Tunnel: Giải pháp thay thế Ngrok để Test Webhook & Demo App appeared first on Tomoshare.

Tại sao lại cần có proxy?

Thay vì kết nối trực tiếp tới server, client gửi request đến proxy để đánh giá và thực hiện những request đó.

• Bảo vệ quyền riêng tư: Proxy có thể được sử dụng để ẩn địa chỉ IP của client, giúp bảo vệ quyền riêng tư của người dùng khỏi các trang web và ứng dụng mà họ truy cập.
• Cân bằng tải (Load balancing): Proxy có thể được sử dụng để phân phối lưu lượng truy cập giữa nhiều server, giúp cải thiện hiệu suất và độ tin cậy của hệ thống.
• Bảo mật (Security): Proxy có thể được sử dụng để lọc lưu lượng truy cập, giúp ngăn chặn các cuộc tấn công mạng.
• Giảm chi phí: Proxy có thể được sử dụng để truy cập các tài nguyên từ xa, giúp giảm chi phí cho doanh nghiệp.

Có 2 loại proxy thường gặp đó là Forward proxy và Reverse proxy.

Forward proxy

• Là một client proxy, hoạt động thay mặt cho các thiết bị clients để gửi yêu cầu đến server.
• Nó nằm giữa clients và Internet, chuyển tiếp các requests của clients đến server thông qua Internet.

Use cases:

• Access control and content filtering: forward proxy kiểm tra các request có hợp lệ hay không để thực hiện forward hoặc block request.
• Log/Monitor request: quản lý và giám sát các request, thường được sử dụng trong môi trường công ty, trường học hay các tổ chức để kiểm soát việc truy cập Internet và bảo vệ khỏi các nội dung độc hại.
• User Privacy: forward proxy nằm giữa client và Internet, nó thay mặt client gửi request đến server qua Internet, có thể che dấu danh tính, địa chỉ IP và bảo vệ quyền riêng tư của người dùng thực.
• Cache responses: giảm độ trễ, tăng performance, tối ưu bandwidth, proxy cache lại response để trả về cho client trong các lần request tiếp theo thay vì request trực tiếp đến server.

Services:

• Squid
• Privoxy
• VPN services
• Cloudflare WARP

Reverse proxy

• Là một server proxy, nằm giữa Internet và server để xử lý các request thay mặt cho server.
• Chúng hoạt động như những servers bình thường. Reverse proxy chuyển tiếp request đến một hoặc nhiều server thật, kết quả sau đó trả về cho client, làm cho client không biết về những server thật nói trên.
• Reverse proxy được cài đặt trong một private network của một hoặc nhiều server, và tất cả lưu lượng truy cập đều phải đi qua proxy này.

Use cases:

• Load Balancing: cân bằng tải, phân bổ lượng truy cập trang web đến các máy chủ khác nhau, nhằm mục đích tăng throughput, giảm letancy, phục vụ số lượng client lớn hơn.
• Security: có thể coi reverse proxy là một Web Application Firewall (WAF), có nhiệm vụ chặn các truy cập khả nghi đến server, làm rate limit, một phần nào đó ngăn chặn tấn công DDoS.
• Cache responses: giảm độ trễ, tăng performance, tối ưu bandwidth, proxy cache lại response để trả về cho client trong các lần request tiếp theo thay vì request trực tiếp đến server.
• SSL encryption/decryption: reverse proxy có thể xử lý việc SSL termination (dừng), giải mã lưu lượng được mã hóa SSL từ client và chuyển tiếp nó đến máy chủ phụ trợ ở dạng không được mã hóa và ngược lại.

Services:

• Nginx
• Apache HTTP
• HAProxy
• CDN services

Điểm khác biệt chính

• Forward proxy:
  • Xử lý request từ client tới Internet.
  • Bảo vệ quyền riêng tư client và lọc nội dung.
• Reverse proxy:
  • Xử lý request từ Internet tới web servers.
  • Performance và security.

Nguồn: https://blog.bytebytego.com

Cảm ơn mọi người đã dành thời gian để đọc 🙇‍♂️

The post Forward proxy vs. Reverse proxy appeared first on Tomoshare.

1. Sử dụng kho lưu trữ Extra Packages for Enterprise Linux (EPEL):

Kho lưu trữ EPEL thường chứa các gói phần mềm bổ sung mà có thể không có sẵn trong các kho lưu trữ mặc định của Amazon Linux.

Đầu tiên, cài đặt kho lưu trữ EPEL:

sudo amazon-linux-extras install epel -y

2. Cài đặt Nginx:

Sau khi thêm kho lưu trữ EPEL, bạn có thể thử cài đặt Nginx bằng yum:

sudo yum install nginx -y

3. Khởi động và Kích hoạt Nginx:

Sau khi cài đặt, khởi động và kích hoạt dịch vụ Nginx:

sudo systemctl start nginx
sudo systemctl enable nginx

4. Kiểm tra Trạng thái Nginx:

Kiểm tra trạng thái của dịch vụ Nginx để xác nhận rằng nó đang chạy:

sudo systemctl status nginx

The post Cài đặt nginx trên Amazon Linux 2 (ECS Optimized) appeared first on Tomoshare.

Logrotate không chỉ giúp giảm kích thước file log một cách tự động mà còn có thể nén file để tiết kiệm không gian lưu trữ

Trong bài viết này, chúng ta sẽ tìm hiểu cách Logrotate được cấu hình để tự động nén và đẩy file lên S3, giúp bạn duy trì hệ thống được sạch sẽ và dễ quản lý hơn

Config

cd /etc/logrotate.d
touch rails_log_rotation

/home/ubuntu/path-to-deploy/current/log/production.log {
  daily
  dateext
  missingok
  rotate 90
  compress
  copytruncate
  lastaction
    aws s3 sync /home/ubuntu/path-to-deploy/current/log/ s3://path-to-bucket-name --exclude "*" --include "production.log*.gz" 2>&1
  endscript
  create 0644 root root
  su root root
}

home/ubuntu/path-to-deploy/current/log/production.log

• Link đến file log cần được quản lý bởi logrotate

daily

• Thực hiện xoay vòng log hàng ngày (được thực hiện bằng cron-job)

• Có nghĩa là file /home/ubuntu/path-to-deploy/current/log/production.log sẽ được làm mới mỗi ngày

• Check cron configuration

cd /etc/
ls | grep cron
cron.d
cron.daily
cron.hourly
cron.monthly
cron.weekly
crontab

dateext

• Thêm ngày vào filename của file log được xoay vòng để đảm bảo không bị trùng tên

missingok

• Cho phép logrotate bỏ qua nếu không tìm thấy file

rotate 90

• Giữ lại tối đa 90 file logs đã quay vòng
• Trong trường hợp này, có thể hiểu là cho phép lưu trữ file logs của 90 ngày gần nhất

compress

• Nén file log đã xoay vòng để tiết kiệm không gian lưu trữ

copytruncate

• Sao chép nội dung từ file cũ vào file mới, sau đó quay lại đầu file cũ và cắt bớt nó. Điều này giúp logrotate có thể xoay vòng mà không làm ảnh hưởng đến ứng dụng đang chạy

lastaction và endscript

• Bọc một đoạn code hoặc command được thực thi sau khi xoay vòng
• Trong trường hợp này, sử dụng AWS CLI để đồng bộ hóa các file logs đã xoay vòng với Amazon S3
• Loại trừ tất cả các files, chỉ bao gồm các file logs đã nén (production.log*.gz)
• Lưu ý
  • Bạn cần thay thế path-to-bucket-name bằng đường dẫn thích hợp đến S3 Bucket của bạn
  • EC2 phải tương tác được với S3 Bucket của bạn (có thể dùng aws configure hoặc attached IAM role đều được)

create 0644 root root

• Tạo một file log mới với quyền truy cập 0644 và chủ sở hữu là root

su root root

• Chuyển quyền sở hữu của file sang root sau khi tạo mới để đảm bảo an toàn và bảo mật

Tóm lại

• Config này giúp bạn quản lý và tự động xoay vòng file production.log mỗi ngày
• Nén file để tiết kiệm không gian và đồng thời sao chép lên Amazon S3 để lưu trữ

Manual test config

sudo logrotate -f /etc/logrotate.conf

The post Logrotate: Compress và push file log lên S3 appeared first on Tomoshare.

Swap không phải là sự thay thế cho bộ nhớ vật lý, nó là một phần của ổ đĩa, chính vì thế nó có thời gian truy cập chậm hơn bộ nhớ vật lý. Nếu hệ thống của bạn liên tục hết bộ nhớ, bạn nên bổ sung thêm RAM.

Các thao tác của mình được thực hiện trên Ubuntu 20.04

Tạo một Swap File

Tại sao chúng ta cần swap?

Có một tình huống hết sức cảm động như thế này. Bạn đang chạy một hệ thống săn voucher, trong các ngày bình thường thì lượng user truy cập không nhiều vì có voucher đâu mà săn 😛 

Bỗng dưng tới ngày 12.12, hay các ngày số đẹp mà tiki hay lazada hay dụ các bạn vào hệ thống để săn sale ấy, thì lượng truy cập tăng đột biến và đây là cấu hình server của bạn,

• ổ cứng: 40GB
• RAM: 2GB

khiến cho RAM server của bạn ngỏm củ tỏi dẫn tới việc sập hệ thống. Tới đây các bạn đã thấy cảm động chưa 😅

Nguyên nhân sập hệ thống thì đã rõ, là do hết dung lượng RAM, vậy làm sao để giải quyết vấn đề này?

• Mua thêm 2GB RAM → 4GB
• Tận dụng swap space → we are here, chúng ta sẽ mượn của ổ đĩa 2GB để tạo swap space, server sẽ sử dụng dung lượng mình đã swap này khi RAM đạt tới ngưỡng nhất định gọi là swappiness, mình sẽ nói ở phần dưới nhé.

Lưu ý đây là cách giải quyết tạm thời đề phòng server sập thôi nhé, đối với mình thì cách đầu tiên là ngon nhất, vì nó tận dụng tối đa sức mạnh của RAM

Trong bài này, mình sẽ tạo swap file 2GB. Nếu bạn muốn tạo nhiều hơn thì thay 2G thành con số bạn mong muốn.

1. Tạo swap file:

sudo fallocate -l 2G /swapfile

2. Set quyền cho file để user không nằm trong sudo không đọc và ghi file:

sudo chmod 600 /swapfile

3. Thiết lập swapfile dưới dạng vùng hoán đổi Linux:

sudo mkswap /swapfile

Output

Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
no label, UUID=fde7d2c8-06ea-400a-9027-fd731d8ab4c8

4. Sau khi tạo thì enable nó lên để sử dụng nhé

sudo swapon /swapfile

Để thực hiện thay đổi vĩnh viễn, hãy mở tệp /etc/fstab và thêm dòng sau:

/swapfile swap swap defaults 0 0

5. Xác nhận swap file đã được enable hay chưa:

sudo swapon --show

Output

NAME      TYPE      SIZE  USED PRIO
/swapfile file        2G    0B   -1

sudo free -h

Output

              total        used        free      shared  buff/cache   available
Mem:          981Mi        97Mi        68Mi       0.0Ki       814Mi       735Mi
Swap:         2.0Gi        10Mi       1.9Gi

Điều chỉnh giá trị swap – swappiness

Swappiness cho phép chúng ta thiết lập thông số để Linux sử dụng swap space, trên Ubuntu giá trị này mặc định là 60, bạn kiểm tra bằng lệnh dưới đây:

cat /proc/sys/vm/swappiness

Vậy làm thế nào để sửa?

sudo vim /etc/sysctl.conf
# Sau đó thêm cuối dòng
vm.swappiness=90

# Chạy lệnh dưới đây để reload lại config ở trên nhé
sudo sysctl -p /etc/sysctl.conf

Xoá swap file

sudo swapoff -v /swapfile
sudo rm /swapfile

💌 Lời cảm ơn

Cảm ơn các bạn đã theo dõi hết bài 😍. Trên đây là toàn bộ những gì chưa sẻ về Cách tạo swap file trên Ubuntu hy vọng nó giúp bạn phần nào trong hành trình code của bạn. 💪

The post Cách tạo swap file trên Ubuntu appeared first on Tomoshare.

Bài viết này sẽ hướng dẫn cho bạn các bước để cấu hình Basic Authentication bảo vệ server Nginx chạy trên môi trường CentOS và Ubuntu Server.

1. Cài đặt htpasswd

Tiến hành cài gói apache2-utils (Debian, Ubuntu) hoặc httpd-tools (CentOS)

Ubuntu, Debian:

sudo apt-get update 
sudo apt-get install apache2-utils 

CentOS:

sudo yum install httpd-tools 

2. Tạo Password File

Sau khi htpasswd được cài đặt, hãy tạo file mật khẩu bằng câu lệnh sau với flag -c nếu file “.htpasswd” chưa tồn tại:

sudo htpasswd -c /etc/nginx/.htpasswd username 

Thay thế “username” với tên đăng nhập bạn mong muốn. Sẽ có prompt chờ bạn nhập thông tin cho user trên

Lưu ý: nếu đã có file  /etc/nginx/.htpasswd rồi thì KHÔNG sử dụng flag -c

sudo htpasswd /etc/nginx/.htpasswd tomosia-admin

Nếu user tomosia-admin đã tồn tại thì lệnh trên sẽ cập nhật lại password

3. Cấu hình xác thực mật khẩu cho Nginx

Mở tệp cấu hình nginx của bạn, thường nó sẽ nằm ở đường dẫn /etc/nginx/nginx.conf hoặc cấu hình cho 1 site nhất định tại /etc/nginx/sites-available/example.com hoặc /etc/nginx/conf.d/example.com. Sau đó thêm dòng sau vào file cấu hình

auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.htpasswd;

Nếu muốn thiết lập basic auth cho toàn bộ website trên server thì cần thêm vào khối http

http {
   ...
   auth_basic "Restricted Access!"; 
   auth_basic_user_file /etc/nginx/.htpasswd;
   ...
}

Nếu muốn thiết lập cho một website hoặc domain nhất định cần thêm vào khối server tương ứng

server {
    ...
    auth_basic "Restricted Access!";
    auth_basic_user_file /etc/nginx/.htpasswd;
    ...
}

Nếu muốn thiết lập cho một location nhất định hãy thêm vào khối location

location /swagger-ui/ {
    ...
    auth_basic "Restricted Access!";
    auth_basic_user_file /etc/nginx/.htpasswd;
    ...
}

4. Restart Nginx

sudo service nginx reload #debian/ubuntu
sudo systemctl restart nginx #redhat/centos

5. Kiểm tra

The post Hướng dẫn cấu hình Basic Authentication trên Nginx appeared first on Tomoshare.