(IT) AIをサーバー管理に活用する

※アイキャッチ画像もAI作(笑

AIが出始めるまで、Webサーバーやメールサーバーの構築・運用をする場合、OSSの公式ページをみて手順を確認したり、過去の同じものを構築した先輩方のWebサイト(blog含む)が書いた投稿(時には英語のページも)を読んで設定したりしてたわけ。
ただ、それらの投稿も、OSのディストリビューションとかモジュールのバージョンとかまでばっちり同じってわけにいかなかったり、モジュールのアップデートがあって、最新のものはまだ誰もやってなかったりして、ばっちり同じ設定にして完成なんてことはなくて、自分なりにいろいろ調べて設定したりしてたものだった。
要は、「答えはこれ」と書いてあることはまずなくて、いろいろな情報を検索する検索力と情報をまとめて設定に落とし込むノウハウみたいなものがないと、難しい世界だったことは確かだ。
正解にたどりつけず、セキュリティ設定をトチって盛大にSPAMメールを不正中継してしまってGmailが自分の管理しているメールサーバーからのメールを受け取ってくれなくなったりしたこともあった(告白)

それが、だ。

例えば。これまで「Fail2Ban」というモジュールがあって、うまく使うとWebサーバーでもメールサーバーでもおかしな挙動をするアクセスについては、そのアクセス元のIPアドレスからのアクセスを一定期間止めるということができる、ということまではわかっていたんだが、結局設定ファイルの書き方や関連モジュールとの連携がうまくいかず、導入をあきらめていて。人力で膨大なログを見て、怪しい動きをしているIPアドレスをVPCのインバウンドルールで拒否するみたいなことをするしかなかった。タイムリーにはならないし、網羅性も低い。

それが、だ。

AI登場で全然変わった。
「Fail2Banで怪しいログを残すIPアドレスからのアクセスをしてくるIPをアドレスからの通信を拒否したいから設定を教えて」とだけ言えば、AIが対象マシンのOSやapache、Postfixのバージョンから、今の設定ファイル(httpd.confやmain.cf)を全部読み込んでくれて、現状を把握した上で、
・インストールすべきモジュール
・書くべき設定ファイルの名前
・設定ファイルの中身(全部書いてくれる)
・設定反映の方法
・動作確認の方法
・ログ確認による設定のチューニング(設定ファイルの編集)
まで全部教えてくれる。「答えはこれ」が与えられるのだよ。言われるがままにサーバーの設定をすると、怪しいアクセスを拒否するサーバーができあがるわけだ。
これまでは調べて書いて、エラーに当たってまた調べて、という風に設定ファイルができあがるまでが大変だったし、そこで挫折したことも多かった。
その一番苦しいところがなくなっちゃうんだぜ、AI。

は や く 言 っ て よ ー ん

とあるサーバーはこれをやって、無駄なアクセスに応答しなくてよくなったので、CPU負荷が半分になった。
しばらく運用して、ログを全部送って「ちゃんと動いているか?止めちゃいけないIP止めてないか?評価して」ってお願いすると何MBもあるログを瞬時に読み解いて、設定のチューニングの手順を示してくれる。
マップルの地図(死語)を見て目的地までの道順を確認して運転していたのに、ある日目的地さえ指定すればナビゲーションシステムが道順を教えてくれるようになったのと同じ感じなのかな、とも思ったり。
ただ、AIの回答も絶対正確なわけではなくて、半端なログの解釈をして、半端なチューニングして終わらせようとするから、そういう時は厳しく説教するとちゃんと反省して学習してくれるが、人間によるちゃんとした確認が絶対必要ということとは思う。例えば「怪しいbotアクセスは全部拒否して」とお願いすると、GoogleBotのアクセスを拒否してたりする笑
そんなことしたらSEO的な死を意味することは、業界の人ならよくご存知のことと思う。
「精度悪いぞ」
「サーバー管理において『推測』は毒だ」
など、若いエンジニアにする説教と同じことをAIに向かって書いたりしてた笑

とはいえ、逆に言えば、確認する勘所さえ理解していれば、面倒くさい設定や構築、運用やチューニングはある程度AIがやってくれるので、物凄くラクになったことには違いない。これからエンジニアになろうとする人や若手のシゴトのススメ方は激的に変化するだろうと感じた老齢エンジニアなのであった。Google無しで調べ物をしたり、NAVI無しで運転したり、スマホ無しで生活したりという経験がないとありがたみがわからないとは思うものの、オレ達が不要な苦労をしていたものだ、とも思ったり。今の若い人はどういうことで苦労するんだろう、とふと思ったり笑

(IT) 新手の攻撃とその対策

<現象編>
先日(2015/10/19)の攻撃は、中国やマレーシアなどいろいろな国のマシンから
一斉に、このblogが乗ってるwebサーバーの「0jejhcec65c24dslii.com」と
いう名前のサイト(当然存在しない)の「#320」みたいなありもしない
ページ内リンクへのアクセスがしこたま来てた。
access_logはこんな感じ。

117.169.1.140 – – [19/Oct/2015:19:51:54 +0900] “GET /#101 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
177.99.87.146 – – [19/Oct/2015:19:52:07 +0900] “GET /#432 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
124.200.250.22 – – [19/Oct/2015:19:51:50 +0900] “GET /#22 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
114.26.14.87 – – [19/Oct/2015:19:52:07 +0900] “GET /#345 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
190.42.61.126 – – [19/Oct/2015:19:52:08 +0900] “GET /#326 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
91.121.153.214 – – [19/Oct/2015:19:51:54 +0900] “GET /#237 HTTP/1.0” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
113.204.212.50 – – [19/Oct/2015:19:51:50 +0900] “GET /#225 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
117.169.6.138 – – [19/Oct/2015:19:51:39 +0900] “GET /#220 HTTP/1.1” 500 263 “http://0jejhcec65c24dslii.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”

ログを更に見てみると、数分後にこんなエラーが1秒に1回出てた。
存在しないページ内リンク(アンカー)を探しに行くと、apacheの子プロセスが
起動されて、CPUやらメモリやらの資源を食い潰しているのか。

::1 – – [19/Oct/2015:19:55:01 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:04 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:04 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:05 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:06 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:07 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:08 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:09 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”
::1 – – [19/Oct/2015:19:55:10 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “Apache/2.2.15 (CentOS) (internal dummy connection)”

error_logも一応確認したけど、あまりめぼしいものがなくて、タイムスタンプが
近いものとしては、こんなのだけかな。

[Mon Oct 19 19:53:01 2015] [error] server reached MaxClients setting, consider raising the MaxClients setting

<対策編>(Special Thanks to「インフラ部」)
(1)意図しない名前でアクセスされた場合、反応しないための記述。
httpd.confのVirtualHostの先頭にdummyエントリを追加。
今回の大量アクセスは、IPアドレスで到達するけど、ターゲットのサーバー名が
「0jejhcec65c24dslii.com」という存在しないサーバー名宛てに来てたので。

#
# Use name-based virtual hosting.
#
NameVirtualHost *:80
#
<VirtualHost _default_>
ServerName dummy
DocumentRoot /var/www/dummy
<Directory /var/www/dummy>
Order Allow,Deny
</Directory>
</VirtualHost>
<VirtualHost *:80>
    ServerAdmin “anonymous@hogehoge”
    DocumentRoot “/foo/bar”
    ServerName www.ryoshr.net
(続く・・・)

(2)「#」で始まるページ内リンクを動作させない。
.htaccessでもいいみたいけど、httpd.confに追記。

<VirtualHost *:80>
    ServerAdmin “anonymous@hogehoge”
    DocumentRoot “/foo/bar”
    ServerName www.ryoshr.net
    ErrorLog logs/hogehoge_error_log
    CustomLog logs/hogehoge_access_log combined
    RewriteEngine On
    RewriteCond %{THE_REQUEST} /#
    RewriteRule .* – [F,L]
</VirtualHost>

(3)その他パラメータを調整。
MaxClient値を半分に(256→128)
MaxRequestsPerChild値を2.5倍に(4000→10000)

(4)Fail2Banをインストール

間違ってたら、ご指摘ください。