ເລື່ອງກ່ຽວກັບແພັກເກັດ DNS ທີ່ຂາດຫາຍໄປຈາກການຊ່ວຍເຫຼືອດ້ານວິຊາການຂອງ Google Cloud

ຈາກ Google Blog Editor: ທ່ານເຄີຍສົງໄສວ່າວິສະວະກອນ Google Cloud Technical Solutions (TSE) ຈັດການກັບການຮ້ອງຂໍການຊ່ວຍເຫຼືອຂອງທ່ານແນວໃດ? ວິສະວະກອນສະຫນັບສະຫນູນດ້ານວິຊາການ TSE ມີຄວາມຮັບຜິດຊອບໃນການກໍານົດແລະແກ້ໄຂແຫຼ່ງທີ່ຜູ້ໃຊ້ລາຍງານບັນຫາ. ບາງບັນຫາເຫຼົ່ານີ້ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ, ແຕ່ບາງຄັ້ງທ່ານພົບປີ້ທີ່ຮຽກຮ້ອງໃຫ້ມີຄວາມສົນໃຈຂອງວິສະວະກອນຫຼາຍຄັ້ງໃນເວລາດຽວກັນ. ໃນບົດຄວາມນີ້, ຫນຶ່ງໃນພະນັກງານ TSE ຈະບອກພວກເຮົາກ່ຽວກັບບັນຫາທີ່ຫຍຸ້ງຍາກຫຼາຍຈາກການປະຕິບັດທີ່ຜ່ານມາຂອງລາວ - ກໍລະນີຂອງແພັກເກັດ DNS ທີ່ຂາດຫາຍໄປ. ໃນເລື່ອງນີ້, ພວກເຮົາຈະເບິ່ງວ່າວິສະວະກອນຈັດການແນວໃດເພື່ອແກ້ໄຂສະຖານະການ, ແລະສິ່ງທີ່ພວກເຂົາຮຽນຮູ້ໃຫມ່ໃນຂະນະທີ່ແກ້ໄຂຂໍ້ຜິດພາດ. ພວກເຮົາຫວັງວ່າເລື່ອງນີ້ບໍ່ພຽງແຕ່ຈະໃຫ້ຄວາມຮູ້ແກ່ເຈົ້າກ່ຽວກັບຂໍ້ບົກພ່ອງທີ່ຝັງເລິກເທົ່ານັ້ນ, ແຕ່ຍັງໃຫ້ຄວາມເຂົ້າໃຈແກ່ເຈົ້າກ່ຽວກັບຂະບວນການທີ່ເຂົ້າສູ່ການຍື່ນປີ້ຊ່ວຍເຫຼືອກັບ Google Cloud.

ການແກ້ໄຂບັນຫາແມ່ນທັງວິທະຍາສາດແລະສິລະປະ. ມັນທັງຫມົດເລີ່ມຕົ້ນດ້ວຍການສ້າງສົມມຸດຕິຖານກ່ຽວກັບເຫດຜົນສໍາລັບພຶດຕິກໍາທີ່ບໍ່ແມ່ນມາດຕະຖານຂອງລະບົບ, ຫຼັງຈາກນັ້ນມັນໄດ້ຖືກທົດສອບຄວາມເຂັ້ມແຂງ. ຢ່າງໃດກໍ່ຕາມ, ກ່ອນທີ່ພວກເຮົາຈະສ້າງສົມມຸດຕິຖານ, ພວກເຮົາຕ້ອງກໍານົດບັນຫາຢ່າງຈະແຈ້ງແລະຊັດເຈນ. ຖ້າຄໍາຖາມສຽງບໍ່ຊັດເຈນເກີນໄປ, ຫຼັງຈາກນັ້ນທ່ານຈະຕ້ອງວິເຄາະທຸກຢ່າງຢ່າງລະມັດລະວັງ; ນີ້ແມ່ນ "ສິລະປະ" ຂອງການແກ້ໄຂບັນຫາ.

ພາຍໃຕ້ Google Cloud, ຂະບວນການດັ່ງກ່າວກາຍເປັນຕົວຊີ້ບອກທີ່ສັບສົນຂຶ້ນ, ເນື່ອງຈາກ Google Cloud ພະຍາຍາມສຸດຄວາມສາມາດເພື່ອຮັບປະກັນຄວາມເປັນສ່ວນຕົວຂອງຜູ້ໃຊ້ຂອງມັນ. ເນື່ອງຈາກວ່ານີ້, ວິສະວະກອນ TSE ບໍ່ສາມາດເຂົ້າເຖິງການແກ້ໄຂລະບົບຂອງທ່ານ, ຫຼືຄວາມສາມາດໃນການເບິ່ງການຕັ້ງຄ່າຢ່າງກວ້າງຂວາງຄືກັບຜູ້ໃຊ້. ດັ່ງນັ້ນ, ເພື່ອທົດສອບສົມມຸດຕິຖານໃດໆຂອງພວກເຮົາ, ພວກເຮົາ (ວິສະວະກອນ) ບໍ່ສາມາດປັບປຸງລະບົບໄດ້ໄວ.

ຜູ້ໃຊ້ບາງຄົນເຊື່ອວ່າພວກເຮົາຈະແກ້ໄຂທຸກຢ່າງເຊັ່ນ: ກົນຈັກໃນການບໍລິການລົດ, ແລະພຽງແຕ່ສົ່ງ id ຂອງເຄື່ອງ virtual ໃຫ້ພວກເຮົາ, ໃນຂະນະທີ່ໃນຄວາມເປັນຈິງຂະບວນການເກີດຂຶ້ນໃນຮູບແບບການສົນທະນາ: ການລວບລວມຂໍ້ມູນ, ການສ້າງແລະຢືນຢັນ (ຫຼືປະຕິເສດ) hypotheses, ແລະ, ໃນທີ່ສຸດ, ບັນຫາການຕັດສິນໃຈແມ່ນອີງໃສ່ການສື່ສານກັບລູກຄ້າ.

ບັນຫາຢູ່ໃນຄໍາຖາມ

ມື້​ນີ້​ພວກ​ເຮົາ​ມີ​ເລື່ອງ​ທີ່​ມີ​ຕອນ​ທ້າຍ​ທີ່​ດີ​. ຫນຶ່ງໃນເຫດຜົນສໍາລັບການແກ້ໄຂສົບຜົນສໍາເລັດຂອງກໍລະນີທີ່ສະເຫນີແມ່ນລາຍລະອຽດຫຼາຍແລະຖືກຕ້ອງຂອງບັນຫາ. ຂ້າງລຸ່ມນີ້ທ່ານສາມາດເບິ່ງສໍາເນົາຂອງປີ້ທໍາອິດ (ແກ້ໄຂເພື່ອຊ່ອນຂໍ້ມູນລັບ):

ຂໍ້ຄວາມນີ້ມີຂໍ້ມູນທີ່ເປັນປະໂຫຍດຫຼາຍສໍາລັບພວກເຮົາ:

• ລະບຸ VM ສະເພາະ
• ບັນຫາຕົວມັນເອງແມ່ນຊີ້ໃຫ້ເຫັນ - DNS ບໍ່ເຮັດວຽກ
• ມັນໄດ້ຖືກຊີ້ບອກບ່ອນທີ່ບັນຫາສະແດງໃຫ້ເຫັນຕົວຂອງມັນເອງ - VM ແລະ container
• ຂັ້ນຕອນທີ່ຜູ້ໃຊ້ປະຕິບັດເພື່ອກໍານົດບັນຫາແມ່ນຊີ້ໃຫ້ເຫັນ.

ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ໄດ້​ຮັບ​ການ​ຈົດ​ທະ​ບຽນ​ເປັນ "P1​: ຜົນ​ກະ​ທົບ​ທີ່​ສໍາ​ຄັນ - ການ​ບໍ​ລິ​ການ​ບໍ່​ສາ​ມາດ​ນໍາ​ໃຊ້​ໃນ​ການ​ຜະ​ລິດ​"​, ຊຶ່ງ​ຫມາຍ​ຄວາມ​ວ່າ​ການ​ຕິດ​ຕາມ​ສະ​ຖາ​ນະ​ການ​ຄົງ​ທີ່ 24/7 ຕາມ​ໂຄງ​ການ "ເຮັດ​ຕາມ​ດວງ​ຕາ​ເວັນ​" (ທ່ານ​ສາ​ມາດ​ອ່ານ​ເພີ່ມ​ເຕີມ​ກ່ຽວ​ກັບ​ການ ບູລິມະສິດຂອງຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້), ດ້ວຍການຍົກຍ້າຍຂອງມັນຈາກທີມງານສະຫນັບສະຫນູນດ້ານວິຊາການຫນຶ່ງໄປຫາຄົນອື່ນດ້ວຍການປ່ຽນເຂດເວລາແຕ່ລະຄົນ. ໃນຄວາມເປັນຈິງ, ເມື່ອບັນຫາມາຮອດທີມງານຂອງພວກເຮົາໃນ Zurich, ມັນໄດ້ອ້ອມຮອບໂລກແລ້ວ. ໃນເວລານີ້, ຜູ້ໃຊ້ໄດ້ປະຕິບັດມາດຕະການຫຼຸດຜ່ອນ, ແຕ່ຢ້ານວ່າສະຖານະການການຜະລິດເກີດຂື້ນອີກ, ເພາະວ່າສາເຫດຂອງຮາກຍັງບໍ່ທັນຖືກຄົ້ນພົບ.

ເມື່ອປີ້ມາຮອດ Zurich, ພວກເຮົາມີຂໍ້ມູນຕໍ່ໄປນີ້ຢູ່ໃນມືແລ້ວ:

• ເນື້ອຫາ /etc/hosts
• ເນື້ອຫາ /etc/resolv.conf
• ສະຫລຸບ iptables-save
• ປະກອບໂດຍທີມງານ ngrep ໄຟລ໌ pcap

ດ້ວຍຂໍ້ມູນນີ້, ພວກເຮົາພ້ອມທີ່ຈະເລີ່ມຕົ້ນ "ການສືບສວນ" ແລະໄລຍະການແກ້ໄຂບັນຫາ.

ຂັ້ນຕອນທໍາອິດຂອງພວກເຮົາ

ກ່ອນອື່ນ ໝົດ, ພວກເຮົາໄດ້ກວດເບິ່ງບັນທຶກແລະສະຖານະຂອງເຄື່ອງແມ່ຂ່າຍ metadata ແລະໃຫ້ແນ່ໃຈວ່າມັນເຮັດວຽກຢ່າງຖືກຕ້ອງ. ເຄື່ອງແມ່ຂ່າຍ metadata ຕອບສະຫນອງກັບທີ່ຢູ່ IP 169.254.169.254 ແລະ, ໃນບັນດາສິ່ງອື່ນໆ, ມີຄວາມຮັບຜິດຊອບໃນການຄວບຄຸມຊື່ໂດເມນ. ພວກເຮົາຍັງໄດ້ກວດເບິ່ງສອງຄັ້ງວ່າໄຟວໍເຮັດວຽກຢ່າງຖືກຕ້ອງກັບ VM ແລະບໍ່ໄດ້ບລັອກແພັກເກັດ.

ມັນເປັນບາງບັນຫາທີ່ແປກປະຫລາດ: ການກວດສອບ nmap ໄດ້ປະຕິເສດການສົມມຸດຕິຖານຕົ້ນຕໍຂອງພວກເຮົາກ່ຽວກັບການສູນເສຍແພັກເກັດ UDP, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງຄິດເຖິງທາງເລືອກແລະວິທີການຫຼາຍເພື່ອກວດເບິ່ງພວກມັນ:

• ແພັກເກັດຖືກຫຼຸດລົງຢ່າງເລືອກບໍ? => ກວດເບິ່ງກົດລະບຽບ iptables
• ມັນນ້ອຍເກີນໄປບໍ? ບຸກຄົນ? => ກວດເບິ່ງຜົນຜະລິດ ip a show
• ບັນຫາມີຜົນກະທົບພຽງແຕ່ແພັກເກັດ UDP ຫຼື TCP ເຊັ່ນກັນບໍ? => ຂັບໄລ່ dig +tcp
• ແພັກເກັດທີ່ສ້າງຂຶ້ນໃນຂຸດຖືກສົ່ງຄືນບໍ? => ຂັບໄລ່ tcpdump
• libdns ເຮັດວຽກຢ່າງຖືກຕ້ອງບໍ? => ຂັບໄລ່ strace ເພື່ອກວດສອບການສົ່ງຂອງແພັກເກັດທັງສອງທິດທາງ

ໃນທີ່ນີ້ພວກເຮົາຕັດສິນໃຈໂທຫາຜູ້ໃຊ້ເພື່ອແກ້ໄຂບັນຫາສົດໆ.

ໃນ​ລະ​ຫວ່າງ​ການ​ໂທ​, ພວກ​ເຮົາ​ສາ​ມາດ​ກວດ​ສອບ​ຫຼາຍ​ຢ່າງ​:

• ຫຼັງຈາກການກວດສອບຫຼາຍໆຄັ້ງພວກເຮົາຍົກເວັ້ນກົດລະບຽບ iptables ຈາກບັນຊີລາຍຊື່ຂອງເຫດຜົນ
• ພວກເຮົາກວດເບິ່ງການເຊື່ອມຕໍ່ເຄືອຂ່າຍ ແລະຕາຕະລາງການກຳນົດເສັ້ນທາງ, ແລະກວດເບິ່ງຄືນວ່າ MTU ແມ່ນຖືກຕ້ອງ
• ພວກເຮົາຄົ້ນພົບວ່າ dig +tcp google.com (TCP) ເຮັດວຽກຕາມທີ່ມັນຄວນ, ແຕ່ dig google.com (UDP) ບໍ່ເຮັດວຽກ
• ​ໄດ້​ຂັບ​ໄລ່​ອອກ​ໄປ tcpdump ມັນຍັງເຮັດວຽກຢູ່ dig, ພວກເຮົາພົບວ່າແພັກເກັດ UDP ຖືກສົ່ງຄືນ
• ພວກເຮົາຂັບລົດອອກໄປ strace dig google.com ແລະພວກເຮົາເບິ່ງວິທີການຂຸດຄົ້ນຢ່າງຖືກຕ້ອງໂທຫາ sendmsg() и recvms()ຢ່າງໃດກໍຕາມ, ອັນທີສອງຖືກລົບກວນໂດຍການຫມົດເວລາ

ແຕ່ຫນ້າເສຍດາຍ, ການສິ້ນສຸດຂອງການປ່ຽນແປງມາຮອດແລະພວກເຮົາຖືກບັງຄັບໃຫ້ເລັ່ງບັນຫາໄປສູ່ເຂດເວລາຕໍ່ໄປ. ການຮ້ອງຂໍ, ແນວໃດກໍ່ຕາມ, ກະຕຸ້ນຄວາມສົນໃຈໃນທີມງານຂອງພວກເຮົາ, ແລະເພື່ອນຮ່ວມງານແນະນໍາການສ້າງຊຸດ DNS ເບື້ອງຕົ້ນໂດຍໃຊ້ໂມດູນ Python ທີ່ຂູດຮີດ.

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

fragment ນີ້ສ້າງແພັກເກັດ DNS ແລະສົ່ງຄໍາຮ້ອງຂໍໄປຍັງເຄື່ອງແມ່ຂ່າຍ metadata.

ຜູ້ໃຊ້ດໍາເນີນການລະຫັດ, ການຕອບສະຫນອງ DNS ຖືກສົ່ງຄືນ, ແລະແອັບພລິເຄຊັນໄດ້ຮັບມັນ, ຢືນຢັນວ່າບໍ່ມີບັນຫາໃນລະດັບເຄືອຂ່າຍ.

ຫຼັງຈາກ "ການເດີນທາງທົ່ວໂລກ" ອີກຄັ້ງຫນຶ່ງ, ການຮ້ອງຂໍກັບຄືນໄປຫາທີມງານຂອງພວກເຮົາ, ແລະຂ້ອຍໂອນມັນໃຫ້ຕົວເອງຢ່າງສົມບູນ, ຄິດວ່າມັນຈະສະດວກກວ່າສໍາລັບຜູ້ໃຊ້ຖ້າຄໍາຮ້ອງຂໍຢຸດເຊົາການວຽນຈາກບ່ອນອື່ນ.

ໃນເວລານີ້, ຜູ້ໃຊ້ຕົກລົງເຫັນດີທີ່ຈະໃຫ້ຮູບພາບຂອງລະບົບ. ນີ້ແມ່ນຂ່າວດີຫຼາຍ: ຄວາມສາມາດໃນການທົດສອບລະບົບດ້ວຍຕົນເອງເຮັດໃຫ້ການແກ້ໄຂບັນຫາໄວຂຶ້ນ, ເພາະວ່າຂ້ອຍບໍ່ຈໍາເປັນຕ້ອງຂໍໃຫ້ຜູ້ໃຊ້ດໍາເນີນການຄໍາສັ່ງ, ສົ່ງຜົນໄດ້ຮັບແລະວິເຄາະໃຫ້ເຂົາເຈົ້າ, ຂ້ອຍສາມາດເຮັດທຸກຢ່າງດ້ວຍຕົນເອງ!

ເພື່ອນຮ່ວມງານຂອງຂ້ອຍເລີ່ມອິດສາຂ້ອຍເລັກນ້ອຍ. ໃນໄລຍະອາຫານທ່ຽງ ພວກເຮົາສົນທະນາກ່ຽວກັບການປ່ຽນໃຈເຫລື້ອມໃສ, ແຕ່ບໍ່ມີໃຜຄິດວ່າມີຫຍັງເກີດຂຶ້ນ. ໂຊກດີ, ຜູ້ໃຊ້ເອງໄດ້ໃຊ້ມາດຕະການເພື່ອຫຼຸດຜ່ອນຜົນສະທ້ອນແລະບໍ່ຮີບຮ້ອນ, ດັ່ງນັ້ນພວກເຮົາມີເວລາທີ່ຈະຕັດບັນຫາ. ແລະນັບຕັ້ງແຕ່ພວກເຮົາມີຮູບພາບ, ພວກເຮົາສາມາດດໍາເນີນການທົດສອບໃດໆທີ່ພວກເຮົາສົນໃຈ. ຍິ່ງໃຫຍ່!

ຖອຍຫຼັງ

ຫນຶ່ງໃນຄໍາຖາມສໍາພາດທີ່ນິຍົມຫຼາຍທີ່ສຸດສໍາລັບຕໍາແຫນ່ງວິສະວະກອນລະບົບແມ່ນ: "ຈະເກີດຫຍັງຂຶ້ນເມື່ອທ່ານ ping wwwgooglecom? ຄໍາຖາມແມ່ນດີຫຼາຍ, ນັບຕັ້ງແຕ່ຜູ້ສະຫມັກຕ້ອງການອະທິບາຍທຸກສິ່ງທຸກຢ່າງຈາກ shell ກັບພື້ນທີ່ຜູ້ໃຊ້, ກັບ kernel ຂອງລະບົບແລະຫຼັງຈາກນັ້ນກັບເຄືອຂ່າຍ. ຂ້ອຍຍິ້ມ: ບາງເທື່ອຄຳຖາມສໍາພາດກໍ່ເປັນປະໂຫຍດໃນຊີວິດຈິງ...

ຂ້ອຍຕັດສິນໃຈໃຊ້ຄໍາຖາມ HR ນີ້ກັບບັນຫາໃນປະຈຸບັນ. ເວົ້າປະມານ, ເມື່ອທ່ານພະຍາຍາມກໍານົດຊື່ DNS, ຕໍ່ໄປນີ້ຈະເກີດຂຶ້ນ:

1. ແອັບພລິເຄຊັນເອີ້ນຫ້ອງສະຫມຸດລະບົບເຊັ່ນ libdns
2. libdns ກວດເບິ່ງການຕັ້ງຄ່າລະບົບທີ່ DNS server ມັນຄວນຈະຕິດຕໍ່ (ໃນແຜນວາດນີ້ແມ່ນ 169.254.169.254, metadata server)
3. libdns ໃຊ້ການໂທລະບົບເພື່ອສ້າງຊັອກເກັດ UDP (SOKET_DGRAM) ແລະສົ່ງແພັກເກັດ UDP ດ້ວຍການສອບຖາມ DNS ໃນທັງສອງທິດທາງ.
4. ໂດຍຜ່ານການໂຕ້ຕອບ sysctl ທ່ານສາມາດກໍາຫນົດຄ່າ UDP stack ໃນລະດັບແກ່ນ
5. kernel ພົວພັນກັບຮາດແວເພື່ອສົ່ງແພັກເກັດຜ່ານເຄືອຂ່າຍໂດຍຜ່ານການໂຕ້ຕອບເຄືອຂ່າຍ
6. hypervisor ຈັບແລະສົ່ງແພັກເກັດໄປຫາເຄື່ອງແມ່ຂ່າຍ metadata ເມື່ອຕິດຕໍ່ກັບມັນ
7. ເຊີບເວີ metadata, ໂດຍ magic ຂອງມັນ, ກໍານົດຊື່ DNS ແລະສົ່ງຄືນຄໍາຕອບໂດຍໃຊ້ວິທີດຽວກັນ

ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າສົມມຸດຕິຖານໃດທີ່ພວກເຮົາໄດ້ພິຈາລະນາແລ້ວ:

ສົມມຸດຕິຖານ: ຫ້ອງສະຫມຸດຫັກ

• ການທົດສອບ 1: ແລ່ນ strace ໃນລະບົບ, ກວດເບິ່ງວ່າ dig ໂທຫາລະບົບທີ່ຖືກຕ້ອງ
• ຜົນໄດ້ຮັບ: ການໂທລະບົບທີ່ຖືກຕ້ອງຖືກເອີ້ນ
• ການທົດສອບ 2: ການນໍາໃຊ້ srapy ເພື່ອກວດເບິ່ງວ່າພວກເຮົາສາມາດກໍານົດຊື່ bypassing ຫ້ອງສະຫມຸດລະບົບ
• ຜົນໄດ້ຮັບ: ພວກເຮົາສາມາດເຮັດໄດ້
• ການທົດສອບ 3: ດໍາເນີນການ rpm –V ໃນຊຸດ libdns ແລະໄຟລ໌ຫ້ອງສະຫມຸດ md5sum
• ຜົນໄດ້ຮັບ: ລະຫັດຫ້ອງສະຫມຸດແມ່ນຄືກັນຫມົດກັບລະຫັດໃນລະບົບປະຕິບັດການທີ່ເຮັດວຽກ
• ການທົດສອບ 4: ຕິດຕັ້ງຮູບພາບລະບົບຮາກຂອງຜູ້ໃຊ້ຢູ່ໃນ VM ໂດຍບໍ່ມີພຶດຕິກໍານີ້, ແລ່ນ chroot, ເບິ່ງວ່າ DNS ເຮັດວຽກຫຼືບໍ່
• ຜົນໄດ້ຮັບ: DNS ເຮັດວຽກຢ່າງຖືກຕ້ອງ

ສະ​ຫຼຸບ​ໂດຍ​ອີງ​ໃສ່​ການ​ທົດ​ສອບ​: ບັນຫາບໍ່ໄດ້ຢູ່ໃນຫ້ອງສະຫມຸດ

ສົມມຸດຕິຖານ: ມີຂໍ້ຜິດພາດໃນການຕັ້ງຄ່າ DNS

• ການທົດສອບ 1: ກວດເບິ່ງ tcpdump ແລະເບິ່ງວ່າແພັກເກັດ DNS ຖືກສົ່ງແລະກັບຄືນຢ່າງຖືກຕ້ອງຫຼັງຈາກແລ່ນຂຸດ
• ຜົນໄດ້ຮັບ: ແພັກເກັດຖືກສົ່ງຢ່າງຖືກຕ້ອງ
• ການທົດສອບ 2: ກວດເບິ່ງສອງຄັ້ງໃນເຄື່ອງແມ່ຂ່າຍ /etc/nsswitch.conf и /etc/resolv.conf
• ຜົນໄດ້ຮັບ: ທຸກສິ່ງທຸກຢ່າງແມ່ນຖືກຕ້ອງ

ສະ​ຫຼຸບ​ໂດຍ​ອີງ​ໃສ່​ການ​ທົດ​ສອບ​: ບັນຫາບໍ່ແມ່ນກັບການຕັ້ງຄ່າ DNS

ສົມມຸດຕິຖານ: ຫຼັກເສຍຫາຍ

• ທົດສອບ: ຕິດຕັ້ງ kernel ໃຫມ່, ກວດເບິ່ງລາຍເຊັນ, restart
• ຜົນໄດ້ຮັບ: ພຶດຕິກໍາທີ່ຄ້າຍຄືກັນ

ສະ​ຫຼຸບ​ໂດຍ​ອີງ​ໃສ່​ການ​ທົດ​ສອບ​: ແກ່ນບໍ່ເສຍຫາຍ

ສົມມຸດຕິຖານ: ພຶດຕິກໍາທີ່ບໍ່ຖືກຕ້ອງຂອງເຄືອຂ່າຍຜູ້ໃຊ້ (ຫຼືການໂຕ້ຕອບເຄືອຂ່າຍ hypervisor)

• ການທົດສອບ 1: ກວດເບິ່ງການຕັ້ງຄ່າ firewall ຂອງທ່ານ
• ຜົນໄດ້ຮັບ: firewall ຜ່ານແພັກເກັດ DNS ໃນທັງ host ແລະ GCP
• ການທົດສອບ 2: ຂັດຂວາງການຈະລາຈອນແລະຕິດຕາມຄວາມຖືກຕ້ອງຂອງການສົ່ງຕໍ່ແລະການສົ່ງຄືນຄໍາຮ້ອງຂໍ DNS
• ຜົນໄດ້ຮັບ: tcpdump ຢືນຢັນວ່າເຈົ້າພາບໄດ້ຮັບຊອງຄືນ

ສະ​ຫຼຸບ​ໂດຍ​ອີງ​ໃສ່​ການ​ທົດ​ສອບ​: ບັນຫາບໍ່ໄດ້ຢູ່ໃນເຄືອຂ່າຍ

ສົມມຸດຕິຖານ: ເຊີບເວີ metadata ບໍ່ເຮັດວຽກ

• ການທົດສອບ 1: ກວດເບິ່ງບັນທຶກເຊີບເວີ metadata ສໍາລັບຄວາມຜິດປົກກະຕິ
• ຜົນໄດ້ຮັບ: ບໍ່ມີຂໍ້ບົກຜ່ອງໃນບັນທຶກ
• ການທົດສອບ 2: Bypass ເຄື່ອງແມ່ຂ່າຍ metadata ຜ່ານ dig @8.8.8.8
• ຜົນໄດ້ຮັບ: ການແກ້ໄຂແມ່ນແຕກຫັກເຖິງແມ່ນວ່າໂດຍບໍ່ມີການນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍ metadata

ສະ​ຫຼຸບ​ໂດຍ​ອີງ​ໃສ່​ການ​ທົດ​ສອບ​: ບັນຫາບໍ່ແມ່ນກັບເຄື່ອງແມ່ຂ່າຍ metadata

ເສັ້ນທາງລຸ່ມ: ພວກເຮົາໄດ້ທົດສອບລະບົບຍ່ອຍທັງໝົດຍົກເວັ້ນ ການ​ຕັ້ງ​ຄ່າ runtime​!

ເຂົ້າໄປໃນການຕັ້ງຄ່າ Kernel Runtime

ເພື່ອກໍາຫນົດຄ່າສະພາບແວດລ້ອມການປະຕິບັດ kernel, ທ່ານສາມາດນໍາໃຊ້ຕົວເລືອກເສັ້ນຄໍາສັ່ງ (grub) ຫຼືການໂຕ້ຕອບ sysctl. ຂ້ອຍເບິ່ງໃນ /etc/sysctl.conf ແລະພຽງແຕ່ຄິດວ່າ, ຂ້າພະເຈົ້າໄດ້ຄົ້ນພົບການຕັ້ງຄ່າ custom ຫຼາຍ. ຮູ້ສຶກວ່າຂ້ອຍໄດ້ຈັບເອົາບາງສິ່ງບາງຢ່າງ, ຂ້ອຍໄດ້ຍົກເລີກການຕັ້ງຄ່າທີ່ບໍ່ແມ່ນເຄືອຂ່າຍຫຼືບໍ່ແມ່ນ tcp ທັງຫມົດ, ເຊິ່ງຍັງຄົງຢູ່ກັບການຕັ້ງຄ່າພູເຂົາ. net.core. ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ໄປຫາບ່ອນທີ່ການອະນຸຍາດຂອງເຈົ້າພາບຢູ່ໃນ VM ແລະເລີ່ມນໍາໃຊ້ການຕັ້ງຄ່າເທື່ອລະອັນ, ຫນຶ່ງຫຼັງຈາກນັ້ນ, ກັບ VM ທີ່ແຕກຫັກ, ຈົນກ່ວາຂ້າພະເຈົ້າພົບເຫັນຜູ້ກະທໍາຜິດ:

net.core.rmem_default = 2147483647

ນີ້ແມ່ນ, ການຕັ້ງຄ່າ DNS breaking! ຂ້ອຍພົບອາວຸດຄາດຕະກຳ. ແຕ່ເປັນຫຍັງເລື່ອງນີ້ເກີດຂຶ້ນ? ຂ້ອຍຍັງຕ້ອງການແຮງຈູງໃຈ.

ຂະຫນາດ buffer DNS ພື້ນຖານແມ່ນ configured ຜ່ານ net.core.rmem_default. ມູນຄ່າປົກກະຕິແມ່ນຢູ່ບ່ອນໃດຫນຶ່ງປະມານ 200KiB, ແຕ່ຖ້າເຄື່ອງແມ່ຂ່າຍຂອງທ່ານໄດ້ຮັບແພັກເກັດ DNS ຫຼາຍ, ທ່ານອາດຈະຕ້ອງການເພີ່ມຂະຫນາດ buffer. ຖ້າ buffer ເຕັມເມື່ອແພັກເກັດໃຫມ່ມາຮອດ, ຕົວຢ່າງຍ້ອນວ່າແອັບພລິເຄຊັນບໍ່ດໍາເນີນການໄວພໍ, ຫຼັງຈາກນັ້ນທ່ານຈະເລີ່ມສູນເສຍແພັກເກັດ. ລູກຄ້າຂອງພວກເຮົາໄດ້ເພີ່ມຂະຫນາດ buffer ຢ່າງຖືກຕ້ອງຍ້ອນວ່າລາວຢ້ານການສູນເສຍຂໍ້ມູນ, ຍ້ອນວ່າລາວກໍາລັງໃຊ້ຄໍາຮ້ອງສະຫມັກສໍາລັບການລວບລວມຂໍ້ມູນຜ່ານແພັກເກັດ DNS. ຄ່າທີ່ລາວຕັ້ງແມ່ນສູງສຸດທີ່ເປັນໄປໄດ້: 231-1 (ຖ້າຕັ້ງເປັນ 231, kernel ຈະສົ່ງຄືນ "ການໂຕ້ຖຽງບໍ່ຖືກຕ້ອງ").

ທັນໃດນັ້ນຂ້ອຍຮູ້ວ່າເປັນຫຍັງ nmap ແລະ scapy ເຮັດວຽກຢ່າງຖືກຕ້ອງ: ພວກເຂົາໃຊ້ຊັອກເກັດດິບ! ເຕົ້າຮັບດິບແມ່ນແຕກຕ່າງຈາກເຕົ້າຮັບປົກກະຕິ: ພວກມັນຂ້າມ iptables, ແລະພວກມັນບໍ່ຖືກ buffered!

ແຕ່ເປັນຫຍັງ "buffer ໃຫຍ່ເກີນໄປ" ເຮັດໃຫ້ເກີດບັນຫາ? ມັນຈະແຈ້ງບໍ່ໄດ້ຜົນຕາມທີ່ຕັ້ງໃຈໄວ້.

ໃນຈຸດນີ້, ຂ້ອຍສາມາດສ້າງບັນຫາໃນຫຼາຍໆເມັດແລະການແຈກຢາຍຫຼາຍ. ບັນຫາປາກົດຢູ່ໃນ 3.x kernel ແລ້ວແລະໃນປັດຈຸບັນມັນຍັງປາກົດຢູ່ໃນ kernel 5.x.

ແທ້ຈິງແລ້ວ, ເມື່ອເລີ່ມຕົ້ນ

sysctl -w net.core.rmem_default=$((2**31-1))

DNS ຢຸດເຮັດວຽກ.

ຂ້ອຍເລີ່ມຊອກຫາຄ່າທີ່ເຮັດວຽກຜ່ານລະບົບການຄົ້ນຫາແບບຖານສອງແບບງ່າຍໆແລະພົບວ່າລະບົບເຮັດວຽກກັບ 2147481343, ແຕ່ຕົວເລກນີ້ແມ່ນຊຸດຕົວເລກທີ່ບໍ່ມີຄວາມຫມາຍສໍາລັບຂ້ອຍ. ຂ້ອຍໄດ້ແນະນໍາໃຫ້ລູກຄ້າລອງໃຊ້ເບີນີ້, ແລະລາວຕອບວ່າລະບົບເຮັດວຽກກັບ google.com, ແຕ່ຍັງມີຂໍ້ຜິດພາດກັບໂດເມນອື່ນໆ, ດັ່ງນັ້ນຂ້ອຍສືບຕໍ່ສືບສວນ.

ຂ້ອຍໄດ້ຕິດຕັ້ງ dropwatch, ເຄື່ອງມືທີ່ຄວນຈະຖືກນໍາໃຊ້ກ່ອນຫນ້ານັ້ນ: ມັນສະແດງໃຫ້ເຫັນເຖິງບ່ອນທີ່ຢູ່ໃນ kernel packet ສິ້ນສຸດລົງ. culprit ແມ່ນຫນ້າທີ່ udp_queue_rcv_skb. ຂ້າພະເຈົ້າໄດ້ດາວໂຫລດແຫຼ່ງແກ່ນແລະເພີ່ມຈໍານວນຫນ້ອຍ ໜ້າ ທີ່ printk ເພື່ອຕິດຕາມບ່ອນທີ່ແພັກເກັດນັ້ນສິ້ນສຸດລົງ. ຂ້ອຍພົບສະພາບທີ່ຖືກຕ້ອງຢ່າງໄວວາ if, ແລະພຽງແຕ່ເບິ່ງມັນສໍາລັບບາງເວລາ, ເນື່ອງຈາກວ່າມັນແມ່ນຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງໄດ້ມາຮ່ວມກັນເປັນຮູບທັງຫມົດ: 231-1, ຕົວເລກທີ່ບໍ່ມີຄວາມຫມາຍ, ໂດເມນທີ່ບໍ່ໄດ້ເຮັດວຽກ ... ມັນແມ່ນຊິ້ນສ່ວນຂອງລະຫັດໃນ. __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

ກະລຸນາສັງເກດ:

• rmem ແມ່ນປະເພດ int
• size ເປັນປະເພດ u16 (unsigned sixteen-bit int) ແລະເກັບຮັກສາຂະຫນາດແພັກເກັດ
• sk->sk_rcybuf ແມ່ນປະເພດ int ແລະເກັບຮັກສາຂະຫນາດ buffer ເຊິ່ງ, ຕາມຄໍານິຍາມ, ແມ່ນເທົ່າກັບຄ່າໃນ net.core.rmem_default

ໃນເວລາທີ່ sk_rcvbuf ເຂົ້າຫາ 231, ການສະຫຼຸບຂະຫນາດຂອງແພັກເກັດອາດຈະສົ່ງຜົນໃຫ້ ເຕັມຈຳນວນເຕັມ. ແລະນັບຕັ້ງແຕ່ມັນເປັນ int, ມູນຄ່າຂອງມັນຈະກາຍເປັນລົບ, ດັ່ງນັ້ນເງື່ອນໄຂຈະກາຍເປັນຄວາມຈິງໃນເວລາທີ່ມັນຄວນຈະເປັນຜິດ (ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໄດ້ທີ່. ການເຊື່ອມຕໍ່).

ຄວາມ​ຜິດ​ພາດ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ແກ້​ໄຂ​ໃນ​ວິ​ທີ​ການ trivial​: ໂດຍ​ການ​ສາຍ​ unsigned int. ຂ້າພະເຈົ້າໄດ້ນໍາໃຊ້ການແກ້ໄຂແລະເລີ່ມຕົ້ນລະບົບໃຫມ່ແລະ DNS ເຮັດວຽກອີກເທື່ອຫນຶ່ງ.

ລົດຊາດຂອງໄຊຊະນະ

ຂ້ອຍສົ່ງຜົນການຄົ້ນພົບຂອງຂ້ອຍໃຫ້ລູກຄ້າແລະສົ່ງ LKML ແກ້​ໄຂ kernel​. ຂ້າພະເຈົ້າຍິນດີ: ທຸກຊິ້ນສ່ວນຂອງປິດສະຫນາເຂົ້າກັນໄດ້, ຂ້າພະເຈົ້າສາມາດອະທິບາຍໄດ້ຢ່າງແນ່ນອນວ່າເປັນຫຍັງພວກເຮົາສັງເກດເຫັນສິ່ງທີ່ພວກເຮົາສັງເກດເຫັນ, ແລະສໍາຄັນທີ່ສຸດ, ພວກເຮົາສາມາດຊອກຫາວິທີແກ້ໄຂບັນຫາໄດ້ຍ້ອນທີມງານຂອງພວກເຮົາ!

ມັນເປັນມູນຄ່າທີ່ຮັບຮູ້ວ່າກໍລະນີດັ່ງກ່າວໄດ້ກາຍເປັນເລື່ອງທີ່ຫາຍາກ, ແລະໂຊກດີທີ່ພວກເຮົາບໍ່ຄ່ອຍໄດ້ຮັບການຮ້ອງຂໍສະລັບສັບຊ້ອນດັ່ງກ່າວຈາກຜູ້ໃຊ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com