Servery spravuju nějakých 15+ let, je to moje profese i koníček. U každé instalace se vždy snažím o jistý minimalismus. Nainstaluju minimální verzi OS (toho času stále Debian), tu navíc upravím tak, že odinstaluju nepotřebné balíčky a zbytek konfigurace převedu to na systemd. Když už tam teda je. Tj starej networking jde na systemd-networkd, systemd-resolved. ifupdown a dhcp client může jít pryč. Máme systemd-journald, takže rsyslog může jít pryč.
Všechny nepotřebné služby zůstanou buď vypnuté (ideálně zamaskované), nebo, pokud tomu nebrání nějaké závislosti, rovnou odinstalované. Další balíčky jako wpasupplicant a bluez na serveru fakt nepotřebuju. Ty běžící se zabezpečí (ssh pouze s klíči apod.).
Výchozí minimální stav je tedy jen běžící ssh a to buď jako služba, nebo přes systemd socket activation. Nic víc na síťových portech neposlouchá.
Mám tedy výchozí minimální systém. Následně nainstaluju služby, které chci. A dál řeším jen nastavení těchto služeb, základního systému se od této chvíle prakticky není třeba dotknout.
Proč to píšu. Nedávno jsem se dostal do týmu, který dělá věci zcela jinak. Uvedu to na příkladu poštovního serveru. Používám postfix a dovecot. Pro authentizaci používám dovecot, pro doručování do schránek používám dovecot. To jest stačí nainstalovat balíčky, nastavit postfix pro příjem pošty a nastavit ověřování uživatelů (pokud nejsou lokální) přes dovecot (smtpd_sasl_type) a nastavit doručování přes dovecot (mailbox_command = /usr/lib/dovecot/deliver). Automaticky tak funguje sieve apod.
A tím to hasne. Nijak se nemusí zasahovat do systémového nastavení, pošta funguje pro lokální uživatele a funguje i vzdálený přístup přes imap. Uživatele stačí vytvářet standardním systémovým příkazem.
Tým, kde mám tu čest nyní pracovat, to dělá jinak. Postfix a dovecot tady je, ale pro doručování do schránek zařizuje maildrop. Protože si neporadí (nijak do hloubky jsem to nezkoumal a je mi to jedno) s rozlišením, jestli má vytvářet mailbox nebo maildir, tak ve výchozím stavu vytváří mailbox soubor. Jenže v nastavení dovecotu je maildir. Takže to nefunguje. Proto je potřeba v /etc/skel vytvořit maildir. Pro každého nově vytvořeného uživatele se tak kopíruje výchozí maildir. Protože se nechce, aby se uživatelé mohli na mailserver přihlašovat, tak se ještě mění /etc/adduser.conf, kde se mění shell na nologin.
Přijde mi to jako naprosto zbytečná komplikace. U mě zvolený typ poštovní schránky vytváří dovecot (toho času mdbox mail_location = mdbox:~/.mdbox). Protože ten doručuje. Vůbec nic nemusím měnit v /etc/skel (což jsem za celou kariéru nikdy nemusel dělat) ani nastavovat /etc/adduser.conf (což jsem taky nikdy nedělal), protože výhradně používám klíče (tj. pokud nechci, aby se tam uživatel přihlašoval, tak mu nenastavím klíč). Fyzický přístup na terminál stejně nemá. A už vůbec ne na případnou virtuální konzoli. A i kdyby se tam neznámo jak přihlásil, tak jediné, co uvidí, jsou soubory jeho vlastní pošty. Ale přes imap klienta je to přece jen pohodlnější.
Tolik pro ukázku. V žádném případě nechci nijak problematizovat zvolený postup, jistě funguje. Jen mi přijde zvláštní dělat tolik nepotřebných zásahů do systému, když stačí pouze nastavit služby pro danou roli. Nastavuju poštovní server a veškerá nastavení nesou postfix a dovecot. Nevidím důvod sahat kamkoliv jinam.
Můj již mnohokrát prezentovaný přístup vychází z Exupéryho citátu: „dokonalé není to, kam nelze nic přidat, ale to, odkud nelze nic odebrat“. Snažím se udržoval minimální množinu „atomů“, ze kterých postavím celek. Tj. odpovědí není vzít jeden monolit a prohlásit: je to jeden balíček (jak si to někteří chybně vykládají). Nikoliv. Odpovědí je mít minimální množinu nástrojů, se kterými udělám maximum věcí. Cílem by nemělo být nastavit v systému úplně všechno, ale pouze změnit ty věci, které ve výchozím stavu nevyhovují. Pokud může úložiště po poštu vytvořit přímo pošťák, který k tomu má navíc všechny potřebné informace, tak je zbytečné to delegovat někam jinam a měnit systémové soubory.
Myslím, že můj přístup funguje lépe dlouhodobě a méně komplikuje updaty na nové verze. Při upgrade řeším jen nastavení daných služeb. Tím, že zbytek systému je v podstatě ve výchozím stavu, tak instalátor nemá problém s konfiguračními soubory. Protože se nemění. Ano, po upgrade je potřeba vše zkontrolovat zejména s ohledem na zabezpečení (tj. zkontrolovat běžící služby a jejich nastavení). Ale tj v minimálním systému poměrně rychlá práce. Navíc se dá do značné míry automatizovat.
U systémů, jejichž admini se hrdě hlásí k tomu, že si to přizpůsobili přesně k obrazu svému a nastavili desítky konfigů a pro jistotu ještě navíc na všechna temná zákoutí dali skripty, které ještě navíc něco dělají – tady posunou nějaký soubor, tady změní timestamp, od kterého se potom odvíjí další akce, tady zavolají systémovou službu (tak že nefunguje ovládání pomocí systemctl, protože vám tu službu nestále něco pod rukama nahazuje), je upgrade prakticky neproveditelný. Akorát jsem dodnes nepochopil, jaké má tento křehký systém přesně za výhody. Je to vlastně takový osobní vendor lock-in na jednoho admina. Který už je 10 let pryč.
Ale ptám se vážně: jak moc nastavujete servery?
Celkem dost. Už jen samotný základ je celkem složitý, takže ansible+playbooky.
Jinak samotným základem se myslí:
jméno, síť, konfigurace sssd, join do domény, nastavení sudo, nastavení ntp, bash promptu, instalace RootCA, konfigurace ssh, deploy klíčů správců pro ssh, konfigurace syslogu do ELK atd. atd. atd.
Až pak nastává čas na rozběhání konkrétní služby, pro kterou je VM určeno.
Zdar Max
Jinak ještě dodám, že pokud se bavíme o konfiguraci jednotlivých služeb, tak co nejpřehledněji, nejjednodušeji a žádné speciality ani workaroundy, protože to pak vytváří zbytečné problémy do budoucna.
Zdar Max
Díky za reakci. Ono bez konkretizace, co ty servery dělají, se to asi nedá srovnat, ale proč linux do domény? Nebo myslíš klasickej ldap?
Na naše servery se uživatelé nepřihlašují a adminů je pár, takže jsou to pouze lokální uživatelé. Tj při instalaci serveru vytvořit uživatele a nastavit jim klíče. Celkem trivka.
Osobně vmka vždy nastavuju jako co nejvíce soběstačná, tj stačí jen připojení do internetu. I dns resolver je lokální. To vmko lze vzít a strčit do jiné sítě a stále bude fungovat. Nepotřebuje externí db uživatelů, nic.
Logy do ELK, no asi je to námět na další článek. ;-) Všichni jsou posedlí logováním.
Do AD domény, kde jsou uživatelé. Je to kvůli jednotnému heslu.
Admin má účet v AD (většina z nich má WinPC, které je též v AD) a musí být v příslušné skupině.
Až poté se může přihlásit na linuxový server přes svůj certifikát a pomocí svého hesla z AD pak může volat sudo a dělat si co chce.
Nu a to všechno pak jednoduše umožní implementovat SoD (Segregation of Duties), aneb aby všichni admini neměli přístup všude. A osobně už jsem se s problémy s adminy setkal (jeden si třeba zaviroval PC), takže z osobní zkušenosti mi to dává smysl (jak SoD, tak řešit cert+účet do AD).
Logy do ELK je jen další úroveň ochrany. Pokud chceš vědět, co se ti na síti skutečně děje, tak na to asi jednotná ochrana nestačí. IDS/IPS jako Suricata, Flowmon, Snort apod. ti neodhalí všechno. Je třeba ještě SIEM (Security Information and Event Management), což je analýza logů, nad kterou je nějaký alerting. Takže třeba ELK+ElastAlert2 (pokud nechceš platit). Honneypoty v síti jsou pak jen třešnička na dortu, které ti odhalí sebemenší port scan.
Jinak template VM máme také vesměs hodně čistý a pak to doháníme ansiblem. Není pak problém rychle nahodit třeba 4VM, nebo celý nový Kubernetí cluster během chvilky.
Zdar Max
To mi připomíná jedno nejmenované ministerstvo, kde měli miliardu logů, siem, netflow, vůbec se tam nedalo připojit a měli současně všechno tak zastaralé, že si nevšimli několika (úspěšných) útoků. To je, podle mě, celkem přeháňka, které se prosazuje jen proto, aby mohl někdo z ELK apod. udělat komerční produkt a ten potom prodávat. Toto prostě není potřeba a může to být i kontraproduktivní. Někdo se jen spoléhá na tyto systémy a vůbec nezná to prostředí, což je podle mě to nejdůležitější. Netvrdím, že je to tvůj případ, ty to znáš a současně na to narveš dalších 20 sledovacích systémů, ale není potřeba být takový extremista.
Tak ono ELK není jen o tom, že ho použiji jako SIEM. Mám dost služeb, které logují do syslogu nebo do souboru, ale zároveň ty logy potřebuji zpřístupnit developerům. ELK je jedna z věcí, jak jim je nějak přehledně naservírovat.
Dalším důvodem jsou některé síťové prvky, kde potřebuji diagnostikovat nějaký problém. A síťové prvky v případě výtuhu, či restartu přijdou o logy, protože logování do ram.
A pak jsou tu Windows Servery, kde vydolovat nějaký logy a časové návaznosti jsou celkem porod. V ELK to jde osekat o zbytečnosti a agregovat do skupin podle přání. Není tak třeba větší problém si v ELK zagregovat logy z Win serveru tak, že máš přehledně logované operace nad SMB Share a můžeš celkem jednoduše zjistit, kdo co kdy udělal (změnil, vytvořil, smazal, upravil oprávnění apod.).
ELK+ElastAlert2 je tedy jednotné řešení na základě skupiny několika požadavků.
Pokud jde o bezpečnost, tak jsme zjistili, že dělat penetrační testy několikrát do roka není dostačující. Proto si základní penetrační testy děláme sami v krátkých intervalech, abychom rychle odstínili základní bezpečností problémy (zapomenuté nezaktualizované zařízení, zapomenuté default heslo, někde omylem povolený nevhodný port, špatně nastavené služby apod.).
Zdar Max
Dobře, pro mě je tohle extrém a za celou dobu v IT jsem nepotřeboval možná ani 1% z toho (a v dalších článcích popíšu proč a proč se tomu vlastně úmyslně vyhýbám – ono logovat všechno taky není vždy úplně dobré – i z hlediska soukromí – viděl jsem lidi pátrat v logách ne proto, se něco stalo, ale proto, že je moc a moc zajímalo, kdo a kdy něco dělal – protože na dotyčného chtěli prostě něco najít; a tohle prostě nemá s IT nic společného).
Co se týče penetračních testů, jasně, fajn, je lepší na to mít papír, že je vše v pořádku, ale updatuje se tak nějak průběžně. Když to srovnám se správou domu, tak je lepší provést kontrolní prohlídku ještě před revizí (a tu potom mít čistou), než řešit termíny z revize. (A já obecně mám moc rád revize a kontroly. To si musím zařídit na důchod.)
Tak z našich logů nejde moc vysledovat co a kdo jak dělal, resp. sledovat někoho konkrétního. Asi by to nějak šlo, ale vyžadovalo by to značné úsilí a mnohem drsnější logování, což ale není náš scope.
Pokud jde o penetrační testy, tak nejde jen o papír. Skutečně nám pomohly zalepit nějaké problémy a poodhalit tu bezpečnostní stránku. Ono totiž dost často platí „Nikomu nevěř“. Pokud nějakému kolegovi zadáš, ať něco nějak nastaví, tak je to jak s Schrodingerovou kočkou. Dokud se do té krabice nepodíváš, tak nevíš, zda to skutečně udělal, a zda to udělal dobře. Kontrolovat po všech všechno generuje velké režije, je potřeba více lidí, kteří chybí atd. Je pak tedy nejlepší kontrolovat jen část a dohánět zbytek testy. A pak je tu ta věc, že nikdo není vševědoucí a neomylný, takže i já mohu udělat chyby, které ani napodruhé nemusím zaznamenat.
Zdar Max
Co na to napsat, pokud ty jako vedoucí nevěříš svým kolegům a musíš po nich všechno kontrolovat, tak je prostě něco špatně. Ano, já jsem měl taky kolegy, kde jsem si to raději udělal sám, ale potom ty, na které byl 100% spoleh. Jenže to je složitější problém. Mnoho lidí má problém říct, že něco neumí (to není příjemné nikomu) nebo nestíhá nebo že třeba nechtějí dělat tak odbornou práci. A mnoho pracovních prostředí je nastaveno tak, že se všechno vždycky musí stihnout apod. No takže se to stihne no. Se všemi následky. Monitoring je jiná věc, já sám preferuju „test driven administration“ kdy si nejdřív nastavím monitoring ještě neexistujícího stroje a potom jej postavím. A vím, že mám hotovo. Jenže se to nesmí přehnat. Chci pracovat s lidmi a ne s roboty, kteří mají na všechno přesně vymezený čas, úkol apod. A nechci ani sám sebe příliš monitorovat.
Spíše je to o tom, že nikdo není neomylný. Je to spíše o drobných chybkách tu a tam, než že by něco bylo vyloženě špatně. Třeba někdo nastaví ups, změní hesla, nastaví snmp atd., ale už třeba zapomene deaktivovat uživatele „readonly“, protože mu třeba v tu chvíli někdo zavolá, nebo ho vyruší a on si pak myslí, že to udělal, nebo na to zapomene úplně. Vše funguje, je to zabezpečené, ale i tak je špatně mít readonly usera. Je to jen příklad, těch omylů a problémů může nastat mnohem více, i komplikovanější a na všechno nelze mít vypracovaný step2step postup s checkboxy nebo to kontrolovat další osobou.
Zdar Max
Ano, nikdo není neomylný a já tohle řeším tím, že ty věci jsou simple as possible a je jich co nejméně (co do počtu typů). K té ups, to patří taky do výběrového procesu. Mám rád věci fungující out of box a mající rozumný default. Poslední půl rok testuju nový hw pro další rozvoj a je to teda tragedie, 90% odpad. Nejedná se vyloženě o IT, ale u jistou část průmyslu, ale tj celkem jedno. Nejsem vůbec ochoten se zabývat něčím, co ani software výrobce nedokáže správně nakonfigurovat ani třeba proscanovat. Prostě to jde na blacklist.
Jinak, chápeme se, ale neshodujeme se. Moje cesta je se té komponenty zbavit, ty se snažíš kolem ní postavit lepší plot. Obé funguje.
Snazim se drzet podobne filozofie jako ty, ale nezjistuji, co by se z minimalni instalace debianu dalo jeste vyhodit. V podstate pouzivam default a i kdyz je potreba tak ho nastavim podle sveho. V zakladu nastavuji rotaci logu, instalaci zakladnich utilit, vzdalene logovani, monitoring, ssh server, postfix pro odesilani mailu (nikdy jsem nemel rad exim, takze jsem vzdy nahrazoval exim postfixem). V zakladu mi na debianu vadi, ze uzivatele si mohou lezt navzajem do home adresaru, takze menim prava k domacim adresarum (mozna prave v adduser.conf). Pak pridavam sluzbu, ktera ma na stroji bezet. Snazim se mit vsechny stroje v ansible playboocich a ty verzovat, abych videl co se menilo.
Díky. Já na instalaci (dle našich potřeb) mám preseed configurační soubor (je to teda šílená technologie sahající až ke vzniku debu) a následně ansible. Ale trochu mi vadí přítomnost balíků jako bluez apod. Oni nemají přímo určený instalátor pro servery, takže pokud člověk (nebo skript) při instalaci vybere pouze ssh server a nic dalšího, tak to automaticky instaluje task-laptop, kde je i bluetooth. Což je logické pro minimální instalace určené pro ntb, ale ne pro servery. Takže v ansible mám seznam balíčků k odstranění (po té minimální instalaci).
Už jsem uvažoval o změně distra, ale zase deb má bohatý repositář a kde co všechno je jednoduše instalovatelné jedním apt příkazem.
Schválně jsem mrknul na mojí minimální instalaci a bluez tam nemám (dpkg -l | wc = 326 ). Mám tam task-ssh-server a task-english. task-laptop nemám nainstalovaný, není to tím preseedem?
Také tam nemám bluez. Jinak moje default instalace (základní balík s nrpe agentem, pluginama, sssd apod.) jsem na cca 470.
Zdar Max
Ne, v tomto případě jde o čistou instalaci bez preseedu. Instalační image debian-10.10.0-amd64-netinst.iso. UEFI VirtualBox.
Vybraný pouze ssh server (tj ani ne standard system utilites):
Podle mě je zmatenej ten laptop-detect. Ale nebudu to víc debugovat, on ten ansible se stejně bude spouštět, a některé balíčky bych stejně odinstalovával (rsyslog, ifupdown apod.)