NAS-säkerhet för en offentlig webbplats: De 5 lagren vi kör på Synology

NAS-säkerhet brukar beskrivas som en lista med switchar inuti DSM. För en NAS som bara lagrar familjefoton räcker den listan. Vår gör något mer riskabelt: SynoPower Club, en butik som tar emot betalningar på 16 språk, hanteras från en Synology NAS i vårt eget rack, så varje skanner och botnät på internet kan knacka på dörren. En inställning skulle aldrig vara tillräckligt med NAS-säkerhet för det. Den här artikeln om NAS Hosting 101 går igenom de fem lager som en förfrågan passerar innan den når WordPress, vad varje lager fångade i verkliga incidenter under 2026, och de gånger ett lager skadade oss istället för angriparen.

SynoPower Club-punkt: Jag arbetade på supportsidan av Synology i flera år, och de komprometterade maskinerna jag såg blev nästan aldrig besegrade av något smart. De hade fortfarande standardadministratörskontot aktiverat, en hanteringsport vidarebefordrad till internet, och ingen andra faktor. Bra NAS-säkerhet är mestadels tråkigt arbete som utförs i rätt ordning. Det som förvånade mig efter att vi började vara värd för vår egen butik är hur mycket av jobbet som flyttas utanför NAS:en. Det mesta av trafiken vi avvisar idag avvisas innan den ens når vår linje.

Vad NAS-säkerhet innebär när NAS-enheten är värd för en webbplats #

En privat NAS har en enda uppgift ur säkerhetssynpunkt: att hålla främlingar borta från inloggningssidan. En NAS som är värd för en offentlig webbplats har motsatt problem. Främlingar är kunderna, och tusentals av dem måste ta sig in varje dag utan ett konto. Frågan ändras från vem som får ansluta till vad en anslutning får begära.

Därför slutade vi tänka på NAS-säkerhet som en produktfunktion och började rita upp det som en väg. En förfrågan till vår butik passerar fem punkter, och var och en kan avvisa den:

• Kanten. Cloudflare tar emot varje förfrågan först och svarar på de flesta av dem från sin egen cache.
• Routern. En Synology-router inspekterar vad Cloudflare skickar vidare och vidarebefordrar endast de portar vi behöver.
• Den främre NAS-enheten. En DSM-maskin avslutar TLS och fungerar som omvänd proxy och e-postserver.
• Virtual DSM. WordPress körs i en container inuti sin egen Virtual DSM-instans, förutom allt annat.
• Applikationen. WordPress bestämmer självt vad en besökare får göra på ett formulär eller en inloggningssida.

Inget enskilt lager är pålitligt. Varje lager finns där för den dag lagret framför det är fel, felkonfigurerat eller helt enkelt förbisett.

Lager 1: Cloudflare avvisar de flesta attacker innan de når oss #

Bra NAS-säkerhet börjar någonstans som inte är NAS:en. Den billigaste förfrågan att försvara sig mot är den som aldrig kommer fram. Under de 24 timmarna innan vi skrev detta hanterade Cloudflare 78 690 förfrågningar för vår domän. Den besvarade 57 620 av dem från sin cache, stoppade 5 590 som oönskade och skickade endast 15 470 vidare till vår ursprungskälla. Fyra av fem förfrågningar använde aldrig en enda CPU-cykel på NAS:en.

Vi har Pro-planen och kör 15 anpassade brandväggsregler plus två hastighetsgränser. Var och en av dem existerar på grund av en specifik dålig dag. Tre exempel visar mönstret:

• Webshelljägare, 20 juli. På 17 timmar loggade vi 950 sonderingar för 535 olika PHP-filnamn från 14 adresser. Att blockera adresser kunde inte hålla jämna steg, så vi vände på logiken: bara de få PHP-ingångspunkter som WordPress verkligen använder är tillåtna, och alla andra nekas vid kanten.
• Autentiseringsskannrar, 29 augusti. En våg från molnnätverk bad om konfigurations- och hemliga filer mer än 1 400 gånger. Inga felmeddelanden fanns, men varje fel fick WordPress att bygga en fullständig felsida, belastningsgenomsnittet nådde 46 och containern var tvungen att startas om. Dessa sökvägar är nu blockerade helt och hållet, och overifierad trafik från de stora molnnätverken får en webbläsarutmaning.
• Ett botnät för att lägga till i varukorgen, 31 augusti. Inom en timme kom 258 förfrågningar om att lägga till i varukorgen från nästan lika många olika adresser, ungefär en förfrågan vardera, så det fanns inget att blockera efter adress. En hanterad utmaning på just den åtgärden stoppade det, och riktiga webbläsare skickade det utan att märka det.

Cloudflare Turnstile täcker de former som brandväggen inte kan bedöma: registrering, lösenordsåterställning, kommentarer och kontaktformuläret. Kontot som styr allt detta, och det hos vår domänregistrator, kräver båda en andra faktor. En angripare som kan ändra din DNS behöver inte bryta din NAS.

Nivå 2: Hotförebyggande åtgärder på Synology-routern #

Allt som Cloudflare släpper igenom når en Synology-router som kör SRM, det andra NAS-säkerhetslagret. Detta är lagret som fanns i den ursprungliga anteckningen för den här artikeln: Hotdetektering blockerar ytterligare en våg. Det är ett intrångsskyddssystem som jämför paket med kända attacksignaturer, och vårt system är inställt på att automatiskt eliminera matchningar med hög allvarlighetsgrad istället för att bara logga dem.

Den 2 augusti 2026 utförde en adress 116 försök på en PHP-brist som bara drabbar Windows-servrar. Den kunde aldrig ha fungerat mot oss, och det är poängen med historien: Threat Prevention stoppade alla försök, och när vi sökte i webbserverns loggfiler efteråt fanns adressen inte alls där. Attacken slutade vid routern.

Tre enklare inställningar på samma låda gör lika mycket för NAS-säkerheten som inspektionsmotorn gör:

• Endast nödvändiga portar vidarebefordras. Webb- och e-postportar går till den främre NAS-servern. DSM-hanteringsportarna och SSH vidarebefordras inte någonstans.
• Landets regler i brandväggen. En kort lista över regioner vi inte säljer till nekas innan någon ansökan ser paketet.
• Säker åtkomst. DNS och webbfiltrering hindrar maskiner i nätverket från att kommunicera med kända skadliga domäner, vilket spelar roll den dagen något inuti redan är infekterat.

Nivå 3: NAS-säkerhet inuti DSM, från 2FA till automatisk blockering #

Den främre NAS-enheten är det första Synology-systemet som ett externt paket kan nå, så det är här klassiska NAS-säkerhetsråd gäller fullt ut. Våra inställningar är avsiktligt ooriginella:

• Standardkontona är inaktiverade. Både administration och gäst är avstängda. Varje automatiserad inloggningsattack börjar med dessa två namn.
• Administratörer kan inte logga in med enbart ett lösenord. Tvåfaktorsautentisering tillämpas för hela administratörsgruppen, och Adaptive MFA ber om extra bevis när en inloggning ser ovanlig ut.
• Automatisk blockering är på. Tio misslyckade inloggningar inom fem minuter blockerar källadressen, och blockeringen upphör inte att gälla av sig själv.
• DSM-brandväggen är aktiverad utöver routerns regler, så ett misstag på en enhet är inte ett hål i båda.
• Säkerhetsuppdateringar installeras av sig själva på den här maskinen. På Virtual DSM som driver butiken får vi bara aviseringar, och vi uppdaterar manuellt efter att ha tagit en ögonblicksbild.

Två vanor är lika viktiga för NAS-säkerhet som switcharna. Vi når DSM utifrån via QuickConnect eller inte alls, vilket är anledningen till att ingen hanteringsport behöver vara öppen. Och tillfälliga medhjälpare får tillfälliga konton: när en entreprenör eller en AI-agent behöver administratörsåtkomst skapar vi ett namngivet konto, låter arbetet slutföras och inaktiverar det samma dag.

Lager 4: En Virtual DSM som innehåller skadan #

WordPress körs inte på den främre NAS:en. Det körs i en container inuti en Virtual DSM, en komplett andra kopia av DSM som hostas av Virtual Machine Manager. E-post, omvänd proxyn och webbutiken finns därför i separata system med separata konton och separat lagring.

Isolering är den del av NAS-säkerhet som inte försöker förhindra ett intrång. Det begränsar vad ett intrång är värt. Om ett WordPress-plugin någonsin komprometteras, landar angriparen i en container med en minnesgräns, inuti en virtuell maskin som inte innehåller några postlådor och inga säkerhetskopior. Och eftersom hela maskinen är en enda fil till Virtual Machine Manager, tar en ögonblicksbild före varje riskabel ändring några sekunder och en återställning tar några minuter.

Virtual Machine Manager inkluderar en Virtual DSM-instans gratis på modeller som stöds, vilket räcker för att prova den här layouten. Ytterligare instanser kräver en licens per instans.

Lager 5: Vad WordPress fortfarande måste göra själv #

De yttre NAS-säkerhetslagen bedömer paket och förfrågningar. Endast applikationen vet vad en förfrågan betyder, så några försvar måste finnas kvar i WordPress:

• En andra faktor för varje administratörsinloggning, samma regel som i DSM.
• Tysta gränser för lösenordsåterställningar. Upprepade återställningsförfrågningar för ett konto ignoreras utan felmeddelande, eftersom ett användbart felmeddelande informerar en angripare om att kontot finns.
• Ingen användarlista för främlingar. Standardsätten för att lista WordPress-användarnamn är stängda.
• Tor nekas på formulär. I september använde någon vårt kontaktformulär för att översvämma andra med bekräftelsemejl, och varje bidrag kom via Tor. Att läsa webbplatsen via Tor fungerar fortfarande. Att skicka in ett formulär fungerar inte.
• En billig felsida. En förfrågan om något som inte existerar får ett svar på en kilobyte istället för en fullständig temansida på 148 kilobyte.

Tor-incidenten har sin egen beskrivning: E-postbombning via kontaktformulär.

Lägga till NAS-säkerhet i fyra steg, utifrån och in #

Om du börjar från en NAS med standardinställningar spelar ordningen på ditt NAS-säkerhetsarbete större roll än verktygen. Arbeta utifrån och in och testa webbplatsen efter varje steg.

Ett femte steg tillhör alla som slutför de fyra första: begränsa webbportarna på routern till de adressintervall som Cloudflare publicerar. Det är den del av NAS-säkerheten som oftast lämnas till senare. Tills dess är en proxy ett förslag. Den som får reda på linjens verkliga adress kan gå runt den och bara se de inre lagren.

När en NAS-säkerhetsregel skadar dig istället #

Varje regel som stoppar en angripare kan stoppa en kund, och felet är tyst. Det här är de tre gånger vår egen NAS-säkerhetsinstallation kostade oss något.

I juli blockerade en regel riktad mot sökrobotar även den kontroll som Google använder för att granska shoppingannonser, och 39 produktannonser godkändes inte innan vi kopplade ihop de två händelserna. Sedan dess har varje botregel gjort ett uttryckligt undantag för verifierade sökrobotar.

I september försökte en företagskund i USA betala fyra gånger under två dagar och misslyckades varje gång utan fel på någon av sidorna. Hans företag dirigerar all webbtrafik genom en molnbaserad säkerhetsgateway, så för vår brandvägg såg han ut som skannrarna från augustivågen och fick en utmaning mitt i kassan. Företagsköpare kommer ofta från samma molnnätverk som angripare hyr. Vi begränsade regeln så att personer som redan handlar lämnas ifred.

Och hotskyddsmotorn som presterade så bra den 2 augusti slutade skicka utgående trafik för vår e-postserver efter samma explosion. E-posten köades tills routern startades om. En inspektionsmotor i sökvägen är ytterligare en sak som kan misslyckas, och när vår misslyckades misslyckades den och stängdes.

Lärdomen för NAS-säkerhet är inte att ta bort lager. Det är att skriva ner varför varje regel finns, titta på vad den blockerade under sin första vecka och föredra en utmaning framför en blockering närhelst en riktig person kan vara i andra änden.

Säkerhetskopieringar är lagret som fungerar efter att de andra misslyckats #

Ingen NAS-säkerhet gör återställning valfri. Maskinvarufel, uppdateringar går fel och en administratör klockan ett på natten är farligare än de flesta botnät. Vi behåller tre typer av kopior: ögonblicksbilder på NAS:en för snabb återställning, en schemalagd export av hela den virtuella maskinen som är synkroniserad med molnlagring och en separat extern säkerhetskopia av data.

Exporten av virtuella maskiner beskrivs steg för steg i VMM-säkerhetskopiering till Google Drive, och klustret som är värd för allt det i vår 3-nods VMM Pro-installation.

Begränsningar för denna NAS-säkerhetsinstallation #

Detta är ett litet företag som beskriver vad det driver, inte en standard. Några ärliga begränsningar:

Vår NAS-säkerhet är beroende av Cloudflare. Om deras nätverk har en dålig dag, har vi det också, och den betalda planen är en del av webbplatsens månadskostnad.

Den byggdes genom att reagera. De flesta av våra regler skrevs dagen efter en incident. Ett större team skulle ha gjort hotmodellering först och hittat några av dessa hål innan en angripare gjorde det.

NAS-säkerhet behöver underhåll. Regler som listar specifika sökvägar eller nätverk blir inaktuella, och en regel som ingen kommer ihåg är ett framtida avbrott. Vi granskar listan när webbplatsens struktur ändras.

Och det skyddar en butik, inte en bank. Om du lagrar hälsojournaler eller kortnummer på en NAS behöver du mer än den här artikeln, till att börja med en professionell granskning.

Vanliga frågor #

Referenser och videogenomgångar #

• Synology: hur man lägger till extra NAS-säkerhet, den officiella checklistan för konton, brandvägg och uppdateringar.
• Hjälp med Synology SRM Hotdetektering, som beskriver allvarlighetsnivåer och den automatiska borttagningspolicyn.
• Hjälp med Synology DSM 2-faktorsautentisering, inklusive hur man tillämpar det för en grupp.
• Cloudflare WAF-anpassade regler, regelspråket bakom kantlagret.
• Cloudflare IP-intervall, listan som ska tillåtas på din router när du låser källan.

Dessa Synology-videor täcker DSM-sidan av NAS-säkerhet, från den allmänna checklistan till den andra faktorn och användarbehörigheter.

Mer från den här serien om att hosta ett företag på en NAS: åtgärda avvisad e-post med en SMTP-relä. Vill du separera dina egna tjänster på samma sätt som vi gör? Börja med en Virtual DSM-licens, eller bläddra bland alla licenser på SynoPower Club.