Dotaz: Port 54/tcp open xns-ch

[alanos]

Mohl by mi někdo říct co je to za port ? Popřípadě který program ho používá ?

Odpovědi

[alanos]

nmap -sV vypsal že by to měl být sshd .

54/tcp open  ssh     SCS sshd 2.0.13 (protocol 1.5)

akorát nevím proč je to jako xns-ch :o) . Nebo je to normální když mám na serveru povolenou jen službu ssh ?

[rastos]

nmap hovorí, že sa mu zdá, že tam počúva ssh.

Čo povie

netstat -ltp | grep 54

pustený ako root? Ak tam niečo počúva tak v poslednom stĺpci bude PID a meno procesu. Z toho by som sa pozrel do /proc/{pid}/exe - ci to náhodou nie je nejaká pliaga.

[rastos]

http://www.iana.org/assignments/port-numbers :

xns-ch           54/tcp    XNS Clearinghouse
xns-ch           54/udp    XNS Clearinghouse
#                          Susie Armstrong <Armstrong.wbst128@XEROX>

[alanos]

Ano to jsem si našel taky , ale jaksi nevím k čemu to slouží :o)-.

[rastos]

To v princípe nemusíš vedieť. Ktokoľvek môže IANA požiadať o pridelenie čísla portu (asi za poplatok). Znamená to len toľko, že ak začínaš vyvíjať nejaký sieťový protokol, tak by si to dané číslo nemal použiť, pretože sa môže stať, že nejaký užívateľ poštve tvojho klienta na server toho, kto si to číslo zaregistroval ( alebo naopak) a taký server a klient sa potom nedohodnú.

[NN]

Je to dost podezrely port btw..

NN

[alanos]

sudo netstat -ltp | grep 54
tcp        0      0 *:54   *:*     LISTEN      2436/ttyload

[alanos]

je to k něčemu nebo ten program mohu odinstalovat ? / tudíž by měl zmizet i ten otevřený port usuzuji.

[rastos]

Imho, je to nejaká neplecha.

http://www.linux.com/archive/feature/113974

.... I checked my site for obvious backdoors by typing netstat -lntpe. Aloha! There was a strange daemon named ttyload listening on port 4444. This process did not show up when I used the hacked ps command. ...

Vyššie som písal ako sa pozrieť, kde ten súbor je.

[alanos]

No měl jsem takového lepana že jsem , vše kill nul a rebootnul server, a hlavně pustil firewal , neb jak jsem se dival do logu utoku na ssh bylo za posledni dva dny hromada. Momentalně už je otevřen jen port 22 a ten jsem pro jistotu ještě zabespečil proti nabourávání. Že já vůl to vše nepustil hned po naistalování. Mimochodem utoky vedené z ruska a číny..

[rastos]

Re-installation should be considered mandatory upon an intruder obtaining root access.

[alanos]

A jelikož jsem se dival že jeden utok byl uspěšný , chci se zeptat jestli jde nějak zjistit jestli si tam nenechal nějaké vratka. Podařilo se mu vytvořit uživatele /jinak hacknul heslo roota - bylo opravdu velmi slabé/ vše jsem změnil a toho uživatele vymazal , bohužel i on po sobě zametal a tak mi smazal v /var/log co se dalo ../takže co dělal se už asi nedozvim/ . Je to pro mne poučení :o)) naštěstí to byl jen skušební server který skoro nic nedělal . Co jsem vysledoval je že měl puštěný SCREEN a sftp .

V crontab nic pro roota ani jineho uživatele není , ve vypisu ps taky nic podezřeleho , žádný sleep není puštěn. Dle logu z /var/log/auth.log jde vidět že to patrně dělal nějaký robot .

Jeho IP 188.27.209.105 -- patrně z Rumunska

[Jendа]

chci se zeptat jestli jde nějak zjistit jestli si tam nenechal nějaké vratka

V podstatě nelze. Možná by šlo rozbalit si na jiném stroji všechny balíčky, které jsou na napadeném serveru nainstalované, a zkontrolovat sha1 součty. Ale to je spíš kdyby sis chtěl hrát.

Smazat, přeinstalovat, nastavit silné heslo, přihlašovat se SSH klíčem.

[alanos]

No prozatim se nic neděje , sleduji tedy od rana , na serveru je otevřen jen 22/port pro ssh a zakazal jsem přihlašni roota . dal jsem ale

sudo netstat -lntpe
tcp 0   0 0.0.0.0:54    0.0.0.0:*  LISTEN   0  5907  2484/ttyload

ps aux |grep ttyload
root  2484  0.0  0.1   2284   528 ?        Ss   12:35   0:00 /sbin/ttyload -q

namp moje_verejna_ip
Not shown: 1685 closed ports, 29 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh

a teď nevím jestli je to vpořádku nebo ne.

[Jendа]

Problém je v tom, že útočník mohl třeba opatchovat PAM, aby mu bral nějaké univerzální heslo. Nebo si mohl pohrát s konfigurací nějaké služby, která tam běží, a vytvořit tak nebezpečnou konfiguraci. Nebo mohl někam nakopírovat binárku bashe a nastavit jí SUID bit. Nebo si každou noc spouští wget, který stahuje z jeho serveru instrukce a spouští je. Nebo se při příštím rebootu spustí DDoS útok na server Ministerstva vnitra. Nebo… nebo… Prostě jednou rootem, navždy rootem, jak říká jedna populární reklama na prací prášek.

zakazal jsem přihlašni roota

No tím jsi tomu fakt pomohl… (ironie)

Zakazováním přihlášení roota se nepomůže ani zdravému systému, natož pak nakaženému.

[alanos]

Tak postupoval jsem podle těch navodu co jsou na webu , a jelikož se mi to nidky nestalo tak jsem v sshd_config tomu rootovi zakazal, heslo na roota jsem změnil na podstatně silnější , já klidně ten server přeinstaluji , to není problém , jen mě spíše zajímá jestli jde vysledovat nějaké nekalé praktiky. Když to smažu tak se už nic nedozvím :o) na serveru nic není žádna data /defakto jen routuje síť/. Pokud by chtěl co spouštět tak by to bylo v crontabu /tedy alepoň myslím/ . Hledal jsem ten ttyload a zjistil jsem že Deban Lenny /tedy stable verze/ takový balík nemá, tudíž celkem netuším jak se tam dostal ...

[Jendа]

Tak postupoval jsem podle těch navodu co jsou na webu

Tak v tom případě byl návod vadný. Je to velice rozšířený omyl. Kde kdo doporučuje zakázat přihlašování roota na SSH a v okamžiku, kdy se ho zeptáš, jak přesně by to mělo zvyšovat bezpečnost, není schopen odpovědět…

já klidně ten server přeinstaluji , to není problém , jen mě spíše zajímá jestli jde vysledovat nějaké nekalé praktiky. Když to smažu tak se už nic nedozvím :o)

Já bych porovnal integritu souborů s distribučními a v případě nalezení backdooru bych si s tím pohrál ve VirtualBoxu a pak o tom napsal do blogu .

Pokud by chtěl co spouštět tak by to bylo v crontabu /tedy alepoň myslím/ .

Binárka cronu může být podvržená a mít nějaký cronjob klidně natvrdo v sobě.

Hledal jsem ten ttyload a zjistil jsem že Deban Lenny /tedy stable verze/ takový balík nemá, tudíž celkem netuším jak se tam dostal ...

No to je jednoduché - nainstaloval ti ho tam útočník .

[alanos]

Cele to tedy zabalim ,a až bude čas tak si o tom něco přečtu a porovnám to. Zatim jsem jenom zjisitl dva baliky ttyload a ttymon , když jsem je chtěl smazat v /sbin/ tak mi to nedovolil :o) /ani jako rootovi/.

sudo rm -f /sbin/ttymon
rm: nelze odstranit „/sbin/ttymon“: Operace není povolena

Ale dobře mi tak .o)) ať je to i ponaučením pro všechny co si dávájí slabé hesla.

[Jendа]

Chtělo by to porovnávat se současnými verzemi balíčků. Po větší aktualizaci se totiž kontrolní součty budou lišit u spousty souborů.

[NN]

Jedna se o SHV4(SHV5) toolkit napasovany na nejaky novejsi exploit.. SHV4 Rootkit Analysis

NN

[NN]

prejmenovat na xxxx.PDF....

NN

[Sten]

Kde kdo doporučuje zakázat přihlašování roota na SSH a v okamžiku, kdy se ho zeptáš, jak přesně by to mělo zvyšovat bezpečnost, není schopen odpovědět…

Zajímalo by mě, koho jste se ptal. Protože já vám klidně řeknu, že zákaz přihlašování roota na SSH heslem zvyšuje bezpečnost tak, že útočník na začátku nezná ani jméno uživatele, které by mohl pro svůj útok použít.

[Bilbo]

Když se k tomu navíc přidá např. denyhosts, tak tam jde pak např. nadstavit že po 5 neúspěšných pokusech o přihlášení během jedné hodiny má dotyčný na den utrum. Jednak se tím zvýší bezpečnost, protože hesla nejdou zkoušet donekonečna (teda, u mně nejsou vůbec, protože sshd heslo nebere a chce jen klíč), jednak v logu není takový bordel (někteří jedinci tam byli schopni nasekat během chvíle tisíce pokusů o přihlášení) - po pátém pokusu je dotyčný od ssh odstřižen.

[Jendа]

Pokud bys to jméno přidal přímo k heslu na roota, zvýšíš si odolnost proti bruteforce stejně. S tím, že ji můžeš zvýšit ještě víc, protože v uživatelském jménu se na rozdíl od hesla nesmí vyskytovat divoké znaky. Když máš heslo qwerty123, řeš problém změnou hesla a ne přejmenováním roota.

[Jendа]

No dobře, souhlasím, že mé tvrzení, že to nemůže nijak zvýšit bezpečnost, bylo poněkud silné. Ale za tím, že je přejmenování roota hloupé, a že je tady spousta mnohem lepších možností, jak tu bezpečnost zvýšit, si stojím.

[alanos]

Tak mi to nedalo a projel jsem to chkrootkit .,

Searching for t0rn's v8 defaults... Possible t0rn v8 \(or variation\) rootkit installed
Searching for Showtee... Warning: Possible Showtee Rootkit installed

[pht]

Typické chování...

1. Připouštíte že Váš stroj byl nabourán a žádáte o radu
2. Připouštíte že jste udělal blbost s nastavením hesla
3. Odmítáte radu číslo 1 (přeinstalovat) a pokračujete v dělání blbosti

[cynic_asshole]

Proč? Napsal, že přeinstalace mu nedělá problém a že na tom serveru nic cenného nemá. Takhle se aspoň může něco nového naučit. Já bych jej hnedka neodsuzoval.

[pht]

Aha, tak to jsem nějak přehlédl, četl jsem jen prvních pár příspěvků kde vzdoroval

[alanos]

Ano tak to přesně je , snažím se teď jen zjisiti co to všechno dělá , alespoň se člověk s tím lépe seznámí , mě se to nikdy nestalo a proto to hodlám prozkoumat z blízka :o. Například jsem skusil nabootovat Live CD a pokusil jsem se odstranit soubory v /usr/lib/libsh kde jsem našel jeden soubor který tam podstrčil. Ale neše smazat , rm -f prostě nefunguje .o)). Rada je jasná ANO MUSÍ se to přinstalovat, jak jsem se všude dočetl. Ale do te doby než mě to přestane bavit budu hledat kde nechal tesař díru .. . Z venku již žádné útoky nejsou , otevřený je jen port 22 . Zjistil jsem taky že programy ttymon a ttyload se spusti při každém spuštění počítače . Jdu hledat co je spouští , neb ani ty nejdou smazat. Jen se chci zeptat jestli existuje nějaký příkaz který /kromě rm, a formátu oddílu :o)/ soubor smaže.

#tohle je ten soubor od t0rn v8
/usr/lib/libsh/.bashrc

ten první rootkit jsem smazal /šel smazat ../ Smazání /sbin/ttyload a ttymon zatím bz uspechu.

[NN]

Google: SHV4 Rootkit Analysis

Stahni si dokument a prepis ho na PDF a doctes se spoustu zajimaveho cteni :D..

NN

[alanos]

Jj to už jsem četl odkaz je někde výše, mno asi to v pondělí přeinstaluji , prohledal jsem co jsem mohl , nic jineho nenašel ,chrotkit nehlasi ani žádné infikované soubory kromě toho co jsem před chvili vypsal , ale tam se mi podařilo alespoň vymazat obsah toho souboru , tudíž je prázdný .

Pokud by to někoho zajimalo a chěl by nějaký výpis dejte vědět. Budu ještě celou neděli pozorovat co se děje :o))

[pht]

snažím se teď jen zjisiti co to všechno dělá

Na 99% je to jen normální využití slabiny v hesle bez konkrétního zaměření na Vás. Útočník bude Váš stroj používat nadále pro instalaci botnetu (spam, DoS, ...) a crackování dalších strojů.

Jen se chci zeptat jestli existuje nějaký příkaz který /kromě rm

Pravděpodobně je soubor nastavený jako immutable, zkuste chattr -i

Z venku již žádné útoky nejsou , otevřený je jen port 22

Zapřemýšlejte o změně portu nebo omezení přístupu přes firewall.

[alanos]

Tak chattr -i nepomohl soubor je tam pořád . Firewal jsem zapnul , ssh jsem tam ješte ošetřil pomocí recent_ssh .

Pokud by chtěl utočník znovu se přihlásit na můj stroj,co bych měl sledovat abych to poznal. Tail mi běží na skoro všech logách . Ale zatím vidím jen svoji činnost, kromě jednoho dnešního pokusu z číny o přihlášení na ssh2

[cynic_asshole]

On pht myslel chattr -i na odstranění toho immutable příznaku a pak ho smazat přes rm -f.

[alanos]

jo to jsem pochopil ale jedine co to udělalo že odstranilo práva ale rm -f nezabral.

 sudo lsattr  /usr/lib/libsh/.bashrc
------------------- /usr/lib/libsh/.bashrc

sudo rm -f  /usr/lib/libsh/.bashrc
rm: nelze odstranit „/usr/lib/libsh/.bashrc“: Přístup odmítnut

[pht]

Zkoušíte tohle na tom systému nabootovaném nebo z jiného systému (live cd)?

[alanos]

Na nabotovanem systemu , pracuji na něm teď na dálku .

[pht]

Tak to máte něco napíchlého, aby to nešlo smazat.

[cynic_asshole]

Hmm… co si a jiným počítači zkompilovat rm se staticky slinkovanými knihovnami? Není možné, že máš pozměněné i rm?

[alanos]

No teď nemohu bohužel sedím na widlích /XP/ ale skusil jsem stahnout z debian.org coreutil baliček a pomoci dpkg ho naistaloval ale vysledek e pořád stejny :o).

[cynic_asshole]

Aha, chápu. No, nejlepší je fakt nabootovat z nějakého Live distra. Tam máš aspoň jakous takous jistotu, že s obrazem nikdo nic nedělal. Pracovat na tom kompromitovaném stroji už nemá cenu.