Legge til en brannmurregel / sikkerhetspolicy på ATP/USG FLEX/USG/ZyWall-Gateway

Viktig varsel:
Kjære kunde, vær oppmerksom på at vi bruker maskinoversettelse for å levere artikler på ditt lokale språk. Ikke all tekst kan oversettes nøyaktig. Hvis det er spørsmål eller uoverensstemmelser om nøyaktigheten av informasjonen i den oversatte versjonen, vennligst les den originale artikkelen her: Originalversjon

Firewall, eller "Security Policy" som vi kaller det i våre nyere generasjons enheter, er kjernen i enhetene våre. Denne opplæringen er ment å gi deg en grunnleggende forståelse av arbeidsmåtene til Firewall-enheten vår, og bør gjøre deg klar til å ta dine første skritt i å lage dine egne brannmurregler!

 

Grensesnitt, soner og sikkerhetspolicyer

Grensesnitt

Før vi dykker dypt inn i konfigurasjonen, må vi først kort snakke om hvordan vi strukturerer brannmurene våre – som vi for enkelhets skyld bare vil referere til som «USG» eller «ATP». Vår USG består av flere grensesnitt, fra WAN-porter til LAN-porter til alle andre virtuelle grensesnitt du lager på enheten.

Grensesnitt er i utgangspunktet uavhengige nettverkssegmenter på gatewayen og kan finnes innenfor menybanen

Configuration > Network > Interface

I dette eksemplet, et skjermbilde av standard Ethernet-grensesnitt på en ATP200:

mceclip0.png

 

Soner

Nå som vi forstår selve kjernekonseptet til grensesnittene, la oss gå over til soner, da spesielt sonene vil bli viktige for våre brannmurregler / sikkerhetspolicyer. I de fleste tilfeller vil en USG eller ATP også bestå av flere LAN, flere VLAN og/eller flere WAN. Når det gjelder brannmurregler, kan det hende du har en gruppe grensesnitt som du vil ha de samme reglene som gjelder - mest sannsynlig vil du ha alle LAN-grupper med samme rettigheter i hele nettverket, eller du vil at flere WAN-porter skal behandles det samme. I dette tilfellet er sonene en perfekt beholder for grensesnitt. I tilfelle du lurer på hva som menes med denne uttalelsen - dette bør forhåpentligvis bli klart veldig snart.

I Sone-menyen via

Configuration > Object > Zone

du kan finne de forskjellige standardsonene og grensesnitttilordningene mot disse sonene:

mceclip1.png

På samme måte som du har flere såkalte "objekter" i sonen, kan du også lage flere adresseobjekter, tjenesteobjekter og mange flere forskjellige typer objekter.

 

Objekter

Siden denne veiledningen er ment å gi et bilde av å lage brannmurregler / sikkerhetspolicyer, la oss holde dette kapittelet kort: USG / ATP-serien fungerer med såkalte objekter. Objekter er, som navnet sier, objekter i en database, f.eks. adresseobjekter, tjenesteobjekter (porter og protokoller), blant mange andre objekter. Disse objektene i seg selv har ingen funksjon og er bare en database. Den virkelige magien skjer når vi plasserer disse objektene innenfor policyer, for eksempel sikkerhetspolicyen (brannmurregelen).

Bare som et eksempel, her et skjermbilde av tjenesteobjektlisten, som finnes via

Configuration > Object > Service

mceclip2.png

Som du kanskje ser, er det mange gjenstander som allerede er klargjort for direkte bruk innenfor retningslinjene.

 

Sikkerhetspolicyer / Firewall regler

Nå, som vi har gått gjennom forutsetningene for å forstå grensesnitt, soner og objekter, kan vi nå gå over til å faktisk lage brannmurregler. Menyen for dette finner du via

Configuration > Security Policy > Policy Control

og det ser slik ut:

mceclip3.png

De aller fleste Firewall-regler som du normalt vil integrere i nettverket ditt er allerede forhåndskonfigurert som standard, for eksempel er full tilgang fra utsiden (WAN) til innsiden (LAN) av nettverket ditt selvfølgelig blokkert for å motvirke ondsinnede angrep fra internettet. Også, for eksempel, er din LAN til WAN-tilgang på den annen side ubegrenset, fordi det er en brukerpreferanse hvis du vil blokkere noen porter for LAN-klientene dine.

Vi ser nå forskjellige kolonner i policyreglene:

  • Prioritet: Rekkefølgen av Firewall-regelen - brannmurregler kjøres fra topp til bunn, i den spesifikke rekkefølgen
  • Status: viser om regelen er aktiv - gul er på, grå er av
  • Navn: Navn på brannmurregelen
  • Fra: Refererer til sonen som trafikken kommer fra
  • Til: Refererer til sonen som trafikken vil flyte til
  • IPv4-kilde: Refererer til et adresseobjekt, gjør det lettere å finjustere brannmurregler til spesifikke IPv4-kilder
  • IPv4-destinasjon: Refererer til et adresseobjekt, gjør det enklere å finjustere brannmurregler til spesifikke IPv4-destinasjoner
  • Tjeneste: Refererer til et tjenesteobjekt, gjør det mulig å lage en regel som kun gjelder for en enkelt port/protokoll eller en gruppe med porter/protokoller
  • Bruker: Tillater finjustering av brannmurregelen til kun å gjelde for brukerobjekter/brukergrupper
  • Tidsplan: Dette gjør det mulig å sette opp brannmuren til å bare bli aktiv i løpet av en bestemt tidsplan (nyttig for foreldrekontroll, skoleapplikasjoner osv.)
  • Handling: Definerer om trafikken som samsvarer med alle ovennevnte parametere får passere eller nektes
  • Logg: Her kan du angi om du vil ha en loggoppføring i tilfelle samsvarende trafikk flyter gjennom brannmuren
  • Profil: I dette segmentet kan du legge til UTM-tjenester og deres respektive profiler (for eksempel innholdsfilterprofiler osv.)

Nå, som vi har oppdaget de forskjellige tingene man kan sette opp innenfor policykontroll, la oss bare lage et eksempel for en konfigurasjon:

Mål: Vi ønsker å blokkere LAN1 til LAN2, men alt annet som både LAN1 og LAN2 når ut skal ikke blokkeres.

Som standard har LAN1 og LAN2 rett og slett tilgang til hva som helst: Fra LAN1 (eller LAN2, for den saks skyld) Til hvilken som helst (unntatt ZyWall ) lar begge LAN-nettverkene få tilgang til hverandre. For å ikke tillate dette, kan vi ganske enkelt "kutte av" godtgjørelsen via en brannmurregel satt til toppen, og ikke tillate en bestemt retning. I vårt eksempel vil vi ikke tillate LAN2 til LAN1. Siden kommunikasjon er en toveis gate, bør dette også avbryte ethvert forsøk på å få tilgang fra LAN1 til LAN2:

mceclip0.png

Vi setter handlingen til å nekte. Denne handlingen vil bare slippe pakken, annet enn avvisningsalternativet , vil sende tilbake informasjon til tilgangsenheten om hvorfor den ikke har tilgang til nettverket. Informasjonen basert på avvisningshandlingen kan enkelt brukes til å avskjære og hacke enheten, så det anbefales ikke i de fleste tilfeller.

Vi setter også "logg nektet trafikk" som loggvarsel , dette vil vise oss med røde bokstaver en oppføring i loggen når noen prøver å fortsatt få tilgang til nettverket.

Etter å ha satt opp denne regelen, bør du kunne se loggoppføringer så snart noen prøver å gå inn i henhold til brannmurregelen din.

Her er et eksempel på hvordan disse loggene kan se ut (en annen regel enn vår LAN1 --> LAN2-regel vi opprettet ovenfor, bare for demonstrasjonsformål:

Monitor > Log


mceclip1.png

 

Disse instruksjonene for første trinn skal gjøre det enkelt for deg å lage dine første brannmurregler på sikkerhetsgateway-enhetene dine!

Artikler i denne seksjonen

Var denne artikkelen nyttig?
14 av 20 syntes dette var nyttig
Del

Kommentarer

0 kommentarer

Logg på hvis du vil legge inn en kommentar.