web スクレイピング隠蔽技術

beepcap

2017/12/10

はじめに

なんか気づいたらアドベントカレンダーに登録してた。 webスクレイピングの10日目だ。 beepcapである。

webスクレイピング... 最近はwebスクレイピングなどとかっこいい名前が付いているが、昔はwebクローラといった気がする。厳密な定義がどうかは分からんのだが、軽く調べてみても両者を明確に区別する文言は見つからない。本記事ではwebクローラと言うことにする。

さて、古くからwebを扱っている人間にとって、 webクローラというのは親の敵のような存在だ。ネットワークが従量課金性であった時代では、アップロードとダウンロード双方に回線料が発生するのだ。クローラにアクセスされた分の料金を支払わねばならない個人サイトの運営者はとにかくクローラを排除する必要に迫られた。

その検出手法と攻防の推移を紹介しながら話を進めよう。

基本編

初歩的なクロール対策

「初歩的な」と書いたが、一般的なwebクローラの攻防は大体これだ。まずさくっとwebクロールしてみよう。きっと今回のACの他の記事にwgetによるクロールの話が出てくると思うので仔細は語らないが、

$ wget -r -l inf -k -nc -E -np http://targ.et

といったところだろうか。上記は最速で取得しようとするので、 httpdのアクセスログは単一のIPアドレスでうめつくされる。管理者側からはバレバレだ。

この行為への対策はIPアドレスフィルタリングとなる。自動化して一定時間のアクセスを禁止するものから、

$ iptables -A INPUT -p tcp -m hashlimit -dport 80 -hashlimit-name no_robot -hashlimit 5/s -hashimit-burst 3 -hashlimit-mode srcip -j ACCEPT $ iptables -A INPUT -dport 80 -j DROP

やらかしたら二度とアクセスを許さないものまで多種多様だが、

$ iptables -A INPUT -s xx.xx.xx.xx/32 -j DROP

対webクローラの手法としてIPアドレスフィルタリングは良く使われていた。 90年代〜2000年代初頭にwebページを運営していた仲間内では「クロール元のIPリスト」なるものがやりとりされていたりもしたのだ。こうなってしまっては満足に収集も出来ない。そこで、次のような対策が打たれた。

初期の対策の対策

これもwgetの例でいいだろう。

$ wget -r -l inf -k -nc -E -np -w 1 http://targ.et

このコードは1秒に1回のアクセスに取得を制限するものだ。一般的なクローラの動作といっていい。現代の普通のサイトではクローラを拒否する理由なんて負荷くらいのものだから、この対策で十分に効果があるし、目を付けられてブロックされる恐れも無い。
世の中の大半が幸せなら、それ以上の技術はいらない。

などという甘い考え方が通用しない人たちもいる。

例えばセキュリティ技術者のようにログを監視している人々にとっては、こんなふうにこれらのアクセスが見える。

[水 12月 6 08:30:03 2017] Inbound_tcp_s SRC=xxx.xxx.xxx.xxx DST= LEN=40 TOS=0x00 PREC=0x00 TTL=238 ID=45566 PROTO=TCP SPT=43146 DPT=80 WINDOW=1024 RES=0x00 SYN URGP=0 [水 12月 6 08:30:04 2017] Inbound_tcp_s SRC=xxx.xxx.xxx.xxx DST= LEN=40 TOS=0x00 PREC=0x00 TTL=238 ID=45567 PROTO=TCP SPT=6666 DPT=80 WINDOW=1024 RES=0x00 SYN URGP=0 [水 12月 6 08:30:05 2017] Inbound_tcp_s SRC=xxx.xxx.xxx.xxx DST= LEN=40 TOS=0x00 PREC=0x00 TTL=238 ID=45568 PROTO=TCP SPT=22012 DPT=80 WINDOW=1024 RES=0x00 SYN URGP=0 [水 12月 6 08:30:06 2017] Inbound_tcp_s SRC=xxx.xxx.xxx.xxx DST= LEN=40 TOS=0x00 PREC=0x00 TTL=238 ID=45569 PROTO=TCP SPT=30153 DPT=80 WINDOW=1024 RES=0x00 SYN URGP=0 . . .

webクローラであることがバレバレだ。 webクローリングを阻止したい人間がいれば、排除されてそれで終わりとなる。

そこで、ここからが本題だ。如何にしてwebクロールを隠蔽するのか。

アクセスのタイミングの隠蔽

人間が操作しているかのようなログを残せば、機械だと見破られなければ如何に優秀な管理者が相手であっても、これをブロックして仕舞うことは難しい。

例えばこれをランダム化によって回避しようとする手法がある。 wgetで言えば-random-waitという手法である。これを行うとアクセスの待ち時間がランダム化し、パッと見では分からなく・・・ならない。普通に怪しい。ただし、自動解析ツールを使って監視している場合は検出されなくなることがある。周期性をキーに監視しているツールが存在するからだ。それでも、まぁアクセスが多くなるので、人間に監視を促すよう警告が出る場合がある。そうしたらお陀仏だ。

ランダムではなく、人のような動きをクローラにはさせてやらねばならない。

とここまで書いたが、残り締め切りまで一時間しか無いので、巻いていこう。タイミング隠蔽を含めて、クロールが発覚しにくい手法の肝要な部分は3つある。

人の動きを模倣するには2つの点で気をつけねばならない。一つはアクセスする頻度だ。先程までの話から展開させると、つまり人は文書を読んでから次のリンクをクリックするので、文書上の距離を計測すれば適切な待ち時間を算出できる。この方法は、レンダリング後の画像を使う確実な方法と、マークアップと文を含めた文字数で算出する方法があるが、評価し確認してみた所だと、文字数だけでもかなり精度が高い。これはマークアップという書式の特徴だと思われる。ただし、画像の中に文書があるような形態の場合はやはり画面上の距離を推定する必要がある。どの程度の精度と成果をバランス良く摂るのかを検討して設計して欲しい。

アクセス元の偽装

言うまでもないが、アクセス元を偽装しなければ、同じサイトに毎日現れる不審なログに気付かれる可能性がある。とはいえ、アクセスのたびにProxyを切り替えるような手法はダメだ。 SYNのたびにProxyが切り替わるログは完全に怪しさしかないし、まともなサイトの管理者は、むしろパブリックなProxyを弾くように設定している。ここで大事なのは、企業などからアクセスしているように見せかけることだ。この場合、仮に頻度がある程度高くても、同じページを一斉に参照している可能性も考慮されるからだ。

ということで、この場合も最適解だけ書くと、安価なクラウドサービスをレンタルし、自前のProxyサーバを立てること。そして、一日以上、短くても数時間以上の長いスパンでProxyの切り替えをすることだ。同じサイトに同じ人間がいることはおかしくない。という心理上の正しさを追求すべきである。

クロールする時間

最後の項目だが、これは簡単だ。 24時間ページを見続けられる人間は居ない。あなたがクロールする時、それをアルバイトに任せることを考えて、稼働のシナリオを考えるのだ。webクローラとは隠密の世界なのである。

最後に

最後に、これらのいかがわしいwebクローラのコードを貼っ付けるのと、 Apache ManifoldCFとApache Solrによって構築するwebクローリングシステムの運用方法に言及しようと思っていたのだが。時間切れでなんにも出来てません。本当に申し訳ない。これらの話を聞きたい方は、Twitterで直接話しかけて欲しい。 @beepcapとしていつでもリプライを待っているぞ。

以上