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 vil bli overført fra organisasjonens 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 tilgangspunktet for oppringt nettverk. Derfor er det viktig å definere kontroller for denne tilgangen. Det er mange hensyn angående tilgangsregler, for eksempel å lage modemer utelukkende for å håndtere utgående signaler ( utelukkende) for oppringt tilgang. Det er nødvendig å skrive en regelklausul som foreskriver bruken av de riktige kontrollene.
All telefontilgang til nettverket må beskyttes med sterke autentiseringskontroller. Modemer må konfigureres for enten oppringt eller utringt tilgang, 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... Mulig ulike forbindelser til nettverket fra utenfor organisasjonen. Reglene kan fastsette direkte tilgang for klienter til nettverket gjennom en virtuell privat nettverk VPN(Virtuelt privat nettverk) og gjennom en organisasjons nettverksutvidelser kjent som ekstranett.
- Internett-tilkobling... Skiller seg fra andre forbindelser fordi 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. Dersom det er etablert et sikkerhetsstyringsutvalg i samsvar med policyen (se kapittel 3 Ansvar innen området informasjonssikkerhet"), kan utvalget 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 sammen eksterne kontorer, klienter og forenkle tilgangen til å betjene entreprenører eller potensielle entreprenører. Denne veksten har skapt to typer eksterne tilkoblinger: virtuelle private nettverk ( VPN- Virtual Private Network) og ekstranett. VPN er rimelig måte installere informasjonslenke mellom to eller flere divisjoner av organisasjonen 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å legitimasjonen til datastrømmen som kommer 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. Men for å sikre at spørsmålet om autentisering løses for tilleggssystemer, skal reglene for porter du kan legge til følgende.
Applikasjonene som kreves for at gatewayene skal fungere, må være autentisert på nettverket. Hvis selve applikasjonen ikke kan autentiseres, er autentiseringsreglene beskrevet i dette dokumentet bør gjelde for hjelpesystemer koblet gjennom gatewayer.
Rekorder: 4Ekstern Internett-tilgangskontroll (foreldrekontroll)
Denne veiledningen beskriver prosessen med å konfigurere datamaskiner som kjører operativsystemer. Windows-familien XP, 7 eller Linux (Ubuntu) for fjernkontroll av tilgang til internettsider.
Håndboken beskriver ikke i detalj metodene for å jobbe med Rejector-tjenesten, som vil bli diskutert nedenfor, den lar deg bare konfigurere datamaskinen din slik at den kan dra full nytte av dens evner.
Alle verktøyene som brukes tilhører utvalget av gratis programvare eller åpen kildekode.
Introduksjon
Internett er et flott verktøy for å lære, slappe av eller chatte med venner. Men på nettet dessuten nyttig informasjon, er det også uønsket for barnet ditt. I tillegg kan det å bruke timer på Internett distrahere fra andre viktige aktiviteter som lekser, sport, søvn eller sosialt samvær med jevnaldrende. Derfor er det nødvendig å overvåke barnets aktiviteter på Internett.
Det finnes mange forskjellige kontrollmetoder, men de er ikke alltid effektive. Overtalelse og pedagogiske samtaler kan vare i svært kort tid, fordi det å være på nettverket kan fengsle et barn så mye at det vil glemme all overtalelsen. Og forbud kan påvirke utviklingen av nyttige søke- og læringsferdigheter på Internett negativt.
I slike tilfeller vil du bli hjulpet spesielle programmer for å begrense og kontrollere tilgangen til nettverket. Med disse kan du beskytte barnet ditt mot negative påvirkninger Internett, men samtidig gi handlefrihet. Et slikt verktøy er Internet Access Control System Rejector.
Rejector er et sentralisert prosjekt for Internett-tilgangskontroll. Det vil tillate deg å beskytte barn og ungdom mot farlig informasjon. I hovedsak er Rejector en DNS-server med muligheten til å fjernstyre den.
Hvordan det fungerer?
Du registrerer deg, legger til IP-ene dine, konfigurerer tilgangsparametere. Du kan bruke tjenesten uten registrering, men da vil du ikke kunne bruke alle funksjonene.
Dine datamaskiner er konfigurert slik at alt DNS-spørringer ble sendt til DNS-serverne til Rejector 95.154.128.32 og 176.9.118.232.
Hver forespørsel kontrolleres for samsvar med innstillingene dine, for eksempel forbudte kategorier eller nettsteder, tillatte eller forbudte nettsteder, bokmerkelister eller uredelige nettsteder, og hvis blokkeringen bekreftes, blir forespørselen omdirigert til forbudssiden.
Du kan tilpasse denne siden etter eget ønske.
Tillatte forespørsler som har bestått valideringen går til den delte forespørselsbufferen for rask levering til alle klienter.
Mer Detaljert beskrivelse Du kan finne Rejector-produktet på den offisielle nettsiden rejector.ru
Instruksjoner for systemoppsett
1. La oss opprette en bruker med normale rettigheter
Vanligvis, når du installerer operativsystemet, opprettes en bruker med administratorrettigheter. En slik bruker kan produsere alt mulige handlinger levert av operativsystemet i kjøttet før fjerningen av selve systemet.
For å utelukke reversibiliteten til alle våre fremtidig handling fra siden av brukeren som vi tar kontroll over, vil vi opprette en bruker med begrensede rettigheter, og for administratoren vil vi bruke et passord.
V Windows-system dette gjøres gjennom kontrollpanelet; v Linux opprettelse brukeren er tilgjengelig via Systeminnstillinger.
2. Sett opp en nettverkstilkobling
Rejector er en tjeneste som i hovedsak er en DNS-server. For å jobbe med det, må du først konfigurere Nettverkstilkobling slik at DNS-spørringer sendes til Rejectors DNS-servere 95.154.128.32 og 176.9.118.232.
Windows og Linux gjør dette annerledes.
Windows XP
Windows Vista
Detaljerte instruksjoner finner du på
Windows 7
Detaljerte instruksjoner finner du på
På de fleste operativsystemer Linux-familien programmet brukes til å konfigurere nettverket Nettverkssjef... For å endre DNS-serveren, gjør følgende:
Trykk på RMB på tilkoblingsindikatoren og inn kontekstmenyen, velg elementet Endre tilkobling
Hvis du bruker DHCP-server når du kobler til Internett, endrer vi IPv4-parametrene Innstillingsmetode på Automatisk (DHCP, kun adresse)
I felt DNS-servere skriv inn to adresser atskilt med komma 95.154.128.32, 176.9.118.232
Opprette en forbindelse Tilgjengelig for alle brukere og Automatisk pluggbar
3. Registrer deg på Rejector-nettstedet
I prinsippet kan dette være utgangspunktet. Men nå, når en av vanskelighetene er over, gjør vi det enkelt og greit. Følg linken og fyll ut Enkel form for registrering.
4. Legg til et administrert nettverk
Ved å registrere oss på tjenesten kan vi opprette det nødvendige antallet nettverk eller, som i prinsippet er det samme - klientene vi skal administrere. Nettverk (klienter) identifiseres på tjenesten ved deres IP-adresse. Derfor, for å kontrollere tilgangen til Internett til en datamaskin, må du vite dens IP-adresse. For nå, la oss bare opprette et nettverk gjennom kontrollpanelet på Rejector-nettstedet på.
Fyll ut Legg til nettverk-skjemaet. Nettverksnavn - her kan du skrive inn navnet til barnet ditt hvis han har sin egen datamaskin og du vil kontrollere ham. Status- mest sannsynlig vil du ha Dynamisk IP-adresse(en sjelden leverandør tildeler Statisk adresse gratis), så vi velger denne alternativknappen. Nettverks-ID- du kan skrive på latin navnet du spesifiserte i det første feltet.
5. Sende IP-adressen
For at tjenesten skal fungere, må den hele tiden "kjenne" klientens IP-adresse, som kan variere fra tilkobling til tilkobling (Dynamisk IP-adresse). Dette er hovedproblemet som tas opp i denne opplæringen.
Tjenesteutviklerne tilbyr selv programmet Rejector Agent, som sender klientens IP-adresse til serveren. Men dette programmet kan ikke fungere autonomt. Derfor vil vi benytte en ny mulighet. Nemlig - oppdatering ved hjelp av en HTTP-forespørsel (beskrivelse ved lenke).
For å oppdatere klientinformasjonen via en HTTP-forespørsel i bakgrunnen, trenger vi Curl-programmet. Dette programmet er i stand til å sende HTTP-casts til Internett via kommandolinjen. Vi vil sette parametrene for dette programmet i skriptet; for Windows vil dette være en bash-fil for Linux - sh.
Curl er gratis og har en Windows-versjon, så vi vil bruke den i begge miljøene. Til Windows nyeste versjonen av programmet kan lastes ned fra lenken. For å installere, pakk bare ut innholdet i det resulterende arkivet i mappen C: \ WINDOWS \ SYSTEM32 (dette vil forenkle oppstarten av programmet). V operativsystem Linux-familien vil sannsynligvis ha den allerede installert.
6. Skript for regelmessig oppdatering av IP-adressen
Nettstedet foreslår følgende HTTP-forespørsel http://brukernavn: [e-postbeskyttet]/ni ...,
som vil oppdatere verdien til IP-adressen. Vi vil levere det som en parameter til curl-programmet.
Forespørselen om å oppdatere adressen må sendes fra datamaskinen vi ønsker å overvåke. På grunn av det faktum at tekstterminalen behandler kommandoer på en spesiell måte, måtte forespørselsteksten endres litt. Skriptet for Windows og Linux vises nedenfor.
For Windows
: Løkke
krøll "http: // pålogging %% 40mail-server.com:passord@ updates.rejector.ru / nic / update? vertsnavn = nettnavn"
# Gjør en forsinkelse på 300 sekunder
ping -n 300 127.0.0.1> NUL
ekko 111
goto loop
Hvor innlogging %% 40mail-server.com er din postkasse, ved hjelp av hvilken de registrerte seg på Rejector (@-tegnet erstattes av %% 40); passord - passord; nett-navn - navnet på nettverket på Rejector-tjenesten Plasser skriptteksten i en vanlig tekstfil, erstatt utvidelsen med .bat og du vil ha et kjørbart skript.
For Linux
#! / usr / bin / sh
mens sant; gjør krølle -u [e-postbeskyttet]: passord "http: //updates.rejector.ru/nic/update? vertsnavn = ... søvn 300; ferdig;
Alt her er det samme som for Windows. Skriv denne teksten til en tekstfil med filtypen sh.
Begge skriptene inneholder passordet for Rejector-kontoen i åpen form, så det er nødvendig å skjule innholdet fra visning for vanlig bruker... Linux og Windows implementerer dette annerledes.
For å forby visning og redigering av dette laget av oss, må du endre eieren og gruppen til filen til root og nekte alle unntatt eieren tilgang til filen. Hvis du har kompetansen til å jobbe i kommandolinje da må du gå med kommandoen cd til katalogen med skriptfilen og utfør kommandoen chown rot: rot skcript.sh og chmod 700 script.sh.Å gjøre det samme i grafisk skall, må du først starte filbehandleren med administratorrettigheter, finne skriptfilen og endre rettigheter, ved å bruke kontekstmenyen.
Uten å gå inn på hvordan du kan endre filtillatelser som i Linux, brukte jeg følgende løsning. La oss konvertere den kjørbare filen vår til en EXE-fil for å skjule innholdet. Til dette formålet vil vi bruke gratis program Bat To Exe Converter. Jeg foreslår at du laster ned den russifiserte versjonen fra lenken eller på den offisielle nettsiden til programmet. Programmet er selvforklarende. Ved inngangen legger vi bat-filen vår på utgangen får vi en exe-fil.
7. Vi setter på automatisk start
Gjenstår å gjøre siste steg... La oss lage automatisk start programmer sammen med systemoppstart. Linux og Windows gjør dette annerledes.
Vi logger på systemet på vegne av administratoren og flytter vår kjørbare file.exe til PogramFiles-mappen. Finn mappen i brukerens hjemmekatalog Hovedmeny, i det Programmer, Auto Start hvor vi plasserer snarveien fra programmet vårt (dette kan gjøres ved å dra selve programmet med med Shift-tasten). Klar.
La oss legge den kjørbare filen i mappen / usr / bin... La oss redigere lanseringsfilen lokale applikasjoner systemer /etc/rc.local ved å legge til en linje før utgang 0.
/usr/bin/script.sh
hvor script.sh Er navnet på filen vår.
Dette fullfører systemoppsettet. Du kan gå til Rejector-tjenesten og konfigurere nettverksdriftsmodusen.
Kivshenko Alexey, 1880
Denne artikkelen gir en oversikt fem alternativer for å løse problemet med å organisere tilgang til tjenester bedriftsnettverk fra Internett. Gjennomgangen gir en analyse av alternativer for sikkerhet og gjennomførbarhet, som vil bidra til å forstå essensen av problemet, oppdatere og systematisere kunnskapen deres for både nybegynnere og mer erfarne. Materialene i artikkelen kan brukes til å underbygge designbeslutningene dine.
Når du vurderer alternativer, ta nettverket der du vil publisere som eksempel:
- Bedriftspostserver (web-post).
- Bedrift terminalserver(RDP).
- Ekstranetttjeneste for entreprenører (Web-API).
Alternativ 1. Flatt nettverk
I denne varianten er alle noder i bedriftsnettverket inneholdt i ett felles nettverk for alle ("Internt nettverk"), innenfor hvilket kommunikasjon mellom dem ikke er begrenset. Nettverket er koblet til Internett gjennom en edge-ruter/brannmur (heretter - IFW).Tilgang av noder til Internett utføres gjennom NAT, og tilgang til tjenester fra Internett gjennom Port forwarding.
Fordeler med alternativet:
- Minimumskrav til funksjonalitet IFW(kan gjøres på nesten alle, til og med en hjemmeruter).
- Minimumskrav til kunnskapen til spesialisten som implementerer opsjonen.
- Minimumsnivået for sikkerhet. I tilfelle et brudd, der inntrengeren får kontroll over en av serverne publisert på Internett, blir alle andre noder og kommunikasjonskanaler i bedriftsnettverket tilgjengelige for ham for ytterligere angrep.
Et slikt nettverk kan sammenlignes med en bedrift hvor ansatte og kunder er i ett fellesrom (åpent rom)
hrmaximum.ru
Alternativ 2. DMZ
For å eliminere den tidligere nevnte ulempen, er nettverksnoder tilgjengelig fra Internett plassert i et spesielt dedikert segment - den demilitariserte sonen (DMZ). DMZ er organisert ved hjelp av brannmurer som skiller den fra Internett ( IFW) og fra internt nettverk (DFW).
I dette tilfellet er reglene for filtrering av brannmurer som følger:
- Fra det interne nettverket kan du starte tilkoblinger til DMZ og til WAN ( Bredt område Nettverk).
- Du kan starte tilkoblinger til WAN fra DMZ.
- Fra WAN kan du starte tilkoblinger til DMZ.
- Det er forbudt å starte tilkoblinger fra WAN og DMZ til det interne nettverket.
Fordeler med alternativet:
- Økt nettverkssikkerhet mot hacking individuelle tjenester... Selv om en av serverne er kompromittert, vil ikke inntrengeren kunne få tilgang til ressurser som ligger på det interne nettverket (f.eks. nettverksskrivere, videoovervåkingssystemer osv.).
- Å flytte servere til DMZ alene øker ikke sikkerheten deres.
- En ekstra ME er nødvendig for å skille DMZ fra det interne nettverket.
Denne varianten av nettverksarkitekturen ligner organiseringen av arbeids- og klientområdene i en bedrift, hvor klienter kun kan lokaliseres i klientområdet, og personalet kan være både i klient- og arbeidsområdet. DMZ-segmentet er nøyaktig analogen til klientsonen.
autobam.ru
Alternativ 3. Separasjon av tjenester i Front-End og Back-End
Som nevnt tidligere, forbedrer ikke sikkerheten til selve tjenesten å plassere en server i DMZ på noen måte. Et av alternativene for å rette opp situasjonen er å dele tjenestefunksjonaliteten i to deler: Front-End og Back-End. Dessuten er hver del plassert på en separat server, mellom hvilken nettverksinteraksjon er organisert. Front-End-servere som implementerer funksjonaliteten til å samhandle med klienter på Internett er plassert i DMZ, og Back-End-servere som implementerer resten av funksjonaliteten blir stående i det interne nettverket. For interaksjon mellom dem på DFW lage regler for å tillate initiering av front-end til back-end-tilkoblinger.
Som et eksempel, vurder en bedrift Posttjeneste betjene klienter både fra nettverket og fra Internett. Klienter fra innsiden bruker POP3 / SMTP, mens klienter fra Internett bruker et webgrensesnitt. Vanligvis, på implementeringsstadiet, velger bedrifter den enkleste måten å distribuere en tjeneste på og plasserer alle komponentene på én server. Etter hvert som behovet for å sikre informasjonssikkerhet realiseres, deles funksjonaliteten til tjenesten inn i deler, og den delen som er ansvarlig for å betjene klienter fra Internett (Front-End) overføres til en egen server som samhandler over nettverket med serveren som implementerer den gjenværende funksjonaliteten (Back -End). I dette tilfellet plasseres Front-Enden i DMZ, mens Back-Enden forblir i det interne segmentet. For kommunikasjon mellom Front-End og Back-End på DFW opprette en regel som tillater initiering av tilkoblinger fra front-end til back-end.
Fordeler med alternativet:
- Generelt kan angrep rettet mot den beskyttede tjenesten "snuble" over Front-Enden, noe som vil nøytralisere eller redusere mulig skade betydelig. For eksempel vil angrep som TCP SYN Flood eller langsom http-lesing rettet mot en tjeneste føre til at Front-End-serveren ikke er tilgjengelig, mens Back-Enden vil fortsette å fungere normalt og betjene brukere.
- Generelt kan det hende at Back-End-serveren ikke har tilgang til Internett, som i tilfelle hacking (for eksempel lokalt kjører ondsinnet kode) vil komplisere fjernkontroll jeg er fra internett.
- Front-End er bra å plassere på den brannmur applikasjonslag (for eksempel nettapplikasjonsbrannmur) eller inntrengingsforebyggende system (IPS, for eksempel snort).
- For kommunikasjon mellom Front-End og Back-End på DFW det opprettes en regel som gjør det mulig å starte en tilkobling fra DMZ til det interne nettverket, noe som skaper trusler knyttet til bruk av av denne regelen fra andre noder i DMZ (for eksempel ved å implementere IP-spoofing-angrep, ARP-forgiftning, etc.)
- Ikke alle tjenester kan deles inn i Front-End og Back-End.
- Virksomheten skal implementere forretningsprosesser for oppdatering av reglene brannmur.
- Selskapet må implementere beskyttelsesmekanismer mot angrep fra inntrengere som får tilgang til serveren i DMZ.
- V det virkelige liv selv uten å dele servere inn i Front-End og Back-End, trenger servere fra DMZ svært ofte tilgang til servere som ligger i det interne nettverket, så de indikerte ulempene dette alternativet vil også være gyldig for det tidligere vurderte alternativet.
- Hvis vi vurderer beskyttelsen av applikasjoner som kjører gjennom nettgrensesnittet, vil bruken av http omvendt, selv om serveren ikke støtter separasjonen av funksjoner mellom front-end og back-end. proxy-server(for eksempel nginx) som en Front-End vil minimere risikoen forbundet med tjenestenektangrep. For eksempel kan SYN flomangrep gjøre http omvendt proxy utilgjengelig mens Back-End fortsetter å fungere.
Dette alternativet ligner i hovedsak på en arbeidsorganisasjon der assisterende sekretærer brukes for høyt belastede arbeidere. Da vil Back-End være en analog av en lastet ansatt, og Front-End vil være en analog av en sekretær.
mln.kz
Alternativ 4. Sikret DMZ
DMZ er den delen av nettverket som er tilgjengelig fra Internett, og som et resultat har høyest risiko for vertskompromittering. Utformingen av DMZ og tilnærmingene som brukes i den skal gi maksimal overlevelse under forhold når inntrengeren fikk kontroll over en av nodene i DMZ. Som mulige angrep, la oss vurdere angrep som er mottakelige for nesten alle Informasjonssystemer arbeider med standardinnstillinger:Beskyttelse mot DHCP-relaterte angrep
Til tross for at DHCP er designet for å automatisere konfigurasjonen av IP-adresser til arbeidsstasjoner, er det i noen selskaper tilfeller når IP-adresser for servere utstedes via DHCP, men dette er en ganske dårlig praksis. Derfor, for å beskytte mot Rogue DHCP Server, DHCP-sulting, anbefales det å deaktivere DHCP fullstendig i DMZ.Beskyttelse mot MAC flomangrep
For å beskytte mot MAC-flom, konfigurer bryterportene for å begrense maksimal intensitet kringkaste trafikk(siden disse angrepene vanligvis genererer kringkastingstrafikk). Angrep relatert til bruk av spesifikke (unicast) nettverksadresser vil bli blokkert av MAC-filtrering, som vi dekket tidligere.Beskyttelse mot UDP-flomangrep
Forsvar fra av denne typen angrep utføres på samme måte som MAC flombeskyttelse, bortsett fra at filtrering utføres ved IP (L3) laget.Beskyttelse mot TCP SYN flomangrep
For å beskytte mot dette angrepet er følgende alternativer mulig:- Vertsbeskyttelse med TCP SYN Cookie-teknologi.
- Brannmurbeskyttelse (forutsatt at DMZ er undernett) ved å begrense mengden trafikk som inneholder TCP SYN-forespørsler.
Beskyttelse mot angrep på nettverkstjenester og webapplikasjoner
Det er ingen universell løsning på dette problemet, men det er veletablert praksis å implementere programvaresårbarhetshåndteringsprosesser (identifikasjon, patching, etc., for eksempel), samt bruk av inntrengningsdeteksjons- og forebyggingssystemer (IDS / IPS).Beskyttelse mot autentiseringsbypass-angrep
Som i forrige tilfelle one-stop løsning det er ikke noe slikt problem.Vanligvis i saken et stort antall mislykkede forsøk autorisasjonskontoer, for å unngå å gjette, er autentiseringsdata (for eksempel et passord) blokkert. Men denne tilnærmingen er ganske kontroversiell, og her er hvorfor.
For det første kan inntrengeren brute-force autentiseringsinformasjon med en intensitet som ikke fører til blokkering av kontoer (det er tilfeller der et passord ble brute-force innen flere måneder med et intervall på flere titalls minutter mellom forsøkene).
For det andre, denne funksjonen kan brukes til tjenestenektangrep der inntrengeren vil utføre bevisst et stort nummer av autorisasjonsforsøk for å blokkere kontoer.
Mest effektivt alternativ fra angrep av denne klassen vil bruke IDS / IPS-systemer, som, ved oppdagelse av forsøk på brute-force passord, ikke vil blokkere regnskap, og kilden fra hvor gitt utvalg skjer (blokker for eksempel IP-adressen til inntrengeren).
Den endelige listen over beskyttelsestiltak for dette alternativet:
- DMZ er delt inn i IP-undernett basert på et separat undernett for hver vert.
- IP-adresser tildeles manuelt av administratorer. DHCP brukes ikke.
- På nettverksgrensesnitt som DMZ-vertene er koblet til, MAC- og IP-filtrering er aktivert, begrensninger på intensiteten av kringkastingstrafikk og trafikk som inneholder TCP SYN-forespørsler.
- Auto-forhandling av porttyper er deaktivert på bryterne, bruk av innebygd VLAN er forbudt.
- TCP SYN-informasjonskapselen er konfigurert på DMZ-verter og servere på det interne nettverket som disse vertene kobles til.
- Sårbarhetshåndtering implementeres på DMZ-vertene (og gjerne resten av nettverket).
- Inntrengningsdeteksjons- og forebyggingssystemer IDS / IPS implementeres i DMZ-segmentet.
- Høy grad av sikkerhet.
- Økte krav til utstyrets funksjonalitet.
- Arbeidskostnader i implementering og støtte.
Hvis vi tidligere sammenlignet DMZ med et klientområde utstyrt med sofaer og ottomaner, vil en beskyttet DMZ se mer ut som en pansret kasse.
valmax.com.ua
Alternativ 5. Koble tilbake
Beskyttelsestiltakene som ble vurdert i forrige versjon var basert på det faktum at nettverket hadde en enhet (switch / ruter / brannmur) som var i stand til å implementere dem. Men i praksis, for eksempel ved bruk virtuell infrastruktur(virtuelle brytere har ofte veldig begrensede muligheter), kan det hende at en slik enhet ikke eksisterer.Under disse forholdene blir mange av de tidligere vurderte angrepene tilgjengelige for inntrengeren, hvorav de farligste vil være:
- angrep som gjør det mulig å avskjære og endre trafikk (ARP-forgiftning, CAM-tabelloverløp + TCP-øktkapring, etc.);
- angrep relatert til utnyttelse av sårbarheter på interne nettverksservere, som du kan starte tilkoblinger til fra DMZ (som er mulig ved å omgå filtreringsregler DFW på grunn av IP- og MAC-spoofing).
Dermed står vi overfor oppgaven med å beskytte serverne til det interne nettverket mot angrep fra inntrengeren både fra DMZ og fra det interne nettverket (infeksjon av den automatiserte arbeidsplassen med en trojaner kan tolkes som handlingene til inntrengeren fra det interne nettverket).
Tilnærmingen foreslått nedenfor er rettet mot å redusere antall kanaler som inntrengeren kan angripe servere gjennom, og det er minst to slike kanaler. Den første er regelen om DFW, som gir tilgang til serveren på det interne nettverket fra DMZ (selv med begrensede IP-adresser), og den andre er åpen på serveren nettverksport hvor tilkoblingsforespørsler forventes.
Du kan lukke disse kanalene hvis den interne nettverksserveren selv bygger tilkoblinger til serveren i DMZ og vil gjøre dette ved å bruke kryptografisk beskyttet nettverksprotokoller... Da blir det nei åpen port, ingen regler om DFW.
Men problemet er at vanlige servertjenester ikke kan fungere på denne måten, og for å implementere denne tilnærmingen må du bruke nettverkstunneling, implementert for eksempel ved bruk av SSH eller VPN, og allerede innenfor tunnelene tillate tilkoblinger fra serveren i DMZ. til serveren på det interne nettverket ...
Generell ordning arbeidet med dette alternativet er som følger:
- En SSH/VPN-server er installert på en server i DMZ, og en SSH/VPN-klient er installert på en server i det interne nettverket.
- Den interne nettverksserveren starter byggingen av nettverkstunnelen til serveren i DMZ. Tunnelen er bygget med gjensidig autentisering av klient og server.
- Serveren fra DMZ, innenfor rammen av den konstruerte tunnelen, initierer en tilkobling til serveren i det interne nettverket, gjennom hvilken de beskyttede dataene overføres.
- En lokal brannmur er konfigurert på den interne nettverksserveren for å filtrere trafikk som går gjennom tunnelen.
Å bruke dette alternativet i praksis har vist at det er praktisk å bygge nettverkstunneler ved hjelp av OpenVPN, siden det har følgende viktige egenskaper:
- Kryssplattform. Du kan organisere kommunikasjon på servere med forskjellige operativsystemer.
- Evne til å bygge tunneler med gjensidig klient- og serverautentisering.
- Evnen til å bruke sertifisert kryptografi.
Fordeler med alternativet:
- Arkitektonisk reduksjon av antall angrepsvektorer på den beskyttede serveren til det interne nettverket.
- Sikre sikkerhet i fravær av filtrering av nettverkstrafikk.
- Beskytter data som overføres over nettverket mot uautorisert visning og modifikasjon.
- Evnen til selektivt å øke sikkerhetsnivået til tjenestene.
- Muligheten for å implementere et to-krets beskyttelsessystem, der den første kretsen er gitt ved hjelp av brannmur, og den andre er organisert på grunnlag av dette alternativet.
- Implementering og vedlikehold av dette beskyttelsesalternativet krever ekstra arbeidskostnader.
- Inkompatibilitet med nettverkssystemer Intrusion Detection and Prevention (IDS / IPS).
- Ekstra databelastning på servere.
Hovedbetydningen av dette alternativet er at en betrodd person etablerer en forbindelse med en ikke-betrodd person, som ligner på en situasjon når bankene selv ringer tilbake en potensiell låntaker for å verifisere dataene ved utstedelse av lån.
Skoleportalen støtter internettilgangskontroll.
Håndteringen utføres gjennom integrasjon med Squid proxy-serveren.
For å endre tilgangsrettigheter, gå til menyen: Tjeneste → Internett-tilgang ....
Denne handlingen er kun tilgjengelig for representanter for skoleadministrasjonen.
For å gi tilgang til Internett er det nok å merke av i boksen ved siden av brukernavnet (elev, lærer), eller hele klassen. For å tilbakekalle tilgang må du fjerne merket i boksen. Endringer tas i bruk etter å ha klikket på "Lagre"-knappen.
For å lage bilen inn lokalt nettverk tilgang til Internett, veiledet av adgangen som er konfigurert i portalen, må du konfigurere den til å bruke en proxy-server.
Proxyserveradressen er adressen til skoleserveren din på det lokale nettverket der skoleportalen er installert. Proxy-serverport - 3128 .
Når en bruker får tilgang til Internett via en proxy-server, vil brukernavnet og passordet fra Skoleportalen bli bedt om.
For på en pålitelig måte å forhindre at Internett-tilgang omgår proxy-serveren, er det verdt å sjekke at skoleserveren ikke gir ruting til Internett for maskinene av interesse, og også at maskinene ikke har tilgang gjennom en svitsj, modem, ruter, Wi- Fi og annet utstyr til en utdanningsinstitusjon som ansatte og studenter har nettverkstilgang til.
Innholdsfiltreringssystemer (SCF)
Både fravær av SCF og integrasjon med flere leverandører støttes.
GFR-innstillingen er plassert i venstre kolonne på siden for Internett-tilgangskontroll.
Noen SCF-er krever registrering for å administrere forbudte ressurslister (f.eks. sosiale nettverk, obskønt materiale, samling av abstrakter, etc.). Endringer i slike innstillinger gjøres i nettgrensesnittene på selve SCF-nettstedet, og ikke i portalen. Tjenesteleverandøren til SCF gir støtte til brukere om kvaliteten på filtrering. Portalen aktiverer og deaktiverer bare retningen for spørringer til SCF DNS-servere fra skolens proxy-server og ingenting mer.
GFR, på samme måte som Internett-tilgang, gjelder bare for maskiner som er strengt konfigurert gjennom en skoleproxy-server.
Viktig! Etter slått på må SCF sjekkes i henhold til dine forventninger, siden portalen ikke kan sjekke dette automatisk for deg. SCFs vilkår og betingelser kan endres av deres produsenter når som helst. Det er verdt å abonnere på nyhetene om tjenesten du bruker.
Hva skal jeg gjøre hvis portalen viser inskripsjonen "Funksjon deaktivert" eller noe ikke fungerer.
Kontrollene og handlingene i denne delen av artikkelen er kun gitt for Ubuntu server 10,04 LTS:
Alle handlinger må utføres som root-bruker.
1. Er blekksprut installert?
Dpkg -s squid3 | grep -i versjon
Hvis ikke, installer:
Apt-get install squid3
2. Er disse parameterne i konfigurasjonsfil Portal?
Auth = grunnleggende htpasswd = / var / www / sp_htpasswd sp_users_allowed = / var / www / sp_users_allowed
Hvis ikke, legg til og utfør
Pkill raskt
3. Kjører blekksprut? Lytter du på port 3128?
Undersøkelse:
Netstat -ntlp | grep 3128
Svaret bør være noe sånt som følgende (1234 for eksempel, du kan ha et annet prosessnummer):
Tcp 0 0 0.0.0.0:3128 0.0.0.0:* LYTT 1234 / (blekksprut)
Slik starter du Squid:
/etc/init.d/squid3 start
* Starte Squid HTTP Proxy 3.0 squid3
4. Sett Squid til autorun:
Update-rc.d squid3 aktivere
5. Opprett, hvis ikke, og angi tilgangsrettighetene til tjenestefilene som er ansvarlige for administrasjon fra portalsiden:
Trykk på / var / www / sp_htpasswd / var / www / sp_users_allowed chown www-data.proxy / var / www / sp_htpasswd / var / www / sp_users_allowed chmod 660 / var / www / sp_htpasswd / var / www / sp_users_allowed
6. Ut av esken Squid-konfigurasjonsfilen er ikke klar for integrering, den må justeres.
Først, sørg for at det IKKE er portalintegrasjon i den (flere rettelser er ikke tillatt):
Grep "School Portal Internet Control" /etc/squid3/squid.conf
Hvis linjen fra utførelsen av kommandoen ovenfor vises, bør dette trinnet hoppes over.
Men hvis konfigurasjonsfilen har blitt endret på en slik måte at linjen er der, og integrasjonen ikke fungerer, ta original fil config fra Squid og følg dette trinnet over det.
Så hvis linjene er NEI:
6.1. Fjerning av regler som hindrer integrasjon og endring av feilsider til russiske versjoner:
Perl -i-original -p -e "s! ^ Http_access nekte alle $! # Http_access nekte alle !; s! ^ # Error_directory / usr / share / squid3 / errors / templates $! Error_directory / usr / share / squid-langpack /ru!;" /etc/squid3/squid.conf
6.2. Vi introduserer et fragment av integrasjonen:
Ekko "# =============================== # Skoleportal Internettkontroll # For å deaktivere erstatte /etc/squid3/squid.conf med /etc/squid3/squid.conf-original # ============================= auth_param grunnleggende program / usr / lib / squid3 / ncsa_auth / var / www / sp_htpasswd auth_param basic barn 5 auth_param basic realm Squid proxy-caching webserver auth_param basic credentialsttl 2 timer auth_param basic casesensitive på acl sp_users_allowed proxy_auth "/ var / www / splow_auth." > /etcsquisquid.d.
Hvis en slik blokk vises mer enn én gang i squid.conf-filen, fjern repetisjonene, selv om alt fungerer. Med gjentakelsen av Squid, hver gang opptakslisten oppdateres fra portalen, vil den sende advarsler om regeloverstyringer til loggen sin.
6.3. Etter å ha gjort endringene, må Squid startes på nytt.
/etc/init.d/squid3 restart
7. Deretter bruker du nettgrensesnittet til Skoleportalen for å distribuere Internett-tilgang. Du bør observere endringen i listen over tillatte brukerpålogginger til portalen i filen / var / www / sp_users_allowed etter å ha klikket på "Bruk"-knappen i portalens nettgrensesnitt.
Squid-tilgangslogger (/ var / log / squid3) vil inneholde påloggingene til portalbrukerne. Alle logganalysatorer som er kompatible med Squid-loggformatet kan brukes. Integrasjon med portalen bryter ikke med standard loggformat, forskjellen er at det er pålogginger fra portalen på plass, der det vil være en strek i fravær av brukerautorisasjon.
8. Sjekk om brannmuren blokkerer tilkoblinger på skolens server og på klientmaskiner. Som standard, på en ren Ubuntu-server, tillater brannmuren alle tilkoblinger, hvis du har tuklet med konfigurasjonen på noen måte, sørg for at tilkoblinger fra skolens lokale nettverk til port 3128 på serveren er tillatt og utgående tilkoblinger fra serveren.
