Dotaz: jaký proces?

[ik]

Příloha:

• cosi (1818 bytů)

Zdravím.

Po každém rebootu PC (Fedora) se mi nějaký neznamý proces pokouší otevřít desítky spojení (port 80) ven, na neexistující adresu někde v Asii. Ani ss, ani netstat mi nenapíšou, který program to dělá, ve výpisu visí spojení ve stavu SYN-RECV, místo jména programu je jen pomlčka. Přikládám kousek logu z iptables (mé doménové jméno a ip adresa je pozměněno).

Rád bych zjistil, jaký proces se snaží z mého kompu volat domů.

Odpovědi

[debian+]

Viez zisti PID procesu? Ak hej, pozri sa na /proc/{PID}. Pastni ho sem. ... Pozeral si vystup lsof?

[ik]

PID je právě to, co potřebuji zjistit. Jenže u spojení ve stavu SYN-RECV není PID uvedeno (???)

[debian+]

Pouzi wireshark.

[ik]

Potřebuji to monitorovat hned bo bootu, wireshark je kanon na vrabce. Nainstalován mám tcpdump, ten by snad měl SYN packety zaznamenat taky.

[Josef Kufner]

Ne, PID v paketech nikde není. Jsou tam jen IP adresy a čísla portů. Podle čísel portů to pak putuje ze síťovky do toho správného socketu (procesu).

[NN]

SYN ACK, port 80 je zdrojovy.. nejsou to nahodou odpovedi? Na portu 80 nemas nejakou sluzbu, web?

[ik]

Odpovědi na neexistující IP? Jde to ven z mého kompu (na iptables loguji aktivitu na OUTPUT chainu. Na INPUT chainu není na portu 80 nic). Cílová adresa někde na Tchajwanu není dostupná ani pingem - proto jsem na to přišel, že spojení chvíli visí v SYN. Krátce po bootu tahle aktivita zanikne a pak už se nedá zjistit nic. Pokud na portu 80 spustím regulérní httpd.service, tak mi ss samozřejmě napíše, že se jedná o apache.

Přece se to musí dát zjistit nějak systémověji, než instalací snifferu.

[NN]

Poustis ten netstat pod rootem(-p)? Co podle inode?

netstat --program --numeric-hosts --numeric-ports --extend
find -inum 123456

[ik]

ano, dal jsem tam i dvakrát e, ale inode jsem tam neviděl.

[NN]

Jeste na to muzes jit jinak, jak se to po startu spusti/aktivuje..

[ik]

No to mne napadlo taky, ale to bych musel dělat o víkendu.

[NN]

Nejaka binarka v /tmp? Cron, rc.local? Fake sluzba?

[debian+]

Zmenit jadro/kernel (pokial kernel napadnuty) alebo neni nejaky atipicky modul nacitany?

[ik]

$ rpmverify kernel-core-4.18.9-100.fc27.x86_64

.M....... g /boot/System.map-4.18.9-100.fc27.x86_64

.M....... g /boot/initramfs-4.18.9-100.fc27.x86_64.img

Vzhledem k tomu, že bootuji mašinu jen a POUZE po upgrade kernelu, tak by to mělo jet vždy na novém a čistém kernelu, tedy pokud přátelé mistra L něco nenacpali rovnou do distribučního kernelu, což mi přijde poněkud amatérské. Používám moduly z distribuce, nic vlastního nebo nvidia blob atd. Jak mám poznat, že mezi těmi šedesáti moduly je nějaký atypický? Od pohledu mi přijde atypická nejmíň polovina, samé podivné zkratky,

[debian+]

Jak mám poznat, že mezi těmi šedesáti moduly je nějaký atypický? Od pohledu mi přijde atypická nejmíň polovina, samé podivné zkratky,

Preto je spravca serveru praca a nie len konicek ;) ...

Skratime cas ... nainstaluj si cisti instalacii a budes mat skoro 100% istotu.

[ik]

Díky za komentář. Profesionálního správce UNIX a Linux serverů jsem dělal patnáct let. Ale pravda, to byla éra před LP dalšíma fanatikama z RedHatu.

[cronin]

Hej, aj dinosaury žili na planéte celkom spokojne a celkom dlho; aj francúzska akadémia vied tvrdila, že "z oblohy žiadne kamene nepadajú, pretože tam žiadne nie sú".

[SpaceExplo]

Pingem ne, ale kdyz si das http://103.74.194.188 tak ti to napise, ze pristup neni povolen. Takze existuje a neco na ni zije.

[SpaceExplo]

Jinak - mam tu vanila Fedoru 27, posledni update a nic takovyho v netstatu po bootu nemam

[Michal Kubeček]

Jak jste přišel na to, že je "neexistující"? Podle whois patří "baud linker network co., limited" z Hong Kongu. Takže nejspíš nějaký script kiddie.

Pomlčka místo čísla/jména procesu znamená, že (a) ten socket je jádra nebo (b) proces už ho zavřel. Nechce se mi dohledávat, kdy přesně se nový socket přiřadí procesu, ale je dost pravděpodobné, že v tomhle okamžiku (ještě nebyl dokončen three-way handshaking) to ještě není - vlastně to dost možná ještě pořád je request socket.

Takže jediná zajímavá otázka je, proč nevidíte ty SYN packety, na které je to odpověď, ale to je nejspíš tím, že jste si logovací pravidlo přidal jen do chainu OUTPUT.

[ik]

Na whois jsem to našel taky, ale fakt, že má někdo zaregistrovaný nějaký rozsah ip přece neznamená, že konkrétní adrese nějaka služba skutečně žije.

Popsaný jev jsem zachytil asi čtyřikrát a pokaždé byla ta adresa jiná, ale vždy v danou chvíli jen jedna.

SYN pakety jsem neviděl, pravda, ani jsem je nelogoval.

Pokud mi do PC něco zvenčí tluče a platí váš bod b) nebo a) (což asi platí) a odpovídá můj apache, pak mi není jasné, proč se to ukazuje jen po rebootu (nebo restartu apache), jen z jedné adresy a po několika sekundách to skončí. To by někdo venku musel dostat informaci, že jsem rebootoval počítač.

[Michal Kubeček]

fakt, že má někdo zaregistrovaný nějaký rozsah ip přece neznamená, že konkrétní adrese nějaka služba skutečně žije

Vy jste napsal "neexistující IP", ne "adresa, na které neběží žádná služba".

SYN pakety jsem neviděl, pravda, ani jsem je nelogoval.

Pokud s jistotou nevíte, že žádné nebyly, princip Occamovy břitvy radí začít spíš hypotézou, že to je opravdu odpověď na SYN zvenku, než předpokládat, že váš systém posílá SYNACK pakety sám od sebe.

a odpovídá můj apache

Možná jsem to včera nenapsal dost jasně, takže to zkusím teď. V téhle fázi ještě není spojení navázané, takže Apache s tím nemá nic společného. Ten jen zavolal listen() a accept(), ale dokud nebude dokončen "3-way handshaking", je to zcela v režii jádra a accept() se nevrátí.

mi není jasné, proč se to ukazuje jen po rebootu (nebo restartu apache), jen z jedné adresy a po několika sekundách to skončí

Těžko říct. Otázka je, jestli se to nárazově nestává i jindy, jen jste si toho nevšiml. Nebo to může souviset s nastavením paketového filtru nebo něčeho jiného.

[ik]

Takže - zkoušel jsem startovat služby postupně ručně - a popsané chování se objevilo po startu httpd.service, což je apache. Zatímco normální spojení mají ve výpisu uvedeno jak PID, tak inode, tak tyhle podivné konexe (IP adresa, na kterou to volá je pokaždém restartu jiná) mají místo PID pomlčku a místo čísla inode nulu. Budu pátrat dále. Díky za váš čas.

[Michal Kubeček]

Nejdřív napíšete

Pokud na portu 80 spustím regulérní httpd.service, tak mi ss samozřejmě napíše, že se jedná o apache.

a potom zase

popsané chování se objevilo po startu httpd.service, což je apache

Tak poslouchá tam ten apache nebo ne? Co je to "regulérní" a "neregulérní" http.service? Jestli chcete poradit, tak napište pořádně, co děláte a jak to máte nastavené; na hru na schovávanou není nikdo zvědavý (ta adresa 147.111.111.111 je, předpokládám, také vymyšlená).

[ik]

Sorry za nepřesnost. Problému jsem si všimnul při standardním startu PC se systemd. Takže apache už běžel, když jsem se zalogoval. Normálně vidím v tu chvíli ve výpisu netstatu nebo ss poslouchající služby a navázaná spojení a spojení čekající na uzavření. S tím, že je u nich uvedeno, které službě patří. To jsem nazval slovem regulérní. Když jsem k tomu viděl padesát spojení ve stavu SYN-RECV u kterých nebyla uvedena služba, PID ani inode, tak jsem chtěl vědět, jak zjistím, která aplikace tohle způsobuje. Vzhtedem k tomu, že packety šly z mého PC ven z portu 80, nazval jsem to neregulérním http.

Vzhledem k tomu, že se popsaná věc objevuje jen po rebootu (a zřejmě někdy po restartu apache, ale ne vždy) tak stejně nevím na 100 %, zda to způsobuje nějaký modul apache. Povyhazoval jsem z apache nějaké snad nepotřebné moduly, webalizer, proxy, optional modules atp. a zatím se to neprojevilo. Ale pořád nevím, co to vlastně dělá. 147.111.111.111 je místo ip adresy mého PC.

[lertimir]

No konečně nějaká informace. Stav SYN-RECV se dosáhne ve stavovém diagramu TCP ve chvíli, kdy na port přijde paket SYN a jádro odešle paket SYN/ACK a čeká na přijetí posledního ACK paketu z 3 cestného handshakingu, aby komunikační kanál otevřelo a předalo aplikaci. viz např zde nebo v originálním RFC k TCP. Je nutné si všimnout, že nejdříve musí aplikace posunout stav z CLOSED na LISTEN, jak lidově říkáme "otevřít port". Proto se nic neděje dokud spuštění apache, protože na případné pakety nikdo neodpoví. (ale tcpdump nebo wireshark by je viděl). Apach port otevře a poslouchá. Popsaná situace je typická pro DoS útok Syn flood, kdy útočník posílá SYN packety, nutí server otvírat spojení a rezervovat zdroje a nic dalšího nedělá. Před dokončením 3 cestného handshankingu spojení ještě neexistuje a proto je obsluhuje jádro a nepatří aplikaci.

Asi je Vaše IP ve světě populární.

[Gilhad]

Pak si projdi, co vsechno za moduly taha apache a jake sity mas nainstalovane (tedy zda se pri jejich spousteni nemuze spustit neco divneho)

(Mozna bych pro zacatek zazalohovat /etc/apache2/vhost.d (nebo kde to nastavujes) a zkusil to spustit s timto adresarem prazdnym, a postupne pridaval sity, dokud se pri startu apache to chovani neprojevi - pak odebral vse, az na posledni pridanou a pokud to porad pri startu apache bude delat, tak si prosel, jake moduly pouziva a co vlastne dela sama.)

[ik]

to jsem udělal, nechal jsem jen moduly, které jsou nezbytné a postupně přidal pár dalších, které potřebuji. Jenže ten podezřelý provoz se neobjevuje pokaždé po restaru apache. Projevuje se většinou po rebootu PC.