Zulip Server z open source komunikační platformy Zulip (Wikipedie, GitHub) byl vydán ve verzi 9.0. Přehled novinek v příspěvku na blogu.
Byla vydána (𝕏) nová verze 24.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 24.7 je Thriving Tiger. Přehled novinek v příspěvku na fóru.
Binarly REsearch upozorňuje na bezpečnostní problém PKFail (YouTube) v ekosystému UEFI. Stovky modelů zařízení používají pro Secure Boot testovací Platform Key vygenerovaný American Megatrends International (AMI) a jeho privátní část byla při úniku dat prozrazena. Do milionů zařízení (seznam v pdf) po celém světě tak útočníci mohou do Secure Bootu vložit podepsaný malware. Otestovat firmware si lze na stránce pk.fail. Ukázka PoC na Linuxu na Windows na YouTube.
Mobilní operační systém /e/OS (Wikipedie) založený na Androidu / LineageOS, ale bez aplikací a služeb od Googlu, byl vydán ve verzi 2.2 (Mastodon, 𝕏). Přehled novinek na GitLabu. Vypíchnuta je rodičovská kontrola.
Společnost OpenAI představila vyhledávač SearchGPT propojující OpenAI modely umělé inteligence a informace z webů v reálném čase. Zatím jako prototyp pro vybrané uživatele. Zapsat se lze do pořadníku čekatelů.
Distribuce Linux Mint 22 „Wilma“ byla vydána. Je založená na Ubuntu 24.04 LTS, ale s desktopovým prostředím Cinnamon (aktuálně verze 6.2), příp. MATE nebo Xfce, balíkem aplikací XApp, integrací balíčků Flatpak a dalšími změnami. Více v přehledu novinek a poznámkách k vydání.
Příspěvek na blogu Truffle Security: Kdokoli může přistupovat ke smazaným a privátním repozitářům na GitHubu.
Byla vydána nová verze 14 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v cgitu. Vypíchnout lze podporu rozšíření v Lua.
Byla vydána verze 1.80.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Apple oznámil, že v beta verzi spustil své Apple Maps na webu. Podporován je také webový prohlížeč Chrome. Ne však na Linuxu.
iptables -t nat -A PREROUTING -p tcp -d ... --dport 80 -j DNAT --to-destination ...
192.168.1.100 odtud potrebuji presmerovat
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 71.7.163.29:8080Nebude to fungovat, pokud by cílový server (jehož adresu zadáte v prohlížeči), byl ve vaší síti (tj. měl adresu typu 192.168.1.něco). Podmínkou také je, že klienti (prohlížeč) posílají s HTTP požadavkem hlavičku
Host:
(v HTTP/1.1 už je povinná a všechny klasické moderní prohlížeče ji posílají) – jinak nebude proxy vědět, kam se má dál dotázat na skutečný obsah. Jinak to, o co se pokoušíte, se nazývá transparentní proxy.
Zároveň potřebujete, aby se klienti mohli dotazovat DNS serverů nebo zprovoznit v síti místní DNS resolver, kterého se budou dotazovat.
Pokud by vám to stále nefungovalo, spusťte si na routeru tcpdump -ni interface 'port 80'
(resp. port 8080) postupně na vnitřním a vnějším rozhraní a sledujte, kam až pakety dorazí a kde se ztrácí.
Pakety procházející přes PREROUTING
se upraví ještě před routováním, takže na firewallu pak musíte mít povolenou komunikaci a navázání spojení z vnitřního počítače na 71.7.163.29:8080 a v opačném směru existující spojení z 71.7.163.29:8080 na vaše klientské počítače.
Mimochodem, předpokládám že normální routování máte už na routeru rozchozené a že např. s vypnutým firewallem se z klienta na web normálně dostanete.
Pokud máte možnost rozumně nastavit proxy na klientských počítačích a chcete pouze klienyt donutit používat vaší proxy, zvažte nastavení proxy a na routeru zablokujte veškerou odchozí komunikaci na port 80 (a např. 8080 a 3128, případně veškerou odchozí komunikaci) a jako výjimku povolte pouze komunikaci na váš proxy server. Nikam jinam se klienti připojit nebudou moci, ale budou vědět, že jsou připojeni přes proxy server (občas to může předejít nějakým nedorozuměním apod. – transparentní proxy server je přeci jen svého druhu únos spojení).
OUTPUT
správně. Že počítač pakety zahazuje může mít podle mne ve vašem případě jediný důvod – firewall. O překlad zdrojové adresy paketu s odpovědí by se měl postarat DNAT. Takže do routování a firewallu by měl paket odpovědi od proxy vstupovat se zdrojovou IP adresou nastavenou na IP serveru, kam původně směřoval dotaz prohlížeče, a port 80. Těmto paketům je nutné povolit průchod firewallem vašeho počítače (v INPUT). Asi nejjednodušší je
iptables -A INPUT -p tcp -m state --state ESTABLISHED, RELATED -j ACCEPTčímž povolíte komunikaci pro všechna již navázaná spojení. Pokud byste měl na počítači 192.168.1.100 více rozhraní, a pakety na server měly putovat jiným rozhraním, než pakety k proxy serevru, vstupoval by do hry ještě RP filtr, který kontroluje, zda paket přišel tím rozhraním, kde je očekáván. Ale pokud máte na 192.168.1.100 jen jedno rozhraní, neměl by na to mít RP filtr žádný vliv.
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martiansjestli si o těch příchozích paketech jádro nemyslí něco divného. A zkusil bych na tom počítači během testu úplně vypnout firewall pro příchozí pakety – vymazat
INPUT
a nastavit mu default policy na ACCEPT
. Ještě můžete zkusit vypsat si pravidla iptables s parametrem -v
(např. iptables -vL
), zobrazí se i počty paketů, které prošly jednotlivými větvemi. Pokud nemáte na počítači jiný síťový provoz, můžete podle toho poznat, která pravidla se aplikovala. Pokud tedy je problém skutečně v nastavení firewallu. Ale pokud pakety se správnými hlavičkami dorazí až na vaši síťovou kartu a nemáte problém s routováním, nevidím už jiné místo, kde by mohl být problém…
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 195.70.150.7:80 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -P INPUT DROPA fungovalo to podle předpokladu, tj. na jakoukoliv adresu se načetla hlavní stránka ábíčka (jenom odkazy se trochu zbláznily - vzniklo tohle: http://www.seznam.cz/blog/limoto/2007/2/23/170597)
#telnet www.google.com 80 GET / HTTP/1.0⏎ Host: www.google.com⏎ ⏎Dostat byste měl HTML kód titulní stránky Googlu.
Tiskni
Sdílej: