Příspěvky

391

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 29. 11. 2016, 23:24:54 »

Kdyby tam žádné šifrování nebylo, tak kdokoli nabootuje livecd (po vymazání hesla v BIOSu resetem CMOS) a k datům se dostane.
Kdyby byl klíč k LUKSu uložen na připojené flashce, tak jej dokáže kdokoli se schopností "číst v initramdisku" zkopírovat, disk si odemknout a k datům se dostat. Podobně (hůř) kdyby byl klíč přímo v initramdisku.

Rozdíl je v tom, že z TPM dostanete data jen tehdy, když bude systém v předem definovaném stavu. A to platí pro BIOS, kompletní zavaděč, linuxové jádro, initramdisk a cmdline.

Změna jakéhokoli byte v kterékoli fázi bootu způsobí odchylku od definovaného stavu a TPM klíč k odšifrování disku nevydá.

Oddíl s LUKSem má víc keyslotů a v jednom z nich je i dlouhé a složité heslo pro recovery, pokud by došlo k poškození TPM nebo rozbití "definovaného stavu systému".

392

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 29. 11. 2016, 22:20:30 »

Cilem je full disk encryption na masine, ke ktere potencialne muze mit pristup dost lidi vcetne uklizecek (stroj pobezi v praci) a automaticke odemykani disku, aniz by klic mohl kdokoli vzit a disk si odemknout.
Roli samozrejme hraje i pohodli (automaticke odemceni disku bez nutnosti zadavani dlouheho hesla).

Pokud se k datum v pocitaci nekdo pokusi pristoupit, musel by zajistit pritomnost spravneho bootloaderu (hashe MBR a celeho grubu musi sedet), kernelu, initrd (hashe museji sedet) a kernelove cmdline (opet musi sedet hash).

Uplne jinou kapitolou je nastaveni systemu tak, aby se k datum v PC nikdo nedostal pomoci klavesnice, monitoru a dalsich periferii, pripadne po siti, v okamziku, kdy je uspesne nabootovano. :-)

393

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 29. 11. 2016, 00:15:47 »

OK, takze to funguje a docela dobre.
TrustedGrub2 po opatchovani poslusne plni PCR registry sha1 hashem cmdline, vmlinuz a initrd
Luks-tpm po opatchovani funguje dobre s trousers, umi si brat hesla (TPM owner a TPM NVRAM) ze souboru s hesly
Dalsi skripty vycitaji hodnoty z TPM pri bootu a pokud narazi na takovou ulozenou hodnotu, ktera je overena v aktualnim PCR prostredi, tak ji pouzijou pro luksOpen

Jeste mi chybi doplnit do tpm-luks podporu pro checksum trustedgrub2, ale i bez tehle kontroly se pouzity pristup ukazuje jako funkcni...

Co s tim ovsem pak? Udelat fork vsech patricnych nastroju na githubu, udelat patche oproti aktualnim verzim, nebo z toho udelat *.deb baliky, ktere pujdou nejak rozumne nainstalovat?

Napsat clanek na root?

394

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 28. 11. 2016, 14:01:25 »

:-)
Zatim jsem musel ohackovat trustedgrub2, aby mi do pcr-15 ukladal hash cmdline a do pcr-14 hash z vmlinuz+initrd, cimz simuluju chovani trustedgrub-legacy. Zvazuju poslat to jako pull request do repozitare trustedgrub2, imho by se to mohlo hodit i jinym.
Ted me ceka hackovani luks-tpm pro podporu trustedgrub2, protoze existujici verze je usita na miru trustedgrub-legacy a fedore/centosu.
Protoze to zkousim na Ubuntu, budu muset upravit/predelat i premount skripty cryptrootu.

Trosku me prekvapilo, jak spatne na tom je v oblasti measured bootu a FDE Linux oproti Windows a jejich Bitlockeru.

395

Software / TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 28. 11. 2016, 00:14:19 »

Ahoj,
Pouzivate nekdo nejaky loader (TrustedGrub nebo nejakou alternativu), ktery nabizi "measured boot", tedy udelat snimek sama sebe, snimek kernelu a initramdisku, snimek parametru kernelu, a to vse ulozit do TPM?
Rad bych zprovoznil automaticke odemykani LUKS rootfs pri bootu s vyuzitim measured bootu a TPM, coz by mohlo jit pomoci luks-tpm, ale problem je v rozumnem naplneni TPM registru (PCR) bootloaderem.

TrustedGrub (fork grub-legacy) by sice mel delat presne to, co potrebuji, ale nejde zkompilovat (resp. po heavy patchovani jde, ale produkuje >100 MB stage1 a stage2 soubory, coz na disk nejde nainstalovat :-))

TrustedGrub2 jde zkompilovat, nainstalovat a dokonce i nabootuje, ale staci jakakoli udalost v grub menu (stisk libovolne klavesy) a uz jsou hodnoty v PCR jine, nez kdyz grub menu vytimeoutuje a spusti prvni menuitem. To brani predpocitani hodnot PCR z beziciho systemu (nikdo nevi, kdo kolikrat zmackne klavesu...) a tim padem znemoznuje skutecne fungujici a nerozbijejici se boot.

Masina, kde to zkousim, nema EFI, takze jsem se ani nezabyval tim, jestli by pro muj ucel sel znasilnit secure boot.

Za jakoukoli ideu budu rad.

Diky.

396

Server / Re:OpenWRT jako klient OpenVPN

« kdy: 09. 08. 2016, 11:32:50 »

DHCP server by na OpenWRT pro rozhrani br-VPN_CLIENT mel byt vypnuty (DHCP klient muze byt zapnuty, ale staticky pridelena adresa muze byt praktictejsi).

My mame konfiguraci tap+wifi(+bridge s eth VLAN rozhranim) funkcni. Je to proste:
V LuCI v nastaveni br-VPN_CLIENT bych overil:
V General Setup
"No DHCP Server configured for this interface"

V Physical Settings
Bridge Interfaces - zaškrtnuto (zřejmě je, podle obrázku)
Interface - Wireless Network XXX - zaškrtnuto

Výpis bridgů (je vidět bridge wlan0 a tap interface):
root@OpenWrt:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-Phones_Test  7fff.d4ca6d06e8dc       no              wlan0
                                                        tap_Test

Výpis up-skriptu pro tunel:
root@OpenWrt:~# cat /etc/openvpn/test.up.sh
#!/bin/sh

ip link set tap_Test up
brctl addif br-Phones_Test tap_Test

Použitý konfigurák (až na up-skript tam není nic speciálního):
root@OpenWrt:~# cat /etc/openvpn/<vpn>.conf
client
dev tap_Test
proto udp
remote <hostname> <port> udp
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
ns-cert-type server
ca <ca.crt>
cert <klient.crt>
key <klient.key>
script-security 2
up /etc/openvpn/test.up.sh

Přidejte nám sem výpis
brctl show
ip a s br-VPN_client

Všechno to samozřejmě předpokládá, že wifi je správně nastavená. :-)
Možná by stálo za to, rozdělit eth porty do dvou VLAN/skupin (v LuCI v menu Network-Switch) a část portů přiřadit do br-VPN_client. Pak by bylo možné zkoušet DHCP klienta připojeného pomocí ethernetu.

397

Hardware / Re:HW pro minimalistický linuxový server

« kdy: 03. 01. 2013, 10:10:20 »

Ahoj,
zkoušel jste někdo, jestli GWL MK802 jde napájet i přes USB? Hledám něco do auta, kde mám redukci z autozapalovače na mikroUSB.

Díky.

398

Sítě / Re:Nedostupnost www.vlada.cz po IPv6

« kdy: 08. 06. 2012, 09:15:10 »

Rozbity to meli uz v breznu, tehdy reagovali po trech tydnech od upozorneni, ale koukam, ze to asi jeste porad nemonitorujou

(I mne uz to zase funguje.)

399

Sítě / Re: Rozdělení adresního prostoru IPv6

« kdy: 26. 05. 2011, 09:30:05 »

Dnešní moderní domácí routery rády využívají takové featury jako Guest (V/W)LAN, zároveň pokud by koncák chtěl virtualizovat (VMWARE), potřeboval by pro virtuální sítě další /64 bloky.

Tedy, pro koncáka je potřeba:
- 1 adresa ze spojovacího rozsahu (záleží na podobě sítě, jestli je jeden spojovací rozsah pro více zákazníků, nebo jen pro jednoho)
- X krát /64 bloky pro domácí LAN sítě - pro běžného uživatele bych nedával míň, než /62 (tj. čtyři /64 bloky), pokud máte adres dostatek, tak spíš rovnou /56 (obecně doporučovaná velikost pro domácnost). Takových bloků (/56) máte ve /32 celkem 16777216, při správném strukturování sítě je pro malého ISP nemožné je vyčerpat.

Firmám přidělujte /48, /52 nebo /56 (podle velikosti a počtu využívaných podsítí - tam se /56 rozsah dá vyčerpat poměrně rychle, např. pro VPNky, serverové DMZ, LAN a WLAN pro zaměstnance, LAN a WLAN pro hosty, atd., atd.).

Menším (podřízeným) ISP přidělujte rozhodně větší blok, než /48, protože ten jim při dodržování min. /62 pro klienta a správném segmentování sítě dlouho stačit nebude.

Pokud můžete, nechte si rezervy (k jednomu přidělenému bloku rezervujte jeden, tři, sedm, nebo patnáct stejně velkých, číselně následujících bloků), tj. pokud malému ISP přidělím 2001:db8:f0::/48, tak rozsahy 2001:db8:f1::/48 až 2001:db8:f7::/48 nechávám do budoucna, kdyby jim nestačil stávající rozsah.

A samozřejmě, kde to půjde, agregujte prefixy :-) vaše routery vám při zpracovávání routovacích tabulek poděkují.

400

Vývoj / Re: IPv4 a IPv6 na stejném portu

« kdy: 19. 04. 2011, 07:38:38 »

Ad Debian: Jen dodam, ze vychozi hodnota je:
0 v Lennym, Etchi a starsich
1 ve Squeeze a novejsim

Volba se v kernelu (celosystemove) meni zapisem do /proc/sys/net/ipv6/bindv6only.

Nastavenim V6ONLY ve vlastni aplikaci celosystemovy priznak prebijete. Konkretni kod uz je otazkou googleni

401

O serveru Root.cz / Re: Root má mizernou dostupnost

« kdy: 30. 03. 2011, 09:36:43 »

Přidám, jak se problém projevuje. Zatím jsme ho pozorovali vždy v souvislosti s tcp portem 80 (web):
- z windows odejde SYN paket s nenastaveným tcp timestamp parametrem k serverům iinfa, servery odpoví, spojení je navázáno
- z linuxu ve firemní síti odejde SYN paket s nastaveným tcp timestamp parametrem k serverům iinfa a zpátky ve velkém množství případů nepřijde ani SYN/ACK paket. Pokud náhodou SYN/ACK dorazí, spojení je navázáno a proběhne, to se ale vyskytuje zřídkakdy.

Už z podstaty problému je jedno, v jaké aplikaci se zkoušíme připojit, selže telnet, wget i browsery (firefox, chrome).

Pokoušeli jsme se najít problém u nás v síti, ale neúspěšně, routování autonomního systému i kancelářské sítě je OK a víc toho neodhalíme...

Co "pomáhá" klientovi s Linuxem:
echo 0 > /proc/sys/net/ipv4/tcp_timestamps

Pak se servery iinfa záhadně rozjedou...

Jde o podobný (možná stejný) problém jako na http://www.dslreports.com/forum/r20384007-tcptimestamps-and-two-clients-behind-one-nat-router

Edit: Ještě dodám, že s IPv6 spojeními problémy nejsou :-) takže se načte text rootu/lupy, ale protože css a obrázky jsou na IPv4 only webech, tak prohlížeč čeká na timeouty.