CÁCH UPGRADE VMWARE VCENTER SERVER 8.0.U3.00000-8.0.U3.00300
Mục đích
Tình hình ransomware dạo này rất phức tạp với các lỗ hổng của Vmware vSphere mà đặc biệt là vCenter dễ khai thác lỗ hỏng và tấn công. Chúng ta cần rà soát update bản vá mới nhất của Vmware Esxi nhé.
Backup
Trước khi thực hiện lưu ý cần sao lưu toàn bộ cấu hình vCenter 8.0 trước khi thực hiện Upgarde nhé.
Kiểm tra dung lượng ổ cứng còn trống.
Backup Full VM VCSA, hoặc dùng backup build in của vCenter nhé
Cài xong vào đường dẫn C:\Program Files\Exchange DkimSigner
Sent to desktop cho dễ lần sau thao tác, chúng ta chạy file configuration.dkim.signer.exe
Lần đầu tiên init sẽ chọn ok load cấu hình mặc định
Chọn tab dkim settings
Có thể default hoặc chúng ta chọn Relaxed
Cấu hình Domain settings phần này quan trọng
Add-> phuongnguyenblog.com cần ký cho domain mail nào add domain đó. Lưu ý đây là ngữ cảnh domain của tôi. Còn các bạn add domain của các bạn.
Lần đầu khai báo thì Generate new key-> tạo key .pem
Khai báo select và khai báo DNS local để xác minh thành công nhé. Các bạn có thể khai báo select khác nhau miễn sau tạo DNS để nhận được select của DKIM là ok.
Save domain
Test dkim
Kiểm tra
Chọn vào dấu 3 chấm-> Show original
Chúng ta thấy 3 điều kiện điều pass nhé, SPF, DKIM, DMARC.
Nếu các bạn muốn báo cáo đẹp hơn thì dùng mxtools phân tích header email nhé.
Các nhà nghiên cứu tại Morphisec đã phát hiện ra chi tiết kỹ thuật quan trọng về lỗ hổng thực thi mã từ xa (RCE) không cần tương tác người dùng trong Microsoft Outlook, được định danh là CVE-2024-38021. Lỗ hổng này cho phép kẻ tấn công thực thi mã tùy ý mà không cần xác thực người dùng. Nó khai thác lỗ hổng trong cách Outlook xử lý các liên kết hình ảnh. Khác với CVE-2024-21413, CVE-2024-38021 bỏ qua bản vá ban đầu của Microsoft bằng cách tấn công phương thức mso30win32client!HrPmonFromUrl.
Phương thức này, chịu trách nhiệm phân tích cú pháp URL trong các thẻ hình ảnh, không đặt cờ BlockMkParseDisplayNameOnCurrentThread. Do đó, nó cho phép xử lý các composite monikers, dẫn đến việc gọi hàm MkParseDisplayName không an toàn.
Điều này có thể dẫn đến việc khai thác lỗ hổng bảo mật bằng cách lợi dụng quá trình phân tích các liên kết trong Outlook, gây ra nguy cơ thực thi mã độc từ xa mà không cần sự tương tác của người dùng. Cuộc tấn công liên quan đến việc chèn một composite moniker vào URL trong thẻ hình ảnh. Điều này giúp vượt qua các biện pháp bảo mật được áp dụng trong chức năng tạo liên kết, dẫn đến khả năng thực thi mã từ xa và rò rỉ thông tin đăng nhập NTLM cục bộ.
Microsoft’s Patch Microsoft’s patch for CVE-2024-38021 follows a similar approach to the previous vulnerability, utilizing the BlockMkParseDisplayNameOnCurrentThread flag in the HrPmonFromUrl function. This prevents the invocation of the vulnerable MkParseDisplayName function for composite monikers in image tag URLs.
Tuy nhiên, các nhà nghiên cứu đã phát hiện rằng việc sử dụng một file moniker đơn giản vẫn có thể dẫn đến rò rỉ thông tin đăng nhập NTLM cục bộ, cho thấy bản vá chưa hoàn toàn khắc phục tất cả các rủi ro bảo mật tiềm ẩn.
Microsoft đã đánh giá lỗ hổng này với mức độ nghiêm trọng “Important”, phân biệt giữa người gửi đáng tin cậy và không đáng tin cậy. Đối với người gửi đáng tin cậy, lỗ hổng này là zero-click, nghĩa là không cần tương tác từ người dùng, trong khi đối với người gửi không đáng tin cậy, yêu cầu người dùng phải thực hiện một lần nhấp chuột.
–Khuyến cáo– Cập nhật kịp thời tất cả bản vá các ứng dụng Microsoft Outlook và Office mới nhất. Triển khai các biện pháp bảo mật email mạnh mẽ, bao gồm tắt tính năng xem trước email tự động.
Training người dùng về những rủi ro khi mở email từ các nguồn không xác định.
CÁCH UPGRADE ESXI HOST TỪ 8.0U2-22380479- 8.0U2B-23305546
Check sync and uprade từ vCenter Lifecycle Manager
Từ lifecycle manager-> Action-> sync update
Check Update từ Cluster nếu có
Check-> recommended images
Chọn Validate
Chọn Vender là Dell Dell addon for PowerEdge Servers
Do máy chủ tôi đang chạy Dell nên chọn dell các bạn chạy gì chọn đúng loại Server nhé.
Chọn validate ->Save
Check
Image hardware compatibility is not verified in non-vSAN clusters
B3: Check Compliance
B4: Chọn vào Remediate All cho tất cả các Host
Lưu ý tới bước remediate host trong môi trường Cluster HA Vmware tạm thời chúng ta move hoặc migration tất cả VM sang host còn lại, DRS để chế độ DPM disable. VÌ Host phải vào maintance mode
Hoặc remediate từng host 1
Hiện chạy cluster vsphere HA có thể làm từng tự tuần con một
Reboot thành công đã upgrade host 172.16.1.2
Làm tương tự cho host còn lại 172.16.1.1
Move migration VM qua host 172.16.1.2 và đưa host về mode maintenance
Phương Nguyễn biên soạn
Chúc các bạn thành công trong công việc quản trị hệ thống Vmware Sphere.
Microsoft đã phát hành Bản cập nhật Hotfix (HU) cho phép hỗ trợ các vấn đề về chức năng và địa chỉ mới trong Bản cập nhật bảo mật (SU) tháng 3 năm 2024
Áp dụng phiên bản:
Exchange Server 2019 CU13 and CU14 Exchange Server 2016 CU23
Điểm mới bản HU
HU tháng 4 năm 2024 giới thiệu hỗ trợ Chứng chỉ elliptic curve cryptography (ECC) và xác thực Hybrid modem cho Outlook trên web và ECP.
Published calendars might not work with a “This calendar isn’t available” error after installing March 2024 SU
Microsoft vẫn đang tìm cách khắc phục một sự cố khác khiến việc in lịch trong OWA có thể không hoạt động trừ khi sử dụng phím tắt CTRL+P. Một số tính năng bản HU Exchange lần này
Ngày 13/02/2024 MS đang công bố tính khả dụng của Bản cập nhật tích lũy H1 2024 (CU) cho Exchange Server 2019 (hay còn gọi là CU14). CU14 bao gồm các bản sửa lỗi cho các sự cố được khách hàng báo cáo, thay đổi bảo mật và tất cả các Bản cập nhật bảo mật (SU) đã phát hành trước đó.
Cài đặt Bản cập nhật tích lũy ngay lập tức để giải quyết các vấn đề được tìm thấy trong Exchange Server 2019 và bảo vệ môi trường của bạn.
1. Với Exchange 2019 CU14 khi cài mặt định enable Extended Protection hoặc chúng ta không muốn bật thêm tham số /DoNotEnableEP or /DoNotEnableEPFEEWS trong quá trình setup
2. Hỗ trợ .NET Framework 4.8.1 trên Windows Server 2022
3. TLS 1.3 dự kiến EX2019CU15
4. Lưu ý sau phiên bản sẽ không hỗ trợ bản vá bảo mật trong tương lai: EX2019CU12, EX2016CU22.
CVE dưới đây được giải quyết bằng Bản cập nhật tích lũy:
CVE-2024-21410 – Microsoft Exchange Server nâng cao lỗ hổng đặc quyền
Xin lưu ý rằng CVE-2024-21410 cũng áp dụng cho Exchange Server 2016. Đối với các máy chủ Exchange 2016, hãy làm theo Cấu hình Bảo vệ Mở rộng Windows trong Máy chủ Trao đổi nếu Bảo vệ Mở rộng chưa được bật trong tổ chức của bạn
Lưu ý rằng Exchange Server 2013 KHÔNG được hỗ trợ và bạn phải nâng cấp lên Exchange Server 2019 hoặc Exchange Online càng sớm càng tốt
Lưu ý rằng Exchange Server 2013 KHÔNG được hỗ trợ và bạn phải nâng cấp lên Exchange Server 2019 hoặc Exchange Online càng sớm càng tốt.
P/s: Khuyến cáo Quản trị viên cần triển khai cập nhật trong môi trường Lab trước khi thực hiện triển khai update trong môi trường Production
Theo như thông báo của Gmail thì bắt đầu tháng 02 năm 2024 có 1 số đổi mới bảo mật gửi vào gmail
Quan trọng: Kể từ tháng 2 năm 2024, Gmail sẽ yêu cầu những người gửi từ 5.000 thư trở lên mỗi ngày đến các tài khoản Gmail phải làm các việc sau: Xác thực email gửi đi, tránh gửi email không mong muốn, đồng thời giúp người nhận dễ dàng huỷ đăng ký.
Các nguyên tắc trong bài viết này có thể giúp bạn gửi và chuyển thành công email đến các tài khoản Gmail cá nhân. Tài khoản Gmail cá nhân là tài khoản có đuôi là @gmail.com hoặc @googlemail.com.
Người gửi trên Google Workspace: Nếu bạn sử dụng Google Workspace để gửi số lượng lớn email thì phải tuân thủ theo chính sách Gmail của Google Workspace.
Nội dung cập nhật về các yêu cầu đối với người gửi
Điểm mới trong tháng 12/2023 Gmail đã cập nhật đối với người gửi bắt buộc phải dùng kết nối TLS để truyền email.
Yêu cầu đối với tất cả người gửi vào gmail
Kể từ ngày 1 tháng 2 năm 2024, tất cả những người gửi email đến các tài khoản Gmail đều phải đáp ứng các yêu cầu trong mục này.
Quan trọng: Nếu bạn gửi hơn 5.000 thư mỗi ngày đến các tài khoản Gmail, hãy tuân theo Các yêu cầu đối với việc gửi từ 5.000 email trở lên mỗi ngày.
Thiết lập phương thức xác thực email DKIM hoặc SPF cho miền của bạn.
Đảm bảo rằng địa chỉ IP hoặc miền gửi thư có bản ghi DNS chuyển tiếp và bản ghi DNS ngược hợp lệ, còn được gọi là bản ghi PTR (PTR record hay dân gian gọi là IP Reverse). Tìm hiểu thêm hướng dẫn tại đây (https://support.google.com/mail/answer/81126)
IP Adress: Địa chỉ IP gửi của bạn phải có bản ghi PTR. Bản ghi PTR xác minh rằng tên máy chủ gửi được liên kết với địa chỉ IP gửi. Mỗi địa chỉ IP phải liên kết với một tên máy chủ trong bản ghi PTR. Tên máy chủ trong bản ghi PTR phải có DNS chuyển tiếp tham chiếu đến địa chỉ IP gửi.
IP Sharing (Dạng sài chung host): Địa chỉ IP dùng chung (IP dùng chung) là địa chỉ IP được nhiều người gửi email sử dụng. Hoạt động của bất kỳ người gửi nào sử dụng địa chỉ IP dùng chung cũng sẽ ảnh hưởng đến danh tiếng của tất cả người gửi sử dụng IP dùng chung đó.
Danh tiếng xấu có thể ảnh hưởng đến tần suất gửi thư của bạn.
Nếu bạn sử dụng một IP dùng chung để gửi email, bạn cần:
Đảm bảo địa chỉ IP dùng chung đó không thuộc bất kỳ danh sách chặn nào trên Internet. Thư được gửi từ địa chỉ IP trong danh sách chặn sẽ có nhiều khả năng bị đánh dấu là thư rác.
Nếu bạn sử dụng một nhà cung cấp dịch vụ email cho IP dùng chung của mình, hãy sử dụng Công cụ Postmaster để giám sát danh tiếng của địa chỉ IP dùng chung.
Sử dụng kết nối TLS để truyền email. Để biết các bước thiết lập TLS trong Google Workspace. Xem hướng dẫn tại đây (https://support.google.com/a/answer/2520500)
Giữ cho tỷ lệ thư rác được báo cáo trong Công cụ Postmaster dưới 0,1% và đừng để tỷ lệ thư rác bằng hoặc cao hơn 0,3%. Xem hướng dẫn tại (https://gmail.com/postmaster). Phần này nên đăng ký và add domain của các bạn vào để giám sát
Rate dưới 0.1%, và không cao hơn 0.3% sẽ bị khoá ngay lập tức này gặp rồi Gmail block luôn domain gửi vào.
5. Định dạng thư theo Tiêu chuẩn định dạng thư trên Internet (RFC 5322) (https://tools.ietf.org/html/rfc5322)
6 Không được mạo danh ở phần đầu thư Từ: của Gmail. Gmail sẽ bắt đầu sử dụng chính sách thực thi cách ly theo DMARC, và việc mạo danh trong phần đầu thư Từ: của Gmail có thể ảnh hưởng đến việc gửi email (https://support.google.com/a/answer/10032169#policy-options)
7. Nếu bạn thường xuyên chuyển tiếp email, kể cả việc sử dụng danh sách gửi thư hoặc cổng thư đến, hãy thêm phần đầu ARC vào email gửi đi. Phần đầu ARC cho biết thư đã được chuyển tiếp và xác định bạn là người chuyển tiếp. Người gửi danh sách gửi thư cũng phải thêm phần đầu List-id:. Phần đầu này chỉ định danh sách gửi thư cho các thư gửi đi. (https://support.google.com/mail/answer/81126?hl=vi&sjid=11774976608095956067-AP#arc)
Yêu cầu đối với việc gửi từ 5.000 email trở lên mỗi ngày gửi vào Gmail
Kể từ ngày 1 tháng 2 năm 2024, những người gửi hơn 5.000 thư mỗi ngày đến các tài khoản Gmail phải đáp ứng các yêu cầu trong mục này.
Thiết lập phương thức xác thực email DKIM hoặc SPF cho miền của bạn.
Đảm bảo rằng địa chỉ IP hoặc miền gửi thư có bản ghi DNS chuyển tiếp và bản ghi DNS ngược hợp lệ, còn được gọi là bản ghi PTR. Tìm hiểu thêm
Sử dụng một kết nối TLS để truyền email. Để biết các bước thiết lập TLS trong Google Workspace, hãy xem bài viết Cần có một kết nối bảo mật cho email.
Giữ cho tỷ lệ thư rác được báo cáo trong Công cụ Postmaster dưới 0,1% và đừng để tỷ lệ thư rác bằng hoặc cao hơn 0,3%. Tìm hiểu thêm về tỷ lệ thư rác.
Định dạng thư theo Tiêu chuẩn định dạng thư trên Internet (RFC 5322).
Không được mạo danh ở phần đầu thư Từ: của Gmail. Gmail sẽ bắt đầu sử dụng chính sách thực thi cách ly giao thức DMARC, và việc mạo danh phần đầu thư Từ: của Gmail có thể ảnh hưởng đến việc gửi email.
Nếu bạn thường xuyên chuyển tiếp email, kể cả việc sử dụng danh sách gửi thư hoặc cổng thư đến, hãy thêm phần đầu ARC vào email gửi đi. Phần đầu ARC cho biết thư đã được chuyển tiếp và xác định bạn là người chuyển tiếp. Người gửi danh sách gửi thư cũng phải thêm phần đầu List-id:. Phần đầu này chỉ định danh sách gửi thư cho các thư gửi đi.
Thiết lập phương thức xác thực email bằng DMARC cho miền gửi thư của bạn. Bạn có thể đặt Chính sách thực thi bằng DMARC thành none. Tìm hiểu thêm
Đối với thư trực tiếp, miền trong phần Từ: của người gửi phải khớp với miền SPF hoặc miền DKIM. Đây là điều kiện bắt buộc để vượt qua yêu cầu phù hợp với DMARC.
Thư tiếp thị và thư gửi cho những người đã đăng ký phải hỗ trợ tính năng nhấp một lần để huỷ đăng ký, đồng thời phải có một đường liên kết huỷ đăng ký rõ ràng trong nội dung thư. Tìm hiểu thêm
Nếu bạn gửi hơn 5.000 email mỗi ngày trước ngày 1 tháng 2 năm 2024, hãy làm theo các nguyên tắc trong bài viết này càng sớm càng tốt. Việc đáp ứng các yêu cầu dành cho người gửi trước thời hạn trên có thể giúp cải thiện khả năng gửi email. Nếu bạn không đáp ứng các yêu cầu được mô tả trong bài viết này, email của bạn có thể không được gửi như mong đợi hoặc có thể bị đánh dấu là thư rác.
Để tìm hiểu thêm về cách thiết lập SPF, DKIM và DMARC, hãy truy cập vào bài viết Ngăn chặn thư rác, hành vi giả mạo và lừa đảo bằng phương thức xác thực của Gmail (https://support.google.com/a/answer/10583557 )
Lời kết
Đối với Quản trị viên IT Admin đơn vị, công ty cơ quan mình đang quản lý nên xem lại cách gửi email hiện tại của để đảm bảo bảo mật Email đám ứng đủ các tiêu chí trên:
Authentication (SPF, DKIM và DMARC), PTR, mà Gmail hay Yahoo yêu cầu… Nếu cần, hãy cập nhật cấu hình SPF, DKIM và DMARC của bạn để tuân thủ các yêu cầu mới.
PTR Record
Kiểm tra Email System dùng giao thức TLS connection tranmission
Tận dụng tối đa công cụ Postmaster giám sát các chỉ số của Gmail đưa ra: Authenticated (SPF, DKIM, DMARC), Spam rate luôn dưới 0,1% và không vượt 0.3%, IP reputation, domain reputation (High), Encryption traffic(TLS incoming/ TLS Outgoing),…
Đối với hệ thống marketing thường dùng bulk email cần đáp ứng tiêu chí Gmail nếu không sẽ dính chưởng block domain trường hợp này Phương Nguyễn đã gặp rồi ít nhất hơn 3 khách hàng.
Hạn chế thấp nhất các email vào gmail quảng cáo mà bị report là spam thì sẽ dính spam. Trương hợp có dùng để gửi email dạng thông báo hoặc tiếp thị liên kết cho khách thì nên có phương thức dễ đăng ký (subscribe) và huỷ đăng (List-Unsubscribe=One-Click) một lần nếu có.
Thiết nghĩ đây là yêu cầu bắt buộc với 1 hệ thống email mà bạn đang quản trị hệ thống nhà làm (on-premise) hay thuê hosting hay đi thuê cloude GG, 365, Zoho,.. Cũng nên xem và kiểm tra chặt chẽ để tránh Spam không đáng có.
Bài viết có tham khảo gmail và hiệu chỉnh theo ý cá nhân.