Wordpressを使用したシステムの検証

Tomo-9925 commented 3 years ago

コードの改善としては，応答速度が激遅だったためキャッシュの機能をつけたり，AF_INET6のソケットを使われた場合にIPv4の検知が行えなかったためIPv6へのサポートをしたりしていました．あと，ログの出力の方，マージし忘れていたため，サクッと場所を入れ替えて対応しています．すみません．

検証内容としてWordpressコンテナでwp-cron.phpをcronで実行することを想定して，複数コンテナ（mariadb, wordpress）複数プロセス（apache2, mariadb, php）の通信制御を行います（wp-cronは通信が来るたびにスケジュールされたジョブを確認して実行するかどうかを判断します．このcronを使用した手法はパフォーマンスが下がる問題や，ジョブが正確に行われないという問題を解決します．）．発生しうる通信は，exampleのwordpressの通りです（漏れがあれば教えて下さい）．

検証では，容易な認証情報の流出により，metasploitのexploits/unix/webapp/wp_admin_shell_uploadを使用してシェルにアクセスされることを想定します（アイデアが無い…）．現在行った感じだと，うまく弾いてくれるのですが，ログを見るとプロセスの特定に失敗するという問題が発生しています．何らかのバグを見つけた場合報告していただけると幸いです．

masibw commented 3 years ago

ありがとうございますまだコードは深く読めていないのですが

ログの修正
キャッシュの実装
IPv6の対応のような関心毎にPRを分けていただけるとレビューの面でもGitの操作的にもありがたいです...

Tomo-9925 commented 3 years ago

すみません、次々と問題が見つかってしまって、こうなってしまいました…以後気をつけます🙇🏻‍♂️

Tomo-9925 commented 3 years ago

現在行った感じだと，うまく弾いてくれるのですが，ログを見るとプロセスの特定に失敗するという問題が発生しています．何らかのバグを見つけた場合報告していただけると幸いです．

改めてログを見てみると，同じような通信がちゃんとできているものがあるので，キューから取り出される前にソケットが閉じられたり，プロセスが終了したり可能性があるので，正規の動作かなと思いました．ちゃんと検証もしたほうが良いのかな…？

cnet.log.gz

masibw commented 3 years ago

pingだけですがパフォーマンス測定の結果をおいておきます

以前(キャッシュなし)

/ # ping -c {serverIP}
PING {serverIP} ({serverIP}): 56 data bytes
64 bytes from {serverIP}: seq=0 ttl=63 time=10.305 ms
64 bytes from {serverIP}: seq=1 ttl=63 time=11.974 ms
64 bytes from {serverIP}: seq=2 ttl=63 time=8.103 ms
64 bytes from {serverIP}: seq=3 ttl=63 time=7.117 ms
64 bytes from {serverIP}: seq=4 ttl=63 time=7.607 ms
64 bytes from {serverIP}: seq=5 ttl=63 time=6.809 ms
64 bytes from {serverIP}: seq=6 ttl=63 time=10.730 ms
64 bytes from {serverIP}: seq=7 ttl=63 time=6.832 ms
64 bytes from {serverIP}: seq=8 ttl=63 time=7.434 ms
64 bytes from {serverIP}: seq=9 ttl=63 time=7.179 ms

--- {serverIP} ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 6.809/8.409/11.974 ms

このPR(procキャッシュ)

3 packets transmitted, 0 packets received, 100% packet loss
/ # ping -c 10 {serverIP}
PING {serverIP} ({serverIP}): 56 data bytes
64 bytes from {serverIP}: seq=0 ttl=63 time=14.995 ms
64 bytes from {serverIP}: seq=1 ttl=63 time=8.642 ms
64 bytes from {serverIP}: seq=2 ttl=63 time=4.685 ms
64 bytes from {serverIP}: seq=3 ttl=63 time=3.793 ms
64 bytes from {serverIP}: seq=4 ttl=63 time=3.599 ms
64 bytes from {serverIP}: seq=5 ttl=63 time=3.850 ms
64 bytes from {serverIP}: seq=6 ttl=63 time=4.347 ms
64 bytes from {serverIP}: seq=7 ttl=63 time=5.159 ms
64 bytes from {serverIP}: seq=8 ttl=63 time=3.219 ms
64 bytes from {serverIP}: seq=9 ttl=63 time=3.023 ms

--- {serverIP} ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 3.023/5.531/14.995 ms

Tomo-9925 commented 3 years ago

先生との概要内容の議論メモ

プロセスが特定できない問題

ソケットが閉じられていたのであれば，処理速度を上げる．無駄がないかを再度確認すべき．

キャッシュはパケットから特定したinode->プロセスでなくソケット->プロセスごとに取るべきでは？

正確にプロセスが特定できないのではと思っていたが，それよりも処理時間が原因で特定ができなくなる方が問題．

TO-DO

[ ] 並列処理
[x] キャッシュの変更

ひとまず，ここのコードの問題を修正，マージ次第，別のブランチでTO-DOの変更を行います．

masibw commented 3 years ago

ありがとうございます

僕も処理速度について確認しようと思ってたんですがそもそも使ってるnfqueueが重い説もあるのかなーと思ってるのでnfqueueに渡してすぐに透過させた場合どれくらいの速度低下があるのか測ってみたいですね…（近いうちにします）

Tomo-9925 commented 3 years ago

wp-cronは通信が来るたびにスケジュールされたジョブを確認して実行するかどうかを判断します．このcronを使用した手法はパフォーマンスが下がる問題や，ジョブが正確に行われないという問題を解決します．

ここのところがあまり理解できていないです..どう言う意味ですか？

わざわざコンテナでcontabをインストールしてwp-cronをphpで実行させる意味ですよね…？あまりうまく説明できなかったと自分でも思っています… 次のページがわかりやすいと思うので参考にしてみてください．

wp-cronの起動をcronに任せてWordPressを高速化させる。 | ハックノート

キューから取り出される前にソケットが閉じられたり，プロセスが終了したり可能性があるので，正規の動作かなと思いました

キューというのはiptablesから渡してるNFQUEUEのことですよね？取り出される前にソケット・プロセスが終了するというのはこのシステムの処理が遅くて間に合ってないと言う意味にはならないですか？

システムの高速化，がんばります…

masibw commented 3 years ago

あーーなるほど！！

このcronを使用した手法はパフォーマンスが下がる問題や，ジョブが正確に行われないという問題を解決します．

これをcnetのパフォーマンス下がる問題の解決だと勘違いしてました！なるほどです！

システムの高速化，がんばります…

遅いと入ってもmsレベルの話なのでかなり厳しいチューニングにはなりそうですよね…微力ながらお手伝いさせていただけたらと思います🙇‍♂️

Tomo-9925 commented 3 years ago

ソケットキャッシュも含め一通りできる修正は行いました（並列処理はちゃんと分けます）．再度確認していただけると幸いです．（関数名が長いのはどうしようもないです…）

masibw commented 3 years ago

最小限のシステムで実験してみたんですが最初から倍遅くなってるので結構パフォーマンス厳しいですね〜〜〜 https://github.com/masibw/only-netfilter-queue 何もシステムなし

/ # ping -c 10 {serverIP}
PING {serverIP} ({serverIP}): 56 data bytes
64 bytes from {serverIP}: seq=0 ttl=63 time=0.309 ms
64 bytes from {serverIP}: seq=1 ttl=63 time=0.294 ms
64 bytes from {serverIP}: seq=2 ttl=63 time=0.422 ms
64 bytes from {serverIP}: seq=3 ttl=63 time=0.471 ms
64 bytes from {serverIP}: seq=4 ttl=63 time=0.407 ms
64 bytes from {serverIP}: seq=5 ttl=63 time=0.560 ms
64 bytes from {serverIP}: seq=6 ttl=63 time=0.398 ms
64 bytes from {serverIP}: seq=7 ttl=63 time=0.434 ms
64 bytes from {serverIP}: seq=8 ttl=63 time=0.596 ms
64 bytes from {serverIP}: seq=9 ttl=63 time=0.480 ms

--- {serverIP} ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.294/0.437/0.596 ms

最小限のシステムあり

/ # ping -c 10 {serverIP}
PING {serverIP} ({serverIP}): 56 data bytes
64 bytes from {serverIP}: seq=0 ttl=63 time=1.084 ms
64 bytes from {serverIP}: seq=1 ttl=63 time=1.122 ms
64 bytes from {serverIP}: seq=2 ttl=63 time=0.750 ms
64 bytes from {serverIP}: seq=3 ttl=63 time=0.873 ms
64 bytes from {serverIP}: seq=4 ttl=63 time=0.922 ms
64 bytes from {serverIP}: seq=5 ttl=63 time=0.857 ms
64 bytes from {serverIP}: seq=6 ttl=63 time=0.772 ms
64 bytes from {serverIP}: seq=7 ttl=63 time=0.812 ms
64 bytes from {serverIP}: seq=8 ttl=63 time=0.964 ms
64 bytes from {serverIP}: seq=9 ttl=63 time=0.736 ms

--- {serverIP} ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.736/0.889/1.122 ms

Tomo-9925 / cnet