Hướng dẫn khắc phục lỗ hổng bảo mật CVE-2019-11477 trên Cloud365
Hướng dẫn khắc phục lỗ hổng bảo mật CVE-2019-11477 trên Cloud365
Nơi chứa các tài liệu tham khảo của dịch vụ Cloud365.
Ở bài trước thì chúng ta đã cùng nhau nói về giao thức DHCP trong mạng máy tính. Giao thức DHCP được thực hiện bởi 4 gói tin DISCOVERY OFFER REQUEST ACK. Trong KVM liệu nó có giống như vậy không? Kiểu mạng NAT và BRIDGE trong KVM có sử dụng giao thức DHCP giống nhau không? Chúng ta cùng nhau đi tìm hiểu ở bài này và cùng phân tích các gói tin mà DHCP sử dụng trong KVM là gì. Let’s go!
Để có thể thấy được cách thức hoạt động của kiểm mạng NAT trong KVM thì ở đây tôi sẽ tạo ra một VM và dùng lệnh tcpdump để bắt gói tin trong khi yêu cầu cấp địa chỉ IP như bài trước ta đã thực hiện.
đây là cấu trúc lệnh tcpdump mà tôi đã sử dụng ở bài này. Vì chúng ta lab nó ở trên VM nên ta sẽ chia sẻ file dhcp.pcap này ra host và sử dụng wireshark để đọc nó. để chia sẻ ra ngoài host ta sử dụng lệnh scp. Nếu như bạn chưa biết sử dụng lệnh scp thì bạn có thể tham khảo cách dùng của nó tại đây và tôi sử dụng dòng lệnh sau
scp dhcp.pcap anhduc@192.168.1.29:/home/anhduc
tôi sử dụng lệnh trên với mục đích chia sẻ tệp đó ra thư mục /home/anhduc và chúng ta cùng kiểm tra thư mục đó đã được copy ra ngoài chưa nào
Chúng ta đã chia sẻ thành công gói tin này ra ngoài PC của chúng ta. Bây giờ chúng ta hãy cùng kiểm tra lý thuyết ở bài trước xem có đúng không và cùng xem giao thức dhcp trong kiểm mạng NAT của KVM hoạt động ra sao bằng cách phân tích gói tin bằng wireshark
Đúng như lý thuyết thì giao thức DHCP đã sử dụng 4 gói tin ta đã nói trước đó để cấp phát địa chỉ IP cho chiếc VM của ta. Các bạn muốn biết được rằng ai là người đã cấp DHCP cho chiếc VM này của chúng ta thì hãy để ý vào gói tin ACK. Tại sao lại nhìn vào gói tin này? Bởi vì gói tin này là gói tin cuối cùng thông báo rằng PC có thể sử dụng được IP đó do đó nó sẽ ghi đầy đủ địa chỉ của DHCP server và DHCP client.
Như ta thấy thì ở đây có địa chỉ MAC của server và client là Src 52:54:00:d1:c5:a8 và Dst 52:54:00:cb:73:32 trong đó Src( địa chỉ nguồn) Dst( địa chỉ đích)
Thì cũng thấy Src 52:54:00:d1:c5:a8 chính là địa chỉ của server và là địa chỉ của NAT default tạo ra là virbr0 để cấp IP cho client. Vậy ta có thể kết luận rằng nơi mà cung cấp DHCP cho VM chính là Virtual Router cung cấp cho VM
Kịch bản mà ta thực hiện ở đây là. Ta sẽ tạo ra một host-kvm (VM có cài KVM) rồi tạo ra một VM trong đó và sử dụng mạng theo kiểu bridge (nếu như bạn chưa biết cách tạo một kiểu mạng bridge thì hãy xem nó tại đây). Và rồi ta dùng lệnh tcpdump giống như phần trên ta thực hiện với kiểu mạng NAT
Ta cần chuẩn bị một con VM bao gồm những yêu cầu sau
Đầu tiên ta phải cài một VM trong host-kvm và kiểu tra địa chỉ MAC của nó
Sau khi thấy được địa chỉ MAC (52:54:00:9a:a2:7d) của VM thì ta sẽ thực hiện lệnh tcpdump và các bước như đã làm với kiểu mạng NAT và ta sẽ thấy được kết quả như sau
Đây chính là gói tin mà tôi đã bắt được sau khi sử dụng kiểu mạng bridge. Chúng ta lại cùng nhìn vào gói tin ACK.
Như ta thấy thì Src 52:54:00:01:5d:4d và Dst là 52:54:00:9a:a2:7d trong đó Dst chính là client và là VM ta yêu cầu cấp IP còn src thì là MAC mà kiểu mạng NAT tạo ra cho Host KVM chứ không. nó là người cấp DHCP cho VM chứ không phải card do bridge tạo ra.
Ta thấy được sự khác biệt của NAT MODE và Bridge MODE trong KVM là. Khi sử dụng kiểu mạng NAT thì nơi cấp DHCP cho VM chính là NAT cấp cho VM. Còn khi sử dụng kiểu mạng bridge thì Bridge không thể cấp DHCP cho VM mà router nơi ta cắm mạng vào PC mới có thể cấp DHCP.
Chúc các bạn thành công!
Thực hiện bởi cloud365
Written by Nguyễn Anh Đức