Skydd mot brute force-attacker

Vad är en brute force-attack?

En brute force-attack är en metod för att komma åt inloggningsuppgifter genom att systematiskt testa alla möjliga kombinationer av tecken. Attacken är automatiserad och utförs med skript och/eller bots som riktar in sig på en utvald inloggningssida. På grund av sin relativt enkla uppbyggnad är brute force en vanlig metod för dataintrång och är något som såväl företag som den enskilda användaren behöver skydda sig emot.

Hur skyddar vi oss mot en brute force-attack?

I flexites programvara finns det i grund och botten två nivåer av skydd mot brute force-attacker:

• Begränsning av antal inloggningsförsök på systemnivå
  I flexiteWEB är antalet tillåtna misslyckade inloggningsförsök begränsad. Denna begränsning är vad detta dokument behandlar.

• Komplexa och unika lösenord på användarkonton
  Om ett användarkonto har ett så pass simpelt lösenord att det är enkelt att gissa sig till spelar det ingen roll hur bra övriga skydd är. Lösenord måste vara tillräckligt komplexa för att övriga skydd ska utlösas. Det är rekommenderat att använda en blandning av gemener, versaler, siffror och specialtecken. Det är dessutom viktigt att inloggningsuppgifterna är unika och inte förekommer på andra platser.

Skydd mot brute force-attacker i flexiteWEB

Det är rimligt att anta att en legitim användare från och till misslyckas med ett fåtal inloggningsförsök. Om det däremot sker flertalet misslyckade försök, mot ett eller flera konton, under kort tid är detta att betrakta som suspekt aktivitet.

I flexiteWEB finns ett inbyggt skydd mot upprepade inloggningsförsök mot flexite-konton, baserat på följande scenarion:

• Attack mot enskilt användarkonto — Användarkontot blockeras efter:

  • 10 konsekutiva misslyckade inloggningsförsök inom 24 timmar, oavsett från vilken IP-adress som försöken utförs.

  • 10 konsekutiva misslyckade inloggningsförsök inom 24 timmar från en enskild IP-adress, oavsett om inloggning lyckats från andra IP-adresser.

• Attacker från enskild IP-adress — Efter 10 misslyckade inloggningsförsök, med ett eller flera användarkonton, inom 60 sekunder från en och samma IP-adress, blockeras IP-adressen från vilken inloggningsförsöken utförts.

• Attacker från flera IP-adresser — Efter 50 misslyckade inloggningsförsök, med ett eller flera användarkonton, inom 60 sekunder stoppas webbapplikationen flexiteWEB fullständigt.

Skydd för inloggning med PIN-kod

Användare utan flexite-konto kan via länk i e-post logga in med sin e-postadress i kombination med en PIN-kod som skickas till e-postadressen. Denna inloggningsmetod skyddas på liknande vis som enskilda användarkonton, med skillnaden att det i detta fall är e-postadressen som blockeras och inte ett användarkonto.

Utreda och häva blockering

Det är kritiskt att utreda varför en blockering inträffat innan blockeringen hävs.

Vid blockering av enskilda användarkonton och IP-adresser hävs blockeringen från flexiteCLIENT.

I de fall webbapplikationen stoppats fullständigt måste den startas upp igen. Notera att webbapplikationen startar upp automatiskt när tjänsten för Apache Tomcat startas om, vilket medför att det inte ska ses som ett bestående skydd.

Blockerat användarkonto

Ett användarkonto blockeras som standard efter att:

• 10 konsekutiva misslyckade inloggningsförsök utförts inom 24 timmar mot ett och samma konto, oavsett från vilken IP-adress som försöken utförs.

• 10 konsekutiva misslyckade inloggningsförsök utförts inom 24 timmar mot ett och samma konto från en enskild IP-adress, oavsett om inloggning lyckats från andra IP-adresser.

Det grundläggande förfarandet är att analysera åtkomstloggar och samtala med användaren för att utreda huruvida det rör sig om en attack, eller om användaren själv stått för de misslyckade inloggningsförsöken.

1. I flexiteCLIENT, ta reda på exakt tidpunkt för låsning av användarkontot.
   Under Systemaktivitet listas samtliga låsta användarkonton tillsammans med tidpunkt för låsning.

   • Låsning av användarkonto loggas även i flexiteWEBs loggfil belägen på webbservern; c:\tomcat\flexite\log\{date}_flexite.log:

     {timestamp} Account {account} has been locked due to 10 unsuccessful
     login attempts within 86400 seconds

2. I flexiteCLIENT, navigera till System > Loggar > Händelseloggar och filtrera loggen på användarnamnet för den blockerade användaren samt datum från Systemaktivitet.

   1. Notera tidpunkter för loggrader för Händelse "Inloggning misslyckades".

3. Samtala med användaren om tidpunkterna för de misslyckade inloggningarna.

4. Utifrån insamlad information, bedöm om det rör sig om användarmisstag eller en attack.

   1. Om det rör sig om användarmisstag, lås upp kontot under Systemaktivitet alternativt på användarkortet.

   2. Om det rör sig om en attack betyder det att användarnamnet hamnat i fel händer. Överväg att byta användarnamn på aktuellt konto, alternativt att inaktivera aktuellt konto och skapa nytt. Lås upp användarkontot efter utförda åtgärder.

Blockerad IP-adress

En IP-adress blockeras som standard efter att 10 misslyckade inloggningsförsök utförts, med ett eller flera användarkonton, inom 60 sekunder från en och samma IP-adress.

Det grundläggande förfarandet är att analysera åtkomstloggar och utreda huruvida det rör sig om en attack, eller om det rör sig om användarmisstag.

1. I flexiteCLIENT, ta reda på exakt tidpunkt för låsning av IP-adress.
   Under Systemaktivitet listas samtliga låsta IP-adresser tillsammans med tidpunkt för låsning.

   • Låsning av IP-adress loggas även i flexiteWEBs loggfil belägen på webbservern; c:\tomcat\flexite\log\{date}_flexite.log:

     {timestamp} IP address {address} has been locked due to 10 unsuccessful login attempts within 60 seconds

2. I flexiteCLIENT, navigera till System > Loggar > Händelseloggar och filtrera loggen på datum från flexiteWEB logg.

   1. Notera tidpunkter, användarnamn samt IP-adress för loggrader för Händelse "Inloggning misslyckades".

3. Utifrån insamlad information, bedöm om det rör sig om användarmisstag eller en attack. Om det rör sig om ett fåtal användarkonton, samtala med användarna om tidpunkterna för de misslyckade inloggningarna.

   1. Om det rör sig om användarmisstag, lås upp IP-adressen under Systemaktivitet.

   2. Om det rör sig om en attack betyder det att användarnamnen hamnat i fel händer. Överväg att byta användarnamn på aktuella konto, alternativt att inaktivera aktuellt konto och skapa nytt. Lås upp IP-adressen efter utförda åtgärder.

Stoppad flexiteWEB

Webbapplikationen flexiteWEB stoppas som standard fullständigt efter att 50 misslyckade inloggningsförsök utförts, med ett eller flera användarkonton, inom 60 sekunder.

Det grundläggande förfarandet är att analysera åtkomstloggar och utreda huruvida det rör sig om en attack, eller om det rör sig om användarmisstag.

1. I flexiteCLIENT, ta reda på exakt tidpunkt för nedstängningen av flexiteWEB.
   Loggar för flexite brute force-skydd finns att läsa under System > Loggar > Åtkomstloggar > Säkerhet. Nedstängning av flexiteWEB registreras på följande vis:
   "flexite system har låsts på grund av %attempts misslyckade inloggningsförsök inom %seconds sekunder"

   • Nedstängning av flexiteWEB loggas även i flexiteWEBs loggfil belägen på webbservern; c:\tomcat\flexite\log\{date}_flexite.log:

     {timestamp} Flexite system has been locked due to 50 unsuccessful login attempts within 60 seconds

2. I flexiteCLIENT, navigera till System > Loggar > Händelseloggar och filtrera loggen på datum från flexiteWEB logg.

   1. Notera tidpunkter, användarnamn samt IP-adresser för loggrader för Händelse "Inloggning misslyckades".

3. Utifrån insamlad information, bedöm om det rör sig om användarmisstag eller en attack.
   Med denna mängd misslyckade inloggningsförsök finns det en risk att det rör sig om en attack, oavsett om försöken utförts från en eller flera IP-adresser.

   1. Om samtliga försök skett mot samma användarkonto kan det betyda att användarnamnet hamnat i fel händer. Överväg att byta användarnamn på aktuellt konto, alternativt att inaktivera aktuellt konto och skapa nytt, för användaren.

   2. Om försöken skett mot flera konton kan det röra sig om en organiserad attack. I detta fall kan det vara en god idé att se över åtkomsten till webbservern som huserar flexiteWEB.

4. För att undvika obehörig åtkomst till flexiteWEB är det rekommenderat att starta upp flexiteWEB först efter åtgärder vidtagits.

Konfiguration

För mer information om flexites brute force-skydd i flexiteWEB, vänligen kontakta Flexite AB.