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.
iptables -I INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
prejdú cez posledné pravidlo v INPUT chain-e ktoré všetky pakety pošle na NFLOG target.
iptables -A INPUT -j NFLOG --nflog-prefix "INPUT chain DROP"
To logovacie pravidlo zaloguje pakety, ktoré chodia ako odpoveď na spojenie iniciované odo mňa. Nerobí to však vždy. Mám pocit, že to súvisí s dĺžkou paketov.
Policy pre INPUT chain je DROP. Distro je gentoo, Jadro 2.6.36.2, iptables 1.4.10.
Ako prídem na to, či sa nejaký paket mal alebo nemal match-núť pravidlom ESTABLISHED,RELATED?
man iptables
. Uvádět při problémech s firewallem dva vybrané příkazy pro přidání pravidel je k ničemu – je potřeba sem dát kompletní výpis pravidel iptables
, jak jsou v tabulkách jádra. Taky je dobré popsat, jak vypadá spojení, které zkoumáte – protokol, odkud je spojení navázané atd.
je potřeba sem dát kompletní výpis pravidel iptables, jak jsou v tabulkách jádra.Ten je pomerne dlhý a váham či to uverejňovať. Security, by obscurity
Taky je dobré popsat, jak vypadá spojení, které zkoumáte – protokol, odkud je spojení navázané atd.ADSL pripojenie, kde ADSL modem je v bridge-mode. Linux robi PPP spojenie. Problém mávam pri pokuse o prenos väčšieho (rádovo niekoľko GB) súboru cez rsync/ssh z LAN na stroj vonku. Časť sa prenesie, ale potom to odvisne - dáta sa neprenášajú a v logu mi začnú pribúdať záznamy o paketoch, ktoré sa mali podľa mňa matchnúť cez ESTABLISHED ale sa nematchli. Hláška z logu konkrétne hovorí:
Jun 22 07:08:30 amctn INPUT chain DROP IN=ppp0 OUT= MAC=... SRC=62.153.129.46 DST=212.5.197.56 LEN=52 TOS=08 PREC=0x00 TTL=58 ID=50699 DF PROTO=TCP SPT=22 DPT=61056 SEQ=999827174 ACK=1561835762 WINDOW=1002 ACK URGP=0 MARK=0
SPT a DPT sedí. Čo iné sa dá sledovať? Odchytiť cez tcpdump/wireshark kompletnú komunikáciu a zistiť či sedí aj SEQ a ACK?
Ešte jednu zaujímavú vec som si všimol. Mám:
iptables -L INPUT -xv
Chain INPUT (policy DROP 1992 packets, 510309 bytes)
pkts bytes target prot opt in out source destination
46940 4683356 icmp_pk icmp -- any any anywhere anywhere
8325 632664 ACCEPT udp -- ppp0 any anywhere anywhere udp dpt:ntp
877161 11691158 ACCEPT all -- ppp0 any anywhere anywhere state RELATED,ESTABLISHED
...
51024 17494080 NFLOG all -- any any anywhere anywhere nflog-prefix "INPUT chain DROP"
iptables -L FORWARD -xv
Chain FORWARD (policy DROP 12 packets, 1032 bytes)
pkts bytes target prot opt in out source destination
27495 2573807 icmp_pk icmp -- any any anywhere anywhere
...
# iptables -L icmp_pk -xvn
Chain icmp_pk (2 references)
pkts bytes target prot opt in out source destination
11324 950536 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
11140 3516175 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 5
780 44234 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 4
51336 2752928 NFLOG icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 nflog-prefix "accepted"
51336 2752928 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
icmp type 3 code 4 je "icmp fragmentation-needed". Je normálne, že tam neprišiel ani jeden paket?
Problém mávam pri pokuse o prenos väčšieho (rádovo niekoľko GB) súboru cez rsync/ssh z LAN na stroj vonku.Na to nemá
INPUT
vůbec žádný vliv, ten se týká jen paketů začínajících nebo končících na daném počítači. Procházející pakety procházejí řetězem FORWARD
.
Pokud se ty pakety objeví v INPUT
, znamená to podle mne, že se „neodNATovaly“ (tj. IP adresa cíle se měla vrátit inverzně k tomu, jak se původně změnila adresa zdroje). Hledal bych problém buď v zaplnění tabulky spojení, kterou používá NAT, nebo nějaký podivný limit na délku spojení počítaný ne od posledního paketu, ale od začátku spojení.
Pokud se ty pakety objeví v INPUT, znamená to podle mne, že se „neodNATovaly“To znie logicky.
Hledal bych problém buď v zaplnění tabulky spojení, kterou používá NAT, nebo nějaký podivný limit na délku spojení počítaný ne od posledního paketu, ale od začátku spojení.
Kde také niečo hľadať?
dmesg povie
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
65536
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
177
iptables -nvL
, který vám ukáže počty paketů, které danému pravidlu vyhověly.
Předpokládám, že v tabulce nat
(iptables -t nat -nvL
) žádná pravidla, která by operovala s počtem paketů apod. nemáte – třeba nějaké pravidlo s connbytes
, connlimit
, limit
, quota
apod.
V gentoo mam balíček net-firewall/conntrack-tools, umí pěkně vypisovat sesnam spojení, to by mohlo pomoci?
Podle následujícího schématu je nejdřív odnatování a pak INPUT?
iptables
v PREROUTING, dělá se automaticky na základě příslušného pravidla SNAT v POSTROUTING. Pokud se z nějakého důvodu neprovede, pokračuje paket dál do routování s cílovou IP adresou routeru, takže půjde do INPUTu.
Tiskni
Sdílej: