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.
Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 65 tisíc vývojářů. Z Česka jich bylo 710. Ze Slovenska 246.
Konfigurace A: Linux router (FC5) s eth0 smer LAN (ip_eth0), eth1 WAN (ip_eth1), wlan0 down. V ramci LAN je SIP brana (ip_SIP). Vse funguje OK, vcetne SIP telefonu
Zmena konfigurace (bez restartu systemu, scriptem) na Konfiguraci B: Linux router s eth0 smer LAN (ip_eth0), eth1 down, wlan0 WAN (ip_wlan0). V ramci LAN je SIP brana (ip_SIP). Vse funguje OK.
vratim zpet konfiguraci A (opet bez restartu systemu) a prestane fungovat NAT pro SIP.
tcpdump -n -i eth1 port 5060
zde by melo prece byt (!):
10:06:46.093893 IP ip_wlan0.sip > ip_SIP_SERVER.sip: SIP, length: 497
10:06:46.093893 IP ip_eth1.sip > ip_SIP_SERVER.sip: SIP, length: 497
Jinak NAT funguje, napr. pro browseni z laptopu pripojeneho do LAN.
iptables -t nat -L
nevypise zadne pravidlo kde by se vyskytovala adresa ip_wlan0,
naopak
iptables -v -L -t nat ... 59 5067 SNAT all -- any eth1 172.16.0.0/24 anywhere to:10.25.9.228 ...pritom system zarputile NATuje ip_SIP na ip_wlan0, diky cemuz samozrejme prestane fungovat SIP telefon.
rmmod ipt_MASQUERADE iptable_nat ip_tables xt_state xt_tcpudp x_tables xt_multiport
Dotaz: JAK toto vyresit bez rebootu? Jak disgnostikovat funkci iptables v takoveto situaci?
--------------- System: FC5 Kernel: 2.6.20-1.2320.fc5smp iptables -V iptables v1.3.5 NAT nastavuju takto:pri restartu iptables vsechny chainy flushuju vcetne nat:$IPT -t nat -A POSTROUTING -s net_eth0/24 -o eth1 -j SNAT --to ip_eth1
resp.$IPT -t nat -A POSTROUTING -s net_eth0/24 -o wlan0 -j SNAT --to ip_wlan0
iptables -F iptables -X iptables -Z iptables -t nat -F iptables -t nat -X iptables -t nat -Z
iptables
můžete diagnostikovat buď (složitěji ale přesněji) přes target LOG
nebo ULOG
nebo přes počítadla paketů v jednotlivých řetězcích (jednodušší, ale mně to zatím vždy stačilo).
Jak vypadá routování na tom stroji – používá se pouze hlavní routovací tabulka, nebo jsou tam nějaká pravidla? Jak vypadají pakety na vstupu do routeru – tcpdump -n -i eth0 port 5060
– mají očekávané IP adresy?
Nevím, zda jde o TCP nebo UDP, ale nemůže být problém v tom, že NAT si myslí, že jde pořád o stejné spojení a tudíž natuje podle stále stejných pravidel (což je správné chování)? Zkuste tabulku spojení vyprázdnit přes conntrack -F
.
... IP ip_SIP.sip > ip_SIP_SERVER.sip: SIP, length: XXX
iptables -t conntrack -F
?
iptables v1.3.5: can't initialize iptables table `conntrack': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
conntrack: bylo to mysleno jakoNe,iptables -t conntrack -F?
conntrack
je samostatná utilita, není přímo součástí iptables, ale je v samostatném balíku conntrack-tools.
Diky moc za nasmerovani. Pridal jsem do scriptu na rekonfiguraci spojeni conntrack -F
a funguje to jako vino.
navazane SIP spojeni je pekne videt pomoci
conntrack -L | grep 5060
Pozn: conntrack tools v FC5 nebyly, ale spravilo to trivialni "yum install conntrack"
, natahly se z extras.
Tiskni
Sdílej: