I själva verket är det här inget nytt. Inom IT säkerhets området kallas detta Social Engineering och har funnits sedan datorerna begynnelse, men då framför allt för att ta sig in i företags och myndigheternas system. Då tekniken blev bättre och bättre och datorer och nätverk blev bättre skyddade fanns det enklare sätt att komma åt och stjäla information än att försöka “hacka” sig in på nätverken. Genom att göra en detaljerad research om företagen och användarna var det helt enkelt enklare att ringa en användare eller ta sig fysiskt in på företagen och utge sig för att vara från helpdesk och fråga efter användarens inloggningsuppgifter.

Då tekniken och även användarmedvetenheten har blivit så mycket bättre även på  hemmaplan har det helt enkelt blivit svårare att sprida skadlig kod eller få en användare att klicka på en länk. Där emot är vi fortfarande för godtrogna och litar på en person som faktiskt ringer och erbjuder sin hjälp samtidigt som vi är lättskrämda då vi hör att datorn är smittad och den riskerar att bli obrukbar och alla privata foton och filmer riskerat att försvinna.

Några grunder som du som användare bör tänka på både privat och på jobbet:

1. Ge ALDRIG ut inloggningsuppgifter, oavsett vem som frågar efter dessa. Inloggningsuppgifter är personliga och det finns aldrig ett giltigt skäl till varför du skall lämna ut detta till någon annan oavsett på ditt arbete eller privat.

2. Klicka aldrig på en länk som du fått av en okänd avsändare eller som verkar suspekt. Rent krasst, du kan inte vara för misstänksam även fast du fått ett mail av din bästa vän så syna först att mailadresser ser korrekt ut och att det är rimlig information som avsändaren skickat
3. Ange aldrig dina inloggningsuppgifter på en webbsida som du inte känner igen eller över en okrypterad anslutning.  Känner du inte igen webbsidan eller programmet som frågar efter dina inloggningsuppgifter se till att alltid försäkra dig om att det är korrekt. Exempelvis logga in med ditt Facebook konto eller Live konto på en okänd hemsida eller över en http session, https är ett måste vid inloggning.
   Logga heller inte in från en okänd allmän dator på exempelvis ett internetcafé då det är stor risk att det finns “key loggers” som registrerar vad du skriver.
   Ett tips om du måste logga in från en allmän dator och vill minska risken för att ditt lösenord skall hamna i en keylogger: Skriv en lång textsträng i exempelvis notepad där fragment av ditt lösenord finns med och kopiera sedan ut rätt tecken och klistra in det i lösenordsfältet.

Andra sidor som skriver om det här bedrägeriförsöken är dels vår blogg på Onevinn
http://blogg.onevinn.se/

Min kollega Tom har även skrivit om detta och lagt ut två filmer med inspelningar från dessa samtal. Kan verkligen tipsa om den andra filmen där mottagaren driver med den som ringer och slutet på filmen är grymt roligt
http://itblogg.aafloen.se/

OTP metoder
Det finns flera tillvägagångssätt att ge användaren en engångskod (även kallat One-Time Password OTP). Det klassiska som man nyttjar till flera banktjänster med mera är hårdvarudosor, det här har även PointSharp, men jag kan tycka att det är lite bökigt att kräva att användaren skall ha med sig denna dosa. Det finns då några andra smart alternativ, dels finns en kort-dosa som är i samma storlek som ett bankkort/smartcard och får lätt plats i plånboken, kortet har en liten display och med hjälp av ett enkelt tryck generar den OTP koder. Ett annat alternativ är att använda telefonen som man ändå alltid har med sig. Här finns två alternativ, dels kan man få ett SMS skickat vid inloggning med en engångskod, dels finns det även OTP appar till i stort sett varenda telefonmodell vilket jag tycker är den smidigaste lösningen. Telefonen har man alltid med sig och man slipper kostnad för SMS eller eventuella fördröjningar.

Distribution av PointSharp app
Distribution av PointSharp appen är enkel från PointSharp Admin gränssnittet där man kan välja att skicka ut den via SMS eller E-post till valfri användare och det finns en dosa per mobilplattform. Användaren får då ett meddelande med en länk till appen från appstore/marketplace samt en personlig kod som knyter OTP dosan till användaren. Användaren kan även ta hem appen på egen hand för att i efterhand få en kod och knyta appen till användarkontot.

Inloggningsformulär
Som det ser ut i nuvarande PointSharpversion så finns det bara ett specialanpassat gränssnitt för inloggningsformulär med SMS. Om man använder annan OTP metod så nyttjar man standard inloggningsformulären som i exemplet nedan är Exchange OWA formuläret.
Här anger man sitt användarnamn och lösenord (vilket kan vara användarens AD lösenord alternativt ett unik PointSharplösenord) följt utav genererad OTP kod i samma lösenordsfält.

Naturligtvis kan man editera gränssnittet själv och förklara mer tydligt för användaren hur han skall ange kombinationen av lösenord och OTP.
Det finns även planer från PointSharp att komma med fler modifierade formulär för att kunna skilja på lösenord och OTP.

Det här är en perfekt metod för att höja säkerheten till de webbtjänster som du publicerar via TMG med en stark autentisering, som då innebär något användaren vet (lösenordet) samt något den har (dosan).

En fördel kan också vara att man har ett unikt lösenord via PointSharp för alla webbtjänster och ActiveSync för att på så sätt hindra att användaren anger sitt AD lösenord på främmande datorer så som Internet-Caféer och liknande.

Igår publicerades en rollup uppdatering till Forefront TMG Service Pack 2.

Det har dykt upp en del problem i och med Service Pack 2. Framför allt så är den här uppdateringen aktuell om du har problem med Reporting Services. Exempelvis om du får ett felmeddelande som “Subreport could not be shown” när du genererar en User Activity eller Site Activity rapport.

Notera att denna rollup uppdatering kräver att du har TMG Service Pack 2 installerad och den skall då installeras på samtliga TMG och även EMS om du har en större klustrad lösning. Observera också att alltid uppgradera eventuell EMS först och sedan den TMG som har reporting service-tjänsten för att sedan fortsätta installera på övriga array medlemmar. Den här uppdateringen kräver heller ingen omstart av servern.

Läs mer om uppdateringen och ladda hem den via kb2649961

Mitt nyårsfirande fick ett gott avslut då jag fick reda på att jag är tilldelad MVP (Most Valuable Professional) inom Microsoft Forefront ännu ett år!

Önskar alla läsare ett riktigt gott nytt 2012 där vi garanterat kommer få se många nya produkter och snygga säkerhetslösningar!

Det finns alltid risker med att ha för mycket information i dessa mobila enheter och det bästa är att kunna kontrollera exakt vilken information som skall få finnas på vilken enhet och för vilken användare.

Det finns flera bra plugins till både Forefront TMG och UAG. Vi har bland annat ett svenskt företag vid namn PointSharp vars plugin ger funktioner som flerfaktorautentisering och utökad säkerhet för Micrsosoft Exchange ActiveSync.

Till skillnad från flera andra tredjepartsprodukter så kräver inte den här någon som helst installation eller handpåläggning på själva klienten utan alla enheter som kan kommunicera med Exchange ActiveSync kommer fungera precis som vanligt, med undantag av några säkerhetsmässiga fördelar.

Med hjälp av PointSharp kan vi skapa ett separat lösenord som enbart används för ActiveSync, det här lösenordet kan vi spara i befintligt Active Directory så vi behöver ingen separat databas för detta ändamål.
En stor fördel är också att vi kan automatisera mycket av det här flödet och även ge användaren möjlighet att hantera sitt ActiveSynclösenord och sina mobila enheter på egen hand genom en självbetjäningsportal. Alternativet är också att en servicedeskorganisation behöver involveras för att godkänna nya enheter för att på så sätt få kontroll över vilka enheter som får synkronisera företagets information.
När användaren loggar in på självbetjäningsportal med sitt vanliga AD konto första gången autoskapas ett PointSharpkonto med motsvarande namn som användarkontot i ADt, användaren kan sedan själva autogenerera ett lösenord.

Med hjälp av PointSharps TMG Filter och en produkt som heter PointSharp Secure ActiveSync kan vi även sätta upp ett regelverk över vilka Exchange-funktioner som får synkroniseras ut till vilken typ av enhet. På det sättet kan vi säkerhetsklassa de enheter som finns i miljön och därefter sätta upp regler för att exempelvis en viss telefonmodell enbart får synkronisera mail och kalender men inga bifogade filer medans en viss typ av platta kan ta emot alla bifogade filer så länge det inte är ett säkerhetsklassat dokument.

Rent tekniskt bygger autentiseringstekniken på Kerberos Constrained Delegation (KCD) där TMG servern har rätt att delegera autentisering bak mot Exchange och då istället autentisera användaren med sitt PointSharpkonto.

Det här höjer säkerheten på flera plan. Dels så finns inte något AD-lösenord lagrat på telefonen och sedan finns det heller inte risk att felaktiga påloggningsförsök låser det riktiga AD-kontot. En snygg funktion för att inte själva PointSharpkontot skall bli utlåst av en felaktigt konfigurerad telefon är att den registrerar flera påloggningsförsök med samma lösenord som ett enda försök.

En annan säkerhetsaspekt på det hela är att all kontroll av vilka funktioner och vilken information som får synkroniseras ut till telefonerna baserat på telefonmodell och användare och kontrolleras redan på edge-nivå, innan någon som helst information når fram till Exchange.

Genom att integrera PointSharps lösning kan du även nyttja funktioner för att få flerfaktorautentisering mot både webbpubliceringar och VPN lösningar. Ett tänkbart scenario är att även autentisera Outlook Web App (OWA) med PointSharpkontot för att på så sätt undvika att ange ett AD-lösenord från ett Internetcafe.

Det här var bara exempel på några scenarier över hur man kan kombinera dessa produkter för att få en säkrare ActiveSynclösning. Det första man bör göra är att se till vilka verksamhetsbehov man har och vilken information man vill skydda och sedan anpassa den tekniska lösningen utefter de behov som finns. 

Nu finns det egentligen ingen anledning att avinstallera Service Pack till TMG, men i det här fallet gjordes det i en felsökning. Frågan är snarare, vad är det egentligen som hade hänt här när vi inte såg någon konfiguration?

Avinstallationen gjordes via Program and Features (snabbkommando appwiz.cpl) vilket är helt korrekt. Där emot uppstod ett problem då man inte längre kunde se array konfigurationen grafiskt längre. Det hela visade sig bero på att själva TMG programvaran hade avinstallerat SP1 och var tillbaka på RTM nivå men ADLDS databasen som tillhandahåller konfigurationen i sig var fortfarande på SP1 nivå.

Hur identifierades detta då?
För att identifiera vilken patch-nivå ADLDS databasen  har så öppnar du denna via ADSI EDIT där du ansluter med nedanstående uppgifter:

Där Connection Point är cn=fpc2 och “Computer” skall vara namnet på TMG servern följt av :2171 (såvida du inte ändrat default port.)

Gå sedan ner i strukturen till Array-Root och under CN=Arrays välj egenskaper på den du vill inspektera. Attributet msFPC=AdminMinorVersion visar vilken version du använder och om den skiljer sig från versionnumret på TMGn.

(I mitt fall demar jag exemplet från min labbmiljö där jag har en icke publik version)

Lösningen?
För att komma runt problemet var den absolut enklaste lösningen att helt enkelt få upp  TMGn till SP1 version igen vilket då gjorde att den kunde läsa in konfigurationen och visa den grafiskt på nytt.

Jag har inte testat detta, men det är högst sannolikt att samma fel skulle kunna uppstå på en UAG där man avinstallerar TMGns Service pack på samma sätt.

Slutsatsen blir också att man bör undvika att avinstallera service pack till TMG/UAG, (vilket i det här scenariot var en del av en annan felsökning)

FIX: Forefront Threat Management Gateway 2010 prematurely closes the connection to the web server when a web proxy client uploads data by using an SSL tunnel

En annan bra blogg-artikel kommer från två MVP kollegor som identifierade ett scenario efter TMG Service Pack 2 installation. Om man manuellt har raderat standard nätverksregeln “Internet Access”. Vid installation av SP2 återställs nämligen den här regeln vilket kan ge konstiga effekter om man exempelvis har valt att TMG skall routa trafik mot Internet.

Richard Hicks blogg

Så skall “jag lära dig allt jag kan” om TMG så är det bara att boka in en kurs. Naturligtvis kontrar man med “Nåja, det går väl ganska fort” vilket stämmer, kursen är planerad till tre dagar

http://www.cornerstone.se/sv/Om-Cornerstone/Instruktorer/Anders-Olsson/

Därför tänkte jag reda ut hur man hanterar interna nät och routing en gång för alla.

I både TMG och UAG får man specificera vilka nät som skall klassificeras som interna nät. Problematiken i det här har att göra med det saknas en intern gateway på det interna nätverkskortet då det enbart går att ha en default gateway och den skall alltid vara konfigurerad på det externa nätverkskortet. Det här gör att det krävs ett extra moment där man specificerar en route över hur TMG/UAG skall nå det här nätverket från det interna nätverkskortet.

Felmeddelandet ovan beskriver det här klart och tydligt. Det finns ett specificerat internt nät där det saknas routing från det interna nätverkskortet vilket då betyder att det är det externa nätverkskortets default gateway som då kommunicerar med detta subnät, vilket blir tokigt.

För att se till att de här uppgifterna alltid stämmer när man skall lägga till ett nytt nät finns det ett bra tillvägagångssätt att följa:

Steg 1.

Definiera routing till det nya nätet.
I tidigare ISA/IAG lösningar var man tvungen att använda “Route Add kommando” på varje ISA/IAG i exempelvis ett kluster men i TMG finns nu ett mer enkelt och användarvänligt sätt att hantera Steg 1 i detta tillvägagångsätt.

I TMG konsolen gå in under Networking och fliken Routing där du klickar på Create Network Topology
Definiera nät och subnät samt den gateway som är nåbar från det subnät som är specificerat på det interna nätverkskortet.

Tryck Apply och vänta någon minut så ändringarna slår igenom.
Det kommer nu läggas till en route för detta nät och är det en Enterpriselösning med flera TMG/UAG så sker detta på samtliga servrar med automatik.

Steg 2.

Se till att det nya nätet som du specificerat routing för också definieras som ett internt nät av TMG/UAG.
I TMG konsolen gå in under Networking och fliken Networks. Dubbelklicka på Internal Network och till fliken Addresses, välj Add Adapter..

Klicka på Internal  och klicka på Ok. Alla nät kommer nu läggas till under Internal Addresses.

Under Network adapter details i bilden ovan specificeras alla nät som är routade från det interna kortet.
Fördelen med det här tillvägagångssättet är att TMG själv bygger upp IP Adresslistan baserat på vilka nät som den kan routa till och på det sättet kommer konfigurationen alltid att fungera.

Observera att det kan komma en Alert om IP spoofing eller Configuration Error under tiden som steg 1 har genomförts då det finns routing för ett icke specificerat internt nät under den tidpunkten. Såvida steg 2 genomförs kan detta ignoreras.

Det som många missar är att du faktiskt kan nyttja Microsofts säkerhetslösningar i exempelvis Forefront för att supportera även övriga enheter.

En tydlig trend som vi ser just nu är att Microsoft satsar mer och mer på att supportera övriga enheter än sina egna. Ett exempel är senaste uppdatering till Forefront Unified Access Gateway (UAG) där vi fått utökad stöd för både Apples och Androids enheter (http://technet.microsoft.com/en-us/library/hh490321.aspx)

Jag har skrivit en artikel över hur du kan nyttja Microsofts teknik för att både supportera fler enheter i din infrastruktur men också för att skydda företagsinformation från icke managerade enheter.
Artikeln kan du läsa på Microsoft TechNet

Tillsammans med Michael Bohlin på Microsoft spelade vi även in en video om samma ämne

Klicka på bilden för att komma till videon