Site blog

Sida: 1 2 ()
Vem som helst (även för gäster)

DirectAccess har funnits i ett antal år, men numera är Microsoft på väg att flytta fokus mot Always On VPN. Teknikerna erbjuder båda en sömlös och transparant fjärrtillgång som alltid är tillgänglig. Always On VPN har ett antal fördelar över DirectAccess när det gäller säkerhet, autentisering, hantering och stödfunktioner.


Säkerhet

DirectAccess tillhandahåller full nätverksanslutning när klient fjärransluter. Funktionen saknar inbyggda funktioner för att kontrollera anslutning. Det finns en möjlighet att sätta restriktioner tillgång till externa resurser genom att sätta brandvägg mellan server för DirectAccess och lokalt nätverk, men denna policy kommer att appliceras på alla anslutna klienter.

Windows 10 Always On VPN finns funktioner för att finmaskigt filtrera trafik. Där Direct Access tillhandahåller tillgång till interna resurs vid anslutning, ger Always On VPN en möjlighet för administratörer att på olika sätt sätta restriktioner för anslutningar mot interna resurser. Filter kan appliceras baserat på användare eller grupper. Exempelvis kan användare på marknadsavdelning bara komma åt denna avdelnings servrar.

 

Autentisering och hantering

DirectAccess inkluderar stöd för stark autentisering av användare med smarta kort eller lösningar för One Time Password (OTP). Dock finns det ingen möjlighet att tilldela tillgång baserat på konfiguration av enhet eller hälsa, eftersom denna funktion har tagits bort i Windows Server 2016. Som tillägg kräver DirectAccess att både klient och server är ansluten till domän då konfiguration sätts genom group policy i Active Directory.

Windows 10 Always On VPN inkluderar stöd för “modern authentication and management”, vilket ger som resultat bättre säkerhet. Klienter som använder Always On VPN kan vara anslutna till domän i Azure Active Directory och villkorsbaserad tillgång kan användas. ”Modern authentication” stödjer även Azure MFA och Windows Hello for Business. Funktionen hanteras av lösning för Mobile Device Management (MDM) såsom Microsoft Intune.

 

Prestanda

DirectAccess använder IPsec med IPv6, som måste kapslas in i Transport Layer Security (TLS) för att routas över ett publikt IPv4 Internet. IPv6 trafik kommer att översättas till IPv4 av DirectAccess server. Prestanda för DirectAccess accepteras oftast om klienter har en anslutning till Internet som är pålitlig och med hög kvalite. Dock om anslutningen är dålig, kommer detta att innebära dålig prestanda eftersom det finns flera lager av inkapsling och översättning.

För Windows 10 Always On VPN används vanligvis IKEv2. Detta protokoll erbjuder den bästa säkerheten och prestanda när jämförelse sker med TLS-baserade protokoll görs. Som ett tillägg så bygger inte funktionen på samma sätt som DirectAccess på IPv6. Eftersom inte flera lager av inkappsling och översättning används, kommer prestanda alltid att bli bättre.

 

Stödfunktioner

DirectAccess är en lösning från Microsoft som måste installeras på server som använder sig av Windows och Active Directory. Funktionen kräver även Network Location Server (NLS) så att klienter kan räkna ut om de finns på ett lokalt nätverk eller inte. Tillgängligt för NLS är kritisk och att försäkra sig att funktionen är tillgänglig kan vara en utmaning speciellt för större organisationer.

Windows 10 Always On VPN stödjer infrastrukturer som är mindre komplexa än de för DirectAccess. Det finns inget krav för NLS, vilket innebär ett färre antal servrar att installera, hantera och monitorera. Som ett tillägg så är Always On VPN helt infrastrukturoberoende och kan installeras på tredjeparts VPN-servrar såsom Cisco, Checkpoint, SonicWALL, Palo Alto med flera.
 
Bild av Mats Johannesson
av Mats Johannesson - Tuesday, 7 May 2019, 11:42
Vem som helst (även för gäster)



Dokumentet beskriver hur du arbetar med Windows 10 Autopilot. Dokumentet utgår ifrån .easec:s kursmiljö med virtuell maskin som innehåller Windows 10 Enterprise Edition och att du har en prenumeration för Microsoft Intune.



[ Modifierad: Tuesday, 7 May 2019, 11:45 ]
 
Bild av Mats Johannesson
av Mats Johannesson - Monday, 29 April 2019, 11:10
Vem som helst (även för gäster)

Historik

Tidig dator ålder

På 60-talet var det inte så vanligt med datorer, då kostnaden för dessa var väldigt höga. Bara för att hyra en dator var kostnaden alldeles för höga för att de skulle vara vanliga för de flesta företagen.

Ett behov och att lösa detta behov är en drivkraft för utveckling, så också inom datorvärlden. De tidigaste datorerna vara dedicerade för en specifik arbetsuppgift och det kunde ta dagar, t om veckor att köra ett jobb. Detta ledde fram till utvecklingen av virtualisering. Utvecklingen leddes av tanken att kunna dela dators resurser  med många användare på samma gång.

När skapandet av centraliserad dator kom, så var detta de första tecknen på virtualisering. Under 60-talet var flera terminal ansluten till en större central dator vilket möjliggjorde att arbetet kunde utföras från en central plats. Att arbeta med en central plats för dator, gav möjlighet att från denna plats kontrollera all bearbetning från en central plats, om en terminal skulle sluta att fungera, kunde användare gå till en annan terminal och logga på denna för att fortsätta sitt arbete. Dock fanns det fortfarande några negativa sidor. Exempelvis om användare kraschade den centrala datorn, så gick systemet ner för alla användare. Detta ledde fram till datorer inte bara behöver kunna separera användare utan även processer som körs i systemet.


Virtualisering

1973 publicerade Gerald J. Popek och Robert P. Goldberg rapporten Formal Requirements for Virtualizable Third Generation Architectures, där de beskriver tre typer av virtualisering:

-         Type 0, där virtualisering görs direkt på hårdvara.

-         Type 1, där virtualiseringstekniken innehåller ett operativsystem.

-         Type 2, där virtualiseringstekniken kräver att det redan finns ett operativsystem.

Formal Reguirements for Virtualizable

Detta dokument ligger till grund för all virtualisering som företag och organisationer arbetar med idag och blir också, kan man säga, en delning mellan virtualisering och teknik för att särskilja applikationer eller tjänster.


chroot

1979 togs det ett annat steg med utvecklingen av kommandot chroot (change root). chroot används för att skapa en delad men isolerad miljö. Kommandot ger en möjlighet till att ändra root-miljö för en körandes process tillsammans med dess barn (children).

chroot

Detta gav en möjlighet att isolera systemprocesser till egna segregerade filsystem så att tester kunde utföras utan att påverka den globala miljön för systemet. I mars 1982 la Bill Joy till kommandot i den sjunde versionen av Unix.


Solaris Zones

2004 lanserades Solaris containers, Solaris containers skapar en full miljö för applikationen genom att använda Solaris Zones. Med zones får applikationen tillgång till användare, processer, filsystem och hårdvara på systemet. Dock kan applikationen bara se var som finns i sin egen zon.


jail

I syftet att förstå containers, får vi förflyttas oss framåt i tiden lite, till 1990-talet, när Bill Cheswick arbetade med att försöka förstå hur en cracker använde den tid som denna hade på sig i ett system. I sin undersökning byggde Cheswick en miljö som tillätt honom att analysera cracker:s tangentnedslagningar och för att lära sig dennes teknik. Hans lösning var att använda en miljö skapade av chroot och som var modifierad. Resultatet av Cheswick:s studier ledde fram till kommandon jail i Linux.

I mars 2000 (närmare bestämt 4 mars 2000), introducerade FreeBSD kommandot jail i sitt operativsystem. Även om kommandot liknande chroot så inkluderades ytterligare funktioner såsom möjlighet att isolera filsystem, användare, nätverk, etc. FreeBSD jail ger möjlighet till att tilldela IP-adress, konfigurera skräddarsydda mjukvaruinstallation och modifiering för varje miljö. Dock till en kostnad då funktionalitet för mjukvaran påverkades.


control groups (cgroups)

2006 lanserade ett antal utvecklare på Google process containers. Dessa var designade för isolering och begränsningar för resurnyttjande för process. 2007 döptes process container om till control groups (cgroups) för att undvika namnkollision med ordet containers.


LXC

2008 lades cgroups till i Linux kernel 2.6.24 och som i sin tur ledde till att projektet LXC startades. LXC står för Linux Containers och ger en möjlighet till virtualisering på operativsystemsnivå, genom att tillåta att ett antal isolerade Linuxbaserade miljöer (containers) körs på delad Linux kernel. En och var av dessa containers har sina egna processer och nätverk.


LMTCFY

2013 ändrade Google på konceptet containers, genom att göra sitt projekt Let Me Contain That For You (LMTCFY) till ett öppet projekt. Genom att använda LMTCFY, kunde applikationer skrivas för container och med möjlighet att skapa och hantera sina egna undercontainers. Arbetet på LMCTFY stoppades 2015 och Google beslöt att arbetet skulle läggas i projektet libcontainer, som Docker hade startat.

 

Start för Docker

"The technology was not accessible/useful for developers, containers were not portable between different environments, and there was no ecosystem or set of standard containers," Docker's chief executive Ben Golub.

Docker lanserades som ett open-source projekt 2013. Docker tillhandarhåller möjligheten att paketera containers så att de kan flyttas från en miljö till en annan. Från början använda Docker LXC-teknologien, men 2014 ersattes LXC med libcontainer, vilket ger en möjlighet för container att arbeta med Linux namespaces, libcontainer control groups, capabilities, säkerhetsprofiler i AppArmor, gränssnitt för nätverk och regelverk för brandvägg. Docker bidrar till community med globalt eller lokalt förråd kallat för registry, ett restful API och CLI-klient. Senare har även Docker implementerat hanteringssystem för kluster med namnet Docker Swarm och ett antal andra produkter för orkestrering.


.easec har ett stort antal kurser där du får lära dig allt om Docker och containers, se gärna vidare på https://portal.easec.se/moodle/course/index.php?categoryid=7






etiketter:
[ Modifierad: Monday, 29 April 2019, 11:12 ]
 
Vem som helst (även för gäster)



Gartner  förutspår att när vi når 2020, kommer mer än 50 % av de global organisationerna att produktions köra applikationer i containers, idag är det mindre än 20 % av dessa globala organisationer som kör containers i produktion. 

Enligt 451 Reseach var marknaden $762 miljoner förra året och kommer att öka 3.5 gånger till $2.7 billion är 2020. 


.easec tillsammans med Edument AB anordnar Docker Birthdayparty den 2 april 2019 i Malmö, välkommen du med och lär dig mer om detta. Både .easec och Edument AB har lång erfarenhet av Docker.

 
Bild av Mats Johannesson
av Mats Johannesson - Thursday, 7 March 2019, 09:28
Vem som helst (även för gäster)




Docker in Docker (DiD)

Det finns möjlighet att låta Docker container starta och köra en annan Docker container. Detta görs genom att köra en Docker Unix socket inuti en container. Socket är en endpoint på nätverket där information skickas mellan olika mjuvaror. Docker.sock är en Unix socket som ger möjlighet för Docker daemon, dockerd, att kommunicera med kommandoradsgränssnittet via REST API.

Socket blir som en fil, /var/run/docker.sock, eftersom det är en fil kan administratörer dela och köra docker.sock inuti container och använda den för att starta och kommunicera med denna. En container som kör docker.sock kan starta eller stoppa andra containers, skapa avspeglingar på värd eller skriva till värds filsystem.

Dock finns det några säkerhetsrisker med detta och det är viktigt att administratör är medveten om detta.

 

Risker med möjligheten

Docker.sock kommer att utöka attackytan för container och det kan bli ett sätt att kompromettera värd. Om en icke auktoriserad användare får tillgång till container som kör docker.sock, kommer hen att få rooträttigheter på värd och i Docker. Rootanvändare kan förändra värd och denna användare har även möjlighet att starta, stoppa eller exekvera vilket kommando i Docker som helst. Dessutom kan hen lyssna på eller ansluta till API, då denna person har tillgång till Docker socket.


Använda funktionen säkert

Detta bästa sättet att undvika dessa säkerhetsrisker, är att inte alls använda sig av docker socket. Men om organisationen måste använda sig av docker.sock, följ dessa rekommendationer:

  • Innan du monterar docker.sock till container, funderar på information som denna container kommer att dela eller innehålla – ju mer känslig information, desto högre säkerhetsrisk. Tilldela bara tillgång för container till den information som den behöver genom att använda docker.sock. Som minsta åtgärd, sätt information i container till endast read-only, eftersom detta kommer att förhindra ickeauktoriserad användare att ändra informationen. Denna åtgärd kommer dock inte att förhindra att denna användaren från root-rättigheter på värd.
  • För att sätta restriktioner på vad användare kan göra, slå på Transport Layer Security (TLS) eller använd sk authorization proxies. Docker kan också blockera tillgång till socket över http och tillhandahålla ytterligare funktioner för auktorisation och autentisering genom konfigurationer för rollbaserade rättigheter. Som ett tillägg kan du använda Docker Bench for Security, ett skript som automatiserar kontroll av container via riktlinjer från Center för Internet Security och rekommendationer för implementeringar av containers.


Alternativ för docker.sock

Det finns inte många direkta alternativ for funktionen, men genom att använda proxies kan säkerheten förhöjas.

HAProxy är en lastbalanserare för TCP och http som är öppen källkod. Administratörer kan sätta upp HAProxy för att lyssna på docker.sock och även för att stödja specificerade endpoints eller att ta bort  tillgången till docker.sock.

Ett annat alternativ är docker-proxy-acl, som är en Unix socket-proxy. Med denna produkt kan du låsa ner eller tillåta tillgång till endpoints och detta inkluderar containers, avspeglingar, volymer, händelser, arbetsuppgifter och nätverk. Docker-proxy-acl kan också förhindra att användare bygger egna Dockerfile där de kan lägga till instruktioner av misstänkt natur och på detta sätt få in dessa instruktioner i en avspegling som organisationen använder sig av.

 

Produkter som nämns i denna artikel:

Docker Bench Security: https://github.com/docker/docker-bench-security

HAProxy: http://www.haproxy.org/

docker-proxy-acl: https://github.com/titpetric/docker-proxy-acl



[ Modifierad: Thursday, 7 March 2019, 10:46 ]
 
Vem som helst (även för gäster)



Åtta principer för Continuous Delivery

 

1.     Process för release/produktionssättning måste kunna repeteras och måste vara pålitlig.

 

2.     Automatisera allting. Manuell produktionssättning kan aldrig beskrivas som repeterbar eller pålitlig.

 

3.     Om något är svårt eller jobbigt, gör det ofta. Om du gör något som är arbetsamt oftare, leder detta till att du troligtvis automatiserar det eller hittar dellösningar. Exempelvis tycker du det är arbetsamt att implementera schema för databas, brukar detta leda till att du inte gör detta så ofta. Det du egentligen skulle göra, är att göra detta en gång om dagen istället för kanske en gång i månaden.

 

4.     Ha allting i source control. Detta kanske låter lite konstigt idag. Och vem har inte allt i source control? Eller?

 

5.     Gjord, eller done, betyder släppt eller released. Detta handlar om ägandeskap för projektet, efter detta steg har ägandeskapet överförts till användare. En till utvecklarteam kontrollerar kontinuerligt funktion i produktion.

 

6.     Bygg in kvalitet! Ta tiden som krävs för att fundera på hur du kan mäta kvalitet för programkod. Projekt som har ett bra sätt att mäta kvalitet (unit test, sätt att koda, regelverk, mätning komplexitet) kommer att vara bättre än projekt som inte användare och dessutom långsiktigt vara lättare att underhålla.

 

7.     Alla har ett ansvar för processen för release. Ett program som körs på utvecklarens dator, kommer inte att generera pengar för företaget. På ett liknade sätt så kommer ett projekt utan någon plan för utrullning, att aldrig bli släppt och återigen kommer inga pengar in till företaget. Företag får in pengar när produkter släpps till kunder och därför skall processen vara av intresse för alla. Utvecklare skall utveckla sina projekt med tanke på hur utrullning skall ske. Projektledare skall planera projektet med tanke på utrullning. Testare skall förutom att testa själva programmet, lägga fokus på att testa utrullningen. Tester av den sistnämnda typen skall vara automatiserade och inbyggda i själva utrullningen.

8.     Förbättring – pågående process. Luta dig inte tillbaka och vänta på att ditt system kommer att bli gammalt och omöjligt att underhålla. Förbättringsprocessen pågår alltid och blir mycket lättare att genomför om du redan har tänkt på detta.

 

Dessa åtta principer leder till dessa fyra praxis:


1.     Bygg exekverbara filer endast en gång. Exekverbara filer skall lagras på en plats och denna plats skall endast vara nårbar av mekanism för utrullning.

 

2.     Använd exakt samma mekanism för utrullning till varje miljö.

 

3.     Testa din utrullning. Även om utrullningen har varit lyckad, behöver detta inte innebära att allting verkligen finns på plats. Skriv ett test som kontrollerar så att allting finns där det skall vara. Exempelvis jämför från en lista över filer så att dessa finns, eller jämför konfiguration utifrån en lista, i denna lista finns den förväntade konfigurationen, denna jämförs med hur det verkligen ser ut.

 

4.     Om något fallerar, stoppa allting! Ta bort utrullningen och starta om processen igen, patcha inte eller förändra någonting, istället gör du en rollback på utrullningen, fixa problemet på ett ordentligt sätt. Gör aldrig förändringar i ett system som lever! Inte ens om det är ont om tid. Detta leder alltid till en dålig kvalité på din programkod.


 
Bild av Mats Johannesson
av Mats Johannesson - Tuesday, 8 January 2019, 09:12
Vem som helst (även för gäster)

Orkestrering i Docker


Ny kurs från .easec, Orkestrering i Docker.

Två dagars kurs med följande innehåll:

Docker

Modulen ger bakgrundsinformation om Docker och kunskaper hur du installerar Docker.

Lektioner: Bakgrund, Docker bas och Arkitektur


Kommando

I denna modul får du lära dig användbara kommando för att arbeta med Docker och containers.

Lektioner: Kommando och Hantera container


Dockerfile

Dockerfile är en vital funktion för att skapa avspeglingar, men används även av många andra funktioner i Docker. I denna modul tittar vi på grunderna i Dockerfile.

Lektioner: Skapa avspegling och Dockerfile


Orkestrering

I denna modul tittar vi på Docker Compose, Docker Swarm, Docker Machine och Docker Cloud. Alla dessa är inbyggda verktyg för att hantera orkestrering av Docker. I modulen nämns även andra tredjepartstjänster.

Lektioner: Docker Compose, Docker Swarm och Docker Machine


Kubernetes

I denna modul tittar vi på och arbetar med Kubernetes.

Lektioner: Koncept och arkitektur, Deklarativ och imperativ, Nätverksmodell och Första kontakt med kubectl.


På utbildningscenter i Sverige eller via molnet!


 
Vem som helst (även för gäster)

Installera och konfigurera NAT med Windows PowerShell


PDF beskriver hur du använder Windows PowerShell för att installera och konfigurera NAT på Windows Server 2016 Core 1809.


PDF hittar du här: https://stordevsumj.blob.core.windows.net/easec/Konfigurera_router_pa_Windows_Server_Core.pdf

[ Modifierad: Friday, 4 January 2019, 14:18 ]
 
Bild av Mats Johannesson
av Mats Johannesson - Thursday, 3 January 2019, 12:49
Vem som helst (även för gäster)

Släktforskning


Det är ingen hemlighet att .easec gillar Docker, varför inte kombinera släktforskning med Docker? Pdf beskriver hur du tillverkar container i Docker med verktyget Webtrees. Webtrees är ett opensource projekt för släktforskning.


Vill du se hur det ser ut, gå till: http://famjohannesson.se . 


Hur jag har gjort, finns beskrivit här: https://stordevsumj.blob.core.windows.net/easec/Skapa_avspegling_for_Webtrees.pdf

[ Modifierad: Thursday, 3 January 2019, 12:52 ]
 
Bild av Mats Johannesson
av Mats Johannesson - Wednesday, 10 October 2018, 01:24
Vem som helst (även för gäster)

Promo


Denna nya kurs har fokus på Windows Server 2016/2019, men Linux finns med på ett hörn.


Direktlänk till kursen: https://portal.easec.se/moodle/enrol/index.php?id=19

[ Modifierad: Sunday, 14 October 2018, 11:46 ]
 
Sida: 1 2 ()

  
RSS