Dotaz: Jak na šifrované logy z apache a syslogu?

[Bilbo]

Rád bych šifroval logy co produkuje na serveru apache a syslog (u syslogu by stačila i jen část logů), aby když se někdo na server nabourá, případně ho ukradne, tak aby se do těch logů co tam jsou uloženy nedostal.

Tedy by to musela být nějaká asymetrická kryptografie (např. něco na způsob GPG), kdy na serveru je jen veřejný klíč a privátní je uložen bezpečně v trezoru (ve chvíli, kdy si chci logy přečíst, tak si je přenesu na jiný počítač, vezmu z trezoru klíč a tam je dešifruju).

GPG jen tak asi nepůjde použít (umí šifrovat soubory, ale asi to nepůjde tak jednoduše s rourami, kde data plynule proudí několik měsíců bez přestávky)

Principiálně by to mělo být snad možné - apache umí logy posílat rourou zadanému programu, rsyslog sice ne, ale umí named pipes (fifo) takže by tu taky neměl být problém.

Tedy jediné co "zbývá", je nějaký program co mu teče na vstup log v plaintextu a z něj se to pak zapisuje nějakým způsobem do nějakých šifrovaných souborů. A umí se nějak vyrovnat s rotací logů a jinými problémy - restart apache, aby se log celý nezničil při náhlém ukončení programu (OOM, restart serveru ...), atd ...

Víte někdo o nějakém programu, co by tohle dělal (nebo ho lze nějak přiohnout, aby se k tomuhle dal použít), nebo si ho budu muset napsat sám?

Odpovědi

[Max]

Mně to přijde jako security obscurity. Když se někdo nabourá na server, tak logy je to poslední, o co bych se bál. Ale to, že si neumím dobře představit zneužitelnost logů, ještě nic neznamená.
Jinak osobně bych to možná řešil nějakým separátním logovacím serverem. To by do hodně velké míry zregulovalo počet možných bezpečnostních chyb (vše na FW zakázáno, jen naslouchání na ssh a syslogu povoleno).
Nevýhodou zašifrovaných logů je to, že jsou zašifrovaný a tudíž se ti zvyšuje čas potřebný k řešení nějakého problému.
Dalším problémem je, že když nasadíš šifrování, tak si odpálíš další bezpečnostní prvek, který zřejmě nepoužíváš a tím je automatická kontrola logů nějakým scriptem (log analyzerem jako je např. Logwatch), který v případě nalezení neobvyklého, nebo i předem definovaného, záznamu dá okamžitě vědět správci.
Zdar Max

[Bill Gates]

>vše na FW zakázáno, jen naslouchání na ssh
SSH mit otevrene z venku - tomu taky neverim..
SSH zavrit taky, na SSH lezu skrz VPN bezici na serveru na totalne nestandardnim portu a az na VPNce teprve otevreny port SSH. By musel nekdo hacknout VPNku a pak jeste heslo na SSH, to uz je psycho.

[pht]

By musel nekdo hacknout VPNku a pak jeste heslo na SSH, to uz je psycho.

Správně. Ještě že žádní psycho hackeři nejsou.

[Bilbo]

V logwatch nevidím nepřekonatelný problém, kopie nešifrovaných logů se pustí do další roury, na jejímž konci bude logwatch. Logwatch pak bude posílat maily šifrované GPG :)

Separátní logovací server asi nebude to správné řešení pro mně, jednak pořád musím řešit stejný problém (někdo nabourá nebo ukradne i ten logovací server, tedy potřeba šifrovat), jednak to znamená další stroj navíc.

Samozřejmě, že optimální je, pokud se podaří server zabezpečit tak, aby se na něj nikdo nedostal, ale snažím se, aby když už se někdo serveru zmocní, nebo se na něj nabourá, aby nadělal minimum škody. Je celkem rozdíl, pokud si někdo ze serveru odnese logy za rok s citlivými údaji, nebo jen za krátkou (od hacknutí do objevení hackera), až nulovou (někdo vyškubne bednu ze zdi a odnese si ji) dobu.

[zulu]

S takovým přístupem ti taky může někdo nabořit server s privátním klíčem a logy rozšifrovat. Trochu soudnosti, pane. Mimo to, jak se ti do logů dostanou citlivá data a proč je tam cpeš?

[Bilbo]

Rozdíl je v tom, že se akorát ty logy přenesou na logovací server (takže se jen změní cíl pro útočníka) - a ve chvíli kdy logserver klekne, tak přijdu o značnou část logů než ho osobně nahodím.

Privátní klíč nemusí být online (může strávit většinu doby v trezoru), takže tam je riziko o dost nižší.

Je dost případů, kdy data z logů můžou být cennější, než jakákoliv jiná data na serveru. Komplet index googlu je relativně cenný (je potřeba dobrá konektivita a hodně času k jeho vybudování, ale zase to může "snadno" udělat kdokoliv), ale informace kdo kde co vyhledává (čili logy) bude asi cennější (a lépe zneužitelná ve špatných rukou) a nedá se tak snadno získat, viz. třeba rozruch kolem uvolnění podobných dat Amazonem (který je sice "anonymizoval", ale moc to nepomohlo ....)

[Max]

Nojo, jenomže ten logovací server může být mnohonásobně lépe zabezpečenější, než ten původní, jelikož na něm nepoběží žádné služby, jen asi dvě a ty budou na FW omezeni jen pro určité IP. Takže jediná možnost, jak by se někdo mohl do serveru nabourat, je zjistit si heslo roota, nebo přijít na nějaký remote exploit jádra k získání root práv. Obě dvě věci považuji za v dnešní době hodně nerealistické.
Zdar Max

[pht]

ten logovací server může být mnohonásobně lépe zabezpečenější, než ten původní

To může být pravda, ale na tom ve výsledku asi nebude moc záležet.

Nakonec chcete ty data někam dostat, abyste je mohl zpracovat nebo číst, takže bude mnohem více záležet na tom, jak zabezpečíte čtení. (Pokud je chcete jen shromažďovat, tak nejbezpečnějším a nejúspornějším místem je /dev/null :)

zjistit si heslo roota ... považuji za v dnešní době hodně nerealistické

Žijete asi v jiné realitě než já (a spousta jiných).

[Ondrej]

Resis blbost. Pokud ti nekdo ukradne nebo naboura server, mas mnohem horsi problem nez nejaky cteni logu. Z logu se nic utocnik nedozvi, mnohem zajimavejsi jsou data na nem. A pokud mas aplikaci, ktera do syslogu cpe duverny data - aplikaci okamzite vyhod.

Jinak bych to resil logovacim serverem s sifrovanym diskem, klic na flashce. Pokud potrebujes restartovat server, tak k nemu dojit, strcit do nej flashku, nechat pripojit disky a flashku si zase odnest.

Ale jak rikam ja a i lidi prede mnou - resis zbytecnou blbost. Nicemu nepomuzes a jenom budes spotrebovavat vykon stroje na (de)sifrovani logu.

P.S.: A ted si predstav, ze ti nekdo crackne soukromej klic! preci jenom je to jenom par kilobitu dat - u 2048bit klice je jenom 2^2048 moznejch privatnich klicu, coz je nejaky (a popravde celkem i maly) cislo - 3,231700607e+616 (cca.)

[pht]

u 2048bit klice je jenom 2^2048 moznejch privatnich klicu, coz je nejaky (a popravde celkem i maly) cislo - 3,231700607e+616 (cca.)

Jak kde :)

[pht]

Tedy jediné co "zbývá", je nějaký program co mu teče na vstup log v plaintextu a z něj se to pak zapisuje nějakým způsobem do nějakých šifrovaných souborů. A umí se nějak vyrovnat s rotací logů a jinými problémy - restart apache, aby se log celý nezničil při náhlém ukončení programu (OOM, restart serveru ...), atd ...

Myslím, že jste na to kápnul. Ten program si musí přečíst (zapamatovat) kus záznamu z logu, ten pak zašifrovat a uložit. To není nic proti ničemu (postačí na to docela malý skript).

Jen si musíte rozvrhnout, jak dlouhý kus si budete pamatovat. Pokud bude moc krátký, budete režie šifrování příliš veliká. Pokud bude moc dlouhý, hrozí, že při výpadku přijdete o adekvátně dlouhý kus záznamů. Pokud bych střelil od boku, tak bych šifroval např. jednou za minutu nebo jednou za 4 kb textu, podle toho, co přijde dřív.

Samozřejmě musíte k tomu připojit nástroj, kterým budete ty logy schopen efektivně číst.

[Bilbo]

Jo, šlo by to řešit podobně jako to dělá GPG - asymetrickou šifrou se zašifruje session key a zbytek se pak šifruje symetrickou šifrou - u čehož lze cpát šifrovaná data do logu po menších kusech průběžně. Navíc oproti GPG by se tu ale musel session key každých X minut střídat, takže bych pak musel napsat i vlastní dešifrátor a nešel by použít formát GPG.

Ale napadlo mně, jestli nějaký podobný software už neexistuje, že bych ho nemusel celý psát ... sice by šlo použít k tomu velké kusy z GPG, ale i tak by bylo jednodušší použít už něco hotového.

[pht]

Můžete rovnou použít gpg, na každej ten kousek zvlášť.