ServersMan@VPSでのiptables設定(state版)

ServersMan@VPSでのiptablesがstateに正式対応したようなので、以前の改訂版としてstateを使用したルールの書き方をまとめる。

(注意) stateに対応したという情報が流れた後に一時的に「stateの文法が通るようになったが実際は動作しない」という時期があった。5/12日現在においては、一旦rebootすることで正常にstateが動作するようになるので、この記事の内容を試す前に一旦rebootすることをおすすめする。



これからやること
まず、簡単にstateを利用したルールの作り方を書くと、

1. ESTABLISHED, RELATEDというstateな通信を許可するルールを設定
2. その後ろにサービス提供したいport宛のNEWというstateな通信を許可するルールを設定
3. 最後にすべてDROPする

となる。1で設定するルールによってESTABLISHEDなtcpコネクションやDNSの返信パケットなどは自動的に許可されるので、設定する人間は2のルールを決めるためのポリシーを考えるだけでよい。

失敗すると怖いので...
さて、ServersMan@VPSはroot権限はあるが、リモート環境(ssh等でアクセスする必要がある)であり、しかもコンソールアクセスが提供されているわけでもないので、iptablesの設定に失敗してsshでアクセスできなくなったりすると、サポートにお願いしてiptables設定を解除してもらう必要がある。こうなってしまうと少なくとも1日は無駄にしてしまうので、可能な限りiptables設定の失敗は避けたい。

そこで、一旦安全なルールを設定し、stateによる動作を確認した後に厳密なルールを投入するという方法を解説する。(完璧じゃぁないが、だいぶ失敗は防げると思う)

ポリシー決定
提供したいサービスをもとに許可ポリシーを決定する。例として、Webサーバとメールサーバをたてて運用する場合を考えると、以下のようなポリシーになる。

1. HTTP, HTTPS: 不特定多数の人にWebサーバを公開するつもりなので、すべてのIPアドレスからの接続を許可する。
2. SMTP: 自分のドメインのメールを受け取るメールサーバにするつもりなので、すべてのIPアドレスからの接続を許可する。
3. SSH: 管理用に必須なので許可する。自宅、会社、出先などいろいろなところからアクセスする必要があるので、すべてのIPアドレスからの接続を許可する
4. 前回の解説にも書いたが、ローカル通信は当然許可する。また、icmpも許可。ident(auth)はtcp resetで拒否、その他のすべての通信はDROPで拒否する。

ポリシーから動作確認用ルールを作成
上記のポリシーからiptablesのルールを作成すると以下のようになる。

これは /etc/sysconfig/iptables にそのまま使える形式(iptables-save(8)の出力)で書いてある。

1行目〜4行目はおまじない。

5行目はMYCHAINという名前のチェイン（ルールの集合）を作成している。こうしておくことで作成したルールの再利用性が高まる。（あんまり再利用する機会もないけど）

6行目は前述の「ESTABLISHED, RELATEDというstateな通信を許可するルールを設定」だ。

7行目はicmpの許可

8行目はローカル通信の許可

9〜12行目は各種提供サービスの許可。ここで --state NEW としているが、これは接続開始要求のパケット(SYNパケット)のみ許可するという意味になる。--state NEW をつけない場合は、SYNフラグがたっていないパケット(ESTABLISHEDを偽装したパケット等)を受け付けることになるので --state NEW をつけた方がよい。

13行目はident宛の通信を拒否している。ただし、DROPのように無視するのではなく、tcp reset を送信して拒否することを明示的に相手に知らせている。詳しくは前回の記事参照。

14行目は本来DROPとするはずだが、動作確認用にACCEPTにしている。こうしておけば仮に上のルールが間違っていたとしても完全にロックアウトされることはない。動作確認の方法については後述。

15行目はINPUTチェインですべてのパケットをMYCHAINチェインに飛ばしている。

16行目はおまじない。

動作確認
上記の設定をファイルに落としたら、iptablesのサービスが再起動時に自動的にあがらないようにしたうえで、iptables-restore(8)を使ってルールを反映させる。
iptables.txt というファイルにセーブしているとすると、以下のようなコマンドになる。

無事通信が継続できたら反映されたルールを確認する。

もしロックアウトされてしまった場合はServersManのアカウントのページからrebootさせればよい。iptablesサービスをoffにしておけば、ルールが勝手にセーブされたり起動時に間違ったルールが自動的に適用されることを防げるはずだ。
なお、VPSサーバからDNSを引けない場合、SSHでアクセスしたときにログインするまでに時間がかかることがあるので、SSHでアクセスして反応がなくてもしばらく待ってみた方が良い。

ルールの確認は /etc/init.d/iptables status でもいいが、ここでは iptables -L -nv を使う。このコマンドを使うことで、どのルールにどれだけのパケットがマッチしたかを確認することができるからだ。

ここで、ESTABLISHED のルールと SSHのルール(dpt:22)の行の一番左のカラム(pkts)の数値をみると、カウントアップされていることがわかる。この数値はそのルールにマッチしたパケットの数を示している。もし許可したルールに該当するはずの通信を行っても、ここがカウントアップされていない場合は、そのルールにマッチしていない(＝何かが間違っている)ということなので、ルールを見直す。
例えばSSHを許可しているが、新たにSSHで接続しても最後の全ACCEPTのカウントばかりあがっていくようならば、最後のACCEPTをこのあとDROPに変更したときに通信できなくなってしまうはずだ。

意図した通りに動くようになるまで、ルール作成と動作確認を繰り返す。

動作確認用ルールから厳密なルールを作成
これは簡単。最後のACCEPTをDROPに変更するだけだ。


ルール投入
前述の用に iptables-restore  でルールを投入し、問題なければ内容を /etc/sysconfig/iptables に保存し、iptablesサービスを有効化する。


まとめ
今回の要点は以下の通り。

1. stateをつかったルールは、「ESTABLISHED,  RELATED許可」→「提供サービスのNEWを許可」→「ほかはDROP」が基本形
2. iptables -L -nv で意図したルールにマッチしているか確認してから最後のDROPを有効化する

コメント、突っ込み等あればお願いします。