fail2banでdirectory traversalなwebアクセスを蹴る

apacheやnginxなどのwebサーバでサービスを提供していると、そのサービスは常に不正アクセスのリスクにさらされます。
特にWordPressといった著名なソフトウェアを運用していれば、分かりきった不正アクセスパターンでのアクセスはしばしばやってきます。
対処としては、運用しているソフトウェアのバージョンを新しく安全なものに保ち、設定も安全で正しい状態にすることが大切です。そうすれば、対策済の過去の不正アクセスパターンを受けても実害はありません。とばいえ、「分かりきった不正アクセスパターン」でログが汚されたり、無意味なサーバ負荷が増えるのはうっとうしいものです。

この手のアクセスは、個別に知恵を絞って攻撃してくる相手よりも、何も考えずwell knownなパターンをひたすらスクリプトで叩いてくる連中だったりします。それも乗っ取った第三者のホストを使ったり、技術的には何もわかっちゃいないが出回っている攻撃スクリプトをひたすら動かして遊んでいる手合いだったりします。後者は俗にscript kiddieと呼ばれるものですね。余計うっとうしいです。

この手のアクセスをサーバの前段で防ぐにはIDS (intrusion detection system, 侵入検知システム)を導入するのも手ですが、そこまでのコストもかけられない場合は、fail2banで手軽に蹴ってしまうこともできます。

directory traversal

先日、WordPressを運用しているサイトにscript kiddie的なアクセスを延々とくらっていました。
実害はありませんが、ログは太るし負荷も若干食うし、うっとうしいなー と思いました。
アクセスパターンを見てみると、数十行えんえんとこんなのばっか。

GET /?language_id=../../../../../../../../etc/passwd%00
GET /?module=../../../../etc/passwd%00
GET /?npage=1&content_dir=../../../../etc/passwd%00
GET /?p=cat&c=../../../../../../../../etc/passwd%00
GET /?set_lng=../../../../../../etc/passwd%00
GET /Factux/admin?lang=../../../../../etc/passwd%00
GET /Factux/admin_modif.php?lang=../../../../../etc/passwd%00
GET /Factux/article_new.php?lang=../../../../../etc/passwd%00

典型的なディレクトリ・トラバーサルです。
WordPressへの不正アクセスパターンのトレンドを追いかけて対処していくのはあまりに面倒です。悪者にそこまでつきあわされるのはまっぴら。そのかわり、問題をある程度一般化し、ベタベタなdirectory traversalを蹴ってしまうのは一定の効き目がありそうです。

fail2banとは

fail2banは、各種ログを定期的に監査し、不正アクセスのパターンを見つけ、source ipからのアクセスをiptablesで一定時間拒否してしまうツールです。
標準でも各種アプリケーションのログ監査と対処ルールがいろいろ書かれています。
ここに、directory traversalも蹴るルールセットを追加してみます。

fail2banのインストール

Debian GNU/Linux系ディストリビューションであればapt install fail2banで。
rpm系など他いろいろの場合はそれぞれどうぞ。

設定

/etc/fail2ban/filter.d/apache-dirtraversal.conf

/etc/fail2ban/filter.d にfail2banの各種アプリケーションに対するフィルタルールが並んでいます。
apache用のものも、既に apache-*.conf としていくつか用意されています。
ここに新たに apache-dirtraversal.conf としてルールを追加してやりましょう。

# Fail2Ban configuration file
[Definition]
failregex = <HOST>.*] "GET /.*\.\./\.\./\.\./
ignoreregex =

../ が3段以上あると怪しい、という判断にしています。

/etc/fail2ban/jail.conf

/etc/fail2ban/jail.conf に、末尾でいいので以下を追加します。

[apache-dirtraversal]
enabled  = true
port     = http,https
filter   = apache-dirtraversal
logpath  = /var/log/apache*/*access.log
maxretry = 3

logpath の値は、運用しているバーチャルホストのアクセスログをカバーするよう、必要に応じて調整してください。

fail2ban再起動

service fail2ban restart でfail2banを再起動します。

テスト

運用ホストで

tail -f /var/log/apache*/*access.log
tail -f /var/log/fail2ban.log

など流して状況監視します。

では不正アクセスをしてみます。
もちろん、不正もどきアクセスを行った結果、期待通りにアクセス拒否をされると、しばらくサイトにアクセスができなくなってしまいますから、汚れ仕事専用のweb proxyなどを通して、拒否されてもよいアクセス経路でテストしましょう。

http://wordpress.example.com/Factux/admin?lang=../../../../../etc/passwd%00
http://wordpress.example.com/?language_id=../../../../../../../../etc/passwd%00
http://wordpress.example.com/?set_lng=../../../../../../etc/passwd%00

みごとアクセスできなくなっちゃいました!

デメリット

ディレクトリ・トラバーサルっぽいアクセスパターンを蹴っているわけなので、正当に「ディレクトリ・トラバーサルっぽいアクセスパターンでアクセスするWebアプリケーション」を運用している場合は、正当なアクセスも蹴られてしまうデメリットがあります。

でもそれって

http://dull.example.com/cgi-bin/shop.cgi?user=123456&mode=help&txt=../../../setsumei/kiyaku02.html

みたいなことする設計のサイトなわけですよね。こんなの、そもそものところでなんかどっかアレじゃないか、と思ったりします。