NAS-sikkerhet for et offentlig nettsted: De 5 lagene vi kjører på Synology

NAS-sikkerhet beskrives vanligvis som en liste over svitsjer i DSM. For en NAS som bare inneholder familiebilder, er den listen nok. Vår gjør noe mer risikabelt: SynoPower Club, en butikk som tar betalinger på 16 språk, betjenes fra en Synology NAS i vårt eget rack, slik at alle skannere og botnett på internett kan banke på døren. Én innstilling ville aldri være nok NAS-sikkerhet for det. Denne NAS Hosting 101-artikkelen går gjennom de fem lagene en forespørsel krysser før den når WordPress, hva hvert lag fanget opp i reelle hendelser i løpet av 2026, og gangene et lag skadet oss i stedet for angriperen.

SynoPower Club-punkt: Jeg jobbet på supportsiden av Synology i årevis, og de kompromitterte maskinene jeg så ble nesten aldri slått av noe smart. De hadde standard administratorkonto fortsatt aktivert, en administrasjonsport videresendt til internett, og ingen annen faktor. God NAS-sikkerhet er stort sett kjedelig arbeid utført i riktig rekkefølge. Det som overrasket meg etter at vi begynte å være vert for vår egen butikk, er hvor mye av jobben som flyttes utenfor NAS-en. Mesteparten av trafikken vi avviser i dag blir sendt bort før den i det hele tatt berører linjen vår.

Hva NAS-sikkerhet betyr når NAS-en er vert for et nettsted #

En privat NAS har én oppgave i sikkerhetsmessig forstand: å holde fremmede unna innloggingssiden. En NAS som er vert for et offentlig nettsted har det motsatte problemet. Fremmede er kundene, og tusenvis av dem må komme seg inn hver dag uten en konto. Spørsmålet endrer seg fra hvem som kan koble til til hva en tilkobling har lov til å be om.

Derfor sluttet vi å tenke på NAS-sikkerhet som en produktfunksjon og begynte å tegne det som en vei. En forespørsel til nettbutikken vår passerer fem punkter, og hver enkelt kan avslå den:

• Kanten. Cloudflare mottar alle forespørsler først og svarer på de fleste av dem fra sin egen cache.
• Ruteren. En Synology-ruter inspiserer hva Cloudflare sender videre og videresender bare de portene vi trenger.
• Den fremre NAS-en. En DSM-maskin avslutter TLS og fungerer som omvendt proxy og e-postserver.
• Virtual DSM-en. WordPress kjører i en container i sin egen Virtual DSM-instans, atskilt fra alt annet.
• Søknaden. WordPress bestemmer selv hva en besøkende kan gjøre på et skjema eller en innloggingsside.

Ingen enkelt lag er til å stole på for å være riktig. Hvert lag er der for den dagen laget foran det er feil, feilkonfigurert eller rett og slett forbigått.

Lag 1: Cloudflare avviser de fleste angrep før de når oss #

God NAS-sikkerhet starter et sted som ikke er NAS-en. Den billigste forespørselen å forsvare seg mot er den som aldri kommer. I løpet av de 24 timene før vi skrev dette, håndterte Cloudflare 78 690 forespørsler for domenet vårt. Den svarte på 57 620 av dem fra hurtigbufferen, stoppet 5590 som uønskede og sendte bare 15 470 videre til opprinnelsesstedet vårt. Fire av fem forespørsler brukte aldri en eneste CPU-syklus på NAS-en.

Vi har Pro-abonnementet og kjører 15 tilpassede brannmurregler pluss to hastighetsgrenser. Hver av dem eksisterer på grunn av en spesifikk dårlig dag. Tre eksempler viser mønsteret:

• Nettskalljegere, 20. juli. På 17 timer logget vi 950 prober for 535 forskjellige PHP-filnavn fra 14 adresser. Blokkering av adresser holdt ikke tritt, så vi snudde logikken: bare de få PHP-inngangspunktene WordPress faktisk bruker er tillatt, og alle andre blir nektet i utkanten.
• Legitimasjonsskannere, 29. august. En bølge fra skybaserte hostingnettverk ba om konfigurasjons- og hemmelige filer mer enn 1400 ganger. Ingen av dem fantes, men hver feil fikk WordPress til å bygge en full feilside, gjennomsnittlig belastning nådde 46 og containeren måtte startes på nytt. Disse stiene er nå blokkert fullstendig, og ubekreftet trafikk fra de store skybaserte nettverkene får en nettleserutfordring.
• Et botnett for å legge til i handlekurven, 31. august. Innen en time kom det 258 forespørsler om å legge til i handlekurven fra nesten like mange forskjellige adresser, omtrent én forespørsel hver, så det var ingenting å blokkere etter adresse. En administrert utfordring på den ene handlingen stoppet det, og ekte nettlesere passerte det uten å legge merke til det.

Cloudflare Turnstile dekker formene brannmuren ikke kan bedømme: registrering, tilbakestilling av passord, kommentarer og kontaktskjemaet. Kontoen som kontrollerer alt dette, og den hos domeneregistratoren vår, krever begge en annen faktor. En angriper som kan endre DNS-en din trenger ikke å ødelegge NAS-en din.

Lag 2: Trusselforebygging på Synology-ruteren #

Det Cloudflare slipper gjennom, ankommer en Synology-ruter som kjører SRM, det andre NAS-sikkerhetslaget. Dette er laget som var i det opprinnelige notatet for denne artikkelen: Trusselforebygging blokkerer nok en bølge. Det er et system for forebygging av inntrenging som sammenligner pakker med kjente angrepssignaturer, og vårt system er satt til å automatisk fjerne treff med høy alvorlighetsgrad i stedet for bare å logge dem.

Den 2. august 2026 utførte én adresse 116 forsøk på en PHP-feil som bare påvirker Windows-servere. Den kunne aldri ha fungert mot oss, og det er poenget med historien: Threat Prevention droppet alle forsøk, og da vi søkte i webserverloggene etterpå, var adressen ikke der i det hele tatt. Angrepet endte på ruteren.

Tre enklere innstillinger på samme boks gjør like mye for NAS-sikkerhet som inspeksjonsmotoren gjør:

• Bare de nødvendige portene videresendes. Nett- og e-postporter går til den fremre NAS-en. DSM-administrasjonsportene og SSH videresendes ikke noe sted.
• Landets regler i brannmuren. En kort liste over regioner vi ikke selger til blir avvist før noen søknad ser pakken.
• Sikker tilgang. DNS og nettfiltrering hindrer maskiner i nettverket i å kommunisere med kjente ondsinnede domener, noe som er viktig den dagen noe inni allerede er infisert.

Lag 3: NAS-sikkerhet i DSM, fra 2FA til automatisk blokkering #

Front-NAS-en er det første Synology-systemet en ekstern pakke kan nå, så det er her klassiske NAS-sikkerhetsråd gjelder fullt ut. Innstillingene våre er bevisst uoriginale:

• Standardkontoene er deaktivert. Både administrator og gjest er slått av. Alle automatiserte påloggingsangrep starter med disse to navnene.
• Administratorer kan ikke logge på med bare et passord. Tofaktorautentisering håndheves for hele administratorgruppen, og Adaptive MFA ber om ekstra bevis når en pålogging ser uvanlig ut.
• Automatisk blokkering er på. Ti mislykkede pålogginger innen fem minutter blokkerer kildeadressen, og blokkeringen utløper ikke av seg selv.
• DSM-brannmuren er aktivert i tillegg til ruterreglene, så en feil på én enhet er ikke et hull i begge.
• Sikkerhetsoppdateringer installeres av seg selv på denne maskinen. På Virtual DSM-en som driver verkstedet blir vi bare varslet, og vi oppdaterer manuelt etter å ha tatt et øyeblikksbilde.

To vaner er like viktige for NAS-sikkerhet som svitsjene. Vi når DSM utenfra via QuickConnect, eller vi når den ikke i det hele tatt, og det er derfor ingen administrasjonsport trenger å være åpen. Og midlertidige hjelpere får midlertidige kontoer: Når en entreprenør eller en AI-agent trenger administratortilgang, oppretter vi en navngitt konto, lar arbeidet bli ferdig og deaktiverer den samme dag.

Lag 4: En Virtual DSM som inneholder skaden #

WordPress kjører ikke på front-NAS-en. Den kjører i en container inne i en Virtual DSM, en komplett andre kopi av DSM som driftes av Virtual Machine Manager. E-post, reverse proxy og nettbutikken ligger derfor i separate systemer med separate kontoer og separat lagring.

Isolering er den delen av NAS-sikkerhet som ikke prøver å forhindre et innbrudd. Det begrenser hva et innbrudd er verdt. Hvis en WordPress-plugin noen gang blir kompromittert, lander angriperen i en container med en minnegrense, inne i en virtuell maskin som ikke inneholder postbokser og ingen sikkerhetskopier. Og fordi hele maskinen er én enkelt fil til Virtual Machine Manager, tar et øyeblikksbilde før hver risikabel endring sekunder, og det tar noen få minutter å rulle tilbake.

Virtual Machine Manager inkluderer én Virtual DSM-instans gratis på støttede modeller, som er nok til å prøve dette oppsettet. Ytterligere instanser krever en lisens hver.

Lag 5: Hva WordPress fortsatt må gjøre selv #

De ytre NAS-sikkerhetslagene bedømmer pakker og forespørsler. Bare applikasjonen vet hva en forespørsel betyr, så noen få forsvarsmekanismer må eksistere i WordPress:

• En annen faktor for hver administratorpålogging, samme regel som i DSM.
• Stille grenser for tilbakestilling av passord. Gjentatte forespørsler om tilbakestilling av én konto blir droppet uten en feilmelding, fordi en nyttig feilmelding forteller en angriper at kontoen finnes.
• Ingen brukerliste for fremmede. Standardmåtene for å liste opp WordPress-brukernavn er stengt.
• Tor blir nektet på skjemaer. I september brukte noen kontaktskjemaet vårt til å oversvømme andre med bekreftelses-e-poster, og alle innsendinger kom via Tor. Det fungerer fortsatt å lese nettstedet via Tor. Det fungerer ikke å sende inn et skjema.
• En billig feilside. En forespørsel om noe som ikke finnes, får et svar på én kilobyte i stedet for en full temabasert side på 148 kilobyte.

Tor-hendelsen har sin egen beskrivelse: E-postbombing via kontaktskjema.

Legge til NAS-sikkerhet i fire trinn, utenfra og inn #

Hvis du starter fra en NAS med standardinnstillinger, er rekkefølgen på NAS-sikkerhetsarbeidet viktigere enn verktøyene. Arbeid utenfra og inn, og test nettstedet etter hvert trinn.

Et femte trinn gjelder alle som fullfører de fire første: begrens webportene på ruteren til adresseområdene Cloudflare publiserer. Det er den delen av NAS-sikkerheten som oftest legges til senere. Inntil det er gjort, er en proxy et forslag. Alle som lærer den virkelige adressen til linjen, kan gå rundt den og bare se de indre lagene.

Når en NAS-sikkerhetsregel skader deg i stedet #

Enhver regel som stopper en angriper kan stoppe en kunde, og feilen er stille. Dette er de tre gangene vårt eget NAS-sikkerhetsoppsett kostet oss noe.

I juli blokkerte en regel rettet mot robotsøkeprogrammer også kontrollen Google bruker for å gjennomgå handlelister, og 39 produktlister ble ikke godkjent før vi koblet de to hendelsene sammen. Siden den gang har hver robotregel et eksplisitt unntak for verifiserte robotsøkeprogrammer.

I september prøvde en bedriftskunde i USA å betale fire ganger i løpet av to dager, og hver gang mislyktes det uten feil på noen av sidene. Selskapet hans ruter all nettrafikk gjennom en sikkerhetsgateway i skyen, så for brannmuren vår så han ut som skannerne fra augustbølgen og fikk en utfordring midt i betalingen. Bedriftskjøpere kommer ofte fra de samme skynettverkene som angripere leier. Vi snevret inn regelen slik at folk som allerede handler får være i fred.

Og trusselforebyggingsmotoren som presterte så bra 2. august sluttet å sende utgående trafikk for e-postserveren vår etter det samme utbruddet. E-posten ble stående i kø til ruteren ble startet på nytt. En inspeksjonsmotor i ruten er enda en ting som kan feile, og da vår feilet, ble den lukket.

Lærdommen for NAS-sikkerhet er ikke å fjerne lag. Det er å skrive ned hvorfor hver regel eksisterer, se på hva den blokkerte i løpet av den første uken, og foretrekke en utfordring fremfor en blokkering når en ekte person kan være i den andre enden.

Sikkerhetskopier er laget som fungerer etter at de andre feiler #

Ingen NAS-sikkerhet gjør gjenoppretting valgfritt. Maskinvarefeil, oppdateringer går galt, og en administrator klokken ett om natten er farligere enn de fleste botnett. Vi beholder tre typer kopier: øyeblikksbilder på NAS-en for rask tilbakestilling, en planlagt eksport av hele den virtuelle maskinen som er synkronisert med skylagring, og en separat ekstern sikkerhetskopiering av dataene.

Eksporten av virtuelle maskiner beskrives trinn for trinn i VMM-sikkerhetskopi til Google Disk, og klyngen som er vert for alt det i vårt 3-noders VMM Pro-oppsett.

Begrensninger for dette NAS-sikkerhetsoppsettet #

Dette er et lite selskap som beskriver hva det driver, ikke en standard. Noen ærlige begrensninger:

NAS-sikkerheten vår er avhengig av Cloudflare. Hvis nettverket deres har en dårlig dag, har vi det også, og den betalte planen er en del av den månedlige kostnaden for nettstedet.

Den ble bygget ved å reagere. De fleste av reglene våre ble skrevet dagen etter en hendelse. Et større team ville ha utført trusselmodellering først, og ville ha funnet noen av disse hullene før en angriper gjorde det.

NAS-sikkerhet trenger vedlikehold. Regler som viser spesifikke stier eller nettverk blir foreldet, og en regel ingen husker er et fremtidig driftsavbrudd. Vi gjennomgår listen hver gang nettstedstrukturen endres.

Og det beskytter en butikk, ikke en bank. Hvis du lagrer helsejournaler eller kortnumre på en NAS, trenger du mer enn denne artikkelen, og det starter med en profesjonell gjennomgang.

Ofte stilte spørsmål #

Referanser og videogjennomganger #

• Synology: hvordan legge til ekstra NAS-sikkerhet, den offisielle sjekklisten for kontoer, brannmur og oppdateringer.
• Hjelp med Synology SRM-trusselforebygging, som beskriver alvorlighetsnivåer og retningslinjene for automatisk sletting.
• Hjelp med Synology DSM 2-faktor-autentisering, inkludert hvordan man håndhever det for en gruppe.
• Cloudflare WAF-tilpassede regler, regelspråket bak kantlaget.
• Cloudflare IP-områder, listen som skal tillates på ruteren din når du låser opprinnelsen.

Disse Synology-videoene dekker DSM-siden av NAS-sikkerhet, fra den generelle sjekklisten til den andre faktoren og brukertillatelser.

Mer fra denne serien om å hoste en bedrift på en NAS: fikse avvist e-post med en SMTP-relé. Ønsker du å skille ut dine egne tjenester slik vi gjør? Start med en Virtual DSM-lisens, eller bla gjennom alle lisenser på SynoPower Club.