Bättre och säkrare lösenord i ditt AAD/AD

Även om Microsoft och många andra har kommit väldigt långt att med olika tekniker komma ifrån lösenordsinloggning kommer vi nog ha klassiska lösenord kvar ett antal år till.

Lösenord är dock något som de flesta användarna tycker är krångligt, tråkigt och mest av allt något onödigt ont som man bara måste ta sig igenom. Majoriteten av våra användare lägger nog ingen större vikt av att lösenordet Sommar2018! är ett svagt lösenord, bara de lyckas komma igenom alla svåra lösenordpolicys och sätta ett godkänt lösenord.

Som tur är har vi genom åren lärt oss mycket om lösenord och vilka krav som faktiskt höjer säkerheten på våra lösenord. Vi har även lärt oss vilka lösenordpolicys som faktiskt riskerar att sänka säkerheten på lösenord.

Klassiskt tänk som att vi bör byta vårat lösenord med jämna mellanrum har nu ersatts av att vi bör sätta ett lösenord vi kan och kommer ihåg utan några krav på att byta detta såvida det inte blivit läckt/knäckt.

Det vi har lärt oss av detta är ett kontinuerligt krav på lösenordsbyte ofta resulterar i att man lägger till och ändrar några siffror och specialtecken i samma lösenord. Exempelvis ”Sommar2017” enbart byts mot ”Sommar2018” eller kanske ”Sommar2018!” Det här är något som även är känd av de som gör intrång och om vi tittar på attackerna de senaste åren har det skett en klar ökning av så kallade spray attacks. Dessa går ut på att man bygger upp en lista på de vanligaste förekommande lösenorden exempelvis ”Password” med alla dess varianter ”P@$$w0rd!” och så vidare. För att ta sig runt lock out policys och andra skydd testar med dessa lösenord mot alla identifierade användarkonton på ett företag.
Det räcker då att ett användarkonto eller värsta fall ett administrator-konto har ett lösenord som man tidigare trodde var starkt, ex. “P@$$w0rd!” eller  “$0mM@r!” blir knäckt, så riskerar man ett fulländat intrång.

Som tur är, är det inte bara the bad guys som blir duktigare och mer erfarna. Microsoft lägger enormt mycket resurser på att identifiera hur attacker går till för att lära sig att bygga allt bättre skydd mot de rådande attackerna.

Det senaste runt lösenordsskydd är Password Protection som är en funktion i Azure Active Directory som ökar skyddet både i Azure Active Directory och lokala Active Directoryt.

Tjänsten består av flera skydd för att öka lösenordssäkerheten och blockera intrång baserat på lösenordsförsök.

Det ingår dels en lista med de vanligaste lösenorden så kallade banned password list. Denna lista är i skrivande stund snart uppe i 1000 lösenord. Alla olika kombinationer av dessa lösenord blockeras också, vilket gör att flera miljoner lösenord kommer blockeras.

Då lösenord ofta innehåller namnet på företaget, den lokala orten med mera kan man även komplettera den här listan och ange lösenord som ofta förekommer i sin egen organisation och som kan vara lätt även för den som attackerar organisationen att identifiera. Även olika kombinationer av dessa lösenord kommer blockeras som i exemplet nedan för företaget MSSEC och Company

  • Mssec, mssec2018!, M$$3C…
  • Company, company2017?, c0mMp@ny

Eller varför inte “Sommar”, “Vinter” m.m. om det är något som kanske tidigare användes av Service Desk när de återställde lösenord

clip_image001[4]

För att även lösenord som sätts eller byts i det lokala Active Directory:t skall få samma skydd finns en proxy och agent som installeras lokalt och knyts med våra domänkontrollanter. Dessa hämtar och applicerar samma inställningar som vi konfigurerat i vårat Azure AD.

clip_image001[6]

Det här resulterar i att när en användare försöker sätta någon av dessa lösenordskombinationer kommer detta att blockeras.

Både om användaren försöker sätta ett lösenord från listan i det lokala ADt som i exemplet nedan

clip_image001[8] clip_image001[10]

Alternativt om användaren ändra det via självbetjäningsportalen i Azure AD

clip_image001[12] clip_image001[14]

Förutom att Password Protection motverkar att vanliga lösenord konfigurerats innehåller den även en funktion, så kallad Smart lockout för att blockera lösenordsintrång utan att låsa ut den faktiska användaren.

Om det pågår inloggningsförsök som enligt avancerade algoritmer tolkas som intrångsförsök kommer dessa inloggningar att stoppas med den riktiga användaren kan fortsätta jobba helt ostört.

Den här funktionen har funnits i Azure AD en längre tid oavsett licensform, men tack vare det nya gränssnittet med Custom smart lockout kan vi nu även anpassa skyddet och konfigurera känsligheten för sin egen organisation.

Detta gör att Password Protection både stöttar dina användare att sätta bättre och säkrare lösenord som inte är lika lätta att gissa sig fram till, samtidigt som den blockerar felaktiga inloggningsförsök utan att störa användaren.

Annonser
Publicerat i Azure Active Directory | Märkt , , | Lämna en kommentar

Identifiera ett Secure Email-phishing försök

Tyvärr fortsätter phishing mail att öka och de blir allt duktigare på att kopiera officiella mailtjänster och utskick i ett ständigt försök att få mottagaren att klicka på en bifogad länk, och i många fall även få mottagaren att ange sitt användarnamn och lösenord.

Det har nu kommit phishing mail som försöker efterlikna Microsoft Secure Email / Office 365 Message Encryption vilket i flera fall har varit så gott som identiska med standardgränssnittet.

Jag vill med den här artikeln påvisa hur man kan särskilja på ett phishing mail och ett äkta Secure Email.

Phishing mail

Ett exempel på ett phishing mail där det är två väsentliga fel:

  1. När du håller musen över ”Read the Message” -länken ser du att den inte pekar inte på ”outlook.office365.com”
  2. Avsändaradressen som även skall redovisas i meddelandet matchar inte avsändaradressen

clip_image001

Ett äkta Secure Email

  1. ”Read the message”-länken pekar på outlook.office365.com
  2. Avsändaradressen är både korrekt och matchar avsändaradress i meddelandet

clip_image002

Ett äkta anpassat Secure Email

De bilder och text i ett Secure Email som beskrivs i denna artikel kan bytas ut. Här är det viktigt att informera och utbilda interna användare om organisationens design, både för interna användares skull, men även för att de skall kunna stötta externa mottagare och ha vetskap om upplevelsen när de skyddar epost externt.

Oavsett anpassad design skall motsvarande länk och avsändaradresser matcha enligt exemplet nedan.

clip_image003

Tekniskt skydd mot Phishing mail

Det är väldigt viktigt att oavsett tekniska skyddslösningar även utbilda slutanvändare att vara vaksamma på denna typ av hot.

Ett bra skydd mot bland annat phishing är Office 365 Advanced Threat Protection (ATP). Dess ATP Safe Link Protection funktion genomsöker och ersätter alla inkluderade länkar (bland annat för att skydda mot DNS-ompekningar som används för att i efterhand styra användaren till en skadlig websida)

Även om den här typen av lösning oftast stoppar användaren att komma till en skadlig websida går det att utläsa om det är ett phishing mail som i exemplet nedan:

clip_image004

Läs mer om hur Secure Email fungerar och i vilka scenarion som ett skyddad mail redovisas enligt ovan

Publicerat i Azure Information protection | Märkt , | 3 kommentarer

Nyheter i Secure Email och dess funktionalitet

Microsoft har kommit långt i sin resa att skydda epost och Office dokument utan att ställa några motkrav på mottagaren. Lösningen gör det enklare för våra svenska företag och myndigheter att möta de nya GDPR lagarna.

Historiskt sett har det varit stora utmaningar att nyttja Rights Management Services (RMS) för att skydda epost-meddelanden och andra filer till externa användare utanför sin egen organisation.

I ett RMS-scenario krävs följande för att kunna läsa något som är skyddat av denna lösning:

  1. Ett konto som kan autentisera sig mot avsändarens Azure Active Directory (eller Active Directory i ett AD RMS scenario)
  2. En applikation som stödjer RMS i form av dekryptering och applicering av de begränsade rättigheterna som definieras vid kryptering (Ex begränsa utskrift, kopiering eller vidarebefordring av epost)

Secure Email är en lösning från Microsoft som automatiskt tillämpas om någon av de två övre kraven inte uppfylls. Lösningen gör det möjligt att skydda oavsett vem mottagaren är och tillåter även att innehållet visas via en webbläsare och ställer därmed inga krav på övriga applikationer. Secure Email bygger på klassiska RMS och det som tidigare kallades för Outlook Message Encryption (OME). Med OME får mottagaren tillgång till informationen genom en inloggning mot avsändarens Office 365 –webbgränssnitt. Det här scenariot resulterar i att ingen oskyddad information lämnar avsändarens organisation.

I följande exemplet går jag igenom de senaste nyheterna inom Secure Email och mottagarens upplevelse om de uppfyller kraven eller inte:

Skydda och skicka Epost-meddelande

– Användaren kan skydda ett epostmeddelande och välja om mottagaren skall ha fulla rättigheter (Encrypt) eller om mottagaren skall vara begränsad att vidarebefordra, kopiera, skriva ut eller på annat sätt sprida innehållet (Do Not Forward).
(I nuläget finns bara alternativet ”Encrypt” via webbgränssnittet till Exchange (OWA). Funktionen kommer via AIP klienten framöver även till lokalt installerade Outlook som idag bara har ”Do not Forward”-alternativet)
Är ett Office dokument bifogat kommer även detta krypteras med motsvarande rättigheter

clip_image001

Alternativ 1: Mottagare som uppfyller kraven

– Mottagare som har exempelvis Office 365 och därmed både konto i Azure AD och Applikationer som förstår RMS.

Alla supporterade Office-versioner har idag inbyggt stöd för RMS.
Där emot är alternativet Encrypt en helt ny standard där stödet nyligen släpptes till Office Version 1804 (Build 9226.xxxx).

clip_image002

Äldre Office versioner kommer inte få stöd utan supporterar enbart Do Not Forward som funnits i snart 15 år.
Om en äldre Office/Outlook version används kommer ett epostmeddelande skyddat med Encrypt att visas på samma sätt som exemplet nedan då applikationen inte kan tolka den här RMS-rättigheten.

Alternativ 2: Mottagare som inte uppfyller kraven

Mottagare som varken har konto hos Microsoft eller applikationer som förstår RMS, i detta fall ett gmail-konto.

image

För att logga in mot Office 365 har en gmail-användare möjlighet att autentisera sig direkt med sitt Googlekonto då Microsoft federerar med Google och flera andra leverantörer.

Saknas den här möjligheten finns det alltid ett alternativ att istället logga in med en engångskod (OTP)

clip_image007

En OTP kod skickas då till samma mottagare

clip_image009 clip_image011

Efter lyckad autentisering kommer Office IRM dekryptera och visa både mailet och den bifogade Officefilen via webbläsaren

clip_image013

I båda alternativen är det fortfarande RMS som nyttjas för kryptering/dekryptering och i alternativ 2 tillsammans med det som kallas för Office IRM. I alternativ 1 när det är en lokalt installerad programvara som dekrypterar innehållet används det som kallas för Client-Side-decryption där RMS dekrypteringen sker lokalt. Office IRM i Alternativ 2 gör att tjänster så som Exchange, SharePoint och Office Online krypterar/dekrypterar innehållet åt användaren, så kallad Server-Side-Encryption/decryption.

Varje RMS-krypterad fil har även en okrypterad text som redovisas om applikationen inte förstår RMS. I Secure Email är detta texten som länkar till Office 365 där vi även ser att det krypterade mailet ligger bifogad. Den här texten kan även anpassas vilket jag tidigare beskrivit här https://itsakerhetsguiden.se/2017/11/17/anpassa-secure-email-fr-din-organisation/

Publicerat i Azure Information protection | Märkt , | Lämna en kommentar

Identifiera och förhindra att känslig information sprids via molntjänster med CAS

Microsoft Cloud App Security (CAS) har flera syften. Den har dels en viktig del för att få en bild över vilka molntjänster som verksamhetens användare nyttjar. Den har även en integration med Azure Information Protection för att detektera känslig information och applicera skydd.

Jag kommer med den här artikeln påvisa ett konkret exempel på hur CAS kan stötta verksamheten genom att både identifiera och förhindra känslig information som sparas och delas via molntjänster.

Känslig information delas via molntjänst

Förutom att skydda känslig information är det viktigt att ha en informationsklassifikation som inte stoppar verksamheten.

Om vi t.ex. automatiskt klassificerar eller ger användarna möjlighet att klassificera något som ”Confidential Unprotected” för att klassificera informationen utan att begränsa dess behörighet kan det komma tillfällen vi ändå vill ta åtgärd på filen.

Exemplet här rör när en användare delar filen externt utanför bolaget via en molntjänst i det här fallet OneDrive for Business. Här har vi nu möjlighet att både identifiera och ta åtgärd just på detta.

image

Identifiera och larma

Cloud App Security (CAS) kan integrerar med bland annat Office 365 inom samma tenant.

Med hjälp av CAS kan vi skapa en policy som t.ex. larmar om en fil klassificerad som Confidential men oskyddad delas med någon utanför bolaget

image

Det här resulterar i att administratörerna dels kan få ett larm av denna händelse och redogörelse i CAS över vem/vilka filen delas med

image

Via CAS får administratören mer information och får även möjlighet att vidta en åtgärd på detta larm

image

Manuell åtgärd

Exempelvis kan vi applicera ett skydd på filen genom att byta till en AIP Label som även krypterar filen (till fördefinierade användare) och på så sätt styra exakt vem/vilka som har behörighet till filen

image

image

Automatiserat skydd

Om administratören inser att det är idé att automatisera ovanstående åtgärd vid denna händelse kan vi också välja att skapa åtgärdspolicy baserat på detta larm som utför samma åtgärd

image

Åtgärden ser till att CAS automatiskt kommer skydda filen när den delas externt och vi kan avgöra var och när det här skall ske

image

Resultat

Det här kommer resultera i att oavsett vem som filen delats med kommer enbart de som är definierade i vår Information Protection Policy att nå filen

Samma skydd på övriga molntjänster

Idag fungerar ovanstående scenario för SharePoint Online, OneDrive for Business, Box och G Suite

Fler tjänster kommer få samma möjlighet och framöver kommer vi kunna använda Conditional Acess för att inspektera sessioner via publicerade molntjänster via Azure Application Proxy.

image

Publicerat i Azure Information protection | Märkt | Lämna en kommentar

Azure Advanced Threat Protection

Microsoft har från den 1:a mars lanserat sin Advanced Threat Analytics (ATA)-lösning som en molntjänst, kallad Azure Advanced Threat Protection. Vad innebär då detta?

ATAn har till syfte att detektera och larma om intrång i vårat lokala AD. Verktyget bygger på att ATA samlar in och analyserar på portnivå allt som når våra domänkontrollantera för att på så sätt identifiera intrång. Detta kräver rejält med prestanda av den lokala lösningen.

Vi har även Defender Advanced Threat Protection (ATP) som har till syfte att identifiera och även blockera intrång på våra klientdatorer med hjälp av bl.a. analys av allt som händer på enheten. Defender ATP nyttjar Microsofts Threat intelligence tjänst i molnet med bl.a. reputation-kontroll av allt ifrån filhashar till IP-adresser och URLer som klienter kommunicerar med.

Vad ger då Azure Advanced Threat Protection?
Dels tar den över ATAns roll och monitorerar våra DCs med hjälp av små enkla sensorer som då inte kräver att vi behöver investera i ny hårdvara.
Den integrerar också med Defender ATP för att på så sätt kunna samköra systemen och då detektera intrång både i vår lokala miljö men också i våra klienter oavsett var Windowsenheten är ansluten.

image

Med tanke på att Defender ATP numera är extremt kraftfullt och kan ta åtgärder som att sätta klienten i karantän vid säkerhetsincidenter. Nu kan vi även få in information från Azure ATP för att identifiera fler risker. På samma sätt kan vi identifiera risker på klienter för att motverka att attackerna fortsätter när klienten väl ansluter sig till det lokala AD:t.

image

image

ATA som produkt kommer finnas kvar för de som vill köra detta lokalt. Dessvärre kommer inte integrationen med Defender ATP och Office ATP till den lokala ATA-lösningen.

Namnskillnaden där den lokala ATA-lösningen är mer “Analytics” för att detektera och larma om intrång medan ATP-som molntjänst även har “Protection” för att att ta åtgärd på dess larm.

Läs mer om Azure ATP:
Microsofts EM+S Blog
Microsoft Docs

Publicerat i Advanced Threat Analytics, Endpoint Protection | Märkt | Lämna en kommentar

Skydda alla filtyper till ALLA mottagare

Microsoft har sedan de började leverera sin RMS-lösning som en tjänst i Azure haft som vision att bland annat kunna skydda alla filtyper (jämfört med enbart Office filer som var begränsningen tidigare) till alla typer av mottagare. Alla filtyper var något som blev löst ganska omgående men där emot har det varit en del begränsningar när det kommer till att skydda oavsett mottagare.

Tack vare Azure AD/Office 365 fick man direkt en lösning att skydda mellan organisationer och tack vare konceptet ”RMS for individuals” kan användare som inte tillhör en organisation som använder sig av Azure AD/Office 365 registrera sig kostnadsfritt för denna tjänst.

Begränsningen har varit när det kommer till publika domäner och epostleverantörer så som gmail, hotmail, telia, med mera. I det här fallet har vi tusentals domäner som varit begränsade att kunna nyttja denna lösning. Jag kan personligen argumentera för att denna begränsningen även har kunnat rättfärdigas av att ID-kontrollen av att skapa ett organisationskonto generellt är bra mycket högre än ett att skapa ett publikt epostkonto som oftast kan genomföras av vem som helst mer eller mindre anonymt.

Begränsningen har dock varit ett problem för många verksamheter då behovet ändå har funnits att skydda även till vissa konton som nyttjar dessa publika mailtjänster.

Tack vare den tjänst som idag heter Secure Email och går även under namnet Office 365 Message Encryption version 2 (OMEv2) har vi sedan en tid tillbaka kunnat skydda både mail och även bifogade Officefiler även till publika mailtjänster. Lösningen bygger på att mottagaren i själva verket loggar in mot avsändarens Office 365 -miljö för att både läsa mailet via Outlook online och bifogade filer via Office online. Idag kan vi dock inte skydda en fil exempelvis via Office eller AIP klienten till en publik adress och mottagaren kan inte ladda ner en bifogad fil och konsumera utanför webbgränssnittet.

Nuvarande AIP client blockerar idag möjligheten att skydda till en publik mailadress:image

Konceptet med RMS for individuals är dock på väg att ändras för att lösa detta och det kommer fungera enligt följande:

  1. Om mottagaren har en organisationsadress som saknas i Azure AD kommer dess domän att skapas i Azure och användarkontot kommer registreras.
  2. I det scenarion som inte ovanstående fungerar exempelvis om mottagaren har en publik mailtjänst kommer det inom kort generera ett Microsoft Account (MSA) account med samma namn som den publika mailadressen.

På det här sättet kommer Microsoft i mål med sin vision. Lösningen kommer att kunna skydda till alla typer av mottagare. Precis som tidigare kommer det inte vara någon kostnad kopplad till att registrera sig för den här tjänsten, som då tillåter oavsett mottagare att kunna konsumera skyddad information oavsett filtyp.

Om vi tittar i Preview versionen av kommande AIP client kan vi redan nu skydda en fil till ett publikt konto.

2018-03-06 10_07_38-Sheldon on ONEVINNANDERSX1 - Virtual Machine Connection

2018-03-06 10_08_30-Sheldon on ONEVINNANDERSX1 - Virtual Machine Connection

Mer information om RMS for individuals från Microsoft TechX 2015 https://youtu.be/6uAa9eRcDtQ?t=718 

Mer om Secure Email:

https://itsakerhetsguiden.se/2017/10/27/skydda-gdrp-information-aven-till-publika-mailtjanster/

https://itsakerhetsguiden.se/2017/11/17/anpassa-secure-email-fr-din-organisation/

Publicerat i Azure Information protection | Lämna en kommentar

Identifiera och skydda befintlig information

Vid införande av en lösning för att skydda känslig information är det vanligt att man fokuserar på att skydda ny information vid skapande. Men vad gäller då med all lokal befintlig information och hur detekterar man vilken befintlig information som faktiskt är skyddsvärd?

När det kommer till klassiska RMS/IRM har vi i över 10 års tid kunna applicera skydd på:

Filservrar
Med hjälp av Windows Server rollen File Classification Infrastructure (FCI) som då baserat på mappnivå eller innehåll kan applicera skydd av befintliga filer. Till en början rörde det sig enbart om Officedokument men sedan en tid tillbaka har vi möjlighet att skydda oavsett filtyp.

SharePoint
Information Rights Management (IRM) i SharePoint nyttjar RMS för att applicera skydd på Office-dokument/pdf som öppnas eller delas från SharePoint. IRM appliceras per bibliotek och kan på så sätt bli en utmaning att i efterhand kunna avgöra vilka bibliotek som innehåller skyddsvärda dokument i en större SharePoint-farm.

Vi saknar idag möjlighet att klassificera filer med ovanstående lokala lösningar och det krävs att filservern kör Windows Server.

Azure Information Protection Scanner

Azure Information Protection (AIP) Scanner är en lösning för lokalt sparade filer. Om vi tänker oss att vi nyttjar Office 365 DLP system, för att utföra åtgärder på den metadata den kan identifiera och utföra åtgärder på. Exempelvis person och id-nummer i ett GDPR scenario på information som vi lagrar och hanterar via Office 365.  Oavsett om vi använder Office 365 eller inte finns oftast motsvarande behov även lokalt.
AIP Scannern identifierar, klassificerar och skyddar filer som är sparade lokalt. AIP Scannern nyttjar de labels och regler som vi redan definierats i Azure Information Protection.

AIP Scannern kan söka igenom både lokala SharePoint/OneDrive servrar och CIFS filytor (både Windows File shares och NAS) för att antingen enbart identifiera eller även applicera klassificering/skydd av dokument.

Komponenterna som krävs följer med vid installation av AIP klienten (aka.ms/aipclient) och både installeras och konfigureras via PowerShell.

För att ge en tydlig bild av dess syfte och funktion följer här ett exempel.

Exempel av AIP Scanner

I mitt exempel använder vi följande AIP regler:

  • en standard informationsklassning kallad ”Business” för alla dokument och mail som skapas. Informationen klassificeras utan att applicera något skydd. image
  • en regel som identifierar filer med svenskt personnummer och då klassificerar som ”Secret” och applicerar ett skydd så enbart interna användare når dessa filer och begränsar rättigheter till spridning i form av kopiering eller utskrift.image

Vi söker igenom både en lokal filserver och en lokal SharePoint/OneDrive.

Vi kan välja att ignorera redan klassificerade filer eller som i mitt exempel bortse från tidigare klassificering med målsättning att applicera ett korrekt skydd även om en användare klassificerat en fil felaktigt. Detta förutsätter också att AIP Scannern körs med ett konto som “Super User” för att på så sätt kunna dekryptera och inventera även befintligt skyddade filer.

clip_image002

Filytorna ser innan scanning ut enligt följande med både Office dokument och andra filtyper:

SharePoint:clip_image003

File share:clip_image004

AIP Scannern kan köras i två olika lägen:

  • enbart inventera och få en översikt över bland annat hur många filer som är klassificerade/skyddade samt innehåller känsliga uppgifter så som personnummer
  • påtvinga klassificering och skydd baserat på dess innehåll

Vi kan också välja att schemalägga scannern eller som i nedanstående fall göra en manuell engångsskörning

clip_image005

Efter AIP Scannern är konfigurerad kan tjänsten startas med ovanstående kommando och när tjänsten har gått färdigt finns en rapport över körningen.

Rapporterna skapas som en kommaseparerad fil (csv) och kan exempelvis importeras till Excel som i mitt fall nedan. Det framgår tydligt vilka filer som förändrats, vad de hade för informationsklassificering (label) sedan innan, samt hur filerna har förändrats och baserat på vad.

clip_image006

Filytorna ser nu ut enligt följande där den uppmärksamme även kan se på filernas något ökade storlek att de krypterats. Både Officefiler och övriga filtyper har klassificerats och krypterats både på filservern och SharePoint vilket inte varit möjligt i SharePoint tidigare.

SharePoint och exempel på en skyddad txt-fil och dokument som innehåller ett personnummer:clip_image008

File share med exempel på två PowerPointfiler med olika klassificeringar och skydd baserat på dess innehåll:clip_image007

En rekommendation är att enbart inventera och att även genomföra några tester med förändring mot en icke produktionsyta till en början. När resultatet är enligt förväntan genomför en engångskörning och vid behov schemalägg sedan denna mot skarpa lagringsytor.

Publicerat i Azure Information protection, Informationssäkerhet | Märkt | Lämna en kommentar