Je spouštění upgradu apt-get tak často, aby byl webový server bezpečný?

Odstranili jste spoustu problémů, které vás běžně přivádějí do problémů (konkrétně za předpokladu, že aplikace, kterou hostujete, je zcela bezpečná). Z praktického hlediska je musíte bezpodmínečně zvážit.

Ale pravděpodobně, protože o nich víte, máte zavedena nějaká ochranná opatření. Pojďme si promluvit o zbytku.

Pro začátek byste pravděpodobně neměli spouštět aktualizaci „každý tak často“. Většina distribucí provozuje e-mailové konference oznámení o zabezpečení a jakmile je tam oznámena zranitelnost, je to spíše veřejné (dobře, často je to před tím, ale ve vaší situaci nemůžete skutečně sledovat všechny seznamy zabezpečení na světě). Jedná se o seznamy s nízkou návštěvností, takže byste se měli opravdu přihlásit k odběru svých distribucí a upgradovat, když z nich dostanete upozornění.

Často může být náhodně udržovaný server brutálně vynucený nebo slovníkový útok po dlouhou dobu, protože správce ve skutečnosti nehledá znaky. Pak je dobré použít obvyklá protiopatření – žádné ověřování heslem ssh, fail2ban na ssh a Apache – a ideálně nastavit upozornění na monitorování, když dojde k podezřelé aktivitě. Pokud je to mimo váš rozpočet na údržbu (čas), zvykněte si pravidelně se přihlašovat a kontrolovat tyto věci ručně.

I když to není tradičně považováno za součást zabezpečení, chcete se ujistit, že můžete rychle spustit nový server. To znamená, že konfigurační skripty serveru (nástroje jako Ansible, Chef atd. jsou každopádně užitečné při správě systému) a systém automatického zálohování, který jste otestovali. Pokud byl váš server narušen, musíte předpokládat, že je navždy narušen, a jednoduše ho vymazat, a to je na škodu, pokud jste svá data pravidelně nezálohovali.

Ne. Toto není dost na to, abyste byli v bezpečí.

Pravděpodobně vás to nějakou dobu udrží v bezpečí, ale zabezpečení je složité a rychle se vyvíjející, takže váš přístup opravdu není dost dobrý pro dlouhodobé zabezpečení . Pokud by všichni vycházeli ze stejných předpokladů, jaké uvádíte ve své otázce, byl by dnes internet jedním velkým botnetem.

Takže ne, neomezujme tuto otázku na balíčky. Podívejme se na zabezpečení serveru holisticky, aby každý, kdo to čte, získal představu o tom, kolik pohyblivých částí ve skutečnosti je.

• APT (např. repozitáře Ubuntu) pokrývá pouze část vaší softwarové sady. Pokud používáte (např.) Wordpress nebo jinou oblíbenou PHP knihovnu a která není repo-kontrolována, musíte ji také aktualizovat. Větší rámce mají mechanismy, které to automatizují, ale ujistěte se, že provádíte zálohy a monitorujete stav služby, protože ne vždy jdou dobře.

• Napsal jsi to všechno sám, takže si myslíš, že jsi v bezpečí před dětmi ze scénáře? Kolem běží automatizovaný SQL injection a XSS exploit bot, který šťourá do každého řetězce dotazu a formuláře.

  Toto je vlastně jedno z míst, kde dobrý framework pomáhá chránit před neadekvátními programátory, kteří si neuvědomují nuance těchto útoků. Obavy zde také pomáhá rozptýlit kompetentní programátor, který prověří kód.

• Potřebuje PHP (nebo Python, nebo co spouštíte) opravdu všude umět psát? Vylepšete svou konfiguraci a zmírníte mnoho útoků. Ideálně jediná místa, kde je webová aplikace možná zapisovat jsou databáze a místa, kde se skriptování nikdy nespustí (např. pravidlo nginx, které umožňuje pouze obsluhovat statické soubory).

  Výchozí nastavení PHP (alespoň jak je lidé používají) umožňují PHP číst a zapisovat PHP kdekoli ve webovém kořenovém adresáři. To má vážné důsledky, pokud je váš web zneužit.

• A váš plán aktualizací je aktivně škodlivý. Co je to proboha „každý tak často“? Kritické chyby vzdáleného zabezpečení mají krátký poločas rozpadu, ale mezi 0-denním a dostupností opravy je již zpoždění a některé exploity jsou také obráceny a vytvořeny z oprav (aby se zachytily pomalé šťouchance).

  Pokud používáte aktualizace pouze jednou za měsíc, je velmi velká pravděpodobnost, že budete volně používat zneužitelný software. TL;DR:Použijte automatické aktualizace.

• Verze distribucí nevydrží věčně. Pokud jste byli rozumní a vybrali si LTS verzi Ubuntu, máte 5 let od prvního vydání. Během této doby vyjdou další dvě verze LTS a to vám dává možnosti.

  Pokud jste byli na vlně „NOVĚJŠÍ JE LEPŠÍ“ a při nastavování serveru šli s 16.10, máte 9 měsíců . To jo. Pak musíte upgradovat do 17.04, 17.10, než budete moci odpočívat v 18.04 LTS.

  Pokud vaše verze Ubuntu vyprší, můžete celý den upgradovat, ale nezískáte žádné aktualizace zabezpečení.

• A samotný zásobník LAMP není jediným vektorem útoku na standardní webový server.

  • Musíte zpevněte konfiguraci SSH:pouze používat klíče SSH, deaktivovat hesla, přesměrovat port, deaktivovat přihlášení uživatele root, sledovat hrubé pokusy a blokovat je pomocí fail2ban .
  • Firewall vypne všechny ostatní služby pomocí ufw (et alii).
  • Nikdy nevystavujte databázi (pokud nepotřebujete do a poté uzamknout příchozí IP ve firewallu).
  • Nenechávejte nainstalované náhodné skripty PHP, jinak budete zapomeňte na ně a oni budou nechat se nabourat.

• Ve vašem popisu není žádné sledování. Jsi slepý. Pokud se tam něco dostane a začne odčerpávat spam, infikovat vaše webové stránky atd., jak můžete říct, že se stalo něco špatného? Monitorování procesu. Naplánované porovnání souborů s git (ujistěte se, že jde o přístup pouze pro čtení ze serveru).

• Zvažte zabezpečení (fyzické a vzdálené) vašeho ISP. Investují desetník „hostitelů“ (aka piráti CPanel) – kteří vybírají 2 dolary měsíčně neomezené hostingové plány – stejné zdroje do zabezpečení jako zařízení vyhrazeného serveru? Zeptejte se a prozkoumejte historii porušení.

• A pak jste tu vy . Zabezpečení počítače, na kterém kódujete všechny tyto věci, je téměř stejně důležité jako server. Pokud používáte stejná hesla, nesete odpovědnost. Zabezpečte své klíče SSH fyzickým klíčem FIDO-UF2.

Devops dělám ~15 let a je něco, co se můžete naučit v práci, ale ve skutečnosti stačí jediné porušení – jeden teenager, jeden robot – aby zničil celý server a způsobil týdny práce s dezinfekcí pracovního produktu.

Stačí být při vědomí o tom, co běží a co je vystaveno, vám pomůže lépe se rozhodovat o tom, co děláte. Jen doufám, že to někomu pomůže zahájit proces auditování jejich serveru.

Ale pokud vy – průměrný programátor webových aplikací – nejste ochotni se do takových věcí pouštět, měli byste vůbec provozovat server? To je vážná otázka. Nebudu vám říkat, že byste rozhodně neměli, ale co se s vámi stane, když toto všechno ignorujete, váš server je hacknutý, váš klient přijde o peníze a vy odhalíte osobní údaje o zákaznících (např. fakturační údaje) a budete žalováni ? Jste pojištěni na tuto úroveň ztráty a odpovědnosti?

Ale ano, to je důvod, proč jsou spravované služby mnohem dražší než hloupé servery.

Na základě záloh...

Úplná záloha systému je možná to nejhorší, co byste si mohli ponechat —z důvodu zabezpečení – protože budete v pokušení jej použít, pokud vás někdo hackne. Jejich jediným místem je zotavení po selhání hardwaru.

Problém s jejich používáním v hackech je, že se resetujete na ještě dřívější bod v čase. Nyní je ve vašem stacku patrných více nedostatků, existuje ještě více exploitů pro díru, která vás dostala. Pokud server přepnete zpět online, můžete být okamžitě napadeni. Můžete firewallem vypnout příchozí provoz a provést upgrade balíčku a to může pomoci vám, ale v tuto chvíli stále nevíte, co vás to dostalo nebo kdy vás to dostalo. Všechny své domněnky zakládáte na příznaku, který jste viděli (vkládání reklamy na vaše stránky, spam odrážený ve vaší mailq). Hack mohl být měsíce před tím.

Jsou samozřejmě lepší než nic a v případě vyhasnutí disku jsou v pořádku, ale opět z bezpečnostních důvodů jsou to nesmysl .

Dobré zálohy jsou recepty

Chcete něco – jen prostý dokument nebo něco technického, jako je Ansible/Puppet/Chef rutina – co může někoho vést k obnovení celého webu na zcela nový server. Co je třeba zvážit:

• Seznam balíčků k instalaci
• Seznam změn konfigurace, které je třeba provést
• Jak obnovit zdroj webu ze správy verzí.
• Jak obnovit výpis databáze* a jakékoli další statické soubory, u kterých možná nemáte kontrolu nad verzí.

Čím podrobnější zde můžete být, tím lépe, protože slouží také jako osobní záloha . Moji klienti vědí, že pokud já zemřít, mají testováno plánují obnovit své stránky na hardware, který přímo ovládají.

Dobrá skriptovaná obnova by neměla trvat déle než 5 minut. Takže i časový rozdíl mezi skriptovaným obnovením a obnovením obrazu disku je minimální.

Je vysoká pravděpodobnost, že si server ponecháte většinou bezpečné, pokud aktualizace spouštíte často (tj. alespoň denně, namísto pouze „každé tak často“).

Čas od času se však vyskytnou kritické chyby, jako je Shellshock nebo ImageTragick. Také nezabezpečená konfigurace serveru může způsobit útoky. To znamená, že byste také měli provádět více akcí, než jen spouštět pravidelné aktualizace, například:

• snížit plochu útoku spuštěním minimálního systému, tj. neinstalovat žádný zbytečný software
• snížit prostor pro útok omezením jakýchkoli služeb přístupných zvenčí, tj. nepovolit přihlašování SSH na základě hesla (pouze na základě klíče), nespouštět nepotřebné služby atd
• ujistěte se, že rozumíte dopadu kritických aktualizací
• očekávejte, že systém bude napaden, a pokuste se snížit dopad, například spuštěním služeb, které jsou přístupné zvenčí uvnitř nějakého chrootu, vězení nebo kontejneru
• protokolovat důležité události, jako jsou neúspěšná přihlášení, pochopit protokoly a skutečně je analyzovat

Přesto nejpoužívanějším vektorem počátečního útoku jsou pravděpodobně nezabezpečené webové aplikace jako Wordpress nebo jiné CMS. Ale váš předpoklad byl, že webová aplikace je plně bezpečná, takže doufejme, že tomu tak skutečně je.