Trong điều kiện bị ảnh hưởng, kẻ tấn công từ Internet có thể gửi SMTP request được tạo đặc biệt và khiến máy chủ thực thi lệnh hệ điều hành dưới quyền user zimbra mà không cần tài khoản đăng nhập Zimbra hợp lệ.

Theo thông tin công bố, các máy chủ sử dụng phiên bản Zimbra trước 10.1.20, có cài đặt zimbra-snmp và bật SNMP notification cần được ưu tiên kiểm tra.

Zimbra đã phát hành bản vá trong phiên bản ZCS 10.1.20.

CVE-2026-73570 cũng đã được đưa vào danh mục Known Exploited Vulnerabilities – KEV của CISA, cho thấy lỗ hổng đã được ghi nhận khai thác thực tế.

Lưu ý: Bài viết tập trung vào việc kiểm tra, phát hiện dấu hiệu compromise và xử lý phòng thủ. Không bao gồm mã khai thác hoặc payload tấn công.

1. CVE-2026-73570 là gì?

CVE-2026-73570 thuộc nhóm lỗi:

CWE-78 – OS Command Injection

Lỗ hổng liên quan đến quá trình xử lý SNMP notification của Zimbra.

Dữ liệu không tin cậy có thể được xử lý không an toàn trước khi được chuyển tới cơ chế thực thi command, từ đó dẫn tới khả năng OS Command Injection.

Có thể hình dung chuỗi tấn công như sau:

Internet
    ↓
SMTP request được tạo đặc biệt
    ↓
Zimbra SMTP
    ↓
SNMP Notification
    ↓
OS Command Injection
    ↓
Thực thi command dưới user zimbra
    ↓
Payload / Persistence / Malware

Điểm nguy hiểm là attacker có thể khai thác từ xa mà không cần có mailbox hoặc tài khoản Zimbra hợp lệ.

Quyền thực thi ban đầu là user:

zimbra

không phải root.

Tuy nhiên đây vẫn là mức ảnh hưởng nghiêm trọng bởi user zimbra có quyền truy cập và vận hành nhiều thành phần quan trọng của hệ thống mail.

2. Máy chủ Zimbra nào có nguy cơ?

Nên ưu tiên kiểm tra nếu server đáp ứng các điều kiện:

• Đang chạy Zimbra Collaboration Suite.
• Phiên bản thấp hơn 10.1.20.
• Có package zimbra-snmp.
• SNMP notification đang được bật.
• SMTP server được public ra Internet.

3. Kiểm tra phiên bản Zimbra

Đăng nhập SSH vào server và chạy:

su - zimbra -c 'zmcontrol -v'

Hoặc:

su - zimbra
zmcontrol -v

Ví dụ:

Release 10.1.19.GA...

Nếu phiên bản thấp hơn:

10.1.20

thì nên tiếp tục kiểm tra SNMP và các dấu hiệu compromise.

4. Kiểm tra package SNMP

Với Ubuntu/Debian:

dpkg -l | grep -E 'zimbra-snmp|zimbra-net-snmp'

Với hệ điều hành sử dụng RPM:

rpm -qa | grep -E 'zimbra-snmp|zimbra-net-snmp'

Nếu server có package liên quan đến SNMP, tiếp tục kiểm tra service.

su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep -i snmp'

Nếu xuất hiện:

zimbraServiceEnabled: snmp

nghĩa là SNMP service đang được enable trên server.

5. Kiểm tra SNMP notification

Chạy:

su - zimbra -c 'zmlocalconfig snmp_notify'

Nếu kết quả:

snmp_notify = yes

thì SNMP notification đang được bật.

Trong trường hợp máy chủ đồng thời đang chạy phiên bản vulnerable, cần ưu tiên cập nhật bản vá.

6. Kiểm tra trạng thái dịch vụ Zimbra

Trước khi thực hiện thay đổi, nên lưu lại trạng thái hiện tại:

su - zimbra -c 'zmcontrol status'

Ví dụ:

Host mail.example.com
    amavis                  Running
    antispam                Running
    antivirus               Running
    ldap                    Running
    logger                  Running
    mailbox                 Running
    memcached               Running
    mta                     Running
    proxy                   Running
    snmp                    Running
    stats                   Running

Một điểm cần lưu ý:

Tất cả service đang Running không có nghĩa server chắc chắn chưa bị compromise.

Malware vẫn có thể hoạt động dưới user zimbra trong khi Zimbra hoạt động bình thường.

7. Kiểm tra dấu hiệu máy chủ đã bị khai thác

Server thuộc phiên bản vulnerable không đồng nghĩa chắc chắn đã bị hack.

Cần kiểm tra thêm các dấu hiệu bất thường.

7.1. Kiểm tra /dev/shm

Chạy:

ls -lah /dev/shm

Liệt kê chi tiết file:

find /dev/shm -maxdepth 1 -type f \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %s %p\n' | sort

/dev/shm là vùng shared memory dạng tmpfs.

Malware có thể sử dụng vị trí này để:

• Lưu binary tạm thời.
• Chạy payload.
• Tạo file persistence.
• Lưu script tải malware.

Tuy nhiên:

Không được kết luận file là malware chỉ vì file nằm trong /dev/shm.

Cần kiểm tra thêm:

• Owner.
• Process đang sử dụng.
• Hash.
• Thời gian tạo.
• Nội dung file.

7.2. Kiểm tra cron của user zimbra

Chạy:

crontab -l -u zimbra

Đặc biệt chú ý cron gọi file từ:

/dev/shm
/tmp
/var/tmp

Ví dụ dạng đáng nghi:

* * * * * /dev/shm/<random-file>

Nếu một file lạ được chạy mỗi phút, đây là dấu hiệu cần điều tra.

Backup cron trước khi thay đổi:

crontab -l -u zimbra \
> /root/zimbra-crontab-$(date +%F-%H%M%S).txt 2>&1

7.3. Kiểm tra process của user zimbra

Chạy:

ps -fu zimbra

Hoặc:

ps auxf | grep '[z]imbra'

Có thể kiểm tra executable thực tế:

for pid in $(pgrep -u zimbra); do
    echo "===== PID $pid ====="
    readlink -f /proc/$pid/exe 2>/dev/null
    tr '\0' ' ' < /proc/$pid/cmdline 2>/dev/null
    echo
done

Nếu process thuộc user zimbra đang chạy binary từ:

/dev/shm/
/tmp/
/var/tmp/

thì cần ưu tiên kiểm tra.

7.4. Kiểm tra kết nối mạng

Chạy:

ss -tunap

Hoặc:

lsof -nP -i -a -u zimbra

Cần lưu ý các outbound connection:

• Tới IP Internet không rõ nguồn gốc.
• Connection được duy trì liên tục.
• Port bất thường.
• Process không thuộc thành phần Zimbra quen thuộc.

7.5. Kiểm tra file mới được tạo bởi user zimbra

Có thể kiểm tra:

find /tmp /var/tmp /dev/shm \
-user zimbra -type f -mtime -30 -ls 2>/dev/null

Lệnh trên tìm các file thuộc user zimbra được thay đổi trong vòng 30 ngày gần nhất.

Không nên chạy:

find /

trên production server lớn nếu không cần thiết vì có thể tạo thêm I/O cho hệ thống.

8. Vì sao chỉ xóa file malware là chưa đủ?

Giả sử phát hiện file:

/dev/shm/<malware>

và chỉ thực hiện:

rm -f /dev/shm/<malware>

thì chưa thể kết luận server đã sạch.

File có thể được tạo lại bởi:

• Process vẫn đang chạy trong RAM.
• Cron persistence.
• Systemd timer.
• Systemd service.
• Webshell.
• Script khác.
• Máy chủ tiếp tục bị khai thác do chưa vá.

Quy trình đúng nên theo hướng:

Containment
      ↓
Thu thập evidence
      ↓
Xác định persistence
      ↓
Dừng malicious process
      ↓
Quarantine malware
      ↓
Patch Zimbra
      ↓
Kiểm tra lại hệ thống

9. Quy trình xử lý khi nghi ngờ server đã bị compromise

Đối với server production, không nên xóa file ngay khi phát hiện dấu hiệu bất thường.

Nên thu thập evidence trước.

Bước 1: Tạo thư mục lưu thông tin incident

TS=$(date +%Y%m%d_%H%M%S)
INC="/root/zimbra-incident-$TS"

mkdir -p "$INC"

Bước 2: Lưu danh sách process

ps auxf > "$INC/process.txt"

Bước 3: Lưu kết nối mạng

ss -tunap > "$INC/network.txt"

Bước 4: Lưu cron của user zimbra

crontab -l -u zimbra \
> "$INC/zimbra-crontab.txt" 2>&1

Bước 5: Lưu thông tin /dev/shm

ls -lah /dev/shm \
> "$INC/dev-shm.txt"

Bước 6: Lưu trạng thái Zimbra

su - zimbra -c 'zmcontrol status' \
> "$INC/zmcontrol-status.txt" 2>&1

Lưu version:

su - zimbra -c 'zmcontrol -v' \
> "$INC/zimbra-version.txt" 2>&1

10. Tạm thời tắt SNMP notification

Nếu chưa thể patch ngay, có thể cân nhắc disable SNMP notification để giảm vector tấn công.

Kiểm tra:

su - zimbra -c 'zmlocalconfig snmp_notify'

Tắt:

su - zimbra -c 'zmlocalconfig -e snmp_notify=no'

Kiểm tra lại:

su - zimbra -c 'zmlocalconfig snmp_notify'

Kết quả:

snmp_notify = no

Đây chỉ là giải pháp containment tạm thời.

Giải pháp chính vẫn là upgrade Zimbra lên phiên bản đã vá.

Nếu doanh nghiệp đang sử dụng SNMP để giám sát hệ thống thì cần lưu ý việc tắt SNMP notification có thể ảnh hưởng monitoring.

11. Xác định process sử dụng file nghi ngờ

Ví dụ:

lsof /dev/shm/<suspicious-file>

Hoặc:

fuser -v /dev/shm/<suspicious-file>

Kiểm tra hash:

sha256sum /dev/shm/<suspicious-file>

Kiểm tra metadata:

stat /dev/shm/<suspicious-file>

Nếu đã xác định process độc:

kill <PID>

Nếu process không dừng:

kill -9 <PID>

Không nên sử dụng pkill với pattern quá rộng vì có thể kill nhầm process Zimbra hợp lệ.

12. Kiểm tra persistence

Ngoài cron của user zimbra, cần kiểm tra thêm.

Systemd timer

systemctl list-timers --all

Systemd service

systemctl list-unit-files --type=service

Cron hệ thống

find /etc/cron* -type f -mtime -30 -ls 2>/dev/null

Cron spool

find /var/spool/cron -type f -mtime -30 -ls 2>/dev/null

Không xóa entry chỉ vì thấy lạ.

Cần xác minh xem entry có thuộc hệ thống hoặc phần mềm hợp lệ hay không.

13. Quarantine malware thay vì xóa ngay

Tạo thư mục quarantine:

QUA="/root/zimbra-quarantine-$(date +%Y%m%d_%H%M%S)"
mkdir -p "$QUA"

Copy evidence:

cp -a /dev/shm/<suspicious-file> "$INC/"

Di chuyển malware:

mv /dev/shm/<suspicious-file> "$QUA/"

Tính SHA256:

sha256sum "$QUA"/* \
> "$QUA/sha256.txt" 2>/dev/null

Sau đó có thể hạn chế quyền:

chmod -R 000 "$QUA"

Việc giữ lại hash và file giúp phục vụ:

• Điều tra incident.
• Đối chiếu IOC.
• Kiểm tra bằng antivirus.
• So sánh với các server khác.

14. Kiểm tra JSP/Webshell

Sau khi attacker có khả năng chạy command dưới user zimbra, không nên giả định /dev/shm là persistence duy nhất.

Một vị trí cần kiểm tra là Jetty webapps.

find /opt/zimbra/jetty/webapps \
     /opt/zimbra/jetty_base/webapps \
-type f \( -iname '*.jsp' -o -iname '*.jspx' \) \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %s %p\n' \
2>/dev/null | sort

Kiểm tra file được thay đổi gần đây:

find /opt/zimbra/jetty/webapps \
     /opt/zimbra/jetty_base/webapps \
-type f \( -iname '*.jsp' -o -iname '*.jspx' \) \
-mtime -30 -ls 2>/dev/null

Cần lưu ý:

File JSP mới không mặc định là webshell.

File có thể thuộc:

• Zimbra patch.
• Zimlet.
• Customization.
• Web application hợp lệ.

Cần kiểm tra nội dung, package, owner và hash trước khi xử lý.

15. Kiểm tra SSH persistence

Kiểm tra user hệ thống:

awk -F: '$3 >= 1000 {print $1,$3,$6,$7}' /etc/passwd

Kiểm tra SSH authorized keys:

find /root /home /opt/zimbra \
-name authorized_keys -type f \
-print -exec cat {} \; 2>/dev/null

Nếu phát hiện key lạ, cần đối chiếu với key quản trị hợp lệ trước khi xóa.

16. Upgrade Zimbra để vá CVE-2026-73570

Zimbra đã sửa lỗi liên quan trong:

Zimbra Collaboration 10.1.20

Nếu đang sử dụng phiên bản vulnerable, nên nâng lên:

10.1.20

hoặc phiên bản mới hơn đang được Zimbra hỗ trợ.

Trước khi upgrade nên:

• Backup mailbox.
• Backup database.
• Backup configuration.
• Kiểm tra dung lượng ổ đĩa.
• Kiểm tra repository.
• Đọc release notes.
• Xác nhận OS tương thích.
• Chuẩn bị phương án rollback.

Sau khi update:

su - zimbra -c 'zmcontrol -v'

Tiếp tục kiểm tra service:

su - zimbra -c 'zmcontrol status'

17. Kiểm tra sau khi xử lý

Kiểm tra /dev/shm

ls -lah /dev/shm

Kiểm tra cron

crontab -l -u zimbra

Kiểm tra process

ps -fu zimbra

Kiểm tra network

ss -tunap

Kiểm tra dịch vụ

su - zimbra -c 'zmcontrol status'

Kiểm tra version

su - zimbra -c 'zmcontrol -v'

Kiểm tra mail queue

/opt/zimbra/common/sbin/postqueue -p

Nếu malware hoặc file bất thường tiếp tục xuất hiện lại sau khi đã xóa thì rất có thể:

persistence vẫn còn

hoặc:

vector khai thác chưa được xử lý triệt để

18. Có mất dữ liệu email khi xử lý không?

Các thao tác:

• Disable SNMP notification.
• Dừng malicious process.
• Xóa persistence.
• Quarantine malware.
• Upgrade Zimbra.

không trực tiếp xóa mailbox.

Dữ liệu email Zimbra thường nằm tại:

/opt/zimbra/store/

Database nằm tại:

/opt/zimbra/db/data/

Do đó tuyệt đối không tự ý:

xóa
move
chỉnh sửa

các thư mục trên nếu chưa xác định database hoặc mailbox thực sự gặp sự cố.

19. Không recovery MySQL nếu database vẫn bình thường

CVE-2026-73570 là lỗi OS Command Injection.

Nó không đồng nghĩa database Zimbra chắc chắn đã bị lỗi.

Kiểm tra:

su - zimbra -c 'zmcontrol status'

Kiểm tra MySQL:

su - zimbra -c 'mysql.server status'

Kiểm tra port:

ss -ltnp | grep 7306

Kiểm tra log:

tail -n 200 /opt/zimbra/log/mysql_error.log

Nếu kết quả vẫn:

mysql is running
mailbox Running

và log không ghi nhận corruption hoặc lỗi database nghiêm trọng thì không nên thực hiện MySQL recovery.

Database recovery là một quy trình riêng và có rủi ro lớn hơn malware cleanup.

20. Những việc nên làm sau incident

Sau khi hoàn tất xử lý, nên tiếp tục:

1. Theo dõi CPU và Load Average.
2. Theo dõi /dev/shm.
3. Theo dõi cron user zimbra.
4. Kiểm tra outbound connection.
5. Kiểm tra mail queue.
6. Kiểm tra JSP/webshell.
7. Kiểm tra SSH key.
8. Kiểm tra systemd timer/service.
9. Kiểm tra file mới tạo bởi user zimbra.
10. Rotate credential nếu nghi ngờ bị lộ.
11. Đối chiếu IOC với các Zimbra server khác.
12. Kiểm tra log SMTP tại thời điểm nghi ngờ compromise.
13. Đảm bảo server đang chạy phiên bản Zimbra đã được vá.

21. CISA đã ghi nhận khai thác thực tế

CVE-2026-73570 đã được đưa vào danh mục:

Known Exploited Vulnerabilities – KEV

của CISA.

Điều đó có nghĩa đây không chỉ là một lỗ hổng tồn tại trên lý thuyết mà đã có bằng chứng được sử dụng trong các cuộc tấn công thực tế.

Vì vậy, đối với Zimbra server public ra Internet, việc kiểm tra và patch cần được ưu tiên.

Một điểm rất quan trọng:

zmcontrol status

có thể vẫn hiển thị:

mailbox Running
mta Running
proxy Running

trong khi process malware vẫn đang chạy dưới user zimbra.

Do đó không thể chỉ dựa vào việc dịch vụ đang Running để kết luận server an toàn.

22. Tóm tắt quy trình

1. Kiểm tra version Zimbra
        ↓
2. Kiểm tra package/config SNMP
        ↓
3. Kiểm tra /dev/shm
        ↓
4. Kiểm tra cron
        ↓
5. Kiểm tra process
        ↓
6. Kiểm tra network
        ↓
7. Thu thập evidence
        ↓
8. Disable SNMP notification tạm thời
        ↓
9. Dừng malicious process
        ↓
10. Loại bỏ persistence
        ↓
11. Quarantine malware
        ↓
12. Hunt JSP/Webshell/SSH persistence
        ↓
13. Upgrade Zimbra >= 10.1.20
        ↓
14. Kiểm tra service + mail queue
        ↓
15. Theo dõi dấu hiệu tái nhiễm

Kết luận

CVE-2026-73570 là lỗ hổng nghiêm trọng trong Zimbra Collaboration Suite liên quan đến SNMP notification.

Trong điều kiện vulnerable, attacker từ xa chưa xác thực có thể lợi dụng SMTP request được tạo đặc biệt để thực thi OS command dưới quyền user zimbra.

Các điều kiện cần đặc biệt lưu ý:

Zimbra < 10.1.20
+
zimbra-snmp
+
SNMP notification được bật

Nếu phát hiện server có dấu hiệu compromise, không nên chỉ:

rm malware

rồi kết luận hệ thống đã an toàn.

Quy trình đầy đủ cần bao gồm:

Containment
+
Evidence Collection
+
Process Analysis
+
Persistence Removal
+
Malware Quarantine
+
Patch
+
Verification

Quan trọng nhất vẫn là nâng cấp Zimbra lên phiên bản đã được vá và tiếp tục theo dõi server sau khi xử lý.

Nguồn tham khảo

• NIST National Vulnerability Database – CVE-2026-73570
• Zimbra Security Advisories
• Zimbra Collaboration 10.1.20 Release Notes
• CISA Known Exploited Vulnerabilities Catalog
• CERT Polska

Bài viết CVE-2026-73570: Lỗ hổng Zimbra SNMP RCE – Cách kiểm tra và xử lý đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

DNSSEC tại Tenten được cấu hình tùy theo nơi đăng ký tên miền và hệ thống Nameserver đang sử dụng. Trước khi thao tác, cần kiểm tra tên miền đã đăng ký dịch vụ DNSSEC hay chưa.

1. Kiểm tra và đăng ký dịch vụ DNSSEC

Đầu tiên, Quý khách đăng nhập trang quản lý tên miền Tenten và kiểm tra tên miền đã có dịch vụ DNSSEC hay chưa.

• Nếu chưa đăng ký DNSSEC, Quý khách cần mua hoặc đăng ký dịch vụ DNSSEC cho tên miền.
• Nếu đã đăng ký DNSSEC, tiếp tục kiểm tra Nameserver đang sử dụng để lựa chọn cách cấu hình phù hợp.

Sau khi dịch vụ được kích hoạt, truy cập mục Cấu hình DNSSEC của tên miền.

2. Tên miền Việt Nam và tên miền quốc tế

Tên miền Việt Nam như .vn, .com.vn và tên miền quốc tế như .com, .net, .org có cách cấu hình DNSSEC cơ bản giống nhau:

1. Đăng ký dịch vụ DNSSEC.
2. Kích hoạt DNSSEC tại nơi đang quản lý DNS.
3. Khai báo DS Record và KSK nếu sử dụng DNS bên thứ ba.
4. Chờ hệ thống đồng bộ.
5. Kiểm tra lại trạng thái DNSSEC.

Thời gian cập nhật có thể khác nhau tùy loại tên miền và hệ thống Registry quản lý.

3. Tên miền và DNS đều sử dụng tại Tenten

Áp dụng khi:

• Tên miền được đăng ký tại Tenten.
• Nameserver đang sử dụng là Nameserver Tenten.
• Các bản ghi DNS được quản lý tại Tenten.

Các bước thực hiện

1. Kiểm tra và đăng ký dịch vụ DNSSEC nếu chưa có.
2. Đăng nhập trang quản lý tên miền Tenten.
3. Chọn tên miền cần cấu hình.
4. Truy cập mục Cấu hình DNSSEC.
5. Nhấn Bật.
6. Chờ hệ thống Tenten tạo khóa và cập nhật trạng thái.
7. Kiểm tra lại sau khi hệ thống đồng bộ.

Trong trường hợp này, Quý khách không cần nhập DS Record và KSK thủ công. Hệ thống Tenten sẽ tự tạo và quản lý thông tin DNSSEC.

Sau khi kích hoạt, trạng thái có thể tạm thời hiển thị Chưa kích hoạt trong thời gian hệ thống đang đồng bộ.

4. Tên miền tại Tenten nhưng DNS sử dụng bên thứ ba

Áp dụng khi:

• Tên miền được đăng ký tại Tenten.
• Nameserver sử dụng Cloudflare hoặc máy chủ DNS riêng.
• DNSSEC được tạo tại nơi đang quản lý DNS.

Các bước thực hiện

1. Kiểm tra tên miền đã mua dịch vụ DNSSEC tại Tenten chưa.
2. Nếu chưa có, đăng ký dịch vụ DNSSEC.
3. Bật DNSSEC tại Cloudflare hoặc máy chủ DNS của khách hàng.
4. Lấy thông tin DNSSEC do bên thứ ba cung cấp, gồm:
   • Key Tag;
   • Algorithm;
   • Digest Type;
   • Digest;
   • KSK/Public Key.
5. Truy cập mục Cấu hình DNSSEC tại Tenten.
6. Chọn Upload DS, KSK.
7. Nhập thông tin DS và KSK do bên thứ ba cung cấp.
8. Nhấn Lưu.
9. Quay lại màn hình quản lý và nhấn Bật.
10. Chờ hệ thống đồng bộ và kiểm tra lại.

Ví dụ cấu hình Cloudflare

Cloudflare cung cấp:

Nhập tại Tenten:

DS 1

Key Tag: 2371
Digest Type: 2
Algorithm: 13
Digest: F7FA43336165E3B072A620797FFD5AFBD580F6FF52D89AD*****F0D2665D573

DS 2

Key Tag: 2371
Digest Type: 2
Algorithm: 13
Digest: F7FA43336165E3B072A620797FFD5AFBD580F6FF5******475427F0D2665D573

Thông tin KSK:

Flags: 257
Protocol: 3
Algorithm: 13
Public Key: Nhập đầy đủ Public Key do bên thứ ba cung cấp

Tenten là nơi tiếp nhận DS Record để cập nhật lên hệ thống quản lý tên miền. Cloudflare hoặc máy chủ DNS riêng là nơi tạo khóa và ký DNSSEC.

5. Tên miền ở nhà cung cấp khác có dùng DNSSEC Tenten được không?

Hiện phía tenten chưa hỗ trợ dùng DNS tenten nếu Quý khách dùng tên miền ở nhà cung cấp khác ạ.

6. Cách nhập DS Record trên hệ thống Tenten

Trường hợp chỉ có một DS Record

Hệ thống Tenten không cho phép để trống DS 2. Vì vậy, cần nhập cùng một DS Record vào cả DS 1 và DS 2.

Ví dụ:

DS 1

Key Tag: 2371
Digest Type: 2
Algorithm: 13
Digest: F7FA43336165E3B072A620797FFD5AFBD580F6FF52D89AD4*****0D2665D573

DS 2

Key Tag: 2371
Digest Type: 2
Algorithm: 13
Digest: F7FA43336165E3B072A620797FFD5AFBD580F6FF52D89*****27F0D2665D573

Hệ thống Tenten sẽ tự nhận diện hai DS giống nhau và xử lý theo một DS Record hợp lệ.

Trường hợp có hai DS Record

Nếu nhà cung cấp DNS cung cấp hai DS Record khác nhau:

DS 1: Nhập bản ghi DS thứ nhất
DS 2: Nhập bản ghi DS thứ hai

Không tự sửa hoặc trộn thông tin giữa hai DS.

Ví dụ cách tách bản ghi DS

Bản ghi đầy đủ:

tenmien.com. 3600 IN DS 2371 13 2 F7FA43336165E3B072A620797FFD5AFBD580F6FF52D*****75427F0D2665D573

Nhập tại Tenten:

Key Tag: 2371
Algorithm: 13
Digest Type: 2
Digest: F7FA43336165E3B072A620797FFD5AFBD580F6FF52D89A*****7F0D2665D573

Không nhập tên miền, TTL 3600 hoặc nội dung IN DS vào ô Digest.

7. Kiểm tra DNSSEC sau khi cấu hình

Sau khi lưu và bật DNSSEC, có thể kiểm tra bằng các công cụ:

• DNSViz;
• Verisign DNSSEC Debugger;
• Google Admin Toolbox Dig.

Hoặc sử dụng lệnh:

dig DS tenmien.com
dig DNSKEY tenmien.com
dig +dnssec tenmien.com

DNSSEC hoạt động đúng khi:

• Có DS Record;
• Có DNSKEY;
• DS khớp với khóa đang sử dụng;
• Không xuất hiện lỗi BOGUS.

8. Một số lưu ý

• Luôn kiểm tra tên miền đã đăng ký DNSSEC trước khi cấu hình.
• Xác định chính xác Nameserver đang thuộc Tenten hay bên thứ ba.
• Nếu dùng Cloudflare hoặc DNS riêng, phải lấy DS/KSK từ hệ thống đó.
• Nếu chỉ có một DS, phải nhập giống nhau vào cả DS 1 và DS 2.
• Nếu có hai DS, nhập đúng từng bản ghi tương ứng.
• Không tự sửa Key Tag, Algorithm, Digest Type, Digest hoặc Public Key.
• Không thay đổi Nameserver khi DNSSEC đang hoạt động.
• Không bật, tắt DNSSEC nhiều lần trong thời gian ngắn.
• Sau khi thao tác cần chờ hệ thống đồng bộ trước khi kiểm tra kết quả.

Trong trường hợp Quý khách thao tác không được có thể gửi email hỗ trợ đến hòm thư : kythuat@tenten.vn để được hỗ trợ.

Bài viết Hướng dẫn cấu hình DNSSEC cho tên miền tại Tenten đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.

1. Tải xuống source code WordPress:

– Các bạn truy cập vào đường dẫn https://wordpress.org/download/, sau đó tải xuống bản mới nhất về

– Nếu muốn sử dụng bản WordPress cũ hơn, các bạn chỉ cần gõ thêm thông tin phiên bản đó trên trang tìm kiếm là được.

2. Truy cập vào trang DirectAdmin và upload source code lên

– Vào File Manager

– Vào thư mục public_html

– Click chuột phải chọn Upload File

– Chọn source code WordPress và sau đó ấn Upload

– Khi upload xong file, ta tiến hành giải nén như ảnh dưới:

– Đây là tổng quan sau khi giải nén xong:

3. Tạo database cho website

– Ta cần tạo database để có thể cấu hình setting WordPress cho website ở bước sau, các bạn truy cập vào mục MySQL Management:

– Các bạn tìm phần Create Database

– Các bạn tạo tùy ý theo nhu cầu của bản thân để dễ nhớ

4. Cấu hình WordPress:

– Ở bước này khi truy cập vào tên miền các bạn sẽ thấy bước cấu hình:

– Các bạn tiếp tục làm tương tự với việc cấu hình WordPress ở mọi nền tảng khác.

Chúc các bạn thao tác thành công!

Bài viết Hướng dẫn cách upload source code WordPress trên DirectAdmin đã xuất hiện đầu tiên vào ngày Hướng dẫn TENTEN.