OP がログを追加した後、その問題が Struts 2 のリモート コード実行エクスプロイト (CVE-2017-5638) にあることが明らかになりました。
いくつかの追加リンク:
<オール>解決策は、Struts をバージョン 2.3.32 または 2.5.10.1 にアップグレードすることです。
私がシステム管理者だったとき、私は以前に同様の問題に直面しました。 Tomcat サーバーか Java アプリかを区別する必要があると思います。
「感染したJavaアプリ」なしでTomcatを起動すると、cronが有効になりますか? (つまり、Tomcat からアプリケーションを削除して起動します) その場合は、より大きな問題があるため、起動スクリプトと、Tomcat サーバーにデプロイされたすべてのアプリケーションを確認する必要があります。
それ以外の場合は、アプリに問題があると確信しています。
その場合は、
にアクセスしてください。$CATALINA_BASE/webapps/your_app
アプリケーションの整合性を確認してください。認識できない追加のファイルはありますか?
次に、Tomcat インストールの webapps ディレクトリに移動します。
$CATALINA_BASE/webapps/
そのディレクトリで実行:
grep -R '91.230.47.40' *
感染の原因となっている可能性のあるファイル/コード行を見つけるには、アプリのファイルまたは新しいファイルである可能性があります。
コードは CSV システムにありますか?
CSV リポジトリから感染したサーバーの外部で war ファイルをビルドし、次のことを行います。
md5sum your_app.war
Tomcat サーバーからアプリケーションを削除して再デプロイし、md5 を介して正しい war をアップロードしていることを確認してから、crontab が呼び出されているかどうかを確認してください。
この手順についてフィードバックをお寄せいただければ、喜んでお手伝いさせていただきます。
サーバー上でこの種の攻撃を撃退する必要がありましたが、上記のように tomcat ユーザーの crontab を上書きし続けました。 IPアドレスは同じでした。 IP アドレスの webapps ディレクトリ全体を grep しても原因は明らかになりませんでした。
私たちの場合、ストラットは使用しませんが、webapps に「host-manager」アプリと「manager」アプリがあり、JMX が有効でポートが開いていました。それらなしで再起動すると解決したように見えるので、私の推測では、脆弱性はそれらのいずれかにある可能性があります.具体的には、7.0.73 で修正された JMX の脆弱性が原因である可能性があります (https://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.73)。
私たちが現在行っているもう 1 つの予防策は、wget と chmod へのアクセスを root のみに制限することです (これらのバイナリで chmod 770 を実行するだけです)。