GNU/Linux >> Linux の 問題 >  >> Linux

Windowsサーバーのセキュリティのベストプラクティス

管理された運用のお客様向けの免責事項

必要なときにRackspaceがサーバーにアクセスできるようにするために、セキュリティのベストプラクティスを検討する際に、次の構成を変更しないでください。

  • サーバーに接続するとき、RackspaceSupportはユーザーrackとしてログインします ポート3389を介したパブリックIPアドレスへのリモートデスクトップ接続を使用する。

  • 既存のサーバーを再構築するか、スナップショットから新しいサーバーを構築するには、管理者ログインが有効になっている必要があり、ポート445はMicrosoft®Windows®ファイアウォールでブロックされていません。

これらの値を変更する必要がある場合は、Rackspaceの管理者に連絡して、 FanaticExperienceを提供する能力に影響を与えない方法で変更を加えてください。 ®。

この記事では、パブリックインターネットと対話するMicrosoftWindowsサーバーをセットアップするときに考慮すべき一般的なセキュリティのベストプラクティスをいくつか紹介します。これらのベストプラクティスは一般的にすべてのサーバーに適用されますが、この記事では特にWindowsを実行しているRackspacePublicCloudServerについて説明します。

ローカルファイアウォールルールを使用する

デフォルトでは、Rackspace PublicCloudServerにはファイアウォールデバイスがありません。ファイアウォールデバイスなしでパブリックインターネットと相互作用するサーバーの場合、Windowsファイアウォールは、サーバーリソースとプライベートデータ、およびインターネット接続にアクセスできるすべてのユーザーとの間の唯一の保護です。

ファイアウォールでできるだけ多くのルールを無効にします。ルールを無効にすると、公開インターフェースを介して開いてリッスンするポートが少なくなり、サーバーにアクセスしようとするユーザーへのサーバーの露出が制限されます。

開いている必要があるポートについては、それらの特定のルールでIPアドレスをホワイトリストに登録して、サーバーへのアクセスを制限します。インターネットサービスプロバイダー(ISP)が時間の経過とともに変化する動的なパブリックIPアドレスを提供している場合でも、ローカルの自宅またはオフィスのコンピューターのIPアドレスをホワイトリストに追加します。コンソールからリモートでサーバーにログインし、新しいIPアドレスを追加することで、クラウドコントロールパネルから必要に応じてファイアウォールルールを変更できます。

IPアドレスのホワイトリストを介してサーバーへのアクセスを制限することで、サーバーへのアクセスが必要なユーザーがサーバーにアクセスできるようにすることができますが、そうでないユーザーはこれらのオープンポートからブロックされます。クラウドサーバーでのウェブホスティングのためにWindowsファイアウォールで開く必要がある最も一般的なポートは次のとおりです。

ポート サービス
80 HTTP IISサイトまたはWebアプリケーション
443 HTTPS SSLを使用してIISサイトまたはWebアプリケーションを保護する

サーバー上の一般的な名前のアカウントまたはサービスに対するブルートフォース攻撃または悪用の試みを制限するために、パブリックインターフェイスのIPアドレスホワイトリストを介して次のポートをロックダウンすることをお勧めします。

ポート 説明
3389 サーバーにリモートでログインするためのリモートデスクトップ接続
21 FTP 地域の地理的な場所とクラウドサーバー間でデータを安全に転送するため
990 FTPS(Windows) 地域の地理的な場所とSSL証明書を組み込んだクラウドサーバー間でデータを安全に転送するため
5000-5050 FTP FTP通信用のパッシブポート
1433 SQL SQL通信に使用されるデフォルトのポート
53 DNS DNSリクエストに使用されるデフォルトのポート
何を共有するかを検討する

ファイル共有を介して他のユーザーが利用できるデータを検討してください。ファイアウォールで開いているポート(ポート445および139)がサーバーを不要な接続試行にさらすため、Windowsファイル共有を有効にすることはお勧めしません。

一部のお客様は、サーバーを使用して、QuickBooks®、PeachTree、MicrosoftOffice®(リモートデスクトップセッション用のOutlook®)、またはその他のサードパーティソフトウェアソリューションなどのバックオフィスソフトウェアをホストしています。顧客は、マップされたネットワークドライブを構成して、ローカルコンピューターのドライブ文字を使用してローカルコンピューターからクラウドサーバーにデータを簡単に移動できるようにしたい場合があります。ただし、この方法はお勧めしません。サーバーの安全性は、最も弱いパスワードと同じです。

さらに、ユーザーがサーバーにダウンロードしてインストールできるようにするソフトウェアに注意してください。インストールされているすべてのソフトウェアパッケージは、サーバーの攻撃への露出を高めます。

パスワードポリシー

前述のように、ハードウェアファイアウォールを使用してクラウドサーバーをプロビジョニングしたかどうかに関係なく、サーバーは、それにアクセスできる最も弱いパスワードと同じくらい安全です。パスワードについては、次のヒントに従ってください。

  • 大文字と小文字、数字、および特殊文字(!、#、$、%など)を含む12〜14文字以上の強力なパスワードを使用してください。単純なパスワードを割り当てることは、特にパブリックインターネット上で利用可能なクラウドサーバーにとっては非常に危険です。

  • 各ユーザーのパスワードの有効期限を設定します。新しいパスワードを定期的に覚えておく必要があるのは不便ですが、この方法でデータの安全性を高めることができます。

ビルド後の自動化プロセスは管理者のデフォルトのユーザーアカウントに依存しているため、Windowsを実行しているクラウドサーバーでこのユーザー名を変更することはお勧めしません。

管理者アカウントを介してサーバーにアクセスできるユーザーに注意してください。複数のユーザーがサーバーへの管理者アクセスを必要とする場合は、管理者アクセス権を持つ複数のアカウントを作成します。管理者アカウントで複数のログファイルエントリを解読しようとするよりも、特定のユーザーアカウントを探すことで、ログファイル内のユーザーを追跡する方が簡単です。

Event Id 4625の複数のインスタンス セキュリティログまたはEvent Id 1012 SystemLogにある場合、これらのイベントはログイン試行の失敗に関連しているため、誰かがサーバーをハッキングしようとしていることを意味している可能性があります。

リモートデスクトップ接続(RDC)を介してログインするユーザーの場合、サーバーでセッションを開いたままにするRDCウィンドウを単に閉じるのではなく、サーバーからログオフして使用済みリソースを解放していることを確認してください。

アクティブディレクトリ

侵入からの唯一の保護はWindowsファイアウォールであり、Active Directoryはクラウドサーバー環境に問題をもたらすため、通常、クラウドサーバーでActiveDirectoryを実行することはお勧めしません。 Active Directoryは通常、サーバーが物理ファイアウォールの背後に配置され、そのファイアウォールアプライアンスを介してVPNトンネリングを介して接続される専用サーバー環境でより適切に使用されます。

Rackspaceは、RackConnectと呼ばれるソリューションのハードウェアファイアウォールを経由する場合にのみ、仮想プライベートネットワーク(VPN)をサポートします。この記事の執筆時点では、ファイアウォールとサーバーを接続するプロセスはビルドプロセス中に自動化されているため、サーバーを作成する前にこの物理ファイアウォールのセットアップを実装する方が簡単です。物理ファイアウォールはクラウドサーバーほど迅速にプロビジョニングされないため、ハイブリッドチームを通じてリクエストする必要があります。物理ファイアウォールとRackConnectの詳細については、https://www.rackspace.com/cloud-connectivity/rackconnect/を参照してください。

クラウドサーバーにActiveDirectoryをインストールする場合は、1つに障害が発生した場合に備えて、2つのドメインコントローラーを実行することをお勧めします(現在、ドメインコントローラーではイメージングを使用できません)。 DNS増幅攻撃を防ぐために、DNSをロックダウンすることもお勧めします。

SQLServerインスタンス

MicrosoftSQLServer®を実行しているサーバーの場合、SQLポート1433をロックダウンして、内部インターフェイスのみをリッスンします。できれば、サーバー上のSQLServerにアクセスする必要がある他のサーバーの既知のIPアドレスのリストからの接続のみをリッスンします。 SQLポート1433がパブリックインターフェイスを介してリッスンすることを許可できますが、このルールは、開発者がサーバー上のデータベースに接続しているコンピューターのIPアドレスのみに制限する必要があります。

これらの接続をサーバーに制限しない場合、ポート1433が公開され、外部のハッカーが このポートを介してサーバーにブルートフォース攻撃を試みます。これらのタイプの攻撃は、ネットワークトラフィックを増加させ、サーバーのパフォーマンスを低下させ、重要なアカウントがロックアウトされた場合にダウンサイトをもたらすことさえあります。このポートへのアクセスを制限することにより、これらの問題が発生する前に軽減します。

SQLServerStandardまたはSQLServerWebエディションを実行しているサーバーの場合、サーバーからバックアップできるフラットファイルにライブデータベースファイルからデータをダンプし、ハードドライブがいっぱいにならないようにバックアップをクリーンアップするようにメンテナンスプランを構成することをお勧めします。

Windowsアップデート

Windows Updateが有効になっていることを確認し、サーバーの状態に注意してください。Windowsオペレーティングシステム(OS)にパッチが適用されていることを確認してください。北米で毎月第2火曜日に発生するパッチ火曜日は、Microsoftがセキュリティパッチを定期的にリリースする日です。お客様は、サーバーを最新の状態に保つパッチ適用戦略を実装するための最善の方法を決定する必要があります。デフォルトでは、RackspaceCloudServerは毎日午前2時から午前4時の間に更新をチェックします。

サーバーのバックアップ

ある種の災害復旧計画を立てます。私たちが提供するオプションの1つは、クラウドサーバーイメージを毎晩作成し、デフォルトで7日間保持してクラウドファイルコンテナーに書き込むことです。サーバーのスナップショットを作成し、新しいサーバーインスタンスの作成や、そのイメージからの既存のサーバーの再構築に使用するために、イメージをクラウドファイルに保存します。

また、クラウドバックアップによるファイルレベルのバックアップも提供しています。 C:全体をバックアップすることはお勧めしません ロックされているライブファイルが原因でバックアップジョブがエラーで完了するため、ドライブします。さらに、Windowsシステムファイルは、当社が提供するベースイメージまたはサーバーで取得されたカスタムイメージに含まれているため、そのデータを毎日バックアップする必要はありません。Cをバックアップすることをお勧めします。 :\ inetpub (IIS)ディレクトリおよびバックアップが必要なその他のユーザーデータ。さらに、バックアップ用にライブデータをフラットファイルにダンプするようにSQL Serverメンテナンスプランを構成した場合は、それらのディレクトリもバックアップに含めることをお勧めします。

>

バックアップジョブをチェックして、それらが正常に完了し、バックアップが有効であることを確認します。イメージから新しいサーバーインスタンスを作成してイメージが有効であることを確認し、Cloud Backupsからファイルを復元して、バックアップされたデータが復元されていることを確認します。

:すべてのサーバーがクラウドイメージの恩恵を受けることができるわけではありません。具体的には、ボリュームからの起動を使用するサーバーのイメージを作成することはできません。 構成。さらに、サーバーイメージは便利ですが、イメージプロセスはファイルの整合性を検証しないため、イメージを唯一のバックアップソースと見なしてはなりません。 Rackspaceは、最も重要なデータのファイルレベルのバックアップを強くお勧めします。したがって、ビジネスのディザスタリカバリに最適なソリューションを検討する必要があります。この記事では、サーバーイメージとクラウドバックアップの違いを確認できます:Rackspaceクラウドバックアップとクラウドサーバーイメージバックアップ

コード

インターネットにさらされる最後の攻撃対象領域はコードです。あなたとあなたの開発者は、あなたのコードが適切な認証と承認を実施していることを確認する必要があります。たとえば、管理者レベルの権限でWebアプリケーションを実行することを許可しないでください。ファイルの認証は慎重に定義する必要があり、ハッカーがWebアプリケーションを悪用してサーバーを制御するのを防ぐために、アプリケーションへのすべての入力は可能な限り最高の検証を行う必要があります。

次のサイトは、ASP.NETセキュリティの向上に関する情報を提供します。

  • https://www.asp.net/web-forms/pluralsight
  • https://www.iis.net/configreference/system.webserver/security/requestfiltering
  • https://blogs.iis.net/wadeh/archive/2008/12/18/filtering-for-sql-injection-on-iis-7-and-later.aspx
結論

ユースケースによっては、お客様がクラウドサーバーサービスを活用してホスティングのニーズを満たす場合に、他のより具体的なニーズに対処する必要がある場合があります。ただし、これらの一般的な推奨事項は、Windowsサーバー、クラウド、またはその他を作成する際のセキュリティを検討する際の良いスタートです。


Linux
  1. 最高のVPSは何ですか:WindowsまたはLinux?

  2. LinuxでのWordpressセキュリティのベストプラクティス

  3. Nagiosサーバーのベストプラクティス?

  1. ファイアウォールルール構成のベストプラクティス

  2. Linuxサーバーのセキュリティのベストプラクティス

  3. WindowsServer2012ファイアウォールを管理する

  1. セキュリティとパフォーマンスのためのDNSのベストプラクティス

  2. 6 Kubernetesセキュリティのベストプラクティス:ワークロードを保護する

  3. OpenSSHセキュリティのベストプラクティス