Fórum Root.cz
Hlavní témata => Server => Téma založeno: robert2024 31. 05. 2024, 11:13:12
-
Dobrý den,
rád bych Vás požádal o tipy, co s tím.
Situace je následující:
Server s Almalinux 8.10 remi a epel repo.
Ze serveru se v nepravidelných intervalech otevírá velké množství spojení vždy na jednu IP na port 25.
Zdrojový port spojení je různý.
V logu postfixu v daný okamžik není žádný záznam. Z toho usuzuji, že spojení otevírá něco jiného.
Jak zjistit co za tím je?
Předem děkuji
-
Třeba napadený Wordpress? Je tam webový server? ;)
-
Zacni to hlidat/logovat.. a pak zjistis:
https://unix.stackexchange.com/questions/366376/find-local-processes-starting-tcp-connections
-
prakticky si nemůžeš být jistý ničím, pokud útočník již má nějakou kontrolu nad spuštěnými procesy v OS, je vhodné udělat backup celého filesystemu a systém celý přeinstalovat. Podrobně ověřit všechny aplikaci a nové deploymentu patřičně omezit a ohlídat jejich oprávnění.
Analýza komporomitovaného serveru je jedna z nejtěžších disciplín, nikdy nevíš proti čemu a v jaké úrovni stojí. Je dobré se do toho sám nepouštět, buď si na to někoho najmout nebo to celé schodit a udělat revizi zabezpečení a monitoringu.
-
Jak již předřečníci zmínili, jde o těžkou disciplínu. Ještě se můžete podívat na ss:https://www.root.cz/clanky/uvod-do-prikazu-ss-zjistete-podrobnosti-o-sitovych-rozhranich/
Ideální by bylo zkusit server nějak omezit v přístupu do dalších sítí, aby se infekce případně nemohla šířit dál. Samozřejmě vyměnit hesla, klíče atp.
-
Pro port 25 by měl mít root. Takže bych to zapálil, zalil do betonu a zakopal.
-
Děkuji všem za tipy.
Server má omezený přístup do zbytku sítě.
Web server na něm běží, ale žádný WP nebo něco podobného.
Zkusil jsem použít auditctl, viz příspěvek
Zacni to hlidat/logovat.. a pak zjistis:
https://unix.stackexchange.com/questions/366376/find-local-processes-starting-tcp-connections
Ale moc moudrý z toho nejsem.
V době pokusu o spojení je ve výpisu pouze
... arch=x86_64 syscall=connect success=no exit=EINPROGRESS(Operation now in progress) a0=0xf8 a1=0x7fcca00bd0f8 a2=0x10 a3=0x7fccb0ff3ff7 items=0 ppid=755814 pid=755848 auid=unset uid=eset-efs-wapd gid=eset-efs-daemons euid=eset-efs-wapd suid=eset-efs-wapd fsuid=eset-efs-wapd egid=eset-efs-daemons sgid=eset-efs-daemons fsgid=eset-efs-daemons tty=(none) ses=unset comm=wapd exe=/opt/eset/efs/lib/wapd key=who-connects
Asi bude nejjistější postup:
"to celé schodit a udělat revizi zabezpečení a monitoringu"
-
Jestli jste auditem skutečně odchytil ten citovaný záznam, tak ten socket podle názvů procesu a uživatele otevírá antivir od ESETu. Víc vám neporadím, nikdy jsem s tím na Linuxu nedělal, ale nemá v sobě antivir třeba nějaké e-mailové notifikace (reporty) přes SMTP a v preferencích nastavený vzdálený server, přes který to pak zkouší relay?
-
Zajímavé by mohlo být tu komunikaci si na druhé straně přijmout a prohlédnout si obsah - a z toho zjistit konečný cíl komunikace (mailu) a odhadnout původce.
-
Pro port 25 by měl mít root. Takže bych to zapálil, zalil do betonu a zakopal.
Neměl. Řeč je o cílovém portu, takové spojení může otevřít kdokoli. To, co myslíte vy, je port pro naslouchání. (A ani tam už to nemusí být root, stačí mít příslušnou capability, kterou ovšem může přidělit jen root – každopádně pro tuhle diskusi je to irelevantní.)
Pokud nevíte, jak k útoku došlo, není moc jiná možnost, než ten server přeinstalovat. Chyba ale také může být v nějaké custom aplikaci nebo konfiguraci, takže je dobré po přeinstalaci to víc sledovat, zda se to neobjeví znovu.
Víte něco o té cílové adrese? On to také nemusí být útok, jenom špatná konfigurace něčeho.
-
Co odchytit takovou komunikaci pomocí tcpdumpu a pak si ji prohlédnout ve Wiresharku? ;)
-
Poslední pokus byl na IP:
5.143.241.243
-
Což je mail2.mil.ru - ruské ministerstvo obrany...
-
Což je mail2.mil.ru - ruské ministerstvo obrany...
S nimi určitě nechce mít od nás nikdo nic společného.
-
Poslední pokus byl na IP:
5.143.241.243
Patří Ruskému telekomu. Okamžitě reinstall.
-
Mam trochu jinaci nazor nez predrecnici - za me izolovat, analyzovat a zjistit kudy se do systemu utocnici dostali. Je zde nekolik (rozumej vice nez malo) moznosti a to od webu az po neaktualizovany balik. Samozdrejmosti je nahodit novy server se sluzbami napr. VM. Pokud nezjistite kama se utocnici dostali dovnitr muzete stejnou chybu zopakovat na novem serveru a tim padem budete zase v te same situaci. A to uz nezminuji otevrene ssh do celeho sveta s heslem 1234 atp.
-
Izolovany uz je, to jsem udelal hned, jak jsem se ujistil, ze se neco deje.
Rad bych zjistil, co se stalo a jak k tomu doslo.
A jelikoz jsem si nedokazal poradit, zeptal jsem se zde.
Stale bezi auditctl i tcpdump.
Vim, ze to bude znit divne, ale od te doby co bezi auditctl a tcpdump nedoslo ani k jednomu pokusu o navazni spojeni.
-
Je zde nekolik (rozumej vice nez malo) moznosti a to od webu az po neaktualizovany balik.
Ne všechny servery provozují web nebo jen web. Když nevíme, co tam běželo za služby a v jakém stavu byl ten server, nemá moc smysl hádat, kde všude mohla být chyba.
Vim, ze to bude znit divne, ale od te doby co bezi auditctl a tcpdump nedoslo ani k jednomu pokusu o navazni spojeni.
Mohl tam být někdo připojen interaktivně nebo si ten server mohl stahovat příkazy z nějakého C&C serveru, a když jste ho odpojil od sítě, nedostává instrukce. Sledujete jen odchozí komunikaci na port 25, nebo všechnu? Na výpis procesů, zda tam není něco vyloženě divného, jste se díval?
-
Je zde nekolik (rozumej vice nez malo) moznosti a to od webu az po neaktualizovany balik.
Ne všechny servery provozují web nebo jen web. Když nevíme, co tam běželo za služby a v jakém stavu byl ten server, nemá moc smysl hádat, kde všude mohla být chyba.
Server běží na Almalinux 8.10 s remi a epel repo. Server je pravidelně aktualizovaný.
Mimo repo naistalován Seafile
Vim, ze to bude znit divne, ale od te doby co bezi auditctl a tcpdump nedoslo ani k jednomu pokusu o navazni spojeni.
Mohl tam být někdo připojen interaktivně nebo si ten server mohl stahovat příkazy z nějakého C&C serveru, a když jste ho odpojil od sítě, nedostává instrukce. Sledujete jen odchozí komunikaci na port 25, nebo všechnu? Na výpis procesů, zda tam není něco vyloženě divného, jste se díval?
Sleduji všechnu odchozí komunikaci, ale pozornost jsem věnoval hlavně portu 25.
Výposi procesů také průběžně sleduji a na nic divného jsem nenarazil. Ani zatěž serveru se nijak nezměnila.
Do teď stále ani jeden nový pokus o spojení.
Samozřejmě, pokud se něco nového objeví, podělím se.
Zatím všem děkuji :)
-
Ti z ruska nebudou zadni amateri. To prvni co bych narpogramoval do toho malwaru je ze pokud mi bezi nejake zakladni detekcni nastroje typu tcpdump ihned bych ukoncil veskerou komunikaci. Proto neni divne ze ted se najedou nic neposila. Zkuste ten tcpdump udelat na routeru, nebo obecne nekde mimo ten server.
-
Ti z ruska nebudou zadni amateri. To prvni co bych narpogramoval do toho malwaru je ze pokud mi bezi nejake zakladni detekcni nastroje typu tcpdump ihned bych ukoncil veskerou komunikaci. Proto neni divne ze ted se najedou nic neposila. Zkuste ten tcpdump udelat na routeru, nebo obecne nekde mimo ten server.
Vzpomněl jsem si na knihu Kukaččí vejce, jak Cliff Stoll chytal hackera, že si tisknul telnetové seance v reálném čase na jehličkovou tiskárnu, aby hacker nepojal podezření, kdyby v systému viděl nějaký neobvyklý proces (pamatuju si to dobře, že jo?)... Skvělá kniha podle skutečných událostí https://www.databazeknih.cz/knihy/kukacci-vejce-23458
-
Ti z ruska nebudou zadni amateri. To prvni co bych narpogramoval do toho malwaru je ze pokud mi bezi nejake zakladni detekcni nastroje typu tcpdump ihned bych ukoncil veskerou komunikaci. Proto neni divne ze ted se najedou nic neposila. Zkuste ten tcpdump udelat na routeru, nebo obecne nekde mimo ten server.
Vzpomněl jsem si na knihu Kukaččí vejce, jak Cliff Stoll chytal hackera, že si tisknul telnetové seance v reálném čase na jehličkovou tiskárnu, aby hacker nepojal podezření, kdyby v systému viděl nějaký neobvyklý proces (pamatuju si to dobře, že jo?)... Skvělá kniha podle skutečných událostí https://www.databazeknih.cz/knihy/kukacci-vejce-23458
kukacci vejce je super
-
...
Ze serveru se v nepravidelných intervalech otevírá velké množství spojení vždy na jednu IP na port 25.
...
Poslední pokus byl na IP:
5.143.241.243
Což je mail2.mil.ru - ruské ministerstvo obrany...
Po přečtení topicu a zveřejnění informací, vidím slušný úpadek odbornosti a analytických dovednosti. Je zjevné(nebo vysoce pravděpodobné) že právě stroj u robert2024 je strojem který je útočník, a utočí na ruské servery zjevně jako bot DOS,DDOS. Přeci je port 25 smtp a slouží pro odesílání pošty takže zjevně někdo chce blokovat odesílání.
-
Mně je divné, že by jakkoliv komunikovali přímo s ruským státním serverem a ne přes méně nápadného prostředníka. Vysvětlení technomaniaka vypadá logicky.
-
Mala technicka - port 25 se pouziva na prijem posty.
Na odeslani pouzije server otevirajici spojeni nejaky nahodny port prece.
Pokud budete DDoS-ovat neci port 25, tak postu porad odesle.. ale bude mit spis problem ji prijmout.
-
Mala technicka - port 25 se pouziva na prijem posty.
Na odeslani pouzije server otevirajici spojeni nejaky nahodny port prece.
Pokud budete DDoS-ovat neci port 25, tak postu porad odesle.. ale bude mit spis problem ji prijmout.
Pokud pro odesílání a příjem pošty mám jeden poštovní server, tak když padne na hubu, nic nepřijmu ani neodešlu. ;)
-
Mala technicka - port 25 se pouziva na prijem posty.
Na odeslani pouzije server otevirajici spojeni nejaky nahodny port prece.
Pokud budete DDoS-ovat neci port 25, tak postu porad odesle.. ale bude mit spis problem ji prijmout.
Já tedy smtp používám pro odesílání. Nicméně, dobře víme že port 25 nemusí být smtp, přesněji správce serveru nemusí dodržovat standard či konvenci(zvyk) ale může na něm běžet jakákoliv služba kterou si pro něj nastavím. Faktem je že z mašiny o které se vede téma bylo autorem zveřejněna informace " že s ní odchází mnoho spojení" a všechny míří na 1 port na konkrétní 1 IP.
U DOS,DDOS to nefunguje tak že jedna mašina dělá jenom např. 1 pokus o spojení za sekundu což by při 100 strojích dělalo jenom 100 pokusů o spojení pro jednu cílovou mašinu. Pokud 1 útočník udělá více např. 100 pokusů/sec o spojení a farma má 100 botu pak cíl musí řešit 10 000/sec pokusů o spojení a to je samozřejmě mnohem efektivnější a účinnější.
PS. nicméně pořád nebyli zveřejněny kvalitní informace aby byla 100% jistota "vo co go"
-
Update:
Když jsem byl na server připojený přes ssh, tak nedošlo v tu dobu ani k jednomu pokusu o spojení.
To stejné platí, když přímo na serveru běžel tcpdump.
Určitě by bylo zajímavé pokusit se zjisitit, jak to bylo řízeno, ale neměl jsem na to čas.
Server je odstavený a bez přístupu k síti.
Technomaniak má nejspíš pravdu, byl to bot.