監視インフラストラクチャを安全に保つ方法


はじめに

監視システムは、インフラストラクチャの包括的な概要を教えてくれます。 インフラストラクチャとシステムを効果的に監視するには、ノードが1つであるか10であるかに関係なく、すべてのデータを1か所にまとめる必要があります。 ただし、このデータの一元化により、攻撃者が標的にして悪用する可能性のある脆弱なポイントが必然的に作成されてしまう側面があります。

この記事では、インフラストラクチャを安全な方法で設計する方法と、ノードを保護する方法に焦点を当て、説明していきます。 この記事の後半では、内部ノードから取得したデータ間の集約ポイントである中央ノードにのみ焦点を当てていきます。

MetricFireを使用することで、監視を維持する心配を専門家に引き渡し、監視インフラストラクチャが完全に保護されていることを確認できます。 セキュリティの監視について興味がある方はデモを予約してください!

脆弱性はどこにあるのか?

監視システムが悪用されてしまう理由はいくつかあります。

まず、機密データが不正な方法でアクセスされた場合(攻撃中など)、悪意のある当事者がダッシュボードの情報を変更、修正、および/または操作して、赤フラグであるところを隠されている可能性があります。

第2に、インフラストラクチャの監視には特定のスキルセットが必要であり、専門家でない場合は、設定ミスにつながる可能性のあるエラーを簡単に作成できます。 前回の記事からわかるように、オープンソースのGraphiteとGrafanaを使用して独自のインフラストラクチャを監視し、GraphiteとGrafanaを構成することは簡単な作業ではありません。
構成の複雑な性質により、潜在的なエラーを検出するのが難しく、構成の誤りやその他のエラーは、攻撃者にインフラストラクチャへのアクセスを許容している可能性があります。

これらの脆弱性を保護する方法

脅威に直面した場合、インフラストラクチャの変動性を考えると、そのような攻撃を管理する正確な方法はありません。 むしろ、実用的で論理的な行動を実践する方法しかありません。

この記事では完全なガイドを意図したものではありませんが、コンピュータセキュリティの分野で研究を深めるために使用できる洞察を提供します。次に、監視システムを保護するためのベストコモンプラクティスを見ていきます。

ゼロトラストアーキテクチャ

すべてのコンポーネント(内部コンポーネントを含む)がユーザーの信頼を「疑う」(したがって、ゼロトラスト)ゼロトラストアーキテクチャを実装することがベストプラクティスと見なされます。

この設定により、エンティティのデフォルトの信頼がなくなり、さらに、アーキテクチャが区分化されているため、攻撃者が自身の攻撃を実行するのが困難になります。 ゼロトラストアーキテクチャの構成はリソースを大量に消費しますが、慎重に設計されたITセキュリティ計画に含めることができる最高のインフラストラクチャの1つと見なされています。

インフラストラクチャの露出を制限する

攻撃対象領域を減らす最善の方法は、Web上でのインフラストラクチャの露出を制限することです。 ほとんどの企業は同様に、イントラネット(内部企業ネットワーク)とエクストラネット(外部に面した企業ネットワーク)があります。

このコンテキストでは、ファイアウォールリバースプロキシの2つの要素が役立ちます。 次のセクションでは、ノードが社内ネットワークとのみ対話するように設定されていることを前提とし、また、DebianディストリビューションがインストールされたIPx.x.x.xとドメインhttp://example.comのマシンで実行されています。

ファイアウォールのインストール

前述のように、内部ノードから取得したデータ間の集約ポイントである中央ノードにのみ焦点を当てます。 このセクションでは、中央ノードにファイアウォールをインストールしましょう。

すべてのUnixベースのシステムには、パケットフィルタリングのルールを含むテーブルがあります。 各TCP / IPパケットには、iptablesがパケットを受け入れるかどうかを決定するのに役立つ一連の情報が含まれています。 非常に簡単な方法で、これがファイアウォールの仕組みです。 iptablesは最も完全なソリューションですが、初心者向けに構成するのは複雑かもしれません。

UFW(Uncomplicated Firewall)は、Pythonで開発された特定のユーティリティであり、iptablesの簡単な構成を可能にしています。 これはLinuxコミュニティによって開発された最高のユーティリティの1つであり、場合によっては、Ubuntuなどの一部のディストリビューションにデフォルトでインストールされていることもあります。

UFWをインストールするには、パッケージリポジトリの更新に進みます。

root@nodo apt update
root@nodo apt install ufw

すべてがうまくいった場合、シェルからufw -vを呼び出すと、使用バージョンが返されます。 UFWは、ルールを使用および適用して、ポートでのリクエストをブロックまたは受け入れることに基づいています。 古典的な構文は次のとおりです。

ufw [option] [port/protocol]

  • option:ALLOWまたはDENYにすることができます
  • port:インターフェイスポート(TCP / IP標準に準拠した0〜65535の整数値); プロトコルを指定するプロトコル(TCPまたはUDP)と組み合わせることができます

私たちのアプローチは、最初にすべての着信接続と発信接続を禁止し、次に関心のある接続のみを開くことです。

ufw default deny incoming
ufw default deny outgoing

このようにすると、攻撃者の可能性があるノードに侵入できなくなります。 攻撃者が他のプログラム(ポートがホワイトリストに登録されている)によってこのルールに違反した場合、ノードから外部へのすべての接続がブロックされるため、攻撃者はシェルを開くことができません。 ファイアウォールを有効にする前に、SSHまたはマシンと通信しているプロトコル(RDPなど)をホワイトリストに登録することが重要であることに注意してください。

ufw allow ssh

これで、ファイアウォールを有効にする準備が整いました。

ufw enable

現時点では、追加のルールは有効にしません。 ファイアウォールのステータス(およびファイアウォールがブロックするポート)を確認するには、次のコマンドを起動します。

ufw status

リバースプロキシをインストールしてから、GrafanaGraphiteのポートを開きます。

ufw allow [port graphite]/tcp
ufw allow [port graphite]/udp

NginXのインストール

リバースプロキシは、クライアントによって行われたすべての外部要求を内部サーバーに転送するために使用される特定のサーバーであるため、公開されません。これは、内部サーバーを疲れさせることなく複数のリクエストを処理するようにロードバランサーと一緒に構成できるため、「階層化」の追加レイヤーを構成します。

この場合、Grafanaで使用される内部サーバーがあり、リバースプロキシはNginXになります。 NginXは、Igor SysoevによってCで開発された有名なWebサーバー(Apacheと共に)です。人気のあるインターネット企業であるNetCraftは、Webの約36%がNginXを介して提供されていると推定しています。

NginXには、HTTPサーバーとして機能するだけでなく、ロードバランサーおよびリバースプロキシとしても機能する機能があります。 Apacheとは異なり、NginXは各リクエストを処理するために、シングルスレッドではなく非同期のイベントベースのアプローチを使用します。したがって、NginXの消費リソースはApacheよりもはるかに少なく、このコンテキストでは論理的な選択になります。

最初のステップとして、パッケージ管理を通じてNginXをインストールします。

root@node apt update && apt install nginx

インストールが成功したことを確認するために、UFWファイアウォールでポート80(HTTP)と443を有効にします。

root@node ufw allow 'Nginx Full'

それでは、http://example.comを確認しましょう。 「NginX works」と表示されている場合は、インストール手順はうまくいった証拠です。 この後、リバースプロキシを挿入します。 すべてのNginX構成がディレクトリ/ etc / nginx / sites-enabledにあることに注意することが重要です。デフォルトの構成ファイルをコピーして、リバースプロキシを有効にします。

NginXには、構成を作成するための簡単なルールがいくつかあります。 各行はディレクティブを表し、セミコロン(;)で終了する必要があります。 行が#で始まる場合、それはコメントです。 変更するサービスに応じて、「ブロック」と呼ばれる単一のセクションに複数のディレクティブを含めることができます(たとえば、「HTTP」ブロックは、サーバーのHTTP応答を変更または変更するディレクティブに使用されます)。

root@node cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/example.com
root@node nano /etc/nginx/sites-enabled/example.com

ここから、HTTPブロックを変更します。

server {
  listen       80;
  server_name  example.com;
location / {
    proxy_pass         127.0.0.1:3000;
    proxy_redirect     off;
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_set_header   Upgrade $http_upgrade;
    proxy_set_header   Connection "upgrade";
  }
}   

proxy_passディレクティブは、NginXが接続する必要のある内部アドレスを指定し、他のディレクティブは、クライアントのヘッダーを設定することことが重要です。内部サーバーは、情報の送信先を認識している必要があり、そうしないと、クライアントは別のクライアントの応答を受信してしまいます。

構成が構文的に正しいことを確認するために、-tフラグを指定してNginXを実行します。

root@nodo nginx -t

エラーがない場合は、NginXを再起動しましょう(graph-webサービスがアクティブであることを確認してください)。

root@nodo systemctl restart nginx

http://example.comにアクセスしましょう。 そうすると、Grafanaユーザーインターフェイスが表示されます。

Let'sEncryptをインストールして最初のTLS証明書を取得

HTTPプロトコルは、クライアントサーバーモデルを介した通信に使用される主要なプロトコルの1つです。クライアント/サーバーモデルでは、クライアントはサーバーにサービスを要求します。クライアントとサーバー間の情報交換はクリアテキストで実行されます。ただし、情報は暗号化されていません。

この場合、コンピュータセキュリティの基本的な特性の1つ、つまりメッセージの信頼性が失われます。このプロトコルでは、サーバーの応答が実際に元の応答であるかどうかをクライアントが確認する方法はありません。これを解決するために、新しいタイプのプロトコルであるTLS(Transportation Layer Security、ex-SSL)が導入されました。

TLSプロトコルを使用すると、クライアントサーバーアプリケーションは、データの改ざん、偽造、および傍受を防止するために、ネットワークを介して通信できます。 TLSのおかげで、悪意のあるノードが送信されたパケットを自由に変更して複製する「Man IntheMiddle」などのコンピューター攻撃を防ぐことができます。

HTTPの拡張であるHTTPSは、TLSを使用してHTTPトラフィックの暗号化を提供するアプリケーション層プロトコルです。ドメインでHTTPSを有効にするには、メッセージの信頼性を保証する証明書を取得する必要があります。 Let’s Encryptは、インフラストラクチャの無料の証明書を取得できる非営利団体です。

それでは、暗号化の専門家でなくても簡単かつ迅速に証明書を取得できるユーティリティであるCertBotをインストールしましょう。

sudo apt-get install certbot python-certbot-nginx

新しい証明書を生成してインストールしましょう。

sudo certbot --nginx

CertBotによって生成された証明書の有効期間は限られており(約90日)、その後、次のコマンドを使用して証明書を更新する必要があります。

sudo certbot renew --dry-run

結論:セキュリティには常に注意が必要です

セキュリティシステムの保守は、その設計およびインストール段階と同じくらい重要です。これらは、さまざまな技術機器を備えた複雑なシステムであり、機能を実行するには100%動作する必要があります。バグは、監視インフラストラクチャに壊滅的な影響を与える可能性があり、その結果、会社全体に意図しない結果をもたらす可能性があります。

Let’s Encryptで見たように、データセキュリティには定期的なメンテナンスが必要です。徹底的なメンテナンス設計は、クラス最高のリソースを使用した結果であるということを覚えておくことが重要です。企業にとって、これにはかなりの時間とお金が必要です。企業がこれらの責任を第三者に委託することを決定した場合、そのような企業は提供されるサービスに圧倒される可能性があるため、第三者の選択に熱心に取り組んでおり、寄り添ってくれる企業である必要があります。

時間の制約があり、効率的かつ効果的に作業したい場合、MetricFireは、監視インフラストラクチャのセキュリティを常に監視し、クラス最高の基準に対応するために継続的な更新を適用する24時間年中無休のチームがあなたをサポートします。詳細については、MetricFireデモをご予約になり、お気軽にお申し付けください。