TÌM HIỂU VỀ HỆ THỐNG DNS
DNS là gì ?
DNS, hay Hệ thống phân giải tên miền (Domain Name Servers), đóng vai trò quan trọng trong việc "dịch" tên miền Internet và tên máy chủ thành địa chỉ IP, giúp các máy chủ và thiết bị mạng hiểu được thông tin Trên Internet, DNS tự động chuyển đổi các tên miền mà người dùng nhập vào thanh địa chỉ trình duyệt web thành địa chỉ IP tương ứng.
Khi trình duyệt "dịch" địa chỉ, người dùng có thể đăng nhập vào website một cách dễ dàng Thay vì nhớ và nhập dãy số địa chỉ IP của hosting, người dùng chỉ cần nhập tên website, và trình duyệt sẽ tự động nhận diện.
Mỗi máy tính trên Internet đều có một địa chỉ IP duy nhất Địa chỉ
Địa chỉ IP được sử dụng để thiết lập kết nối giữa máy chủ và máy khách, khởi đầu cho quá trình kết nối Mỗi khi bạn truy cập một website hoặc gửi email, hệ thống DNS đóng vai trò quan trọng trong việc đảm bảo kết nối này diễn ra suôn sẻ.
Trong hàng triệu trang web trên thế giới, việc ghi nhớ từng địa chỉ IP là điều không thể Vì vậy, khái niệm tên miền ra đời, giúp mỗi trang web được xác định bằng một tên duy nhất.
Địa chỉ IP đóng vai trò quan trọng trong việc kết nối các thiết bị mạng, nơi mà DNS thực hiện nhiệm vụ phân giải tên miền thành địa chỉ IP, giúp các thiết bị giao tiếp hiệu quả Ngoài ra, người dùng có thể truy cập một website bằng cách nhập trực tiếp địa chỉ IP thay vì sử dụng tên miền.
Kiến trúc của DNS
1.2.1 DNS Zone và DNS File Zone
DNS Zone là một phần của không gian tên DNS, được quản lý bởi một tổ chức hoặc quản trị viên cụ thể Nó cho phép kiểm soát chi tiết các thành phần DNS, bao gồm cả máy chủ định danh có thẩm quyền.
Các miền không gian tên tạo thành một cấu trúc phân cấp, với tên miền DNS root nằm ở đỉnh Vùng DNS bắt đầu từ một miền trong cấu trúc này và có khả năng mở rộng xuống các miền phụ, cho phép nhiều miền phụ được quản lý bởi một thực thể duy nhất.
Tệp DNS file zone là một tài liệu văn bản thuần túy lưu trữ trên máy chủ DNS, chứa bản sao thực tế của vùng và tất cả các bản ghi cho các miền trong vùng đó Mỗi tệp DNS file zone phải bắt đầu bằng bản ghi Start of Authority (SOA), cung cấp thông tin quan trọng như thông tin liên hệ của quản trị viên vùng.
1.2.2 Resource Record (Các bản ghi DNS)
RR, or Resource Record, is a type of information used to describe DNS data, and these records are stored in zone files located within DNS zones.
Mỗi DNS Zone có một zone file Zone file cũng có thể được xem giống như là cơ sở dữ liệu DNS.
Các zone file chứa một hoặc nhiều bản ghi tài nguyên (resource records) và cần được cập nhật thường xuyên để phản ánh các thay đổi về tên miền Việc không cập nhật định kỳ các bản ghi DNS có thể dẫn đến hệ thống trở nên chậm chạp và lỗi thời Do đó, khả năng chuyển vùng giữa các máy chủ DNS là rất quan trọng để duy trì hiệu suất và độ chính xác của hệ thống.
Resource Record là bản ghi đơn mô tả chi tiết thông tin trong cơ sở dữ liệu DNS, được định dạng dưới dạng văn bản đơn giản.
Owner TTL Class Type RDATA
Mỗi trường này phải được phân tách bằng ít nhất một khoảng trắng
Các loại Resource Record a SOA (Start of Authority)
Mỗi tên miền thường sử dụng một cặp DNS để trỏ đến một hoặc nhiều máy chủ DNS, có nhiệm vụ cung cấp thông tin bản ghi DNS cho tên miền đó Bản ghi SOA (Start of Authority) được xem như dấu hiệu nhận biết của hệ thống về tên miền Cấu trúc của bản ghi SOA thường bao gồm: [tên miền] IN SOA [tên-server-dns] [địa-chỉ-email].
(serial number; refresh number; retry number; experi number; time-to-live number)
@ IN SOA masterdns.hiennt.com admin.hiennt.com (
Hình 1: Cấu trúc bản ghi SOA
Trong bài viết này, chúng ta tìm hiểu về hai giá trị DNS quan trọng liên quan đến tên miền Đầu tiên, masterdns.hiennt.com đại diện cho giá trị DNS chính của tên miền hoặc máy chủ Thứ hai, admin.hiennt.com là sự chuyển đổi từ địa chỉ email admin@hiennt.com, thể hiện rõ ràng chủ thể sở hữu tên miền này.
Serial là định dạng áp dụng cho mọi dữ liệu trong zone, có dạng YYYYMMDDNN, trong đó YYYY là năm, MM là tháng, DD là ngày, và NN là số lần sửa đổi dữ liệu trong ngày Số NN phải luôn tăng lên mỗi khi có sự thay đổi Khi máy chủ DNS Slave kết nối với máy chủ DNS Master, nó sẽ kiểm tra số serial Nếu số serial của Slave nhỏ hơn của Master, dữ liệu zone trên Slave sẽ được coi là cũ, và Slave sẽ sao chép dữ liệu mới từ Master để thay thế.
The Refresh interval specifies the duration for which a Slave DNS Server checks the zone data on the Master Server to update if necessary This value varies based on the frequency of changes within the zone data.
Nếu Slave DNS Server không thể kết nối với Master DNS Server trong thời gian quy định bởi refresh, ví dụ như khi Master DNS Server bị tắt, Slave DNS Server sẽ cố gắng kết nối lại theo chu kỳ thời gian được mô tả trong retry, thường có giá trị nhỏ hơn giá trị refresh.
Expire: Nếu Slave DNS Server không kết nối được với Master DNS Server sau thời gian quy định, dữ liệu zone trên Slave sẽ hết hạn Khi dữ liệu trên Slave hết hạn, máy chủ sẽ ngừng phản hồi các truy vấn liên quan đến zone đó Giá trị expire cần phải lớn hơn giá trị refresh và giá trị retry.
Minimum TTL: Chịu trách nhiệm thiết lập TTL tối thiểu cho 1 zone. b NS (Name Server)
Bản ghi NS là yếu tố quan trọng trong việc khai báo máy chủ tên miền cho một tên miền cụ thể Nó cung cấp thông tin về máy chủ quản lý tên miền đó Mỗi tên miền cần có ít nhất hai máy chủ tên miền để đảm bảo tính ổn định và khả năng truy cập, do đó yêu cầu tối thiểu hai bản ghi NS cho mỗi tên miền là cần thiết.
Cú pháp của bản ghi NS:
IN NS
Ví dụ: thuyhiend.space IN NS ns1.zonedns.vn thuyhiend.space IN NS ns2.zonedns.vn
Tên miền thuyhiend.space sẽ được quản lý bởi máy chủ tên miền ns1.zonedns.vn và ns2.zonedns.vn Điều này có nghĩa là tất cả các bản ghi như A, CNAME, MX của tên miền thuyhiend.space và các tên miền con của nó sẽ được thiết lập trên hai máy chủ này.
Record A là một thành phần quan trọng trong hệ thống DNS, có chức năng ánh xạ từ domain thành địa chỉ IP, giúp người dùng truy cập website dễ dàng Cấu trúc của Record A được định nghĩa như sau: domain IN A .
Ví dụ về 1 khai báo bản ghi A thuyhiend.space A 103.101.161.201
Tên miền con (subdomain): sub.thuyhiend.space A 103.101.161.201 d Record AAAA
Có nhiệm vụ tương tự như bản ghi A, nhưng thay vì địa chỉ IPv4 sẽ là địa chỉ IPv6. e PTR(Pointer Records)
Bản ghi PTR (pointer) trỏ một địa chỉ IP đến một bản ghi A trong chế độ ngược (reverse) và được sử dụng trong kiểu tên miền infrastructure TLD.
Ví dụ về dạng thức một bản ghi PTR như sau:
90.163.101.103.in-addr.arpa IN PTR masterdns.thuyhiend.space đối với IPv4, hoặc đối với IPv6:
0.0.0.0.0.0.0.0.0.0.0.0.d.c.b.a.4.3.2.1.3.2.1.0.8.c.d.0.1.0. 0.2.ip6.arpa IN PTR masterdns.thuyhiend.space f SRV(Service)
Cơ chế hoạt động của DNS
DNS hoạt động theo từng bước theo cấu trúc của DNS Bước đầu tiên gọi là DNS query, một truy vấn để lấy thông tin.
Khi tìm kiếm website bằng cách gõ tên miền vào trình duyệt, DNS server đầu tiên sẽ tra cứu thông tin phân giải trong file hosts, một tệp văn bản trong hệ điều hành giúp chuyển đổi hostname thành địa chỉ IP Nếu không tìm thấy thông tin, nó sẽ tiếp tục tìm trong bộ nhớ cache, nơi lưu trữ tạm thời của phần cứng hoặc phần mềm Bộ nhớ cache phổ biến nhất bao gồm bộ nhớ tạm của trình duyệt và bộ nhớ tạm của nhà cung cấp dịch vụ Internet (ISP) Nếu không có thông tin, bạn sẽ gặp phải mã lỗi.
Khi máy chủ tên miền cục bộ không tìm thấy thông tin về tên miền, nó sẽ gửi yêu cầu đến các máy chủ tên miền cấp cao nhất, tức là máy chủ ROOT Máy chủ ROOT sẽ hướng dẫn máy chủ cục bộ đến địa chỉ của máy chủ quản lý các tên miền có đuôi vn.
Tiếp đó, máy chủ tên miền cục bộ gửi yêu cầu đến máy chủ quản lý tên miền Việt Nam (.VN) tìm tên miền matbao.vn.
Máy chủ tên miền cục bộ sẽ yêu cầu máy chủ quản lý tên miền vnn.vn cung cấp địa chỉ IP của tên miền qldt.ptit.edu.vn Vì máy chủ vnn.vn có cơ sở dữ liệu liên quan đến tên miền này, địa chỉ IP sẽ được trả lại cho máy chủ tên miền cục bộ.
Cuối cùng, máy chủ tên miền cục bộ gửi thông tin tìm thấy đến máy của người sử dụng Người dùng sử dụng địa chỉ IP này để kết nối với server chứa trang web qldt.ptit.edu.vn.
Hình 2: Mô hình hoạt động của DNS
Tổng cộng có khoảng 4 loại server tham gia vào trong hệ thống phân giải tên miền
DNS recursor là một máy chủ chịu trách nhiệm giao tiếp với các máy chủ khác nhằm phản hồi yêu cầu từ client (trình duyệt người dùng) Nó hoạt động như một nhân viên tận tâm, nhận nhiệm vụ thu thập và cung cấp thông tin cần thiết cho client Để hoàn thành nhiệm vụ này, DNS recursor có thể cần liên hệ với Root DNS Server để nhận được sự hỗ trợ trong việc tìm kiếm thông tin chính xác.
Máy chủ DNS gốc, hay còn gọi là nameserver, đóng vai trò quan trọng nhất trong hệ thống phân cấp của DNS Nó không có tên cụ thể và có thể được hiểu như một thư viện giúp định hướng tìm kiếm thông tin hiệu quả.
In practice, a DNS recursive resolver forwards requests to the Root Nameserver, which then responds by indicating the specific top-level domain (TLD) nameservers that need to be queried.
Khi truy cập các trang web như Google hay Facebook, bạn thường sử dụng phần mở rộng com, một trong những loại top-level domain (TLD) Các máy chủ cho TLD này được gọi là TLD nameserver, có nhiệm vụ quản lý toàn bộ thông tin liên quan đến phần mở rộng tên miền chung.
Khi bạn nhập www.google.com vào trình duyệt, phần mở rộng TLD com sẽ yêu cầu một DNS resolver để tìm kiếm thông tin từ một máy chủ DNS Authoritative Máy chủ Authoritative Name Server là nơi lưu trữ chính thức dữ liệu của tên miền.
Khi một DNS resolver phát hiện một authoritative nameserver, quá trình phân giải tên miền bắt đầu Authoritative nameserver lưu trữ thông tin về tên miền và địa chỉ IP tương ứng Nó cung cấp cho recursive resolver địa chỉ IP cần thiết từ danh mục các bản ghi của mình.
CÁC DẠNG TẤN CÔNG VÀO DNS
DNS Spoofing
DNS Cache Poisoning, hay còn gọi là Spoofing, là một hình thức tấn công nhằm chiếm quyền điều khiển DNS Cache và thay đổi thông tin trong đó thành các giá trị giả mạo Kịch bản tấn công này có thể gây ra những hậu quả nghiêm trọng, làm mất an toàn cho dữ liệu và thông tin của người dùng.
Hình 3: Mô hình tấn công DNS Spoofing
Khi người dùng nhập địa chỉ www.facebook.com vào thanh địa chỉ của trình duyệt, hệ thống sẽ xác nhận thông tin địa chỉ IP liên quan đến tên miền này và trả về thông tin, giúp website www.facebook.com hiển thị đầy đủ trên trình duyệt.
Một tên miền có thể chứa nhiều địa chỉ IP, và khi bạn thường xuyên truy cập www.facebook.com, hệ thống sẽ ghi nhớ trang web này để rút ngắn thời gian truy cập sau Tuy nhiên, kẻ tấn công có thể lợi dụng điều này bằng cách thay đổi giá trị của DNS cache, khiến www.facebook.com với địa chỉ IP 69.171.250.35 bị chuyển hướng đến một địa chỉ IP khác chứa trang web độc hại của họ.
DNS Hijacking
a Khái niệm b Kịch bản tấn công c Các bước tấn công
DNS Hijacking là một hình thức chuyển hướng địa chỉ website mà người dùng truy cập Khi bạn nhập địa chỉ abc.com vào trình duyệt, bạn có thể bị điều hướng đến một địa chỉ khác, chẳng hạn như xyz.com, mà không hề hay biết.
Phần lớn tên miền của các trang web được thể hiện dưới dạng văn bản, như ví dụ quantrimang.com Mỗi URL đều gắn liền với một địa chỉ IP tương ứng Nhiệm vụ chính của DNS là phân giải và chuyển đổi các ký tự văn bản thành địa chỉ IP.
IP tương ứng (các bạn mở lệnh RUN > gõ "ping" đến domain là sẽ ra địa chỉ IP của website đó) Ví dụ cụ thể:
Hacker thường sử dụng phương thức lừa đảo người dùng cài đặt phần mềm độc hại, chủ yếu là Malware, nhằm mục đích thay đổi DNS của hệ thống máy tính Khi người dùng nhập địa chỉ website, hệ thống sẽ tự động kết nối tới server DNS giả mạo của hacker thay vì sử dụng DNS chính thức từ ICANN.
The Internet Corporation for Assigned Names and Numbers) và điều hướng người dùng đến website giả mạo của hacker.
NXDOMAIN Attacks
Cuộc tấn công NXDOMAIN là một hình thức tấn công DDoS, trong đó máy chủ DNS bị tấn công bằng cách gửi hàng loạt truy vấn đến các tên miền không tồn tại Hành động này làm đầy bộ nhớ cache của máy chủ tên có thẩm quyền, dẫn đến việc ngăn chặn hoàn toàn các yêu cầu DNS hợp pháp.
Khi bạn truy cập trang web, DNS chuyển đổi tên miền thành địa chỉ IP Nếu bạn nhập asdasdasdasd.com, DNS sẽ không tìm thấy địa chỉ IP tương ứng và trả về thông báo lỗi Tuy nhiên, trình giải quyết vẫn cố gắng tìm kiếm kết quả, sử dụng thời gian quý giá để xem qua bộ nhớ cache và sức mạnh xử lý của CPU Trước khi thông báo lỗi được trả về, yêu cầu đã được xử lý cùng với các yêu cầu hợp lệ khác.
Kẻ tấn công có thể điều khiển một mạng botnet với hàng nghìn người dùng, mỗi người gửi yêu cầu đến một miền không tồn tại Hành động này có thể nhanh chóng làm tắc nghẽn bộ nhớ cache của máy chủ DNS, dẫn đến việc từ chối dịch vụ cho những người dùng muốn truy cập vào các trang web hợp pháp.
Gần đây, một số Nhà cung cấp Dịch vụ Internet (ISP) đã lợi dụng tình trạng này bằng cách chuyển hướng các yêu cầu không hợp lệ đến các máy chủ chứa quảng cáo, thay vì trả về thông báo lỗi Hành động này không chỉ gây phiền toái cho người dùng mà còn tạo ra cơ hội để các ISP thu lợi từ những yêu cầu này.
CÁC CƠ CHẾ BẢO MẬT DNS
DNSSEC
DNSSEC là một công nghệ an ninh nâng cao cho hệ thống DNS, cung cấp cơ chế xác thực giữa các máy chủ DNS và xác thực cho từng zone dữ liệu, nhằm đảm bảo tính toàn vẹn của thông tin.
Giao thức DNS thông thường không có khả năng xác thực nguồn dữ liệu, dẫn đến nguy cơ dữ liệu DNS bị giả mạo và sai lệch trong các tương tác giữa máy chủ DNS và máy trạm hoặc máy chủ chuyển tiếp Để đối phó với tình trạng này, công nghệ bảo mật DNSSEC đã được nghiên cứu và triển khai nhằm bảo vệ DNS khỏi các mối đe dọa giả mạo DNSSEC cung cấp cơ chế xác thực giữa các máy chủ DNS và xác thực từng zone dữ liệu, đảm bảo toàn vẹn dữ liệu.
DNSSEC là công nghệ an toàn mở rộng cho hệ thống DNS, cung cấp các cơ chế chứng thực và đảm bảo toàn vẹn dữ liệu Công nghệ này giới thiệu bốn loại bản ghi mới nhằm tăng cường bảo mật cho DNS.
Bản ghi khóa công cộng DNS (DNSKEY - DNS Public Key): sử dụng để chứng thực zone dữ liệu.
Bản ghi chữ ký tài nguyên (RRSIG - Resource Record Signature): sử dụng để chứng thực cho các bản ghi tài nguyên trong zone dữ liệu.
Bản ghi bảo mật kế tiếp (NSEC - Next Secure) được sử dụng để xác thực các bản ghi có cùng sở hữu trong tập hợp bản ghi tài nguyên hoặc bản ghi CNAME Nó kết hợp với bản ghi RRSIG để đảm bảo tính xác thực cho zone dữ liệu.
Bản ghi ký ủy quyền (DS - Delegation Signer) là một thành phần quan trọng trong việc thiết lập chứng thực giữa các zone dữ liệu, giúp đảm bảo tính xác thực trong quá trình chuyển giao DNS.
Mục tiêu của DNSSEC là không làm thay đổi quá trình truyền dữ liệu DNS và việc chuyển giao giữa các DNS cấp cao và thấp Tuy nhiên, các máy trạm (resolver) cần hỗ trợ các cơ chế mở rộng này Một zone dữ liệu được ký xác thực sẽ bao gồm các bản ghi RRSIG, DNSKEY, NSEC và DS.
Bằng cách tổ chức thêm bản ghi mới và chỉnh sửa các giao thức, DNSSEC đã chứng thực nguồn gốc và tính toàn vẹn dữ liệu cho hệ thống DNS, mở rộng tính năng bảo mật và nâng cao độ an toàn, tin cậy Hệ thống này không chỉ khắc phục những nhược điểm của thiết kế ban đầu mà còn đáp ứng yêu cầu thông tin định tuyến về tên miền, cùng với việc cải thiện giao thức làm việc giữa các máy chủ DNS và tăng cường khả năng dự phòng cho hệ thống.
3.1.2 Cơ chế bảo mật của DNSSEC a Quá trình kí vùng bằng khóa Zone-Signing Key
Mỗi vùng trong DNSSEC sử dụng một cặp khóa ký vùng (ZSK), bao gồm phần riêng để ký từng RRset và phần công khai để xác minh chữ ký Để kích hoạt DNSSEC, nhà khai thác vùng tạo chữ ký số cho từng RRset bằng ZSK riêng và lưu trữ chúng dưới dạng bản ghi RRSIG trên máy chủ định danh.
Các bản ghi RRSIG chỉ có giá trị khi trình phân giải DNS có khả năng xác minh chữ ký Để thực hiện điều này, các nhà điều hành vùng cần công khai ZSK của họ bằng cách thêm nó vào máy chủ định danh trong bản ghi DNSKEY Quá trình ký khóa diễn ra thông qua Key-Signing Key.
Máy chủ định danh DNSSEC sử dụng khóa ký khóa (KSK) để xác thực bản ghi DNSKEY, tương tự như cách mà khóa ký vùng (ZSK) bảo vệ các RRsets KSK ký công khai ZSK, được lưu trữ trong bản ghi DNSKEY, và tạo ra RRSIG cho DNSKEY.
Máy chủ định danh công khai KSK xuất bản một bản ghi DNSKEY khác, cung cấp DNSKEY RRset cần thiết Cả KSK công khai và ZSK công khai đều được ký bởi KSK tư nhân, cho phép người phân giải sử dụng KSK công khai để xác thực ZSK công khai Quá trình xác thực các bản ghi là một bước quan trọng trong việc đảm bảo tính toàn vẹn và độ tin cậy của thông tin DNS.
Quá trình xác thực khóa
Máy chủ Resolver yêu cầu các RRset, name server trả về bản ghi RRSIG tương ứng.
Resolver yêu cầu các bản ghi DNSKEY chứa ZSK công khai và KSK công khai, các bản ghi này cũng trả về RRSIG cho DNSKEY RRset.
Xác minh RRSIG của RRset được yêu cầu với ZSK công khai.
Xác minh RRSIG của DNSKEY RRset bằng KSK công khai.
Hình 7: Key-Signing Key Identified
DNSKEY RRset và các bản ghi RRSIG tương ứng có thể được lưu vào bộ nhớ đệm, giúp các máy chủ định danh DNS giảm thiểu các yêu cầu không cần thiết và bảo vệ khỏi các cuộc tấn công liên tục.
Quá trình xác thực zone
Khi trình phân giải DNSSEC yêu cầu một loại bản ghi cụ thể, nó có thể lấy bản ghi DNSKEY chứa ZSK công khai từ máy chủ định danh Các thành phần này, bao gồm RRset, RRSIG và ZSK công khai, được sử dụng để xác nhận tính hợp lệ của các bản ghi DNS.
Chúng ta sử dụng khóa ký vùng riêng biệt (ZSK) và khóa ký chính (KSK) vì việc thay đổi KSK cũ hoặc bị xâm phạm rất khó khăn, trong khi việc thay đổi ZSK dễ dàng hơn Điều này cho phép sử dụng ZSK nhỏ hơn mà không ảnh hưởng đến bảo mật của máy chủ, đồng thời giảm thiểu lượng dữ liệu mà máy chủ phải gửi trong mỗi phản hồi Bản ghi DS đóng vai trò quan trọng trong việc thiết lập chuỗi tin cậy.
DNSSEC cung cấp bản ghi ký ủy quyền (DS) nhằm chuyển giao sự tin cậy từ vùng mẹ sang vùng con Nhà điều hành vùng sẽ băm bản ghi DNSKEY chứa khóa KSK công khai và gửi nó đến vùng mẹ để xuất bản dưới dạng bản ghi DS.
Domain Key Identify Mail
Domain Keys Identified Mail (DKIM) là một phương thức xác thực email nhằm ngăn chặn việc giả mạo địa chỉ người gửi Nó cho phép người nhận xác minh rằng email thực sự đến từ một tên miền cụ thể và rằng tên miền này đã được ủy quyền DKIM được thiết kế để bảo vệ người dùng khỏi các cuộc tấn công từ thư lừa đảo và email spam, giúp giảm thiểu nguy cơ lây nhiễm mã độc.
Hình 11: Domain Key Identify Mail
DKIM thực hiện hai chức năng chính: ký và xác minh Một trong những chức năng này có thể được xử lý bởi một mô-đun của tác nhân chuyển thư (MTA) Tổ chức ký kết có thể là người gửi thư trực tiếp như tác giả hoặc trang gửi, hoặc là người xử lý gián tiếp như dịch vụ hỗ trợ Các mô-đun ký sẽ chèn một hoặc nhiều trường tiêu đề DKIM-Signature, đại diện cho tổ chức tác giả hoặc nhà cung cấp dịch vụ gốc Việc xác minh thường được thực hiện bởi các mô-đun thay mặt cho tổ chức người nhận, có thể diễn ra tại mỗi bước gửi thư.
DKIM, hay DomainKeys Identified Mail, được hình thành từ sự kết hợp giữa "enhanced DomainKeys" của Yahoo và "Identified Internet Mail" của Cisco Sự sáp nhập này đã tạo nền tảng cho một loạt các tiêu chuẩn IETF và tài liệu hỗ trợ, dẫn đến STD 76, hiện đang được quy định trong RFC 6376 "Identified Internet Mail" của Cisco được đề xuất như một tiêu chuẩn xác thực thư dựa trên chữ ký, trong khi DomainKey của Yahoo được thiết kế để xác minh tên miền DNS của người gửi email và đảm bảo tính toàn vẹn của thư.
DomainKeys và các phần của Identified Internet Mail được kết hợp để tạo ra Thư được xác định tên miền (DKIM) Các nhà cung cấp dịch vụ nổi bật trong việc triển khai DKIM bao gồm Yahoo, Gmail, AOL và FastMail Tất cả các thư từ các tổ chức này đều cần có chữ ký DKIM.
Tùy theo hệ thống Mail server khác nhau sẽ có hướng dẫn khác nhau về cấu hình DKIM ở phía server, nhưng hầu hết đều phải thực hiện các bước:
Xử lý từ bên gửi
Bước 1: Sinh ra cặp khóa private/public, có nhiều phần mềm hỗ trợ việc này (ví dụ: OpenSSL)
Bước 2: Đưa khóa Public lên khai báo bản ghi TXT trên DNS theo đúng domain gửi email.
Bước 3: Cấu hình Mail server sử dụng khóa private để ký vào email trước khi gửi email Khóa này chỉ lưu trên Mail server nên không thể giả mạo.
Bước 1: Nhận được email từ bên gửi và thấy email có thông điệp được mã hóa do cấu hình DKIM.
Để xác nhận nguồn gốc của email, bước 2 là truy vấn DNS để lấy khóa công khai của miền gửi Nếu việc giải mã thành công, điều này chứng tỏ nguồn gửi hợp lệ và email được đảm bảo Ngược lại, bên nhận sẽ dựa vào chính sách của mình để quyết định từ chối hoặc chấp nhận email.
CÀI ĐẶT VÀ QUẢN TRỊ DNS SERVER TRÊN WINDOWS SERVER 2012 R2
Mô hình bài Lab
Các bước thực hiện
Bước 1: Cài đặt dịch vụ DNS trên Windows Server 2012 R2
- Đặt IP tĩnh cho máy chủ Windows
Hình 12: IP config Windows Server 2012
- Quản lí các dịch vụ trong mục Server manager Dashboard
Hình 13: Giao diện Server Manager
- Chọn Add roles and Features Chọn DNS Server
Hình 14: Tạo Role and Feature
- Vào Tools Chọn DNS để mở dịch vụ DNS Server
Bước 2: Tạo zone, thêm các bản ghi vào zone
- Giao diện của DNS Server có dạng như hình dưới Bao gồm các thư mục sau:
+ Forward Lookup Zones: Khai báo các zone truy vấn xuôi trong thư mục này và khai báo các bản ghi trong zone đó
+ Reverse Lookup Zone: Khai báo các zone truy vấn ngược và các bản ghi trong đó
+ Trust Point: Tạo các bản ghi để hình thành cơ chế bảo mật cho dịch vụ DNS
+ Conditional Forwarders: Tạo các điều kiện chuyển tiếp zone dữ liệu
Hình 17: Giao diện DNS Server
- Chuột phải vào Forward Lookup Zones New Zone… Primary Zone
- Khai báo tên cho zone, ở đây ta khai báo abc.com
Hình 19: Nhập tên Forward Zone
- Sau khi khai báo, ta truy cập vào Zone đó Chọn chuột phải và tạo một bản ghi A
Hình 20: Tạo các bản ghi trong Zone
- Nhập địa chỉ IP ứng với tên miền abc.com Add Host
Hình 21: Nhập địa chỉ IP cho bản ghi A
- Tương tự ta tạo một Reverse Zone và một bản ghi PTR trong thư mục Reverse Lookup Zones
Hình 23: Tạo bản ghi PTR
Bước 3: Kiểm tra dịch vụ DNS
- Kết nối máy Windows Server với mạng và máy Windows 7 vào mạng NAT Cấu hình địa chỉ IP của máy Windows 7 nhận IP máyWindows Server làm DNS Server
Hình 24: Đặt địa chỉ DNS Server cho máy client
- Mở CMD, thực hiện câu lệnh: nslookup abc.com và nslookup 192.168.1.100 Ta được kết quả
Hình 25: Kiểm tra dịch vụ trên máy client
CÀI ĐẶT QUẢN TRỊ DNS SERVER SỬ DỤNG BIND9
Các bước cài đặt
Bước 1: Cài đặt dịch vụ Bind9
- Sudo apt-get install bind9
Bước 2: Vào thư mục bind để cấu hình dịch vụ DNS
Hình 26: Cấu trúc file trong Bind9 DNS Server
Bước 3: Chỉnh sửa file named.conf.local để khai báo các zone
Hình 27: Sửa file name.config.local
Bước 4: Chỉnh sửa file name.conf.options Cấu hình forward sang DNS
Hình 28: Chỉnh sửa file name.conf.options
Bước 5: Tạo file forward.abc.com
Hình 29: Tạo Forward Zone và khai báo các bản ghi
Bước 6: Tạo file reverse.abc.com
Hình 30: Tạo reverse zone và khai báo các bản ghi
Bước 7: Khởi động lại dịch vụ và kiểm tra
Hình 31: Kiểm tra dịch vụ Bind9
- Tiến hành kiểm tra trên máy Windows 7 bằng lệnh nslookup
Hình 32: Kiểm tra dịch vụ DNS bằng máy client
DEMO MỘT DẠNG TẤN CÔNG HỆ THỐNG DNS
Mô hình tấn công DNS Spoofing
Hình 33: Mô hình tấn công DNS Spoofing
- Các công cụ sử dụng
+ setoolkit: clone website, capture username/password
+ ettercap: Scan hosts + ARP poisoning (ARP spoofing) + DNS spoofing + Sniff (nghe lén)
Bước 1: Kẻ tấn công cấu hình Ettercap và cấu hình máy Kali Linux để phục vụ tấn công
#echo 1 > /proc/sys/net/ipv4/ip_forward
Bước 2: Kẻ tấn công sử dụng công cụ Setoolkit để tạo fake website giống trang đăng nhập Google
- Khởi động setoolkit bằng câu lệnh setoolkit
- Chọn kiểu tấn công Social-Engineering Attacks
- Chọn Credential Harvester Exploit Menthod
- Tiến hành nhập IP máy Kali Linux
Hình 34: Sử dụng công cụ Setoolkit
Hình 35: Clone site thành công
Bước 3: Kẻ tấn công sử dụng công cụ Ettercap để tiến hành tấn công
- Tiến hành sửa file etter.dns
#vi /etc/ettercap/etter.dns
- Thêm các dòng google.com A 192.168.1.14
*.google.com 192.168.1.14 www.google.com PTR 192.168.1.14
- Add IP của default gateway vào Target 1
- Add IP của máy Victim vào Target 2
- Tiến hành ARP Spoofing để fake MAC
Hình 37: Kích hoạt ARP Spoofing
- Kích hoạt plugin DNS Spoofing bằng cách chọn Plugins Manage
Plugins và chọn kích hoạt dns_spoof
Hình 38: Kích hoạt plugin dns_spoofing
Khi truy cập google.com trên máy Windows 7, người dùng có thể gặp một trang web giả mạo giống hệt trang thật Tuy nhiên, nếu chú ý kỹ, có thể nhận thấy rằng trang web này không sử dụng giao thức mã hóa HTTPS.
- Kiểm tra trên Ettercap thấy thông báo đã giả mạo thành công địa chỉ www.google.com ứng với IP máy Kali Linux là 192.168.1.14
Sau khi đăng nhập, công cụ Setoolkit sẽ ngay lập tức trả về giá trị của hai ô nhập liệu là tên đăng nhập và mật khẩu Điều này cho phép chúng ta thu thập được thông tin Usename và Password từ người dùng.
Hình 41: Thu thập thông tin đăng nhập
