前々回ではINPUTチェインの基本ポリシーとして実際にDROPするまではせずに置いたのですが、やはり試してみないと勉強にならないのでDROPしてみることにしました。まずwebminから設定する方が簡単だと思い、アチコチをしばらくいじっていたのですが、ルール単品では問題なく指定パケットを破棄出来るのだけれど（←例：ポート番号80）、しかしINPUTチェイン全体の基本ポリシーを「DROP」にすることが出来ません（←下部のデフォルトのアクションの箇所）。

　「設定を適用」ボタンを押しても全く更新されない…。これは僕の手順が悪いのか、それともwebminのバグなのか判らなかったので、これまでのようにCoda 2からターミナル経由でDROPさせてみることにしました。「# iptables -P INPUT DROP」を入力してから、保存して再起動。

# iptables -P INPUT DROP
# /etc/init.d/iptables save
# /etc/init.d/iptables restart

　INPUTチェインは原則として破棄、でも設定した例外条件に合致するパケットは通行許可、というルールはうまく動作したようです。試しにポート番号80のみを破棄する設定にしてみたところ、www.♥♡♥.comにはアクセス出来なくなりました。端からブラウザでアクセス出来なくなるので、ページが開いてNot Foundとかいう表示もでません。なるほど。

　ただ、ここで原因不明の遅延が発生。INPUTチェイン全体をDROPすると、以前までの「ACCEPT」していた時と比較して、明らかに動作が非常に重たくなる現象が起きました。webminを操作するのもイライラするくらい反応が遅くなるのですが、ACCEPTに戻すと直ります（しかし、だからと言ってACCEPTに戻してしまうと、「全部許可」なのだから個々のルール設定の意味が無くなってしまう）。具体的にはwebminの動作が重くなって、MySQLへの接続も反応が鈍くなります。httpでのウェブアクセスは、まあ問題なさそう。ちょうどwebminの最新バージョン1.680のダウンロードが表示されていたのでアップデートしてみたけれど、この症状は直らず…どうにかならんものか。

ステートフル・パケットインスペクションにしてみる

　さて今回は、前３４回で触れた「ステートフル・パケットインスペクション」という考え方を試してみることにします。静的なフィルターだけだと偽装パケットが素通り出来てしまうらしいので、動的なものに変更です。

　上記の参考記事をよ〜く読んで自分なりにまとめてみると、例えばssh接続をアクセス前後の状況を見て「動的に許可」する場合の基本的な書式は次のようになるのかしら。

# iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED,RELATED --dport 22 -j ACCEPT
# iptables -A INPUT -p tcp ! --syn -m state --state NEW --dport 22 -j DROP

　では早速、以前変更したwebminのポート番号「zzzzz」でテストしてみます（ssh接続でテストして失敗すると非常に困るので）。ターミナルから上記２行を入力して、保存、再起動。そしてwebminの方で状態を見ると下図のようにルールが追加されました。またよく見ると、前々回で設定したスタティック（静的）なルールが残ったままになっていたので、チェックを入れ、デリートボタンを押して削除します。

　ここで一旦webminをログアウト（ユーザーの切り替え）を行い、新しいルールでログイン出来るかチェック。無事ログイン出来たので、その他のルールについても同様にターミナルを使ってステートフル・パケットインスペクションへ置き換えて行きます。

　webminに入り、古い静的ルール設定を削除し「設定を適用する」ボタンを押します。

　さらに参考記事３ページ目を読んで、OUTPUTチェインを通過するTCPにステートフルなルールを追加設定しておきます。UDPは53番ポートのみ許可。

# iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

　ここまで設定しておいてから、最後にFORWARDチェインとOUTPUTチェインを基本ポリシーとしてDROP。またいつものように保存、リスタート。

# iptables -P FORWARD DROP
# iptables -P OUTPUT DROP
# /etc/init.d/iptables save
# /etc/init.d/iptables restart

sshログインが異様に遅くなった…

　これで「INPUT」「FORWARD」「OUTPUT」全ての基本ポリシーをDROP、通過させたいパケットのみをステートフルに許可することが出来た…と思います。ようやく諸設定を終えて、初心者による初歩的ファイアウォール設定が終わりました。
　ただ、この設定を終えた後、上でも書いた「ターミナルでのログイン」「webminの各操作」等が異様に遅くなりました。ネットで調べてみると、同じような症状に出くわしている人が他にたくさん居て、どうもDNS逆引きをしに行って遅延してるらしい（？）。

　そこでssh接続の設定ファイルを修正します。またあのvi再び。

# vi /etc/ssh/sshd_config

　開いた設定ファイルの適当なところに

UseDNS no

を追加して、「:wq」で上書き保存。そしてsshdデーモンの再起動。

＃  /etc/init.d/sshd restart

　おかげさまで、ssh接続とMySQL接続時のイライラする遅延は解消されました。ただし、webminの各動作が緩慢なのは未解決（追記：自己解決しました。次回の引っ越しメモ第３６回に書きます）。

サーバー引っ越しメモ、ひとまず完結

　終わった。サーバー引っ越しメモ。今後自分が何かヘマをして、再びVPSサーバーをセットアップしなければならない羽目に陥った時、この無駄に冗長なメモは自分にはソコソコ役立つに違いありません。
　この引っ越しメモを始めるきっかけとなったコチラの記事で書かれていた事が、読んだ当時はまるでチンプンカンプンだったものが、ほんのちょっぴりだけ、その概念っぽいところでは理解できたような気がします。少なくとも機械的に手順を踏めるくらいの要領は得たのではないか。
　しかし何度も書いているように、セキュリティ対策はあまりに深遠で、今回行ったものは初歩の初歩だと思うし（Apacheのセキュリティ設定も調べたけど、まるで意味不明で手を付けられないし）、こんな程度のものが役立つのかどうか分かりませんが、自分の背丈に合ったレベルでやれそうな事はやった、という気持ちの区切りが付けられたのはとても大きくて（つまり、とりあえずの義務は果たした、という感じ）、今後は心置きなく「制作日記のためのWordPress組立て」を楽しむことが出来そうです。つづく。

Thunderbolt大作戦はしばらく雑ネタで気分転換し、その後は「音楽制作日記の制作メモ」を始める予定。実はもうすっかり、WordPressの事忘れてるんですよねえ。

2014-04-03 ＞ VPS＆WordPress引っ越しメモ