Linux の 302 (Mixed Environment) 試験対策: Samba セキュリティー

ファイアウォールとデーモン・レベルの両方で Samba をセキュアにする

システム管理者のための LPIC (Linux Professional Institute Certification) の LPI-302 試験に備えるために、Samba をセキュアに構成する方法と、Samba のセキュリティーに関する問題をトラブルシューティングする方法を学んでください。

Sean A. Walberg, Senior Network Engineer

Photo of Sean WalbergSean Walberg はネットワーク・エンジニアであり、ネットワークについて 2 冊の本も書いています。これまで医療やメディアをはじめ、さまざまな業界に携わってきました。



2012年 1月 27日

この連載について

この連載は Linux システム管理タスクの学習に役立つだけでなく、LPIC-3 (Linux Professional Institute Certification レベル 3) 試験に備えるための教材にもなります。

連載の各記事についての説明とリンクについては、developerWorks の LPIC-3 ロードマップを参照してください。現在進行中のこのロードマップは、LPIC-3 試験の最新の目標 (2010年 11月) を反映しています。完成した記事はその都度ロードマップに追加されていきます。

この記事では、以下の内容について学びます。

  • Samba サーバーへのアクセスと Samba サーバーからのアクセスに関する制御を、ファイアウォールを構成して行う方法
  • Samba サーバーでのファイアウォール問題をトラブルシューティングする方法

この記事は、LPIC-3 Specialty「302 Mixed Environment Exam」試験の主題 315 の目標 315.2 の試験対策となります。この目標の重要度は 2 です。

前提条件

この連載記事を最大限に活用するには、Linux の高度な知識と、この記事で説明するコマンドを演習できる実際の Linux システムが必要です。さらに、セキュリティー設定をテストするために使用できる Windows 環境にアクセスできることも必要となります。


ファイアウォール

選択的な LPI-302 試験について

LPIC (Linux Professional Institute Certification) には、さまざまなレベルがあり、レベルが上がるにつれ、より深い知識と経験が必要になってくるという点で、他の多くの認定と似ています。LPI-302 試験は、LPIC レベル階層のレベル 3 に位置する選択的な Specialty 認定試験であり、Linux システム管理に関する高度な知識が求められます。

LPIC レベル 3 (LPIC-3) 認定を取得するには、2 つのレベル 1 試験 (101 と 102)、2 つのレベル 2 試験 (201 と 202)、そして LPIC-3 Core Exam (301) に合格しなければなりません。これらの試験に合格した後、LPI-302 などの選択的な Specialty 認定試験を受けることができます。

Samba には、誰がどの共有にアクセスできるかを制限するための機能が数多くあります。具体的には、特定のユーザーだけにアクセスを制限する機能、パスワードの入力を強制する機能、グループ・メンバーシップをチェックする機能、ネットワーク・レベルでフィルタリングする機能などです。最後に挙げたフィルタリング機能のパラメーター (allow hostssmb ports など) が対象とするのは、IP アドレスと UDP (User Datagram Protocol)/TCP ポートであり、この方法はどのホストに対して Samba サーバーへの接続を許可するかを制御する簡単な手段となります。

ネットワーク・レベルで制御する場合には、サーバーに接続する機器 (内部ネットワークに属する機器、さらには特定のサブネットまたはサーバーのグループに属する機器など) を識別できる能力が求められます。ネットワーク・レベルの制御は防御の最前線であり、アタッカーが機器に接続できなければ、その機器の安全性は高くなります。

ネットワーク・アクセスの制御を Samba デーモン内で行うのは、完璧なソリューションのように聞こえるかもしれませんが、それよりも優れた方法があります。Samba は、接続要求があった場合にその接続処理を完了するまでは、その接続に関する詳細を入手できないため、要求のあったリモート接続が望ましい接続であるかどうかを判断するには、Samba がまず、その接続を許可しなければなりません。望ましくない人々が Samba に接続できないようにすることが狙いだとしたら、Samba がそのような接続を認識すらしないようにするのがより賢明な方法です。Samba 内部の構成は Samba にしか影響しません。したがって、Samba 内部での構成と同じようなソリューションを、Web サーバーやファイル転送などの他のデーモンにも見つける必要があります。

標準的な環境では、ネットワーク・セキュリティーを扱うのはシステム管理者ではなく、他の IT スタッフ・メンバーです。アプリケーション・レベルではなく、ホスト・レベルでアクセスを制御すれば、関心の分離がもたらされ、smb.conf の変更によって生じるエラーも減ることになります。

iptables について理解する

皆さん独自のフィードを作成してください

新しい記事が追加された際、あるいは内容が更新された際に通知を受けられるように、RSS、Atom、または HTML によるカスタム・フィードを作成することができます。それには、developerWorks RSS フィードにアクセスしてください。対象のゾーンとしては「Linux」を選択し、情報の種類としては「記事」を選択して、キーワードには「Linux Professional Institute」と入力します。そして最後にフィードの種類を選択します。

Linux は、iptables という堅牢なホスト・ベースのファイアウォールを提供しています。このファイアウォールは、Linux 機器で送受信されるパケットや、Linux 機器を経由するパケットを検査することができます。これは、iptables が Linux カーネル内部のパケット・フィルタリング・システムや、これらのフィルターを管理するためのコマンドを利用できるからです。カーネル内部のパケット・フィルタリング・システムはここ何年かの間で、当初の単純なマッチング・エンジンから、プラグインを動的にロードできる堅牢なファイアウォールへと成長しています。そのため、基本的な使用状況に当てはまらない場合には、構成するのが厄介な可能性があります。

iptables で何よりも重要な概念は、テーブルそのものの概念です。テーブルにはルールとアクションが包含されており、カーネルはパケットをフィルタリングするときには filter テーブルを参照し、NAT (Network Address Translation: ネットワーク・アドレス変換) が必要なときには nat テーブルを使用します。カーネルにロードされているネットワーク機能によっては、この 2 つ以外のテーブルも存在します。また、パケットが複数のテーブルに適用されることもあります。その一例は、アドレス変換の前にパケットをフィルタリングする場合です。

各テーブル内には、一連のチェーンがあります。テーブルごとに事前定義されたチェーンに加え、このリストにカスタム・チェーンを追加することもできます。事前定義されたチェーンは、それぞれパケットのライフサイクルのなかの異なる時点で使用されます。例えば、filter テーブルには以下の 3 つのチェーンが事前定義されています。

  • INPUT: そのホスト自身を宛先とするパケットの処理内容を判断するために使用されます。
  • OUTPUT: そのホストから送信されたパケットに適用されます。
  • FORWARD: あるインターフェースから別のインターフェースに渡されるパケットにのみ適用されます (そのホストがルーターとして機能している場合など)。

チェーンには、ルールを順番に記述することが可能な順序付きリストがあります。各ルールを構成するのは、マッチング節とターゲットです。マッチング節は、IP アドレスやポート、あるいは特定のアクションが頻繁に発生する場合にのみ有効になるレート制限文など、ほぼあらゆる内容にすることができます。ターゲットは、別のチェーンまたはアクション (パケットを許可あるいは破棄する命令など) にすることができます。マッチング節とターゲットは両方ともカーネル・モジュールを使用して作成できるため、可能性は無限です。

カーネルは、必要な処理内容を基準にチェーンを選択し、そのチェーンの各ルールを順番に調べます。そして、マッチするルールが最初に見つかった時点で、カーネルはターゲットにジャンプします。ほとんどの場合、そこでルール処理は終了しますが、一部のターゲット (例えばロギング) についてはルール処理を終了しないものとして、カーネルは次のルールの処理を続けます。一方、マッチするルールがない場合には、チェーンのデフォルト・ターゲットが使用されます。

注: この記事で説明する内容に必要となるのは、filter テーブルのみです。

Samba をファイアウォールで保護する

Samba のファイアウォール・ポリシーを設計するにはさまざまな方法があり、ポリシーの設定対象となる項目としてはネットワーク構成や、Samba サーバーにアクセスする必要があるユーザーまたは機器などがあります。大まかなポリシーとしては、ホスト全体を保護するか、Samba だけにフォーカスするかのいずれかを選択することができます。

ホスト全体を保護することにした場合、Samba がどのポートを使用しているかは問題になりません。以下のコードに、10.0.0.0/8 プライベート・ネットワークからローカル・サーバーへのトラフィックだけを許可する単純なポリシーを記載します。

iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P INPUT DROP

上記の最初のコマンドは、INPUT チェーンにルールを追加して、現行のルール・リストにルールを追加しています。追加したルールは、ソース・ネットワーク (-s) 10.0.0.0/8 からのあらゆるパケットが、パケットを許可する ACCEPT ターゲットに送られることを指定しています。2 番目のコマンドは、-m state を指定して状態の突き合わせを行う機能を呼び出すことで、既存のセッションでのパケットを許可しています。この突き合わせの機能は、そのホストから開始された接続を追跡するマッチャーです。そのホストからの接続に対する応答パケットは、ESTABLISHED (確立された接続に関するパケット) または RELATED (既存の接続に関係するパケット) と見なされ、このルールの残りの記述によって該当するパケットが許可されます。

最後のコマンドは、INPUT チェーンのデフォルト・ポリシーとしてパケットを破棄するポリシーを設定します。これにより、パケットが 10.0.0.0/8 ネットワークから送信されていない場合、またはそのホストが開始した接続に関係するパケットでない場合には、そのパケットは許可されません。

さらにフィルタリングの粒度を細かくするには、ポート・レベルでフィルタリングする方法を使えます。前の例では、ソース・アドレスを基準にフィルタリングすることから、すべてのサービスがブロックされてしまいます。通常のインターネットからアクセスできるように、ホスト上の Web サーバーをオープン状態のままにしておきたい場合には、前の例でのポリシーは使えません。

Linux の 302 (Mixed Environment) 試験対策: Samba を構成する」で説明したように、Samba は以下に挙げる 4 つの異なるポートを使用することを思い出してください。

  • 137 UDP: NetBIOS (Network Basic Input/Output System) ネーム・サービス
  • 138 UDP: NetBIOS データグラム・サービス
  • 139 TCP: NetBIOS セッション・サービス
  • 445 TCP: ダイレクト・ホスティング (CIFS (Common Internet File System) over TCP)

リスト 1 に記載するポリシーは、10.0.0.0/8 ネットワークから Samba サービスへの接続を許可し、さらに Web サーバーが制約を受けずに稼働できるようにします。

リスト 1. ポート・レベルで機能するポリシー
iptables -A INPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPT
iptables -A INPUT -p udp -s 10.0.0.0/8 --dport 137 -j ACCEPT
iptables -A INPUT -p udp -s 10.0.0.0/8 --dport 138 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -s 10.0.0.0/8 --dport 139 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -s 10.0.0.0/8 --dport 445 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P INPUT DROP

リスト 1 のポリシーは、いくつかの異なるアプリケーションにそれぞれ異なるポリシーを指定しているため、前のポリシーよりも複雑になっています。最初の 2 つのルールは、受信される TCP パケット (-p tcp) が新規セッションを構成する (-m state --state NEW) パケットとしてポート 80 またはポート 443 (--dport 80--dport 443) 宛てに送信されたものであるかどうかを調べます。ソース・アドレスには何の制限も設けられていないため、任意のユーザーからのこれらのパケットが許可されます。

次の 2 つのルールは、内部ネットワーク (-s 10.0.0.0/8) からポート 137 またはポート 138 (--dport 137--dport 138) 宛てに送信された UDP パケット (-p udp) であるかどうかを調べます。UDP はステートレスであるため、接続が新規の接続であるか、確立された接続であるかは関係なく、これらのパケットがすべて許可されます。

5 行目と 6 行目のルールは、パケットの状態を突き合わせる機能とソース・アドレス・フィルターを組み合わせ、内部ネットワークからポート 139 およびポート 445 宛ての新規接続パケットのみを許可します。

最後の 2 行は、前のポリシーの最後の 2 行と同じように機能します。つまり、パケットが現行の接続に関係する場合にはそのパケットを許可し、それ以外の場合には破棄します。


ファイアウォールの問題のトラブルシューティング

ファイアウォールの問題に突き当たることはよくあることで、その多くは想定外の要件に直面したり、アプリケーションが期待どおりに動作しないことが判明したりすることによるものです。ルール自体を誤って設定してしまうことは、よく起こりがちであり、特にポート番号と IP アドレスが数多く含まれるリストを扱っているときに多く起こります。ただし、すべての問題がファイアウォールに関連するわけではないため、基本的なネットワークのトラブルシューティング手順はやはり知っておく必要があります。

ポリシーを表示する

ポリシーを表示するには、iptables コマンドを使用します。-L オプションを指定するとポリシーが一覧表示され、詳細 (-v) オプションを指定すると、パケット・カウンターなどの詳細情報が追加されます。リスト 2 は、リスト 1 のポリシーを表示した場合の例です。

リスト 2. ポリシーの詳細表示
# iptables -L -v
Chain INPUT (policy DROP 47 packets, 5125 bytes)
 pkts bytes target  prot opt in   out  source      destination
    0     0 ACCEPT  tcp  --  any  any  anywhere    anywhere     state NEW tcp dpt:http
    0     0 ACCEPT  tcp  --  any  any  anywhere    anywhere     state NEW tcp dpt:https
    0     0 ACCEPT  udp  --  any  any  10.0.0.0/8  anywhere     udp dpt:netbios-ns
    0     0 ACCEPT  udp  --  any  any  10.0.0.0/8  anywhere     udp dpt:netbios-dgm
    0     0 ACCEPT  tcp  --  any  any  10.0.0.0/8  anywhere     state NEW tcp dpt:139
    0     0 ACCEPT  tcp  --  any  any  10.0.0.0/8  anywhere     state NEW tcp dpt:445
  214 15216 ACCEPT  all  --  any  any  anywhere    anywhere     state RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 292 packets, 35009 bytes)
 pkts bytes target     prot opt in     out     source               destination

詳細な統計では、最初の 2 列に、ルールにマッチしたパケット数およびバイト数が示されます。リスト 2 からは、パケットがマッチしたルールは最後のルールのみであることがわかります。出力の最初の行をよく見てみると、デフォルト・ターゲットにもパケット数が示されています。この数から、47 のパケットがルールにマッチしなかったために破棄されたことがわかります。これが意味するのは、許可されていないユーザーがマシンにアクセスしようとしたか、誤ったファイアウォール・ポリシーによって正規のトラフィックがブロックされたかのいずれかです。

ファイアウォール・ポリシーを表示するもう 1 つの目的は、ポリシー全体を理解することです。マッチするルールが見つかった時点でそのパケットをルールと突き合わせる処理は終了するため、ポリシーの先頭からルールを 1 つひとつ調べて、必要とするトラフィックを破棄しているルールがないかどうかを見極める必要があります。

よくありがちな問題の 1 つは、具体的なルールの前に、それより具体的ではないルールが記述されていることです。この問題を回避するには、最も具体的なルールをポリシーの先頭に配置し、例外がまず始めに処理されるようにしてください。ただし、この慣例に従ったからといって常に問題が解決されるとは限りません。サーバーに接続できないユーザーが出てくる可能性もあります。

リスト 3 に、Engineering ネットワーク内のサーバーに設定されたポリシーを記載します。このポリシーでは、同じネットワーク上のユーザーでもサービスに接続することができません。

リスト 3. 他のルールを無効にしてしまうルールが設定されたポリシー
# iptables -L -v
Chain INPUT (policy DROP 21 packets, 2967 bytes)
target   prot opt in   out  source       destination
ACCEPT   tcp  --  any  any  anywhere     anywhere      state NEW tcp dpt:http
ACCEPT   tcp  --  any  any  anywhere     anywhere      state NEW tcp dpt:https
DROP     tcp  --  any  any  10.0.0.0/8   anywhere
ACCEPT   udp  --  any  any  10.2.3.0/24  anywhere      udp dpt:netbios-ns
ACCEPT   udp  --  any  any  10.2.3.0/24  anywhere      udp dpt:netbios-dgm
ACCEPT   tcp  --  any  any  10.2.3.0/24  anywhere      state NEW tcp dpt:netbios-ssn
ACCEPT   tcp  --  any  any  10.2.3.0/24  anywhere      state NEW tcp dpt:microsoft-ds
ACCEPT   all  --  any  any  anywhere     anywhere      state RELATED,ESTABLISHED

リスト 3 のサーバーは、Engineering ネットワークに属します。このネットワークは 10.2.3.0/24 で、社内の他のネットワーク (10.0.0.0/8) からのアクセスはブロックされます。10.2.3.0/24 ネットワークは、それよりも大きいネットワークのサブネットとなっているため、10.0.0.0/8 ネットワーク全体をブロックするためのルールは、SMB (Server Message Block) 固有のルールの前に配置されています。しかし、iptables は最適なマッチではなく、最初のマッチという概念を適用するため、この配置により、Engineering ネットワークのユーザーまでもが DROP ルールの対象となってしまいます。

上記の問題に対する解決策は、具体的なルールが処理されてから、会社全体のネットワークがブロックされるようにすることです。このようにすれば、Engineering ネットワークに送信されるパケットがあらかじめ許可されるようになります。

高度なトラブルシューティング

多くの場合、問題の原因がファイアウォールにあるのか、それともネットワーの別の場所にあるのかは、あまりよくわかりません。それを判断するための最も単純なテストは、ファイアウォールを無効にして、接続が成功するかどうかを調べることです。けれども当然、ファイアウォールを無効にできない場合もあります。そのような場合に次善の策となるのは、サーバーに到着するパケットを監視することです。

tcpdump ユーティリティーは、ファイアウォールによって破棄されるパケットだとしても、サーバーが確認するネットワーク・パケットを表示します。サーバー側で接続試行があったことを確認できれば、そのパケットがサーバーまで到達していることがわかります。サービスが稼働中であることを前提とすれば、当然、サーバーに到達したパケットをファイアウォールが破棄していると結論付けることができます。リスト 4 に、tcpdump ユーティリティーを実際に使用した例を記載します。

リスト 4. ブロックされた SMB 接続のパケット追跡
# tcpdump -i eth0 tcp port 445
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:24:18.392106 IP CLIENT.search > SERVER.microsoft-ds: S ...
20:24:21.358458 IP CLIENT.search > SERVER.microsoft-ds: S ...
20:24:27.393604 IP CLIENT.search > SERVER.microsoft-ds: S ...

tcpdump には、以下のオプションを指定することができます。

  • -i eth0: eth0 インターフェースでリッスンします。
  • tcp port 445: TCP のポート 445 でパケットを監視します。

リスト 4 の結果には、3 つのパケットがサーバーに到達したことが示されています。矢印はパケットが送信される方向を示しており、これら 3 つのパケットはクライアントからサーバーの microsoft-ds ポート (445) へと送られていることになります。行の終わり近くにある S は接続試行を意味します。応答がないということは、サーバーが応答していないということです。

接続失敗を示すもう 1 つの兆候は、連続するパケット間の違いが次第に大きくなっていくことです。左側のタイム・スタンプから、最初のパケットが到着してから約 3秒後に 2 番目のパケットが到着し、3 番目のパケットはその 6 秒後に到着したことがわかります。ほとんどのネットワーク・プロトコルは指数バックオフを実装するため、試行間隔は毎回 2 倍ずつ長くなっていきます。

参考文献

学ぶために

  • smb.conf の man ページに、この記事で取り上げたコマンドのその他の例および詳しい説明が記載されています。
  • ファイアウォールは、リブートすると無効になります。Debian および Red Hat の Linux インストール済み環境でルール・セットを保存する方法を学んでください。
  • 常に最新の Samba セキュリティー・パッチを適応して、システムを最新の状態に維持してください。
  • LPIC サイトでは、LPI の 3 つの Linux システム管理資格認定レベルについて、詳しい目標、出題範囲、例題などを調べられます。特に、LPI-302 の詳細な目標について調べてください。
  • developerWorks の連載「LPI exam prep」をすべて読んで、Linux の基礎を学び、2009年 4月以前の LPI 試験の目標に基づくシステム管理者認定試験に備えてください。
  • developerWorks Linux ゾーンで、Linux 開発者および管理者向けのハウツー記事とチュートリアル、そしてダウンロード、ディスカッション、フォーラムなど、豊富に揃った資料を探してください。
  • さまざまな IBM 製品および IT 業界についての話題に絞った developerWorks の Technical events and webcasts で時代の流れをキャッチしてください。
  • 無料の developerWorks Live! briefing に参加して、IBM の製品およびツール、そして IT 業界の傾向を素早く学んでください。
  • developerWorks の on-demand demos で、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
  • Twitter で developerWorks をフォローするか、developerWorks で Linux に関するツイートのフィードに登録してください。

製品や技術を入手するために

  • Firewall Builder は、iptables ルールを簡単に管理できるようにする、グラフィカル・ファイアウォール・ポリシー・マネージャーです。
  • iptables のホーム・ページは、Netfilter.org です。このホーム・ページにアクセスして、さまざまな資料およびファイアウォールの機能を拡張できるモジュールのリストを調べてください。
  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=788420
ArticleTitle=Linux の 302 (Mixed Environment) 試験対策: Samba セキュリティー
publish-date=01272012