Sikkerhed: Sådan undgår du bedst muligt at få din hjemmeside hacket

Det værste der næsten kan ske for ens hjemmeside er at den bliver hacket. Udover at det går ud over ens online reputation hos kunderne så kan det give et kæmpe oprydningsarbejde, for ikke bare skal siden gendannes til sin normale gang og udseende men der skal også sikres at det ikke sker igen.

Vores ønske er at forhindre at siden bliver hacket, men hvis (når) det sker så ønsker vi også at vide hvordan en hacker har opnået adgang til siden så vi kan lukke hullet og bagefter så ønsker vi at rydde ordentligt op og fjerne sikkerheds bristen.

Guiden her vil fungere på alle hjemmesider som kører apache på en Linux server.  Eksempler tager ofte udgangspunkt på en WordPress installation men kan også tilpasses til lign. systemer som Prestashop og Drupal.

Sådan foregår hacking

Hacking er et bredt begreb og består i at der omgås system på en måde som de ikke er tiltænkt. Resultatet er at en person opnår adgang til systemer hvor der kan trækkes data ud, høstes nye data eller benytte målet som værktøj til andre mål.

Sagt på en anden måde, så ønsker en hacker at liste kreditkort oplysninger ud af de besøgende på hjemmeside. Han ønsker måske at tilgå eksisterende bruger konti. Han ønsker måske at bruge serveren til data mining af bitcoins eller andre kryptvalutaer. Han ønsker måske at bruge serveren som et led i et angreb på en anden server eller hjemmeside.

Hackeren vil som regel enten prøve at gætte sig frem til login på siden eller vil hackeren prøve at udnytte sårbarheder i softwaren på serveren eller det som hjemmesiden består af.

Typisk vil en hacker bruge et værktøj som er automatiseret og scanner hjemmesiden og serveren automatisk for kendte sårbarheder. Det vil derfor meget sjældent være et personligt eller målrettet angreb imod hjemmesiden eller person bagved.

Forebyggelse af hacking og sikring af hjemmesiden

For alle tiltag gælder det at det er en rigtig god ide først at teste at problemet eksistere hvorefter der implementeres en løsning. Herefter kan man validere at man reelt også har løst et problem fremfor måske blot at lave symptom behandling eller i værst fald gøre problemet større.

Sikring af bruger login

Det bedste tip er nok at sikre ens login til hjemmesiden. Undgå at bruge standard brugernavne såsom “admin”, “hans” og andre. Gør det en lille smule sværere ved blot at tilføje et tilfældig bogstav foran og et par tal bagefter som f.eks. “Tadmin434” og “aHans898”.

Brug et rigtigt tilfældigt koderod som “lcVi6W5DfdSz”. Find dit nu på denne password generator.

Brug en password manager til at huske disse kryptiske kodeord og brugernavne.

Hold server og software til hjemmesiden opdateret

Sørg for at din hosting holder serveren opdateret eller hold den selv opdateret hvis der benyttes en dedikeret server. Det bedste er at opsætte disse systemer til selv at opdatere med sikkerheds opdateringer så de kommer hurtigst muligt på efter frigivelse.

Hold CMS system og plugins opdateret

Hvis der benyttes et eksisterende CMS system som WordPress bør dette også holdes opdateret. Det gælder både selve WordPress core men også plugins og temaer som der er installeret. Typisk er det usikre plugins som ofte er målet og det svage led. I enkelte tilfælde er der set en backdoor i plugins som har været installeret på over 200.000 sider.

Sikre at directories/biblioteker ikke kan skannes

Undgå at der kan skannes efter filer som der ikke direkte benyttes på hjemmesiden. I apache konfiguration tilføj følgende hvilket sikre imod directory skanning.

Options -Indexes

Bloker adgang til kritiske filer

Sikring af filerne imod at blive hentet ned eller uønsket eksekvering, her kan følgende tilføjes til .htaccess og i eksemplet er det wp-config.php fra WordPress som der blokeres adgang til.

<Files wp-config.php>
     Require all denied
</Files>

Blokering af eksekvering i upload folder

Upload af filer bør altid kontrolleres så det kun er rigtige billede filer som kan ligge i en upload mappe. Hvis denne mekanisme omgås bør der blokeres for at der kan eksekveres filer i folderen. Følgende blokere PHP filer i en WordPress upload mappe. Skal tilføjes i apache konfiguration.

<Directory "/var/www/hjemmeside.dk/wp-content/uploads">
     <FilesMatch \.php$>
          Require all denied
     </FilesMatch>
</Directory>

Er blokeringen korrekt vil noget a la det her komme frem

Blokering af filer som ikke er en del af hjemmesiden

Generelt bør filer som ikke er en del af hjemmesiden ikke være online men når der benyttes eksterne plugins kan der følge en del ekstra med som README, licens beskrivelser osv. Selvom disse ikke bør være en sikkerheds risiko kan de blokeres. Følgende blokere for adgang til disse og som tilføjes apache konfiguration.

<LocationMatch ".+\\.(?i:psd|log|cmd|exe|bat|csh|sh|txt|.me)$">
     Require all denied
</LocationMatch>

<LocationMatch "(?i:(?:wp-config\\.bak|\\.wp-config\\.php\\.swp|(?:readme|license|changelog|-config|-sample)\\.(?:php|md|txt|htm|html|php~)))">
     Require all denied
</LocationMatch>

Her blokere vi for .psd, .csh (design filer), .log (en data fil til logning), .cmd, .exe, .bat, .sh som er eksekverer bare filer. Kan justeres efter behov.

I blokerings regel nr. 2, blokere vi for de typiske change log filer samt evt. backups af config fil.

Blokering af skjulte filer

I linux miljø er skjulte filer dem som starter med et punktum. En korrekt konfigureret server bør ikke servere dem til offentligheden så for en sikkerheds skyld opsætter vi vores eget regelsæt til at blokere disse. Typisk vil dette være for .htaccess og .htpassword som er meget almindelige.

<FilesMatch ^(?i:\.ht.*)$>
     Require all denied
</FilesMatch>

Overvågning af hjemmesiden og alarmering

Selvom sikkerheden er i top bør der være overvågning på siden samt alarmering til system administrator.

Scanning af server via antivirus og malware scanner

Serveren bør dagligt scanne alt igennem automatisk for inficerede filer med alarmering til administrator. Et godt værktøj til denne er Immunify som kan scanne serveren igennem. Ejes der egen server er det ikke noget problem at købe og opsætte dette af server administrator men køres der på et webhotel bør lign. service tilbydes af hosting leverandør. Sikre at oprydning også tilbydes af hosting leverandøren.

Scanning af website udefra

En rigtig god indgangsvinkel er at scanne server og hjemmeside udefra så man tester de samme ting af som en hacker ville gøre. Findes der åbenlyse sårbarheder vil de gode værktøjer finde disse og oplyse om hvordan de er nået frem til hullet. Et af de bedste må være Detectify. som gør et rigtigt godt job med at scanne og finde sårbarheder på siderne. Bemærk at siden skal verificeres før der kan skannes og at selve skanningen kan give en høj belastning på serveren. Det anbefales derfor at gøre dette når der er færrest besøgende på siden.

Overvågning via Google Search Console

Hvis din side er oprettet i Google Search Console vil de også løbende holde med om din side indeholder skadelig kode som kan detekteres udefra. Google vil ikke skanne siden for sårbarheder men hvis din hjemmeside indeholder f.eks. skadeligt JS kode som sender brugeren videre til en russisk malware side så vil Google nok opdage det. Se her hvordan Google holder øje. Grafen viser antallet af nuværende infektioner.

Du vil modtage emails fra Google som fortæller at de har fundet skadeligt indhold. Hvis dette sker skal siden ryddes op ASAP. Ja faktisk skal den altid renses ASAP.

Her kan i her se hvordan raten for gentagne infektioner ser ud (kilde Google).

 

Prefix på tabeller i databasen og reducer SQL injection

For CMS systemer såsom WordPress der har faste tabel navne kan det give en fordel at tilføje en tilfældig streng foran tabelnavn.

Et tabelnavn vil få fra wp_users til kdis_wp_users og vil forhindre at en ondsindet bruger som har adgang til databasen vil kunne hente noget fra bruger tabellen uden at kende navnet med prefix. Via SQL injection vil en bruger kunne opnå adgang til databasen og prefix vil netop være med til at reducere mulighederne for brugeren. WordPress plugins som Wordfence kan hjælpe med dette.

Oprydning af hjemmesiden og gendannelse af filer og data

Via et skannings værktøj som Immunify kan der findes de filer som er ændret af hackeren og denne kan også rense dem automatisk. Den fortæller hvilke filer der er inficeret og laver backup af dem før rensning.

Alternativ til skannings værktøj er at søge filerne igennem for den inficerede kode. Da koden kan være meget forskellig og nogle gange ligne valid kode kræver dette lidt øvelse og indeholder stor usikkerhed. PHP kode der er inficeret kan ofte se sådan her ud

<?php eval(gzuncompress(base64_decode('eNqNVutv01YU/1fuokrETUj9iJ...forkortet...O1UcebjkcboO2A1VF0Y18nJo4d2TdNQ')));

da det er en måde at skjule indeholdet på.

Her kan man blot søge hele siden igennem efter denne streng “eval(gzuncompress(base64_decode(” og slette de afsnit som relaterer til dette.

Oprydning er forbundet med risici

Uanset metode til at rydde op kan det være forbundet med en vis risiko da ingen kan garantere at der ikke at opsat en backdoor som endnu ikke er fundet. Derfor kan man som ekstra sikkerhed overskrive CMS system og eksterne plugins med de seneste versioner for på den måde at sikre at en evt. backdoor også vil blive slettet.

Gendannelse af backup

Er der mulighed for at gendanne ud fra en frisk backup kan dette også være en fornuftig mulighed. Der gælder blot det at man bør sikre sig at backup heller ikke er inficeret.

Anbefalingen herfra er daglig backup af både filer og database. En backup kan ligge på samme server men bør kopieres til anden server eller offline medie for at have størst værdi.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *