Kaikkein epämiellyttävä tarina tapahtui yhdelle ystävälleni. Mutta niin epämiellyttävältä kuin se Mihailille osoittautuikin, se oli yhtä viihdyttävää minulle.
Minun on sanottava, että ystäväni on melkoinen UNIX-käyttäjä: voi asentaa järjestelmän itse mysql, php ja tee yksinkertaisia asetuksia Nginx.
Ja hänellä on tusina tai puolitoista rakennustyökaluille omistettua verkkosivustoa.
Yksi näistä moottorisahoille omistetuista sivustoista on tiukasti hakukoneiden kärjessä. Tämä sivusto on ei-kaupallinen arvioija, mutta joku on tottunut hyökkäämään sitä vastaan. Että DDoS, sitten raakaa voimaa, sitten he kirjoittavat säädyttömiä kommentteja ja lähettävät väärinkäytöksiä isännöitsijälle ja RKN:lle.
Yhtäkkiä kaikki rauhoittui ja tämä rauhallisuus ei osoittautunut hyväksi, ja sivusto alkoi vähitellen poistua hakutulosten ylimmiltä riveiltä.
Se oli sanonta, sitten itse järjestelmänvalvojan tarina.
Oli lähellä nukkumaanmenoaikaa, kun puhelin soi: "San, etkö katso palvelintani? Minusta näyttää siltä, että minut hakkeroitiin, en voi todistaa sitä, mutta tunne ei ole jättänyt minua kolmatta viikkoa. Ehkä minun on vain aika hakeutua hoitoon vainoharhaisuuteen?"
Sitä seurasi puolen tunnin keskustelu, joka voidaan tiivistää seuraavasti:
- maaperä hakkerointia varten oli melko hedelmällistä;
- hyökkääjä voi saada pääkäyttäjän oikeudet;
- hyökkäys (jos se tapahtui) oli kohdistettu nimenomaan tähän sivustoon;
- ongelma-alueet on korjattu ja sinun on vain ymmärrettävä, tapahtuiko tunkeutuminen;
- hakkerointi ei voinut vaikuttaa sivuston koodiin ja tietokantoihin.
Viimeiseen kohtaan liittyen.
Vain valkoinen käyttöliittymän IP katsoo ulos maailmaan. Taustaohjelmien ja käyttöliittymän välillä ei ole vaihtoa paitsi http(s), käyttäjät/salasanat ovat erilaisia, avaimia ei vaihdettu. Harmaissa osoitteissa kaikki portit paitsi 80/443 ovat kiinni. Valkoiset tausta-IP:t tietävät vain kaksi käyttäjää, joihin Mikhail luottaa täysin.
Asennettu etuosaan Debian 9 ja kun puhelu soitetaan, järjestelmä on eristetty maailmasta ulkoisella palomuurilla ja pysäytetty.
"Ok, anna minulle pääsy", päätän lykätä unta tunniksi. "Näen omin silmin."
Täällä ja edelleen:
$ 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
Etsitään mahdollista hakkerointia
Käynnistän palvelimen ensimmäisenä pelastustila. Kiinnitän levyt ja selailen niitä todennus-tukit, historia, järjestelmälokit jne., aina kun mahdollista, tarkistan tiedostojen luontipäivämäärät, vaikka ymmärrän, että normaali krakkauskone olisi "pyyhkäissyt" perässään ja Misha oli jo "tallannut" paljon itseään etsiessään .
Aloitan normaalitilassa, en vielä oikein ymmärrä mitä etsiä, tutkin asetuksia. Ensinnäkin olen kiinnostunut Nginx koska yleensä käyttöliittymässä ei ole mitään muuta kuin se.
Asetukset ovat pieniä, hyvin jäsennelty tusinaan tiedostoon, katson ne vain läpi kissa'oi yksi kerrallaan. Kaikki näyttää olevan puhdasta, mutta koskaan ei tiedä, jos olen unohtanut jotain sisältää, anna minun tehdä täydellinen luettelo:
$ 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
En ymmärtänyt: "Missä lista on?"
$ 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
Listauskysymykseen lisätään toinen kysymys: "Miksi niin vanha versio nginxistä?"
Lisäksi järjestelmä uskoo, että uusin versio on asennettu:
$ dpkg -l nginx | grep "[n]ginx"
ii nginx 1.14.2-2+deb10u1 all small, powerful, scalable web/proxy server
Soitan:
- Misha, miksi kokosit uudelleen? Nginx?
- Odota, en edes tiedä kuinka tehdä tämä!
- Okei, mene nukkumaan...
nginx se on selkeästi rakennettu uudelleen ja listauksen tulos "-T" on piilotettu syystä. Hakkeroinnin suhteen ei ole enää epäilyksiä ja voit yksinkertaisesti hyväksyä sen ja (koska Misha kuitenkin vaihtoi palvelimen uuteen) pitää ongelmaa ratkaistuna.
Ja todellakin, koska joku sai oikeudet juuri'ah, sitten se on vain järkevää tehdä järjestelmän uudelleenasennus, ja oli turha etsiä, mikä siellä oli vialla, mutta tällä kertaa uteliaisuus voitti unen. Kuinka voimme saada selville, mitä he halusivat salata meiltä?
Yritetään jäljittää:
$ strace nginx -T
Katsomme sitä, jäljessä ei selvästikään ole tarpeeksi viivoja a la
write(1, "/etc/nginx/nginx.conf", 21/etc/nginx/nginx.conf) = 21
write(1, "...
write(1, "n", 1
Ihan huvin vuoksi verrataan tuloksia.
$ strace nginx -T 2>&1 | wc -l
264
$ strace nginx -t 2>&1 | wc -l
264
Mielestäni osa koodia /src/core/nginx.c
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
ngx_dump_config = 1;
break;
tuotiin muotoon:
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
//ngx_dump_config = 1;
break;
tai
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
ngx_dump_config = 0;
break;
siksi luetteloa "-T" ei näytetä.
Mutta kuinka voimme tarkastella kokoonpanoamme?
Jos ajatukseni on oikea ja ongelma on vain muuttujassa ngx_dump_config yritetään asentaa se käyttämällä gdb, onneksi on avain --with-cc-opt -g esittää ja toivoa, että optimointi -O2 se ei satuta meitä. Samaan aikaan, koska en tiedä miten ngx_dump_config voitaisiin käsitellä tapaus "T":, emme kutsu tätä lohkoa, vaan asennamme sen käyttämällä tapaus 't':
Miksi voit käyttää '-t' sekä '-T'Estä käsittely if(ngx_dump_config) tapahtuu sisällä 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;
}
Tietenkin, jos koodia muutetaan tässä osassa eikä sisällä tapaus "T":, silloin menetelmäni ei toimi.
Testaa nginx.confKun ongelma on jo ratkaistu kokeellisesti, todettiin, että haittaohjelman toimiminen vaatii vähimmäiskokoonpanon Nginx tyyppi:
events {
}
http {
include /etc/nginx/sites-enabled/*;
}
Käytämme sitä artikkelissa lyhyyden vuoksi.
Käynnistä debuggeri
$ 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
Askel askeleelta:
- aseta keskeytyspiste funktioon main ()
- käynnistä ohjelma
- muuttaa sen muuttujan arvoa, joka määrittää konfiguraation lähdön ngx_dump_config=1
- jatkaa/lopeta ohjelmaa
Kuten näemme, todellinen konfiguraatio eroaa meidän, valitsemme siitä loiskappaleen:
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;
Katsotaanpa mitä täällä tapahtuu järjestyksessä.
Päättäväinen User-Agentyandex/google:
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}
Palvelusivut eivät sisälly wordpress:
map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}
Ja niille, jotka kuuluvat molempien yllä olevien ehtojen piiriin
map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}
map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}
tekstissä html-sivut vaihtuvat 'o' päälle 'o' и 'A' päälle 'a':
sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;
Aivan oikein, ainoa hienous on se 'a'! = 'a' ihan kuin 'o'! = 'o':
Siten hakukonebotit vastaanottavat normaalin 100 % kyrillisen tekstin sijaan muokattua roskaa, joka on laimennettu latinalla 'a' и 'o'. En uskalla keskustella siitä, miten tämä vaikuttaa SEO:hin, mutta tuskin tuollaisella kirjainsekoituksella on positiivinen vaikutus sijoituksiin hakutuloksissa.
Mitä voin sanoa, pojat, joilla on mielikuvitus.
viittaukset
Lähde: will.com