Mae Variti yn datblygu amddiffyniad rhag bots ac ymosodiadau DDoS, ac mae hefyd yn cynnal profion straen a llwyth. Yng nghynhadledd HighLoad++ 2018 buom yn siarad am sut i sicrhau adnoddau o wahanol fathau o ymosodiadau. Yn fyr: ynysu rhannau o'r system, defnyddio gwasanaethau cwmwl a CDNs, a diweddaru'n rheolaidd. Ond ni fyddwch yn gallu trin amddiffyniad heb gwmnïau arbenigol o hyd :)
Cyn darllen y testun, gallwch ddarllen y crynodebau byr .
Ac os nad ydych chi'n hoffi darllen neu ddim ond eisiau gwylio'r fideo, mae recordiad ein hadroddiad isod o dan y sbwyliwr.
Recordiad fideo o'r adroddiad
Mae llawer o gwmnïau eisoes yn gwybod sut i wneud profion llwyth, ond nid yw pob un yn gwneud profion straen. Mae rhai o'n cwsmeriaid yn meddwl bod eu gwefan yn agored i niwed oherwydd bod ganddyn nhw system llwyth uchel, ac mae'n amddiffyn yn dda rhag ymosodiadau. Dangoswn nad yw hyn yn hollol wir.
Wrth gwrs, cyn cynnal profion, rydym yn cael caniatâd y cwsmer, wedi'i lofnodi a'i stampio, a gyda'n cymorth ni ni ellir cynnal ymosodiad DDoS ar unrhyw un. Cynhelir profion ar amser a ddewisir gan y cwsmer, pan fo traffig i'w adnodd yn fach iawn, ac ni fydd problemau mynediad yn effeithio ar gleientiaid. Yn ogystal, gan y gall rhywbeth fynd o'i le bob amser yn ystod y broses brofi, mae gennym gysylltiad cyson â'r cwsmer. Mae hyn yn caniatáu ichi nid yn unig adrodd ar y canlyniadau a gyflawnwyd, ond hefyd i newid rhywbeth yn ystod y profion. Ar ôl cwblhau'r profion, rydym bob amser yn llunio adroddiad lle rydym yn nodi'r diffygion a ganfuwyd ac yn rhoi argymhellion ar gyfer dileu gwendidau'r safle.
Sut rydyn ni'n gweithio
Wrth brofi, rydym yn efelychu botnet. Gan ein bod yn gweithio gyda chleientiaid nad ydynt wedi'u lleoli ar ein rhwydweithiau, er mwyn sicrhau na fydd y prawf yn dod i ben yn y funud gyntaf oherwydd cyfyngiadau neu amddiffyniad, rydym yn cyflenwi'r llwyth nid o un IP, ond o'n his-rwydwaith ein hunain. Hefyd, i greu llwyth sylweddol, mae gennym ein gweinydd prawf eithaf pwerus ein hunain.
Postulates
Nid yw gormod yn golygu da
Gorau po leiaf o lwyth y gallwn ddod ag adnodd i fethiant. Os gallwch chi wneud i'r wefan stopio gweithredu ar un cais yr eiliad, neu hyd yn oed un cais y funud, mae hynny'n wych. Oherwydd yn ôl cyfraith gwallgofrwydd, bydd defnyddwyr neu ymosodwyr yn syrthio i'r bregusrwydd penodol hwn yn ddamweiniol.
Mae methiant rhannol yn well na methiant llwyr
Rydym bob amser yn cynghori systemau gwneud heterogenaidd. Ar ben hynny, mae'n werth eu gwahanu ar y lefel gorfforol, ac nid dim ond trwy gynhwysydd. Yn achos gwahaniad corfforol, hyd yn oed os bydd rhywbeth yn methu ar y wefan, mae'n debygol iawn na fydd yn rhoi'r gorau i weithio'n llwyr, a bydd defnyddwyr yn parhau i gael mynediad at o leiaf rhan o'r swyddogaeth.
Mae pensaernïaeth dda yn sail i gynaliadwyedd
Dylid gosod goddefgarwch bai adnodd a'i allu i wrthsefyll ymosodiadau a llwythi yn ystod y cam dylunio, mewn gwirionedd, ar y cam o lunio'r siartiau llif cyntaf mewn llyfr nodiadau. Oherwydd os bydd gwallau angheuol yn ymledu, mae'n bosibl eu cywiro yn y dyfodol, ond mae'n anodd iawn.
Nid yn unig y dylai'r cod fod yn dda, ond hefyd y ffurfwedd
Mae llawer o bobl yn meddwl bod tîm datblygu da yn warant o wasanaeth sy'n goddef diffygion. Mae tîm datblygu da yn wirioneddol angenrheidiol, ond rhaid cael gweithrediadau da hefyd, DevOps da. Hynny yw, mae angen arbenigwyr arnom a fydd yn ffurfweddu Linux a'r rhwydwaith yn gywir, yn ysgrifennu cyfluniadau'n gywir yn nginx, yn gosod terfynau, ac ati. Fel arall, dim ond wrth brofi y bydd yr adnodd yn gweithio'n dda, ac ar ryw adeg bydd popeth yn torri yn y cynhyrchiad.
Gwahaniaethau rhwng profion llwyth a straen
Mae profion llwyth yn caniatáu ichi nodi terfynau gweithrediad system. Mae profion straen wedi'u hanelu at ddod o hyd i wendidau mewn system ac fe'i defnyddir i dorri'r system hon a gweld sut y bydd yn ymddwyn yn y broses o fethiant rhai rhannau. Yn yr achos hwn, mae natur y llwyth fel arfer yn parhau i fod yn anhysbys i'r cwsmer cyn i brofion straen ddechrau.
Nodweddion unigryw ymosodiadau L7
Rydym fel arfer yn rhannu mathau o lwyth yn llwythi ar y lefelau L7 a L3 a 4. Mae L7 yn llwyth ar lefel y cais, yn fwyaf aml mae'n golygu HTTP yn unig, ond rydym yn golygu unrhyw lwyth ar lefel protocol TCP.
Mae gan ymosodiadau L7 rai nodweddion nodedig. Yn gyntaf, maent yn dod yn uniongyrchol i'r cais, hynny yw, mae'n annhebygol y byddant yn cael eu hadlewyrchu trwy ddulliau rhwydwaith. Mae ymosodiadau o'r fath yn defnyddio rhesymeg, ac oherwydd hyn, maent yn defnyddio CPU, cof, disg, cronfa ddata ac adnoddau eraill yn effeithlon iawn a heb fawr o draffig.
Llifogydd HTTP
Yn achos unrhyw ymosodiad, mae'r llwyth yn haws i'w greu nag i'w drin, ac yn achos L7 mae hyn hefyd yn wir. Nid yw bob amser yn hawdd gwahaniaethu traffig ymosod oddi wrth draffig cyfreithlon, ac yn fwyaf aml gellir gwneud hyn yn ôl amlder, ond os yw popeth wedi'i gynllunio'n gywir, yna mae'n amhosibl deall o'r logiau ble mae'r ymosodiad a ble mae'r ceisiadau cyfreithlon.
Fel enghraifft gyntaf, ystyriwch ymosodiad Llifogydd HTTP. Mae'r graff yn dangos bod ymosodiadau o'r fath fel arfer yn bwerus iawn; yn yr enghraifft isod, roedd nifer brig y ceisiadau yn fwy na 600 mil y funud.
HTTP Flood yw'r ffordd hawsaf o greu llwyth. Yn nodweddiadol, mae'n cymryd rhyw fath o offeryn profi llwyth, fel ApacheBench, ac yn gosod cais a tharged. Gyda dull mor syml, mae tebygolrwydd uchel o redeg i mewn i caching gweinydd, ond mae'n hawdd ei osgoi. Er enghraifft, ychwanegu llinynnau ar hap i'r cais, a fydd yn gorfodi'r gweinydd i wasanaethu tudalen newydd yn gyson.
Hefyd, peidiwch ag anghofio am yr asiant defnyddiwr yn y broses o greu llwyth. Mae llawer o ddefnyddwyr-asiantau offer profi poblogaidd yn cael eu hidlo gan weinyddwyr system, ac yn yr achos hwn efallai na fydd y llwyth yn cyrraedd y pen ôl. Gallwch wella'r canlyniad yn sylweddol trwy fewnosod pennawd mwy neu lai dilys o'r porwr yn y cais.
Mor syml ag ymosodiadau Llifogydd HTTP, mae ganddyn nhw hefyd eu hanfanteision. Yn gyntaf, mae angen llawer iawn o bŵer i greu'r llwyth. Yn ail, mae ymosodiadau o'r fath yn hawdd iawn i'w canfod, yn enwedig os ydynt yn dod o un cyfeiriad. O ganlyniad, mae ceisiadau ar unwaith yn dechrau cael eu hidlo naill ai gan weinyddwyr system neu hyd yn oed ar lefel y darparwr.
Beth i'w chwilio
Er mwyn lleihau nifer y ceisiadau yr eiliad heb golli effeithlonrwydd, mae angen i chi ddangos ychydig o ddychymyg ac archwilio'r wefan. Felly, gallwch chi lwytho nid yn unig y sianel neu'r gweinydd, ond hefyd rhannau unigol o'r rhaglen, er enghraifft, cronfeydd data neu systemau ffeiliau. Gallwch hefyd chwilio am leoedd ar y wefan sy'n gwneud cyfrifiadau mawr: cyfrifianellau, tudalennau dewis cynnyrch, ac ati. Yn olaf, mae'n aml yn digwydd bod gan y wefan ryw fath o sgript PHP sy'n cynhyrchu tudalen o gannoedd o filoedd o linellau. Mae sgript o'r fath hefyd yn llwytho'r gweinydd yn sylweddol a gall ddod yn darged ar gyfer ymosodiad.
Ble i edrych
Pan fyddwn yn sganio adnodd cyn ei brofi, rydym yn edrych yn gyntaf, wrth gwrs, ar y safle ei hun. Rydym yn chwilio am bob math o feysydd mewnbwn, ffeiliau trwm - yn gyffredinol, popeth a all greu problemau i'r adnodd ac arafu ei weithrediad. Mae offer datblygu banal yn Google Chrome a Firefox yn helpu yma, gan ddangos amseroedd ymateb tudalennau.
Rydym hefyd yn sganio is-barthau. Er enghraifft, mae yna siop ar-lein benodol, abc.com, ac mae ganddo is-barth admin.abc.com. Yn fwyaf tebygol, mae hwn yn banel gweinyddol gydag awdurdodiad, ond os rhowch lwyth arno, gall greu problemau i'r prif adnodd.
Efallai bod gan y wefan is-barth api.abc.com. Yn fwyaf tebygol, mae hwn yn adnodd ar gyfer cymwysiadau symudol. Gellir dod o hyd i'r cymhwysiad yn yr App Store neu Google Play, gosodwch bwynt mynediad arbennig, dyrannu'r API a chofrestru cyfrifon prawf. Y broblem yw bod pobl yn aml yn meddwl bod unrhyw beth sy'n cael ei ddiogelu gan awdurdodiad yn imiwn i ymosodiadau gwrthod gwasanaeth. Yn ôl pob tebyg, awdurdodi yw'r CAPTCHA gorau, ond nid yw. Mae'n hawdd gwneud 10-20 o gyfrifon prawf, ond trwy eu creu, rydyn ni'n cael mynediad at swyddogaethau cymhleth a heb eu cuddio.
Yn naturiol, rydym yn edrych ar hanes, yn robots.txt a WebArchive, ViewDNS, ac yn edrych am hen fersiynau o'r adnodd. Weithiau mae'n digwydd bod datblygwyr wedi cyflwyno, dyweder, mail2.yandex.net, ond mae'r hen fersiwn, mail.yandex.net, yn parhau. Nid yw'r mail.yandex.net hwn yn cael ei gefnogi mwyach, ni chaiff adnoddau datblygu eu dyrannu iddo, ond mae'n parhau i ddefnyddio'r gronfa ddata. Yn unol â hynny, gan ddefnyddio'r hen fersiwn, gallwch chi ddefnyddio adnoddau'r backend a phopeth sydd y tu ôl i'r cynllun yn effeithiol. Wrth gwrs, nid yw hyn bob amser yn digwydd, ond rydym yn dal i ddod ar draws hyn yn eithaf aml.
Yn naturiol, rydym yn dadansoddi'r holl baramedrau cais a'r strwythur cwci. Gallwch, dyweder, daflu rhywfaint o werth i mewn i arae JSON y tu mewn i gwci, creu llawer o nythu a gwneud i'r adnodd weithio am amser afresymol o hir.
Chwilio llwyth
Y peth cyntaf sy'n dod i'r meddwl wrth ymchwilio i safle yw llwytho'r gronfa ddata, gan fod bron pawb yn chwilio, ac i bron pawb, yn anffodus, mae wedi'i warchod yn wael. Am ryw reswm, nid yw datblygwyr yn talu digon o sylw i chwilio. Ond mae un argymhelliad yma - ni ddylech wneud ceisiadau o'r un math, oherwydd efallai y byddwch yn dod ar draws caching, fel sy'n wir gyda llifogydd HTTP.
Nid yw gwneud ymholiadau ar hap i'r gronfa ddata bob amser yn effeithiol ychwaith. Mae'n llawer gwell creu rhestr o eiriau allweddol sy'n berthnasol i'r chwiliad. Os byddwn yn dychwelyd at yr enghraifft o siop ar-lein: gadewch i ni ddweud bod y wefan yn gwerthu teiars car ac yn caniatáu ichi osod radiws y teiars, y math o gar a pharamedrau eraill. Yn unol â hynny, bydd cyfuniadau o eiriau perthnasol yn gorfodi'r gronfa ddata i weithio mewn amodau llawer mwy cymhleth.
Yn ogystal, mae'n werth defnyddio tudaleniad: mae'n llawer anoddach i chwiliad ddychwelyd tudalen olaf ond un y canlyniadau chwilio na'r cyntaf. Hynny yw, gyda chymorth tudaleniad gallwch chi arallgyfeirio'r llwyth ychydig.
Mae'r enghraifft isod yn dangos y llwyth chwilio. Gellir gweld, o eiliad cyntaf un y prawf ar gyflymder o ddeg cais yr eiliad, aeth y safle i lawr ac ni ymatebodd.
Os nad oes chwiliad?
Os nad oes chwiliad, nid yw hyn yn golygu nad yw'r wefan yn cynnwys meysydd mewnbwn bregus eraill. Gall y maes hwn fod yn awdurdodiad. Y dyddiau hyn, mae datblygwyr yn hoffi gwneud hashes cymhleth i amddiffyn y gronfa ddata mewngofnodi rhag ymosodiad bwrdd enfys. Mae hyn yn dda, ond mae hashes o'r fath yn defnyddio llawer o adnoddau CPU. Mae llif mawr o awdurdodiadau ffug yn arwain at fethiant prosesydd, ac o ganlyniad, mae'r safle'n rhoi'r gorau i weithio.
Mae presenoldeb ar y safle o bob math o ffurflenni ar gyfer sylwadau ac adborth yn rheswm i anfon testunau mawr iawn yno neu yn syml greu llifogydd enfawr. Weithiau mae safleoedd yn derbyn ffeiliau atodedig, gan gynnwys fformat gzip. Yn yr achos hwn, rydym yn cymryd ffeil 1TB, yn ei chywasgu i sawl beit neu cilobeit gan ddefnyddio gzip a'i hanfon i'r wefan. Yna caiff ei ddadsipio a cheir effaith ddiddorol iawn.
Gorffwys API
Hoffwn dalu ychydig o sylw i wasanaethau mor boblogaidd â'r Rest API. Mae sicrhau API Rest yn llawer anoddach na gwefan arferol. Nid yw hyd yn oed dulliau dibwys o amddiffyniad rhag grym 'n Ysgrublaidd cyfrinair a gweithgaredd anghyfreithlon arall yn gweithio i'r API Rest.
Mae'r API Rest yn hawdd iawn i'w dorri oherwydd ei fod yn cyrchu'r gronfa ddata yn uniongyrchol. Ar yr un pryd, mae methiant gwasanaeth o'r fath yn golygu canlyniadau eithaf difrifol i fusnes. Y ffaith yw bod yr API Rest yn cael ei ddefnyddio fel arfer nid yn unig ar gyfer y brif wefan, ond hefyd ar gyfer y cais symudol a rhai adnoddau busnes mewnol. Ac os bydd hyn i gyd yn disgyn, yna mae'r effaith yn llawer cryfach nag yn achos methiant gwefan syml.
Llwytho cynnwys trwm
Os ydym yn cael cynnig i brofi rhai cymhwysiad un dudalen arferol, tudalen lanio, neu wefan cerdyn busnes nad oes ganddo ymarferoldeb cymhleth, rydym yn edrych am gynnwys trwm. Er enghraifft, delweddau mawr y mae'r gweinydd yn eu hanfon, ffeiliau deuaidd, dogfennaeth pdf - rydym yn ceisio lawrlwytho hyn i gyd. Mae profion o'r fath yn llwytho'r system ffeiliau yn dda ac yn clocsio sianeli, ac felly maent yn effeithiol. Hynny yw, hyd yn oed os na fyddwch chi'n rhoi'r gweinydd i lawr, gan lawrlwytho ffeil fawr ar gyflymder isel, byddwch chi'n clogio sianel y gweinydd targed ac yna bydd gwrthod gwasanaeth yn digwydd.
Mae enghraifft o brawf o'r fath yn dangos bod y wefan wedi rhoi'r gorau i ymateb ar gyflymder o 30 RPS neu wedi cynhyrchu 500fed gwall gweinydd.
Peidiwch ag anghofio am sefydlu gweinyddion. Yn aml, gallwch chi ddarganfod bod person wedi prynu peiriant rhithwir, wedi gosod Apache yno, wedi ffurfweddu popeth yn ddiofyn, wedi gosod cymhwysiad PHP, ac isod gallwch weld y canlyniad.
Yma aeth y llwyth i'r gwraidd a dim ond 10 RPS ydoedd. Arhoson ni 5 munud a chwalodd y gweinydd. Mae'n wir nad yw'n gwbl hysbys pam y syrthiodd, ond mae rhagdybiaeth ei fod yn syml â gormod o gof ac felly wedi rhoi'r gorau i ymateb.
Yn seiliedig ar donnau
Yn ystod y flwyddyn neu ddwy ddiwethaf, mae ymosodiadau tonnau wedi dod yn eithaf poblogaidd. Mae hyn oherwydd y ffaith bod llawer o sefydliadau'n prynu darnau penodol o galedwedd ar gyfer amddiffyniad DDoS, sy'n gofyn am gyfnod penodol o amser i gronni ystadegau i ddechrau hidlo'r ymosodiad. Hynny yw, nid ydynt yn hidlo'r ymosodiad yn y 30-40 eiliad cyntaf, oherwydd eu bod yn cronni data ac yn dysgu. Yn unol â hynny, yn yr eiliadau 30-40 hyn gallwch chi lansio cymaint ar y wefan y bydd yr adnodd yn gorwedd am amser hir nes bod pob cais wedi'i glirio.
Yn achos yr ymosodiad isod, roedd egwyl o 10 munud, ac ar ôl hynny cyrhaeddodd rhan newydd, addasedig o'r ymosodiad.
Hynny yw, dysgodd yr amddiffyniad, dechreuodd hidlo, ond cyrhaeddodd rhan newydd, hollol wahanol o'r ymosodiad, a dechreuodd yr amddiffyniad ddysgu eto. Mewn gwirionedd, mae hidlo'n stopio gweithio, mae amddiffyniad yn dod yn aneffeithiol, ac nid yw'r safle ar gael.
Nodweddir ymosodiadau tonnau gan werthoedd uchel iawn ar y brig, gall gyrraedd can mil neu filiwn o geisiadau yr eiliad, yn achos L7. Os byddwn yn siarad am L3 a 4, yna gall fod cannoedd o gigabits o draffig, neu, yn unol â hynny, cannoedd o mpps, os ydych chi'n cyfrif mewn pecynnau.
Y broblem gydag ymosodiadau o'r fath yw cydamseru. Daw'r ymosodiadau o botnet ac mae angen lefel uchel o gydamseru i greu pigyn un-amser mawr iawn. Ac nid yw'r cydlyniad hwn bob amser yn gweithio allan: weithiau mae'r allbwn yn rhyw fath o uchafbwynt parabolig, sy'n edrych braidd yn druenus.
Nid HTTP yn unig
Yn ogystal â HTTP yn L7, rydym yn hoffi manteisio ar brotocolau eraill. Fel rheol, mae gan wefan reolaidd, yn enwedig gwesteiwr rheolaidd, brotocolau post a MySQL yn glynu. Mae protocolau post yn destun llai o lwyth na chronfeydd data, ond gallant hefyd gael eu llwytho'n eithaf effeithlon ac yn y pen draw bydd CPU wedi'i orlwytho ar y gweinydd.
Roeddem yn eithaf llwyddiannus gan ddefnyddio bregusrwydd SSH 2016. Nawr mae'r bregusrwydd hwn wedi'i osod ar gyfer bron pawb, ond nid yw hyn yn golygu na ellir cyflwyno llwyth i SSH. Gall. Yn syml, mae llwyth enfawr o awdurdodiadau, mae SSH yn bwyta bron y CPU cyfan ar y gweinydd, ac yna mae'r wefan yn cwympo o un neu ddau gais yr eiliad. Yn unol â hynny, ni ellir gwahaniaethu rhwng y cais hwn neu ddau yn seiliedig ar y logiau a llwyth cyfreithlon.
Mae llawer o gysylltiadau rydyn ni'n eu hagor mewn gweinyddwyr hefyd yn parhau i fod yn berthnasol. Yn flaenorol, roedd Apache yn euog o hyn, nawr mae nginx mewn gwirionedd yn dioddef o hyn, gan ei fod yn aml yn cael ei ffurfweddu yn ddiofyn. Mae nifer y cysylltiadau y gall nginx eu cadw ar agor yn gyfyngedig, felly rydym yn agor y nifer hon o gysylltiadau, nid yw nginx bellach yn derbyn cysylltiad newydd, ac o ganlyniad nid yw'r wefan yn gweithio.
Mae gan ein clwstwr prawf ddigon o CPU i ymosod ar ysgwyd llaw SSL. Mewn egwyddor, fel y dengys arfer, mae botnets weithiau'n hoffi gwneud hyn hefyd. Ar y naill law, mae'n amlwg na allwch wneud heb SSL, oherwydd canlyniadau Google, safle, diogelwch. Ar y llaw arall, yn anffodus mae gan SSL broblem CPU.
L3&4
Pan fyddwn yn siarad am ymosodiad ar y lefelau L3 a 4, rydym fel arfer yn sôn am ymosodiad ar y lefel gyswllt. Mae llwyth o'r fath bron bob amser yn wahaniaethadwy ac un cyfreithlon, oni bai ei fod yn ymosodiad llifogydd SYN. Y broblem gydag ymosodiadau llifogydd SYN ar gyfer offer diogelwch yw eu cyfaint mawr. Uchafswm gwerth L3&4 oedd 1,5-2 Tbit yr eiliad. Mae'r math hwn o draffig yn anodd iawn i'w brosesu hyd yn oed i gwmnïau mawr, gan gynnwys Oracle a Google.
Mae SYN a SYN-ACK yn becynnau a ddefnyddir wrth sefydlu cysylltiad. Felly, mae'n anodd gwahaniaethu rhwng SYN-llifogydd a llwyth cyfreithlon: nid yw'n glir a yw hwn yn SYN a ddaeth i sefydlu cysylltiad, neu'n rhan o lifogydd.
CDU-llifogydd
Yn nodweddiadol, nid oes gan ymosodwyr y galluoedd sydd gennym, felly gellir defnyddio ymhelaethu i drefnu ymosodiadau. Hynny yw, mae'r ymosodwr yn sganio'r Rhyngrwyd ac yn canfod gweinyddwyr bregus neu wedi'u ffurfweddu'n anghywir sydd, er enghraifft, mewn ymateb i un pecyn SYN, yn ymateb gyda thri SYN-ACKs. Trwy ffugio'r cyfeiriad ffynhonnell o gyfeiriad y gweinydd targed, mae'n bosibl cynyddu'r pŵer trwy, dyweder, dair gwaith gydag un pecyn ac ailgyfeirio traffig i'r dioddefwr.
Y broblem gydag ymhelaethiadau yw eu bod yn anodd eu canfod. Mae enghreifftiau diweddar yn cynnwys achos syfrdanol y memcached bregus. Hefyd, nawr mae yna lawer o ddyfeisiau IoT, camerâu IP, sydd hefyd wedi'u ffurfweddu'n ddiofyn yn bennaf, ac yn ddiofyn maent wedi'u ffurfweddu'n anghywir, a dyna pam mae ymosodwyr yn aml yn ymosod trwy ddyfeisiau o'r fath.
Anodd SYN-llifogydd
Mae'n debyg mai SYN-flood yw'r math mwyaf diddorol o ymosodiad o safbwynt datblygwr. Y broblem yw bod gweinyddwyr system yn aml yn defnyddio blocio IP i'w hamddiffyn. Ar ben hynny, mae blocio IP yn effeithio nid yn unig ar weinyddwyr system sy'n gweithredu gan ddefnyddio sgriptiau, ond hefyd, yn anffodus, rhai systemau diogelwch sy'n cael eu prynu am lawer o arian.
Gall y dull hwn droi'n drychineb, oherwydd os bydd ymosodwyr yn disodli cyfeiriadau IP, bydd y cwmni'n rhwystro ei is-rwydwaith ei hun. Pan fydd y Firewall yn blocio ei glwstwr ei hun, bydd yr allbwn yn methu rhyngweithiadau allanol a bydd yr adnodd yn methu.
Ar ben hynny, nid yw'n anodd rhwystro'ch rhwydwaith eich hun. Os oes gan swyddfa'r cleient rwydwaith Wi-Fi, neu os yw perfformiad adnoddau yn cael ei fesur gan ddefnyddio systemau monitro amrywiol, yna rydym yn cymryd cyfeiriad IP y system fonitro hon neu Wi-Fi swyddfa'r cleient ac yn ei ddefnyddio fel ffynhonnell. Ar y diwedd, mae'n ymddangos bod yr adnodd ar gael, ond mae'r cyfeiriadau IP targed wedi'u rhwystro. Felly, efallai y bydd rhwydwaith Wi-Fi cynhadledd HighLoad, lle mae cynnyrch newydd y cwmni yn cael ei gyflwyno, yn cael ei rwystro, ac mae hyn yn golygu rhai costau busnes ac economaidd.
Yn ystod y profion, ni allwn ddefnyddio ymhelaethu trwy memcached gydag unrhyw adnoddau allanol, oherwydd mae cytundebau i anfon traffig i gyfeiriadau IP a ganiateir yn unig. Yn unol â hynny, rydym yn defnyddio ymhelaethu trwy SYN a SYN-ACK, pan fydd y system yn ymateb i anfon un SYN gyda dau neu dri SYN-ACK, ac ar yr allbwn mae'r ymosodiad yn cael ei luosi dwy neu dair gwaith.
Offer
Un o'r prif offer rydyn ni'n ei ddefnyddio ar gyfer llwyth gwaith L7 yw Yandex-tank. Yn benodol, defnyddir rhith fel gwn, ac mae yna sawl sgript ar gyfer cynhyrchu cetris ac ar gyfer dadansoddi'r canlyniadau.
Defnyddir Tcpdump i ddadansoddi traffig rhwydwaith, a defnyddir Nmap i ddadansoddi'r gweinydd. I greu'r llwyth ar lefel L3&4, defnyddir OpenSSL ac ychydig o'n hud ein hunain gyda'r llyfrgell DPDK. Mae DPDK yn llyfrgell gan Intel sy'n eich galluogi i weithio gyda'r rhyngwyneb rhwydwaith gan osgoi'r pentwr Linux, a thrwy hynny gynyddu effeithlonrwydd. Yn naturiol, rydym yn defnyddio DPDK nid yn unig ar lefel L3 a 4, ond hefyd ar lefel L7, oherwydd ei fod yn caniatáu inni greu llif llwyth uchel iawn, o fewn yr ystod o sawl miliwn o geisiadau yr eiliad o un peiriant.
Rydym hefyd yn defnyddio rhai generaduron traffig ac offer arbennig yr ydym yn eu hysgrifennu ar gyfer profion penodol. Os ydym yn cofio'r bregusrwydd o dan SSH, yna ni ellir manteisio ar y set uchod. Os byddwn yn ymosod ar y protocol post, rydym yn cymryd cyfleustodau post neu'n ysgrifennu sgriptiau arnynt.
Canfyddiadau
Fel casgliad hoffwn ddweud:
- Yn ogystal â phrofi llwyth clasurol, mae angen cynnal profion straen. Mae gennym enghraifft go iawn lle roedd is-gontractwr partner yn perfformio profion llwyth yn unig. Dangosodd y gall yr adnodd wrthsefyll y llwyth arferol. Ond yna ymddangosodd llwyth annormal, dechreuodd ymwelwyr safle ddefnyddio'r adnodd ychydig yn wahanol, ac o ganlyniad gorweddodd yr is-gontractwr i lawr. Felly, mae'n werth chwilio am wendidau hyd yn oed os ydych eisoes wedi'ch diogelu rhag ymosodiadau DDoS.
- Mae angen ynysu rhai rhannau o'r system oddi wrth eraill. Os oes gennych chwiliad, mae angen i chi ei symud i beiriannau ar wahân, hynny yw, nid hyd yn oed i Docker. Oherwydd os bydd chwiliad neu awdurdodiad yn methu, o leiaf bydd rhywbeth yn parhau i weithio. Yn achos siop ar-lein, bydd defnyddwyr yn parhau i ddod o hyd i gynhyrchion yn y catalog, mynd o'r cydgrynwr, prynu os ydynt eisoes wedi'u hawdurdodi, neu eu hawdurdodi trwy OAuth2.
- Peidiwch ag esgeuluso pob math o wasanaethau cwmwl.
- Defnyddiwch CDN nid yn unig i wneud y gorau o oedi rhwydwaith, ond hefyd fel ffordd o amddiffyn rhag ymosodiadau ar orludded sianel a llifogydd yn unig i draffig sefydlog.
- Mae angen defnyddio gwasanaethau amddiffyn arbenigol. Ni allwch amddiffyn eich hun rhag ymosodiadau L3 a 4 ar lefel y sianel, oherwydd mae'n debyg nad oes gennych sianel ddigonol. Rydych hefyd yn annhebygol o frwydro yn erbyn ymosodiadau L7, oherwydd gallant fod yn fawr iawn. Hefyd, mae chwilio am ymosodiadau bach yn dal i fod yn uchelfraint gwasanaethau arbennig, algorithmau arbennig.
- Diweddaru'n rheolaidd. Mae hyn yn berthnasol nid yn unig i'r cnewyllyn, ond hefyd i'r daemon SSH, yn enwedig os oes gennych chi nhw ar agor i'r tu allan. Mewn egwyddor, mae angen diweddaru popeth, oherwydd mae'n annhebygol y byddwch yn gallu olrhain gwendidau penodol ar eich pen eich hun.
Ffynhonnell: hab.com