Videre til indhold 
Die Web-firewall Plesk beskytter hjemmesider specifikt mod cyberangreb som SQL-injektion og cross-site scripting (XSS). I løbet af få trin kan du opsætte en effektiv sikkerhedsbarriere i Plesk, der genkender og afværger både automatiserede trusler og manuelle angreb.
Centrale punkter
- SQL-indsprøjtningForhindrer manipulation af databasen gennem ondsindede forespørgsler.
- XSS-forsvarBlokerer indsprøjtningen af JavaScript i formularer og URL'er.
- ModSecurityKernekomponent i Plesk WAF til registrering af angreb og forsvar.
- Firewall-regler: Kan tilpasses til kun at tillade nødvendige forbindelser.
- SikkerhedsopdateringerRegelmæssig installation af patches beskytter mod kendte sårbarheder.
Login og første adgang til firewall-konfigurationen
Jeg logger ind på Plesk-panelet, kalder afsnittet "Værktøjer og indstillinger" frem via sidepanelet og finder punktet "Firewall" der. Hvis firewallen stadig er deaktiveret, aktiverer jeg den direkte ved hjælp af skyderen. Fra dette øjeblik blokerer Plesk alle indgående forbindelser, som ikke udtrykkeligt er tilladt. Det reducerer straks risikoen for uønsket adgang. For standardiserede hostingscenarier anbefales det først at kontrollere de foruddefinerede firewall-regler omhyggeligt.
Plesk leveres med fornuftige standardindstillinger for webservere, e-mail, FTP og SSH. Alligevel justerer jeg reglerne manuelt, så kun porte, der virkelig er brug for, forbliver åbne - f.eks. 443 til HTTPS eller 22 til SSH. Det er værd at tænke grundigt over, hvilke tjenester der rent faktisk skal være offentligt tilgængelige. Overflødige tjenester er potentielle indgangsporte for angribere, og derfor holder jeg mig strengt til princippet om minimering.
Egne regler: Finjustering af sikkerhed
Vil jeg have Specifikke forbindelser Jeg kan oprette mine egne firewall-regler. Jeg klikker på "Tilføj regel", indtaster et meningsfuldt navn som "Admin SSH internal only", angiver protokollen (f.eks. TCP), porten (f.eks. 22 for SSH) og den tilladte kildeadresse. Dette sikrer, at adgang kun er tilladt via specificerede IP'er.
Jeg gentager denne proces for andre følsomme tjenester, som f.eks. fjernadgang til databaser eller særlige API-slutpunkter. Sådanne ekstra regler reducerer den potentielle angrebsflade massivt. Hvis jeg driver mange VM'er eller ønsker at sikre flere underdomæner, giver segmenterede regler pr. website mening. Firewallen giver mig mulighed for at tildele specifikke regler til individuelle kunder eller projekter, så jeg har en klar logisk adskillelse mellem forskellige hostingmiljøer.
Især i en kompleks struktur med flere tjenester er det nyttigt at organisere firewall-reglerne. Jeg giver dem meningsfulde navne og nummererer dem, hvis det er nødvendigt, for at bevare overblikket. God dokumentation af alle regler er afgørende, da det er den eneste måde, jeg hurtigt kan tjekke, hvorfor en tjeneste er blokeret eller tilladt i tvivlstilfælde. Jeg logger også alle regelændringer: I tilfælde af problemer kan jeg nemt finde ud af, om en ny eller ændret regel er årsagen.
Avanceret firewall-styring: proaktiv overvågning og filtrering
En anden måde at øge sikkerheden på er ved proaktivt at overvåge trafikken. Det gør jeg ved at tjekke serverens logfiler med jævne mellemrum. Alarmer, der f.eks. indikerer portscanninger eller mistænkelige forespørgsler, viser, hvilke angrebsmønstre der i øjeblikket forekommer gentagne gange. Bots kan ofte forsøge at få adgang til en bestemt port eller URL flere hundrede gange inden for få sekunder. Plesk-firewallen sammen med ModSecurity hjælper mig med automatisk at genkende og afværge sådanne angreb.
Ved ikke kun at konfigurere firewallen statisk, men også aktivt overvåge den, kan jeg genkende tendenser eller nye angrebsteknikker på et tidligt tidspunkt. For eksempel kan det være nyttigt permanent at blokere tilbagevendende IP-blokke, som kun sender ondsindet trafik. For at gøre dette opretter jeg en liste over mistænkelige IP'er eller IP-intervaller for at spare mig selv for arbejde, da et angreb, der er blevet blokeret med succes én gang, ofte forsøges igen fra det samme IP-interval.
Nogle gange er det også tilrådeligt at bruge en rate limit-funktionalitet. Selvom Plesk ikke har en integreret løsning til hastighedsgrænser for anmodninger, kan jeg i kombination med andre værktøjer eller særlige ModSecurity-regler forhindre visse IP-adresser i at sende for mange anmodninger inden for en kort periode. Sådanne foranstaltninger er en effektiv tilføjelse til de klassiske firewall-regler og hjælper med at minimere DDoS-tilgange (Distributed Denial of Service).
Konfigurer ModSecurity: Sæt webapplikationsfirewallen korrekt op
Jeg åbner menupunktet "Web Application Firewall (ModSecurity)" i Plesk. Her vælger jeg først regelsættet - OWASP Core Rule Set er gratis og dækker pålideligt almindelige trusler. I "dedikeret tilstand" kan jeg tilpasse, hvilke regler der er aktive. Jeg er især opmærksom på reglerne mod SQL-injektion og cross-site scripting.
Jeg satte tilstanden til Tvinge (håndhævelse), så det ikke kun logges, men også aktivt blokeres. ModSecurity WAF reagerer straks på typiske angrebsmønstre som f.eks. manipulerede anmodninger, usædvanlige parameterlængder eller mistænkelige specialtegn. Yderligere oplysninger om den optimale Plesk-konfiguration kan findes i denne Firewall-instruktioner til Plesk.
Hvis du vil have en endnu mere skræddersyet konfiguration, kan du også starte med en såkaldt "simulation mode" (kun detektion) og først observere, hvilke anmodninger der genkendes som mistænkelige af reglerne. Efter en vis testfase indstiller jeg så systemet til streng "håndhævelsestilstand". Dette reducerer fejlkonfigurationer, og funktionaliteten i din egen webapplikation er altid i fokus. For nogle gange kan det ske, at legitime applikationer eller plugins bruger mønstre, der ligner en WAF-regel, hvilket fører til falske alarmer. Med det mellemliggende trin i simuleringstilstand genkender jeg sådanne tilfælde i god tid.
Genkendelse og forebyggelse af SQL-injektion
SQL-injektion er en af de farligste sikkerhedssårbarheder i moderne webapplikationer. Angribere bruger forberedte formularfelter eller URL-parametre til at forsøge at få direkte adgang til databaseindhold. Webfirewallen genkender typiske kommandoer som "SELECT * FROM" eller "UNION ALL" og blokerer anmodningen på applikationsniveau.
Plesk giver uafhængig beskyttelse her takket være den aktiverede WAF i kombination med regelmæssigt integrerede opdateringer. Jeg tjekker regelmæssigt, om alle ModSecurity-regler er aktiverede og opdaterede. Regler, der kontrollerer databaseinteraktioner med POST/GET-parametre, er særligt vigtige. Politikker, der kan håndhæves, som f.eks. whitelisting af SQL-forespørgsler, reducerer risikoen yderligere.
En god oversigt over, hvordan Plesk-sikkerhedshuller lukkes, kan findes i artiklen Sikkerhedshuller i Plesk lukket. Jeg har lært, at selv den mest sikre firewall kun er effektiv, hvis selve webapplikationerne er pålideligt programmeret. Bagdøre eller usikre plugins kan gøres sværere, men kan ikke kompenseres fuldt ud, hvis der er alvorlige sårbarheder i koden.
Effektivt forsvar mod XSS-angreb
XSS (cross-site scripting) skader ikke kun hjemmesiden, men eksponerer også brugerne direkte. Formularer, kommentarfelter eller profilinputmasker er særligt ofte berørt. Den Plesk Firewall genkender farlige tegnkombinationer som "" eller event-drevne GET-kald takket være ModSecurity. Jeg tilføjer også mine egne regler, hvis visse inputfelter er særligt følsomme.
Jeg sikrer, at valideringer på serversiden træder i kraft for alle input - foranstaltninger på klientsiden er ikke tilstrækkelige. WAF'en kan ændres, så parameterværdier eller uventede metoder udtrykkeligt forbydes. Regelmæssige eksterne sikkerhedsscanninger hjælper med at afsløre tidligere uopdagede sårbarheder.
Især i omfattende webapplikationer, som f.eks. dem med community-funktioner, kan XSS nemt indføres via kommentarfunktioner. Derfor bruger jeg en kombination af escaping på serversiden, filtrering af potentielt farlige tegn og en begrænsning til tilladte HTML-tags (hvis det overhovedet er nødvendigt). Et eksempel er begrænsningen af brugerkommentarer til ren tekst, så ingen HTML eller JavaScript er tilladt. En WAF-regel kan også blokere sådanne injektioner.
Yderligere lag af beskyttelse: URL-hærdning og sikre adgangskoder
For at øge beskyttelsen yderligere er det værd at se på yderligere hærdningsmetoder. URL-hærdning betyder f.eks., at visse administrationsstier eller login-sider kun er tilgængelige via definerede IP-intervaller. Det gør det sværere for angribere at lave brute force-angreb eller gætte sig til tilfældige logins. Jeg kan f.eks. flytte administratorområdet i min webapplikation til et separat subdomæne og kun dele det med min egen kontor-IP.
Et andet kritisk punkt er adgangskoder. Selv den bedste firewall er ikke til megen nytte, hvis der bruges trivielle adgangskoder på login-siden. Derfor konfigurerer jeg strenge krav til password-styrke i Plesk og bruger to-faktor-autentificering (2FA), hvor det er muligt. Dette forhindrer automatiserede angreb, der regelmæssigt prøver millioner af kombinationer af brugeradgangskoder. En solid adgangskodepolitik supplerer derfor firewall-reglerne og giver en yderligere beskyttelseslinje.
Sikkerhedsforanstaltninger til langsigtet beskyttelse
Jeg åbner kun vigtige porte, dokumenterer alle firewall-ændringer korrekt og bruger to-faktor-autentificering til at logge ind på Plesk-panelet. Jeg gemmer også en Komplet backupat komme hurtigt online igen i en nødsituation. Ved konstant at analysere logfiler genkender jeg usædvanlige adgangsmønstre - f.eks. gentagne anmodninger til administratorområder eller mistænkelige IP-adresser.
Jeg har opsummeret de vigtigste best practices i denne tabel:
| Anbefaling | Beskrivelse af |
|---|---|
| Minimering af havnen | Lad kun de nødvendige porte være åbne (f.eks. 443, 22) |
| To-faktor-login | Beskyttelse af login med Authenticator-appen |
| Opdateringer og rettelser | Regelmæssigt installerede sikkerhedsopdateringer |
| Overvågning | Overvåg logfiler og trafikadfærd |
| Strategi for sikkerhedskopiering | Regelmæssige komplette sikkerhedskopier af data |
Mange af disse punkter burde være obligatoriske, hvis en hjemmeside skal køre stabilt på lang sigt. Især opdateringer og programrettelser bliver ofte forsømt, selv om de kan lukke kritiske sårbarheder i populære indholdsstyringssystemer (CMS). En firewall kan genkende angrebsmønstre, men hvis en upatchet komponent giver let adgang, er den overordnede beskyttelse i fare. Jeg anbefaler derfor at tjekke hver måned eller endnu oftere, om der er vigtige sikkerhedsopdateringer til operativsystemet, selve Plesk eller installerede plugins.
Minimér fejl og undgå svigt
Jeg tester effektiviteten af alle nye regler, før jeg anvender dem produktivt. Et regelsæt, der utilsigtet er for restriktivt, kan ellers låse mig ude. Hvis det sker, bruger jeg "paniktilstand" til at blokere al ekstern adgang - kun fysisk adgang via KVM eller VNC er stadig mulig.
Og hvis intet virker, nulstiller jeg firewallen til "Standard" via Plesk-backend - det giver mig mulighed for at rette op på eventuelle alvorlige fejlindstillinger. Især hostingudbydere tilbyder ofte en webkonsol til nødforbindelser - det hjælper også i kritiske øjeblikke.
For yderligere at reducere fejlkilder er det tilrådeligt at bruge et testmiljø, før man endeligt anvender en regel. Der kan jeg tjekke, om min webapplikation fungerer normalt, mens firewallen allerede blokerer for alle potentielle angreb. Efter en vellykket test overfører jeg konfigurationen til live-miljøet. På den måde undgår jeg nedetid og irritation hos brugere eller kunder, som reagerer følsomt på enhver afbrydelse.
Optimer Plesk firewall til enkelt- og multi-hosting
Uanset om det er en eller mange hjemmesider - jeg tilpasser firewallindstillingerne separat for hver hostingstruktur. Strenge regler er især vigtige for delt hosting med flere brugerkonti. Jeg segmenterer undersystemer, indstiller adgangen til administrationsgrænseflader som phpMyAdmin til specifikke IP'er og isolerer effektivt domæner fra hinanden.
Inkluderingen af avancerede beskyttelsesmekanismer som Cloudflare på DNS- eller CDN-niveau giver yderligere beskyttelse. Hvordan Integrer Cloudflare med Plesk er vist i den linkede artikel.
Især i et multi-hosting-miljø kan det ske, at et domæne er sårbart og belaster hele systemet på grund af regelmæssige angreb. I dette tilfælde hjælper det at indføre strengere sikkerhedsregler for det pågældende domæne, aktivere yderligere WAF-moduler eller opsætte din egen IP-blokering. På den måde forbliver andre domæners performance stort set upåvirket, og jeg behøver ikke at træffe omfattende modforanstaltninger for alle kunder.
Langsigtet protokolanalyse og reaktion på hændelser
Ud over akut beskyttelse i tilfælde af angreb spiller komplet dokumentation en stadig vigtigere rolle. Jeg anbefaler, at man ikke kun kigger logfiler igennem sporadisk, men også bruger professionelle overvågningsløsninger eller analyseværktøjer. Det giver mig et overblik over, hvornår og hvor ofte bestemte angreb blev forsøgt, og giver mig mulighed for at udarbejde pålidelige statistikker, der kan hjælpe mig med at træffe beslutninger.
I tilfælde af en hændelse, f.eks. når et domæne er blevet kompromitteret, analyserer jeg logfilerne for at rekonstruere angrebsvektoren så præcist som muligt. Det giver mig mulighed for at se, hvilken regel der virkede, eller hvorfor den fejlede. På baggrund af disse oplysninger tilpasser jeg regelsættet og minimerer dermed risikoen for, at et identisk angreb gentages. Det er en kontinuerlig proces: I takt med at trusselsbilledet ændrer sig, justerer jeg løbende firewall- og WAF-indstillingerne.
En nyttig tilføjelse her er en central syslog-server, hvortil alle relevante hændelser rapporteres. Hvis der er nogle iøjnefaldende mønstre, sender jeg automatisk advarsler via e-mail eller messenger-system. På den måde kan jeg bevare overblikket og reagere hurtigt uden at skulle tjekke logfilerne manuelt, når der opstår problemer.
Øget sikkerhed for almindelige angrebspunkter
Visse tjenester som e-mail (SMTP, IMAP), FTP eller SSH er klassiske indgangspunkter for automatiserede angreb. Derfor fokuserer jeg især på disse porte og regulerer så strengt som muligt, hvilke IP-intervaller forespørgslerne må komme fra. For SSH har jeg fundet det nyttigt at ændre standardporten 22 og indstille den til en anden port. Selv om det ikke i sig selv øger den grundlæggende sikkerhed, er mange automatiske angreb eksplicit rettet mod port 22 og bliver derfor afværget på et tidligt tidspunkt.
Hvis servertjenesten, f.eks. FTP, ikke længere er opdateret på grund af krypteringskravene, er det bedre at bruge SFTP. Så kan jeg lukke den gamle port helt. Det holder angrebspunkterne på et minimum og reducerer risikoen for kompromittering. Med Plesk-firewallen kan jeg nemt se, hvilken port der er aktiv, og hvilke foranstaltninger der træder i kraft, så snart der kommer en mistænkelig anmodning.
Sikker opsætning med Plesk-firewall og målrettet konfiguration
Med den webapplikationsfirewall Med Plesk og konsekvent regelvedligeholdelse kan jeg pålideligt beskytte mine hjemmesider mod angreb som SQL-injektion eller cross-site scripting. Kombinationen af grundlæggende firewallbeskyttelse, ModSecurity-tilpasning og de seneste sikkerhedsopdateringer gør Plesk til et sikkert værktøj til daglig hosting.
For mig er det vigtigt at tjekke systemet regelmæssigt, tilføje regler og dokumentere firewall-indtastninger. Det sikrer, at den beskyttende effekt opretholdes på lang sigt - uanset om der er tale om en lille blog eller en travl virksomhedsplatform. Med en struktureret tilgang, fornuftig finjustering og fremsynede overvågningssystemer kan jeg øge sikkerheden på lang sigt og undgå ubehagelige hændelser. I sidste ende er det nødvendigt med en holistisk tilgang, der holder øje med både teknologi og organisation - Plesk giver det rette fundament for dette.
