Megtörték egy régebbi szervert, hogyan?

Linux-security

Üdv,

Egyik ismerősöm szerverét megtörték.

Nem igazán nagy szerver guru, egy egyszerű kis vm amin a saját kis dolgait tárolja, így a biztonsághoz sem ért igazán valószínüleg ez lett a veszte.

Ami történt:

/opt/ng99 mappába rootként feltölttek egy nginx vagy annak álcázott programot és a 8080-as porton csinált valamit, ami miatt a szolgáltatója leállította a vm-et.

A folyamatokat kilőttem, lepucoltam a programot. Root login ssh-n letiltva ssh port megváltoztatva, más káros dolgot nem találtam.

Az auth.log-ban ez van, semmi próbálkozás csak simán beléptek: Accepted password for root from 149.202.153.251

Kérdésem mivel én sem vagyok nagy biztonsági guru:
- Hogyan juthattak hozzá a jelszóhoz?
- Mit lehet tenni az ellen, hogy ne forduljon hasonló elő újra?
- Érdemes-e újratelepíteni mindent a biztonság kedvéért?

Üdv,
Gab

  • 7311 megtekintés

( slinky v | 2018. 01. 03., sze – 11:44 )

pl jokis joomla, local root explit majd jelszo csere..... es maris tudja a jelszot....

Valóban, a cms-eket több ember is átnézi. ;)
Az ssh-nak és a chroot-nak is előfordul sebezhetősége csakúgy, mint minden másnak, amit említettél és használunk.
(egész vicces volt régen, amikor chroot-ba chroot-olva valódi root lehettél)
De ha ilyen amatőr volt a támadód, hogy a naplót se takarította maga után, nagy "haxot" és komoly rootkit-eket ne remélj szerintem.
A többit már nagyjából leírták.

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

(egész vicces volt régen, amikor chroot-ba chroot-olva valódi root lehettél)

nem. Ha a chroot-on belul root vagy, akkor kitorhettel belole. Eppen ezert nem szabad root-kent futtatni semmit a chroot utan.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Egy dologban lehetsz biztos, az pedig az, hogy mivel élsz, meg fogsz halni. Semmi más nem biztos. Egy 80-as porton http-t beszélő valamit, még ha saját kód is fut rajta, lehet általános okosságokkal tömni, hátha valamelyiket benyeli, és megmond magáról olyasmit, amiből már az ajtó-ablak helyzet csak pár lépés.

Második bekezdés:

"In most cases if you have a system compromise at root level, you will hear that you have to fully reinstall the system and start fresh because it will be very hard to remove all the hidden files the attacker has placed on the system. This is completely true and if you can afford to do this then you should do it. Still even in this case the compromised system contains valuable information that can be used to understand the attack and prevent it in the future."

--
Mobilbarát és reszponzív weboldal készítés

Igen ezt is irja, majd a cikk folytatasa homlokegyenest mas iranyt vesz:

* Don’t panic. Keep your calm and develop a plan of actions
* Disconnect the system from the network
* Discover the method used to compromise the system
* Stop all the attacker scripts and remove his files
* Restore not affected services
* Fix the problem that caused the compromise
* Restore the affected services
* Monitor the system

Es itt nagyon nincs szo ujratelepitesrol.
Ettol meg vannak benne jo gondolatok.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Kérlek, értelmezd is, amit olvasol:

"This is completely true and if you can afford to do this then you should do it".

De ahogy folytatja, ettől még lehetnek értékes infók a rendszeren, ezekhez ad támpontokat. Ráadásul ha sikerülne továbbgörgetned a harmadik-negyedik bekezdéseknél, és neadjisten eljutnál a hozzászólásokig, aztán pedig rákeresnél a horgonyszövegre, amivel linkeltem az oldalt, megtalálnád spif hozzászólását:

"Definitely try to catch them in the act if you can afford the luxury of having a hacked system. Try to keep them from getting into anything else without tipping them off. Gather as much information as you can so you at least know what went wrong, if not who did it. Maybe quietly plant some fake warez/pr0n with trojans/virii or some fake business data they can waste their time with and/or try to sell and get caught that way.

After that, rebuilding is definitely the only way to go. Take off and nuke 'em from orbit: it's the only way to be sure."

--
Mobilbarát és reszponzív weboldal készítés

Remelem nem megyunk at teljesen a dedo szintre. De a cikk meg mindig 2 utat targyal:
a) telepits egy uj gepet
b) javitsd meg a feltort gepet (es ezt fejti ki a cikk).

A linket koszi, mindig jo masok velemenyet is elolvasni.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( _Franko_ v | 2018. 01. 03., sze – 12:52 )

"Mit lehet tenni az ellen, hogy ne forduljon hasonló elő újra?"

Frissítés-frissítés-frissítés. Minden nap.

"Érdemes-e újratelepíteni mindent a biztonság kedvéért?"

Igen.

Számít, nagyon sokat. A jelszóhoz elég sok próbálkozás kell, általában annyi, hogy nem is tudnak értelmes idő alatt bejutni (nekem például van néhány szerverem jelszavas root account-al, évek óta nem törték meg, pedig próbálkoznak lelkesen), egy remote exploit pedig egy próbálkozás után nyitott kapu. Szerinted melyik a fontosabb?

Használom a porteltolást, de azért érdekelne, hogy melyik a jobb, ha egy "jól ismert" portra teszem, azaz pl. nem használom a 691 MS Exchange Routing-ot és oda a 22 helyett, vagy egy !jól ismertre 1024 alatt (pl. 27-re) vagy 49152 felett de ott is inkább jól ismertre vagy inkább ne arra??

"Ha valaki arra nem képes, hogy legalább egy rohadt kulcspárt beizzítson, akkor véleményem szerint teljesen felesleges bármilyen biztonságról beszélni."

Mert? Megmondanád, hogy _becslésed_ szerint mekkora a _tényleges_ kockázata annak, hogy a próbálgatással jussanak be? :)

Szerintem elenyésző... ha jól számolom, akkor körülbelül 10^18 próbálkozás szükséges, napi ~5000 próbálkozás van és ezeknek szinte 100 százaléka nem brutal force, hanem végigpróbálnak néhány arcpirítóan gyenge jelszót, próba szerencse alapon, hátha van olyan balfasz, aki gyenge jelszót használ. Ha neki is állnának a brutal force törésnek, akkor se attól félnék, hogy megtörik, hanem attól, hogy túlterhelik a gépet...

Értem én, de ezek leginkább csak security by obscurity faszságok, a "brutal force jelszótörés SSH-n át" reális kockázata valahol a halálos meteorzápor és a zombi-apokalipszis között van, főleg, hogy általában értéktelen szerverekről beszélünk (tudom-tudom, my precious, de akkor is értéktelen).

Egyrészt a szolgáltatók korlátozásai miatt eléggé kevés helyről lehet spam-et küldeni, másrészt erre maximum akkora erőforrást tesznek, hogy végigpróbálnak néhány gyakori felhasználó-jelszó kombinációt és mennek tovább, ha nincs siker.

Ha végig akarnak próbálni 10^20 feletti kombinációt, akkor inkább kriptovalutát bányásznak, annál azért kicsit garantáltabb a siker, mint bajlódni egy lófasz utolsó VPS-el, amin semmi értékes nincs és amit a törés után néhány nappal leradíroznak a térképről...

Valószínüleg nem klasszikus bruteforce vagy csak részben az, hanem valamilyen listában szereplő gyakori jelszavak és azok kombinációi, amikkel támadnak. Megtörni az erőforrások miatt mindenképp érdemes lehet a gépet, bitcoint azon is tudnak bányászni, meg további törögetéshez használni, kezdetnek. Ahogy a kényszerűségből 22-es vagy akár a 2222-es porton hagyott ssh logokba bele-bele nézek inkább ezres nagyságrendű, mint néhány darabos a próbálkozások száma.

Igazság szerint kár ragozni ezt, épp elég sok elhagyatott vagy úgyhagyott bármilyen Linux fut szerteszét a világban. Látszott ez az amplification támadásos időszakban, meg látszik azóta is az aktuális sztorikon. Ott vannak publikus IP-n management eszközök (azokon is ugye Linux), minimális vagy semmilyen védelemmel, sokszor még az elérhető frissítések sem kerülnek fel. Ugyanilyen issue a milliónyi avult sw-vel futó router is és sokszor hiába akarod frissíteni, alig 6-12 hónapig van követés a gyári fw-hez...

"Valószínüleg nem klasszikus bruteforce vagy csak részben az, hanem valamilyen listában szereplő gyakori jelszavak és azok kombinációi, amikkel támadnak."

Így van. Ha valami közepesen erős jelszót használsz, már meg se próbálják, nem pazarolnak rá erőforrást, amikor van sokkal több törhető gép.

"Megtörni az erőforrások miatt mindenképp érdemes lehet a gépet, bitcoint azon is tudnak bányászni, meg további törögetéshez használni, kezdetnek."

BitCoin-t? VPS-en? Áh... nem pöcsölnek ilyen kis teljesítményekkel... viszont minden másra szokták használni... de én még nem láttam, hogy ténylegesen brutal force próbálkozzanak egy molyfing gépen, nálam az utóbbi egy évben a legkitartóbb próbálkozás is kifulladt 6000 körül, az meg nagyjából egy két karakteres jelszó permutációja.

Itt van egy jó live statisztika SSH honeypot alapján: http://longtail.it.marist.edu/honey/

"Igazság szerint kár ragozni ezt, épp elég sok elhagyatott vagy úgyhagyott bármilyen Linux fut szerteszét a világban."

Leginkább ez a probléma, nyilván szintén nem a molyfing gépet fogják azonnal fifikásan támadni a kiderült sebezhetőséggel, tehát éjjel azért nem kell felkelni, hogy megstoppolja az ember a lyukat, de azért több hónapos vagy több éves hibákat érdemes lenne egy szimpla frissítéssel javítani... akkor nem lenne tele az én HTTP logom se azzal, hogy évekkel ezelőtti phpMyAdmin verziókat próbálgatnak végig akkurátusan, hátha valamelyik ott figyel frissítés nélkül...

Nem erre volt kihegyezve a post, hanem arra, hogy sokan úgy gondolják, hogy az ő kis házi szerverük biztosan nem lesz célpont, mert "értéktelen", amit hostolnak. Vagyis szerintem az a kép él a fejekben (legalábbis valahol tudat alatt), hogy valaki ül a Google előtt, nézegeti az "internetet", és amelyik oldal szerinte értékes, azt megpróbálja megtörni. De itt inkább scriptekről van szó, amelyek egy adott IP tartományban végigpróbálnak pár sebezhetőséget, és ahol sikerül, oda beül a kártékony kód, és ennyi. A mi kis barátunk pedig csak a Bitcoin-egyenlegét vagy a hitelkártyaszám-adatbázisát nézegeti a gépén.

--
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Te írtad, hogy értéktelen szerverekről beszélünk. Erre írtam én, hogy nincs értékes vagy értéktelen szerver.
A "Miért pont az én kis mutyi szerverem lenne célpont?" mentalitásról át kellene állni a "Miért pont az én kis mutyi szerverem NE lenne célpont?" mentalitásra. Ez lett volna az egésznek a célja, de kezdjük túlragozni.

--
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Az értő olvasás ugye megy? Ha megy, akkor visszagörgetsz és megnézed, hogy milyen kontextusban volt megemlítve a szerver értékessége. Ha nem sikerülne, akkor segítek: brutal force jelszópróbálkozás volt a kontextus.

Ha még mindig úgy gondolod, hogy a célpont értékétől függetlenül végigpróbálnak minden egyes szerveren 10^18 variációt, akkor engedd meg, hogy hülyének nézzelek, jó?

> Ha valaki arra nem képes, hogy legalább egy rohadt kulcspárt beizzítson,
> akkor véleményem szerint teljesen felesleges bármilyen biztonságról beszélni.

Aki ssh kulcsokat hasznal, az hogyan tudja biztositani,
hogy veszhelyzet eseten be tudjon lepni?
Mindig nala van a laptopja?
Vagy git clone 'my-private-ssh-key-repo' ?:))

Nekem van erre konecpciom:), de kozel se biztos, hogy a legjobb, igy nem is terhelek itt vele senkit se.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( legyes | 2018. 01. 03., sze – 13:37 )

Véletlenül sem lehet, hogy a jelszava esetleg sima bruteforceszal megfejthető? Mert a botoknak van ideje - veled ellentétben - próbálkozni. Esetleg az adatbázishoz valami webes cucc rootként csatlakozik, mert úgy könnyebb volt telepíteni (script injection)?

A vm szolgáltatójának a policy-ja alapból nem kényszeríti ki a kulcsos bejelentkezést, a felhasználó meg nem tudom róla / nem érdekli.
(Esetleg felteszi magának a kérdést, hogy miért pont az ő kis weboldalát törnék fel, ezért nem foglalkozik komolyabban a biztonsággal)

Gondolom

Simán lehet olyan erős jelszót használni, hogy nem lesz gyakorlatilag rosszabb, mint a kulcs

jaja, csak probald megjegyezni. De nem errol van szo: ha a jelszavakat eleve kizarod, akkor az sshd kapasbol kivag, ha nincs kulcsod.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Azért meg lehet jegyezni hosszú jelszót is: szerinted egy olyan jelszót, hogyaszongyapéldául: 1szer1SzepNap0n+Papr1kajancs1M0s0gat, vagy SzappanAdagoLoFogatHajToPartiArcFelismeRes nehéz megjegyezni? És bruteforce módon belepacsálni? Kell néhány jól irányzott generálási elv plusz kellően hosszú, megjegyezhető, de értelmetlen passphrase, és nincs gond a jelszóval.

Persze, egy szolgáltatáshoz elég jó a correct horse, de 100-hoz már mondjuk kitalálsz egy sémát, amivel úgy generálsz jelmondatokat, hogy az valamilyen módon köthető az adott szolgáltatáshoz. Ekkor viszont fenn áll annak a veszélye, hogy ha az egyik-másik szolgáltatótól ellopják a jelszavakat, akkor az ott használt jelszavad alapján kitalálható a máshol tárolt jelszavad is.
--
HUP Firefox extension | Hupper hibajelentés

( p.zoltan | 2018. 01. 03., sze – 17:58 )

Otthoni saját PC-n víruskeresés volt? Lehet, hogy onnan került ki a pass...

( gkaroly v | 2018. 01. 03., sze – 20:59 )

Nem akarok troll lenni, tényleg nem, de ez az egész azért történt meg, mert hanyag volt a VPS tulajdonosa.

Ami nagyon fontos:
- minimum havi, de inkább heti frissítés (erre van tool, debsecan néven, Ubuntun is ez a neve)
- normális sshd.conf beállítás. Az nem baj, ha jelszóval lehet belépni (nyilván kellően bonyolult legyen, cirmi123 szintűeket felejtsük el), de könyörgöm: roottal NE! Még kulccsal se!
- apt-get install fail2ban - szerintem nagyon fontos. Különösebb beállítani való nincs rajta: felrak, örül.
- emellett az sem árt, ha van rsyslog vagy syslog-ng (és logrotate) telepítve, hogy balhé esetén minden visszakereshető legyen.
- és végezetül, tudom, hogy már lerágott csont, de legyen NAPI backup, minimum 7 napra visszamenőleg (helytakarékossági okokból inkrementális mentés) és külön, más szolgáltató szerverére vagy backup szolgáltatásra (mondjuk backblaze.com).

Ezek csak hirtelen jött gondolatok, jöhetnek a kövek, de én már 5 éve üzemeltetek (jelenleg 7) VPS-t és még egyiket se törték meg (kop-kop), pedig egyiken-másikon WordPress is fut.

--
-- Üvegfiú - Csontkemény harc
Tégy Jót!®

roottal ... Még kulccsal se!

miert ne?

- apt-get install fail2ban - szerintem nagyon fontos. Különösebb beállítani való nincs rajta: felrak, örül.

es ez mitol ved meg teged?

- emellett az sem árt, ha van rsyslog vagy syslog-ng (és logrotate) telepítve, hogy balhé esetén minden visszakereshető legyen

ha egyszer mar bementek, akkor cseszheted a helyi logjaidat.

de legyen NAPI backup, minimum 7 napra visszamenőleg (helytakarékossági okokból inkrementális mentés)

ez mit segit rajtad, ha mar bejottek root-kent?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Ezekkel az a bajom, hogy hamis biztonságérzetet adnak...

Oké, tegye fel a kezét, aki tiltja a root felhasználót, a jelszavas SSH belépést.
Oké, hagyja fenn a kezét, aki _legfeljebb_ fél óra alatt javítja napvilágra került biztonsági hibákat, frissítéssel vagy workaround-al ugyanezen a szerveren.
Aha, senki?

Viszont könnyen érthetőek, és csak egyszer kell beállítani. Így aki ezekből a doksikból képzi magát, az sokszor teljes szakértőnek/teljes biztonságban is érzi magát, mert másról nem is tud.
Ki a fenének van kedve CMS-t frissíteni, ami néha összeakad a templattel, pluginnel, a különböző verziójú JS libekkel... na meg egyébként se fizeti meg senki.
Szóval egyet értek veled.

A root-ot mindenhol tiltom, de erős jelszó esetén ennek csak nagyon speciális esetben látom valódi hasznát.
Még van pár szerver, ahol sima jelszavas azonosítás van, de én is támogatom a kulcsot. Ennek az előnye egyértelmű.

De ahogy korábban írtad, nem az ssh szokott a gyenge láncszem lenni.

root kizárása -> akkor legalább a felhasználónevet is brute-forceolni kell, jószándékú ember meg sudo-zik.

fail2ban -> gondolom letiltja a brute-force azon válfaját, amikor egyetlen/kevés IP-ről próbálkoznak.

logok -> nyilván csak akkor van értelme, ha távoli helyre logolsz, és azért jó, mert akkor tanulsz belőle, mit csináltál rosszul.

backup -> van miből újrahúzni a rendszert (ha még időben észreveszed).

ha backup-bol ujrahuzod a rendszert, akkor visszallitottad a serulekeny rendszert, amire ujra be fognak menni. Szoval ezek a tuti tippek csak vajmi keveset tesznek hozza, sot valojaban inkabb fogalmatlansagrol arulkodnak...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

_Ha_? Nem ha, hanem _igen,_olyan_ az allasuk:D

Fentebb irta, hogy Ubuntu 12.04.

Nem is ertem mit var az aki EOL rendszert "uzemeltet".

Innentol nincs tobb kerdes. Aki ennyire _torte_magat_ (erted :D), hogy friss es biztonsagos legyen a szervere es a csomagjai, annal joggal feltetelezhetjuk, hogy lyukas a weboldal, regi es unsecure beallitasokkal megy a webszerver, php, db szerver, meg ugy kb. barmi.

0-day paradicsom :D

Az esettől függetlenül sajnos akad, hogy az ember kénytelen elavult rendszereket üzemeltetni, mert ilyen-olyan okból bizonyos szolgáltatások ezt megkövetelik. Nekem is van Debian6-os rendszerem is még, ahol vélhetően 2020 közepe-vége körül fogunk tudunk az aktuálisra átállni.

--
Tanya Csenöl az új csatorna

( Raynes v | 2018. 01. 04., cs – 13:36 )

Törölném az egészet, egy kompromittálódott, elavult, a jelek szerint könnyen törhető rendszert nem érdemes istápolgatni és pucolgatni. Ismerős meg ne üzemeltessen szervert, ha nem ért hozzá, szépen kérd el az árát, hogy rendbeteszed neki, különben legközelebb sem fogja rendesen megcsinálni, és megint téged fog hívogatni, hogy újra megtörték. Ezt lehet tenni, hogy ne forduljon elő újra. Konkrétabb tanácsot nem is lehet adni, mivel nem írtál részleteket a rendszerről, ami nem is baj, mert talán nem is érdemes részletekbe menni, szar az egész és kész.

A root jogosultsághoz nem kell a root jelszavát tudni, megszerezni, az csak az egyik út. Elég egy lyukas szoftver (nem kell CMS-nek sem lennie), ahonnan valami hibát kihasználva lehet jelszó nélkül root jogosultsághoz jutni, onnan meg szabad az út az egész rendszer szétbarmolása előtt és megevett mindent a fene. Nem pánikkeltésből találták ki a frissítéseket, azokban ráadásul nem csak lyukakat foltoznak, de bugokat is.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Nálam minden eldobható, konfiguráció-menedzsment gyártja a gépeket image-ekből. Minden adat egy-egy szolgáltatás alatt külső kötetekről kerül csatolásra... A fentiek okán egy standard update is eldob-és-kigurít-egy-újat metodikával zajlik percek alatt. Emellett inkrementális napi mentés is készül, de ilyen esetben azonnal formalinba kerülne a VM és beugrana a helyére egy új.

tl;dr: rakd újra, semmit ne emelj 1:1 át a bukott környezetből és ki kell találni, mi volt lyukas, mert nem engedhető meg az ismételt előfordulás
-----------------------
{0} ok boto
boto ?

( atropus | 2018. 01. 09., k – 09:51 )

- Aki keres, talál. A többi csak türelem kérdése.
- Tanulni, tanulni és tanulni
- Amíg nem találod meg a betörés módját, mi a garancia, hogy nem követed el újból ugyanazt a hibát?

( bigfoot v | 2018. 01. 08., h – 19:57 )

Biztos lezúznám az egészet azonnal, újraépíteni – a vm-et meg nézegetném hogyan is csinálhatták :D izgi Colombo munka

Használjuk rendszeresen:
vpn+kulcspár+root nem megyen be :)+1db adott fix ip-ről enged csak be minden mást eldob. Két rossz kód és 1 órára tilt, bla bla bla ...

DMZ, webszerveren semmi csak a csicsa sallang, belépés riasztás, jogosultság jól beállítva (nem ellustulva "de úgy nem akar menni --- baszok én rá"), frissítés (nem évente egyszer), ha jön valami új hókuszpókusz azt bevezetjük mihamarabb.

Karbantartás nélkül úgyis feltörik. (80 -as port mindig rizikós egyébként is)