DDoS ເພື່ອກູ້ໄພ: ພວກເຮົາດໍາເນີນການທົດສອບຄວາມກົດດັນແລະການໂຫຼດແນວໃດ

Variti ພັດທະນາການປ້ອງກັນ bots ແລະການໂຈມຕີ DDoS, ແລະຍັງດໍາເນີນການທົດສອບຄວາມກົດດັນແລະການໂຫຼດ. ໃນກອງປະຊຸມ HighLoad++ 2018 ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບວິທີການຮັບປະກັນຊັບພະຍາກອນຈາກການໂຈມຕີປະເພດຕ່າງໆ. ໃນສັ້ນ: ແຍກພາກສ່ວນຂອງລະບົບ, ໃຊ້ບໍລິການຟັງແລະ CDNs, ແລະປັບປຸງເປັນປົກກະຕິ. ແຕ່ທ່ານຍັງບໍ່ສາມາດຈັດການກັບການປົກປ້ອງໂດຍບໍ່ມີບໍລິສັດພິເສດ :)

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

ວິດີໂອບັນທຶກບົດລາຍງານ

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

ພວກເຮົາເຮັດວຽກແນວໃດ

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

Postulates

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

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

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

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

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

ລັກສະນະທີ່ໂດດເດັ່ນຂອງການໂຈມຕີ L7

ພວກເຮົາປົກກະຕິແລ້ວແບ່ງປະເພດຂອງການໂຫຼດເຂົ້າໄປໃນການໂຫຼດຢູ່ໃນລະດັບ L7 ແລະ L3&4. L7 ແມ່ນການໂຫຼດຢູ່ໃນລະດັບຄໍາຮ້ອງສະຫມັກ, ສ່ວນຫຼາຍມັນຫມາຍຄວາມວ່າພຽງແຕ່ HTTP, ແຕ່ພວກເຮົາຫມາຍເຖິງການໂຫຼດໃດໆໃນລະດັບ TCP protocol.
ການໂຈມຕີ L7 ມີລັກສະນະພິເສດສະເພາະ. ກ່ອນອື່ນ ໝົດ, ພວກເຂົາມາໂດຍກົງກັບແອັບພລິເຄຊັນ, ນັ້ນແມ່ນ, ມັນຄົງຈະບໍ່ຖືກສະທ້ອນຜ່ານທາງເຄືອຂ່າຍ. ການໂຈມຕີດັ່ງກ່າວໃຊ້ເຫດຜົນ, ແລະເນື່ອງຈາກນີ້, ພວກເຂົາເຈົ້າບໍລິໂພກ CPU, ຫນ່ວຍຄວາມຈໍາ, ແຜ່ນ, ຖານຂໍ້ມູນແລະຊັບພະຍາກອນອື່ນໆທີ່ມີປະສິດທິພາບຫຼາຍແລະມີການຈະລາຈອນຫນ້ອຍ.

HTTP ນໍ້າຖ້ວມ

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

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

ສິ່ງທີ່ຕ້ອງຊອກຫາ

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

ເບິ່ງບ່ອນໃດ

ເມື່ອພວກເຮົາສະແກນຊັບພະຍາກອນກ່ອນການທົດສອບ, ແນ່ນອນ, ພວກເຮົາເບິ່ງເວັບໄຊທ໌ທໍາອິດ. ພວກເຮົາກໍາລັງຊອກຫາທຸກປະເພດຂອງການປ້ອນຂໍ້ມູນ, ໄຟລ໌ຫນັກ - ໂດຍທົ່ວໄປ, ທຸກສິ່ງທຸກຢ່າງທີ່ສາມາດສ້າງບັນຫາສໍາລັບຊັບພະຍາກອນແລະຊ້າລົງໃນການດໍາເນີນງານຂອງມັນ. ເຄື່ອງມືພັດທະນາ Banal ໃນ Google Chrome ແລະ Firefox ຊ່ວຍຢູ່ທີ່ນີ້, ສະແດງເວລາຕອບສະຫນອງຂອງຫນ້າ.
ພວກເຮົາຍັງສະແກນໂດເມນຍ່ອຍ. ຕົວຢ່າງ, ມີຮ້ານຄ້າອອນໄລນ໌ທີ່ແນ່ນອນ, abc.com, ແລະມັນມີໂດເມນຍ່ອຍ admin.abc.com. ສ່ວນຫຼາຍອາດຈະ, ນີ້ແມ່ນກະດານ admin ທີ່ມີການອະນຸຍາດ, ແຕ່ຖ້າທ່ານໃສ່ມັນ, ມັນສາມາດສ້າງບັນຫາສໍາລັບຊັບພະຍາກອນຕົ້ນຕໍ.
ເວັບໄຊດັ່ງກ່າວອາດຈະມີໂດເມນຍ່ອຍ api.abc.com. ສ່ວນຫຼາຍອາດຈະ, ນີ້ແມ່ນຊັບພະຍາກອນສໍາລັບຄໍາຮ້ອງສະຫມັກມືຖື. ແອັບພລິເຄຊັນສາມາດພົບໄດ້ໃນ App Store ຫຼື Google Play, ຕິດຕັ້ງຈຸດເຂົ້າເຖິງພິເສດ, ແຍກ API ແລະລົງທະບຽນບັນຊີທົດສອບ. ບັນຫາແມ່ນວ່າປະຊາຊົນມັກຈະຄິດວ່າສິ່ງໃດກໍ່ຕາມທີ່ຖືກປົກປ້ອງໂດຍການອະນຸຍາດແມ່ນມີພູມຕ້ານທານຕໍ່ການປະຕິເສດການໂຈມຕີການບໍລິການ. ສົມມຸດວ່າ, ການອະນຸຍາດແມ່ນ CAPTCHA ທີ່ດີທີ່ສຸດ, ແຕ່ມັນບໍ່ແມ່ນ. ມັນງ່າຍທີ່ຈະສ້າງ 10-20 ບັນຊີທົດສອບ, ແຕ່ໂດຍການສ້າງພວກມັນ, ພວກເຮົາສາມາດເຂົ້າເຖິງການເຮັດວຽກທີ່ສັບສົນແລະບໍ່ມີຕົວຕົນ.
ຕາມທໍາມະຊາດ, ພວກເຮົາເບິ່ງປະຫວັດສາດ, ຢູ່ robots.txt ແລະ WebArchive, ViewDNS, ແລະຊອກຫາສະບັບເກົ່າຂອງຊັບພະຍາກອນ. ບາງຄັ້ງມັນເກີດຂື້ນວ່ານັກພັດທະນາໄດ້ມ້ວນອອກ, ເວົ້າວ່າ, mail2.yandex.net, ແຕ່ສະບັບເກົ່າ, mail.yandex.net, ຍັງຄົງຢູ່. mail.yandex.net ນີ້ບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນອີກຕໍ່ໄປ, ຊັບພະຍາກອນການພັດທະນາບໍ່ໄດ້ຖືກຈັດສັນໃຫ້ກັບມັນ, ແຕ່ມັນຍັງສືບຕໍ່ບໍລິໂພກຖານຂໍ້ມູນ. ຕາມນັ້ນແລ້ວ, ການນໍາໃຊ້ສະບັບເກົ່າ, ທ່ານສາມາດນໍາໃຊ້ຊັບພະຍາກອນຂອງ backend ແລະທຸກສິ່ງທຸກຢ່າງທີ່ຢູ່ເບື້ອງຫລັງຢ່າງມີປະສິດທິພາບ. ແນ່ນອນ, ນີ້ບໍ່ໄດ້ເກີດຂຶ້ນເລື້ອຍໆ, ແຕ່ພວກເຮົາຍັງພົບເລື້ອຍໆເລື້ອຍໆ.
ຕາມທໍາມະຊາດ, ພວກເຮົາວິເຄາະຕົວກໍານົດການຮ້ອງຂໍທັງຫມົດແລະໂຄງສ້າງຄຸກກີ. ທ່ານສາມາດເວົ້າວ່າ, ຖິ້ມມູນຄ່າບາງຢ່າງເຂົ້າໄປໃນອາເຣ JSON ພາຍໃນຄຸກກີ, ສ້າງຮັງຫຼາຍແລະເຮັດໃຫ້ຊັບພະຍາກອນເຮັດວຽກເປັນເວລາດົນນານທີ່ບໍ່ສົມເຫດສົມຜົນ.

ຄົ້ນຫາການໂຫຼດ

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

ຖ້າບໍ່ມີການຄົ້ນຫາ?

ຖ້າບໍ່ມີການຄົ້ນຫາ, ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າເວັບໄຊທ໌ບໍ່ມີຊ່ອງໃສ່ຂໍ້ມູນທີ່ມີຄວາມສ່ຽງອື່ນໆ. ຊ່ອງຂໍ້ມູນນີ້ອາດຈະເປັນການອະນຸຍາດ. ໃນປັດຈຸບັນ, ນັກພັດທະນາມັກສ້າງ hashes ສະລັບສັບຊ້ອນເພື່ອປົກປ້ອງຖານຂໍ້ມູນການເຂົ້າສູ່ລະບົບຈາກການໂຈມຕີຕາຕະລາງ rainbow. ນີ້ແມ່ນດີ, ແຕ່ hashes ດັ່ງກ່າວໃຊ້ຊັບພະຍາກອນ CPU ຫຼາຍ. ການໄຫຼເຂົ້າຂະຫນາດໃຫຍ່ຂອງການອະນຸຍາດທີ່ບໍ່ຖືກຕ້ອງນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງໂປເຊດເຊີ, ແລະດັ່ງນັ້ນ, ເວັບໄຊທ໌ຢຸດເຮັດວຽກ.
ການປະກົດຕົວຢູ່ໃນເວັບໄຊທ໌ຂອງທຸກປະເພດສໍາລັບຄໍາຄິດເຫັນແລະຄໍາຕິຊົມແມ່ນເຫດຜົນທີ່ຈະສົ່ງບົດເລື່ອງຂະຫນາດໃຫຍ່ຢູ່ທີ່ນັ້ນຫຼືພຽງແຕ່ສ້າງນ້ໍາຖ້ວມໃຫຍ່. ບາງຄັ້ງເວັບໄຊທ໌ຍອມຮັບໄຟລ໌ທີ່ຕິດຄັດມາ, ລວມທັງໃນຮູບແບບ gzip. ໃນກໍລະນີນີ້, ພວກເຮົາເອົາໄຟລ໌ 1TB, ບີບອັດເປັນຫຼາຍ bytes ຫຼື kilobytes ໂດຍໃຊ້ gzip ແລະສົ່ງໄປທີ່ເວັບໄຊທ໌. ຫຼັງຈາກນັ້ນ, ມັນແມ່ນ unzipped ແລະຜົນກະທົບທີ່ຫນ້າສົນໃຈຫຼາຍແມ່ນໄດ້ຮັບ.

API ພັກຜ່ອນ

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

ກຳລັງໂຫຼດເນື້ອຫາໜັກ

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

ຢ່າລືມກ່ຽວກັບການຕັ້ງຄ່າເຄື່ອງແມ່ຂ່າຍ. ເຈົ້າມັກຈະພົບວ່າຄົນຊື້ເຄື່ອງ virtual, ຕິດຕັ້ງ Apache ຢູ່ທີ່ນັ້ນ, ຕັ້ງຄ່າທຸກຢ່າງໂດຍຄ່າເລີ່ມຕົ້ນ, ຕິດຕັ້ງແອັບພລິເຄຊັນ PHP, ແລະຂ້າງລຸ່ມນີ້ທ່ານສາມາດເບິ່ງຜົນໄດ້ຮັບ.

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

ອີງໃສ່ຄື້ນ

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

ນັ້ນແມ່ນ, ການປ້ອງກັນໄດ້ຮຽນຮູ້, ເລີ່ມຕົ້ນການກັ່ນຕອງ, ແຕ່ສ່ວນໃຫມ່, ທີ່ແຕກຕ່າງກັນຫມົດຂອງການໂຈມຕີມາຮອດ, ແລະການປ້ອງກັນເລີ່ມຕົ້ນຮຽນຮູ້ອີກເທື່ອຫນຶ່ງ. ໃນຄວາມເປັນຈິງ, ການກັ່ນຕອງຢຸດເຮັດວຽກ, ການປົກປ້ອງບໍ່ມີປະສິດທິພາບ, ແລະເວັບໄຊທ໌ບໍ່ສາມາດໃຊ້ໄດ້.
ການໂຈມຕີດ້ວຍຄື້ນແມ່ນມີລັກສະນະທີ່ມີມູນຄ່າສູງຫຼາຍຢູ່ໃນຈຸດສູງສຸດ, ມັນສາມາດບັນລຸຫນຶ່ງຮ້ອຍພັນຫຼືລ້ານຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ, ໃນກໍລະນີຂອງ L7. ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບ L3&4, ຫຼັງຈາກນັ້ນສາມາດມີຫຼາຍຮ້ອຍ gigabits ຂອງການຈະລາຈອນ, ຫຼື, ຕາມຄວາມເຫມາະສົມ, ຫຼາຍຮ້ອຍ mpps, ຖ້າທ່ານນັບຢູ່ໃນແພັກເກັດ.
ບັນຫາກັບການໂຈມຕີດັ່ງກ່າວແມ່ນ synchronization. ການໂຈມຕີແມ່ນມາຈາກ botnet ແລະຮຽກຮ້ອງໃຫ້ມີການ synchronization ໃນລະດັບສູງເພື່ອສ້າງການເພີ່ມຂຶ້ນຄັ້ງດຽວທີ່ມີຂະຫນາດໃຫຍ່ຫຼາຍ. ແລະການປະສານງານນີ້ບໍ່ໄດ້ຜົນສະ ເໝີ ໄປ: ບາງຄັ້ງຜົນຜະລິດແມ່ນບາງຊະນິດຂອງຈຸດສູງສຸດຂອງ parabolic, ເຊິ່ງເບິ່ງຄືວ່າເປັນເລື່ອງທີ່ຫນ້າເສົ້າໃຈ.

ບໍ່ແມ່ນ HTTP ດຽວ

ນອກເຫນືອຈາກ HTTP ຢູ່ L7, ພວກເຮົາມັກໃຊ້ໂປໂຕຄອນອື່ນໆ. ຕາມກົດລະບຽບ, ເວັບໄຊທ໌ປົກກະຕິ, ໂດຍສະເພາະແມ່ນໂຮດຕິ້ງປົກກະຕິ, ມີໂປໂຕຄອນ mail ແລະ MySQL ຕິດຢູ່. ໂປໂຕຄອນອີເມລແມ່ນຂຶ້ນກັບການໂຫຼດຫນ້ອຍກວ່າຖານຂໍ້ມູນ, ແຕ່ພວກມັນຍັງສາມາດໂຫລດໄດ້ຢ່າງມີປະສິດທິພາບແລະສິ້ນສຸດດ້ວຍ CPU ຫຼາຍເກີນໄປໃນເຄື່ອງແມ່ຂ່າຍ.
ພວກເຮົາປະສົບຜົນສຳເລັດຢ່າງສົມຈິງກັບຈຸດອ່ອນ SSH ປີ 2016. ໃນປັດຈຸບັນຊ່ອງໂຫວ່ນີ້ໄດ້ຖືກແກ້ໄຂສໍາລັບເກືອບທຸກຄົນ, ແຕ່ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າການໂຫຼດບໍ່ສາມາດສົ່ງກັບ SSH ໄດ້. ສາ​ມາດ. ມີພຽງແຕ່ການໂຫຼດຂະຫນາດໃຫຍ່ຂອງການອະນຸຍາດ, SSH ກິນເຖິງ CPU ເກືອບທັງຫມົດໃນເຄື່ອງແມ່ຂ່າຍ, ແລະຫຼັງຈາກນັ້ນເວັບໄຊທ໌ໄດ້ລົ້ມລົງຈາກຫນຶ່ງຫຼືສອງຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ. ດັ່ງນັ້ນ, ຫນຶ່ງຫຼືສອງຄໍາຮ້ອງຂໍເຫຼົ່ານີ້ໂດຍອີງໃສ່ບັນທຶກບໍ່ສາມາດຈໍາແນກຈາກການໂຫຼດທີ່ຖືກຕ້ອງ.
ການເຊື່ອມຕໍ່ຈໍານວນຫຼາຍທີ່ພວກເຮົາເປີດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຍັງມີຄວາມກ່ຽວຂ້ອງ. ກ່ອນຫນ້ານີ້, Apache ມີຄວາມຜິດໃນເລື່ອງນີ້, ໃນປັດຈຸບັນ nginx ມີຄວາມຜິດຢ່າງແທ້ຈິງ, ເພາະວ່າມັນມັກຈະຖືກຕັ້ງຄ່າໂດຍຄ່າເລີ່ມຕົ້ນ. ຈໍານວນຂອງການເຊື່ອມຕໍ່ທີ່ nginx ສາມາດເປີດໄດ້ແມ່ນຈໍາກັດ, ດັ່ງນັ້ນພວກເຮົາເປີດຈໍານວນການເຊື່ອມຕໍ່ນີ້, nginx ບໍ່ຍອມຮັບການເຊື່ອມຕໍ່ໃຫມ່, ແລະດັ່ງນັ້ນເວັບໄຊທ໌ບໍ່ເຮັດວຽກ.
ກຸ່ມທົດສອບຂອງພວກເຮົາມີ CPU ພຽງພໍເພື່ອໂຈມຕີ SSL handshake. ໃນຫຼັກການ, ຕາມການປະຕິບັດສະແດງໃຫ້ເຫັນ, botnets ບາງຄັ້ງກໍ່ມັກເຮັດສິ່ງນີ້ເຊັ່ນກັນ. ໃນອີກດ້ານຫນຶ່ງ, ມັນເປັນທີ່ຊັດເຈນວ່າທ່ານບໍ່ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີ SSL, ເພາະວ່າຜົນໄດ້ຮັບຂອງ Google, ການຈັດອັນດັບ, ຄວາມປອດໄພ. ໃນທາງກົງກັນຂ້າມ, ແຕ່ຫນ້າເສຍດາຍ, SSL ມີບັນຫາ CPU.

L3&4

ເມື່ອພວກເຮົາເວົ້າກ່ຽວກັບການໂຈມຕີໃນລະດັບ L3&4, ພວກເຮົາມັກຈະເວົ້າກ່ຽວກັບການໂຈມຕີໃນລະດັບການເຊື່ອມໂຍງ. ການໂຫຼດດັ່ງກ່າວເກືອບສະເຫມີສາມາດແຍກອອກຈາກອັນທີ່ຖືກຕ້ອງ, ເວັ້ນເສຍແຕ່ວ່າມັນເປັນການໂຈມຕີ SYN-ນໍ້າຖ້ວມ. ບັນຫາທີ່ມີການໂຈມຕີ SYN-ນໍ້າຖ້ວມສໍາລັບເຄື່ອງມືຄວາມປອດໄພແມ່ນປະລິມານຂະຫນາດໃຫຍ່ຂອງພວກເຂົາ. ຄ່າ L3&4 ສູງສຸດແມ່ນ 1,5-2 Tbit/s. ປະເພດຂອງການຈະລາຈອນນີ້ແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະດໍາເນີນການເຖິງແມ່ນວ່າບໍລິສັດຂະຫນາດໃຫຍ່, ລວມທັງ Oracle ແລະ Google.
SYN ແລະ SYN-ACK ແມ່ນແພັກເກັດທີ່ໃຊ້ໃນເວລາສ້າງການເຊື່ອມຕໍ່. ດັ່ງນັ້ນ, SYN- ນໍ້າຖ້ວມແມ່ນຍາກທີ່ຈະແຍກແຍະຈາກການໂຫຼດທີ່ຖືກຕ້ອງ: ມັນບໍ່ຊັດເຈນວ່ານີ້ແມ່ນ SYN ທີ່ມາເພື່ອສ້າງການເຊື່ອມຕໍ່, ຫຼືສ່ວນຫນຶ່ງຂອງນ້ໍາຖ້ວມ.

UDP-ນໍ້າຖ້ວມ

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

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

SYN ຄວາມຫຍຸ້ງຍາກ - ນໍ້າຖ້ວມ

SYN-ນໍ້າຖ້ວມແມ່ນອາດຈະເປັນປະເພດການໂຈມຕີທີ່ຫນ້າສົນໃຈຫຼາຍທີ່ສຸດຈາກທັດສະນະຂອງຜູ້ພັດທະນາ. ບັນຫາແມ່ນວ່າຜູ້ເບິ່ງແຍງລະບົບມັກຈະໃຊ້ການສະກັດ IP ສໍາລັບການປົກປ້ອງ. ຍິ່ງໄປກວ່ານັ້ນ, ການຂັດຂວາງ IP ມີຜົນກະທົບບໍ່ພຽງແຕ່ຜູ້ບໍລິຫານລະບົບທີ່ປະຕິບັດການນໍາໃຊ້ສະຄິບ, ແຕ່ຫນ້າເສຍດາຍ, ບາງລະບົບຄວາມປອດໄພທີ່ຊື້ດ້ວຍເງິນຫຼາຍ.
ວິທີການນີ້ສາມາດກາຍເປັນໄພພິບັດ, ເພາະວ່າຖ້າຜູ້ໂຈມຕີແທນທີ່ຢູ່ IP, ບໍລິສັດຈະປິດເຄືອຂ່າຍຍ່ອຍຂອງຕົນເອງ. ເມື່ອ Firewall ຂັດຂວາງກຸ່ມຂອງຕົນເອງ, ຜົນຜະລິດຈະລົ້ມເຫລວການໂຕ້ຕອບພາຍນອກແລະຊັບພະຍາກອນຈະລົ້ມເຫລວ.
ຍິ່ງໄປກວ່ານັ້ນ, ມັນບໍ່ຍາກທີ່ຈະສະກັດເຄືອຂ່າຍຂອງທ່ານເອງ. ຖ້າຫ້ອງການຂອງລູກຄ້າມີເຄືອຂ່າຍ Wi-Fi, ຫຼືຖ້າການປະຕິບັດຂອງຊັບພະຍາກອນຖືກວັດແທກໂດຍໃຊ້ລະບົບຕິດຕາມກວດກາຕ່າງໆ, ພວກເຮົາເອົາທີ່ຢູ່ IP ຂອງລະບົບການຕິດຕາມນີ້ຫຼືຫ້ອງການຂອງລູກຄ້າ Wi-Fi ແລະໃຊ້ມັນເປັນແຫຼ່ງ. ໃນທີ່ສຸດ, ຊັບພະຍາກອນເບິ່ງຄືວ່າມີຢູ່, ແຕ່ທີ່ຢູ່ IP ເປົ້າຫມາຍແມ່ນຖືກສະກັດ. ດັ່ງນັ້ນ, ເຄືອຂ່າຍ Wi-Fi ຂອງກອງປະຊຸມ HighLoad, ບ່ອນທີ່ຜະລິດຕະພັນໃຫມ່ຂອງບໍລິສັດໄດ້ຖືກນໍາສະເຫນີ, ອາດຈະຖືກສະກັດ, ແລະນີ້ປະກອບມີຄ່າໃຊ້ຈ່າຍທາງທຸລະກິດແລະເສດຖະກິດທີ່ແນ່ນອນ.
ໃນ​ລະ​ຫວ່າງ​ການ​ທົດ​ສອບ, ພວກ​ເຮົາ​ບໍ່​ສາ​ມາດ​ນໍາ​ໃຊ້​ຂະ​ຫຍາຍ​ໂດຍ​ຜ່ານ memcached ກັບ​ຊັບ​ພະ​ຍາ​ກອນ​ພາຍ​ນອກ​, ເນື່ອງ​ຈາກ​ວ່າ​ມີ​ຂໍ້​ຕົກ​ລົງ​ທີ່​ຈະ​ສົ່ງ​ການ​ຈະ​ລາ​ຈອນ​ພຽງ​ແຕ່​ທີ່​ຢູ່ IP ທີ່​ອະ​ນຸ​ຍາດ​ໃຫ້​. ດັ່ງນັ້ນ, ພວກເຮົາໃຊ້ການຂະຫຍາຍສຽງຜ່ານ SYN ແລະ SYN-ACK, ເມື່ອລະບົບຕອບສະຫນອງການສົ່ງຫນຶ່ງ SYN ກັບສອງຫຼືສາມ SYN-ACKs, ແລະຢູ່ທີ່ຜົນຜະລິດການໂຈມຕີແມ່ນຄູນສອງຫຼືສາມເທື່ອ.

ເຄື່ອງມື

ຫນຶ່ງໃນເຄື່ອງມືຕົ້ນຕໍທີ່ພວກເຮົາໃຊ້ສໍາລັບການເຮັດວຽກ L7 ແມ່ນ Yandex-tank. ໂດຍສະເພາະ, phantom ຖືກນໍາໃຊ້ເປັນປືນ, ບວກກັບມີຫຼາຍ scripts ສໍາລັບການຜະລິດ cartridges ແລະສໍາລັບການວິເຄາະຜົນໄດ້ຮັບ.
Tcpdump ຖືກນໍາໃຊ້ເພື່ອວິເຄາະການຈະລາຈອນເຄືອຂ່າຍ, ແລະ Nmap ຖືກນໍາໃຊ້ເພື່ອວິເຄາະເຄື່ອງແມ່ຂ່າຍ. ເພື່ອສ້າງການໂຫຼດຢູ່ໃນລະດັບ L3&4, OpenSSL ແລະ magic ເລັກນ້ອຍຂອງພວກເຮົາກັບຫ້ອງສະຫມຸດ DPDK ແມ່ນຖືກນໍາໃຊ້. DPDK ເປັນຫ້ອງສະຫມຸດຈາກ Intel ທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດເຮັດວຽກກັບການໂຕ້ຕອບເຄືອຂ່າຍໂດຍຂ້າມ Linux stack, ດັ່ງນັ້ນການເພີ່ມປະສິດທິພາບ. ຕາມທໍາມະຊາດ, ພວກເຮົາໃຊ້ DPDK ບໍ່ພຽງແຕ່ຢູ່ໃນລະດັບ L3 & 4, ແຕ່ຍັງຢູ່ໃນລະດັບ L7, ເພາະວ່າມັນຊ່ວຍໃຫ້ພວກເຮົາສ້າງກະແສການໂຫຼດສູງຫຼາຍ, ພາຍໃນຂອບເຂດຂອງຫຼາຍລ້ານຄໍາຮ້ອງຂໍຕໍ່ວິນາທີຈາກຫນຶ່ງເຄື່ອງຈັກ.
ພວກເຮົາຍັງໃຊ້ເຄື່ອງກໍາເນີດການຈະລາຈອນທີ່ແນ່ນອນແລະເຄື່ອງມືພິເສດທີ່ພວກເຮົາຂຽນສໍາລັບການທົດສອບສະເພາະ. ຖ້າພວກເຮົາຈື່ຈໍາຄວາມອ່ອນແອພາຍໃຕ້ SSH, ຫຼັງຈາກນັ້ນ, ຊຸດຂ້າງເທິງນີ້ບໍ່ສາມາດຖືກຂູດຮີດ. ຖ້າພວກເຮົາໂຈມຕີ mail protocol, ພວກເຮົາໃຊ້ mail utilities ຫຼືພຽງແຕ່ຂຽນສະຄິບໃສ່ພວກມັນ.

ການຄົ້ນພົບ

ໃນຖານະເປັນການສະຫລຸບ, ຂ້າພະເຈົ້າຢາກເວົ້າວ່າ:

• ນອກເຫນືອໄປຈາກການທົດສອບການໂຫຼດຄລາສສິກ, ມັນຈໍາເປັນຕ້ອງເຮັດການທົດສອບຄວາມກົດດັນ. ພວກເຮົາມີຕົວຢ່າງທີ່ແທ້ຈິງທີ່ຜູ້ຮັບເຫມົາຍ່ອຍຂອງຄູ່ຮ່ວມງານພຽງແຕ່ປະຕິບັດການທົດສອບການໂຫຼດເທົ່ານັ້ນ. ມັນສະແດງໃຫ້ເຫັນວ່າຊັບພະຍາກອນສາມາດທົນກັບການໂຫຼດປົກກະຕິ. ແຕ່ຫຼັງຈາກນັ້ນການໂຫຼດຜິດປົກກະຕິໄດ້ປາກົດ, ຜູ້ເຂົ້າຊົມເວັບໄຊທ໌ໄດ້ເລີ່ມໃຊ້ຊັບພະຍາກອນທີ່ແຕກຕ່າງກັນເລັກນ້ອຍ, ແລະເປັນຜົນມາຈາກຜູ້ຮັບເຫມົາຍ່ອຍໄດ້ວາງລົງ. ດັ່ງນັ້ນ, ມັນເປັນມູນຄ່າທີ່ຈະຊອກຫາຊ່ອງໂຫວ່ເຖິງແມ່ນວ່າທ່ານຈະໄດ້ຮັບການປົກປ້ອງຈາກການໂຈມຕີ DDoS ແລ້ວ.
• ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະແຍກບາງສ່ວນຂອງລະບົບຈາກຄົນອື່ນ. ຖ້າທ່ານມີການຄົ້ນຫາ, ທ່ານຈໍາເປັນຕ້ອງຍ້າຍມັນໄປຫາເຄື່ອງຈັກແຍກຕ່າງຫາກ, ນັ້ນແມ່ນ, ບໍ່ແມ່ນແຕ່ກັບ Docker. ເນື່ອງຈາກວ່າຖ້າການຄົ້ນຫາຫຼືການອະນຸຍາດລົ້ມເຫລວ, ຢ່າງຫນ້ອຍບາງສິ່ງບາງຢ່າງຈະສືບຕໍ່ເຮັດວຽກ. ໃນກໍລະນີຂອງຮ້ານອອນໄລນ໌, ຜູ້ໃຊ້ຈະສືບຕໍ່ຊອກຫາຜະລິດຕະພັນໃນລາຍການ, ໄປຈາກຜູ້ລວບລວມ, ຊື້ຖ້າພວກເຂົາໄດ້ຮັບອະນຸຍາດແລ້ວ, ຫຼືອະນຸຍາດຜ່ານ OAuth2.
• ຢ່າປະຖິ້ມການບໍລິການຟັງທຸກປະເພດ.
• ໃຊ້ CDN ບໍ່ພຽງແຕ່ເພື່ອເພີ່ມປະສິດທິພາບການຊັກຊ້າຂອງເຄືອຂ່າຍ, ແຕ່ຍັງເປັນວິທີການປ້ອງກັນການໂຈມຕີໃນຊ່ອງຫວ່າງແລະພຽງແຕ່ນ້ໍາຖ້ວມເຂົ້າໄປໃນການຈະລາຈອນຄົງທີ່.
• ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະໃຊ້ບໍລິການປ້ອງກັນພິເສດ. ທ່ານບໍ່ສາມາດປົກປ້ອງຕົວທ່ານເອງຈາກການໂຈມຕີ L3&4 ໃນລະດັບຊ່ອງທາງ, ເພາະວ່າທ່ານອາດຈະບໍ່ມີຊ່ອງທາງພຽງພໍ. ທ່ານຍັງບໍ່ສາມາດຕໍ່ສູ້ກັບການໂຈມຕີ L7, ເພາະວ່າພວກມັນສາມາດມີຂະຫນາດໃຫຍ່ຫຼາຍ. ນອກຈາກນັ້ນ, ການຄົ້ນຫາການໂຈມຕີຂະຫນາດນ້ອຍຍັງຄົງເປັນສິດທິພິເສດຂອງການບໍລິການພິເສດ, ສູດການຄິດໄລ່ພິເສດ.
• ປັບປຸງເປັນປົກກະຕິ. ນີ້ໃຊ້ບໍ່ພຽງແຕ່ກັບແກ່ນ, ແຕ່ຍັງກັບ SSH daemon, ໂດຍສະເພາະຖ້າທ່ານມີພວກມັນເປີດໃຫ້ພາຍນອກ. ໃນຫຼັກການ, ທຸກສິ່ງທຸກຢ່າງຕ້ອງໄດ້ຮັບການປັບປຸງ, ເພາະວ່າເຈົ້າບໍ່ສາມາດຕິດຕາມຊ່ອງໂຫວ່ບາງຢ່າງດ້ວຍຕົນເອງ.

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