VPSでハッキングを試みましたが、将来どのように保護するか、彼らは何をしようとしていましたか？
更新：彼らはまだここにいます。それらを停止またはトラップするのを手伝ってください！
こんにちはSF'ers、
誰かが私のクライアントサイトの1つをハッキングしたところです。彼らは、サイトのチェックアウトページが支払い情報をテキストファイルに書き込むように、なんとかファイルを変更することができました。
幸運にも不幸にも彼らは詰め込みました、コードにタイプミスがあり、それがサイトを壊したので、私はすぐにそれについて知るようになりました。
私は彼らがこれをどうやってやったのかについて少し気になっています：
私のウェブサイトCMSには、ウェブサイト内で使用する画像やファイルをアップロードできるファイルアップロード領域があります。アップロードは2つのフォルダーに制限されています。これらのフォルダに2つの疑わしいファイルが見つかりました。内容を調べると、ハッカーはサーバーのファイルシステムを表示して独自のファイルをアップロードしたり、ファイルを変更したり、レジストリキーを変更したりできるようです。
一部のファイルを削除し、パスワードを変更しました。CMSを保護し、拡張子によってファイルのアップロードを制限しようとしています。
他に、彼らがどのように侵入したか、そして将来これを防ぐために他に何ができるかについての詳細を調べるために私がすることを提案できることはありますか？
（クライアントの）サイトがすでに侵害されている場合は、最初にオフラインにする必要があります。ハッカーがルートキットをインストールしなかったことを簡単に証明する方法はありません。そのサーブのすべてのデータが危険にさらされており、失われる可能性があると想定する必要があります。念のため、クレジットカードやその他の支払いデータを暗号化せずにSQLデータベースに保存したり、同じシステムのどこかにキーで暗号化して保存したりしていないことを願っています。
次に、正常なイメージから再構築し、最後の正常なバックアップから復元する必要があります。それが確実な唯一の方法です。軌道から核兵器。
彼らがどのようにシステムに侵入したかを理解する限り、人々がいつログインしたかについてのイベントログを見てください。おそらく監査ログも、アップロード領域からコードを実行したかどうかを教えてくれるかもしれません。これは、特にWebサイトの公的にアクセス可能な領域での実行可能アクセス許可、および監査とロギングに関して、優れた学習体験として役立ちます。
最優先事項は、正常なサーバー上でサイトを再構築し、元のサイトよりも厳重に保護することです。
これは " 侵害されたシステムからの回復 "興味深い読み物だと思うかもしれません。
this の質問に対するRobertMoirの高く評価されている回答も役立つかもしれません。
私のウェブサイトCMSには、ウェブサイト内で使用する画像やファイルをアップロードできるファイルアップロード領域があります。アップロードは2つのフォルダーに制限されています。これらのフォルダに2つの疑わしいファイルが見つかりました。内容を調べると、ハッカーはサーバーのファイルシステムを表示して独自のファイルをアップロードしたり、ファイルを変更したり、レジストリキーを変更したりできるようです。
File-upload-areasが非常に危険であるのは、まさにこのためです。アップロードされたコンテンツがハッキングの試みの一部として再利用されないようにするために、すばらしい措置を講じる必要があります。実行可能コンテンツをブロックすると、サイトの他の場所でXSSに対して脆弱なスクリプトがそのコードを呼び出して、実行可能な独自のコンテキストで実行できる可能性があります。
彼らは後で実行できるものをアップロードすることで参加しました。おそらく彼らはそれを直接呼び出しました。その場合、実行不可能なコンテンツのみがそれらのディレクトリにアップロードできることを確認する必要があります。おそらく彼らは他のスクリプトからそれを呼び出しました。これを発見するには、ログファイルを調べて、特定したファイルを呼び出したスクリプトを確認し、スクリプトを保護する必要があります。
サーバーを再構築したら、これらの穴を詳しく調べて、アップロードディレクトリの必要性を再評価します。
Asp.netを実行していて、SOでタグ付けした場合にのみ、ユーザーがファイルをアップロードするルートディレクトリにこのweb.configを追加するだけで済みます。そのweb.configを使用すると、このディレクトリツリーでaspxページを実行することを誰にも許可しません。
<configuration>
<system.web>
<authorization>
<deny users="*" />
</authorization>
</system.web>
</configuration>
最も重要なことは、アップロード領域がある場合、それらの領域に実行可能ファイルが含まれないようにすることです。
エリアがWebアクセス可能で、アップロードが何でもかまいません。必要なのは、aspx/php/etcスクリプトをその場所にアップロードし、そこに移動してアクティブ化することだけです。
これを防ぐには：
- アップロード時にファイルの名前を変更する
- 場所に移動する前に、コンテンツごとにファイルタイプを確認する
- その場所でスクリプトを実行できないようにWebサーバーを設定します
- アップロード場所がWebアクセス可能である必要がない場合は、外部に移動します
現時点でアクセスできる場合、特にウイルスチェッカーでは見つからない可能性のあるカスタムソフトウェアをしばらく使用している場合は、他の場所ではアクセスできなかったコードのクリーンコピーがあることを確認してください。次に、サーバーを再構築します。はい、アクセスが制限されている場合はおそらくまったく不要ですが、わからない場合は、チャンスを逃さないでください。
そうそう、明らかにすべての場所でallパスワードを変更します。あなたのウェブサイトが読み取り可能なパスワードデータベースを持っているアカウントを持っているなら、それらの2つ。あなたのウェブサイトがユーザーの個人データをホストしている場合、あなたはおそらくあなたの国内法に応じてユーザーとおそらく当局に通知する必要があります。
IISログから、ファイルがいつアップロードされたか、どのIPアドレスから取得されたかを確認できるはずです。
最も重要なことは、アップロード領域がある場合、それらの領域に実行可能ファイルが含まれないようにすることです。
エリアがWebアクセス可能で、アップロードが何でもかまいません。必要なのは、aspx/php/etcスクリプトをその場所にアップロードし、そこに移動してアクティブ化することだけです。
これを防ぐには：
- アップロード時にファイルの名前を変更する
- 場所に移動する前に、コンテンツごとにファイルタイプを確認する
- その場所でスクリプトを実行できないようにWebサーバーを設定します
- アップロード場所がWebアクセス可能である必要がない場合は、外部に移動します