いますぐ実践! Linuxシステム管理

[バックナンバーのトップへ] [Linux システム管理のトップへ]


いますぐ実践! Linux システム管理 / Vol.067 / 読者数:861名

こんばんは、うすだです。

よく考えると当たり前なのですが、最近、とある傾向に気づきました。
それは、

  発行しない方が、読者数が増加する。

ということです。(先々週がまさにそうでした。)

読者さんの目につく頻度が高ければ高いほど、解除される可能性が高まりますので、 上記の傾向が存在するのは、しかたがないかなと思います。

でも、やっぱり、がんばって毎週出し続けるより、 どきどきさぼった方が読者数が増えるというのは、なにかやりきれないものがあります。

 

というわけで、来週からは、2週間に1回に変更します。

 

…と宣言するつもりでしたが、それもつまんないので、あまのじゃくな私は、 これからも週1回ペースを維持したいと思います。

…結局、何も言ってませんが、今週も、はりきってまいりますわよ!

今週のお題 - プチ・パケットフィルタリング

栗日記やシス管のサーバが、最近、専用サーバになりました。
以前は、ひとんちにサーバを置かせてもらい、 サーバとインターネットの間にファイアウォールを設置していたのですが、 ファイアウォールのない構成になってしまいました。

時には命をも奪う広大な海に、ぽつねんと放り出されたかのように、 広大なインターネットに、専用サーバがたったひとりで存在してるわけです。

今までは、母なるファイアウォールマシンが、 世間のいろんな攻撃を防御してくれましたが、これからは一人立ちして、 自分の身を自分で守る必要が出てきましたわけですね。

しかし、突然、がちがちに固めて、 最小限しか通さないわよっていう設定を行いますと、 うっかり大事なパケットをも落す設定にしてしまった!!! …なんていう困ったことにもなりかねません。

そんなわけで、今週は、ちょこっとパケットフィルタリングを設定して、 自分の身を徐々に守っていく方法について、ご紹介したいと思います。


今回は、iptables を使用しますが、ディストリビューションによっては、 インストール時に、がちがちな設定をしてくださることもあるようです。

しかし、ここでは、何も設定されていない、フリーダムな状態であることを前提に、 お話をさせていただきたいと思います。
具体的には、以下のような、何も設定されていなくて、 ポリシーがみんな ACCEPT という、ウェルカムな状態を前提とします。

  # iptables -L
  Chain INPUT (policy ACCEPT)
  target     prot opt source               destination         

  Chain FORWARD (policy ACCEPT)
  target     prot opt source               destination         

  Chain OUTPUT (policy ACCEPT)
  target     prot opt source               destination

もしそうなっていなくて、みんなが使っている大事なサーバマシンであるなら、 今回は読むだけにしておいたほうが無難ではないかと思います。

安全な場所にあって、 勝手に設定してもだれも困らない Linux マシンを使用されている貴兄は、 下記を実行してフリーダムな状態にして、実際に試していただければと存じます。

  # iptables -F
  # iptables -P INPUT ACCEPT
  # iptables -P FORWARD ACCEPT
  # iptables -P OUTPUT ACCEPT

ではまず、特定のポート宛のパケットを、閉じてみようと思います。

ここでは、別のマシンから ftp へのアクセスをできなくしてみます。
以下を実行すると、ftp へのアクセスをシャットアウトします。

  # iptables -A INPUT -p tcp --dport ftp -j DROP

これは、TCP の ftp 宛(TCP のポート番号 21 番)のパケットを DROP する設定を、 INPUT に追加しています。
つまり、自分に届いた ftp 宛のパケットを捨てる、という設定です。

上記を実行すると、別のマシンからの ftp を拒否できます。
別のマシンから、設定したマシンに対して ftp を実行しても、下記のように、 しばらーくしてから Connection timed out と言われます。

  % ftp そのマシン
  ftp: connect: Connection timed out
  ftp>

次は、出ていくほうに対して、設定をしてみましょう。

たとえば、社外にメールを送信したいときに、 自力で MX を参照して直接メールサーバに送信するのではなく、 一旦 192.168.1.1 へ送る必要があるとします。
つまり、192.168.1.1 以外のマシンへ、SMTP で接続してはいけない、 という決まりがあるとします。
(Outbound Port25 Blocking というやつですね。(たぶん))

…という設定は、以下を実行するとできます。

  # iptables -A OUTPUT -p tcp --dport smtp -d ! 192.168.1.1 -j DROP

これは、宛先が 192.168.1.1 以外の、 TCP の smtp 宛(TCP のポート番号 25 番)のパケットを DROP する設定を、 OUTPUT に追加しています。
つまり、smtp 宛のパケットで、宛先が 192.168.1.1 以外のパケットを、 捨ててしまうという設定です。

上記を実行すると、そのマシンから 192.168.1.1 以外のマシンへの、 smtp への接続が行えなくなります。
実際にそのマシン上で、telnet コマンドで確認してみますと、下記のように、 Trying 云々と出力されてからしばらーくして、Connection timed out と言われます。

  % telnet smtp.usupi.org smtp
  Trying 59.106.23.151...
  telnet: connect to address 59.106.23.151: Connection timed out

以上、送受信双方の設定について、簡単にご紹介しました。
でも、ほんとに設定できているのかが、すこし気になりますよね。
設定できているかどうかを確認するために、ログに出力してみましょう。

まず、drop_log という名の新しいチェインを作成して、すべてのパケットに対して、 LOG と DROP を行うようにします。

  # iptables -N drop_log
  # iptables -A drop_log -j LOG
  # iptables -A drop_log -j DROP

そして、先ほどと同じ設定を追加するときに、DROP の代わりに、 新たに作成した drop_log を指定します。
たとえば、ftp へのアクセスを拒否する場合は、以下を実行します。

  # iptables -A INPUT -p tcp --dport ftp -j drop_log

そして、実際に ftp へのアクセスがあると、以下のようなメッセージが、 /var/log/messages などに記録されます。

  IN=eth0 OUT= MAC=00:d0:59:ca:59:40:00:60:08:b6:26:7f:08:00 \
  SRC=192.168.1.11 DST=192.168.1.10 LEN=60 TOS=0x00 PREC=0x00 \
  TTL=64 ID=33092 DF PROTO=TCP SPT=1054 DPT=21 WINDOW=5840 RES=0x00 \
  SYN URGP=0

これで、拒否する設定が有効に機能していることがわかります。


以上、ちょこっとパケットフィルタリングの方法を、ご紹介しました。

とはいえ、itables の説明を一切せず、 ひたすら設定例のご紹介に徹してしまいました。 ですので、上記を実行して雰囲気をつかんだら、 ちゃんと iptables のお勉強をして、安全な設定に進化させてください。

ちなみに、iptables の基本的な使い方は、以下にも少しだけあります。
(設定の参照や追加・削除・保存の方法が、さらっと書いてあります。)

Vol.065 - お試しネットワーク環境を作る
http://www.usupi.org/sysad/065.html

宿題の答え

先週の宿題は、

  Proxy ARP を使用したときの、お試し LAN 上のパケットと、社内 LAN
  上のパケットを、観察してみましょう。

でした。

今回は、 外側のマシン 192.168.1.254 から内側のマシン 192.168.1.11 へ ping したところを、 眺めてみたいと思います。
構成は、前回と同様ですが、両端にマシンを追加しています。

         社内 LAN                                  お試し LAN
  +-+----------------+-+                    +-+----------------+-+
    | 192.168.1.0/24 |                        | 192.168.1.0/28 |
    |                +-----[Linux マシン]-----+                |
    |     192.168.1.55(eth0)            192.168.1.1(eth1)      |
    |                                                          |
    |192.168.1.254                                192.168.1.11 |
  [外側のマシン]                                    [内側のマシン]

この構成で、外側のマシンから、

  # ping 192.168.1.11

を実行したときの、Linux マシン上での eth0 と eth1 のパケットの流れを、 tcpdump で確認してみました。
まずは、社内 LAN 側(eth0 側)の結果を、以下に示します。

  # tcpdump -i eth0 -n host 192.168.1.11
  tcpdump: listening on eth0
  21:27:57.088568 arp who-has 192.168.1.11 tell 192.168.1.254
  21:27:57.208568 arp reply 192.168.1.11 is-at 0:90:99:7f:8d:a7
  21:27:57.208568 192.168.1.254 > 192.168.1.11: icmp: echo request
  21:27:57.208568 192.168.1.11 > 192.168.1.254: icmp: echo reply

最初に、外側のマシンが、 192.168.1.11 の MAC アドレスを問い合わせる ARP 要求をブロードキャストします。 なぜなら、外側のマシンは、 内側のマシンが同じサブネット内にいると思っているからです。

そして、その ARP 要求に対して、192.168.1.55 が ARP 応答を返します。
(だから Proxy ARP と言うんですね。)
実際、外側のマシン上で arp コマンドを実行しますと、 どちらも同じ MAC アドレスになっています。

  # arp -an
  ? (192.168.1.55) at 00:90:99:7f:8d:a7 [ether] on eth0
  ? (192.168.1.11) at 00:90:99:7f:8d:a7 [ether] on eth0

ちなみに、Proxy ARP は、存在しないマシンを問い合わせる ARP 要求にも、 律義に答えます。
以下では、192.168.1.7 は存在しませんが、オレオレって言ってます。

  21:44:12.262568 arp who-has 192.168.1.7 tell 192.168.1.254
  21:44:12.402568 arp reply 192.168.1.7 is-at 0:90:99:7f:8d:a7

で、その後、外側のマシンは、内側のマシンへ ICMP Echo Request を送信します。 これは 192.168.1.55 に届きますが、 192.168.1.55 は本当の宛先を知っていますので、内側のマシンに転送します。

今度は、お試し LAN 側(eth1 側)の結果を見てみましょう。

  # tcpdump -i eth1 -n host 192.168.1.11
  tcpdump: listening on eth1
  21:27:57.208568 192.168.1.254 > 192.168.1.11: icmp: echo request
  21:27:57.208568 192.168.1.11 > 192.168.1.254: icmp: echo reply

先ほどの、192.168.1.254 からの ICMP Echo Request が、 お試し LAN に届いています。
内側のマシンは、ICMP Echo Reply を返しますが、 192.168.1.254 は別のサブネットであることを知ってますので、 デフォルトゲートウェイである 192.168.1.1(192.168.1.55) に一旦送信します。 これはまた転送されて、外側のマシンに届きます。

…あ、ごちゃごちゃしていてわかりにくいですね。すみません。
まとめると、以下のような手順になります。

  1. 192.168.1.254 が 192.168.1.11 を問い合わせる ARP 要求を送信。
  2. 192.168.1.55 が代理で ARP 応答を返す。(Proxy ARP)
  3. 192.168.1.254 は、192.168.1.11 に対し ICMP Echo Request を送信。
    宛先 MAC アドレスに 192.168.1.55 を指定するため、192.168.1.55 に送信される。
  4. 192.168.1.55 は、本当の 192.168.1.11 を知っているので、転送。
  5. 192.168.1.11 は、192.168.1.254 からの ICMP Echo Request を受信。
  6. 192.168.1.11 は、192.168.1.254 へ ICMP Echo Reply を送信。
    192.168.1.254 は別のサブネットであるので、 宛先 MAC アドレスが 192.168.1.55 に設定され、192.168.1.55 に届く。
  7. 192.168.1.11 からの ICMP Echo Reply を受信した 192.168.1.55 は、192.168.1.254 に転送。
  8. 192.168.1.254 は、192.168.1.11 からの ICMP Echo Reply を受信。

…やっぱりややこしいですね。
こういう宿題は、今後はあまりやらないようにしたいと思います。

今週の宿題

今週の宿題は、

  tcp_wrapper を使って、不正なポートのアクセスを検出しましょう。

です。

tcp_wrapper については、過去に3回もやってるのですが、 あるサービスへのアクセスを制限する方法ばっかりでした。
ここでは、使っていないポートへのアクセスを、 tcp_wrapper を使用して検出する方法を、考えてみてください。

Vol.013 - tcp_wrapper でログをとる
http://www.usupi.org/sysad/013.html
Vol.014 - tcp_wrapper でアクセス制御
http://www.usupi.org/sysad/014.html
Vol.015 - tcp_wrapper 完結編
http://www.usupi.org/sysad/015.html

あとがき

ITmedia に、女性システム管理者の憂鬱、というシリーズもの(?)が、 最近ときどき連載されています。

Windows ベースの社内システムの管理で、実際に起こりそうな話が、 毎回紹介されています。
…と書くと、ありがちなもののように思われますが、 女性の視点でちょいだめな管理者などを厳しく指摘しているところが、 新鮮に思います。

「女性システム管理者の憂鬱」というページがないようですので、 今までの連載を検索してみました。今のところ以下があります。

「ジャイアンじゃないよ、シャイアンだよ!」
http://www.itmedia.co.jp/enterprise/articles/0607/06/news006.html
「このソフト、パッチが当たらないよ!」
http://www.itmedia.co.jp/enterprise/articles/0607/11/news002.html
ちょっとかわいい、でも困ったプライドの高いM君
http://www.itmedia.co.jp/enterprise/articles/0607/20/news008.html
新人とはこんなにも罪作りなものさ
http://www.itmedia.co.jp/enterprise/articles/0607/25/news021.html

…わたしは、Windows サーバの管理をほとんどしたことがないのですが、 笑えないシビアな問題もあって、Windows なシステムの管理も大変だなーと思いました。

普段、Windows と格闘されているシステム管理者のかたは、 上記を読んで共感したり納得したりして、 日頃のうっぷん(?)を晴らしてみてはいかがでしょうか。

 

今週も、ここまで読んでいただき、ありがとうございました。
それでは、来々週に、お会いしましょう!

 

「いますぐ実践! Linux システム管理」の解除は、以下からできます。
http://www.usupi.org/sysad/ (まぐまぐ ID:149633)

バックナンバーは、こちらにほぼ全部そろっています。
http://www.usupi.org/sysad/backno.html

「栗日記」−いつの間にか検索で1位じゃなくなってるけどまあいいや。
http://www.usupi.org/kuri/ (まぐまぐ ID:126454)
http://usupi.seesaa.net/ (栗日記ブログ)
http://www.fumido.co.jp/kuriniki/ (栗日記ぎゃらりー)


[バックナンバーのトップへ] [Linux システム管理のトップへ]

トップ

バックナンバー
    [日付順] [目的別]

プロフィール

▼ リンク

独学Linux
Linuxデスクトップ環境に関する情報が満載です。 メルマガもありますよ。
Server World
CentOS 6をサーバとしたときの設定例が、これでもかというくらいたくさん載っています。 CentOS以外のディストリビューション(Fedora, Ubuntu)も充実しています。
LINUXで自宅サーバーを構築・導入(Fedora9)
Fedora9のインストールの仕方から管理方法まで、詳しく載っています。 SearchManには情報がもりだくさんです。
マロンくん.NET
〜サーバ管理者への道〜
Linuxをサーバとして使用するための、いろいろな設定方法が載っています。 マロンくんもかわいいです。 なんといっても、マロンくんという名前がいいですね!!
日経Linux
今や数少なくなってしまったLinuxの雑誌。ニュースやガイドもあります。
Linux Square − @IT
@ITが提供する、Linux の情報が満載。 載っていない設定方法はないんじゃないでしょうか。
gihyo.jp…技術評論社
Linuxに限らず様々な技術情報が満載のサイト。 SoftwareDesign誌も、 ソフトウェア技術者は必見です。
SourceForge.JP Magazine
Linux に限らず、オープンソース関連の記事が網羅されています。
ITmediaエンタープライズ:Linux Tips 一覧
Tips というより FAQ 集でしょうか。わからないことがあれば覗きましょう。
IBM developerWorks : Linux
開発者向けですが、勉強になりますよ。
Yahoo!ニュース - Linux
Yahoo!のLinuxに関するニュース一覧です。
栗日記
システム管理とかと全然関係ありませんが、毎日栗の絵を描いています。
システム管理につかれちゃったとき、癒されたいときに、ご覧ください。:-)
WEB RANKING - PC関連
ランキングに参加してみました。押してやってください。

▼ 作ってみました

Add to Google

▼ せんでん




▼ 最近読んだ本

▼ 気に入ってる本