Tuyên bố miễn trừ trách nhiệm: Bài labs thực hành này không phải là “Email giả mạo 1101”. Các ví dụ giả mạo chỉ được trình bày cho mục đích thử nghiệm và phòng ngừa.
- Khái niệm:
Đảm bảo bảo mật email có thể là một trong những nhiệm vụ quan trọng nhất và khó khăn nhất mà quản trị viên phải đối mặt. Mỗi ngày, các máy chủ xử lý hàng ngàn email và việc kiểm soát một luồng thư lớn như vậy là không dễ dàng. Không có gì ngạc nhiên khi tin tặc tập trung vào kênh này khi họ lên kế hoạch tấn công. Họ sử dụng nhiều thủ thuật khác nhau để khiến người dùng nghĩ rằng việc mở một tệp đính kèm đáng ngờ là một ý kiến hay.
Một trong những thủ thuật họ sử dụng là giả mạo email, giả mạo cả địa chỉ email của chính người được phép gửi thư trong nội bộ của hệ thống máy chủ email, nội dung giả mạo, doạ nạt, giả thư thanh toán tiền, báo giá, hoá đơn, hợp đồng, tống tiền…
Email giả mạo “email spoofing” là gì?
Email giả mạo là một phương pháp tấn công rất phổ biến. Người gửi sửa đổi tiêu đề thư để email xuất hiện dưới dạng được gửi từ người khác. Ví dụ, tin tặc sử dụng nó để mạo danh nhân viên của một công ty nhằm lấy thông tin xác thực đăng nhập, dữ liệu cá nhân hoặc thông tin bí mật khác.
- Cách thức xử lý phổ biến:
Hai cách phổ biến nhất để bảo vệ tổ chức của bạn khỏi các cuộc tấn công giả mạo từ bên ngoài là:
- Bản ghi SPF – Danh sách các địa chỉ IP được phép gửi email từ một miền.
- Kiểm tra DKIM – Một phương thức xác thực email. Nó cho phép bạn ký và xác minh email bằng khóa chung và khóa riêng. Các khóa công khai, được xuất bản trong bản ghi DNS được sử dụng để xác minh xem thư có đến từ người gửi ban đầu hay không. Bạn không thể định cấu hình nó trên Exchange Server nguyên bản – bạn cần có plugin áp dụng cho cổng SMTP.
Sơ kết:
Cả hai cách đều cho kết quả tốt khi được cấu hình áp dụng chống giả mạo email bên ngoài (mạng internet).
- Vấn đề bắt đầu khi chúng ta gặp hành vi giả mạo ở trong mạng nội bộ khi một nhân viên cố gắng mạo danh đồng nghiệp hoặc máy tính của người dùng trong công ty bị virus/ ransomware.
- Nó có thể là một trò đùa, hoặc để đạt được một số lợi ích/mục đích – dù bằng cách nào, nó đều có thể phá hoại/gây hại một hệ thống email của công ty theo một số cách:
- Gây hỗn loạn, hoang mang do nội dung trong thư sai trái, thất thiệt.
- Gây thiệt hại vật chất, tiền tài chính.
- Làm hại, thất thoát tính toàn vẹn của dữ liệu.
- Gây tổn hại đến uy tín của cá nhân và công ty.
Tệ hơn nữa, việc chống lại các nỗ lực giả mạo nội bộ đòi hỏi một cách tiếp cận hơi khác.
Bây giờ chúng tôi sẽ trình bày cách ngăn chặn giả mạo email nội bộ trong một tổ chức sử dụng Exchange mail Server. Nhưng trước tiên, hãy mô tả nhanh về môi trường thử nghiệm:
- Xây dựng mô hình Exchange Server 2019 thử nghiệm:
Đối với mục đích trình bày và thử nghiệm, chúng ta sẽ sử dụng các máy sau:
- Có 1 máy chủ Windows Server 2019 làm Domain Controller (PDC và BDC). Tên miền: adatum.com, IPv4: 172.16.0.10
- Có 1 máy chủ Windows Server 2019 DC with Exchange 2019 CU10 cấu hình DAG, IPv4: 172.16.0.11, DAG IPv4: 172.16.0.33
- Có 1 máy cá nhân Windows 10 with Outlook 2016, IPv4: 172.16.0.111
Bây giờ cho phần thích hợp với thực tiễn. Chúng ta sẽ chỉ ra cách các cuộc tấn công giả mạo email được thực hiện và cách ngăn chặn chúng:
- Kịch bản giả mạo Email nội bộ:
Trước tiên, chúng ta hãy xem cách một nhân viên có thể giả dạng người dùng khác khi gửi email. Một lệnh cmdlet “Lệnh ghép ngắn” chạy bằng PowerShell duy nhất là đủ để đạt được điều đó.
Trong ví dụ bên dưới, user1@adatum.com mạo danh user3@adatum.com và gửi email đến user2@adatum.com.
Lệnh cmdlet được user1 sử dụng như sau:
Send-MailMessage –SmtpServer 172.16.0.11 –To user2@adatum.com –From user3@adatum.com –Subject “It`s me user3” –Body “Send me your report”
Tất nhiên, email như vậy sẽ không gây hại gì. Nếu user2 trả lời tin nhắn, email sẽ được chuyển đến user3 chứ không phải kẻ tấn công.
Vấn đề là sau một số sửa đổi, Send-MailMessage có thể gửi email HTML có liên kết độc hại hoặc đính kèm tệp bị nhiễm.
Tôi sẽ không đi quá xa các ví dụ về cách giả mạo có thể được sử dụng để gây hại cho một tổ chức, nhưng hãy tin tôi đi; có nhiều thứ như vậy và chúng luôn là như vậy ở trên mạng.
Thủ thuật tương tự có thể đạt được bằng cách sử dụng Telnet Client. Máy khách Telnet không được cài đặt theo mặc định, nhưng bạn có thể vào Control Panel > Programs > Turn Windows features on or off của Windows và chọn Máy khách Telnet Client ở đó để bật nó.
Để kiểm tra giả mạo email nội bộ, hãy chạy cmd.exe và kết nối với máy chủ của bạn trên cổng 25 bằng cách nhập lệnh CMD:
Telnet 172.16.0.11 25
Chỉ cần nhớ thay thế địa chỉ IP bằng địa chỉ của bạn. Tiếp theo, sử dụng các lệnh SMTP, bạn có thể gửi email:
-
HELO adatum.com (connects to your domain)
-
MAIL FROM: user3@adatum.com (address of the user you want to impersonate)
-
RCPT TO: user2@adatum.com (your victim’s address)
-
DATA: it enables you to specify subject and body of your email. Enter a full stop (.) in a new line to finish data input.
Cả hai phương pháp kết thúc với cùng một kết quả:
Đối với một tình huống thực tế hơn, một cuộc tấn công tương tự được triển khai trong một môi trường khác trông như thế này:
Như bạn có thể thấy, email này không khác với bất kỳ thư nào khác, được gửi bằng phương tiện thông thường. Người nhận rất dễ mắc bẫy vì thư doạ nạt này.
Với tư cách là quản trị viên, bạn có thể phát hiện hành động như vậy trong nhật ký Exchange Logs, nhưng trong một tổ chức lớn công ty có nhiều hòm thư người dùng hơn và luồng thư “mail flow dày đặc, sẽ gặp rất nhiều rắc rối. Chưa kể rằng tác hại có thể được thực hiện trước khi được chúng ta phát hiện.
Vậy tại sao Exchange lại cho phép hành vi như vậy? Và làm thế nào để chặn nó?
Trong triển khai Exchange mặc định, một trình kết nối Nhận “Receive connector ” được tạo. Giao diện người dùng mặc định (tên máy chủ của bạn) được định cấu hình sao cho:
- Nhận từ tất cả các địa chỉ IP.
- Sử dụng cổng SMTP mặc định 25 để nhận email.
- Cho phép email từ người dùng ẩn danh.
Điểm cuối cùng này là thứ cho phép người dùng nội bộ hoặc virus lạm dụng hệ thống gửi thư.
Thật không may, việc tắt quyền cho người dùng ẩn danh cũng sẽ chặn nhận email từ các địa chỉ email bên ngoài. Chà, chúng ta không biết trong môi trường nào thì đó sẽ là một lựa chọn hợp lý.
- Cách ngăn chặn giả mạo email nội bộ:
Có thể có nhiều giải pháp của bên thứ ba chống lại mối đe dọa này, nhưng trong bài viết này, chúng ta sẽ chỉ trình bày cách loại trừ giả mạo bên trong một tổ chức bằng cách sử dụng cơ chế kỹ thuật của Exchange.
Có hai phương pháp chúng ta sẽ chứng minh:
- Cách 1. Chặn các nỗ lực giả mạo bằng bản ghi SPF.
- Cách 2. Ngăn giả mạo nội bộ bằng đầu nối Nhận chuyên dụng.
Cách 1. Sử dụng bản ghi SPF:
Như đã đề cập khi mô tả các cuộc tấn công từ bên ngoài, một trong những vũ khí phổ biến nhất (và hiệu quả) chống lại các nỗ lực giả mạo là sử dụng bản ghi SPF.
Xem cú pháp của bản ghi SPF bên dưới:
V=spf1 ip4:your_server’s IP –all
Nói một cách đơn giản: các bản ghi SPF nằm trong tệp vùng DNS. Họ chỉ định địa chỉ IP của máy chủ được phép gửi email từ một miền nhất định (thêm về cách tạo bản ghi SPF).
Cơ chế này có thể được sử dụng để bảo mật thư từ chính trong nội bộ một cách tương tự như cách nó thường được sử dụng để liên lạc với bên ngoài.
Để phương pháp này hoạt động chống lại đối với giả mạo email nội bộ, bạn sẽ cần thiết lập cấu hình ba yếu tố:
- Bản ghi SPF có trong DNS Local mạng nội bộ,
- Chức năng chống thư rác trong Exchange Server,
- Một ID của người gửi thư.
Nhược điểm của cách 1:
- Để chặn hoàn toàn giả mạo email nội bộ bằng phương pháp này, bạn phải bao gồm tất cả các địa chỉ IP được phép gửi email trong mạng của mình (bao gồm máy in, ứng dụng và các đối tượng web khác).
- Đây không phải là giải pháp thuận tiện nhất nếu bạn có một mạng rộng lớn nhiều VLAN, PVLAN, vô số thiết bị AP, WLAN, smartphone khác nhau…
- Nhưng nếu bạn không có cơ sở hạ tầng quá lớn đó và bạn biết nó rõ như lòng bàn tay, thì giải pháp sẽ hoạt động tốt thôi.
Hướng dẫn từng bước:
Bước 1.
Chúng ta nên tạo bản ghi txt trên máy chủ DNS của mình trong miền cục bộ như thế này:
v=spf1 ip4:172.16.0.11 ip4:172.16.0.33 ip4:192.168.169.51 ip4:172.16.0.111 –all
172.16.0.11 và 172.16.0.33 là địa chỉ IP của Máy chủ Exchange của tôi, trong khi 192.168.169.51 là địa chỉ IP của máy in web của tôi trong một mạng con khác. Máy in gửi email đến Exchange.
172.16.0.111 là máy PC tôi cài Veeam Backup và PC này gửi email báo cáo tình hình backup/restore hệ thống data đến Exchange.
Bước 2. Tiếp theo là cài đặt Exchange Antispam Agent. Bạn có thể sử dụng PowerShell để làm điều đó. Lệnh ghép ngắn cmdlet là:
- Trường hợp máy chủ Exchange 2019 là bản cài trên Windows Core 2019 (không có giao diện) thì sẽ gặp lỗi:
Chữa lỗi khi dùng lệnh PS này cho máy chủ Windows Core 2019 / Exchange 2019 Standard, trước tiên sẽ gõ lện CMD:> Start PowerShellvà bấm phím enter:
Start PowerShell
Một cửa sổ lệnh mới của PowerShell window xuất hiện chúng ta sẽ nhập lệnh ở đây:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Sau đó quay lại lệnh cài AntiSpamAgents.ps1
- Trường hợp máy chủ Exchange 2019 là bản cài trên Windows Server 2019 có giao diện đầy đủ thì chỉ nhập lệnh PowerShell:
& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1
Cài đặt thành công sẽ như thế này:
Bước 3. Bây giờ để các thay đổi được áp dụng, hãy khởi động lại dịch vụ MSExchangeTransport của bạn:
Restart-Service MSExchangeTransport
Bước 4. Cung cấp tất cả địa chỉ IP của Máy chủ Exchange:
Set-TransportConfig –InternalSMTPServers 172.16.0.11,172.16.0.33
Tôi phải cung cấp hai địa chỉ IPv4 vì Máy chủ Exchange của tôi có hai giao diện mạng.
Chúng ta đang gần hoàn tất. Bây giờ, bạn phải định cấu hình quy tắc từ chối email từ các địa chỉ không có trong bản ghi SPF của bạn. Lệnh ghép ngắn PowerShell là:
Set-SenderIdConfig –SpoofedDomainAction Reject
Tất cả những gì còn lại là kiểm tra xem cấu hình hiện tại có chặn thành công nỗ lực giả mạo nội bộ hay không.
Tôi sẽ sử dụng cmdlet giống như tôi đã trình bày ở đầu bài viết. Thay vì gửi email, kẻ tấn công sẽ gặp lỗi sau:
Như bạn có thể thấy, máy chủ Exchange chặn nỗ lực này và hiển thị lỗi 5.7.1 “ID người gửi <PRA> không được phép. Hiệu ứng sẽ giữ nguyên ngay cả khi người dùng nhập hộp thư của chính họ trong thuộc tính –From:
Cuối cùng, hãy để chúng tôi kiểm tra xem điều gì sẽ xảy ra nếu tôi cố giả dạng người dùng khác trên máy có địa chỉ IP 172.16.0.111 (địa chỉ tôi đã thêm vào bản ghi SPF cục bộ trước đó vào máy chủ DNS):
Và ngay sau khi DNS Server local đã thêm IP4 trong bản ghi SPF (TXT) đó thì cũng dùng lệnh PowerShell> Restart-Service MSExchangeTransport
Tôi dùng PowerShell remote có trên Windows Admin Center khi connected tới máy chủ Exchange Core 2019.
Trong khi đó nếu thư soạn và gửi bằng lệnh:
Telnet 172.16.0.11 25 thì lại thành công
Thư đi qua mà không có vấn đề gì:
- Ví dụ này cho thấy một nhược điểm khác của phương pháp ghi SPF. Vì cơ sở xác thực dựa trên IP của người gửi, cấu hình sai hoặc chính máy trong dải ip được phép bị nhiễm virus sẽ không đảm bảo rằng công ty của bạn được bảo vệ hoàn toàn khỏi hành vi giả mạo nội bộ.
- Việc triển khai phương pháp này không ảnh hưởng đến việc gửi email từ các ứng dụng email (Outlook, OWA hoặc ActiveSync) vì chúng sử dụng RPC hoặc MAPI qua HTTP thông qua một cổng khác (443 hoặc 80).
Cách 2. Sử dụng đầu kết nối Nhận chuyên dụng:
- Phương pháp thứ hai là tạo một trình kết nối Nhận bổ sung trên cổng 25.
- Trình kết nối kiểm soát mạng cục bộ và chỉ cho phép các email từ người dùng trong miền đi qua.
- Cách tiếp cận này sử dụng một phương thức ủy quyền khác.
- Thay vì sử dụng IP, nó sử dụng thông tin xác thực tên miền (đăng nhập và mật khẩu).
- Việc thay đổi phương thức ủy quyền tạo ra một vấn đề – tất cả các kết nối Exchange nội bộ phải được ủy quyền. Nói cách khác, mọi thiết bị web và ứng dụng gửi email tới Exchange đều yêu cầu tài khoản miền (hoặc ít nhất chúng có thể có một tài khoản chung).
- Đề cập trước đây, trình kết nối sẽ được đặt cho cổng TCP 25. Tuy nhiên, như bạn có biết, đã có một trình kết nối Nhận, chấp nhận các kết nối ẩn danh từ máy chủ SMTP trên cổng 25.
Vậy làm cách nào để trình kết nối này có thể cùng tồn tại với một cái bạn sắp tạo? Và làm thế nào để Exchange biết nên chọn cái nào?
- Exchange Server khá thông minh khi nói đến điều này.
- Máy chủ sẽ luôn chọn trình kết nối chính xác hơn cho mỗi kết nối.
- Trình kết nối Nhận mà tôi định cấu hình được xác định cho mạng LAN, trong khi trình kết nối mặc định áp dụng cho tất cả các kết nối. Do đó, đối với các kết nối SMTP nội bộ, Exchange sẽ luôn chọn trình kết nối mới, được chỉ định cho mạng LAN.
Hướng dẫn từng bước:
Cách thứ hai, ngoài việc an toàn hơn, còn dễ thực hiện hơn.
Đó là bởi vì nó chỉ yêu cầu tạo một trình kết nối Nhận mới.
Bạn có thể sử dụng một lệnh cmdlet trên PowerShell cho việc đó.
Tôi sẽ sử dụng tên SMTP của Máy khách Nội bộ cho trình kết nối để sau này tôi có thể dễ dàng xác định nó. Hãy nhớ rằng, dải IP được cá nhân hóa VLAN isolate network cho môi trường của tôi:
New-ReceiveConnector –Name “Internal Client SMTP” –TransportRole FrontendTransport –Usage Custom –Bindings 0.0.0.0:25 –RemoteIPRanges 172.16.0.0/24,192.168.170.0/24 –AuthMechanism TLS,Integrated –PermissionGroups ExchangeUsers
Hoặc cũng có thể tạo nó trong Trung tâm quản trị Exchange Administration Center > Mail Flow > Receive Connectors > New: Các cài đặt tương tự với sử dụng trong lệnh cmdlet ở trên.
Trình kết nối phải là nội bộ và vai trò phải được đặt thành TransportRole FrontendTransport… Thật không may, Vai trò mặc định là Hub Transport và có vẻ như tôi không thể thay đổi nó thành tùy chọn mà tôi cần. Dù sao thì chúng ta hãy tiếp tục và xem điều gì sẽ xảy ra.
Trang tiếp theo rất quan trọng – đó là nơi bạn phải chỉ định tất cả các mạng LAN mà bạn có trong tổ chức của mình. Trong trường hợp của tôi, đó là 172.16.0.0/24 và 192.168.170.0/24.
Đó là nơi Exchange đưa ra lỗi.
The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector “LON-EXCH\Default Frontend LON-EXCH”. Receive connectors assigned to different Transport roles on a single server must listen on unique local IP address & port bindings.
Có vẻ như Exchange không thích có hai trình kết nối với các vai trò Vận chuyển khác nhau cùng nghe trên một cổng. Nhưng hai vai trò chỉ khác nhau vì một tùy chọn bị chuyển sang màu xám… Điều này thật đặc biệt, khi xem xét thực tế là một lệnh cmdlet không đưa ra bất kỳ lỗi nào. Bạn có thể kiểm tra xem mình có gặp phải lỗi tương tự hay không, nhưng lời khuyên của tôi là chỉ nên sử dụng cmdlet trên PowerShell.
Trình kết nối (bất kể bạn tạo nó như thế nào) sẽ xuất hiện trong danh sách:
Now for the testing. user1 will try to send a message to user2@adatum.com as user3@adatum.com.
The PowerShell command already used a couple of times in this article does not send an email this time. The error code is different from the one which appeared using the previous method: 5.7.60 SMTP; Client does not have permission to send as this sender.
nếu người dùng thử thủ thuật tương tự sau khi cung cấp thông tin đăng nhập của họ thì sao?
Tốt, vẫn không có may mắn. Nhưng khi cùng một người dùng ngừng cố gắng xuất hiện với tư cách người khác:
Lệnh cmdlet đã thực hiện công việc của nó. Nạn nhân của ngày hôm nay, user3@adatum.com có thể đọc tin nhắn cùng với người gửi ban đầu::
Nỗ lực giả mạo nội bộ cũng bị chặn nếu người dùng ác ý cố gắng sử dụng telnet:
Tóm tắt:
Là quản trị viên Exchange Server, bạn cần biết rằng việc triển khai Exchange mặc định là không đủ để bảo vệ người dùng của bạn khỏi các email độc hại.
Bạn có thể sử dụng bài Labs này để ngăn chặn việc giả mạo email nội bộ mãi mãi.
Cả hai cách trên đều dựa trên cơ chế Exchange Server, tất cả những gì bạn cần là thực hành.
NIỆM SINH GIỚI-ĐỊNH-HUỆ (Mindfulness gives birth to Precepts of Wisdom) 