Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
Microsoft se vyhnul pokutě od Evropské komise za zneužívání svého dominantního postavení na trhu v souvislosti s aplikací Teams. S komisí se dohodl na závazcích, které slíbil splnit. Unijní exekutivě se nelíbilo, že firma svazuje svůj nástroj pro chatování a videohovory Teams se sadou kancelářských programů Office. Microsoft nyní slíbil jasné oddělení aplikace od kancelářských nástrojů, jako jsou Word, Excel a Outlook. Na Microsoft si
… více »Samba (Wikipedie), svobodná implementace SMB a Active Directory, byla vydána ve verzi 4.23.0. Počínaje verzí Samba 4.23 jsou unixová rozšíření SMB3 ve výchozím nastavení povolena. Přidána byla podpora SMB3 přes QUIC. Nová utilita smb_prometheus_endpoint exportuje metriky ve formátu Prometheus.
Správcovský tým repozitáře F-Droid pro Android sdílí doporučení, jak řešit žádosti o odstranění nelegálního obsahu. Základem je mít nastavené formální procesy, vyhrazenou e-mailovou adresu a být transparentní. Zdůrazňují také důležitost volby jurisdikce (F-Droid je v Nizozemsku).
9.2.2012 12:32
| Přečteno: 1635×
| 
Tak nějak se mi zdá, že klasifikace iptables -m state --state ESTABLISHED,RELATED občas zašvindluje.
U nás v práci máme hraniční router a v něm stovky pravidel iptables určujících, odkud kam se smí a nesmí. Někde skoro na začátku se skví tohle:
# ACCEPT ustanovene spojeni iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Očekává se od toho, že pakety patřící do již navázaného spojení (ESTABLISHED) a také pakety navazující nové spojení v rámci již běžící komplexnější komunikace (RELATED) budou bez dalšího odroutovány. Při tom do kategorie ESTABLISHED se počítají i pakety SYN-ACK odpovídající na úvodní SYN při navazování TCP soketu. Dobře, tak se to obvykle dělá. Jenže v logu routeru vidíme četné zakázané pokusy o navázání spojení iniciovaného z nějakého WWW serveru se zdrojovým portem 80, kde cílovým strojem je nějaká naše stanice vysoký port. Na první pohled to vypadá, jako kdyby WWW server byl asi kraknutý a snažil se připojit z portu 80 na pécéčko klienta.
Avšak zdání klame. Ve skutečnosti šňupání paketů pomocí tcpdump ukázalo, že nic takového se neděje, žádné SYN pakety od cizích WWW serverů neběhají. Co se tedy děje? Nejspíš to, že od stanice odejde regulérní navazující SYN a modul -m state si ho nevšimne. Následně server vrátí potvrzující paket SYN-ACK a ten je vyhodnocen jako pokus o navázání spojení zvenčí na stanici a tedy odmítnut.
Jiné vysvětlení mě nenapadá. Navazující SYN nemohl odejít jinudy, to je vyloučeno. A zakázaný paket od serveru musí mít nastavený příznak SYN, protože tam máme taky pravidlo
iptables -A FORWARD -p TCP ! --syn -m state --state NEW -j NOTSYNKdyby ten nečekaný paket neměl SYN, byl by chainem NOTSYN zalogován jiným způsobem, než jak se to děje. Nevidím jinou možnost, než že modul -m state občas zachybuje. Což má ovšem za následek, že spojení je odmítnuto, klient to musí zkusit znovu a uživatel pak vidí zhoršenou odezvu.
Tiskni
Sdílej:
Spíš myslím že ne. Když se na TCP spojení dlouho nic neděje, opravdu router může usoudit, že spojení není aktuální a příští paket potom bude vyhodnocen jako NEW. Ale ten příští paket nebude přece SYN? A když nebude, zamečuje pravidlo NEW_NOT_SYN a podle toho to bude zalogováno, což se ale neděje.
9.2.2012 15:53
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
A jsou po celé cestě stejné timeouty? V linuxu by měly platit jako zde uvedené ... ?
Mimochodem, pokud je spojení vyhodnoceno jako prošlé, mělo by se o tom přes icmp či nějaký tcp/reset poslat info ...
A nepřeplňuje se connection-tracking tabulka?
Nevím,to bych měl vidět v logu? Log je hodně objemný, co mám grepovat? Zdá se mi to dobrá myšlenka, ale v logu nic nevidím.
V logu jádra není nic, co by ukazovalo na přeplnění tabulky pro conntrack. Škoda, vypadalo to jako slibný vysvětlení.
Pozorujem to však spravidla na ssh spojení.
jenže v logu routeru vidíme četné zakázané pokusy o navázání spojení iniciovaného z nějakého WWW serveru se zdrojovým portem 80, kde cílovým strojem je nějaká naše stanice vysoký port.
Ve skutečnosti šňupání paketů pomocí tcpdump ukázalo, že nic takového se neděje, žádné SYN pakety od cizích WWW serverů neběhají.
Pokud to router zahodí, tak je snad logické, že to dál po síti neběhá, ne? Nebo kde se to přesně zakáže a kde šňupete tcpdump-em?
Jinak server nemusí poslat SYN+ACK v jednom paketu, může poslat ACK zvlášť a SYN zvlášť, a není vůbec nic proti RFC793, to říká, že ACK a SYN od serveru může být v jednom paketu. Že to tak být může, se časem nějak vytratilo z překladu, takže se na to přehnaně spoléhá, čehož využívá tzv. split handshake attack, na nějž jsou náchylné některé HW routery. Takže otázka je, jestli před iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT není ještě jiné pravidlo, které SYN od serveru (nesprávně) zahodí. Případně se může stát, že se ACK serveru ztratí (nebo zpozdí) někde po cestě k routeru a dorazí pouze SYN.
Až tak ??? Řekněme že klient i server jsou MS. Něco si řeknou a pak zavřou spojení. Uživatel klikne a IE pošle rovnou HTTP request. Pakety odejdou, protože ven pouštíme všecko. Server se zaraduje a pošle odpověď. Pakety od serveru nemečujou s podmínkou
-m state --state ESTABLISHED,RELATEDprotože spojení nebylo řádně navázáno. Ale nemečujou ani s podmínkou
-p TCP ! --syn -m state --state NEWNení to sice SYN, ale není to ani NEW, protože před chvilkou tady nějaký provoz šel. Vypadá to divně, ale když vyslechnu uživatele postižených stanic a všichni se přiznají k použití MS IE, tak by to začalo vypadat jako docela dobrá hypotéza.
Šňupáme samozřejmě na routeru. SYN který není NEW propouštíme. Zahozené něco od serveru šlo na stanici, která před chvilkou s tím samým serverem normálně komunikovala. Ta chyba není fatální, uživatelé vůbec nevědí, že jim něco nefunguje. Jenom mají asi delší odezvu.
Ono to jenom vypadá jako pokus o pokračování spojení ze serveru na stanici, je to ze zdrojového portu 80 na nějaký vysoký port, ale není to tak. Číslo portu stanice je jiné než ze kterého šlo předchozí spojení. Takže to není chyba conntrack a dokonce ani chyba Microsoftu, je to jen obyčejný útok. Omlouvám se za zbytečné plašení. Jako IP adresy atakujících serverů jsou fingovány adresy oblíbených webových serverů, takže vlastně každému logovanému případu předcházelo skutečné připojení na tento server v nedávné minulosti.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz