Ekstern Internett-tilgangskontroll (foreldrekontroll)

Et økende antall bedrifter i dag trenger å koble datanettverket til Internett. En Internett-leverandør (ISP) er vanligvis ansvarlig for driften av tilgangskanalen, men systemadministratoren for et datanettverk til en bedrift, selv en liten, må løse en rekke organisatoriske og teknologiske problemer. I denne artikkelen vil vi ikke vurdere e-posttjenester, IP-telefoni og virtuelle private nettverk (VPN-er), men vi vil begrense oss til tilgang til web- og ftp-tjenester basert på FreeBSD OS og en SQUID proxy-server i et bedriftsnettverk som dekker opptil 100 arbeidsstasjoner .

To metoder

Det er to hovedmetoder for å gi brukere på et bedriftsnettverk tilgang til web- og ftp-tjenester: gjennom ruting (kringkasting) eller gjennom en proxy-server.

I det første tilfellet (fig. 1) gis tilgang av IP-adressen til datamaskinen som den ansatte jobber på. En slik ordning kan implementeres fullt ut på grunnlag av en programvareløsning - FreeBSD OS-gatewayen og IPFW-brannmuren. I tillegg er det komplekse spesialiserte maskinvare- og programvaregatewayer. For terminalarbeidsstasjoner er organisering av tilgang med IP-adresser teknisk umulig, siden de alle bruker samme IP-adresse til terminalserveren.

For å koble brukerarbeidsstasjoner til Internett-kanalen, brukes en gateway i form av en x86-server med FreeBSD OS installert på den, NATD-program (som gir oversettelse av interne IP-adresser til den virkelige IP-adressen til serveren og omvendt), IPFW, aktivert av ruting og to nettverksgrensesnitt: ett av dem "ser" mot det lokale nettverket, det andre er koblet til leverandøren. På hver klientmaskin, i egenskapene til TCP / IP-protokollen til nettverkskortet, er det nødvendig å registrere IP-adressen til gatewayen.

I det andre tilfellet er brukeren autorisert av tilgangsnavnet (pålogging) og passordet som er tildelt den ansatte. Spesielt dette alternativet kan implementeres ved å bruke SQUID-proxyserveren og ncsa_auth-autentiseringssystemet. La oss vurdere et typisk skjema (fig. 2), hvor SQUID er satt på nettverksporten: serveren "ser" ut med ett grensesnitt til det lokale nettverket, mens det andre er koblet til Internett-kanalen. Med denne innstillingen krever ikke SQUID NATD og ruting for å fungere på Internett (via HTTP, FTP og DNS) på maskiner på det lokale nettverket, siden alle forespørsler til Internett-ressurser sendes av SQUID "fra seg selv" - med IP-adressen av det eksterne grensesnittet til gatewayen. Du kan slå av DNS på klientdatamaskiner fordi SQUID selv refererer til DNS.


Ris. 2. Tilgang til Internett via en proxy-server.

Vanligvis bruker bedriftsnettverket e-post, og du trenger fortsatt ruting og NATD på gatewayen for å få det til å fungere, men for nettpost over HTTP er en SQUID-proxy tilstrekkelig.

SQUID sender data "nedlastet" fra Internett til brukeren og lagrer det i cachen. På en andre forespørsel hentes disse dataene fra hurtigbufferen (hvis, selvfølgelig, nettsiden tillater caching), som er mye raskere og ikke tar opp tilgangskanalen. I tillegg til mer effektiv bruk av kanalbåndbredden, oppnås også besparelser på trafikkvolumet (i følge forfatteren er det i gjennomsnitt per måned 13%). Dataene i hurtigbufferen kan bli oppdatert avhengig av innstillingen til selve proxy-serveren. Når du klikker på Oppdater-knappen i nettleserens kontrollpanel, tvangskopierer proxy-serveren data fra webserveren, selv om den har den i hurtigbufferen og ikke er utdatert (og samtidig oppdaterer den i cachen). Noen sider på nettsteder er imidlertid spesifikt merket som ikke-bufres, for eksempel på grunn av økt relevans.

I tillegg til den faktiske tilgangen, må systemadministratoren også løse problemene med å autorisere tilgang, redegjøre for trafikk og tiden brukere jobber på Internett, for å sikre sikkerheten til bedriftens lokale nettverk. Det er også nødvendig å definere reglene for fordeling av båndbredden til Internett-kanalen blant nettverksbrukere og reglene for tilgang til Internett-ressurser; andre brukerbegrensninger må kanskje angis.

Alle disse prosedyrene, avhengig av typen tilgang som aksepteres (via IP-adresse eller via en proxy-server), har sine egne egenskaper.

Godkjenning

Autentisering med IP-adressen til en datamaskin gir ikke passordbeskyttelse for Internett-tilgang. Brukere som kjenner passord for å få tilgang til driftsmiljøet til andre maskiner i bedriften, kan jobbe på forskjellige datamaskiner. Derfor, hvis flere ansatte bruker én datamaskin til å jobbe på Internett, er det umulig å skille trafikken deres under regnskapsføring.

Det er et alternativ for å forfalske IP-adressen; men det er også et mottiltak - en statisk tabell ARP (Address Resolution Protocol - protokoll for konvertering av IP-adresser til MAC-adresser / maskinvareadresser til nettverkskort) på gatewayen, hvor samsvaret mellom IP-adressen og MAC-adressen til arbeidsstasjonens nettverkskort er skrevet. Generelt er ikke IP-autentisering fleksibel og pålitelig nok til å kun telle den totale mengden trafikk.

Når det gjelder en proxy-server, blir bedriftsnettverksbrukere som har fått tillatelse til å få tilgang til Internett (HTTP, FTP, ICQ) tildelt et identifikasjonspar: navn (pålogging) og passord (passord). Denne ordningen lar også forskjellige brukere få tilgang til Internett fra én datamaskin (hovedsaken er at proxy-serverparametrene er spesifisert i klientprogrammene). Trafikk vil bli registrert for hver bruker (pålogging) separat. Autentisering leveres av en SQUID proxy-server som kjører FreeBSD, og ​​ncsa_auth-programvareundersystemet lagrer passord i kryptert MD5-format. SQUID kan bruke ulike eksterne autentiseringsmekanismer.

Arbeid på Internett via en proxy-server må støttes av klientprogramvaren: innstillingene inneholder DNS- eller IP-adressen til proxy-serveren, samt TCP-porten. Alle moderne nettlesere og ICQ-klientstøtten fungerer gjennom en proxy-server og autentisering på den. Autentisering kan skje ved hver tilkobling (brukernavn og passord er forespurt) eller være permanent (krever ikke brukernavn og passord, mens brukernavnet fra proxy-serverens autentiseringsliste og passord er skrevet i klientprograminnstillingene). Autentisering skjer én gang og er gyldig til klientprogrammet lukkes. På slutten av arbeidet på Internett lukker brukeren ganske enkelt nettleseren og avbryter dermed den tillatte økten.

Trafikkregnskap

Trafikkregnskap etter IP-adresser til arbeidsstasjoner utføres ved hjelp av IPFW - programvarebrannmur innebygd i FreeBSD OS-kjernen. For pålitelig regnskapsføring av trafikk fra brukere med en slik tilgangsordning, må ansatte kun få tilgang til Internett fra sine tildelte arbeidsplasser, noe som naturligvis begrenser fleksibiliteten og mobiliteten til arbeidet deres.

Ikke desto mindre har denne tilnærmingen også sin fordel - en mer nøyaktig regnskapsføring av det totale trafikkvolumet over IP-protokollen. Denne prosedyren oppnås ved å angi to IPFW COUNT-regler:

Tell ip fra hvilken som helst til hvilken som helst inn via de0 tell ip fra hvilken som helst til hvilken som helst ut via de0

Den første regelen tar hensyn til den innkommende strømmen, den andre - utgående. Her er de0 det eksterne nettverksgrensesnittet til gatewayen, som har en ekte IP-adresse på Internett. Samtidig, med en slik ordning, er det umulig å logge navnene på ressursene som besøkes av brukere, samt navnene og størrelsene på nedlastede filer.

Når du bruker en proxy-server, utføres trafikkregnskap ved hjelp av HTTP-protokollen, og mengden av slike data er mindre enn mengden IP-trafikk. Men ved autentisering av brukere, logger SQUID alle data om forespørsler (DNS-adresser til nettsteder, tidspunkt for mottak av forespørselen, størrelse på nedlastede filer, kilde - SQUID-cache eller Internett) i loggen for hver bruker, uavhengig av IP-adressen til klientmaskinen.

Internett-tilkoblingssikkerhet

Å koble en fysisk Internett-kanal direkte til et bedriftsnettverk er ensbetydende med å bringe arbeidsplassene til bedriften til et overfylt område. Som regel er informasjon som sirkulerer i et lokalt nettverk kritisk viktig for driften av en virksomhet, og den ondsinnede effekten av virus (for eksempel e-post), et angrep utenfra eller datalekkasje innenfra kan fullstendig forstyrre driften.

Den skadelige effekten av virus kan neppe undervurderes, men løsningen på dette problemet er 90 % avhengig av brukerbevissthet – om noen vil lansere et virus vedlagt en e-post. Virusangrep kan blokkeres og avvises av antivirusprogrammer på e-postservere (Dr.Web, McAfee, Kaspersky Anti-Virus Business Optimal, etc.) og på brukerdatamaskiner (Norton Antivirus, tilsvarende produkter fra Kaspersky Lab, etc.) . .. Det viktigste her er rettidig oppdatering av antivirusdatabasene.

Angrep fra utsiden, avhengig av hvordan tilkoblingen er organisert, blokkeres ved å kompetent konfigurere gatewayen, bruke en proxy-server på gatewayen uten NAT og ruting, samt flytte proxy-serveren, e-posten og webserveren inn i den "demilitariserte sonen " (DMZ, bedriftens undernettverk tilgjengelig fra Internett).

Bedriftsdatalekkasjer er først og fremst av organisatorisk karakter og utgjør det vanskeligste problemet for sikkerhetspersonell i bedrifter. Det er tekniske løsninger som minimerer muligheten for dette: spesielt lukking av alle TCP / UDP-porter på gateway-grensesnittet "ser" til det lokale nettverket (bare proxy-serverporten gjenstår). Ruting og adresseoversettelse (NAT) mellom Internett og de interne ("grå") IP-adressene til bedriftsnettverket må være deaktivert.

De ovennevnte tiltakene brukes når en proxy-server er installert på gatewayen, men et system med en proxy-server plassert i DMZ anses som sikrere.

Den mest komplette beskyttelsen er gitt av den fysiske separasjonen av det lokale bedriftsnettverket og Internett. I dette tilfellet organiserer bedriften et datanettverk for arbeid på Internett, ikke koblet til det lokale nettverket via informasjonsoverføringskanaler. Data som skal sendes på e-post overføres på flyttbare medier (som CDer), som kontrolleres av sikkerhetstjenesten og krypteres for eksempel ved hjelp av PGP, et gratis krypteringsprogram for e-postmeldinger og filer.

Kanalbåndbreddetildeling

For det IP-baserte tilgangsskjemaet kan båndbreddedeling mellom brukere implementeres ved å bruke pipene til IPFW OS-brannmuren til FreeBSD OS, og når det gjelder SQUID-proxyserveren, kan dens delay_pools-mekanisme brukes.

Serveren bestemmer størrelsen på filen som brukeren ber om, og hvis denne størrelsen ikke overskrider den angitte verdien, lastes filen ned med høyest mulig hastighet. Når det gjelder en større fil, overføres den med en forhåndsbestemt begrenset hastighet. Denne mekanismen gjelder ikke for alle brukere, men bare for de som er oppført i ACL-ene (Access Control List - en navngitt gruppe av objekter som ulike begrensninger kan brukes på), som lar deg konfigurere prioriteringene til ulike brukergrupper meget fleksibelt.

Men hvis bare én bruker jobber for øyeblikket, vil de fortsatt være underlagt fartsgrenser ved opplasting av store filer. IPFW, i motsetning til delay_pools for SQUID, lar deg implementere dynamisk kanaldeling.

Tilgang til ressurser og andre restriksjoner

For IP-skjemaet er restriksjoner bare mulig på IP-adressene til serverne og på TCP / UDP-portene. Dette er upraktisk fordi Apache Web Server Virtual Hosts-mekanismen basert på HTTP v1.1 er vanlig i dag, der en enkelt webserver med en enkelt IP-adresse betjener mange nettsteder med forskjellige DNS-navn.

SQUID, på den annen side, gir svært fleksible mekanismer for å administrere brukertilgang til Internett-ressurser ved å bruke ACL-er. Dette kan for eksempel være tilgang på et bestemt tidspunkt, ukedag, måned; tillatelse / forbud mot å kopiere visse typer filer, tillatelse / forbud mot å få tilgang til en ressurs hvis navn inneholder et bestemt nøkkelord.

Konfigurere IPFW-gatewayen

En gateway er en datamaskin med to nettverksgrensesnitt (det ene er koblet til Internett-kanalen og har en ekte IP-adresse, og den andre "ser" inn i bedriftsnettverket og identifiseres av IP-adressen til subnettet) som FreeBSD er installert på (http://www.freebsd.org). FreeBSD er enkelt å sette opp, pålitelig, gratis og inneholder nesten alt du trenger for en bedriftsomfattende nettverksserver.

Prosessen med å installere FreeBSD OS, konfigurere nettverksgrensesnitt, lansering og konfigurering av IPFW, NATD, ruting - generelt alt du trenger for å konfigurere en Internett-tilgangsport (både via IP og ved å bruke SQUID proxy-serveren, bortsett fra å sette inn selve SQUID) er beskrevet i detalj i boken av M. Eben og B. Tyman "FreeBSD. User's Encyclopedia" (Kiev: Diasoft, 2003).

For begge alternativene for å organisere Internett-tilgang, må du konfigurere IPFW-programvaren. IPFW filtrerer og teller IP-pakker på alle nettverksgrensesnitt. Programmet behandler også pakker på høyere nivåer: UDP, TCP og ICMP. I tillegg deltar IPFW i NATD. Når du konfigurerer ipfw-regler, anbefaler forfatteren å bruke trafshow-verktøyet for å kontrollere anrop til og fra nettverket på alle grensesnitt, og indikerer IP-adressene til eksterne maskiner, protokoller og porter i sanntid. Kommando

Trafshow -i fxp0 -n

setter tilordningen av pakker på fxp0-grensesnittet med portnumre og kommandoen

Ipfw -en liste

viser ipfw-reglene, antall pakker og mengden trafikk (i byte) som er gått siden serveren ble slått på eller regeltellerne sist ble tilbakestilt.

Implementering og arbeid med SQUID

SQUID caching proxy-server (http://www.squid-cache.org) på Unix-plattformen er gratis og åpen kildekode-programvare. Det er svært konfigurerbart, godt dokumentert, allment tilgjengelig og enkelt å integrere med FreeBSD OS. SQUID lar deg organisere ulike typer autentisering ved tilgang til Internett, avgrenser tilgang med en hvilken som helst parameter (domenenavn, nøkkelord i adressen, protokoll, etc.) basert på ACL-lister.

Når du bruker SQUID på gatewayen, er det nødvendig å lukke muligheten for lokale maskiner for å få tilgang til eksterne adresser (og omvendt) og tillate tilgang fra det lokale nettverket kun til proxy-serverporten på det lokale grensesnittet. NAT- og gateway-ruting bør også deaktiveres hvis de ikke er nødvendige for SMTP eller andre tjenester.

Installasjonen utføres fra portene til FreeBSD OS (i versjon 4.9, gjeldende versjon 4.10) / usr / ports / www / squid (2.5 versjon STABLE3) eller / usr / ports / www / squid24 (STABLE7). De nødvendige alternativene må ikke kommenteres i Makefilen. Anbefalte alternativer:

CONFIGURE_ARGS + = -enable-delay-pools (for å aktivere båndbreddetildelingsmekanisme); CONFIGURE_ARGS + = -enable-err-language = Russian-1251 (for diagnostikk på russisk)

Etter å ha installert SQUID, må du installere selve autorisasjonssystemet. Kildene finnes i SQUID-filene:

/usr/ports/www/squid24/work/squid-2.4.STABLE7/auth_modules/NCSA

Arbeidseksempel squid.conf-tekst

Icp_port 0 client_netmask 255.255.255.0 authenticate_program / usr / local / squid / bin / ncsa_auth / usr / local / etc / passwd authenticate_children 20 reference_age 2 uker acl all src 0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 /255.255.255.255 acl SSL_ports port 443 563 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews acl Safe_ports port 70 # 2 1_0 port acl 5-2 er registeret acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filmaker acl Safe_ports port 777 # multiling http acl CONNECT-metode CONNECT acl Inet_users proxy_auth "/ usr / local /_ etc / 1" delayd_class 1 2 delay_parameters 1 7500/7500 1875/1875 delay_access 1 tillate Inet_users delay_access 1 nekte alle http_access tillate manager localhost http_access nekte manager http_access nekte! Safe_ports http_access nekte CONNECT! SSL_ports http_ ccess tillate Inet_users http_access nekte alle

Etter installasjon, konfigurering, lansering av SQUID og dets autorisasjonssystem, trenger administratoren bare å legge til og fjerne brukere. Det er nok å lage brukerdata bare i SQUID, siden det ikke kommer inn i OS-miljøet til proxy-serveren, og følgelig er det ikke nødvendig å opprette OS-brukeridentifikasjonsdata. Etter å ha endret squid.conf eller lagt til / fjernet brukere, bør SQUID lese konfigurasjonen på nytt uten å lukke eksisterende brukersesjoner med kommandoen

Squid -k rekonfigurere.

Når du oppretter en SQUID-bruker ved å bruke ncsa_auth, må du spesifisere brukerens innlogging og passord i to konfigurasjonsfiler; i vårt eksempel vil det se slik ut:

/ usr / local / etc / squid_users / usr / local / etc / passwd

Den første filen legger ganske enkelt til brukernavnet (pålogging) på en ny linje ved hjelp av et tekstredigeringsprogram. Den andre filen lagrer brukerpassord (i MD5) og kan bare legges til denne filen ved å bruke htpasswd-verktøyet som følger med Apache-webserveren.

Det er nødvendig å overvåke innholdet i SQUID-cachen og med jevne mellomrom tømme den for å unngå overløp av filsystemet ved å bruke squid -Z-kommandoen.

I klientinnstillingene i egenskapene til nettlesere og ICQ-klienter må du spesifisere proxy-serverens IP-adresse og port. I vårt eksempel er disse IP: 192.168.1.8 og port 3128 (denne porten brukes som standard). Hvis ICQ-programmet er konfigurert til å fungere gjennom en proxy-server, bruker det den 443., ikke 5190. TCP-porten til ICQ-servere, som også bør tas i betraktning når du konfigurerer brannmurer. Når du bruker SQUID, er det nødvendig å lukke muligheten for lokale maskiner for å få tilgang til den 80. TCP-porten til Internett-servere. Du kan vanligvis bare tillate tilgang til proxy-serverporten, og lukke den for alle andre, bortsett fra e-post, slik at "avanserte" brukere ikke går til Internett utenom SQUID.

Forviklingene ved å sette opp SQUID kan bli funnet på http://www.bog.pp.ru/work/squid.html.

Trafikkanalyse

Til dette formålet brukes et gratis åpen kildekode-analysatorprogram SARG (). Resultatet av arbeidet hennes er HTML-sider som viser alle slags statistiske datastykker om arbeidet til brukere på Internett. Hele loggperioden blir analysert, så det er mer praktisk å foreta de nødvendige kuttene på slutten av måneden og deretter tømme SQUID-loggen ved å bruke access.log-kommandoen.

To typer skiver er oftest nødvendig. For det første fordelingen av mengden informasjon som lastes ned fra Internett av brukere, vanligvis sortert i synkende rekkefølge etter volum (fig. 3). Samtidig gis også kvantitativ informasjon om effektiviteten av caching. Denne delen lar deg analysere arbeidsvolumet på Internett generelt og rangere brukere etter deres aktivitet på Internett.

Den andre populære delen er visning av informasjon lastet opp av en spesifikk bruker etter nettsted (fig. 4), også sortert i synkende rekkefølge av datavolumer. Denne delen lar deg gjennomføre en "debriefing" av brukeren på Internett og finne ut om de oftest etterspurte sidene samsvarer med den ansattes jobboppgaver.

konklusjoner

Vi vurderte to alternativer for å organisere en permanent tilkobling av bedriftsnettverket til Internett.

Alternativet "etter IP-adresser til brukernes datamaskiner som bruker IPFW-regler" har følgende ulemper. For det første er det umulig å kontrollere hensiktsmessigheten av brukerens arbeid på Internett, siden IPFW bare beregner den totale trafikken, for hver regel foreskrevet for en bestemt maskin, og ikke holder styr på nettstedene som er besøkt. For det andre er det umulig å autorisere brukeren som jobber på Internett. Dette er spesielt viktig hvis maskinen er "delt" av flere brukere. Til slutt er det mulig for brukeren å forfalske IP-adressen.

I tillegg, ved bruk av en terminalserver, er det umulig å ta hensyn til trafikken til forskjellige brukere, siden de alle jobber fra den samme IP-adressen til terminalserveren.

Manglene som er oppført gjenspeiler ganske enkelt begrensningene for regnskapsføring og administrasjon av trafikk ved hjelp av IP-adresser og IPFW-regnskapssystemet. IPFW og er ikke ment direkte for å måle trafikken til brukermaskiner, det er et verktøy for å regnskapsføre kanaltrafikk.

En komplett og komplett løsning på problemet leveres av et system som bruker en gateway med FreeBSD OS, en konfigurert IPFW-brannmur og en SQUID-proxyserver installert på den med ncsa_auth-autentisering aktivert. Ved å bruke en caching proxy-server i et bedriftsnettverk kan du spare opptil 10 % på månedlig trafikk og øke hastigheten på lasting av ofte besøkte ressurser.

All programvare som brukes i denne løsningen er gratis. Vedlikeholdskostnadene er minimale, og som praksis viser, er FreeBSD + SQUID ganske pålitelig.

SQUID-systemet er svært skalerbart på grunn av fleksibiliteten i konfigurasjonen og tilstedeværelsen av grensesnitt for tilkobling av eksterne moduler. Feilen i regnskapsføring av trafikk over HTTP versus IP iboende i SQUID er ikke kritisk; det er mye viktigere at det samtidig er mulig å organisere pålitelig kvantitativ og kvalitativ overvåking av arbeidet til brukere på Internett ved å bruke HTTP-, HTTPS- og FTP-protokollene og å differensiere rettigheter og prioriteringer for tilgang.

Proxy-serveren er i stand til å operere på en maskin med ganske lite strøm, for eksempel med en 1 GHz Celeron-prosessor, 128 MB minne og en 20 GB harddisk (denne konfigurasjonen fungerer for øyeblikket i vår bedrift, og betjener 30 brukere), og gateway-rollen for tilgang over IP (FreeBSD, IPFW, NATD) kan kjøre en 166 MHz Pentium-datamaskin med 128 MB minne.

Pavlov Sergey Systems-ingeniør hos Softmart

Denne artikkelen presenterer de mest populære måtene å koble et kontor til en liten organisasjon til Internett. Artikkelen berører ikke spørsmålene om valg av leverandør og spørsmål om valg av sluttutstyr for tilkobling til nettverket. Vi går ut fra at leverandøren gir organisasjonen følgende:

1. Nettverksgrensesnitt Ethernet RJ45 - en standard for nettverksutstyr i lokale nettverk
2. IP-adresse - en eller flere, permanent eller dynamisk
3. IP-adresse til gateway og DNS

Her er også et lite portrett av organisasjonen denne artikkelen er designet for:

1. Antall datamaskiner i nettverket - opptil 30;
2. Det er én filserver eller server for bedriftsstyringssystem i nettverket;
3. Nettserveren og e-postserveren til organisasjonen er vert for leverandøren, og ikke i bedriftens lokale nettverk;
4. Internett-kanalen vil bli brukt av ansatte hovedsakelig til å jobbe med e-post og surfe på nettsidene;
5. Datamaskiner og servere til organisasjonen må beskyttes mot uautorisert tilgang via Internett-kanalen;

Mulige, men sjeldne tilstander kan også nevnes:

1. Sikker tilkobling av ansatte til organisasjonens nettverk eksternt - hjemmefra eller et annet kontor;
2. Sikker tilkobling av små kontorer, geografisk spredt;
3. Plassering av en webserver, e-postserver, server for ethvert internkontrollsystem i organisasjonens nettverk med fri tilgang til dem for ansatte eller klienter på Internett;

Med denne tilnærmingen blir en personlig datamaskin eller server tildelt for å organisere tilgang til Internett. Serveren eller PC-en er utstyrt med et ekstra nettverkskort. En av dem kobles til leverandørens nettverk, den andre til organisasjonens nettverkssvitsj.
Det anbefales å starte NAT-tjenesten på gatewayen - nettverksoversettelse av IP-adresser.

Fordelene med denne løsningen:

1. Evnen til å bruke det bredeste utvalget av programvare for å løse ulike oppgaver, for eksempel:
å beskytte serveren og nettverket mot angrep fra Internett;
for antivirusbeskyttelse av serveren, trafikk eller e-post;
for å beskytte mot spam;
for trafikktelling;
å kontrollere tilgang til Internett for ansatte i organisasjonen;
2. Én IP-adresse fra leverandøren er nok.
3. Et tilstrekkelig nivå av beskyttelse av det lokale nettverket mot ytre påvirkninger er gitt gjennom bruk av NAT-tjenesten.
4. Lave kostnader for en brannmur, siden løsninger for personlige datamaskiner er tillatt.
5. Bare gateway-datamaskinen er synlig fra Internett, og hackere kan kun angripe denne datamaskinen. Det lokale nettverket, inkludert servere og arbeidsstasjoner, er i prinsippet ikke tilgjengelig for dem. Hvis gatewayen svikter, fortsetter organisasjonens lokale nettverk å fungere.

ulemper

1. Hvis gateway-datamaskinen også brukes som en vanlig arbeidsstasjon for en av de ansatte, for eksempel basert på kostnadsbesparelser, er alvorlige sikkerhetsproblemer mulig. Brukeren som jobber på gatewayen kan svekke serverens beskyttelse ved sine handlinger. I tillegg kan det være problemer med ytelsen til gatewayen, siden noe av datamaskinens kraft vil bli tatt fra brukeren;
2. Det frarådes sterkt å bruke gatewayen som en filserver for organisasjonen på grunn av tilgjengeligheten til serveren fra Internett. Det krever en kraftig brannmur (ikke personlig) og arbeidet til en meget dyktig sikkerhetstekniker på gatewayen. Dette er imidlertid en svært vanlig konfigurasjon i små organisasjoner;
3. Krever kjøp av tilleggsprogramvare. NAT er ikke inkludert i Windows-operativsystemer, bortsett fra Microsoft Windows XP (NAT er implementert, men med noen begrensninger). Kostnaden for brannmurer varierer fra titalls dollar til flere tusen. Som et minimum kreves det et spesielt program for å gi tilgang til Internett for alle brukere av det lokale nettverket. (programmet kalles en proxy-server).
4. En ekstra enhet er nødvendig - et nettverkskort.

Den omtrentlige kostnaden for å implementere denne løsningen:

Personlig datamaskin - gateway

$40 0

Proxy-server

UserGate 3.0 (10 økter)

$ 129

Brannmur

Kaspersky AntiHacker

$39

Ekstra nettverkskort

D-Link DFE-530 TX

$10

Tilpasningstjenester

Softmart

$70

Total

$648

Med denne tilnærmingen, for å organisere tilgang til Internett, er det nødvendig å få et ekstra antall IP-adresser fra leverandøren for hver personlig datamaskin i det lokale nettverket til organisasjonen. Denne løsningen vil sannsynligvis gi den raskeste Internett-tilkoblingen for ansatte i en organisasjon. Denne løsningen brukes imidlertid sjelden når antallet datamaskiner i selskapet er mer enn to av to grunner:
1. Leverandøren er ekstremt tilbakeholden med å tildele IP-adresser, og han vil selv anbefale deg å bytte til en hvilken som helst annen ordning for å koble datamaskiner til Internett.
2. Denne løsningen er potensielt den minst sikre når det gjelder å beskytte dataene dine mot uautorisert tilgang og angrep fra nettverket.

Fordeler:

1. Enkel konfigurasjon av datamaskiner.
2. ikke nødvendig å kjøpe en ekstra datamaskin - gateway.
3. ikke nødvendig å kjøpe ekstra programvare - proxy-server.

Ulemper:

1. Omfattende beskyttelse er nødvendig på hver datamaskin.
2. Avhenger av leverandørens evne til å oppgi flere IP-adresser
3. Ingen statistikk over kanalbruk

Kostnaden for å implementere denne løsningen:

For hver datamaskin på nettverket:

Brannmur

Kaspersky AntiHacker

$39

Tilpasning

Softmart

$10

Total

$49

Tilgjengelighet med D-LINK-enheter

D-Link tilbyr et bredt spekter av enheter for sikker tilkobling av små organisasjoner til Internett. Alle løsninger kan grovt sett deles inn i to store klasser:
1. Rutere DI-serien
2. Brannmurer i DFL-serien

Enheter fra DI-familien er spesialdesignet for formål og oppgaver til små kontorer. De har all funksjonaliteten du trenger for en mer enn overkommelig pris. Avhengig av modell kan enhetene være utstyrt med:
brannmur,
Wi-Fi hotspot,
innebygd proxy-server,
nettverksporten til skriveren,
innebygd ADSL-modem
VPN-modul

Alle enheter støtter:
1. DHCP (funksjon for dynamisk tilordning av IP-adresser til datamaskiner på nettverket)
2. NAT (funksjon for dynamisk oversettelse av IP-adresser fra det interne nettverket til IP-adressene til Internett)
3. Funksjonen til en virtuell server, som er nødvendig for å organisere tilgang til en lokal server fra Internett
4. Funksjonen til den beskyttede sonen, som er nødvendig for å organisere tilgang til flere lokale ressurser fra Internett

Verdighet



3. Lav pris for sin klasse.
4. Beskyttelse mot angrep ved bruk av NAT, + muligheten til å legge inn regler for å nekte domener, adresser osv.


7. Muligheten til å opprette sikre tilkoblinger på Internett (VPN), for kommunikasjon med andre kontorer.
8. Mulighet for å organisere tilgang til interne ressurser i lokalnettet.
9. Evne til å støtte mobile brukere (Wi-Fi).
10. Evne til å koble til en nettverksskriver.

Ulemper:


2. Det er maskinvarebegrensninger på antall ansatte som jobber samtidig. DI-enheten vil håndtere opptil 2000 samtidige tilkoblinger uten merkbar ytelsesforringelse.
3. Maskinvaren er mottakelig for angrep innenfra, for eksempel nettverksvirus. Med slike angrep øker belastningen på enheten dramatisk.
4. Selve enheten er dårlig beskyttet mot typiske nettverksangrep. Samtidig lider disse organisasjonene og datamaskinene som regel ikke.
5. Statistikk over ansattes bruk av kanalen er ikke detaljert nok.

Omtrentlig kostnad for løsningen

D -Link DI -604

D-Link

Tilpasning

Softmart

Total

Enheter fra DFL-familien er allerede høyytelses brannmurer utstyrt med alle tenkelige og nymotens løsninger for å beskytte det lokale nettverket og organisasjonens ressurser mot inntrenging. Avhengig av den spesifikke modellen kan enheten for eksempel være utstyrt med:
inntrengningsdeteksjonssystem IDS
systemer for å oppdage typiske angrep og avvise dem
båndbreddestyringssystem
lastbalanseringssystem
VPN

Du må velge en modell basert på antall datamaskiner i nettverket og sikkerhetskrav. Det er best å søke hjelp fra en D-Link Solutions-konsulent.

Fordeler:

1. Maskinvareløsninger er svært pålitelige, kompakte og upretensiøse.
2. Selve enhetene er godt beskyttet mot angrep fra nettverket og beskytter godt omkretsen av organisasjonens lokale nettverk.
3. Beskyttelse mot nettverksangrep, inkludert: SYN, ICMP, UDP Flood, WinNuke, portskanning, spoofing, adressespoofing, denial of service, etc.
4. Når det er konfigurert, trenger ikke systemet ytterligere justeringer.
5. Det er ingen dedikert datamaskin - gateway.
6. Enkel installasjon og konfigurasjon.
7. Lav pris for sin klasse.
8. Muligheten til å opprette sikre tilkoblinger på Internett (VPN), for kommunikasjon med andre kontorer.
9. Mulighet for å organisere tilgang til interne ressurser i lokalnettet.

Ulemper:

1. Justering må gjøres av en kvalifisert tekniker.
2. Statistikk over ansattes bruk av kanalen er ikke detaljert nok.

Omtrentlig kostnad for løsningen

D -Link DFL -100

D-Link

$200

Tilpasning

Softmart

Total

$230

Konklusjon

Med all rikdom av valg, ser det ut til at den mest optimale løsningen for en liten organisasjon fortsatt er en løsning basert på en av D-Link-enhetsmodellene til DI-familien. Enhetene er enkle, kompakte, rimelige og funksjonelle nok. Det eneste DI-løsninger kan klandres for er mangelen på noen proxy-server-funksjoner, for eksempel statistikk over volumet av lastet informasjon om ansatte. Det er tross alt disse dataene som vanligvis brukes av tilbydere for å fakturere for bruken av kanalen. Hvis denne funksjonen er viktig for din organisasjon, bør du i tillegg vurdere å kjøpe en proxy-server, for eksempel UserGate fra eSafeLine. Bare ikke glem at proxy-serveren vil kreve kjøp av en ekstra datamaskin.

Før vi diskuterer autentisering av nettverksbrukere, er det nødvendig å utvikle regler for kontroll av nettverkstilgang. Nettverk er ikke lenger monolitiske objekter. I de fleste tilfeller er det ett eksternt tilgangspunkt - en Internett-tilkobling via en ISP ( Internett-leverandør- Internett-leverandør). Regler for nettverkstilgangskontroll vil diktere hvilken beskyttelse som må installeres ved inngangspunktene til nettverket.

Porter

Porter er punktene der nettverkstrafikk går fra en organisasjons nettverk til et annet nettverk. For gatewaypunkter må reglene for tilgangskontroll ta hensyn til arten av nettverket der broen installeres.

  • Adgangskontrollregler for innkommende og utgående telefonsamtaler (innringing og utringing)... Dekker autentiseringskrav. Det er ganske vanskelig å skjule det oppringte tilgangspunktet til nettverket. Derfor er det viktig å definere kontroller for denne tilgangen. Det er mange hensyn angående tilgangsregler, som å lage modemer utelukkende for å håndtere utgående signaler ( utelukkende) for oppringt tilgang. Det er nødvendig å skrive en klausul i reglene som vil foreskrive bruken av de riktige kontrollene.

    All telefontilgang til nettverket må beskyttes med sterke autentiseringskontroller. Modemer må konfigureres for én av inn- eller utgående tilganger, men aldri for begge. Nettverksadministratoren bør gi prosedyrer for sikker tilgang til modemsystemer. Brukere bør ikke installere modemer på andre punkter i nettverket, i henhold til passende sanksjoner.

  • Andre eksterne tilkoblinger... Ulike koblinger til nettverket fra utenfor organisasjonen er mulig. Reglene kan fastsette direkte tilgang for klienter til nettverket gjennom et virtuelt privat nettverk VPN(Virtuelt privat nettverk) og gjennom en organisasjons nettverksutvidelser kjent som ekstranett.
  • Internett-tilkobling... Skiller seg fra andre forbindelser ved at folk ønsker offentlig tilgang til Internett, mens organisasjonens tjenester gir tillatelse til tilgang. Reglene for disse tilkoblingene er omtalt i kapittel 6, Internettsikkerhetsregler.

Som med alle regler, bør du forvente forespørsler om å endre reglene for tilgangskontroll. Uavhengig av begrunnelsen for justeringen av reglene, bør det være mulig å innføre unntak fra reglene gjennom regelrevisjonsmekanismen. Hvis det er opprettet en sikkerhetsstyringskomité som pålagt av policyen (se kapittel 3, Informasjonssikkerhetsansvar), kan komiteen bli pålagt å revidere reglene.

Enhver gateway som er foreslått for installasjon på et selskaps nettverk hvis det er sannsynlig at den bryter retningslinjene eller prosedyrene foreskrevet av disse retningslinjene, bør ikke installeres uten forhåndsgodkjenning fra sikkerhetsstyringskomiteen.

Virtuelle private nettverk og ekstranett

Økningen i antall nettverk i en organisasjon gjør det nødvendig å se etter nye alternativer for å koble til eksterne kontorer, klienter og forenkle tilgangen til å betjene entreprenører eller potensielle entreprenører. Denne veksten har skapt to typer eksterne tilkoblinger: VPN-er ( VPN- Virtual Private Network) og ekstranett. VPN-er er en rimelig måte å etablere kommunikasjon mellom to eller flere deler av en organisasjon lokalisert i forskjellige territorier. Organisasjoner lager en VPN ved å koble alle avdelinger til Internett og installere enheter som krypterer og dekrypterer informasjon i begge avdelingene som kommuniserer med hverandre. For brukere vil arbeid gjennom en VPN se ut som om begge avdelingene er lokalisert på samme territorium og fungerer i et enkelt nettverk.

Autorisasjonssjekk av hjelpesystemer

Før du fortsetter, er det viktig å huske at hver av gatewayene eller hvert hjelpesystem er inngangspunktet til organisasjonens nettverk. På et hvilket som helst tidspunkt må påloggingsinformasjonen til datastrømmen som går inn og ut av nettverket verifiseres på en eller annen måte. Et av spørsmålene som må vurderes er kravet om autorisasjon av eksterne tilkoblinger til hjelpesystemene til nettverket. Dette kan være et problem for hjelpesystemer som er permanent koblet til nettverket. For slike tilleggssystemer er det nødvendig å bestemme hvordan deres tilstedeværelse på nettverket vil bli autorisert. Faktisk kan selv midlertidige nettverkstilkoblinger, for eksempel innkommende modemtilkoblinger, ha strenge autentiseringskrav.

Denne delen trenger ikke å beskrive reglene for autentiseringskrav – de diskuteres i neste avsnitt, "Påloggingssikkerhet". Her kan vi bare merke oss behovet for autentiseringskrav. Reglene for autentiseringsstandarder vil bli diskutert i neste avsnitt. For å sikre at autentiseringsproblemet er løst for tilleggssystemene, kan imidlertid følgende legges til reglene for internettarbeid.

Applikasjonene som kreves for at gatewayene skal fungere, må være autentisert på nettverket. Hvis selve applikasjonen ikke kan autentiseres, bør autentiseringsreglene beskrevet i dette dokumentet gjelde for sekundære systemer koblet til via gatewayer.