Saluton! Bonvenon al la sesa leciono de la kurso . On ni regis la bazojn pri laboro kun NAT-teknologio , kaj ankaŭ liberigis nian testan uzanton sur la Interreton. Nun estas tempo prizorgi la sekurecon de la uzanto en liaj liberaj spacoj. En ĉi tiu leciono ni rigardos la sekvajn sekurecajn profilojn: Reteja Filtrado, Aplika Kontrolo kaj HTTPS-inspektado.
Por komenci kun sekurecaj profiloj, ni devas kompreni ankoraŭ unu aferon: inspektaj reĝimoj.
La defaŭlta estas Fluobazita reĝimo. Ĝi kontrolas dosierojn kiam ili pasas tra la FortiGate sen bufro. Post kiam la pakaĵo alvenas, ĝi estas procesita kaj plusendita, sen atendi ke la tuta dosiero aŭ retpaĝo estos ricevita. Ĝi postulas malpli da rimedoj kaj provizas pli bonan rendimenton ol Prokura reĝimo, sed samtempe ne ĉiuj Sekurecaj funkcioj disponeblas en ĝi. Ekzemple, Data Leak Prevention (DLP) nur povas esti uzata en Prokura reĝimo.
Prokura reĝimo funkcias alimaniere. Ĝi kreas du TCP-ligojn, unu inter la kliento kaj FortiGate, la dua inter FortiGate kaj la servilo. Ĉi tio permesas al ĝi bufrigi trafikon, t.e. ricevi kompletan dosieron aŭ retpaĝon. Skanado de dosieroj por diversaj minacoj komenciĝas nur post kiam la tuta dosiero estas bufro. Ĉi tio ebligas al vi uzi kromajn funkciojn, kiuj ne estas disponeblaj en Fluo-bazita reĝimo. Kiel vi povas vidi, ĉi tiu reĝimo ŝajnas esti la malo de Fluo Bazita - sekureco ludas gravan rolon ĉi tie, kaj rendimento prenas malantaŭan lokon.
Homoj ofte demandas: kiu reĝimo estas pli bona? Sed ĉi tie ne ekzistas ĝenerala recepto. Ĉio estas ĉiam individua kaj dependas de viaj bezonoj kaj celoj. Poste en la kurso mi provos montri la diferencojn inter sekurecprofiloj en Flua kaj Prokura reĝimoj. Ĉi tio helpos vin kompari la funkciojn kaj decidi kiu estas plej bona por vi.
Ni iru rekte al sekurecaj profiloj kaj unue rigardu Retejan Filtrilon. Ĝi helpas kontroli aŭ spuri, kiujn retejojn vizitas uzantoj. Mi pensas, ke ne necesas pliprofundiĝi por klarigi la bezonon de tia profilo en la nunaj realaĵoj. Ni pli bone komprenu kiel ĝi funkcias.
Post kiam TCP-konekto estas establita, la uzanto uzas GET-peton por peti la enhavon de specifa retejo.
Se la retservilo respondas pozitive, ĝi sendas informojn pri la retejo reen. Jen kie la TTT-filtrilo venas en ludon. Ĝi kontrolas la enhavon de ĉi tiu respondo.Dum kontrolado, FortiGate sendas realtempan peton al la FortiGuard Distribution Network (FDN) por determini la kategorion de la donita retejo. Post determini la kategorion de aparta retejo, la retfiltrilo, depende de la agordoj, faras specifan agon.
Estas tri agoj haveblaj en Flua reĝimo:
- Permesi - permesi aliron al la retejo
- Bloki - bloki aliron al la retejo
- Monitoro - permesu aliron al la retejo kaj registri ĝin en la protokoloj
En Prokura reĝimo, du pliaj agoj estas aldonitaj:
- Averto - donu al la uzanto averton, ke li provas viziti certan rimedon kaj donu al la uzanto elekton - daŭrigu aŭ forlasu la retejon
- Aŭtentikigi - Petu uzantajn akreditaĵojn - ĉi tio permesas al iuj grupoj aliri limigitajn kategoriojn de retejoj.
En la retejo vi povas vidi ĉiujn kategoriojn kaj subkategoriojn de la retfiltrilo, kaj ankaŭ ekscii al kiu kategorio apartenas aparta retejo. Kaj ĝenerale, ĉi tio estas sufiĉe utila retejo por uzantoj de Fortinet-solvoj, mi konsilas vin pli bone koni ĝin en via libera tempo.
Estas tre malmulte, kion oni povas diri pri Aplika Kontrolo. Kiel la nomo sugestas, ĝi permesas vin kontroli la funkciadon de aplikaĵoj. Kaj li faras tion uzante ŝablonojn de diversaj aplikoj, tiel nomataj subskriboj. Uzante ĉi tiujn subskribojn, li povas identigi specifan aplikon kaj apliki specifan agon al ĝi:
- Permesi - permesi
- Monitoro - permesu kaj ensalutu ĉi tion
- Bloki - malpermesi
- Kvaranteno - registri eventon en la protokoloj kaj bloku la IP-adreson dum certa tempo
Vi ankaŭ povas vidi ekzistantajn subskribojn en la retejo .
Nun ni rigardu la HTTPS-inspektan mekanismon. Laŭ statistiko fine de 2018, la parto de HTTPS-trafiko superis 70%. Tio estas, sen uzi HTTPS-inspektadon, ni povos analizi nur ĉirkaŭ 30% de la trafiko tra la reto. Unue, ni rigardu kiel HTTPS funkcias en malglata aproksimado.
La kliento iniciatas TLS-peton al la retservilo kaj ricevas TLS-respondon, kaj ankaŭ vidas ciferecan atestilon, kiu devas esti fidinda por ĉi tiu uzanto. Ĉi tio estas la nura minimumo, kiun ni bezonas scii pri kiel funkcias HTTPS; fakte, la maniero kiel ĝi funkcias estas multe pli komplika. Post sukcesa TLS-manpremo komenciĝas ĉifrita datumtransigo. Kaj ĉi tio estas bona. Neniu povas aliri la datumojn, kiujn vi interŝanĝas kun la retservilo.
Tamen, por firmaaj sekurecaj oficistoj ĉi tio estas vera kapdoloro, ĉar ili ne povas vidi ĉi tiun trafikon kaj kontroli ĝian enhavon aŭ per antiviruso, aŭ per entrudiĝa preventa sistemo, aŭ DLP-sistemoj, aŭ io ajn. Ĉi tio ankaŭ negative influas la kvaliton de la difino de aplikaĵoj kaj retaj rimedoj uzataj en la reto - ĝuste kio rilatas al nia leciona temo. HTTPS-inspekta teknologio estas desegnita por solvi ĉi tiun problemon. Ĝia esenco estas tre simpla - fakte aparato, kiu faras HTTPS-inspektadon, organizas atakon de Man In The Middle. Ĝi aspektas kiel ĉi tio: FortiGate kaptas la peton de la uzanto, organizas HTTPS-konekton kun ĝi, kaj poste malfermas HTTPS-sesion kun la rimedo, kiun la uzanto aliris. En ĉi tiu kazo, la atestilo eldonita de FortiGate estos videbla sur la komputilo de la uzanto. Ĝi devas esti fidinda por la retumilo por permesi la konekton.
Fakte, HTTPS-inspektado estas sufiĉe komplika afero kaj havas multajn limigojn, sed ni ne konsideros ĉi tion en ĉi tiu kurso. Mi nur aldonos, ke efektivigo de HTTPS-inspektado ne estas demando de minutoj; ĝi kutime daŭras proksimume monaton. Necesas kolekti informojn pri la necesaj esceptoj, fari la taŭgajn agordojn, kolekti komentojn de uzantoj kaj ĝustigi la agordojn.
La donita teorio, same kiel la praktika parto, estas prezentitaj en ĉi tiu videoleciono:
En la sekva leciono ni rigardos aliajn sekurecajn profilojn: antivirusa kaj entrudiĝa preventa sistemo. Por ne maltrafi ĝin, sekvu la ĝisdatigojn ĉe la sekvaj kanaloj:
fonto: www.habr.com