Kacho Blog

2010/03/09 Brute Force Attack
の続き。
平日の少ない時間にiptablesをぐぐったのだが、設定を全てshで作るのが主流らしい。
しかし、よく分からないままコピペで済ますとろくなことになりそうもないので、必要最小限の設定を追加してみた。
——————————
[root@shuttle ~]# iptables -A INPUT -p tcp –syn –dport 22 -m recent –name sshattack –set
[root@shuttle ~]# iptables -A INPUT -p tcp –syn –dport 22 -m recent –name sshattack –rcheck –seconds 300 –hitcount
参照元：http://hitaki.net/diary/20051014.html
——————————
どうやら設定するだけだと、再起動すると設定が消えるらしいのでこれで様子見、ということで。
とりあえず、上記の意味を勉強してみた。
参考：
Manpage of IPTABLES

１行目：
iptables
-A INPUT 　　 (INPUTチェインに下記のルールをADDする)
※INPUTチェイン：送信元からパケットを受信
参照：Linuxで作るファイアウォール［パケットフィルタリング設定編］
-p tcp　　 (プロトコルはTCP～)
–syn 　　(～のSYN送信)
※tcp 3way-handshakeの最初
参照：Linuxで作るファイアウォール［パケットフィルタリング設定編］
–dport 22　　 (ポートは22番=SSH)
-m recent 　　(recent（パケットマッチング）モジュールを使う。以下recentのオプション)
参照：iptables の ipt_recent で ssh の brute force attack 対策
–name sshattack　　 (使うリストの名前を指定。下記で送信元リストを保存したり参照したりする)
–set 　　(送信元アドレスをリストに追加する。無条件で。)

２行目：
iptables
-A INPUT
-p tcp
–syn
–dport 22
（ここまで同上）
-m recent 　　(recent（パケットマッチング）モジュールを使う。以下recentのオプション)
–name sshattack　　 (使うリストの名前を指定)
–rcheck 　　(リストにある送信元アドレスから～)
–seconds 300 　　(300秒以内に～)
–hitcount 10 　　(10回以上受信していたら～)
-j DROP 　　(（上記に引っかかった）パケットを破棄する)

つまりこれだけだと、1回目のチャレンジから300秒立てば、通算11回目のチャレンジが出来る、ということね。

iptables(ファイヤーウォール)全般に関する説明は下記が分かりやすい。
Linux のファイアウォールの設定方法

修正
iptables の ipt_recent で ssh の brute force attack 対策(2)

ユーザーにエラーメッセージを読ませるには？
引用元: ユーザーにエラーメッセージを読ませるには？ – スラッシュドット・ジャパン.

・そのまま操作を続けられるならエラーメッセージを出すな。頻繁に出ればユーザは無視する
・出すなら操作手順の最初に出して強制的に止めろ

「そもそもエラーメッセージを出すな」
「ユーザーはメッセージを読まない」
「出すならプログラム側でできる限り原因を特定しておけ」

ログが最強だと思う。

開発者はアプリケーションログにもっと力を入れればいいとおもうんね。
少なくともすべての異常分岐にログをしかけるぐらいやりたい。(エラーは予期しない分岐ともいえるはず)
できれば、操作系のします、しましたのログもほしい。
coreやdmpでは場所が特定できても、履歴がないからどうしてそうなった？系の対応は難しい。
アプリケーションのパフォーマンス上、許されるのであれば、ガシガシログを出力したい。

コマンドライン系のツールでは –debug とかで詳細なログをどんどんはいてくれるものが多いが、GUI系だとなかなかないよねぇ。

後はログを回収する手法を考えることになるんだけど。

私もサポートを職業としている人間として、非常に興味のある話題。
動物を使えば良いだとか、色を使って、などと様々なアイデアがあるものの、結局、ユーザは「出来たか、出来ないか」の結果にしか興味がないため、過程には興味がなく、見もしないし、当然頭にも入っていない、というのが現実。
ユーザに説明させるよりも、ログを見て再現出来るようなアプリケーション作りを心がけるのは良いな、と思いこんな引用に。
ハンパなログの残し方をしてやきもきする経験は結構あるんだけど・・・