Alvorens de authenticatie van netwerkgebruikers te bespreken, is het noodzakelijk om regels te ontwikkelen voor het controleren van netwerktoegang. Netwerken zijn niet langer monolithische objecten. In de meeste gevallen is er één extern toegangspunt - een internetverbinding via een ISP ( Internetprovider- internetprovider). Regels voor netwerktoegangscontrole bepalen welke beveiliging moet worden geïnstalleerd op de toegangspunten tot het netwerk.

Poorten

Poorten zijn de punten waarop netwerk verkeer worden overgedragen van het netwerk van de organisatie naar een ander netwerk. Voor gateway-punten moeten de regels voor toegangscontrole rekening houden met de aard van het netwerk waarin de bridge wordt geïnstalleerd.

• Regels voor toegangscontrole voor inkomende en uitgaande telefoongesprekken (Dial-in en Dial-out)... Omvat authenticatievereisten. Het is vrij moeilijk om het inbeltoegangspunt voor het netwerk te verbergen. Daarom is het belangrijk om controles voor deze toegang te definiëren. Er zijn veel overwegingen met betrekking tot toegangsregels, zoals het maken van modems uitsluitend om uitgaande signalen te verwerken ( alleen uitgaand) voor uitbellen. Het is noodzakelijk om een ​​clausule van de regels te schrijven die het gebruik van de juiste controles zal voorschrijven.

  Alle telefoontoegang tot het netwerk moet worden beveiligd met sterke authenticatiecontroles. Modems moeten worden geconfigureerd voor een van de inbel- of uitbeltoegangen, maar nooit voor beide. De netwerkbeheerder moet procedures voorzien voor gegarandeerde toegang tot modemsystemen. Gebruikers mogen geen modems installeren op andere punten van het netwerk, volgens de toepasselijke sancties.

• Andere externe verbindingen... Mogelijk verschillende verbindingen van buiten de organisatie naar het netwerk. De regels kunnen directe toegang van clients tot het netwerk bepalen via een virtuele prive netwerk VPN(Virtual Private Network) en via de netwerkextensies van een organisatie die bekend staan ​​als extranetten.
• internetverbinding... Verschilt van andere verbindingen doordat mensen openbare toegang tot internet willen, terwijl de diensten van de organisatie toestemming voor toegang verlenen. De regels voor deze verbindingen worden besproken in hoofdstuk 6, Regels voor internetbeveiliging.

Zoals bij elke regel, kunt u verzoeken verwachten om de regels voor toegangscontrole te wijzigen. Ongeacht de redenen voor de aanpassing van de regels, moet het mogelijk zijn om uitzonderingen op de regels in te voeren via het regelherzieningsmechanisme. Indien conform het beleid een veiligheidsmanagementcommissie is ingesteld (zie hoofdstuk 3 Verantwoordelijkheden op het gebied van: informatiebeveiliging"), kan de commissie worden verplicht de regels te herzien.

Elke gateway die wordt voorgesteld voor installatie op het netwerk van een bedrijf als het waarschijnlijk in strijd is met het beleid of de procedures die door dit beleid worden voorgeschreven, mag niet worden geïnstalleerd zonder voorafgaande goedkeuring van het Security Management Committee.

Virtuele privénetwerken en extranetten

De toename van het aantal netwerken in een organisatie maakt het noodzakelijk om te zoeken naar nieuwe mogelijkheden om externe kantoren, klanten met elkaar te verbinden en de toegang tot servicecontractanten of potentiële contractanten te vereenvoudigen. Deze groei heeft twee soorten voortgebracht: externe verbindingen: virtuele privénetwerken ( VPN- Virtual Private Network) en extranetten. VPN zijn goedkope manier installeren informatielink: tussen twee of meer afdelingen van de organisatie die zich in verschillende territoria bevinden. Organisaties creëren een VPN door alle afdelingen met internet te verbinden en apparaten te installeren die informatie coderen en decoderen in beide afdelingen die met elkaar communiceren. Voor gebruikers ziet het werken via een VPN eruit alsof beide afdelingen zich op hetzelfde territorium bevinden en in één netwerk werken.

Autorisatiecontrole van hulpsystemen

Voordat u verder gaat, is het belangrijk om te onthouden dat elk van de gateways of elk hulpsysteem het toegangspunt is tot het netwerk van de organisatie. Op elk punt van binnenkomst moeten de inloggegevens van de gegevensstroom die het netwerk binnenkomt en verlaat op de een of andere manier worden geverifieerd. Een van de problemen waarmee rekening moet worden gehouden, is de vereiste van autorisatie van externe verbindingen met de hulpsystemen van het netwerk. Dit kan een probleem zijn voor hulpsystemen die permanent op het netwerk zijn aangesloten. Voor dergelijke ondersteunende systemen moet worden bepaald hoe hun aanwezigheid op het netwerk wordt geautoriseerd. Zelfs tijdelijke netwerkverbindingen, zoals inkomende modemverbindingen, kunnen zelfs strenge authenticatievereisten hebben.

In deze sectie hoeven de regels voor authenticatievereisten niet te worden beschreven - ze worden besproken in de volgende sectie, "Aanmeldingsbeveiliging". Hier kunnen we alleen de noodzaak van authenticatievereisten opmerken. De regels met betrekking tot authenticatiestandaarden worden in de volgende sectie besproken. Om er echter voor te zorgen dat het probleem van authenticatie voor aangesloten systemen wordt opgelost, is de clausule van de regels voor: poorten u kunt het volgende toevoegen.

De toepassingen die nodig zijn om de gateways te laten functioneren, moeten op het netwerk zijn geverifieerd. Als de applicatie zelf niet kan worden geauthenticeerd, dan zijn de authenticatieregels beschreven in dit document moeten van toepassing zijn op hulpsystemen die via gateways zijn aangesloten.

Records: 4

Toegangscontrole op afstand (ouderlijk toezicht)

Deze handleiding beschrijft het proces van het configureren van computers met besturingssystemen. Windows-familie XP, 7 of Linux (Ubuntu) voor afstandsbediening van toegang tot internetsites.

De handleiding beschrijft niet in detail de methoden om met de Rejector-service te werken, die hieronder zal worden besproken, het stelt u alleen in staat uw computer zo te configureren dat deze ten volle kan profiteren van zijn mogelijkheden.

Alle gebruikte tools behoren tot het aanbod van gratis of open source software.

Invoering

Het internet is een geweldig hulpmiddel om te leren, te ontspannen of te chatten met vrienden. Maar ook op het net bruikbare informatie, is er ook onwenselijk voor uw kind. Bovendien kan urenlang internetten de aandacht afleiden van andere belangrijke activiteiten zoals huiswerk, sporten, slapen of socializen met leeftijdsgenoten. Daarom is het noodzakelijk om de activiteiten van het kind op internet te volgen.

Er zijn veel verschillende controlemethoden, maar ze zijn niet altijd effectief. Overredings- en leerzame gesprekken kunnen maar heel kort duren, omdat het op het netwerk zitten een kind zo kan boeien dat het alle overtuigingskracht vergeet. En verboden kunnen een negatieve invloed hebben op de ontwikkeling van nuttige zoek- en leervaardigheden op internet.

In dergelijke gevallen wordt u geholpen speciale programma's om de toegang tot het netwerk te beperken en te controleren. Hiermee kunt u uw kind beschermen tegen: negatieve invloeden Het internet, maar geeft tegelijkertijd vrijheid van handelen. Een voorbeeld van zo'n tool is de Internet Access Control System Rejector.

Rejector is een gecentraliseerd project voor internettoegangscontrole. Hiermee kunt u kinderen en adolescenten beschermen tegen gevaarlijke informatie. In wezen is Rejector een DNS-server met de mogelijkheid om deze op afstand te beheren.

Hoe het werkt?

U registreert, voegt uw IP's toe, configureert toegangsparameters. U kunt de service gebruiken zonder registratie, maar dan kunt u niet alle functies gebruiken.

Uw computers zijn zo geconfigureerd dat alles DNS-query's werden verzonden naar de DNS-servers van Rejector 95.154.128.32 en 176.9.118.232.

Elk verzoek wordt gecontroleerd op naleving van uw instellingen, zoals verboden categorieën of sites, toegestane of verboden sites, bladwijzerlijsten of frauduleuze sites, en als de blokkering wordt bevestigd, wordt het verzoek doorgestuurd naar de verbodspagina.

U kunt deze pagina naar eigen wens aanpassen.

Toegestane verzoeken die de validatie hebben doorstaan, gaan naar de gedeelde cache voor verzoeken voor snelle levering aan alle clients.

Meer gedetailleerde beschrijving U kunt het Rejector-product vinden op de officiële website rejector.ru

Instructies voor systeemconfiguratie

1. Laten we een gebruiker met normale rechten maken

Meestal wordt bij het installeren van het besturingssysteem een ​​gebruiker met beheerdersrechten gemaakt. Zo'n gebruiker kan alles produceren mogelijke acties geleverd door het besturingssysteem in het vlees vóór de verwijdering van het systeem zelf.

Om de omkeerbaarheid van al onze verdere actie van de kant van de gebruiker over wie we de controle overnemen, zullen we een gebruiker met beperkte rechten maken en voor de beheerder zullen we een wachtwoord gebruiken.

V Windows-systeem dit gebeurt via het Configuratiescherm; v Linux creatie gebruiker is toegankelijk via Systeeminstellingen.

2. Laten we een netwerkverbinding opzetten

Rejector is een service die in wezen een DNS-server is. Om ermee te werken, moet u eerst configureren netwerkverbinding zodat DNS-query's worden verzonden naar de DNS-servers 95.154.128.32 en 176.9.118.232 van de Rejector.

Windows en Linux doen dit anders.

Windows XP

Windows Vista

Gedetailleerde instructies zijn te vinden op:

Windows 7

Gedetailleerde instructies zijn te vinden op:

Op de meeste besturingssystemen Linux-familie het programma wordt gebruikt om het netwerk te configureren Netwerkmanager... Ga als volgt te werk om de DNS-server te wijzigen:

Druk op RMB op de verbindingsindicator en, in contextmenu, selecteer het item Verbinding wijzigen

Als u gebruik maakt van DHCP server wanneer we verbinding maken met internet, veranderen we in de IPv4-parameters Instelmethode: Aan Automatisch (DHCP, alleen adres)

In veld DNS-servers voer twee adressen in, gescheiden door komma's 95.154.128.32, 176.8.118.232

Verbinding maken Beschikbaar voor alle gebruikers en Automatisch inplugbaar

3. Registreer u op de Rejector-website

Dit zou in principe het uitgangspunt kunnen zijn. Maar nu, wanneer een van de moeilijkheden voorbij is, doen we het gemakkelijk en eenvoudig. Volg de link en vul in makkelijke vorm voor registratie.

4. Voeg een beheerd netwerk toe

Door ons te registreren op de service, kunnen we het vereiste aantal netwerken creëren of, wat in principe hetzelfde is, de klanten die we zullen beheren. Netwerken (klanten) worden op de service geïdentificeerd aan de hand van hun IP-adres. Om de toegang tot internet van een computer te beheren, moet u daarom het IP-adres weten. Laten we voor nu gewoon een netwerk maken via het Configuratiescherm op de Rejector-website op.

Vul het formulier Netwerk toevoegen in. Netwerknaam - hier kunt u de naam van uw kind invullen als hij een eigen computer heeft en u hem wilt besturen. Toestand- hoogstwaarschijnlijk heb je Dynamisch IP-adres(een zeldzame provider wijst toe) Statisch adres gratis), dus we selecteren dit keuzerondje. Netwerk identificatie- u kunt de naam die u hebt opgegeven in het eerste veld in het Latijn noteren.

5. Het IP-adres verzenden

Om de service te laten werken, moet deze constant het IP-adres van de klant "kennen", dat kan variëren van verbinding tot verbinding (dynamisch IP-adres). Dit is het belangrijkste probleem dat in deze zelfstudie wordt behandeld.

De serviceontwikkelaars bieden zelf het programma Rejector Agent aan, dat het IP-adres van de klant naar de server stuurt. Maar dit programma kan niet autonoom werken. Daarom zullen we een nieuwe kans grijpen. Namelijk - bijwerken met behulp van een HTTP-verzoek (beschrijving via link).

Om de Client-informatie via een HTTP-verzoek op de achtergrond bij te werken, hebben we het Curl-programma nodig. Dit programma kan via de opdrachtregel HTTP-casts naar internet sturen. We zullen de parameters voor dit programma in het script instellen; voor Windows zou dit een bash-bestand zijn voor Linux - sh.

Curl is gratis en heeft een Windows-versie, dus we zullen het in beide omgevingen gebruiken. Voor Windows nieuwste de versie van het programma kan worden gedownload via de link. Om te installeren, pakt u gewoon de inhoud van het resulterende archief uit in de map C: \ WINDOWS \ SYSTEM32 (dit vereenvoudigt de lancering van het programma). V besturingssysteem in de Linux-familie zal het waarschijnlijk al zijn geïnstalleerd.

6. Script voor het regelmatig bijwerken van het IP-adres

De site stelt het volgende HTTP-verzoek voor: http: // gebruikersnaam: [e-mail beveiligd]/ nee ...,
waarmee de waarde van het IP-adres wordt bijgewerkt. We zullen het als een parameter aan het curl-programma leveren.

Het verzoek om het adres bij te werken, moet worden verzonden vanaf de computer die we willen controleren. Omdat de tekstterminal opdrachten op een speciale manier verwerkt, moest de verzoektekst enigszins worden gewijzigd. Het script voor Windows en Linux wordt hieronder weergegeven.

Voor ramen

: lus
krul "http: // login %% 40mail-server.com:wachtwoord@ updates.rejector.ru / nic / update? hostnaam = net-naam"
# Maak een vertraging van 300 seconden
ping -n 300 127.0.0.1> NUL
echo 111
ga naar lus

Waar login %% 40mail-server.com van jou is postbus, met behulp waarvan zij zich hebben geregistreerd op de Rejector (het @-teken wordt vervangen door %% 40); wachtwoord - wachtwoord; net-name - de naam van het netwerk op de Rejector-service. Plaats de scripttekst in een normale tekstbestand, vervang de extensie door .bat en je hebt een uitvoerbaar script.

Voor Linux

#! / usr / bin / sh
terwijl waar; doe krul -u [e-mail beveiligd]: wachtwoord "http: //updates.rejector.ru/nic/update? hostnaam = ... slaap 300; klaar;

Alles is hier hetzelfde als voor Windows. Schrijf deze tekst naar een tekstbestand met de extensie sh.

Beide scripts bevatten het wachtwoord voor het Rejector-account in open formulier, dus het is noodzakelijk om hun inhoud te verbergen voor weergave voor gewone gebruiker... Linux en Windows implementeren dit anders.

Om het bekijken en bewerken van dit door ons gemaakte bestand te verbieden, moet u de eigenaar en groep van het bestand wijzigen om te rooten en iedereen behalve de eigenaar de toegang tot het bestand ontzeggen. Als je de vaardigheden hebt om in te werken opdrachtregel dan moet je gaan met het commando CD naar de map met het scriptbestand en voer het commando uit chown root: root skcript.sh en chmod 700 script.sh. Om hetzelfde te doen in grafische shell, moet u eerst de bestandsbeheerder starten met beheerdersrechten, het scriptbestand zoeken en wijzigen rechten, met behulp van het contextmenu.

Zonder in te gaan op hoe je de bestandsrechten kunt wijzigen zoals in Linux, heb ik de volgende oplossing toegepast. Laten we ons uitvoerbare bestand naar een EXE-bestand converteren om de inhoud ervan te verbergen. Voor dit doel gebruiken we gratis programma Bat naar Exe-converter. Ik raad aan om de Russified-versie te downloaden via de link of op de officiële website van het programma. Het programma wijst zich vanzelf. Bij de input zetten we ons bat-bestand en bij de output krijgen we een exe-bestand.

7. We zetten de automatische start aan

Over om te doen laatste stap... Laten we maken automatische start programma's samen met het opstarten van het systeem. Linux en Windows doen dit anders.

We loggen in op het systeem namens de beheerder en verplaatsen ons uitvoerbare bestand.exe naar de map PogramFiles. Zoek de map in de thuismap van de gebruiker Hoofdmenu, in het Programma's, Automatische start waar we de snelkoppeling van ons programma plaatsen (dit kan worden gedaan door het programma zelf te slepen met de met de Shift-toets). Klaar.

Laten we het uitvoerbare bestand in de map plaatsen / usr / bin... Laten we het startbestand bewerken lokale toepassingen systemen /etc/rc.local door een regel ervoor toe te voegen uitgang 0.

/usr/bin/script.sh

waar script.sh Is de naam van ons bestand.

Hiermee is de systeemconfiguratie voltooid. U kunt naar de Rejector-service gaan en de netwerkmodus configureren.

Kivshenko Alexey, 1880

Dit artikel geeft een overzicht vijf opties voor het oplossen van het probleem van het organiseren van toegang tot services bedrijfsnetwerk van het internet. De beoordeling biedt een analyse van opties voor veiligheid en haalbaarheid, die zal helpen om de essentie van het probleem te begrijpen, hun kennis op te frissen en te systematiseren voor zowel beginnende specialisten als meer ervaren specialisten. De materialen van het artikel kunnen worden gebruikt om uw ontwerpbeslissingen te onderbouwen.

Neem bij het overwegen van opties het netwerk waar je wilt publiceren als voorbeeld:

1. Zakelijke mailserver (webmail).
2. Zakelijk terminalserver(RDP).
3. Extranetdienst voor aannemers (Web-API).

Optie 1. Platte netwerk

In deze variant zijn alle knooppunten van het bedrijfsnetwerk opgenomen in één gemeenschappelijk netwerk voor iedereen ("Intern netwerk"), waarbinnen de communicatie tussen hen niet beperkt is. Het netwerk is verbonden met internet via een edge-router / firewall (hierna - IFW).

Toegang van knooppunten tot internet wordt uitgevoerd via NAT en toegang tot services vanaf internet via Port forwarding.

Voordelen van de optie:

1. Minimale vereisten voor functionaliteit IFW(kan worden gedaan op bijna elke, zelfs een thuisrouter).
2. Minimale eisen aan de kennis van de specialist die de optie implementeert.

Nadelen van de optie:

1. Het minimale beveiligingsniveau. In het geval van een inbreuk, waarbij de Indringer controle krijgt over een van de op internet gepubliceerde servers, komen alle andere knooppunten en communicatiekanalen van het bedrijfsnetwerk voor hem beschikbaar voor verdere aanvallen.

Analogie uit het echte leven
Zo'n netwerk is te vergelijken met een bedrijf waar personeel en klanten in één gemeenschappelijke ruimte (open ruimte) zitten


hrmaximum.ru

Optie 2. DMZ

Om het eerder genoemde nadeel te elimineren, worden netwerkknooppunten die toegankelijk zijn via internet in een speciaal daarvoor bestemd segment geplaatst - de gedemilitariseerde zone (DMZ). De DMZ is georganiseerd met behulp van firewalls die hem scheiden van internet ( IFW) en van intern netwerk (DFW).


In dit geval zijn de regels voor het filteren van firewalls als volgt:

1. Vanuit het interne netwerk kunt u verbindingen tot stand brengen met de DMZ en het WAN ( Groot gebied Netwerk).
2. U kunt verbindingen met het WAN starten vanuit de DMZ.
3. Vanuit het WAN kunt u verbindingen met de DMZ tot stand brengen.
4. Het initiëren van verbindingen van het WAN en DMZ naar het interne netwerk is verboden.

Voordelen van de optie:

1. Verhoogde netwerkbeveiliging tegen hacking individuele diensten... Zelfs als een van de servers is gecompromitteerd, heeft de indringer geen toegang tot bronnen op het interne netwerk (bijvoorbeeld netwerkprinters, videobewakingssystemen, enz.).

Nadelen van de optie:

1. Het verplaatsen van servers naar de DMZ alleen verhoogt hun veiligheid niet.
2. Er is een extra ME nodig om de DMZ van het interne netwerk te scheiden.

Analogie uit het echte leven
Deze variant van de netwerkarchitectuur is vergelijkbaar met de organisatie van het werk- en klantgebied in een bedrijf, waar klanten zich alleen in het klantgebied kunnen bevinden en het personeel zich zowel in het klant- als werkgebied kan bevinden. Het DMZ-segment is precies het analoog van de klantenzone.


autobam.ru

Optie 3. Scheiding van services in Front-End en Back-End

Zoals eerder opgemerkt, verbetert het plaatsen van een server in de DMZ op geen enkele manier de beveiliging van de service zelf. Een van de opties om de situatie te corrigeren is om de servicefunctionaliteit in twee delen te splitsen: Front-End en Back-End. Bovendien staat elk onderdeel op een aparte server, waartussen netwerkinteractie wordt georganiseerd. Front-end-servers die de functionaliteit van interactie met clients op internet implementeren, worden in de DMZ geplaatst en de back-end-servers die de rest van de functionaliteit implementeren, blijven in het interne netwerk. Voor interactie tussen hen op DFW maak regels om het starten van front-end naar back-end verbindingen mogelijk te maken.

Denk bijvoorbeeld aan een corporate Postdienst klanten bedienen zowel vanuit het netwerk als vanaf internet. Clients van binnenuit gebruiken POP3 / SMTP, terwijl clients van internet een webinterface gebruiken. Meestal kiezen bedrijven in de implementatiefase de eenvoudigste manier om een ​​service te implementeren en alle componenten ervan op één server te plaatsen. Vervolgens, als de noodzaak om informatiebeveiliging te waarborgen wordt gerealiseerd, wordt de functionaliteit van de service opgedeeld in delen en wordt het deel dat verantwoordelijk is voor het bedienen van clients vanaf internet (Front-End) overgebracht naar een aparte server die via het netwerk communiceert met de server die de resterende functionaliteit implementeert (Back-End). In dit geval wordt de Front-End in de DMZ geplaatst en blijft de Back-End in het interne segment. Voor communicatie tussen Front-End en Back-End aan DFW maak een regel die het starten van verbindingen van front-end naar back-end mogelijk maakt.

Voordelen van de optie:

1. Over het algemeen kunnen aanvallen gericht tegen de beveiligde service over de Front-End "struikelen", waardoor mogelijke schade wordt geneutraliseerd of aanzienlijk verminderd. Aanvallen zoals TCP SYN Flood of trage http-leesacties gericht op een service zullen er bijvoorbeeld voor zorgen dat de Front-End-server niet beschikbaar is, terwijl de Back-End normaal blijft functioneren en gebruikers van dienst is.
2. Over het algemeen heeft de Back-End-server mogelijk geen toegang tot internet, wat in geval van hacking (bijvoorbeeld lokaal draaien kwaadaardige code) maakt het moeilijk afstandsbediening ben van internet.
3. Front-end is goed om erop te plaatsen firewall applicatielaag (bijvoorbeeld een webapplicatie-firewall) of een inbraakpreventiesysteem (IPS, bijvoorbeeld snort).

Nadelen van de optie:

1. Voor communicatie tussen Front-End en Back-End aan DFW er wordt een regel gemaakt waarmee een verbinding kan worden gemaakt van de DMZ naar het interne netwerk, wat bedreigingen veroorzaakt met betrekking tot het gebruik van van deze regel van andere knooppunten in de DMZ (bijvoorbeeld door IP-spoofing-aanvallen, ARP-vergiftiging, enz.)
2. Niet alle diensten zijn onder te verdelen in Front-End en Back-End.
3. Het bedrijf moet bedrijfsprocessen implementeren voor het bijwerken van de regels firewall.
4. Het bedrijf moet beschermingsmechanismen implementeren tegen aanvallen van indringers die toegang krijgen tot de server in de DMZ.

Notities (bewerken)

1. V echte leven zelfs zonder servers te verdelen in Front-End en Back-End servers van de DMZ, is het heel vaak nodig om toegang te krijgen tot servers die zich in het interne netwerk bevinden, vandaar de aangegeven nadelen deze optie geldt ook voor de eerder overwogen optie.
2. Als we kijken naar de bescherming van applicaties die via de webinterface werken, zelfs als de server de scheiding van functies tussen de front-end en back-end niet ondersteunt, kan het gebruik van http reverse proxy server(bijvoorbeeld nginx) als front-end minimaliseert de risico's die gepaard gaan met denial-of-service-aanvallen. SYN-flood-aanvallen kunnen bijvoorbeeld de http reverse proxy niet beschikbaar maken terwijl de back-end blijft werken.

Analogie uit het echte leven
Deze optie is in wezen vergelijkbaar met een werkorganisatie waarin assistent-secretaresses worden gebruikt voor zwaarbelaste werknemers. Dan zal Back-End een analoog zijn van een beladen medewerker en Front-End een analoog van een secretaresse.


mln.kz

Optie 4. Beveiligde DMZ

De DMZ is het deel van het netwerk dat toegankelijk is vanaf internet en als gevolg daarvan het grootste risico loopt op host-compromis. Het ontwerp van de DMZ en de benaderingen die erin worden gebruikt, moeten maximale overlevingskansen bieden in omstandigheden waarin de indringer de controle kreeg over een van de knooppunten in de DMZ. Laten we als mogelijke aanvallen rekening houden met aanvallen die vatbaar zijn voor bijna alle Informatie Systemen werken met standaard instellingen:

Verdedigen tegen DHCP-aanvallen

Ondanks het feit dat DHCP is ontworpen om de configuratie van IP-adressen van werkstations te automatiseren, zijn er in sommige bedrijven gevallen waarin IP-adressen voor servers worden uitgegeven via DHCP, maar dit is nogal een slechte gewoonte. Daarom wordt het aanbevolen om DHCP in de DMZ volledig te deactiveren om te beschermen tegen Rogue DHCP Server, DHCP-uithongering.

Bescherming tegen MAC-overstromingsaanvallen

Om te beschermen tegen MAC-flood, zijn de switchpoorten geconfigureerd om de maximale intensiteit te beperken uitzendverkeer(aangezien deze aanvallen meestal broadcast-verkeer genereren). Aanvallen gerelateerd aan het gebruik van specifieke (unicast) netwerkadressen wordt geblokkeerd door MAC-filtering, die we eerder hebben besproken.

Bescherming tegen UDP-overstromingsaanvallen

verdediging van van dit type aanvallen worden op dezelfde manier uitgevoerd als MAC-overstromingsbeveiliging, behalve dat er wordt gefilterd op de IP-laag (L3).

Bescherming tegen TCP SYN-overstromingsaanvallen

Ter bescherming tegen deze aanval zijn de volgende opties mogelijk:

1. Hostbescherming met TCP SYN Cookie-technologie.
2. Firewall-beveiliging (ervan uitgaande dat de DMZ is gesubnetteerd) door de hoeveelheid verkeer te beperken dat TCP SYN-verzoeken bevat.

Bescherming tegen aanvallen op netwerkdiensten en webapplicaties

Er is geen universele oplossing voor dit probleem, maar het is een gevestigde praktijk om processen voor het beheer van softwarekwetsbaarheid te implementeren (bijvoorbeeld identificatie, patching, enz.), evenals het gebruik van inbraakdetectie- en preventiesystemen (IDS / IPS ).

Bescherming tegen aanvallen om authenticatiemiddelen te omzeilen

Zoals in het vorige geval one-stop-oplossing: zo'n probleem is er niet.
Meestal in het geval een groot aantal mislukte pogingen autorisatie-accounts, om te voorkomen dat authenticatiegegevens (bijvoorbeeld een wachtwoord) worden geraden, worden geblokkeerd. Maar deze benadering is nogal controversieel, en dit is waarom.
Ten eerste kan de indringer authenticatie-informatie brute forceren met een intensiteit die niet leidt tot het blokkeren van accounts (er zijn gevallen waarin een wachtwoord binnen enkele maanden brute force was met een interval van enkele tientallen minuten tussen pogingen).
Ten tweede, deze functie kan worden gebruikt voor denial-of-service-aanvallen waarbij de indringer opzettelijk zal plegen een groot aantal van autorisatiepogingen om accounts te blokkeren.
Meest effectieve optie van aanvallen van deze klasse zal IDS / IPS-systemen gebruiken die, bij detectie van pogingen om wachtwoorden brute kracht te geven, niet zullen blokkeren rekening, en de bron van waaruit gegeven selectie gebeurt (blokkeer bijvoorbeeld het IP-adres van de indringer).

De definitieve lijst met beschermende maatregelen voor deze optie:

1. De DMZ is verdeeld in IP-subnetten op basis van een afzonderlijk subnet voor elke host.
2. IP-adressen worden handmatig toegewezen door beheerders. DHCP wordt niet gebruikt.
3. Op Netwerk interfaces waarop de DMZ-hosts zijn aangesloten, MAC- en IP-filtering is geactiveerd, beperkingen op de intensiteit van broadcastverkeer en verkeer dat TCP SYN-verzoeken bevat.
4. Auto-negotiation van poorttypes is uitgeschakeld op de switches, het gebruik van native VLAN is verboden.
5. De TCP SYN Cookie is geconfigureerd op DMZ-hosts en servers op het interne netwerk waarmee deze hosts verbinding maken.
6. Kwetsbaarheidsbeheer wordt geïmplementeerd op de DMZ-hosts (en bij voorkeur de rest van het netwerk).
7. Inbraakdetectie- en preventiesystemen IDS / IPS worden geïmplementeerd in het DMZ-segment.

Voordelen van de optie:

1. Hoge mate van beveiliging.

Nadelen van de optie:

1. Verhoogde eisen aan de functionaliteit van de apparatuur.
2. Arbeidskosten bij implementatie en ondersteuning.

Analogie uit het echte leven
Als we DMZ eerder vergeleken met een klantenruimte uitgerust met banken en voetenbankjes, dan zal een beschermde DMZ meer op een gepantserde kassa lijken.


valmax.com.ua

Optie 5. Terug verbinden

De beschermingsmaatregelen die in de vorige versie werden overwogen, waren gebaseerd op het feit dat het netwerk een apparaat (switch / router / firewall) had dat in staat was om ze te implementeren. Maar in de praktijk, bijvoorbeeld bij het gebruik van virtuele infrastructuur(virtuele schakelaars hebben vaak zeer beperkte mogelijkheden), bestaat een dergelijk apparaat mogelijk niet.

Onder deze omstandigheden komen veel van de eerder overwogen aanvallen beschikbaar voor de indringer, waarvan de gevaarlijkste zijn:

• aanvallen die het mogelijk maken om verkeer te onderscheppen en te wijzigen (ARP-vergiftiging, CAM-tabeloverloop + kaping van TCP-sessies, enz.);
• aanvallen die verband houden met de exploitatie van kwetsbaarheden van interne netwerkservers waarmee verbindingen kunnen worden gestart vanuit de DMZ (wat mogelijk is door filterregels te omzeilen DFW vanwege IP- en MAC-spoofing).

De volgende belangrijke eigenschap, waar we eerder niet bij stilgestaan ​​hebben, maar die daardoor niet minder belangrijk wordt, is dat geautomatiseerde werkstations (AWP's) van gebruikers ook een bron kunnen zijn (bijvoorbeeld bij besmetting met virussen of Trojaanse paarden) van kwaadaardige impact op servers.

We staan ​​dus voor de taak om de servers van het interne netwerk te beschermen tegen de aanvallen van de indringer, zowel van de DMZ als van het interne netwerk (infectie van de geautomatiseerde werkplek met een Trojaans paard kan worden geïnterpreteerd als de acties van de indringer van het interne netwerk).

De hieronder voorgestelde aanpak is gericht op het verminderen van het aantal kanalen waarlangs de indringer servers kan aanvallen, en er zijn ten minste twee van dergelijke kanalen. De eerste is de regel op DFW, waardoor toegang tot de interne netwerkserver vanaf de DMZ mogelijk is (zelfs met beperkte IP-adressen), en de tweede is open op de server netwerkpoort: waarop verbindingsverzoeken worden verwacht.

U kunt deze kanalen sluiten als de interne netwerkserver zelf verbindingen opbouwt met de server in de DMZ en dit doet met cryptografisch beveiligde netwerkprotocollen... Dan zal er geen zijn open poort, geen regels op DFW.

Maar het probleem is dat gewone serverservices niet weten hoe ze op deze manier moeten werken, en om deze aanpak te implementeren, moet u netwerktunneling gebruiken, bijvoorbeeld geïmplementeerd met SSH of VPN, en al binnen de tunnels kunt u verbindingen van de server in de DMZ naar de server op het interne netwerk ...

Algemeen schema het werk van deze optie ziet er als volgt uit:

1. Een SSH/VPN-server wordt geïnstalleerd op een server in de DMZ, en een SSH/VPN-client wordt geïnstalleerd op een server in het interne netwerk.
2. De interne netwerkserver initieert het bouwen van de netwerktunnel naar de server in de DMZ. De tunnel is gebouwd met wederzijdse authenticatie van de client en server.
3. De server van de DMZ brengt in het kader van de aangelegde tunnel een verbinding tot stand met de server in het interne netwerk, via welke de beveiligde gegevens worden verzonden.
4. Op de interne netwerkserver is een lokale firewall geconfigureerd om het verkeer dat door de tunnel gaat te filteren.

Het gebruik van deze optie in de praktijk heeft aangetoond dat het handig is om netwerktunnels te bouwen met OpenVPN, aangezien het de volgende belangrijke eigenschappen heeft:

• Cross-platform. U kunt de communicatie organiseren op servers met verschillende besturingssystemen.
• Mogelijkheid om tunnels te bouwen met wederzijdse client- en serverauthenticatie.
• De mogelijkheid om gecertificeerde cryptografie te gebruiken.

Op het eerste gezicht lijkt het misschien dat dit schema onnodig ingewikkeld en dat, aangezien je nog steeds een lokale firewall op de interne netwerkserver moet installeren, het gemakkelijker is om de server van de DMZ, zoals gewoonlijk, zichzelf te laten verbinden met de interne netwerkserver, maar doe dit over een versleutelde verbinding. Deze optie zal inderdaad veel problemen oplossen, maar het zal niet het belangrijkste bieden: bescherming tegen aanvallen op de kwetsbaarheden van de interne netwerkserver, uitgevoerd door de firewall te omzeilen met behulp van IP- en MAC-spoofing.

Voordelen van de optie:

1. Architecturale vermindering van het aantal aanvalsvectoren op de beveiligde server van het interne netwerk.
2. Zorgen voor beveiliging bij afwezigheid van filterend netwerkverkeer.
3. Bescherming van gegevens die via het netwerk worden verzonden tegen onbevoegde weergave en wijziging.
4. Het vermogen om selectief het beveiligingsniveau van diensten te verhogen.
5. De mogelijkheid om een ​​​​beveiligingssysteem met twee circuits te implementeren, waarbij het eerste circuit wordt voorzien van firewalling en het tweede is georganiseerd op basis van deze optie.

Nadelen van de optie:

1. De implementatie en het onderhoud van deze beschermingsoptie vereist extra arbeidskosten.
2. Incompatibiliteit met netwerksystemen Inbraakdetectie en -preventie (IDS / IPS).
3. Extra rekenbelasting op de servers.

Analogie uit het echte leven
Het belangrijkste punt van deze optie is dat een vertrouwenspersoon een verbinding tot stand brengt met een niet-vertrouwde persoon, vergelijkbaar met een situatie waarin de banken bij het verstrekken van leningen zelf een potentiële lener terugbellen om de gegevens te verifiëren.

bedrijfsnetwerken

Tags toevoegen

Het schoolportaal ondersteunt internettoegangscontrole.

Beheer wordt uitgevoerd door integratie met de Squid-proxyserver.

Ga naar het menu om toegangsrechten te wijzigen: Dienst → Internettoegang ....

Deze actie is alleen beschikbaar voor vertegenwoordigers van de schooladministratie.

Om toegang tot internet te geven, volstaat het om het vakje naast de gebruikersnaam (leerling, docent) of de hele klas aan te vinken. Om de toegang in te trekken, moet u het vinkje weghalen. Wijzigingen worden toegepast nadat u op de knop "Opslaan" hebt geklikt.

Om de auto binnen te halen lokaal netwerk toegang hebt gekregen tot internet, geleid door de toegang die is geconfigureerd in de Portal, moet u deze configureren om een ​​proxyserver te gebruiken.

Het adres van de proxyserver is het adres van uw schoolserver op het lokale netwerk waar de schoolportal is geïnstalleerd. Proxyserverpoort - 3128 .

Wanneer een gebruiker toegang heeft tot internet via een proxyserver, wordt de gebruikersnaam en het wachtwoord van de schoolportal gevraagd.

Om op betrouwbare wijze te voorkomen dat internettoegang de proxyserver omzeilt, is het de moeite waard om te controleren of de schoolserver geen routering naar internet biedt voor de machines van belang, en ook dat de machines geen toegang hebben via een switch, modem, router, Wi- Fi en andere apparatuur van een onderwijsinstelling, waartoe medewerkers en studenten netwerktoegang hebben.

Contentfiltersystemen (SCF)

Zowel de afwezigheid van SCF als integratie met meerdere providers worden ondersteund.

De GFR-instelling staat in de linkerkolom van de pagina Internettoegangsbeheer.

Sommige SCF's vereisen registratie om lijsten met verboden middelen te beheren (bijvoorbeeld sociale netwerken, obscene materialen, abstracte collecties, enz.). Wijzigingen in deze instellingen worden aangebracht in de webinterfaces op de SCF-website zelf, en niet in de Portal. Gebruikersondersteuning met betrekking tot de filtratiekwaliteit wordt geleverd door de SCF-serviceorganisatie. De Portal schakelt alleen de richting van query's naar de SCF DNS-servers vanaf de proxyserver van de school in en uit en niets meer.

GFR is, net als internettoegang, alleen van toepassing op machines die strikt via een schoolproxyserver zijn geconfigureerd.

Belangrijk! Na het inschakelen moet SCF volgens uw verwachtingen worden gecontroleerd, aangezien de Portal dit niet automatisch voor u kan controleren. De algemene voorwaarden van SCF kunnen op elk moment door hun fabrikanten worden gewijzigd. Het is de moeite waard om je te abonneren op het nieuws van de dienst die je gebruikt.

Wat te doen als het portaal het opschrift "Functie uitgeschakeld" weergeeft of iets niet werkt.

De controles en acties in dit deel van het artikel zijn alleen bedoeld voor: Ubuntu-server 10.04 LTS:

Alle acties moeten worden uitgevoerd als de rootgebruiker.

1. Is inktvis geïnstalleerd?

Dpkg -s inktvis3 | grep -i versie

Zo niet, installeer dan:

Apt-get install squid3

2. Zijn deze parameters in config-bestand Portaal?

Auth = basis htpasswd = / var / www / sp_htpasswd sp_users_allowed = / var / www / sp_users_allowed

Zo niet, toevoegen en uitvoeren

Pkill snel

3. Loopt Squid? Luisteren op poort 3128?

Inspectie:

Netstat -ntlp | grep 3128

Het antwoord zou ongeveer als volgt moeten zijn (bijvoorbeeld 1234, u heeft mogelijk een ander procesnummer):

Tcp 0 0 0.0.0.0:3128 0.0.0.0:* LUISTER 1234 / (inktvis)

Hoe te beginnen met Inktvis:

/etc/init.d/squid3 start

* Squid HTTP Proxy 3.0 squid3 starten

4. Stel Squid in op autorun:

Update-rc.d squid3 inschakelen

5. Maak, zo niet, en stel de toegangsrechten in voor de servicebestanden die verantwoordelijk zijn voor het beheer vanaf de Portal-zijde:

Touch / 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. Out-of-the-box Squid-configuratiebestand is niet klaar voor integratie, het moet worden aangepast.

Zorg er eerst voor dat er GEEN portal-integratie in zit (meerdere fixes zijn niet toegestaan):

Grep "School Portal Internet Control" /etc/squid3/squid.conf

Als de regel uit de uitvoering van de bovenstaande opdracht wordt weergegeven, moet deze stap worden overgeslagen.

Als het configuratiebestand echter zodanig is gewijzigd dat de regel er is en de integratie niet werkt, neem dan origineel bestand config van Squid en volg deze stap erboven.

Dus, als de regels NIET zijn:

6.1. Regels verwijderen die integratie verhinderen en foutpagina's wijzigen naar Russische versies:

Perl -i-original -p -e "s! ^ Http_access deny all $! # Http_access deny all !; s! ^ # Error_directory / usr / share / squid3 / errors / templates $! Error_directory / usr / share / squid-langpack / ru !; " /etc/squid3/squid.conf

6.2. Introductie van een fragment van integratie:

Echo "# ============================= # School Portal Internet Control # Om uit te schakelen vervang /etc/squid3/squid.conf door /etc/squid3/squid.conf-original # =========================== auth_param basisprogramma / usr / lib / squid3 / ncsa_auth / var / www / sp_htpasswd auth_param basic children 5 auth_param basic realm Squid proxy-caching webserver auth_param basisreferentiesttl 2 uur auth_param basic hoofdlettergevoelig op acl sp_users_allowed proxy_auth "/ var / www / splow_auth." >3/squidsquid.

Als zo'n blok meer dan eens voorkomt in het squid.conf-bestand, verwijder dan de duplicaten, zelfs als alles werkt. Met de herhaling van Squid, zal elke keer dat de toelatingslijst wordt bijgewerkt vanuit de portal, waarschuwingen over regeloverschrijvingen naar zijn logboek worden verzonden.

6.3. Na het aanbrengen van de wijzigingen moet Squid opnieuw worden opgestart.

/etc/init.d/squid3 herstart

7. Gebruik vervolgens de webinterface van de School Portal om internettoegang te distribueren. U moet de wijziging in de lijst met toegestane gebruikersaanmeldingen van de portal in het bestand / var / www / sp_users_allowed observeren nadat u op de knop "Toepassen" in de webinterface van de portal hebt geklikt.

Squid-toegangslogboeken (/ var / log / squid3) bevatten de logins van de portalgebruikers. Alle log-analysers die compatibel zijn met het Squid-logformaat kunnen worden gebruikt. Integratie met de Portal schendt het standaard logformaat niet, het verschil is dat er logins van de portal aanwezig zijn, waar er een streepje zou zijn bij afwezigheid van gebruikersautorisatie.

8. Controleer of de firewall verbindingen op de schoolserver en op clientcomputers blokkeert. Standaard staat de firewall op een schone Ubuntu-server alle verbindingen toe, als je op welke manier dan ook met de configuratie hebt geknoeid, zorg er dan voor dat verbindingen van het lokale netwerk van de school naar poort 3128 van de server zijn toegestaan ​​en uitgaande verbindingen vanaf de server.