Google oznámil, že Quick Share na Androidu funguje s AirDropem na iOS. Zatím na telefonech Pixel 10. Uživatelé tak mohou snadno přenášet soubory z telefonů s Androidem na iPhony a obráceně.
Byla vydána nová verze 8.5 (8.5.0) skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Přináší řadu novinek a vylepšení (URI Extension, Pipe Operator, Clone With, …). Vydána byla také příručka pro přechod z předchozích verzí.
Evropská komise zahájila tři vyšetřování týkající se cloudových platforem Amazon Web Services (AWS) a Microsoft Azure. Evropská exekutiva, která plní také funkci unijního antimonopolního orgánu, chce mimo jiné určit, zda jsou americké společnosti Microsoft a Amazon v cloudových službách takzvanými gatekeepery, tedy hráči, kteří významně ovlivňují provoz internetu a musí dle nařízení o digitálních trzích (DMA) na společném trhu
… více »Společnost Meta Platforms vyhrála ostře sledovaný spor o akvizici sítě pro sdílení fotografií Instagram a komunikační aplikace WhatsApp. Podle amerického soudu firma jejich převzetím neporušila antimonopolní zákon, protože si tak nemonopolizovala trh sociálních sítí. Žalobu na Metu podala před pěti lety americká Federální obchodní komise (FTC). FTC argumentovala, že Meta, tehdy známá jako Facebook, koupila tyto dvě společnosti v letech 2012 a 2014 proto, aby s nimi nemusela soutěžit.
Home Assistant včera představil svůj nejnovější oficiální hardware: Home Assistant Connect ZBT-2 pro připojení zařízení na sítích Zigbee nebo Thread.
Byla vydána verze 9.1 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a informačním videu.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,809 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější superpočítač v Evropě JUPITER Booster s výkonem 1,000 exaFLOPS je na čtvrtém místě. Nejvýkonnější český superpočítač C24 klesl na 192. místo. Karolina, GPU partition klesla na 224. místo a Karolina, CPU partition na 450. místo. Další přehledy a statistiky na stránkách projektu.
Microsoft představil Azure Cobalt 200, tj. svůj vlastní SoC (System-on-Chip) postavený na ARM a optimalizovaný pro cloud.
Co způsobilo včerejší nejhorší výpadek Cloudflare od roku 2019? Nebyl to kybernetický útok. Vše začalo změnou oprávnění v jednom z databázových systémů a pokračovalo vygenerováním problém způsobujícího konfiguračního souboru a jeho distribucí na všechny počítače Cloudflare. Podrobně v příspěvku na blogu Cloudflare.
Byla vydána (Mastodon, 𝕏) první RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
Dnes si ukážeme konfiguraci pro road warrior scénář. Autentizace bude probíhat sdíleným klíčem a výměna klíču bude realizována pomocí IKE démona racoon. Vzhledem k tomu, že bohužel zatím nejčastějším případem, kdy je někomu umožněn přístup do interní sítě zvenčí, je nějaký pán z vedení, ukážeme si, jak využít integrovaného L2TP/IPSec klienta, který je standardně ve Windows 2000/XP. A když už ten přístup bude hotový, ukážeme si, jak se tam dostane sysadmin z Linuxu.
Přehledné porovnání kladů a záporů L2TP/IPSec lze nalézt na http://www.jacco2.dds.nl/networking/freeswan-l2tp.html#ProsCons.
K realizaci našeho scénáře potřebujeme nějakou implementaci protokolu L2TP.
Protokol L2TP (Layer Two Tunneling Protocol) je popsán v RFC 2661. L2TP je v podstatě rozšířením protokolu PPP, který umožňuje spojení pouze mezi přístupovým zařízením (NAS) a klientem. L2TP tento problém odbourává a umožňuje, aby koncová zařízení byla kdekoliv v IP síti. V Linuxu je prakticky L2TP používáno tak, že L2TP vrstva se domluví na specifických parametrech protokolu a vlastní spojení už opět realizuje pppd démon.
Implementace použitá pro naše testování se nachází na http://www.l2tpd.org. Tamtéž lze nalézt odkazy na další implementace. Implementace l2tpd je kompletně v user-space. Několik pokusů o implementaci v kernelu zůstává na mrtvém bodě. Projekt jako takový také není zrovna příliš ve středu zájmu. Poslední verze 0.69 vyšla někdy v roce 2002. Od té doby se nashromáždilo několik patchů, které jsou třeba pro správnou funkčnost.
Patchovaný balíček udržuje Jacco de Leeuw na adrese: http://www.jacco2.dds.nl/networking/freeswan-l2tp.html#L2TPoverview
Pro Debian se udržuje balíček na této stránce: http://packages.qa.debian.org/l/l2tpd.html. Tamtéž by měl být zapracovaný patch na poslední bezpečnostní problém ( http://www.securityfocus.com/archive/1/365211).
Při použití s kernelem 2.6 je třeba mít povolené
CONFIG_LEGACY_PTYS=y.
Alternativní implementace: http://www.mail-archive.com/l2tpd-devel@l2tpd.org/msg00153.html.
Mimochodem, taková poznámka k patentům: http://www.jacco2.dds.nl/networking/freeswan-l2tp.html#Patent
Racoon je implementace IKEv1 protokolu sloužícího pro automatickou výměnu klíčů. Podporuje autentizaci pomocí certifikátů, sdíleného klíče, kerberosu a rozpracována je podpora plain RSA klíčů. Ta je důležitá pro interoperabilitu se *Swan implementacemi. V některém z dalších dílů třeba také na nějakou ukázku dojde ;).
Při testování byla použita distribuce Fedora Core 2, ale stejné chování lze očekávat i u SuSE apod. Balíček, ve kterém se racoon nachází, se jmenuje ipsec-tools.
Podpora pro IPSec je již i v balíku initscripts, takže lze standardně
používat konfigurační soubory typu ifcfg-ipsec0,
keys-ipsec0. Parametry lze najít v
/etc/sysconfig/network-scripts/ifup-ipsec nebo v dokumentaci k
distribuci. Průvodce nastavením IPSecu můžeme spustit příkazem
system-config-network. Konfigurace se nevztahuje na L2TP.
V našem případě ovšem zůstaneme u ruční konfigurace.
Konfigurační soubor pro racoon je /etc/racoon/racoon.conf a obsahuje:
Dále si uvedeme parametry, které jsou podstatné pro náš příklad. Ostatní
parametry lze nalézt v manuálových stránkách - man
racoon.conf. Konfiguraci bereme z pohledu, že racoon je příjemce
spojení. Parametry tedy znamenají, jaké hodnoty jsou akceptovatelné. Pokud
bude racoon iniciátor (klient), budou hodnoty znamenat, jaké parametry
požaduje od druhé strany. Mezi komunikujícími musí nastat vzájemná shoda v
požadovaných a akceptovatelných parametrech.
log <level>; #level - notify, debug, debug2path pre_shared_key "/etc/racoon/psk.txt";listen, padding, timerObsahují direktivy, které umožňují přesněji specifikovat, na jakém portu má racoon poslouchat. Dále obsahují nastavení kolem časovačů a nastavení formátu vyplňování paketů - padding.
remoteremote anonymous { exchange_mode main; generate_policy on; proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key; dh_group modp1024; }}sainfosainfo anonymous { encryption_algorithm 3des; authentication_algorithm hmac_md5; compression_algorithm deflate;}Konfigurační soubor tedy bude ve finále vypadat takto:
path pre_shared_key "/etc/racoon/psk.txt";
|
Jak už někoho určitě napadlo (minimálně ty, co se tím živí), abychom klienta mohli ověřit, musíme ho nějak identifikovat. V případě, že identifikaci nijak zvlášť nespecifikujeme, bere racoon jako bernou minci IP adresu klienta. To ovšem znamená, že tuto adresu potřebujeme vždy vědět předem.
Soubor se sdílenými hesly by potom vypadal nějak takto.
# psk.txt
|
Toto řešení se nám ovšem nelíbí, protože je velmi pravděpodobné, že někdo bude mít adresu dynamickou. Dle kapitoly 4.6.2.1 v RFC 2407 máme tyto možnosti identifikace klienta:
| ID Type Value |
|---|
RESERVED 0 |
ID_IPV4_ADDR 1 |
ID_FQDN 2 |
ID_USER_FQDN 3 |
ID_IPV4_ADDR_SUBNET 4 |
ID_IPV6_ADDR 5 |
ID_IPV6_ADDR_SUBNET 6 |
ID_IPV4_ADDR_RANGE 7 |
ID_IPV6_ADDR_RANGE 8 |
ID_DER_ASN1_DN 9 |
ID_DER_ASN1_GN 10 |
ID_KEY_ID 11 |
V situaci, kdy nám stačí jedno sdílené heslo pro všechny klienty (např.
máme 5 manažerů) a používáme autentifikaci pomocí L2TP, bychom potřebovali
ID_IPV4_ADDR_SUBNET 4. Tato možnost bohužel zatím není v
racoonu implementována (hledá se nový majitel tohoto kousku kódu ;)).
Soubor se sdílenými hesly by potom mohl vypadat nějak takto.
# psk.txt
|
Vyhnout se tomuto problému je možné při použití jiné metody
identifikace. Například lze použít ID_FQDN 2. V konfiguraci
racoona (klient) potom použijeme v sekci remote direktivu
peers_identifier fqdn "fakt.jsem.to.ja.ver.mne.cz";.
V konfiguraci racoona (server) použijeme v sekci remote
direktivu peers_identifier fqdn;. Soubor se sdílenými hesly by
potom vypadal takto.
# psk.txt
|
Po tom, co se přátelsky poplácáme po rameni, zase raději vychladneme, protože nastavit způsob identifikace ve windows pravděpodobně nepůjde.
Další věc je, že takto peers_identifier fqdn
"fakt.jsem.to.ja.ver.mne.cz"; si identifikaci může nastavit
kdokoliv.
V okamžiku, kdy máme hotovou konfiguraci racoona, musíme zajistit
pravidla, podle kterých se spojení bude šifrovat. Níže uvedený skript
zařídí, že paket jdoucí na port 1701 (l2tp) musí být šifrovaný. V okamžiku,
kdy se klient pokusí spojit pomocí L2TP/IPSec, se spustí proces, ve kterém se
ustanoví IPSec tunel. Na straně serveru racoon se díky direktivě
generate_policy on; vygenerují pravidla pro komunikaci s
klientem. Tímto šifrovaným tunelem již potom dále probíhá L2TP
komunikace.
#!/bin/sh
|
Politika se nastavuje pomocí nástroje setkey - více man
setkey. Pro testování doporučuju pouštět racoon na popředí a mít v
konfiguraci zapnutý debug: bash# racoon -F.
Hlavní konfigurační soubor pro l2tpd je
/etc/l2tpd/l2tpd.conf a obsahuje:
lnsLNS je zkratka pro L2TP Network Server. Konfigurace v této sekci se tedy vztahují k nastavení serveru.
[lns default] ip range = 10.10.10.10-10.10.10.100local ip = 10.10.10.1require chap = yesrefuse pap = yesrequire authentication = yesname = LinuxVPNserverppp debug = yespppoptfile = /etc/ppp/options.l2tpdlac
LAC je zkratka pro L2TP Access Concentrator. Konfigurace v této sekci se tedy vztahují k nastavení klienta. Jelikož konfigurujeme server, zůstane tato sekce prázdná. Konfigurační soubor tedy bude ve finále vypadat takto:
# l2tpd.conf
|
V souboru /etc/ppp/options.l2tpd jsou již klasické parametry pro PPP
démona.
ipcp-accept-local
|
V souboru /etc/ppp/chap-secrets uvedeme jména a hesla
uživatelů, kterým chceme umožnit připojení.
# Secrets for authentication using CHAP
|
Pro testování doporučuju pouštět l2tpd na popředí: bash# l2tpd
-D.
Možností jak nastavit OS Windows bude zřejmě více, já uvedu ten, který znám.
Start - Nastavení - Ovládací panely - Síťová připojení. Vlevo nahoře je odkaz na Vytvořit nové připojení. Dále postupujeme takto: Připojit k firemní síti - Připojení k VPN - zadáme libovolný název připojení - zadáme ip/fqdn adresu našeho VPN serveru - dokončíme.
Dále je potřeba nastavit sdílené heslo (PSK - Pre Shared Key). V konfiguraci serveru jsme si zvolili PSK "hladjemujnepritel". Spustíme vlastnosti připojení a heslo zadáme do nastavení protokolu IPSec - viz obrázek.
Uložíme vlastnosti a zkusíme vytočit připojení. Tam ještě zadáme uživatelské jméno a heslo, které musí odpovídat chap-secrets na VPN serveru.
Konfigurace klienta je v podstatě stejná jako konfigurace serveru. V
sekci remote uvedeme místo "anonymous" IP adresu našeho VPN
serveru. Konfigurační soubor bude vypadat takto:
# racoon.conf
|
Pravidla, podle kterých se kernel rozhoduje, zda pakety šifrovat, či ne, opět zavedeme pomocí nástroje setkey.
#!/bin/sh
|
V konfiguračním souboru /etc/l2tpd/l2tpd.conf nyní
potřebujeme sekci lac. Parametrem lns říkáme, na
jaké adrese sedí náš přístupový VPN server.
[global]
|
V souboru /etc/ppp/options.l2tpd je změn více. Důležité je
uvést name, protože tímto říkáme lns, jakým uživatelským
jménem se budeme autentizovat.
noauth
|
Záznam pro toto jméno musíme tedy mít v chap-secrets.
# chap-secrets
|
Pokud máme konfigurace připraveny, můžeme připojení spustit.
bash# echo "c vpn" > /var/run/l2tp-control
|
Parametr "c vpn" znamená, že l2tpd má iniciovat spojení (c
jako connect) podle sekce lac s názvem "vpn".
L2tpd se pokusí připojit na port 1701 na přístupovém VPN serveru. Protože VPN server má v politice nastaveno, že vše, co jde na port 1701, musí být šifrované, spustí se proces ustanovení šifrovaného IPSec tunelu. Jakmile se podaří tunel sestavit, proběhne již zabezpečeným kanálem autentizace na úrovni l2tp. Klient je připojen, je mu přidělena ip adresa a může vesele firemní poštou posílat hanbaté obrázky a provádět jiné podobné běžné pracovní úkony.
Jedním z velkých problémů, který ještě není uspokojivě vyřešen, je průchod NATem. Podpora NAT traversal pro transport mód v racoonu zatím není implementována.
Dnes ukázaný scénář je vhodný spíše pro malé sítě a firmy, kde změna sdíleného hesla není problémem. Lepší správu v případě velkého množství klientů nám zabezpečí použití certifikátů. Jakým způsobem nahradit sdílený klíč pomocí certifikátů si ukážeme příště.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: