Yr erthygl hon yw'r bedwaredd yn y gyfres “Sut i Reoli Eich Seilwaith Rhwydwaith.” Gellir dod o hyd i gynnwys pob erthygl yn y gyfres a dolenni yma.

В y rhan gyntaf Yn y bennod hon, edrychwyd ar rai agweddau ar ddiogelwch rhwydwaith yn y segment Canolfan Ddata. Bydd y rhan hon yn cael ei neilltuo i'r segment “Mynediad Rhyngrwyd”.

Mynediad i'r rhyngrwyd

Heb os, pwnc diogelwch yw un o'r pynciau mwyaf cymhleth ym myd rhwydweithiau data. Fel mewn achosion blaenorol, heb honni dyfnder a chyflawnrwydd, byddaf yn ystyried yma gwestiynau eithaf syml, ond, yn fy marn i, cwestiynau pwysig, yr wyf yn gobeithio y bydd yr atebion iddynt yn helpu i godi lefel diogelwch eich rhwydwaith.

Wrth archwilio'r segment hwn, rhowch sylw i'r agweddau canlynol:

• dylunio
• Gosodiadau BGP
• Amddiffyniad DOS/DDOS
• hidlo traffig ar y wal dân

Dylunio

Fel enghraifft o ddyluniad y segment hwn ar gyfer rhwydwaith menter, byddwn yn argymell arweinyddiaeth o Cisco o fewn Modelau DIOGEL.

Wrth gwrs, efallai y bydd datrysiad gwerthwyr eraill yn ymddangos yn fwy deniadol i chi (gweler. Cwadrant Gartner 2018), ond heb eich annog i ddilyn y dyluniad hwn yn fanwl, rwy'n dal i'w chael yn ddefnyddiol deall yr egwyddorion a'r syniadau y tu ôl iddo.

Nodyn:

Yn SAFE, mae'r segment "Mynediad o Bell" yn rhan o'r segment "Mynediad Rhyngrwyd". Ond yn y gyfres hon o erthyglau byddwn yn ei ystyried ar wahân.

Y set safonol o offer yn y segment hwn ar gyfer rhwydwaith menter yw

• llwybryddion ffin
• waliau tân

Marc 1

Yn y gyfres hon o erthyglau, pan fyddaf yn siarad am waliau tân, yr wyf yn ei olygu NGFW.

Marc 2

Rwy'n hepgor ystyried gwahanol fathau o atebion L2/L1 neu droshaenu L2 dros atebion L3 sy'n angenrheidiol i sicrhau cysylltedd L1/L2 ac yn cyfyngu fy hun i faterion ar lefel L3 ac uwch yn unig. Yn rhannol, trafodwyd materion L1/L2 yn y bennod “Glanhau a Dogfennaeth".

Os nad ydych wedi dod o hyd i wal dân yn y gylchran hon, yna ni ddylech ruthro i gasgliadau.

Gadewch i ni wneud yr un peth ag yn rhan flaenorolGadewch i ni ddechrau gyda'r cwestiwn: a oes angen defnyddio wal dân yn y segment hwn yn eich achos chi?

Gallaf ddweud ei bod yn ymddangos mai dyma'r lle mwyaf cyfiawn i ddefnyddio waliau tân ac i gymhwyso algorithmau hidlo traffig cymhleth. YN rhan 1 Soniasom am 4 ffactor a allai ymyrryd â'r defnydd o waliau tân yn segment y ganolfan ddata. Ond yma nid ydynt mor arwyddocaol bellach.

Enghraifft 1. Oedi

Cyn belled ag y mae'r Rhyngrwyd yn y cwestiwn, nid oes diben siarad am oedi o hyd yn oed tua 1 milieiliad. Felly, ni all yr oedi yn y segment hwn fod yn ffactor sy'n cyfyngu ar y defnydd o'r wal dân.

Enghraifft 2. Cynhyrchiant

Mewn rhai achosion gall y ffactor hwn fod yn arwyddocaol o hyd. Felly, efallai y bydd yn rhaid i chi ganiatáu rhywfaint o draffig (er enghraifft, traffig o gydbwyswyr llwythi) i osgoi'r wal dân.

Enghraifft 3. Dibynadwyedd

Mae angen ystyried y ffactor hwn o hyd, ond yn dal i fod, o ystyried annibynadwyedd y Rhyngrwyd ei hun, nid yw ei bwysigrwydd i'r segment hwn mor arwyddocaol ag ar gyfer y ganolfan ddata.

Felly, gadewch i ni dybio bod eich gwasanaeth yn byw ar ben http/https (gyda sesiynau byr). Yn yr achos hwn, gallwch ddefnyddio dau flwch annibynnol (heb HA) ac os oes problem llwybro gydag un ohonynt, trosglwyddwch yr holl draffig i'r ail.

Neu gallwch ddefnyddio waliau tân mewn modd tryloyw ac, os byddant yn methu, caniatáu i draffig osgoi'r wal dân wrth ddatrys y broblem.

Felly, yn fwyaf tebygol yn unig pris efallai mai dyma'r ffactor a fydd yn eich gorfodi i roi'r gorau i ddefnyddio waliau tân yn y gylchran hon.

Pwysig!

Mae yna demtasiwn i gyfuno'r wal dân hon â wal dân y ganolfan ddata (defnyddiwch un wal dân ar gyfer y segmentau hyn). Mae'r ateb, mewn egwyddor, yn bosibl, ond mae angen ichi ddeall hynny oherwydd Mae wal dân Mynediad Rhyngrwyd mewn gwirionedd ar flaen eich amddiffyniad ac yn “cymryd ymlaen” o leiaf rhywfaint o'r traffig maleisus, yna, wrth gwrs, mae angen i chi ystyried y risg gynyddol y bydd y wal dân hon yn anabl. Hynny yw, trwy ddefnyddio'r un dyfeisiau yn y ddau segment hyn, byddwch yn lleihau argaeledd segment eich canolfan ddata yn sylweddol.

Fel bob amser, mae angen i chi ddeall, yn dibynnu ar y gwasanaeth y mae'r cwmni'n ei ddarparu, y gall dyluniad y segment hwn amrywio'n fawr. Fel bob amser, gallwch ddewis gwahanol ddulliau yn dibynnu ar eich gofynion.

Enghraifft

Os ydych yn ddarparwr cynnwys, gyda rhwydwaith CDN (gweler, er enghraifft, gyfres o erthyglau), yna efallai na fyddwch am greu seilwaith ar draws dwsinau neu hyd yn oed gannoedd o bwyntiau presenoldeb gan ddefnyddio dyfeisiau ar wahân ar gyfer llwybro a hidlo traffig. Bydd yn ddrud, a gall fod yn ddiangen.

Ar gyfer BGP nid oes rhaid i chi gael llwybryddion pwrpasol o reidrwydd, gallwch ddefnyddio offer ffynhonnell agored fel Cwagga. Felly efallai mai'r cyfan sydd ei angen arnoch chi yw gweinydd neu sawl gweinydd, switsh a BGP.

Yn yr achos hwn, gall eich gweinydd neu sawl gweinydd chwarae rôl nid yn unig gweinydd CDN, ond hefyd llwybrydd. Wrth gwrs, mae yna lawer o fanylion o hyd (fel sut i sicrhau cydbwysedd), ond mae'n ymarferol, ac mae'n ddull rydyn ni wedi'i ddefnyddio'n llwyddiannus ar gyfer un o'n partneriaid.

Gallwch gael sawl canolfan ddata gyda diogelwch llawn (waliau tân, gwasanaethau amddiffyn DDOS a ddarperir gan eich darparwyr Rhyngrwyd) a dwsinau neu gannoedd o bwyntiau presenoldeb “syml” gyda dim ond switshis L2 a gweinyddwyr.

Ond beth am yr amddiffyniad yn yr achos hwn?

Gadewch i ni edrych ar, er enghraifft, y poblogaidd yn ddiweddar Ymosodiad DDOS Ymhelaethiad DNS. Mae ei berygl yn gorwedd yn y ffaith bod llawer iawn o draffig yn cael ei gynhyrchu, sy'n “clocsio” 100% o'ch holl ddolenni i fyny.

Beth sydd gennym yn achos ein dyluniad.

• os ydych chi'n defnyddio AnyCast, yna mae'r traffig yn cael ei ddosbarthu rhwng eich pwyntiau presenoldeb. Os mai terabits yw cyfanswm eich lled band, yna mae hyn ynddo'i hun mewn gwirionedd (fodd bynnag, yn ddiweddar bu sawl ymosodiad gyda thraffig maleisus ar drefn terabits) yn eich amddiffyn rhag dolenni i fyny “gorlifo”.
• Fodd bynnag, os bydd rhai dolenni cyswllt yn mynd yn rhwystredig, yna rydych chi'n tynnu'r wefan hon o'r gwasanaeth (rhowch y gorau i hysbysebu'r rhagddodiad)
• gallwch hefyd gynyddu'r gyfran o draffig a anfonir o'ch canolfannau data “llawn” (ac, yn unol â hynny, wedi'u diogelu), gan ddileu rhan sylweddol o draffig maleisus o fannau presenoldeb heb eu diogelu.

Ac un nodyn bach arall i'r enghraifft hon. Os byddwch chi'n anfon digon o draffig trwy IXs, yna mae hyn hefyd yn lleihau eich bregusrwydd i ymosodiadau o'r fath

Ffurfweddu BGP

Mae dau bwnc yma.

• Cysylltedd
• Ffurfweddu BGP

Rydym eisoes wedi siarad ychydig am gysylltedd yn rhan 1. Y pwynt yw sicrhau bod traffig i'ch cwsmeriaid yn dilyn y llwybr gorau posibl. Er nad yw optimaidd bob amser yn ymwneud â hwyrni, hwyrni isel fel arfer yw'r prif ddangosydd o optimaidd. I rai cwmnïau mae hyn yn bwysicach, i eraill mae'n llai. Mae'r cyfan yn dibynnu ar y gwasanaeth a ddarperir gennych.

Enghraifft 1

Os ydych chi'n gyfnewidfa, a bod cyfnodau amser o lai na milieiliadau yn bwysig i'ch cleientiaid, yna, wrth gwrs, ni ellir siarad am unrhyw fath o Rhyngrwyd o gwbl.

Enghraifft 2

Os ydych chi'n gwmni hapchwarae a bod degau o filieiliadau yn bwysig i chi, yna, wrth gwrs, mae cysylltedd yn bwysig iawn i chi.

Enghraifft 3

Mae angen i chi ddeall hefyd, oherwydd priodweddau'r protocol TCP, bod y gyfradd trosglwyddo data o fewn un sesiwn TCP hefyd yn dibynnu ar RTT (Amser Taith Gron). Mae rhwydweithiau CDN hefyd yn cael eu hadeiladu i ddatrys y broblem hon trwy symud gweinyddwyr dosbarthu cynnwys yn agosach at ddefnyddiwr y cynnwys hwn.

Mae astudio cysylltedd yn bwnc diddorol ynddo'i hun, sy'n deilwng o'i erthygl neu gyfres o erthyglau ei hun, ac mae angen dealltwriaeth dda o sut mae'r Rhyngrwyd "yn gweithio."

Adnoddau defnyddiol:

aeddfed.net
bgp.he.net

Enghraifft

Rhoddaf un enghraifft fach yn unig.

Gadewch i ni dybio bod eich canolfan ddata wedi'i lleoli ym Moscow, a bod gennych chi un ddolen gyswllt - Rostelecom (AS12389). Yn yr achos hwn (cartref sengl) nid oes angen BGP arnoch, ac rydych yn fwyaf tebygol o ddefnyddio'r gronfa gyfeiriadau o Rostelecom fel cyfeiriadau cyhoeddus.

Gadewch i ni dybio eich bod yn darparu gwasanaeth penodol, ac mae gennych nifer digonol o gleientiaid o Wcráin, ac maent yn cwyno am oedi hir. Yn ystod eich ymchwil, fe wnaethoch chi ddarganfod bod cyfeiriadau IP rhai ohonyn nhw yn y grid 37.52.0.0/21.

Trwy redeg traceroute, gwelsoch fod y traffig yn mynd trwy AS1299 (Telia), a thrwy redeg ping, cawsoch RTT ar gyfartaledd o 70 - 80 milieiliad. Gallwch hefyd weld hwn yn gwydr edrych Rostelecom.

Gan ddefnyddio'r cyfleustodau whois (ar ripe.net neu gyfleustodau lleol), gallwch chi benderfynu'n hawdd bod bloc 37.52.0.0/21 yn perthyn i AS6849 (Ukrtelecom).

Nesaf, trwy fynd i bgp.he.net rydych yn gweld nad oes gan AS6849 unrhyw berthynas ag AS12389 (nid ydynt yn gleientiaid nac yn uwchgysylltiadau â'i gilydd, ac nid ydynt yn sbecian). Ond os edrychwch chi ar rhestr o gyfoedion ar gyfer AS6849, fe welwch, er enghraifft, AS29226 (Mastertel) ac AS31133 (Megafon).

Unwaith y byddwch chi'n dod o hyd i wydr y darparwyr hyn, gallwch chi gymharu'r llwybr a'r RTT. Er enghraifft, ar gyfer Mastertel bydd RTT tua 30 milieiliad.

Felly, os yw'r gwahaniaeth rhwng 80 a 30 milieiliad yn arwyddocaol i'ch gwasanaeth, yna efallai bod angen i chi feddwl am gysylltedd, cael eich rhif AS, eich cronfa gyfeiriadau o RIPE a chysylltu dolenni cyswllt ychwanegol a / neu greu pwyntiau presenoldeb ar IXs.

Pan fyddwch chi'n defnyddio BGP, rydych chi nid yn unig yn cael y cyfle i wella cysylltedd, ond rydych chi hefyd yn cynnal eich cysylltiad Rhyngrwyd yn ddiangen.

Y ddogfen hon yn cynnwys argymhellion ar gyfer ffurfweddu BGP. Er gwaethaf y ffaith bod yr argymhellion hyn wedi’u datblygu yn seiliedig ar “arfer gorau” darparwyr, serch hynny (os nad yw eich gosodiadau BGP yn eithaf sylfaenol) maent yn ddi-os yn ddefnyddiol ac mewn gwirionedd dylent fod yn rhan o’r caledu a drafodwyd gennym yn y rhan gyntaf.

Amddiffyniad DOS/DDOS

Nawr mae ymosodiadau DOS / DDOS wedi dod yn realiti bob dydd i lawer o gwmnïau. Mewn gwirionedd, mae rhyw ffurf neu'i gilydd yn ymosod arnoch chi'n eithaf aml. Mae'r ffaith nad ydych wedi sylwi ar hyn ond yn golygu nad yw ymosodiad wedi'i dargedu wedi'i drefnu yn eich erbyn eto, a bod y mesurau amddiffyn a ddefnyddiwch, hyd yn oed efallai heb yn wybod iddo (amrywiol amddiffyniadau integredig systemau gweithredu), yn ddigonol i sicrhau bod diraddio'r gwasanaeth a ddarperir yn cael ei leihau i chi a'ch cleientiaid.

Mae yna adnoddau Rhyngrwyd sydd, yn seiliedig ar logiau offer, yn tynnu mapiau ymosod hardd mewn amser real.

Yma gallwch ddod o hyd i ddolenni iddynt.

Fy hoff map o CheckPoint.

Mae amddiffyniad rhag DDOS/DOS fel arfer yn haenog. I ddeall pam, mae angen i chi ddeall pa fathau o ymosodiadau DOS / DDOS sy'n bodoli (gweler, er enghraifft, yma neu yma)

Hynny yw, mae gennym dri math o ymosodiad:

• ymosodiadau cyfeintiol
• ymosodiadau protocol
• ymosodiadau cais

Os gallwch chi amddiffyn eich hun rhag y ddau fath olaf o ymosodiadau gan ddefnyddio, er enghraifft, waliau tân, yna ni allwch amddiffyn eich hun rhag ymosodiadau sydd wedi'u hanelu at “lethu” eich dolenni cyswllt (wrth gwrs, os nad yw cyfanswm eich gallu i sianeli Rhyngrwyd yn cael ei gyfrifo mewn terabits, neu well eto, mewn degau terabit).

Felly, amddiffyniad rhag ymosodiadau “cyfaintol” yw'r amddiffyniad cyntaf, a rhaid i'ch darparwr neu ddarparwyr ddarparu'r amddiffyniad hwn i chi. Os nad ydych chi wedi sylweddoli hyn eto, yna rydych chi'n ffodus am y tro.

Enghraifft

Gadewch i ni ddweud bod gennych chi sawl cyswllt uwch, ond dim ond un o'r darparwyr all roi'r amddiffyniad hwn i chi. Ond os yw'r holl draffig yn mynd trwy un darparwr, yna beth am y cysylltedd y buom yn ei drafod yn fyr ychydig yn gynharach?

Yn yr achos hwn, bydd yn rhaid i chi aberthu cysylltedd yn rhannol yn ystod yr ymosodiad. Ond

• dim ond am gyfnod yr ymosodiad y mae hyn. Os bydd ymosodiad, gallwch chi ad-drefnu BGP â llaw neu'n awtomatig fel bod traffig yn mynd trwy'r darparwr sy'n rhoi'r “ymbarél” i chi yn unig. Ar ôl i'r ymosodiad ddod i ben, gallwch ddychwelyd y llwybr i'w gyflwr blaenorol
• Nid oes angen trosglwyddo'r holl draffig. Os gwelwch, er enghraifft, nad oes unrhyw ymosodiadau trwy rai cysylltiadau neu sbecian (neu nad yw'r traffig yn arwyddocaol), gallwch barhau i hysbysebu rhagddodiaid gyda nodweddion cystadleuol tuag at y cymdogion BGP hyn.

Gallwch hefyd ddirprwyo amddiffyniad rhag “ymosodiadau protocol” ac “ymosodiadau cais” i'ch partneriaid.
Yma yma gallwch ddarllen astudiaeth dda (cyfieithu). Yn wir, mae'r erthygl yn ddwy flwydd oed, ond bydd yn rhoi syniad i chi o'r ymagweddau ar sut y gallwch chi amddiffyn eich hun rhag ymosodiadau DDOS.

Mewn egwyddor, gallwch gyfyngu'ch hun i hyn, gan allanoli'ch amddiffyniad yn llwyr. Mae manteision i'r penderfyniad hwn, ond mae anfantais amlwg hefyd. Y ffaith yw y gallwn siarad (eto, yn dibynnu ar yr hyn y mae eich cwmni yn ei wneud) am oroesiad y busnes. Ac ymddiried yn y fath bethau i drydydd partïon...

Felly, gadewch i ni edrych ar sut i drefnu'r ail a'r drydedd linell amddiffyn (yn ogystal ag amddiffyniad gan y darparwr).

Felly, yr ail linell amddiffyn yw hidlo a chyfyngwyr traffig (poliswyr) wrth fynedfa eich rhwydwaith.

Enghraifft 1

Gadewch i ni dybio eich bod wedi gorchuddio eich hun ag ymbarél yn erbyn DDOS gyda chymorth un o'r darparwyr. Gadewch i ni dybio bod y darparwr hwn yn defnyddio Arbor i hidlo traffig a hidlwyr ar ymyl ei rwydwaith.

Mae'r lled band y gall Arbor ei “brosesu” yn gyfyngedig, ac ni all y darparwr, wrth gwrs, basio traffig ei holl bartneriaid sy'n archebu'r gwasanaeth hwn trwy offer hidlo yn gyson. Felly, o dan amodau arferol, nid yw traffig yn cael ei hidlo.

Gadewch i ni dybio bod yna ymosodiad llifogydd SYN. Hyd yn oed os gwnaethoch archebu gwasanaeth sy'n newid traffig yn awtomatig i hidlo os bydd ymosodiad, nid yw hyn yn digwydd ar unwaith. Am funud neu fwy rydych chi'n parhau i fod dan ymosodiad. A gall hyn arwain at fethiant eich offer neu ddiraddio'r gwasanaeth. Yn yr achos hwn, bydd cyfyngu traffig ar y llwybr ymyl, er y bydd yn arwain at y ffaith na fydd rhai sesiynau TCP yn cael eu sefydlu yn ystod y cyfnod hwn, yn arbed eich seilwaith rhag problemau ar raddfa fwy.

Enghraifft 2

Mae’n bosibl y bydd nifer anarferol o fawr o becynnau SYN nid yn unig yn ganlyniad i ymosodiad llifogydd SYN. Gadewch i ni dybio eich bod yn darparu gwasanaeth lle gallwch ar yr un pryd gael tua 100 mil o gysylltiadau TCP (i un ganolfan ddata).

Gadewch i ni ddweud, o ganlyniad i broblem tymor byr gydag un o'ch prif ddarparwyr, bod hanner eich sesiynau'n cael eu cicio. Os yw'ch cais wedi'i ddylunio yn y fath fodd fel ei fod, heb feddwl ddwywaith, ar unwaith (neu ar ôl peth egwyl yr un peth ar gyfer pob sesiwn) yn ceisio ailsefydlu'r cysylltiad, yna byddwch yn derbyn o leiaf 50 mil o becynnau SYN. yr un pryd.

Er enghraifft, os oes rhaid i chi redeg ssl/tls ysgwyd llaw ar ben y sesiynau hyn, sy'n cynnwys cyfnewid tystysgrifau, yna o safbwynt disbyddu adnoddau ar gyfer eich cydbwysydd llwyth, bydd hwn yn “DDOS” llawer cryfach na syml llifogydd SYN. Mae'n ymddangos y dylai balanswyr ymdrin â digwyddiadau o'r fath, ond... yn anffodus, rydym yn wynebu problem o'r fath.

Ac, wrth gwrs, bydd plismon ar y llwybrydd ymyl yn arbed eich offer yn yr achos hwn hefyd.

Y drydedd lefel o amddiffyniad yn erbyn DDOS / DOS yw eich gosodiadau wal dân.

Yma gallwch chi atal y ddau ymosodiad o'r ail a'r trydydd math. Yn gyffredinol, gellir hidlo popeth sy'n cyrraedd y wal dân yma.

Tip

Ceisiwch roi cyn lleied o waith â phosibl i'r wal dân, gan hidlo cymaint â phosibl ar y ddwy linell amddiffyn gyntaf. A dyna pam.

A yw erioed wedi digwydd i chi, ar hap, wrth gynhyrchu traffig i wirio, er enghraifft, pa mor wrthwynebol yw system weithredu eich gweinyddion i ymosodiadau DDOS, eich bod wedi “lladd” eich wal dân, gan ei llwytho i 100 y cant, gyda thraffig ar ddwysedd arferol ? Os na, efallai ei fod yn syml oherwydd nad ydych wedi ceisio?

Yn gyffredinol, mae wal dân, fel y dywedais, yn beth cymhleth, ac mae'n gweithio'n dda gyda gwendidau hysbys ac atebion profedig, ond os anfonwch rywbeth anarferol, dim ond rhywfaint o sothach neu becynnau gyda phenawdau anghywir, yna rydych chi gyda rhai, nid Gyda tebygolrwydd mor fach (yn seiliedig ar fy mhrofiad), gallwch stupefy hyd yn oed o'r radd flaenaf offer. Felly, yng ngham 2, gan ddefnyddio ACLs rheolaidd (ar lefel L3/L4), dim ond traffig a ddylai ddod i mewn i'ch rhwydwaith y dylech ei ganiatáu.

Hidlo traffig ar y wal dân

Gadewch i ni barhau â'r sgwrs am y wal dân. Mae angen i chi ddeall mai dim ond un math o ymosodiad seiber yw ymosodiadau DOS/DDOS.

Yn ogystal ag amddiffyniad DOS / DDOS, gallwn hefyd gael rhywbeth fel y rhestr ganlynol o nodweddion:

• wal tân cais
• atal bygythiadau (antifeirws, gwrth-ysbïwedd, a bregusrwydd)
• Hidlo URL
• hidlo data (hidlo cynnwys)
• blocio ffeiliau (blocio mathau o ffeiliau)

Chi sydd i benderfynu beth sydd ei angen arnoch o'r rhestr hon.

I'w barhau

Ffynhonnell: hab.com