Variti нь роботууд болон DDoS халдлагаас хамгаалах хамгаалалтыг хөгжүүлж, стресс, ачааллын тест хийдэг. HighLoad++ 2018 бага хурал дээр бид янз бүрийн төрлийн халдлагаас нөөцийг хэрхэн хамгаалах талаар ярилцсан. Товчхондоо: системийн хэсгүүдийг тусгаарлаж, үүлэн үйлчилгээ болон CDN-г ашиглаж, байнга шинэчилж байгаарай. Гэхдээ та тусгай компанигүйгээр хамгаалалтыг даван туулж чадахгүй :)
Текстийг уншихаасаа өмнө товч хураангуйг уншиж болно .
Хэрэв та унших дургүй эсвэл зүгээр л видеог үзэхийг хүсч байвал манай сурвалжлагын бичлэгийг спойлер дор оруулсан болно.
Тайлангийн видео бичлэг
Олон компаниуд ачааллын тестийг хэрхэн хийхээ мэддэг ч бүгд стресс тест хийдэггүй. Манай зарим үйлчлүүлэгчид өндөр ачаалалтай системтэй, халдлагаас сайн хамгаалдаг учраас сайтаа халдашгүй гэж боддог. Энэ нь бүхэлдээ үнэн биш гэдгийг бид харуулж байна.
Мэдээжийн хэрэг, туршилт хийхээсээ өмнө бид үйлчлүүлэгчээс зөвшөөрөл авч, гарын үсэг зурж, тамга дарж баталгаажуулдаг бөгөөд бидний тусламжтайгаар DDoS халдлагыг хэнд ч хийх боломжгүй. Туршилтыг хэрэглэгчийн сонгосон цагт, түүний нөөц рүү чиглэсэн урсгал бага байх үед хийгддэг бөгөөд хандалтын асуудал үйлчлүүлэгчдэд нөлөөлөхгүй. Нэмж дурдахад, туршилтын явцад ямар нэг зүйл үргэлж буруу болж болзошгүй тул бид үйлчлүүлэгчтэй байнга холбоотой байдаг. Энэ нь танд хүрсэн үр дүнг мэдээлэхээс гадна туршилтын явцад ямар нэг зүйлийг өөрчлөх боломжийг олгодог. Туршилт дууссаны дараа бид үргэлж тайлан гаргаж, илэрсэн дутагдлыг зааж, сайтын сул талыг арилгах зөвлөмжийг өгдөг.
Бид хэрхэн ажиллаж байна
Туршилт хийхдээ бид ботнетийг дуурайдаг. Бид сүлжээндээ байхгүй үйлчлүүлэгчидтэй ажилладаг тул хязгаарлалт эсвэл хамгаалалт идэвхжсэний улмаас туршилт эхний минутанд дуусахгүй байхын тулд ачааллыг нэг IP-ээс биш, харин өөрсдийн дэд сүлжээнээс хангадаг. Нэмж дурдахад бид ихээхэн ачаалал үүсгэхийн тулд өөрийн нэлээд хүчирхэг туршилтын сервертэй болсон.
Постулятууд
Хэт их нь сайн гэсэн үг биш
Бид бага ачаалалтай байх тусам нөөцийг бүтэлгүйтэлд хүргэж чадна. Хэрэв та секундэд нэг хүсэлт, тэр ч байтугай минутанд нэг хүсэлтээр сайтын үйл ажиллагааг зогсоож чадвал энэ нь маш сайн хэрэг. Учир нь бүдүүлэг байдлын хуулийн дагуу хэрэглэгчид эсвэл халдагчид санамсаргүйгээр энэ эмзэг байдалд орох болно.
Бүрэн бүтэлгүйтлээс хэсэгчлэн бүтэлгүйтсэн нь дээр
Бид системийг нэг төрлийн бус болгохыг үргэлж зөвлөж байна. Түүнээс гадна тэдгээрийг зөвхөн савлах замаар бус физик түвшинд салгах нь зүйтэй. Физик тусгаарлах тохиолдолд сайт дээр ямар нэг зүйл бүтэлгүйтсэн ч гэсэн энэ нь бүрэн ажиллахаа болихгүй байх магадлал өндөр бөгөөд хэрэглэгчид ядаж нэг хэсэг функцэд хандах боломжтой хэвээр байх болно.
Сайн архитектур нь тогтвортой байдлын үндэс юм
Нөөцийн эвдрэлийг тэсвэрлэх чадвар, түүний халдлага, ачааллыг тэсвэрлэх чадварыг дизайны үе шатанд, үнэн хэрэгтээ тэмдэглэлийн дэвтэрт эхний схемийг зурах үе шатанд тусгасан байх ёстой. Учир нь хэрэв үхлийн алдаа гарч ирвэл ирээдүйд засах боломжтой боловч энэ нь маш хэцүү байдаг.
Зөвхөн код төдийгүй тохиргоо сайн байх ёстой
Олон хүмүүс сайн хөгжүүлэлтийн баг нь алдаа дутагдалтай үйлчилгээний баталгаа гэж боддог. Сайн хөгжүүлэлтийн баг үнэхээр хэрэгтэй, гэхдээ бас сайн ажиллагаа, сайн DevOps байх ёстой. Өөрөөр хэлбэл, бидэнд Линукс болон сүлжээг зөв тохируулах, nginx дээр тохиргоог зөв бичих, хязгаар тогтоох гэх мэт мэргэжилтнүүд хэрэгтэй байна. Үгүй бол нөөц нь зөвхөн туршилтанд сайн ажиллах бөгөөд хэзээ нэгэн цагт үйлдвэрлэлд бүх зүйл эвдрэх болно.
Ачаалал ба стресс тестийн ялгаа
Ачааллын туршилт нь системийн үйл ажиллагааны хязгаарыг тодорхойлох боломжийг олгодог. Стресс тест нь системийн сул талыг олоход чиглэгддэг бөгөөд энэ системийг эвдэж, зарим хэсгүүдийн эвдрэлийн явцад хэрхэн ажиллахыг харах зорилготой юм. Энэ тохиолдолд стресс тест эхлэхээс өмнө ачааллын шинж чанар нь үйлчлүүлэгчдэд тодорхойгүй хэвээр үлддэг.
L7 халдлагын онцлог шинж чанарууд
Бид ихэвчлэн ачааллын төрлийг L7 ба L3, 4 түвшний ачаалалд хуваадаг. L7 нь програмын түвшний ачаалал бөгөөд ихэнхдээ энэ нь зөвхөн HTTP гэсэн утгатай боловч TCP протоколын түвшний аливаа ачааллыг бид хэлдэг.
L7 халдлага нь тодорхой онцлог шинж чанартай байдаг. Нэгдүгээрт, тэд шууд програм дээр ирдэг, өөрөөр хэлбэл тэдгээрийг сүлжээний хэрэгслээр тусгах магадлал багатай юм. Ийм халдлага нь логикийг ашигладаг бөгөөд үүнээс үүдэн тэд CPU, санах ой, диск, мэдээллийн сан болон бусад нөөцийг маш үр дүнтэй, бага ачаалалтай зарцуулдаг.
HTTP үер
Аливаа халдлагын үед ачааллыг бий болгох нь зохицуулахаас илүү хялбар байдаг бөгөөд L7-ийн хувьд энэ нь бас үнэн юм. Довтолгооны урсгалыг хууль ёсны урсгалаас ялгах нь тийм ч хялбар биш бөгөөд ихэнхдээ үүнийг давтамжаар хийж болно, гэхдээ хэрэв бүх зүйл зөв төлөвлөгдсөн бол логуудаас халдлага хаана, хууль ёсны хүсэлтүүд хаана байгааг ойлгох боломжгүй юм.
Эхний жишээ болгон HTTP Flood халдлагыг авч үзье. Графикаас харахад ийм халдлага нь ихэвчлэн маш хүчтэй байдаг бөгөөд доорх жишээн дээр хүсэлтийн оргил тоо минутанд 600 мянга давсан байна.
HTTP Flood нь ачаалал үүсгэх хамгийн хялбар арга юм. Ерөнхийдөө энэ нь ApacheBench гэх мэт ачааллын туршилтын хэрэгслийг авч, хүсэлт, зорилтыг тавьдаг. Ийм энгийн аргын тусламжтайгаар серверийн кэш рүү орох магадлал өндөр байдаг ч үүнийг тойрч гарахад хялбар байдаг. Жишээлбэл, хүсэлтэд санамсаргүй мөрүүдийг нэмэх нь серверийг шинэ хуудас руу байнга үйлчлэхэд хүргэдэг.
Мөн ачаалал үүсгэх явцад хэрэглэгчийн агентийн талаар бүү мартаарай. Алдартай туршилтын хэрэгслүүдийн олон хэрэглэгчийн агентуудыг системийн администраторууд шүүдэг бөгөөд энэ тохиолдолд ачаалал нь арын хэсэгт хүрэхгүй байж магадгүй юм. Та хүсэлтэд хөтчөөс бага эсвэл бага хүчинтэй толгой хэсгийг оруулснаар үр дүнг мэдэгдэхүйц сайжруулах боломжтой.
HTTP Flood халдлага нь энгийн хэрнээ сул талуудтай. Нэгдүгээрт, ачааллыг бий болгохын тулд их хэмжээний эрчим хүч шаардагдана. Хоёрдугаарт, ийм халдлагыг илрүүлэхэд маш хялбар байдаг, ялангуяа тэд нэг хаягаас ирдэг. Үүний үр дүнд хүсэлтийг системийн администраторууд эсвэл бүр үйлчилгээ үзүүлэгчийн түвшинд шууд шүүж эхэлдэг.
Хайлт хайх
Үр ашгийг алдалгүйгээр секундэд ирдэг хүсэлтийн тоог багасгахын тулд та бага зэрэг төсөөлөл үзүүлж, сайтыг судлах хэрэгтэй. Тиймээс та зөвхөн суваг эсвэл серверийг төдийгүй програмын бие даасан хэсгүүдийг, жишээлбэл, мэдээллийн сан эсвэл файлын системийг ачаалж болно. Та мөн сайт дээр том хэмжээний тооцоо хийдэг газруудыг хайж болно: тооцоолуур, бүтээгдэхүүн сонгох хуудас гэх мэт. Эцэст нь хэлэхэд, сайт нь хэдэн зуун мянган мөр бүхий хуудас үүсгэдэг PHP скрипттэй байдаг. Ийм скрипт нь серверийг ихээхэн ачаалдаг бөгөөд халдлагын бай болж чаддаг.
Хаана хайх вэ
Туршилт хийхээсээ өмнө бид эх сурвалжийг сканнердахдаа эхлээд сайт руу нь хардаг. Бид бүх төрлийн оролтын талбарууд, хүнд файлуудыг хайж байна - ерөнхийдөө нөөцөд асуудал үүсгэж, түүний ажиллагааг удаашруулж болох бүх зүйлийг хайж байна. Google Chrome болон Firefox-н программыг хөгжүүлэх хэрэгслүүд энд тусалж, хуудасны хариу өгөх хугацааг харуулдаг.
Бид мөн дэд домайнуудыг сканнердаж байна. Жишээлбэл, abc.com нэртэй онлайн дэлгүүр байдаг бөгөөд энэ нь admin.abc.com дэд домайнтай байдаг. Энэ нь зөвшөөрөлтэй админ самбар байх магадлалтай, гэхдээ хэрэв та үүн дээр ачаалал өгвөл энэ нь үндсэн нөөцөд асуудал үүсгэж болзошгүй юм.
Энэ сайт нь api.abc.com дэд домайнтай байж болно. Энэ нь гар утасны програмуудын эх үүсвэр байх магадлалтай. Програмыг App Store эсвэл Google Play дээрээс олж, тусгай хандалтын цэг суулгаж, API-г задалж, туршилтын бүртгэлийг бүртгэж болно. Асуудал нь хүмүүс зөвшөөрлөөр хамгаалагдсан аливаа зүйл нь үйлчилгээний халдлагыг үгүйсгэхээс хамгаалдаг гэж боддогт оршино. Зөвшөөрөл нь хамгийн сайн CAPTCHA гэж үздэг ч тийм биш юм. 10-20 туршилтын бүртгэл хийхэд хялбар байдаг, гэхдээ тэдгээрийг үүсгэснээр бид нарийн төвөгтэй, нууцлагдмал функцүүдэд хандах боломжтой болно.
Мэдээжийн хэрэг, бид robots.txt болон WebArchive, ViewDNS-ээс түүхийг харж, нөөцийн хуучин хувилбаруудыг хайж олох болно. Заримдаа хөгжүүлэгчид mail2.yandex.net-ийг гаргасан ч хуучин хувилбар болох mail.yandex.net хэвээр байна. Энэ mail.yandex.net цаашид дэмжигдэхгүй, хөгжүүлэлтийн нөөц түүнд хуваарилагдаагүй ч мэдээллийн санг үргэлжлүүлэн ашигласаар байна. Үүний дагуу хуучин хувилбарыг ашигласнаар та арын хэсгийн нөөц болон байршлын ард байгаа бүх зүйлийг үр дүнтэй ашиглах боломжтой. Мэдээжийн хэрэг, энэ нь үргэлж тохиолддоггүй, гэхдээ бид ийм зүйлтэй байнга тулгардаг.
Мэдээжийн хэрэг, бид хүсэлтийн бүх параметрүүд болон күүки бүтцэд дүн шинжилгээ хийдэг. Та күүки доторх JSON массив руу зарим утгыг буулгаж, олон тооны үүрийг үүсгэж, нөөцийг үндэслэлгүй удаан ажиллуулах боломжтой гэж хэлж болно.
Хайлтын ачаалал
Сайтыг судлахад хамгийн түрүүнд санаанд орж ирдэг зүйл бол мэдээллийн баазыг ачаалах явдал юм, учир нь бараг бүх хүн хайлт хийдэг бөгөөд бараг бүх хүмүүст харамсалтай нь хамгаалалт муутай байдаг. Зарим шалтгааны улмаас хөгжүүлэгчид хайлтанд хангалттай анхаарал хандуулдаггүй. Гэхдээ энд нэг зөвлөмж байна - та ижил төрлийн хүсэлт гаргах ёсгүй, учир нь та HTTP үерийн нэгэн адил кэштэй тулгарч магадгүй юм.
Өгөгдлийн санд санамсаргүй асуулга хийх нь үргэлж үр дүнтэй байдаггүй. Хайлтанд тохирох түлхүүр үгсийн жагсаалтыг гаргах нь илүү дээр юм. Хэрэв бид онлайн дэлгүүрийн жишээ рүү буцвал: энэ сайт нь автомашины дугуй зардаг бөгөөд дугуйны радиус, машины төрөл болон бусад параметрүүдийг тохируулах боломжийг олгодог гэж үзье. Үүний дагуу холбогдох үгсийн хослол нь мэдээллийн санг илүү төвөгтэй нөхцөлд ажиллахад хүргэдэг.
Нэмж дурдахад хуудасны тэмдэглэгээг ашиглах нь зүйтэй: хайлтын үр дүнгийн эцсийн хуудсыг буцаах нь эхнийхээс хамаагүй хэцүү байдаг. Өөрөөр хэлбэл, хуудасны тусламжтайгаар та ачааллыг бага зэрэг төрөлжүүлэх боломжтой.
Доорх жишээ нь хайлтын ачааллыг харуулж байна. Туршилтын эхний секундээс секундэд арван хүсэлтийн хурдтайгаар сайт унтарч, хариу өгөхгүй байгааг харж болно.
Хэрэв хайлт байхгүй бол?
Хэрэв хайлт байхгүй бол энэ нь сайт нь бусад эмзэг оролтын талбаруудыг агуулаагүй гэсэн үг биш юм. Энэ талбар нь зөвшөөрөл байж болно. Өнөө үед хөгжүүлэгчид нэвтрэх мэдээллийн санг солонгын хүснэгтийн халдлагаас хамгаалахын тулд нарийн төвөгтэй хэш хийх дуртай байдаг. Энэ нь сайн, гэхдээ ийм хэш нь CPU-ийн нөөцийг их хэмжээгээр хэрэглэдэг. Хуурамч зөвшөөрлийн их урсгал нь процессорын доголдолд хүргэдэг бөгөөд үүний үр дүнд сайт ажиллахаа болино.
Сайт дээр сэтгэгдэл, санал хүсэлтийн бүх төрлийн маягт байгаа нь маш том текст илгээх эсвэл зүгээр л их хэмжээний үер үүсгэх шалтгаан болдог. Заримдаа сайтууд хавсаргасан файлуудыг, түүний дотор gzip форматыг хүлээн авдаг. Энэ тохиолдолд бид 1TB файлыг авч, gzip ашиглан хэд хэдэн байт эсвэл килобайт болгон шахаж сайт руу илгээдэг. Дараа нь үүнийг задалж, маш сонирхолтой эффектийг олж авна.
Амрах API
Би Rest API гэх мэт алдартай үйлчилгээнүүдэд бага зэрэг анхаарал хандуулахыг хүсч байна. Rest API-г хамгаалах нь ердийн вэбсайтаас хамаагүй хэцүү байдаг. Нууц үгийн бүдүүлэг хүч болон бусад хууль бус үйлдлээс хамгаалах өчүүхэн аргууд ч Rest API-д тохирохгүй.
Rest API нь мэдээллийн санд шууд ханддаг тул эвдэхэд маш хялбар байдаг. Үүний зэрэгцээ ийм үйлчилгээний бүтэлгүйтэл нь бизнест нэлээд ноцтой үр дагаварт хүргэдэг. Баримт нь Rest API нь ихэвчлэн үндсэн вэбсайтад төдийгүй мобайл програм болон зарим дотоод бизнесийн нөөцөд ашиглагддаг. Хэрэв энэ бүхэн уналтад орвол үр нөлөө нь энгийн вэб сайтын бүтэлгүйтлээс хамаагүй хүчтэй болно.
Хүнд контентыг ачаалж байна
Хэрэв бидэнд нарийн төвөгтэй ажиллагаагүй энгийн нэг хуудастай програм, буух хуудас эсвэл нэрийн хуудасны вэбсайтыг туршихыг санал болговол бид хүнд контент хайж байна. Жишээлбэл, серверийн илгээдэг том зургууд, хоёртын файлууд, pdf баримтууд - бид энэ бүгдийг татаж авахыг хичээдэг. Ийм туршилтууд нь файлын системийг сайн ачаалж, суваг бөглөрдөг тул үр дүнтэй байдаг. Өөрөөр хэлбэл, та серверээ буулгаагүй, бага хурдаар том файл татаж авбал зорилтот серверийн сувгийг бөглөж, дараа нь үйлчилгээ үзүүлэхээс татгалзах болно.
Ийм туршилтын жишээ нь 30 RPS хурдтайгаар сайт хариу өгөхөө больсон эсвэл 500 дахь серверийн алдааг гаргаж байгааг харуулж байна.
Серверүүдийг тохируулах талаар бүү мартаарай. Нэг хүн виртуал машин худалдаж аваад, тэнд Apache суулгаж, бүх зүйлийг анхдагчаар тохируулж, PHP програм суулгаж, үр дүнг доороос харж болно.
Энд ачаалал үндсэн дээр очсон бөгөөд ердөө 10 RPS байв. Бид 5 минут хүлээсэн бөгөөд сервер гацсан. Түүнийг яагаад унасан нь бүрэн тодорхойгүй байгаа нь үнэн, гэхдээ тэр зүгээр л хэт их ой санамжтай байсан тул хариу өгөхөө больсон гэсэн таамаглал байдаг.
Долгион дээр суурилсан
Сүүлийн нэг хоёр жилийн хугацаанд долгионы халдлага нэлээд алдартай болсон. Энэ нь олон байгууллага DDoS хамгаалалтад зориулж тодорхой хэмжээний техник хангамж худалдаж авдаг бөгөөд энэ нь халдлагыг шүүж эхлэхийн тулд статистик мэдээлэл цуглуулахад тодорхой хугацаа шаардагддагтай холбоотой юм. Өөрөөр хэлбэл, тэд эхний 30-40 секундын дотор халдлагыг шүүдэггүй, учир нь тэд өгөгдөл цуглуулж, суралцдаг. Үүний дагуу эдгээр 30-40 секундын дотор та сайт дээр маш их зүйлийг эхлүүлэх боломжтой тул бүх хүсэлтийг арилгах хүртэл нөөц удаан хугацаанд хэвтэх болно.
Доорх довтолгооны хувьд 10 минутын завсарлагатай байсан бөгөөд үүний дараа довтолгооны шинэ, өөрчлөгдсөн хэсэг ирсэн.
Өөрөөр хэлбэл, хамгаалалт сурсан, шүүж эхэлсэн боловч довтолгооны шинэ, огт өөр хэсэг ирж, хамгаалалт дахин суралцаж эхлэв. Үнэн хэрэгтээ шүүлтүүр нь ажиллахаа больж, хамгаалалт үр дүнгүй болж, сайтыг ашиглах боломжгүй болно.
Долгионы довтолгоо нь оргил үедээ маш өндөр утгаараа тодорхойлогддог бөгөөд L7 тохиолдолд секундэд нэг зуун мянга эсвэл сая хүсэлт хүрч чаддаг. Хэрэв бид L3 & 4-ийн талаар ярих юм бол хэдэн зуун гигабит траффик, эсвэл багцаар тооцвол хэдэн зуун mpps байж болно.
Ийм халдлагын асуудал бол синхрончлол юм. Халдлагууд нь ботнетээс ирдэг бөгөөд нэг удаагийн огцом өсөлтийг бий болгохын тулд өндөр түвшний синхрончлол шаарддаг. Мөн энэ зохицуулалт нь үргэлж үр дүнтэй байдаггүй: заримдаа гаралт нь зарим төрлийн параболик оргил байдаг бөгөөд энэ нь үнэхээр өрөвдмөөр харагддаг.
Зөвхөн HTTP биш
L7 дээрх HTTP-ээс гадна бид бусад протоколуудыг ашиглах дуртай. Дүрмээр бол ердийн вэбсайт, ялангуяа ердийн хостинг нь шуудангийн протоколууд болон MySQL-тэй байдаг. Мэйл протоколууд нь өгөгдлийн сангаас бага ачаалалтай байдаг ч тэд маш үр дүнтэй ачаалагддаг бөгөөд сервер дээр хэт ачаалалтай CPU-тэй болдог.
Бид 2016 оны SSH эмзэг байдлыг амжилттай ашиглаж чадсан. Одоо энэ эмзэг байдлыг бараг бүх хүмүүст зассан боловч энэ нь ачааллыг SSH-д оруулах боломжгүй гэсэн үг биш юм. Чадах. Зүгээр л асар их зөвшөөрлийн ачаалал байдаг, SSH нь сервер дээрх бараг бүх CPU-г иддэг бөгөөд дараа нь секундэд нэг эсвэл хоёр хүсэлтээс вэбсайт сүйрдэг. Иймээс бүртгэл дээр үндэслэсэн эдгээр нэг эсвэл хоёр хүсэлтийг хууль ёсны ачааллаас ялгах боломжгүй юм.
Бидний серверт нээсэн олон холболтууд мөн хамааралтай хэвээр байна. Өмнө нь Apache үүнд буруутай байсан бол одоо nginx буруутай, учир нь энэ нь ихэвчлэн анхдагчаар тохируулагдсан байдаг. Nginx-ийн нээлттэй байлгах холболтын тоо хязгаарлагдмал тул бид ийм тооны холболтыг нээснээр nginx шинэ холболтыг хүлээн авахаа больсон бөгөөд үүний үр дүнд сайт ажиллахгүй болно.
Манай туршилтын кластер нь SSL гар барихад халдах хангалттай CPU-тэй. Зарчмын хувьд, практикээс харахад ботнетууд заримдаа үүнийг хийх дуртай байдаг. Нэг талаас, Google-ийн үр дүн, зэрэглэл, аюулгүй байдал зэрэг нь SSL-гүйгээр хийх боломжгүй нь ойлгомжтой. Нөгөө талаас, харамсалтай нь 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-ACK-д хариу өгөх эмзэг эсвэл буруу тохируулагдсан серверүүдийг олдог. Зорилтот серверийн хаягаас эх хаягийг хууран мэхлэснээр нэг пакетаар эрчим хүчийг гурав дахин нэмэгдүүлж, хохирогч руу урсгалыг дахин чиглүүлэх боломжтой.
Олшруулалтын асуудал нь тэдгээрийг илрүүлэхэд хэцүү байдаг. Сүүлийн үеийн жишээнүүдэд эмзэг memcached-ийн дуулиан шуугиантай хэрэг багтсан болно. Нэмж дурдахад, одоо маш олон IoT төхөөрөмж, IP камерууд байдаг бөгөөд тэдгээр нь ихэвчлэн анхдагчаар тохируулагдсан байдаг бөгөөд анхдагч байдлаар буруу тохируулагдсан байдаг тул халдагчид ийм төхөөрөмжөөр ихэвчлэн халдлага хийдэг.
Хэцүү SYN үер
SYN-flood нь магадгүй хөгжүүлэгчийн үүднээс хамгийн сонирхолтой халдлага юм. Асуудал нь системийн администраторууд хамгаалах зорилгоор IP хориглолтыг ихэвчлэн ашигладаг. Түүгээр ч барахгүй IP хаалт нь зөвхөн скрипт ашиглан ажилладаг системийн администраторуудад төдийгүй харамсалтай нь маш их мөнгөөр худалдаж авсан хамгаалалтын зарим системд нөлөөлдөг.
Энэ арга нь гамшиг болж хувирах болно, учир нь халдагчид IP хаягийг солих юм бол компани өөрийн дэд сүлжээг хаах болно. Галт хана нь өөрийн кластерыг блоклох үед гаралт нь гадны харилцан үйлчлэлд амжилтгүй болж, нөөц амжилтгүй болно.
Түүнээс гадна өөрийн сүлжээг хаах нь тийм ч хэцүү биш юм. Хэрэв үйлчлүүлэгчийн оффис нь Wi-Fi сүлжээтэй эсвэл нөөцийн гүйцэтгэлийг янз бүрийн хяналтын систем ашиглан хэмждэг бол бид энэ хяналтын систем эсвэл үйлчлүүлэгчийн оффисын Wi-Fi-ийн IP хаягийг авч, эх сурвалж болгон ашигладаг. Төгсгөлд нь нөөц боломжтой мэт боловч зорилтот IP хаягууд хаагдсан байна. Тиймээс компанийн шинэ бүтээгдэхүүнийг танилцуулж буй HighLoad бага хурлын Wi-Fi сүлжээг хааж болох бөгөөд энэ нь бизнесийн болон эдийн засгийн тодорхой зардалд хүргэдэг.
Туршилтын явцад бид зөвхөн зөвшөөрөгдсөн IP хаягууд руу траффик илгээх гэрээтэй байдаг тул бид гадны ямар ч эх сурвалжтай memcach-ээр дамжуулан өсгөлтийг ашиглах боломжгүй. Үүний дагуу бид SYN ба SYN-ACK-ээр дамжуулан өсгөлтийг ашигладаг бөгөөд систем нь нэг SYN-ийг хоёр, гурван SYN-ACK-ээр илгээхэд хариу үйлдэл үзүүлэх бөгөөд гаралтын үед халдлагыг хоёроос гурав дахин үржүүлдэг.
Хэрэгсэл
L7 ажлын ачаалалд бидний ашигладаг гол хэрэгслүүдийн нэг бол Yandex-tank юм. Ялангуяа хийсвэрийг буу болгон ашигладаг бөгөөд сум үүсгэх, үр дүнд нь дүн шинжилгээ хийх хэд хэдэн скриптүүд байдаг.
Tcpdump нь сүлжээний урсгалыг шинжлэхэд, Nmap нь серверт дүн шинжилгээ хийхэд ашиглагддаг. L3 & 4 түвшинд ачааллыг бий болгохын тулд OpenSSL болон DPDK номын сантай өөрийн ид шидийг ашигладаг. DPDK нь Intel-ийн номын сан бөгөөд Линукс стекийг тойрч сүлжээний интерфейстэй ажиллах боломжийг олгодог бөгөөд ингэснээр үр ашгийг нэмэгдүүлнэ. Мэдээжийн хэрэг, бид DPDK-ийг зөвхөн L3 & 4 түвшинд төдийгүй L7 түвшинд ашигладаг, учир нь энэ нь нэг машинаас секундэд хэдэн сая хүсэлт илгээх хүрээнд маш өндөр ачааллын урсгалыг бий болгох боломжийг олгодог.
Бид мөн тодорхой туршилтанд зориулж бичсэн замын хөдөлгөөний генератор болон тусгай хэрэгслийг ашигладаг. Хэрэв бид SSH-ийн эмзэг байдлыг эргэн санавал дээрх багцыг ашиглах боломжгүй. Хэрэв бид шуудангийн протокол руу халдах юм бол бид шуудангийн хэрэгслүүдийг авч эсвэл зүгээр л скрипт бичдэг.
үр дүн нь
Дүгнэж хэлэхэд би дараахь зүйлийг хэлмээр байна.
- Сонгодог ачааллын туршилтаас гадна стресс тест хийх шаардлагатай. Түншийн туслан гүйцэтгэгч зөвхөн ачааллын туршилт хийдэг бодит жишээ бидэнд бий. Энэ нь нөөц нь хэвийн ачааллыг тэсвэрлэх чадвартай болохыг харуулсан. Гэвч дараа нь хэвийн бус ачаалал гарч, сайтын зочдод нөөцийг арай өөрөөр ашиглаж эхэлсэн бөгөөд үүний үр дүнд туслан гүйцэтгэгч хэвтэв. Тиймээс DDoS халдлагаас аль хэдийн хамгаалагдсан байсан ч эмзэг байдлыг хайх нь зүйтэй.
- Системийн зарим хэсгийг бусдаас тусгаарлах шаардлагатай. Хэрэв танд хайлт байгаа бол үүнийг тусдаа машинууд руу, өөрөөр хэлбэл Docker руу ч шилжүүлэхгүй байх хэрэгтэй. Учир нь хайлт эсвэл зөвшөөрөл амжилтгүй болбол ядаж ямар нэг зүйл үргэлжлүүлэн ажиллах болно. Онлайн дэлгүүрийн хувьд хэрэглэгчид каталогоос бүтээгдэхүүнээ хайж олох, нэгтгэгчээс явах, аль хэдийн зөвшөөрөл авсан бол худалдаж авах, эсвэл OAuth2-ээр дамжуулан зөвшөөрөл өгөх болно.
- Бүх төрлийн үүлэн үйлчилгээг үл тоомсорлож болохгүй.
- CDN-ийг зөвхөн сүлжээний саатлыг оновчтой болгох төдийгүй сувгийн хомсдол, статик урсгал руу цутгах халдлагаас хамгаалах хэрэгсэл болгон ашигла.
- Тусгай хамгаалалтын үйлчилгээг ашиглах шаардлагатай. Та сувгийн түвшинд L3 & 4 халдлагаас өөрийгөө хамгаалах боломжгүй, учир нь танд хангалттай суваг байхгүй байх магадлалтай. Та мөн L7-ийн дайралттай тэмцэх магадлал багатай, учир нь тэдгээр нь маш том хэмжээтэй байж болно. Нэмж дурдахад жижиг халдлагуудыг хайх нь тусгай алба, тусгай алгоритмуудын эрх мэдэл хэвээр байна.
- Тогтмол шинэчлээрэй. Энэ нь зөвхөн цөмд төдийгүй SSH дэмонд ч хамаатай, ялангуяа хэрэв та тэдгээрийг гаднаас нь харж болно. Зарчмын хувьд бүх зүйлийг шинэчлэх шаардлагатай байдаг, учир нь та тодорхой эмзэг байдлыг өөрөө хянах боломжгүй юм.
Эх сурвалж: www.habr.com