ハッカーは私のEC2インスタンスをどのように侵害しましたか？
私のEC2インスタンスが最近ハッキングされました。私は自分のWebサイトを開始しているだけで、サーバーには機密情報がまだないので、それは本当に問題ではありませんが、将来的には存在する予定です。私のWebサイトを保護するために、侵害されたサーバーを終了し、別のサーバーをセットアップします。
私の問題は、これが二度と起こらないようにすることです。新しいサーバーが安全であることを確信できる唯一の方法は、最初のサーバーがどのように侵害されたかを知り、新しいサーバーが同じように侵害されないようにすることです。方法。しかし、最初のサーバーがどのようにハッキングされたかを特定/理解するのに苦労しています。
使用されるスタックはRails 4.2.4 + Postgresql 9.3 + Puma + Nginx 1.4.6です。実行しているサーバーは、AWS EC2 t2.microインスタンス上のUbuntu 14.04.2 LTSです。My AWSアクセスキーはどこにも公開されていません。サーバーにSSHアクセスできるのは私だけです。
今、私はハッカーではありません、またはそのことについては優れたシステム管理者でもありません（私は学んでいますが）、サーバーへの侵入方法についてオープンマインドを保つ必要がありますが、サーバーにアクセスする唯一の方法はSSHであるので、私はそれがハッカーも侵入した方法だと思います。 SSHポート22のソースが0.0.0.0/0になるようにインバウンドセキュリティグループルールを誤って残していたため、これがハッカーの侵入方法である可能性が高いと思います。
次のようなコマンドで秘密鍵を使用してsshでサーバーにアクセスします
ssh -vi "/home/me/.ssh/my_private_key.pem" ubuntu@my_aws_instance.com
私のサーバーがDDOS攻撃を行っているという[email protected]のメールから侵害の通知を受けました。ログを調べてもこれを確認することはできませんでしたが、/var/tmpに、サーバーが実際にハッキングされていることを確信させるフィッシングメールを送信するように設計されているように見えるいくつかの非表示のphpスクリプトを見つけました。
自分のサーバーを攻撃しようとしたときにhydraによって確認されたsshのパスワードが設定されていません。これは、攻撃者が私のRSA秘密キーを推測したに違いないことを私に示唆しています...私はこれが 現実的には不可能 であることを理解しています。
サーバーが侵害された可能性のある他の方法については知りません。誰かアイデアはありますか？私の仮定または手順のいずれかが間違っていますか？
受信セキュリティグループルール（ハッキングされた時点）：
HTTP TCP 80 0.0.0.0/0
PostgreSQL TCP 5432 0.0.0.0/0
SSH TCP 22 0.0.0.0/0
Custom TCP Rule TCP 9200 91.216.55.150/32
よろしくお願いします。私は多くの有用な情報を省いていると思いますので、何か他に知りたいことがあれば尋ねてください。
編集：
ウェブサイトにはかなり標準的なRailsデータ入力機能が含まれています。主にhtmlフォームを使用しており、 carrierwave と呼ばれるgemを使用して画像をアップロードすることもできます。
使用されているスタックはRails 4.2.4 + Postgresql 9.3 + Puma + Nginx 1.4.6です。実行しているサーバーは、AWS EC2 t2.microインスタンス上のUbuntu 14.04.2 LTSです。
Ruby on Rails 4.2.4 is vulnerable to a directory traversal attack to the render method is used（since Puma run on RoR、thisこれは潜在的に問題となる可能性があります。これにより、攻撃者自身がアクセスすることはできませんが、エスカレーションして リモートコード実行攻撃 にすることができます pgrade RoR バージョン> = 5.0にこれから保護するための.0.beta1.1。
Postgresql 9.3.xは 脆弱DoS からより深刻な バッファオーバーフロー攻撃 までのいくつかの攻撃に対応しています。 PostgreSQLのアップグレード 使用しているバージョンのさまざまな脆弱性から保護するために、最新バージョンにアップグレードします。
Nginx 1.4.6- バージョン1.4.6 のレコードは実際には表示されません。とにかく、少なくともバージョン1.4.xに影響する 2つの既知の脆弱性 があります。 最新バージョン にアップグレードして、これらの脆弱性から保護してください。 （実際には、先月 最新の脆弱性 が発表されており、最新のメインラインバージョン[1.9.9]はまだ脆弱です。これはDoS攻撃であり、対象のファイアウォールルールで防ぐことができます）
秘密鍵を使用してSSHでサーバーにアクセスします...
パスワードログインも許可するようにsshd設定を編集していない限り、これはリモートの攻撃者がSSHログインをブルートフォースできないようにするのに十分です。ただし、SSHクライアントとして使用するコンピューターが危険にさらされている場合は、キーも危険にさらされていることを考慮する必要があります。
ハッカーは私のEC2インスタンスをどのように侵害しましたか？
より多くの情報なしで言うのは難しい。実行中のサービス、ファイアウォールルール、およびログファイルのスタックのリストが役立ちます。
私の問題は、これが二度と起こらないようにしたいことです...
タフなクッキー 。公開されているWebサーバーがある限り、攻撃されます。取るべきより良いアプローチは、これが将来再び起こる可能性があることを受け入れ、それに備えることです。あなたができるいくつかの現実的なことは、ソフトウェアに完全にパッチを当てることです ファイアウォールルールの調整 （本当に 全世界 へのアクセスを与える必要がありますか？ ）、 IDS/IPS を AWSローカルネットワーク に実装してすべてのトラフィックをルーティングし、最後に すべてのトラフィックをログに記録する を転送して- 強化 ロギング サーバー 。
これはおそらく、ハッキングされた方法を理解し、将来ハッキングされるのを防ぐための最も重要なステップです。ログファイルをグレッピングすることはオプションですが、サーバーのログを明確に視覚的に表現すると、異常を検出し、後でサーバーが攻撃されたときに検索することがはるかに簡単になります。 Webサーバーが侵害された場合、攻撃者は攻撃の痕跡をローカルで消去できるため、別個の強化されたログサーバーを用意することが重要です。
さらに一歩進めたい場合は、 異常の検出プロセスを自動化する を行い、それに基づいて反応を定義できます。
最善の解決策は、Linuxで2番目のEC2インスタンスを実装することです。次に、このインスタンスにOpenVPNをインストールします。 WebサーバーにSSH接続するのはあなただけなので、実際には無料のライセンス（2人の同時ユーザー）でOpenVPNアクセスサーバーを入手できます。 0.0.0.0/0からのSSHを許可するルールがあることは悪いニュースです。また、データベースポートはインターネット（0.0.0.0/0）に対して開いてはなりません。
これはどのように作動しますか？たとえば、WebサーバーにSSHで接続するには、まずVPNネットワークに接続する必要があります。次に、プライベートIPを使用してWebサーバーにSSHで接続します。 Webサーバーのセキュリティグループルールは次のようになります。「10.0.8.0/24からのSSHを許可する」AWSにOpenVPNサーバーをインストールする方法は？このリンクに従ってください： AWSにOpenVPNアクセスサーバーをインストール