Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Richard Biener oznámil vydání verze 14.1 (14.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 14. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2023. Vybráni byli Bruno Haible za dlouhodobé příspěvky a správu knihovny Gnulib, nováček Nick Logozzo za front-end Parabolic pro yt-dlp a tým Mission logiciels libres francouzského státu za nasazování svobodného softwaru do praxe.
iptables --table filter --new-chain SECURE_SSH iptables --table filter --append SECURE_SSH --match recent --set --name SECURE_SSH_RECENT iptables --table filter --append SECURE_SSH --match recent --update --name SECURE_SSH_RECENT --hitcount 10 --seconds 60 --jump DROP iptables --table filter --append SECURE_SSH --jump ACCEPT iptables --table filter --append INPUT --match state --state NEW --protocol TCP --match multiport --destination-port 22 --jump SECURE_SSHA to je asi tak všetko čo mám - čomu rozumiem. Chcem sa ale opýtať, že aké su ešte možné techniky škodenia a ako im zabrániť na firewalle? Napríklad na nete som našiel takéto niečo:
iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN FIN,SYN --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags SYN,RST SYN,RST --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,RST FIN,RST --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,ACK FIN --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags PSH,ACK PSH --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags ACK,URG URG --jump DROPO čo tu presne ide? Na rôznych stránkach som našiel rôzne varianty takéhoto kódu, niektoré to boli príklady na 4 riadky, niektoré na 6 a tento 9 riadkový príklad je najdlhší aký som našiel. Ďalej som našiel takého niečo:
iptables --table filter --new-chain SYN_FLOOD iptables --table filter --append SYN_FLOOD --match limit --limit 1/s --limit-burst 3 --jump RETURN iptables --table filter --append SYN_FLOOD --jump DROP iptables --table filter --append INPUT --protocol TCP --syn --jump SYN_FLOODTomuto rozumiem čo robí, len ten limit je nastavený správne? Aké sú ďalšie techniky na obranu proti svinstvu z netu? Vopred vám veľmi pekne ďakujem za odpovede.
napríklad privátne adresy nemajú čo hľadať na rozhraní, ktoré ide do netu
To neplatí obecně. IPSec je jedna z důležitých výjimek.
(Ať tak nebo tak, IPv4 se svými „privátními“ adresami je něco jako mor, protože kvůli němu přestal fungovat Internet „tak, jak měl“ a zvítězily pak pochybné technologie typu Skype, které celý uměle vytvořený problém „řeší“.)
Základní technika obrany proti svinstvu z netu (na které všechno ostatní stojí) je aktuální kernel. Pokud jde o ip{,6}tables, filtrovat se dá téměř všechno, ale v každém případě by mělo být povolené ICMP{v4,v6}. Dají se nastavit omezení na frekvenci a typ zpráv, ale bez ICMP může docházet ke spoustě ošklivých jevů jak pro klienty serveru ve vnějším Internetu, tak pro stroje ve vnitřní síti, pro které server třeba slouží jako router. Jde zejména o MTU. Když je někde po cestě menší MTU než lokální, uživatelům se pak třeba nestahují z některých serverů stránky, případně se jejich stahování pokaždé na pár minut zasekne.
Pravidla s typy TCP paketů by pravděpodobně měla být vhodně seřazená a na vhodném místě v řetězci oddělená něčím jako
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
To oddělí kombinace flagů, které jsou podezřelé vždy, od těch, které se v navázaném spojení můžou vyskytovat. To všechno by pak mělo být před přijímacími pravidly pro různé konkrétní protokoly nad TCP. Otázkou zůstává, jestli má smysl „závadné“ kombinace flagů takto fitrovat. Nesmyslné kombinace musí zahodit přímo TCP stack v kernelu. (Kdyby na něj nebylo spolehnutí, Internet by byl velmi nebezpečným místem.) Jediné vysvětlení by mohlo být, že správce u nějaké konkrétní služby neočekává jisté typy chování (protistrany), takže si může dovolit některé zvláštnosti odfiltrovat. Nicméně nepřipadá mi, že by se něco takového obecně hodilo jako globální nastavení pro všechny protokoly nad TCP.
Ochrana proti SYN floodingu je v kernelu zabudovaná pro IPv6 i IPv4 a ve většině případů není nutné vymýšlet na to nějaká explicitní pravidla. Přímé filtrování na základě frekvence se sice na první pohled může jevit jako dobrý nápad, ale nějaký globální limit nadělá nakonec víc škody než užitku, protože jeden útočník útočící na jednom portu může klidně omezit použitelnost všech ostatních služeb, když se mu zlíbí. Přinejmenším by mělo existovat jiné nastavení pro SSH (velmi nízká frekvence i burst) a jiné třeba pro HTTP, DNS (ano, i tam dojde na TCP, třeba u DNSSEC) či obecně pro protokoly, kde se větší bursty dají očekávat. Rozhodně tady nebude fungovat one size fits all konfigurace; server pak může navenek vypadat jako nespolehlivý a každou chvíli offline.
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTZ "vonku" povoľujem len ICMP, 22, 25, 53U, 53T, 80, 443, 465, 993, 1194 a z "vnútra" je to samozrejme nejaká samba, proxy, ntp, cups, udpxy, ... Ešte raz ďakujem.
Mimochodom, dala by sa viac rozviesť tá myšlienka ohľadom tohto:-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Před tím pravidlem jsou pravidla, která sežerou všechny možné vadné nebo nechtěné pakety — nechtěné nebo vadné za všech okolností, bez ohledu na to, jestli existují nějaká TCP spojení. (Ne že by taková pravidla byla nutná, ale někteří správci je rádi používají kvůli logování — aby měli přehled o případných pokusech o útok.)
Po tom pravidle následují pravidla, která sežerou pakety předstírající existenci nějakého TCP spojení, přestože ve skutečnosti žádné neexistuje. Taková pravidla se používají snad jedině kvůli logování; každopádně ale nechceš, aby se k nim řetězec dostal v případě, kdy spojení opravdu existuje. Že spojení existuje, o tom ví právě modul conntrack
.
Pravidlo s conntrack
se dá použít ještě v jednom případě: Když je nějaký řetězec extrémně dlouhý. Pak se toto pravidlo dá někam na začátek řetězce a ušetří tak průchod celým řetězcem při každém paketu. V některých jiných systémech (FreeBSD, Solaris) má firewall stromovitou strukturu, která se samovolně přeuspořádá a rotuje v závislosti na přijímaných paketech, aby se vždycky nejčastěji přijímaný typ paketu ocitl nejblíž kořeni stromu. (Tím pádem není potřeba řešit dělení pravidel do řetězců a počet pravidel.) Tohle ale v Linuxu (zatím) není, takže se někdy může hodit průchod dlouhým řetězcem zkrátit. Na gigabitovém ethernetu to rozhodně nehraje roli, zatímco u 10 Gb/s se už o takových věcech uvažovat musí.
Tiskni Sdílej: