Inbyggda metoder att skydda sig mot lösenordsattacker i Windows och varför de inte fungerat

Lösenordsattacker ( eller ordboksattacker , bruteforce attacks och dictionary attacks ) förekommer garanterat på de flesta servrar som är nåbara från Internet, var sig det är Windows, Linux, Netware eller Solaris. Attacker kan också komma inifrån företaget.

Principen bygger på att gissa sig till en användares användarnamn och lösenord genom att helt automatisera försöken med långa listor / ordböcker med variationer på ord .
Skydd mot bruteforce försök specifikt på Windows-servrar har alltid varit en mardröm och skulle fortsätta att vara så om inte det äntligen fanns en kostnadseffektiv och väl fungerande lösning med Syspeace

De flesta systemadministratörer med självrespekt börjar med de bästa avsikter att faktiskt hålla koll på lösenordsattacker och andra larm men så småningom ger de upp på grund av det stora antalet attacker som sker dagligen. Vi kan prata om hundratals attacker. Per dag.

Andra systemadministratörer tror att en brandvägg tar hand om problemet eller att en sk account lockout policy är lösningen.
Ingen av dem är det och jag tänkte belysa varför nedan.

Brandväggen för att spärra attacker
Vad gör en brandvägg egentligen ? Brandväggens roll är att blockera trafik på oönskade portar och att neka portscans och olika SYN flood attacker. I vissa fall kan den även söka efter virus i trafiken så länge trafiken är okrypterad.
Det är ungefär det en brandvägg gör. En brandvägg är i grunden en dörrvakt avgöra vem som får in för att snacka med killarna på insidan och vem som inte får det.
Om en angripare ansluter på en giltig port (t.ex. https på port 443 ) , vidarebefordras det till servern ifråga t.ex webbmail gränssnittet på en Microsoft Exchange Server eller Microsoft Windows Terminal Server eller Citrix-server.
När angriparen kommit fram så inloggningsbegäran lokalt av servern, inte brandväggen. Inloggningsprocessen hanteras av Windows Authentication processen (som i sin tur kan valideras mot Active Directory eller en lokal användardatabas med hjälp SAM).
Brandväggen är redan ute ur bilden verkligen eftersom den inte har något samband med Windows servern förutom TCP-anslutning och hålla den sessionen vid liv egentligen.
De kommunicerar inte resultatet av inloggningsprocessen mellan varandra.

En annan metod man använder ibland är en ändring från standardportar .
Inloggningsprocessen hanteras fortfarande av Windows Server även om du kommer att bli av med många portscans och “lata bakgrundsförsök” om du använder icke-standardportar.
I grund och botten du bli av med script kiddies men problemet är inte löst. Trafiken omdirigeras/port vidarebefordras fortfarande till servern som gör den verkliga autentiseringen och en hacker som vill ta sig in nöjer sig inte med att bara söka efter standardportar utan kommer även hitta de ”dolda” portarna med olika verktyg som telnet , nmap .
De är ju publikt tillgängliga.

Använda Remote desktop gateway elller ett sk DMZ
Använda till exempel en Remote Desktop Gateway kommer inte att hantera problemet heller.
Med hjälp av en RDP Gateway minskas exponeringen för attacker till fler servrar på insidan av brandväggen men det är fortfarande nåbart och användarinloggningar måste valideras fortfarande.
Grundproblemet är att validernigen av inloggningen fortfarande sker lokalt på servern, oavsett på vilka portar och hur de kommer dit. Det gäller Microsoft Windows Server, Exchange Server, Citrix, Sharepoint, CRM, Terminal och RDS Server och så vidare. Listan kan nog gå göras hur lång som helst .

Risker med att ändra standardportar
Det finns också risk för saker slutar fungera när du installerar några uppdateringar eller patchar till dina Windows Servrar om du börjar ändra standardportar eller standardkonfigurationer.
Det har hänt mig några gånger och det är inte så roligt att vara ärlig när man har 1000 användare inte kunna logga in bara för att du gjort det du ska. Tro mig, det är inte en bra måndag morgon.

Att skydda sig med VPN
Ja. Det är en säkrare metod men här finns också några problem.
Först av allt, det är inte så lätt att hålla reda på VPN-certifikat, sätta upp och hantera alla licenskostnader (som kan vara ganska betydande riktigt) och (ibland kostsamma) hårdvara du behöver ha på plats. Historiskt har det också alltid varit prestandaproblem med de flesta VPN-lösningar, eftersom all trafik leds genom en eller ett fåtal VPN servrar.
Några av dem tar betalt även för den bandbredd som du vill att det ska kunna använda för VPN-anslutningar eller ta betalt för antalet samtidiga VPN-anslutningar, kan en VPN-lösning vara ganska dyrt som en nyinvestering och med hänsyn till all administration inblandade i den.
Ett annat problem som kan finnas är att man tillåter all trafik genom en VPN in till företagets nät vilket kan vara riskabelt om arbetsstationen blivit hackad. Den kan då t.ex. genomföra lösenordsattacker från ”insidan” av nätet och det är inte alltid man tänker på att skydda sig även mot inre hot.

VPN och tillgänglighet för webbmail
Du vill kanske inte heller att kräva att dina användare har en VPN-anslutning till Microsoft Exchange OWA eftersom hela idén med OWA är att den ska lätt att nå från var som helst. Även från en flygplats.
Jag vet att det finns några företag som faktiskt kräver VPN även för OWA och det är bara bra antar jag, men ju mer vi flyttar våra data och applikationer till molntjänster, kommer detta krångel med olika VPN och krångligheter så småningom blekna in i de mörka hörnen av Internet (det är min personliga övertygelse ändå).
Saken är den att dina användare inte vill vara bundna av komplicerade VPN-klienter. Användarnas syn är ”det ska bara fungera att arbeta” och det måste vara enkelt och intuitivt för dem. De dagar då “System Administratörer från helvetet” kunde genomföra alla typer av komplexa lösningar för att hålla saker säkra och tvinga användarna att ha mycket specifika och komplexa sätt att komma åt data är över.

Antivirus som skydd
Nej. Ett antivirus söker efter skadlig kod som trojaner och andra virus på servrar och hanterar dem Ett antivirus har inget med inloggningar att göra.

Att skaffa en hårdvarubaserad IDS/IPS eller t.ex. SNORT
Med hjälp av en centraliserad och specialiserad IDS/IPS kan man fånga mycket saker
Detta är en mer effektiv metod, ja.

Nackdelen är, de flesta av dessa system kräver att du ändrar din infrastruktur och får specifik och kostsam hårdvara, licenser och dyra konsulter för att implementera och planera projektet.
Någon måste sen också övervaka det, ta hand om det och så vidare.

Det finns paralleller till VPN metoden här även om en IDS/IPS gör mycket mer eftersom den undersöker all nätverkstrafik till och från företagsnätet, undersöker den för skadlig kod och så vidare.
Jag är inte säker faktiskt om en IDS/IPS per automatik kan kommunicera med Windows Server Authentication Process så jag ska faktiskt inte kommer att säga något om det.
Jag skulle förutsätta att de kan, annars har jag svårt att se poängen (från perspektivet med lösenordsattacker alltså). Om inte så skulle man ju fortfarande behöva hantera attacken på servern på något sätt.

Att låsa ute konton
I Microsoft Windows Server finns egentligen bara en enda inbyggd mekanism för att hantera den här typen av attacker och den kallas för Account Lockout Policy.
Account Lockout Policy metoden är också bristfällig på grund av det faktum att en angripare ganska lätt kan orsaka en DOS (Denial of Service) helt enkelt genom att hamra din server med ogiltiga inloggningar, men med giltiga användarnamn, vilket gör riktiga användarkonton oanvändbara för giltiga användare.
I grunden är allt angriparen behöver veta användarens inloggningsnamn. I många system och företag är det inte svårt att gissa sig till.
Prova t.ex. företagetsnamn\förnamn eller postadressen för användaren eftersom det är ganska ofta också ett giltigt inloggningsnamn.

Om en angripare gör detta från tiotusentals datorer samtidigt kan det effektivt helt lamslå ett företag eller en organisation och ingen kan logga in, varken utifrån eller på kontoret. Som en parantes kan nämnas att administratörskontot i Windows inte går att låsa så en angripare kan försöka hur många gånger som helst mot just det kontot viket de också gör.

Att använda sig av molntjänster
Vi flyttar mer och mer av våra data och applikationer till olika molntjänster. På det sättet blir vi av med några av de här problemen på våra egna servrar och förhoppningsvis, har din leverantör av molntjänster faktiskt en plan för dessa scenarier, rutiner och har den nödvändiga övervakningen och programvaran plats.
Om du använder en Cloud Computing-plattform baserad på Windows-servrar, ska du faktiskt fråga din leverantör hur de hanterar brute force försök på sina servrar. Troligtvis kommer de att ge dig en eller flera av de scenarier som beskrivs ovan och som jag har visat er, är de inte tillräckliga för att hantera uppgiften.
De är sällan förberedda på frågan ens. Fråga gärna din egen leverantör och se vilket svar du får. Min gissning är något svävande svar men i grunden har de inget på plats för att hantera lösenordsattacker.

Du kan även prova att logga in dig eget konto med ditt eget användarnamn, men fel lösenord massor av gånger och se vad som händer. Kommer det bli utelåst? Kommer din maskin låsas ut? Hur kommer din molnleverantör att reagera och kommer du informeras på något sätt att ett intrångsförsök har gjorts med hjälp av ditt konto? Hur många gånger kan någon försöka komma åt ditt konto utan att du blir uppmärksammad på det? Kan din leverantör även snabbt få fram om information om varifrån attacken skedde, hur många tidigare just den IP adressen har försökt ta sig in och liknande information utifall du vill polisanmäla?
Personligen vet jag bara en molntjänstleverantör i Sverige som tänkt på de här sakerna och det är Red Cloud IT.

Att hantera lösenordsattacker automatiskt med hjälp av Syspeace
Även om du väljer att inte använda det jag föreslår så rekommenderar jag ändå starkt att du börjar tänka på de här sakerna på rätt sätt, eftersom de här problemen kommer att eskalera i framtiden.
Ta bara en titt på alla hacktivism med DDOS-attacker som händer där ute. Det är bara en början eftersom Internet fortfarande är relativt ungt.
Först av allt, och det är oerhört viktigt att du förstår att det spelar det ingen roll om du själv driftar dina egna servrar eller om du använder VPS (Virtual Private Servers) någon annanstans eller ens om du är en molntjänstleverantör.
Den grundläggande principen står fast, om du ger någon form av tjänst till användare som använder Windows-autentisering så bör du läsa detta och förhoppningsvis har jag fått fram min poäng

Om du redan har brute force attacker mot dina Windows-system i dag och jag är ganska säker på att du redan har det (bara slå på loggningen i Windows och jag är säker på att du ser att du har mer än du faktiskt trodde, som en fotnot så är den här typen av loggning inte påslaget som standard i Windows.)
När du noterar en attack finns ett antal saker du måste göra

Först av allt. Blockera attacken.
Du behöver blockera attacken. Omedelbart. Detta är naturligtvis din första prioritet. På ena elelr andra sättet ska du blockera det i en brandvägg , antingen i den lokala Windows brandväggen eller i den externa, Välj det som går snabbast och lättast.
Man inte vill att slösa CPU och RAM och bandbredd på dessa människor (eller botnät) och naturligtvis, du inte vill att de ska faktiskt lyckas logga in på era servrar (om du har en usel lösenordspolicy på plats ) Du vill inte heller att man dölja ett riktitg intrångsförsök bakom en DDOS-attack för att fylla dina loggfiler och gömma sig där. (Ja, det är inte en ovanlig metod).
Det finns också en hel del rapporter om DDOS-attacker som används för att dölja den verkliga anledningen vilket är att ta reda på vilka säkerhetsåtgärder som finns på plats för framtida bruk.
Att känna sin fiende

Steg två . Spåra attacken. Varifrån kom den?
För det andra måste du ta reda på varifrån attacken har sitt ursprung och vilka användarnamn som användes. Du vill veta om det är en konkurrent som försöker hacka dig och komma åt dina företagsdata eller om du befinner dig i den lustiga situationen att det är ditt eget användarnamn som försöker logga från soliga Brasilien och du bara inte är i Brasilien (även om du skulle älska att vara). Du är i Bromölla och tittar på vinterslasket. Nånting är på gång.
Du vill också se om det är en tidigare anställd som försöker logga in. Det här är saker du vill veta och hålla koll på eftersom det kan finnas rättsliga frågor längre fram.
Punkterna ett och två, vill att du ska hanteras i realtid. Det finns ingen användning för dig att ta reda på två dagar efter attacken att något faktiskt hände. Du vill ha den stoppad, rapporterad och hanterad när det händer.

De juridiska aspekterna av en attack
Som ett tredje steg måste du bestämma vad du ska göra med vetskapen om attacken. Ska det överlämnas till advokaterna, din chef, polisen eller är det bara “ingenting” och kan kastas?

Att automatisera hanteringen av attacken
Det enklaste och mest kostnadseffektiva sättet att hantera brute force attacker mot Windows-server är att ha en automatiserat system att blockera, spåra och rapportera varje attack och det är där Syspeace kommer in i bilden

Syspeace är en lokalt installerad Windows-tjänst, som drar minst med systemresurser.
Den övervakar servern för oönskade inloggningsförsök och blockerar inkräktare i realtid i den lokala brandväggen utifrån de regler som du konfigurerat. Till exempel “om denna IP-adress har misslyckats med inloggning 20 gånger under de senaste 30 minuterna ska den blockeras helt i 5 timmar och skicka mig ett mail om det”

Detta innebär att du kan till exempel ställa in en blockerande regel som motsvara din Account Lockopu Policy men du höjer Syspeace till att blockera attacken innan din Account Lockout Policy slår till. På det sätet låses inte dina konton utifrån men du har ändå möjligheten att få konton låsta om de beter sig märkligt på insidan av företagets brandvägg.
Eftersom Syspeace övervakar Windows-autentisering och inloggningsprocessen spelar det ingen roll vilken brandvägg du använder eller vilka portar du använder. Övervakning, rapportering och blockering sker där själva inloggningsförsöket görs och därför fångas och hanteras automatiskt.

När en inkräktares IP-adress är blockerad, så blockeras den på alla portar mot den servern, vilket innebär att om du har andra tjänster som också körs på den server (som FTP, RDP, SQL elelr vad som helst) så skyddas också de tjänsterna direkt från angriparen. Angriparen kan alltså inte leta sig vidare till nästa tjänst och försöka hitta sårbarheter där. Det här är ett vanligt tillvägagångssätt utifall att en specifik programvara har skydd mot lösenordsattacker.
Vanligen kan de bara spärra angriparen för sitt eget program men inte för andra program.

Några andra funktioner i Syspeace
Några andra trevliga funktioner med Syspeace är till exempel GBL (Global BlackLlist) där varje Syspeace installation runt om i världen rapporterar varje attack till en central databas där de granskas och om en angripare bedöms ha attackerat tillräckligt många servrar och tillräckligt många kunder så sprids sedan den informationen till alla andra Syspeace installationer i hela världen. På så sätt är du skyddad i förväg när angriparna försöker hacka just din server. De kan helt enkelt inte ens kommunicera med den.
I Syspeace finns naturligtvis finns det vitlistor, vilket ger dig möjlighet att få dina kunder eller interna användare att aldrig blockeras. I sak är det inte så lämpligt kanske eftersom du nog vill veta att något ändå är på gång t.ex. att en av dina kunder eller användare blivit hackade

Det finns också Attack Control och Access Control som ger dig möjlighet att sortera ut information om framgångsrika och misslyckade inloggningar, hitta dem som försökt hålla sig under radarn, visa rapporter, sammanställa inloggningsmönster och platser för användare.
Du får dagliga och veckorapporter till dig per e-post och varje attack som blockera skickas till dig.
Informationen är tillräckligt detaljerad med från där attacken ursprung inklusive land, vilken användarnamn användes och hur många gånger de faktiskt försökt att hacka eller överbelasta dig innan samt när den IP adressen låses upp igen.
Det ger dig möjlighet att snabbt se om det är något du bör ta hand om eller bara fortsätta med din dag och låta det vara med ett leende på läpparna.

Gränssnittet är lätt att använda så det finns ingen anledning att anlita dyra konsulter att komma igång eller börja använda olika skript och ändra parametrar i dem för att passa dig behov och hoppas på bästa och hoppas att de inte hänger dina servrar. Med olika scripts finns också nackdelarna att du sällan har historik eller en Global Blacklist. De hanterar möjligen jus bara attaken men gör det väldigt svårt att få fram information i efterhand,