PHẦN 1: TÌM HIỂU VỀ HỆ THỐNG DNSDNS là Hệ thống phân giải tên miền, viết tắt của Domain NameServers, nó "dịch" tên miền Internet và tên máy chủ sang địa chỉ IPgiúp các máy chủ và thiết b
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, là một công nghệ quan trọng giúp chuyển đổi tên miền Internet và tên máy chủ thành địa chỉ IP, cho phép các máy chủ và thiết bị mạng giao tiếp với nhau Khi người dùng nhập tên miền vào thanh địa chỉ của trình duyệt web, DNS tự động thực hiện quá trình này để truy cập các trang web một cách dễ dàng.
Khi trình duyệt "dịch" địa chỉ IP, người dùng có thể dễ dàng đăng nhập vào website mà không cần nhớ dãy số IP phức tạp Thay vào đó, chỉ cần nhập tên miền của website, trình duyệt sẽ tự động nhận diện và truy cập.
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 mọi kết nối Khi bạn truy cập vào một trang web hoặc gửi email, hệ thống DNS đóng vai trò quan trọng trong quá trình này.
Trong thế giới rộng lớn của internet, việc ghi nhớ từng dãy số địa chỉ IP là điều không khả thi Chính 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 chức năng 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 hơn 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ây phân cấp, bắt đầu từ tên miền gốc DNS Vùng DNS khởi đầu từ một miền trong câ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.
DNS file zone là tệp văn bản thuần túy lưu trữ trên máy chủ DNS, chứa bản đại diện cho vùng và tất cả các bản ghi của mọi miền trong vùng Tệp này luôn bắt đầu bằng bản ghi Start of Authority (SOA), cung cấp thông tin quan trọng, bao gồm thông tin liên hệ của người quản trị vùng.
1.2.2 Resource Record (Các bản ghi DNS)
RR, hay còn gọi là Resource Record, là mẫu thông tin dùng để mô tả các thông tin liên quan đến DNS Những mẫu thông tin này được lưu trữ trong các zone file thuộc các zone DNS.
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) Việc cập nhật các bản ghi DNS định kỳ là cần thiết khi có tên miền mới hoặc khi có thay đổi ở tên miền cũ Nếu không được cập nhật, hệ thống sẽ 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.
Resource Record là một bản ghi đơn trong hệ thống DNS, cung cấp thông tin chi tiết về các dữ liệu Các bản ghi này được định dạng dưới dạng văn bản đơn giản, giúp dễ dàng quản lý và tra cứu thông tin.
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ỏ về 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 được xem là dấu hiệu nhận biết của hệ thống đối với tên miền, và 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 (
Bản ghi SOA (Start of Authority) bao gồm các thành phần quan trọng như masterdns.hiennt.com, đại diện cho giá trị DNS chính của tên miền, và admin.hiennt.com, được chuyển đổi từ địa chỉ email admin@hiennt.com, thể hiện chủ sở hữu của tên miền này.
Số serial trong dữ liệu zone phải có định 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 trong ngày, luôn tăng lên mỗi lần có sự thay đổi Khi Slave DNS Server kết nối với Master DNS Server, nó sẽ kiểm tra số serial Nếu số serial của Slave thấp hơn Master, điều này có nghĩa là dữ liệu zone trên Slave đã lỗi thời, và Slave sẽ tiến hành sao chép dữ liệu mới từ Master để cập nhật.
The Refresh interval indicates the duration in which a Slave DNS Server checks the zone data on the Master Server for necessary updates This value varies depending on the frequency of changes made to 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ẽ bị quá hạn Khi dữ liệu này quá hạn, Slave 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 để 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, do đó, tối thiểu hai bản ghi NS là bắt buộc cho mỗi tên miền.
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, và các tên miền cấp dưới của thuyhiend.space sẽ được khai báo 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ừ một domain thành địa chỉ IP, giúp người dùng truy cập website 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.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 một website bằng cách nhập tên miền vào trình duyệt (ví dụ: qldt.ptit.edu.vn), máy chủ DNS sẽ đầu tiên tra cứu thông tin phân giải trong file hosts, một tệp tin 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 thông tin từ phần cứng hoặc phần mềm Các vị trí lưu trữ 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 nhận được thông tin cần thiết, 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ề một tên miền cụ thể, 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ủ tên miền 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 Khi nhận được yêu cầu, máy chủ vnn.vn sẽ tra cứu cơ sở dữ liệu và gửi lại địa chỉ IP tương ứng Cuối cùng, máy chủ tên miền cục bộ sẽ chuyển thông tin này đến người sử dụng, cho phép họ kết nối đến server chứa trang web qldt.ptit.edu.vn thông qua địa chỉ IP đã được cung cấp.
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áy chủ chịu trách nhiệm giao tiếp với các máy chủ khác để phản hồi yêu cầu từ trình duyệt người dùng Nó hoạt động như một nhân viên chăm chỉ, thực hiện nhiệm vụ lấy 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ợ.
Máy chủ DNS gốc, hay còn gọi là nameserver, là thành phần 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 ví như một thư viện giúp định hướng tìm kiếm thông tin một cách 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 tên miền cấp cao (top-level domain) Các máy chủ quản lý loại tên miền 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 các 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ủ Name Server Authoritative là nguồn chính thức lưu trữ dữ liệu liên quan đến tên miền này.
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ỉ tương ứng, cung cấp cho recursive resolver địa chỉ IP cần thiết từ danh sách các bản ghi của nó.
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 kỹ thuật tấn công nhằm chiếm quyền điều khiển DNS Cache và thay đổi các giá trị, thông tin bên trong thành thông tin giả mạo Kịch bản tấn công này có thể dẫn đến việc người dùng bị chuyển hướng đến các trang web độc hại mà không hay biết.
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 địa chỉ IP tương ứng với tên miền này và trả về thông tin, giúp website www.facebook.com hiển thị đầy đủ trên màn hình.
Một tên miền có thể liên kết với nhiều địa chỉ IP, và khi bạn thường xuyên truy cập www.facebook.com, hệ thống sẽ lưu trữ thông tin này để tăng tốc độ truy cập trong tương lai 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 cho trang web 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.
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 Cụ thể, 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 có một địa chỉ IP tương ứng, và nhiệm vụ chính của DNS là phân giải, 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 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 thật sự do ICANN quản lý.
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 dạng 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 ngập 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 một trang web, DNS chuyển đổi tên miền thành địa chỉ IP Nếu bạn nhập một tên miền không tồn tại, như 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 sẽ tiêu tốn thời gian quý giá để tìm kiếm kết quả, sử dụng bộ nhớ cache và sức mạnh xử lý của CPU, trước khi trả về thông báo lỗi 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 nhanh chóng làm tắc nghẽn bộ nhớ cache của máy chủ DNS, gây ra tình trạng 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 máy chủ có quảng cáo nhúng, thay vì trả lại 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 kiếm 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 toàn mở rộng 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 từng zone dữ liệu nhằm đảm bảo toàn vẹn dữ liệu Khác với giao thức DNS thông thường, DNSSEC giúp ngăn chặn nguy cơ giả mạo và làm sai lệch dữ liệu trong các tương tác giữa máy chủ DNS, máy trạm (resolver) và máy chủ chuyển tiếp (forwarder) Công nghệ này đã được nghiên cứu và triển khai để bảo vệ DNS khỏi các mối đe dọa giả mạo, đảm bảo nguồn dữ liệu chính xác và đáng tin cậy.
DNSSEC là một công nghệ an toàn mở rộng cho hệ thống DNS, cung cấp cơ chế xác thực và đảm bảo tính toàn vẹn của 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 hệ thống 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 NSEC 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 hệ thống DNS, giúp thiết lập chứng thực giữa các zone dữ liệu Nó được sử dụng để ký xác thực trong quá trình chuyển giao DNS, đảm bảo tính toàn vẹn và bảo mật cho thông tin trong mạng lưới.
DNSSEC nhằm đảm bảo rằng quá trình truyền dữ liệu DNS không bị thay đổi và duy trì sự chuyển giao từ các máy chủ DNS cấp cao xuống cấp thấp Đồng thời, 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.
DNSSEC đã cải thiện tính bảo mật và độ tin cậy của hệ thống DNS thông qua việc tổ chức các bản ghi mới và chỉnh sửa giao thức, nhằm chứng thực nguồn gốc và tính toàn vẹn của dữ liệu Hệ thống này không chỉ đáp ứng yêu cầu thông tin định tuyến tên miền và giao thức giữa các máy chủ DNS, mà còn tăng cường khả năng bảo mật và dự phòng cho hệ thống Quá trình ký vùng bằng khóa Zone-Signing Key là một phần quan trọng trong cơ chế bảo mật của DNSSEC.
Mỗi vùng trong DNSSEC sử dụng một cặp khóa ký vùng (ZSK) gồm phần riêng để ký điện tử cho 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 trên máy chủ định danh dưới dạng bản ghi RRSIG.
Các bản ghi RRSIG không có giá trị nếu không có phương thức xác minh chữ ký từ trình phân giải DNS Để đảm bảo tính toàn vẹn, 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 thông qua bản ghi DNSKEY Quá trình ký khóa sử dụng Key-Signing Key là cần thiết để thực hiện điều này.
Máy chủ định danh DNSSEC không chỉ sử dụng khóa ký vùng mà còn có khóa ký khóa (KSK) KSK thực hiện việc xác thực bản ghi DNSKEY tương tự như ZSK đã đảm bảo các RRsets trong phần trước, bằng cách ký công khai ZSK (được lưu trữ trong bản ghi DNSKEY) và tạo RRSIG cho DNSKEY.
KSK công khai, giống như ZSK công khai, được xuất bản bởi máy chủ định danh trong một bản ghi DNSKEY khác, tạo thành DNSKEY RRset Cả KSK công khai và ZSK công khai đều được ký bởi KSK tư nhân Người phân giải có thể sử dụng KSK công khai để xác thực ZSK công khai trong quá trình xác thực các bản ghi.
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.
Để xử lý yêu cầu, cần truy xuất các bản ghi DNSKEY bao gồm ZSK công khai và KSK công khai, kèm theo RRSIG cho RRset DNSKEY Tiếp theo, tiến hành xác minh RRSIG của RRset bằng ZSK công khai và xác minh RRSIG của DNSKEY RRset bằng KSK công khai.
Bộ nhớ đệm các bản ghi DNSKEY RRset và RRSIG tương ứng giúp các máy chủ định danh DNS tránh bị tấn công liên tục bởi các yêu cầu không cần thiết.
Quá trình xác thực zone
Khi trình phân giải DNSSEC yêu cầu bản ghi cụ thể như AAAA, máy chủ định danh sẽ cung cấp RRSIG tương ứng Tiếp theo, trình phân giải lấy bản ghi DNSKEY chứa ZSK công khai từ máy chủ định danh Từ đó, RRset, RRSIG và ZSK công khai được sử dụng để xác thực các bản ghi.
Chúng ta sử dụng khóa ký vùng riêng biệt (ZSK) và khóa ký chính (KSK) để bảo đảm an toàn cho hệ thống tên miền 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 lại dễ dàng hơn nhiều Điều này cho phép sử dụng ZSK nhỏ hơn mà không làm giảm 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 cạnh đó, 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 KSK công khai và gửi nó đến vùng mẹ để được xuất bản dưới dạng bản ghi DS.
Domain Key Identify Mail
Domain Keys Identified Mail (DKIM) là 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 DKIM cho phép người nhận kiểm tra xem email có thực sự đến từ tên miền cụ thể và liệu tên miền đó có được ủy quyền hay không Phương thức này rất quan trọng trong việc bảo vệ người dùng khỏi các mối đe dọa như thư lừa đảo và email spam, cũng như các mã độc tấn công.
Hình 11: Domain Key Identify Mail 3.2.2 Ứng dụng
DKIM thực hiện hai chức năng chính: chữ ký và xác minh Một trong hai chức năng này có thể được xử lý bởi một mô-đun trong 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à một dịch vụ độc lập hỗ trợ cho người gửi 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ụ 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 nhận, có thể diễn ra tại mọi bước trong quá trình 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 thông số kỹ thuật theo tiêu chuẩn IETF, dẫn đến STD 76, hiện được quy định bởi RFC 6376 “Identified Internet Mail” do Cisco đề xuất nhằm 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 và đảm bảo tính toàn vẹn của thư.
DomainKeys và các thành phần của Internet Mail được kết hợp để hình thành Thư được xác định tên miền (DKIM) Các nhà cung cấp dịch vụ nổi bật như Yahoo, Gmail, AOL và FastMail đều triển khai DKIM, yêu cầu tất cả thư từ các tổ chức này phải 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.
Bước 2: Thực hiện truy vấn DNS để lấy khóa công khai của miền gửi, nhằm giải mã thông tin Nếu quá trình giải mã thành công, nguồn gửi và nội dung email sẽ được xác nhận Ngược lại, bên nhận sẽ căn cứ 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
+ Global Log: Ghi lại nhật kí, các logs của DNS Server
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
Mô hình bài lab
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 ServerBướ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 Google
Hình 28: Chỉnh sửa file name.conf.optionsBướ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 DNS Spoofing
- 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
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 ra 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
Hình 40: DNS spoof thành công
Để bắt đầu, người dùng cần đăng nhập vào công cụ Setoolkit, sau đó công cụ này sẽ trả về giá trị từ hai ô nhập liệu là tên đăng nhập và mật khẩu Như vậy, 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