LinuxはMS Windowsよりも安全なシステムであると考えられているという事実にもかかわらず、この事実だけでは十分ではありません。

したがって、Linuxファミリの基本的なセキュリティ構成についてお話したいと思います。 この記事は初心者のLinux管理者を対象としていますが、経験豊富な専門家はおそらく自分にとって興味深いことを学ぶでしょう。 テキストには、段階的な手順は含まれません。技術と方法の基本的な説明、およびいくつかの個人的な推奨事項のみが含まれます。

ナットを締め始める場所

最初の最も重要な推奨事項は、インターネット上の指示にもっと注意することです。 残念なことに、これらの指示には有害な情報ではないにしても関連性のない情報が含まれていることが多く、これが行われる理由を説明し、そうでない場合は説明しません。 自分が何をしているかを常に正確に理解する必要があります。 コンソールへのコマンドのコピーは完全に危険です。

原則として、ほとんどの製品はかなり適切に文書化されており、公式の情報源から情報を取得するのが最適です。

ネットワーク上では、 rootとしては機能しないという推奨事項がよくあります。これは、すべてに対する完全な権限を持つスーパーユーザーです。 部分的には、推奨事項は正しいです。 ルートとして作業することは 、起こりうるエラーの致命性とパスワード傍受の危険性の観点から安全ではありません。

実際に年に2、3回サーバーで作業し、同時に構成の更新またはマイナーな編集に主に関与しているため、ルート権限の操作はsudoを使用した一時的な特権エスカレーションに似ています。 しかし、いくつかの合理的な予防策はまだ痛くないでしょう：

• 理想的には、サーバーのログインをキーで構成します 。

  
  

• 信頼できないマシンではスーパーユーザーのパスワードを入力しないでください

  
  
• 単純なパスワードまたは辞書パスワードを使用しないでください。 rootユーザーの名前を変更することもできますが、最初にテスト環境で結果を確認することをお勧めします。

更新プログラムのインストールは間違いなく必要で便利です。 崩壊につながった個々のパッケージとオペレーティングシステムの両方を更新していたのは、今だけです。 したがって、常に更新の前に、動作中のサーバーのコピーでインストールをチェックする価値があります。

ファイルシステムの保護

複数のユーザーまたは異なるアカウントで実行されているいくつかのサービスがサーバー上で実行されている場合、ファイルシステムへのアクセス権を分割し、何かが発生した場合に影響を受ける領域を絞り込むのが適切です。

各ディストリビューションは、いわゆる選択的アクセスシステムを使用します。 たとえば、ユーザーがファイルを開くことができるかどうかは、アクセス制御リスト（ACL）によってチェックされます。このチェックマークは、このユーザーに対して有効になっています。

セキュリティを確保するための良い原則は、仕事に本当に必要な権利のみを付与することです。

特に、Linuxシステムでは、ファイルに対して次のアクセスメカニズムが使用されます。

• 各オブジェクトには3つのアクセスパラメータがあります-所有者、所有者が含まれるユーザーグループ、およびその他すべてのユーザー。

  
  
• 各パラメーターは3つの値の組み合わせを取ることができます-読み取り、変更、実行が可能です。

アクセス権は数値形式で便利に表されます。 番号は3桁で、単純なスキームに従って計算されます。

したがって、オブジェクトに対するすべての完全な権利の権利は次のようになります。（400 + 200 + 100）+（40 + 20 + 10）+（4 + 2 + 1）=777。このような権利は、原則として、決して必要ではありません。デバッグ中にのみ公開することは許可されていません。

このアクセスメカニズムは、UGO（User-Group-Others）と呼ばれることもあります。

関連する資料でアクセス権とその操作の詳細を確認できます。

もちろん、このようなアクセスメカニズムは必ずしも便利ではありません。 たとえば、特定のオブジェクトに対するユーザー権限を付与する必要がある場合は、そのオブジェクトをグループに追加するか、新しいオブジェクトを作成する必要があります。 そのため、UNIXシステムでは、ACLと呼ばれるわずかに洗練されたアクセスメカニズムが追加されました。 すでにより柔軟で複雑なアクセスリストをサポートしています。

デフォルトでは、このシステムは無効になっています。 有効にするには、 aclオプションを使用してハードドライブをマウントする必要があります。 たとえば、/ etc / fstabにマウントオプションを追加して、ルートパーティションのaclを有効にします。

これで、システムは拡張ACLをサポートして起動します。

setfaclコマンドを使用して、アクセスリストを管理できるようになりました。 現在の権限を表示-getfacl 。

詳細についてはドキュメントを参照してください。たとえば、ファイルtest.txtでユーザーuserにフルアクセス権を付与します。

ユーザーuserに完全な権限を付与します。

保護メカニズムは非常にシンプルで効果的で、NTFSファイルシステムのACLに似ています。

アウトバーンの防火壁

サーバーへのアクセスを保護するための主なメカニズムは、伝統的にファイアウォールです。 GNU \ Linuxシステムでは、カーネルに組み込まれたnetfilterがこれに使用されます。

iptablesユーティリティは、ほとんどの場合、ファイアウォールを制御するために使用されます。 十分な資料がありますので、一般的な推奨事項に限定します。許可されていないものはすべてブロックします。 そして、許可されるものは可能な限り制限されます。

たとえば、サーバーへのSSHアクセスが特定の外部アドレスからのみ必要な場合、それらからのアクセスのみを許可します。

ただし、iptablesを使用することは、パケットパスを深く理解する必要があるため、必ずしも便利ではありません。 Ubuntuシステムのufwなどの他のユーティリティは、多くの場合、代替手段として使用されます。

たとえば、ufwを使用してsshアクセスを提供するには、次のコマンドを実行します。

ufw allow from 1.2.3.4 to any port 22 

iptablesについても同じことがもっと面倒に見えます。 着信トラフィックを許可する：

 iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 -j ACCEPT 

次に、応答トラフィックを許可します。

 iptables -A OUTPUT -p tcp --sport 22 -d 1.2.3.4 -j ACCEPT 

多くの場合、着信トラフィックとリターントラフィックの2つの明示的なルールを作成する代わりに、確立された接続（ESTABLISHED）と関連する接続（RELATED）のトラフィックを許可するだけです。 これを行うには、以下のコマンドを使用して、すべてのESTABLISHEDおよびRELATED接続を許可するだけで十分です。

 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 

CentOS、Fedora、Red Hatなどの最新のRPMディストリビューションでは、 firewalldデーモンがiptablesの代替として使用されます。 通常のメカニズムとは異なり、リストをリロードせずに外出先でルールを適用できるほか、ゾーン（ネットワーク接続の信頼レベル）を操作できます。 Windowsの組み込みファイアウォールに少し似ています。 確かに、iptablesの後に使用するのは少し珍しく、多くの場合、システム管理者は複雑ではあるが使い慣れたiptablesを返すことを好みます。

ファイアウォールと連携して、 fail2banなどのメカニズムは密接に機能し、次のことを行います。

• sshやftpなどのサービスのログを監視します。

  
  
• 同じIPアドレスからのユーザー名とパスワードが正しくない接続が多すぎる場合、しばらくの間、このIPをファイアウォールでブロックします。 突然それは総当たりです。

fail2banのセットアップの詳細については、 公式Wikiを参照してください。

NSAのガード

SELinuxは、強制アクセス制御システムの追加メカニズムです。 従来のポーリングとは異なり、アクセスはACLではなく特別なポリシーに基づいています。

短所ACLベースのアクセスシステム：

• サーバーユーザーは自分のファイルへのアクセスを提供できます-たとえば、秘密鍵;

  
  
• プロセスはユーザーの権利を継承し、ファイルのアクセス許可を変更できます。たとえば、侵害されたブラウザーはメール通信にアクセスできます。

1998年にNSA（米国国家安全保障局）とRed Hatによって作成されたこれらの欠点をなくすことができます。 Linuxシステムのカーネルでは、この技術が長い間存在していました。 それにもかかわらず、いくつかの指示では、それをオフにすることが頻繁に推奨されていますが、常にそうであるとは限りません。 SELinuxの詳細については、Habréに関する専門記事をご覧ください 。したがって、私は小さな教育プログラムに限定されます。

SELinuxには3つの動作モードがあります。

• 強制する。 デフォルトの動作モードでは、すべての不正なアクションがブロックされます。

  
  

• 寛容。 すべての不正なアクションは実行されますが、ログに記録されます。

  
  
• 無効。 SELinuxは無効です。

getenforceコマンドで現在の動作モードを確認できます; setenforceコマンドで強制モードと許容モードを切り替えることができます。 SELinuxをシャットダウンするには、再起動が必要です。

保護メカニズムは、古典的なメカニズムの後に適用され、オブジェクトの特別なマーキングに基づいています。 次のコマンドで現在のマーキングを表示できます。

 ls -Z 

新しく作成したファイルのマーキングを確認します。

構成の例として、サイトをデフォルト以外のフォルダーに配置し、Webサーバーを別のポートに「ハング」させたい状況を分析します。 httpd.conf構成ファイルの値を変更するだけでは十分ではないため、Webサーバーにフォルダーとポートへのアクセス権を与える必要があることをSELinuxに伝える必要があります。 これを行うには、以下を行う必要があります。

• policycoreutils-python管理パッケージをインストールします

  
  

• コマンドでフォルダーをマークすることについてシステムに指示します。

  
  

   semanage fcontext -a -t httpd_sys_content_t "/path/to/www(/.*)?" semanage fcontext -a -t httpd_sys_rw_content_t "/path/to/www(/.*)?" 

  
  

• 次のコマンドでマーキングを復元します。

  
  

   restorecon -R /path/to/www 

  
  
• ポートへのアクセスを許可します。

 semanage port -a -t http_port_t -p tcp 81 

もちろん、これをすべて実行する前に、SELinuxを詳しく理解することをお勧めします。

ソリューションとしてのSELinuxはユニークではありません。 2番目に人気のあるセキュリティメカニズムはAppArmorです。 開発は当初Novellによって監督されていましたが、このツールは将来性のないものとして放棄されました。 ただし、 Canonicalは現在AppArmorに取り組んでおり、製品はUbuntuシステムと密接に関連しています。 違いについては、多くの既製のポリシーがあるため、AppArmorはSELinuxよりも便利です。

また、ユーザーアクションがジャーナルに記録されるがブロックされないトレーニングメカニズムもあります。これにより、「パイロット」として新しい防御を開始し、すぐに欠陥を取り除くことができます。 SELinuxでこのモードがシステム全体で有効になっている場合、AppArmorを使用して特定のアプリケーションに対して有効にすることができます。 この目的の例：

 aa-complain /path/to/bin 

AppArmorとSELinuxの主な違いは、AppArmorはポリシーをパスにバインドし、SELinuxはファイル記述子に依存することです。 ファイルの実行をブロックしてから移動すると、AppArmorはファイルの起動を許可しますが、SELinuxは許可しません。

ファイルが元のパスで上書きされると、AppArmorはそれをブロックし、SELinuxは実行を許可します。 これらの誤解は、「明示的に許可されたもの以外をすべてブロックする」ポリシーを含めることで回避できます。

要するに、SELinux開発者は使いやすさではなく、セキュリティに焦点を合わせました。 AppArmorでは、すべてが正反対です。 AppArmorの詳細については、メーカーのドキュメントまたはUbuntuライブラリをご覧ください。

残念ながら、何を選択するかについて明確なアドバイスをすることはできません。これは、OSディストリビューションの優先順位と好みの問題だからです。 CentosとRed HatのファンはSELinuxを選択する可能性が高く、Ubuntu愛好家はAppArmorを選択します。

ところで、どのメカニズムを好むのかコメントに書いてください。

念のためマスターキーのセット

このセクションでは、サーバーを保護するための必須のメカニズムではなく、必須のメカニズムについて説明します。

端末へのルート接続を拒否する

GNU \ Linuxシステムでは、rootユーザーが接続できる端末のリストを制限できます。 これは、 / etc / securettyファイルを変更することで実行できます。 ファイルが空の場合、rootは直接接続できず、完全な権限を取得するにはsuまたはsudoが必要です。

パスワードポリシー

また、次のコマンドでパスワードの有効期間を設定すると便利な場合があります。

 chage -M 20 username 

20はパスワードの経過日数です。 別のオプションは、/ etc / login.defsファイルの一般的なパスワードポリシーを変更することです。 パスワードを20日ごとに変更し、ユーザーが5日間このことに関するリマインダーを受信するとします。 次に、ファイルの内容は次のようになります。

 PASS_MAX_DAYS 20 PASS_MIN_DAYS 0 PASS_WARN_AGE 5 

もう1つの便利な機能は、パスワードの複雑さのポリシーです。 このために、 pam_cracklibモジュールが使用されます。 たとえば、パスワードに少なくとも1つの大文字、少なくとも1つの小文字、少なくとも1つの数字、およびパスワード自体の長さを少なくとも8文字にする必要がある場合、行を追加すると役立ちます。

 password required pam_cracklib.so minlen=8 lcredit=1 ucredit=1 dcredit=1 

ファイル/etc/pam.d/system-authに。

権利通知

もう1つの必要なオプションは、スーパーユーザー権限へのアクセスを制御するための各sudoエントリの通知です。 これを行うには、 / etc / sudoersファイルに次の行を追加するだけです。

 mailto [admin@domain.com](mailto:admin@domain.com) mail_always on 

もちろん、システムにメール送信エージェントを設定する必要があります。 標準のsendmailを置き換えるのに適したオプションはssmtpです 。これは、無料のメールサービスでもメールを送信して簡単に友達を作ることができます。

コンパイラーの非アクティブ化

悪意のあるソフトウェアのコンパイルと起動を回避するために、ユーザーが使用するためにサーバー上のコンパイラを無効にする必要はありません。

 rpm -q --filesbypkg gcc | grep 'bin' 

 groupadd compilerGroup 

 chown root:compilerGroup /usr/bin/gcc 

 chmod 0750 /usr/bin/gcc 

構成ファイルの耐性

スーパーユーザーからでもシステムファイルと構成を保護する良い方法は、耐性の属性です。 それを使用するには、 chattr + i filenameコマンドを使用します。

ルートでも免疫ファイルを削除することはできません。

この属性を削除するには、単にchattr -i filenameコマンドを実行します。

各管理者には、サーバーセキュリティに関する独自のベストプラクティスがあると思います。 コメントでそれらを同僚と共有することをお勧めします。