7-security-measures-to-protect-your-servers

SSHを使用すると、パスワード認証を含むあらゆる種類の認証が完全に暗号化されます。 ただし、パスワードベースのログインが許可されている場合、悪意のあるユーザーは繰り返しサーバーへのアクセスを試みることができます。 最新のコンピューティング能力を使用すると、これらの試行を自動化し、適切なパスワードが見つかるまで組み合わせて組み合わせを試みることにより、サーバーへのエントリを取得することが可能です。

SSHキー認証をセットアップすると、パスワードベースの認証を無効にできます。 通常、SSHキーにはパスワードよりも多くのデータが含まれているため、攻撃者が実行しなければならない可能性のある組み合わせが大幅​​に増えます。 多くのSSHキーアルゴリズムは、一致する可能性があるものを実行するのに時間がかかりすぎるという理由だけで、現代のコンピューティングハードウェアでは解読できないと考えられています。

SSHキーは非常に簡単に設定でき、LinuxまたはUnixサーバー環境にリモートでログインするための推奨される方法です。 マシン上でSSHキーのペアを生成でき、数分以内に公開キーをサーバーに転送できます。

キーの設定方法については、https：//www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys—​2 [このガイド]をご覧ください。 それでもパスワード認証が必要だと感じたら、https：//www.digitalocean.com/community/tutorials/how-to-install-and-use-fail2ban-on-ubuntu-14-04 [fail2ban ]サーバーでパスワードの推測を制限します。

ファイアウォールは、サーバー構成の重要な部分です。 サービス自体がセキュリティ機能を実装していたり​​、実行したいインターフェースに制限されている場合でも、ファイアウォールは追加の保護層として機能します。

適切に設定されたファイアウォールは、開いたままにする必要がある特定のサービスを除くすべてへのアクセスを制限します。 ほんの数個のソフトウェアを公開するだけで、サーバーの攻撃対象領域が減少し、悪用に対して脆弱なコンポーネントが制限されます。

Linuxシステムには多くのファイアウォールがあり、その中には他のものよりも学習曲線が急勾配のものがあります。 ただし、一般的には、ファイアウォールの設定は数分で完了し、サーバーの初期設定時またはコンピューターで提供されるサービスを変更するときにのみ必要になります。

簡単な選択はhttps://www.digitalocean.com/community/tutorials/how-to-setup-a-firewall-with-ufw-on-an-ubuntu-and-debian-cloud-server[UFW firewall]です。 その他のオプションは、https：//www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-iptables-on-ubuntu-14-04 [iptables]またはhttps：/を使用することです。 /www.digitalocean.com/community/tutorials/how-to-install-and-configure-config-server-firewall-csf-on-ubuntu[CSF firewall]。

内部通信にパブリックネットワークの代わりにプライベートネットワークを使用することは、2つの選択肢があることを考えると、ほとんど常に望ましいことです。 ただし、データセンター内の他のユーザーは同じネットワークにアクセスできるため、サーバー間の通信を保護するための追加の対策を実施する必要があります。

VPNの使用は、事実上、サーバーのみが見ることができるプライベートネットワークをマップする方法です。 通信は完全にプライベートで安全です。 VPNソフトウェアが公開する仮想インターフェイスを介してトラフィックを渡すように、他のアプリケーションを構成できます。 このように、パブリックインターネット上のクライアントが消費できるサービスのみをパブリックネットワークに公開する必要があります。

この機能を備えたデータセンターでプライベートネットワークを利用することは、サーバーの作成中にインターフェイスを有効にし、プライベートネットワークを使用するようにアプリケーションとファイアウォールを構成するのと同じくらい簡単です。 データセンター全体のプライベートネットワークは、同じネットワークを使用する他のサーバーとスペースを共有することに注意してください。

VPNに関しては、初期セットアップはもう少し複雑ですが、ほとんどのユースケースではセキュリティの向上は価値があります。 VPN上の各サーバーには、セキュリティで保護された接続の確立と構成に必要な共有セキュリティと構成データが必要です。 VPNが起動して実行された後、VPNトンネルを使用するようにアプリケーションを構成する必要があります。 インフラストラクチャを安全に接続するためのVPNの設定については、https：//www.digitalocean.com/community/tutorials/how-to-secure-traffic-between-vps-using-openvpn [OpenVPNチュートリアル]をご覧ください。

サーバーの認証局を確立して証明書を管理すると、インフラストラクチャ内の各エンティティが他のメンバーのIDを検証し、トラフィックを暗号化できます。 これにより、攻撃者がインフラストラクチャ内のサーバーを模倣してトラフィックを傍受する中間者攻撃を防ぐことができます。

各サーバーは、中央の認証局を信頼するように構成できます。 その後、認証局が署名する証明書は暗黙的に信頼されます。 通信に使用しているアプリケーションとプロトコルがTLS / SSL暗号化をサポートしている場合、これはVPNトンネルのオーバーヘッドなしでシステムを暗号化する方法です（VPNは内部でSSLを使用することもよくあります）。

認証局の設定と公開鍵インフラストラクチャの残りの設定には、かなりの初期努力が必要です。 さらに、証明書を管理すると、新しい証明書を作成、署名、または失効する必要がある場合に、追加の管理負担が発生する可能性があります。

多くのユーザーにとって、本格的な公開鍵インフラストラクチャを実装することは、インフラストラクチャのニーズが拡大するにつれて、より意味があります。 VPNを使用してコンポーネント間の通信を保護することは、追加の管理コストに見合うPKIのポイントに到達するまで、適切なストップギャップの手段になる場合があります。

サーバーは、内部目的および外部クライアントを処理するために多くのプロセスを開始します。 これらはそれぞれ、悪意のあるユーザーに対する攻撃対象領域の拡大を表しています。 実行しているサービスが多いほど、アクセス可能なソフトウェアに脆弱性が存在する可能性が高くなります。

マシン上でどのネットワークサービスが実行されているかを把握したら、これらのサービスの分析を開始できます。 それぞれの質問に答えたい質問は次のとおりです。

このタイプのサービス監査は、インフラストラクチャ内の新しいサーバーを構成する際の標準的なプラクティスです。

基本的なサービス監査は非常に簡単です。 `+ netstat +`コマンドを使用すると、各インターフェイスのポートをリッスンしているサービスを確認できます。 TCPおよびUDPトラフィックのリッスンに使用されているプログラム名、PID、およびアドレスを示す簡単な例は次のとおりです。

次のような出力が表示されます。

注意が必要な主な列は、「+ Proto」、「+ Local Address」、および「+ PID /プログラム名」です。 アドレスが「0.0.0.0」の場合、サービスはすべてのインターフェイスで接続を受け入れています。

上記のサービスレベル監査と同様に、安全なシステムの確保に真剣に取り組んでいる場合、システムのファイルレベル監査を実行できると非常に便利です。 これは、管理者が定期的に実行することも、IDSの自動化プロセスの一部として実行することもできます。

これらの戦略は、ユーザーまたはプロセスによってファイルシステムが変更されていないことを確実に確認する唯一の方法です。 多くの理由で、侵入者は多くの場合、長期間サーバーを悪用し続けることができるように隠されたままにしたいと望んでいます。 バイナリを侵害されたバージョンに置き換える可能性があります。 ファイルシステムの監査を行うと、ファイルのいずれかが変更されているかどうかがわかり、サーバー環境の整合性に自信を持つことができます。

IDSの実装またはファイル監査の実施は、非常に集中的なプロセスになる場合があります。 初期構成では、サーバーに行った非標準的な変更について監査システムに通知し、ベースライン読み取り値を作成するために除外する必要があるパスを定義します。

また、日々の運用がより複雑になります。 アップデートを実行する前にシステムを再確認し、アップデートの実行後にベースラインを再作成してソフトウェアバージョンの変更をキャッチする必要があるため、アップデート手順が複雑になります。 また、侵入者が監査を変更して追跡できないように、レポートを別の場所にオフロードする必要があります。

これにより管理の負荷が増大する可能性がありますが、既知の良好なコピーに対してシステムをチェックできることは、知らないうちにファイルが変更されていないことを確認する唯一の方法の1つです。 一般的なファイル監査/侵入検知システムには、https：//www.digitalocean.com/community/tutorials/how-to-use-tripwire-to-detect-server-intrusions-on-an-ubuntu-vps [Tripwire]およびhttps://www.digitalocean.com/community/tutorials/how-to-install-aide-on-a-digitalocean-vps[Aide]。

プロセスを個々の実行環境に分離すると、発生する可能性のあるセキュリティ上の問題を分離する能力が向上します。 bulkheadsとコンパートメントが船の船体違反を封じ込めるのと同様に、個々のコンポーネントを分離することで、侵入者がインフラストラクチャの他の部分へのアクセスを制限できる。

選択した封じ込めの種類によっては、アプリケーションの分離は比較的簡単です。 個々のコンポーネントをコンテナにパッケージ化することで、ある程度の分離を迅速に達成できますが、Dockerはコンテナ化をセキュリティ機能と見なさないことに注意してください。

各ピースに「+ chroot 」環境を設定すると、ある程度の分離も提供できますが、これは「 chroot +」環境から抜け出す方法がしばしばあるため、絶対確実な分離方法でもありません。 専用マシンへのコンポーネントの移動は、最高レベルの分離であり、多くの場合、最も簡単な場合がありますが、追加のマシンのコストが高くなる場合があります。