Webサーバーのメンテナンスとセキュリティ管理のスキル3

まず、ロールを変更し、自分自身を攻撃者の可能性があると見なします。

ほとんどの場合、Web管理者の観点から問題を検討するだけでは、Webサーバーの脆弱性を見つけられない場合があります。反対に、現時点で角度を変えて自分自身を攻撃者として扱うことができるのであれば、その手段と攻撃するWebサーバーの脆弱性を利用する必要があります。セキュリティの脆弱性が存在する可能性があるため、できるだけ早く、セキュリティの脆弱性を修正し、トロイの木馬やウイルスによる攻撃を防止してください。

社外から自分のWebサーバーにアクセスし、完全なテストを実行してから、自分のWebサイトへの攻撃をシミュレートして何が起こるかを確認します。これはWEBセキュリティのための良い方法かもしれません。攻撃者になる可能性がある場合は、スキャンツールを使用してWebサーバーをスキャンし、攻撃される可能性があるサービスがないかどうかを確認します。注意を払わないかもしれないものもありますが、ハッカーがスキャンに一般的に使用するツールを使用すると、それらによって悪用される可能性のあるサービスや脆弱性が見つかります。たとえば、サーバーのインストール時にオペレーティングシステムがデフォルトで不要なサービスをインストールして起動したり、サーバーの設定時に一部のサービスを起動する必要がありますが、間に合わないために攻撃者に攻撃の機会が与えられます。 。最も一般的なものはSNMPサービスで、簡易ネットワーク管理プロトコルとも呼ばれます。このサービスは、システムのインストール後にデフォルトで有効になります。ただし、このサービスは、Webサーバーで使用されているオペレーティングシステム、サーバー上で開かれているサービスおよび対応するポートなど、サーバーシステムに関する詳細情報を攻撃者に提供する可能性があります。攻撃者は、最も基本的な情報を理解している場合にのみ攻撃を仕掛けることができます。 //この記事はwww.45it.comから転送されてきました。コンピュータソフトウェアとハ​​ードウェアアプリケーションネットワーク

セキュリティ管理スタッフは、この問題を安心して見つけることはできませんが、ハッカーのスキャンツールを使ってスキャンできれば、問題がどこにあるか調べなさい。したがって、必要に応じて、攻撃の役割から角度を変更し、それらがどのような攻撃方法を使用するかを検討する必要があります。このようにして、私たちは「権威ファン」の過ちを避け、Webサーバーのセキュリティを確保することができます。

第二に、合理的な権利管理

時には、サーバー上で、Webサーバーを実行するだけでなく、FTPサーバーなどの他のネットワークサービスも実行します。同じサーバーに複数のネットワークサービスを適用すると、サービス間で相互感染が発生する可能性があります。つまり、攻撃者は他のサービスを攻撃し、関連技術を使用して他のアプリケーションを危険にさらす可能性があります。攻撃者はいずれかのサービスを突破する必要があるため、このサービスプラットフォームを使用して企業内から他のサービスを攻撃することができます。一般に、企業コンテンツからの攻撃は、企業外からの攻撃よりもはるかに便利です。

そうすると、サービスによってサービスが異なると言う人がいるかもしれません。実際、これは企業にとって無駄になる可能性があります。パフォーマンスの面では、現在のサーバーにWebサービスとFTPサービスを展開することは完全に可能であり、パフォーマンスには影響しません。この目的のために、企業はコストの観点からサーバーを利用します。現在、セキュリティ管理者に問題がありますが、1つのサーバーに複数のサービスを同時に展開することは可能ですか。 P>たとえば、現在のWebサーバーでは3つのサービスが実行されています。 1つは従来のWebサービス、もう1つはFTPサービス、3つ目はOA（オフィスオートメーション）サービスです。これはサービスがWEBモードであり、インターネットからもOAサーバーに直接アクセスできるため、このサーバーに展開されます。このサーバーの構成はまだ比較的高いので、これら3つのサービスを実行することに多くの困難はありません、そしてパフォーマンスは影響を受けません。問題は、セキュリティを保護するために、FTPサーバー、OAサーバー、およびWebサーバー間のセキュリティが互いに影響を及ぼさないことです。
このセキュリティ要件を達成するために、Windows 2003サーバーが使用されるようになりました。サーバー内のすべてのハードディスクをNTFSパーティションに変換します。一般に、NTFSパーティションはFATパーティションよりはるかに安全です。 NTFSパーティションに付属の機能を使って、それらに適切な権限を割り当てるのが妥当です。たとえば、3つのサーバーに対して異なる管理者アカウントが設定されており、異なるアカウントは特定のパーティションとディレクトリにしかアクセスできません。この場合、管理者アカウントが侵害されても、1つのサービスの記憶域スペースにしかアクセスできず、他のサービスにはアクセスできません。たとえば、WEBサービスはパーティションDにロードされ、FTPサービスはパーティションEに配置されます。 FTPアカウントが漏えいした場合、攻撃に悪用されますが、FTPアカウントにはパーティションDに対する読み書きの権限がないため、Webサーバー上のコンテンツに対して読み書きを実行することはできません。これは保証できます、そしてそれはそれがFTPサーバによって危殆化された後にWebサーバに悪影響を及ぼさないでしょう。

Microsoftのオペレーティングシステムは高価で、より多くのセキュリティ上の脆弱性がありますが、NTFSパーティション上でのその成果は悪くありません。 NTFSパーティションでは、関連サービスのセキュリティを確保するために、高度なセキュリティ管理を実現できます。そのため、結局、Microsoftの2003オペレーティングシステムがサーバーシステムとして採用されましたが、Linuxシステムは採用されませんでした。

3番目に、スクリプトのセキュリティ管理

過去の経験によると、実際、多くのWebサーバーは攻撃のために攻撃されており、悪いスクリプトによって引き起こされています。特に、攻撃者はCGIプログラムやPHPスクリプトを使用して自分のスクリプトやバグを悪用します。

一般に、Webアプリケーションは、正常にアクセスできるようにするためにいくつかの必要なパラメータを渡す必要があります。そして、このパラメーターは2つのカテゴリーに分けられます。1つは信頼できるパラメーターであり、もう1つは信頼できないパラメーターです。たとえば、企業は、Webサーバーをホストするのではなく、独自のWebサーバーを管理することがあります。 Webサーバーのセキュリティを強化するために、サーバーを企業のファイアウォールの内側に配置します。そのため、一般に、企業のファイアウォールの内側からのパラメータは信頼でき、信頼できます;企業の外側からのパラメータは信頼できません。ただし、信頼できないパラメータや、ファイアウォールの外側にあるWebサーバが使用されていないというパラメータではありません。そうではなく、Webサーバーを設計するときには、これらの信頼できないパラメーターを使用するときには、3つの21から21にかかわらず、企業内のパラメーターではなく、それが正しいかどうかを確認する必要があります。それらはすべて世話をされています。これは明らかにWebサーバーのセキュリティを脅かします。このような場合、攻撃者はTELNETを使ってポート80に接続し、危険なパラメータをCGLスクリプトに渡すことができます。

それで、CGIプログラムやPHPスクリプトを書くとき、私たちはそれに注意を払わなければなりません、私たちは彼らに見知らぬ人のパラメータを受け入れさせてはいけませんし、見知らぬ人を扱ってはいけません。パラメータを受け入れる前に、パラメータを提供している人またはパラメータ自体の合法性を必ず確認してください。プログラムやスクリプトを書くときには、あらかじめいくつかの判定条件を追加することができます。提供されたパラメーターが正しくないとサービス期間が判断した場合は、間に合って管理者に連絡してください。これはまた、可能な限り早く攻撃者を検出し、適切な対策を講じるのに役立ちます。

スクリプトのセキュリティについては、以下の点に注意してください。

1.スクリプトやプログラムを書くときは、信頼できないパラメータを直接セッション変数として保存しないでください。セッション変数はWEBアプリケーションの設計原則に従って信頼変数のみを保存するためです。つまり、セッション変数の値は、WEBサービスはそれが信頼できると考え、考えずに使用されます。一般的な設計思想は、最初に一時変数を格納用に設定してから、その正当性を検証するプロシージャまたは関数を作成してその正当性を検証することです。この値は、検証に合格したときにのみセッション変数に渡すことができます。経験によれば、あなたがWEB管理者の苦痛なレッスンを経験していないならば、あなたはこれを却下するかもしれません。ただし、このレッスンを受けたことのある人は、この合法性のプロセスを重視します。結局のところ、それは長期的な知恵なので、初心者はまだやって来る人々のアドバイスに耳を傾ける必要があり、苦しむことはありません。

2.必要がないときは、ページをできるだけ単純にするためにスクリプトを使用しないでください。実際、会社のWebサイトは個人用Webサイトとは大きく異なり、会社のWebサイトはそれほど単純ではなく、あまりレンダリングを必要としません。一方では、レンダリングが過剰なWebサイトはユーザーサイトへのアクセス速度を低下させる可能性があり、他方ではネットワークのセキュリティも低下させます。したがって、十分な必要性がない場合は、サイトの派手な機能をレンダリングする際にスクリプトやプログラムを共有しないでください。

3.スクリプトやプログラムの実行を継続的に追跡します。 Webサイトやスクリプトが最後の手段として使用される場合、それらが違法に悪用された疑いがあるかどうかを確認するために、これらのスクリプトやプログラムの動作を時々監査する必要があります。