Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.0.0. Přehled novinek v poznámkách k vydání.
Nejvyšší soud podpořil novináře Českého rozhlasu. Nařídil otevřít spor o uchovávání údajů o komunikaci (data retention). Uvedl, že stát odpovídá za porušení práva EU, pokud neprovede řádnou transpozici příslušné směrnice do vnitrostátního práva.
Minulý týden proběhl u CZ.NIC veřejný test aukcí domén. Včera bylo publikováno vyhodnocení a hlavní výstupy tohoto testu.
Byla vydána nová verze 3.5.0 svobodné implementace protokolu RDP (Remote Desktop Protocol) a RDP klienta FreeRDP. Přehled novinek v ChangeLogu. Opraveno bylo 6 bezpečnostních chyb (CVE-2024-32039, CVE-2024-32040, CVE-2024-32041, CVE-2024-32458, CVE-2024-32459 a CVE-2024-32460).
Google Chrome 124 byl prohlášen za stabilní. Nejnovější stabilní verze 124.0.6367.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 22 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byla vydána nová verze 9.3 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Novinkou je vlastní repozitář DietPi APT.
Byl vydán Mozilla Firefox 125.0.1, první verze z nové řady 125. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vypíchnout lze podporu kodeku AV1 v Encrypted Media Extensions (EME). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 125.0.1 je již k dispozici také na Flathubu a Snapcraftu.
Valkey, tj. svobodný fork již nesvobodného Redisu, byl vydán v první stabilní verzi 7.2.5.
nebijte me pisu to zhlavy, aniz bych si neco kontroloval, takze cesty/parametry iptables muzou byt nekdy blbe... no teda abych se priznal vuybec nevim o cem mluvite... nejaky widlouze, ale nez vas servu, ze ste OT ;)
paket kdyz doleze skrze sitofku z vnejsiho prostredi do stroje do ipv4 stacku, kde se rozhoduje co dal s nim, tak:
1 - si sam ip stack udela kontroly, jestli neni tak trochu vadnej a nemel by se zahodit
2 - pokud mas nastaveny Route Path filtering. poznas podle cisla "1" v "cat /proc/sys/net/ipv4/conf/*/rp_filter" tak se zahodi paket, ktery prisel na rozhranni routovany korektne treba podle MAC adresey v ethernetovym ramci, ale pokud prisel na rozhranni, kde nevede cesta k dane jeho zdrojove ipv4 adrese, tak se zahodi. typicky paket, ktery se tvari, ze prisel z loopbacku (ipv4-src=127.0.0.1) a objevi se na sitofce(interface!=lo) kde dorazil diky MAC adrese atd takovy docela stary podly druh utoku
3 - tak ip stack rozhodl, ze teda s paketem bude neco delat, ze splnuje nejaky zakladni kriteria. posle teda paket do prvniho bodu netfilteru PREROUTING
4 - v kazdem bodu paket prochazi sadou tabulek v poradi -t mangle, -t nat, -t filter. nat tabulka se tusim nenachazi ve vsech bodech.
5 - paket je teda v -t mangle -L PREROUTING a rozhoduje se o tom, jestli se pozmeni paket. treba Type Of Service (-j TOS --set-tos 0x10) , ktera ma pak vliv na nektere Quality Of Service schedulery, ktere rozhoduji o tom, kdy muze nektery paket predbehnout jiny, kolik pasma muzou takove pakety zabrat atd.
6 - tak TOS dopadl jakkoliv, tak ted je paket dostrkan do -t nat -L PREROUTING tady se rozhoduje o prepisu cilove ipv4 adresy pred tim, nez bude paket nasmerovan na nejake rozhranni.
7 - at uz prepis dopadl jakkoliv, tak jeste zbyva -t filter -L PREROUTING tedy se nerozhodne o nicem jinem, nez jestli uz nas paket dostatecne nasral, aby byl zahozen, nebo muze jit dal
8 - ted nad paketem zasahne zase ip stack a rozhodne, kam bude paket dal pokracovat podle nastaveni routovani "route -nl" "ip route show ..." "cat /proc/sys/net/ipv4/ip_forward"
9a- pokud je paket urcen pro cilovou adresu, ktera se nachazi na tomto stroji, pokracuje do -t mangle -L INPUT
9b- pokud je paket urcen jinam a prosel predchozi casti ipstacku, tedy ma 1 v /proc/.../ip_forward a nejak rozume nastaveny routovaci tabulky, tak je odeslan do -t mangle -L FORWARD
10- v INPUT, ci v FORWARD si po mangle paket odbyde uz jen -t filter
11- pokud projde skrz INPUT, tak je dorucen aplikaci do socketu a KONCI pokud vas zajima cesta paketu, ktery prisel z venku a hodla odejit zase jinam ven, nebo nejake dalsi, tak je na to docela pekny obrazek vsech bodu a cest paketu v nejakem .ps nebo .pdf souboru, ktery se tvari jako IPTables Quick Reference nebo neco podobneho. na rootu na toto tema taky bylo vicero clanku... staci hledat na google ;)
a kdyz budes cist pozorne, tak se dozvis, ze -t mangle neni jen o pozmenovani cili -j TOS, ale muze uz v nem i filtrovat -j REJECT nebo bez chybove odpovedi -j DROP, coz muze slusnemu uzivateli zpusobit neprijemne prodlevy, tobe usetrit velmi malo provozu, ale pred hackery tim nic neschovas a ani je nijak nezpomalis, takze slusnosti je -j REJECT, ale na spatnem modemu je rozumejsi -j DROP stejne jako na GPRS nebo kdekoliv, kde platis za objem odchozich/navazanych dat
dal se dozvis, ze nektere parametry jako -o funguji jen v nekterych bodech (typicky nefunguji v PREROUTING), protoze to udava odchozi rozhranni ktere je zname az od routovani, tak nebude fungovat pred provedenim routovani. a dal se dozvis nekolik uzitecnych veci jako pouziti modulu pro inspekci stavu spojeni -m state --state INVALID -j DROP, ale uz se nedozvis detaily, ze navazni spojeni -p udp -m state --state ESTABLISHED -j ACCEPT nad udp je naprosta silenost, kde se predpoklada nejaka doba, po kterou se navazuji pakety jen na zaklade (src,src-port,dst,dst-port), takze takrka kdokoliv muze podvrhnout zdrojovou adresu a poslat nebezpecny paket.
Tiskni Sdílej: