Fórumok
Rocky 8, iptables. Szeretném tudni egy DROP szabály esetén melyik program hozta létre azt a csomagot, ami fennakadt a tűzfalon. Mert látok sok DROP üzenetet valami cél IP-vel, de hogy ki akart kapcsolódni, no azt nem tudom. És hát szeretném tudni, hogy melyik programot kell megnéznem, miért próbál csatlakozni. Ha esetleg az nftables tudja, akkor maximum (vissza)váltok rá. Kerestem neten, nem találtam megoldást, kérdezek.
Mindenkinek eddig és majd ezután is köszönöm a segítséget, egyszerű megoldást próbáltam találni, de akkor úgy látom kicsit bonyolultabb lesz, végignézem a lehetőségeket.
Hozzászólások
Logolni a source portot, es utana netstat vagy ss?
https://superuser.com/questions/34782/with-linux-iptables-is-it-possibl…
Köszi, ezen az oldalon már túl vagyok.
Egyrészt amit leírnak egyik kvázi megoldásként az egy szabály, ahol program szinten tudod megmondani ("Matches if the packet was created by a process with the given command name.") érvényes legyen rá a szabály, de olyat nem tud, ami nekem kellene, hogy egy csomagról mondja meg, hogy melyik program küldte. Tehát nekem pont az ellenkezője kell. Nem megmondani előre ki teheti, hanem ha már megtette valaki, kiderüljön ki volt az.
Ezen felül írják, hogy kivették a funkciót ("Also, it looks like the --cmd-owner option was removed in kernel >= 2.6.15.") egy korábbi kernel verzióból már.
És én igazán a tűzfal logot akarom "feldolgozni", nem folyamatosan nézni netstat/ss programmal, hogy ki lehet. Lehet egy cronjob ami két óránként fut mondjuk le, ezért nem ülnék a gép előtt folyamatosan, hogy na ki lehet az. De jelenleg egy logban szereplő DST=32.54.184.34 IP-vel semmit sem tudok kezdeni, viszont ha a process neve ott lenne, legalább elképzelésem lenne melyik program akar valamit, megnézem a leírást, konfigurációt, hasonló.
OpenSnitch-et néztem, de nem szeretnék ezért plusz programot felpakolni jelenleg, praktikus lenne mindezt az iptables-ből valahogy kiszedni. Ha nem lehet megoldani, így jártam és nem tudom ki próbálkozott. Csak kíváncsi vagyok rá.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
az ip packetben nincs benne hogy melyik progi kuldte a csomagot. a cmdowner is csak ip-port alapjan kikereste melyik sockethez tartozhat, es azt ki futtatja.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Esetleg ez? Nem megy a linkeles valamiert most eppen...
raboof/nethogs: Linux 'net top' tool (github.com)
Köszi, maga program praktikus, de mint a másik válasznál, én nem folyamatosan akarom nézni mi történik, hanem a tűzfal logokban szeretném látni, hogy melyik program próbálkozott amit tiltott a tűzfal. Amit folyamatosan kell nézni, annál ott kell ülnöm és azt figyelni, amit meg nem szeretnék. Meg persze lehet ami csinálja 2 óránként fut mondjuk le.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
A tűzfal (iptables) maga sajnos nem fogja neked megmondani, mi indította a csomagot, csak azt, hogy milyen paraméterekkel. Azt már külön, más módszerrel kell figyelned, hogy adott paraméterekkel mi állítja elő a csomagokat.
(azt ugyan nem írtad, de feltételezem, hogy a host-on belül, azaz Outgoing chain-ról van szó?)
Háttérben futtatott tcpdump szűrve az ismert paraméterekre? (bár, ha nem engeded ki a csomagot, akkor nem tudod interface-en figyelni :( )
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Igen, sima OUTPUT chain. Ez szomorú, ha nincs ilyen a tűzfalban.
Akkor kell valami monitorozó szart találnom ami figyeli a logot és ha lát ilyen üzenetet akkor lefuttat mondjuk egy programot/shell scriptet ami megnézi a port használatot process szinten. Bár ebben nekem még az bizonytalan, ha már látom a DROP üzenetet, akkor jó eséllyel a program is kiléphetett ami generálta volna a forgalmat, mert a hálózati hívás kilépett.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
iptables -nek van owner modulja, csinálj minden ownerhez egy LOG szagályt ami logolja, adott porton melyik uid/gid akar kommunikálni.
Hirtelen jobb 5letem nincsen.
Fedora 38, Thinkpad x280
Köszi, ennyire elbonyolítani nem akartam.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
Ez egyszerűen nem a tűzfal feladata.
Amit szeretnél, arra a Linux Audit való, ez tud logolni bármit amit akarsz, pl:
auditctl -A exit,always -S connect
Mondjuk, ez minden process-t fog logolni, ami connect syscall-t indít, nem csak azt ami fennakadt a tűzfalon.
zrubi.hu
Köszi, nem tudom egyes elemek meddig tudnak visszanyúlni egy kérésnél a rendszeren belül. Csak azt nem értem, ha az owner modulon keresztül olyat tudok mondani az iptables-nek, hogy melyik alkalmazásra húzza rá az adott szabályt, tehát ekkor létezik csomag-process kapcsolat, akkor egy adott csomaghoz miért nem tudja megmondani ki küldte és a log sorba beleírni vagy lehetőséget adni beleíratni. De akkor ezt az auditctl-t is megnézem.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
az iptables nem mai találmány, amikor ezt csinálták, Linux Audit pl még nem is létezett....
Te pedig szándékosan használod ezt az, uj, modernebb - és default - nftables helyett, ugye?
aztán meg reklamász hogy nincs benne xy feature??! - ezt csak én nem értem?
Ezen felül ez az owner alapú tűzfalazás eléggé deskop szagú dolog, szervereken erre nem nagyon van igény - ahogy én látom.
De, akinek mégiskell, az nftables - a doksija szerint - tudja logolni és/vagy matchelni:
https://wiki.nftables.org/wiki-nftables/index.php/Logging_traffic
zrubi.hu
Pedig nagyon jol meg lehet fogni vele a spammelő siteokat ... Szóval bőven van értelme szervernél is.
Fedora 38, Thinkpad x280
Nem tudom miért támadsz, ha én nem tettem, de oké.
Ha már az iptables-ről beszélünk, /usr/sbin/iptables -> xtables-nft-multi, ami a man szerint "xtables-nft-multi: iptables using nftables kernel api". Gyakorlatilag egy nftables kernel api wrapper az iptables. Régi az iptables akkor pipa.
Szándékosan használom, mert régen ezt használtam, és működött, ez a probléma meg aktuális és az iptables adott. Igazából az előző pont alapján nftables-t használok iptables szöveges állományból. Amúgy az eredeti felvetésben is írtam: "Ha esetleg az nftables tudja, akkor maximum (vissza)váltok rá", így el nem zárkóztam. Mond azt, hogy az nftables meg tudja oldani, de úgy érzem ez nem fog menni. Akkor meg mindegy iptables vagy nftables. A linked is szerintem az iptables owner modul nftables féle megoldása, legalábbis nem láttam olyat az oldalon, hogy a logba bekerül a process neve.
Nem reklamáltam, max nem értettem ha process->packet megy az owner-en keresztül, akkor packet->process miért nem.
Ez egy tűzfal, nem szerver vagy kliens tűzfal. Az owner egy gyári modul, érdektelen hol használod, tulaj vagy process alapján szűr, ez a feladata. Mindegy milyen célú gépen futtatod. És akkor nem ment át, de szívesen megismétlem ahányszor szükséges, nem owner alapján akarok szűrni, hanem fordítva, szeretném tudni, hogy melyik process hozott létre egy adott csomagot. Eddig számomra kiderült, hogy az iptables magában nem elég, ahogy szerintem az nftables sem.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
Miért nem??
https://wiki.nftables.org/wiki-nftables/index.php/Logging_traffic
copy-paste innen:
Nem támadok, csak nem értem melyik részét nem érted.
zrubi.hu
Például azt, hogy miért megoldás az eredeti felvetésemre az általad idézett rész, amikor uid (userid) <> "melyik program hozta létre azt a csomagot". Nem felhasználó, hanem program. Soha nem érdekelt a felhasználó.
Neked lehet beakadt az owner modul képbekerülése miatt, hogy engem az érdekel melyik user futtatja, de ez engem nem érdekel, pontosabban elsősorban nem ez érdekel, mert ahogy az elején írtam, az érdekel hogy melyik program hozta létre az adott csomagot. Tehát az idézett rész rajtam, sajnos, nem segít. Lehet ad plusz információt, de nekem nem az kell.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
Na, már értem mit nem értesz ;)
egy egyszerű csomagyszűrő - legyen az iptables, vagy nftables, vagy akármi más által létrehozva - honnan tudná, hogy melyik processz indítja az adott kapcsolatot?? Ő már csak a létrejött socketet láltja, aminek nem létező tulajdonsága az, hogy ki (melyik userspace process) indította, csak a uig, guid.
Neki ez nem feladata, megkockáztatom semmi köze sincs hozzá. hint: kernel space vs user space.
Ha neked ilyen információra van szükséged, akkor több lehetőséged is van:
1. a csomagszűrő logojon minden csomagot, ami érdekes lehet számodra
2. kapcsold be az Linux Audit logot - a számodra érdekes filter szabályokkal.- lásd feljebb.
3. Ha külön külön nem elég amit kapsz, korreláld a kettőt, és megtalálod amit akarsz.
A másik irány, a már más által is említett pwru ami a 'modern' kernelekben lévő (e)BPF-re épít...
De az is 'csak' egy debug tool, nem folyamatos monitorozásra készült.
zrubi.hu
Örülök. :-) Nem vagyok kernel hacker, nem tudom hol milyen struktúrákat, pointereket ad tovább, tárol, reménykedtem tudja valahogy ki küldte a csomagot, hiszen a process-ig majd vissza kell jutni az socket státusznak, de a válaszok alapján a tűzfalig nem jut le ez az információ, úgyhogy valóban külső program lesz a megoldás. Jelenleg az auditctl tűnik jó iránynak, holnap megnézem milyen paraméterezés megfelelő és mire jutok az általa létrehozott log állománnyal. pwru rocky 8 kernel alatt nem működik, legalább alacsonyabb a kernel verziószáma leírás alapján. Majd azért megpróbálom, mert egyébként praktikus programnak tűnik.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
De felesleges auditctl-lel túlbonyolítanod. Ha tudod, hogy milyen UID/GID indította a csomagot, és az nem a root, akkor nagyon könnyen meg tudod mondani, melyik process lehetett, mert rengeteg szerver processz fut adott felhasználóval. Ha pl kiderül, hogy a named user volt, akkor valószínűleg a BIND indította. Ha a postfix user, akkor a Postfix SMTP szerver.
Ha nem derül ki a userből egyértelműen, még mindig lehet tovább vizsgálódni.
Illetve, a logokból nézz gyakoriságot is, sokszor az is eredményre tud vezetni, hogy pl minden 3 órában jön ilyen log, akkor valószínű valami időzített akármicsoda -> Cron-t megnézem.
Sajnos az informatika általában ilyen, nincsenek előre kész válaszok, nyomozgatni kell.
Blog | @hron84
via @snq-
Szerintem volna arra, a portokkal való baszódás az esetek nagy százalékában tulajdonképp azt akarja mondani, hogy "ezt az izét akarom hagyni kommunikálni".
Ezt mondhatnád egyébként a Docker, az K8s megoldások nagy része (kedvenceim a k3s és k0s ahol a binárisba begyógyított iptables parancsot használja nem az OS-ét) és a Libvirt fejlesztőinek is.
2023-at írunk és mindegyik iptables-t használ backendnek, vagy ha nem akkor a wrapper wrapper-ét firewalld-t.
Ahúgy a modern distrókban ahogy lentebb is írták az iptables csak egy wrapper szintén. A kernelbe nftables szabályok kerülnek.
A legjobb dolgok akkor történnek ha valaki (vagy valami software) felvesz egy iptables-nft-vel (vagy simán nft-vel) és egy iptables-legacy-val is egy szabályt. Ilyenkor aztán betöltődik minden is a kernelbe. És lehet kibogozni , hogy WTF.
Ha REJECT targetet használnál, akkor visszamenne egy ICMP csomag az IJB üzenettel. Hogy szimplán DROP van, a csomag eldobásra kerül - tehát a forgalmat indító program nem értesül arról, hogy a csomagja rossz útra tért. Ergo, nem is lép ki, hanem fut tovább és várja a választ. (Ha UDP forgalmat generál és csak elköhinti magát, az más eset - de nem írtad, hogy UDP lenne.)
Pont ezt akartam mondani, hogy pont hogy nem lép ki a fontos progi, mert a DROP miatt meg kell várnia egy timeout lejártát, szóval pont hogy el lehet még csípni. A fent általad is ismertnek minősített superuser-es oldalon ott van az az ss parancs, amin alig kell módosítanod - azaz amikor beesik a megfelelő log, akkor villámgyorsan kell futtatni ezt:
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Köszi, ebben a drop timeoutban és így nyitott socket-ben van ráció, erre nem gondoltam. Akkor ezt az ss megoldást is megnézem.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
Kérdés, hogy milyen portra próbál menni, abból a tartalom talán sejthető - én tennék rá egy jól irányzott DNAT-ot, és ahova beküldtem, ott tcpdump, vagy akár nc-vel fogadni és lerakni a bejövő stream-et, illetve figyelni azt, hogy esik-e be oda csomag, és akkor megnézni, hogy melyik folyamat kapcsolódik adott portra.
Jellemzően a 443-as port, például mostanság a 104.16.218.84+104.16.219.84 cím sokszor előkerül, rámentem, cloudflare mindkettő, tehát az IP magában karcsú, a request header host mezője lenne talán érdekes. Régebben találtam egy mitmproxy programot, megnézem mit tudok vele tenni. De ennyire meg nem akartam elbonyolítani. :-(
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
Nem fogsz tudni ilyet csinálni.
Btw biztos, hogy iptables? RHEL 8 esetén nftables a default.
Biztos, mert saját kezemmel cseréltem le, nekem szimpatikusabb az iptables, de valóban, gyárilag nftables van.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
Kapd el pwru-val.
Tudod a destination IP-t, meg az iptables logból egyéb információkat, akkor úgy paraméterezed a pwru-t, hogy ki tudd szűrni.
Nálam:
>> iptables -I OUTPUT -p tcp --dport 2222 -j DROP
>> pwru --filter-dst-ip=127.0.0.1 --filter-dst-port=2222
sima ssh login:
2023/06/07 19:43:32 Attached (ignored 0)
2023/06/07 19:43:32 Listening for events..
SKB CPU PROCESS FUNC
0xffff89a6f519c8e8 0 [ssh] ip_local_out
0xffff89a6f519c8e8 0 [ssh] __ip_local_out
0xffff89a6f519c8e8 0 [ssh] nf_hook_slow
0xffff89a6f519c8e8 0 [ssh] kfree_skb_reason(SKB_DROP_REASON_NETFILTER_DROP)
kde-n fájlbrowserből ugyanaz:
0xffff89a6f33c22e8 2 [kioslave5] ip_local_deliver
0xffff89a6f33c22e8 2 [kioslave5] nf_hook_slow
0xffff89a6f33c22e8 2 [kioslave5] kfree_skb_reason(SKB_DROP_REASON_NETFILTER_DROP)
0xffff89a6f33c22e8 2 [kioslave5] skb_release_head_state
Van pár paramétere a pwru-nak, lehet, hogy tudod még jobban szűrni.
Megnéztem, ez érdekes cucc, köszi! ("
pwrurequires >= 5.3 kernel to run", nekem 4.18 van :-()"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
Ezek namespace-ben futó alkalmazások (Docker) vagy simán a hoston/VM-ben?
LD_PRELOAD-al vagy root/alkalmazások cgroupra aggatott BPF programmal minden socket (vagy TCP-nél connect) hívást meghookolnék és hívnék egy SO_CONNMARK setsockoptot. Ez a mark lenne egy random 32 bites érték, de lehet akár a process ID is, ez a legegyszerűbb.
Drop (előtt?) jump iptables log target, ahol remélhetőleg a mark értéke kilogolható. Ezt akár egy (egyébként ősrégi, sürgősen frissítendő) 4.18-as kernelen is meg lehet oldani.
Alap desktop workstation, sima alkalmazások, plusz crontab cuccok. Van docker és VM is rajta, de nem futnak folyamatosan. A leírtakat még emésztem :-), köszi. A Rocky 8 meg 4.18-as kernelen van, ez adott, nem szeretnék custom kernelt alágörbíteni.
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"