その踏み台となったPCにも当然自分が新入した形跡が残ってしまう。そのため、踏み台をするための踏み台を探す。その踏み台を探すための踏み台を探す。......とやっていく。それが単なる数珠つなぎになっているとは限らない。ハッカー自身のPCから多数の踏み台サーバーにログインし、それぞれからまた更に多数の踏み台サーバーにログインし、とやっていくと膨大な量の踏み台サーバーが発生し、特定が困難になる。そのように、ある目的を達成するために行う攻撃もあるのである。方法としては、上で紹介したブルートフォースアタックのような攻撃だったり脆弱性を探したりして踏み台を探す。それらは膨大な作業となるため、自動化するプログラムを作成して侵入を試みるだろう。すると侵入を試みるときには、プログラムを実行するだけとなる。画面には、ログインに失敗した、もしくは成功したのような履歴が残るかもしれない。ちなみに以下の画像は私のサーバーにログインを試みたログである。attack)という攻撃がある。DoS攻撃は、あるサーバーに大量のデータを送信することでサーバーが処理しきれなくなりダウンしてしまうことを狙う攻撃である。DDoS攻撃は更に強力で、DoS攻撃を上で紹介した大量の踏み台を使って対象に一気に攻撃を仕掛けることである。今では、DDoS攻撃をDoS攻撃と呼ぶこともある。いうのもDDoS攻撃をしないとほぼ影響が出ないからである。Webサーバー以外にもよく攻撃されているのが、スマホなどのゲームで使用しているサーバーである。サーバーがDDoS攻撃を受けたことによりメンテナンスになってしまうことも割とある。(なので、あまり詫び石詫び石といわないでほしいと思っている。DoS攻撃に関しては、2018年に多くのエンジニアが利用しているGithubというサービスが1.7Tbpsというデータ量の攻撃を受けてサービスが停止した。1.7Tbpsとは、スマホのデータ量で使うギガバイト換算すると、1秒間に210ギガバイト受けた計算となるため、7GBでデータ制限がかかるとすると0.03秒で上限に達してしまうデータ量となる。DoS攻撃には綿密な準備が必要だが、実際に実行するときにはプログラムを実行するだけ、のような気がしている。そこまでカタカタカタカタする必要がないかもしれない。ハッカーから攻撃を受けたエンジニアは何をするのか。ハッカーは今までに話したとおり、準備には時間がかかるが実際に攻撃するときには意外とすることがない。エンジニアは、意外と事件が起こったときにはカタカタすることが多い。こちらも分類してみる。サーバーがダウンしたとしても、ハッカーによる攻撃でダウンしたのか故障でダウンしたのかしたかがわからない。サーバーが故障したとしても、サーバーのソフトウェア部分がダウンしたのか、機器自体が故障したのか、通信している場合にはネットワーク機器が故障したのかなど、切り分けるところは多数ある。それらを調べるのにはCLIがよく使われる。総合的にチェックするプログラムを用意している場合もあるし、手動で一つ一つの機器に入って調べることもある。常にカタカタカタカタしているのである。サーバーのダウンの原因がハッカーが原因だった場合、発見のタイミングにもよるが基本的にサーバーの機器自体の電源を落とさないといけない。「ハッカーの侵入経路を特定しそこを塞げばいい」と思ってしまうかもしれないが、そうもいかないのだ。いうのも侵入された段階で、何らかの悪意のあるプログラムを設置してセキュリティホールを作成していたり、自動的にサーバーの設定を書き換えて侵入しなくてもなんでも自由にできるようにされてしまったりする。そのため、サーバーをダウンさせることが一番の得策となっていまうわけである。あとでネットワークを遮断した状態でサーバーを起動し、何が原因で侵入されたかなどを検証する必要があるし、サーバーは同じ設定を複数台に施している場合もあるため、他のサーバーも侵入されないように対策する必要がある。ハッカーは事前準備の方が黒い画面をカタカタし、エンジニアは攻撃されているときにカタカタすることが多いというのが私の印象である。映画では事前準備の風景を重点的に描いてしまっては単なるドキュメンタリーになってしまうし、また攻撃されているエンジニアがサーバーの電源を落とし、機器を交換している風景を描いてもなんの面白みもないだろう。映画と現実のギャップをお伝えしてみたかったのである。前の会社でデザイナーの人の前でCLIで操作していたときに「CLI触る人って、どこになんのファイルが有るのか全部覚えているんですか?」と聞かれたことがある。私の答えとしては、割と「なんとなく」だ。設定ファイルはどこにあり、プログラムの本体はどこにあり、ログファイルがどこにあるなどは割と決まっている。設定ファイルの中にどこに必要なファイルが書いてあるといったことも覚えてはいる。そのため、大方の操作はCLIの文字情報だけで操作できるのである。GUIでのマウス操作は日々便利になっている。WindowsにしろMacにしろ(Linuxにしろ)、バージョンを上げるごとに使いやすくなっていっているというのが私の印象だ。「Windows10になって使いづらくなった」というのは単に変わったばかりで慣れていないだけである。本当に変わらない操作がほしいのであれば、CLIをおすすめする。CLIは変わらないよ。umentu_blog最近、ターミナル環境をガラッと変えてみたので。いわずとしれた、ターミナルアプリ。インストール後にフルディスクアクセスを許可する必要がある。gitはもちろん使うんだけど、他の人達のリポジトリをちょうだいするときに管理するのに前は自分でスクリプトを組んでいて、ghqの存在を知り驚愕だった。形式で保存され、ghqコマンドで管理できるので便利。bash->zshを使ってきたけど、なんかモダンなのを使ってみたくて移行。使い勝手が違いすぎてはじめは苦労するけど、進化しているなぁと実感。Homebrewをインストールしていれば環境構築は楽。shellを便利にするスクリプト集的なもの。shellを使うなら入れておいたほうがいい。oh-my-fishのテーマを選択できるが、agnosterを使用している。プラグインの類も設定。oh-my-fishのagnosterはpowerline/fontsが必須なため、設定。iTerm2をPreferencesで設定。1つの言語しか使わないにしても複数言語を使うにしても、使ったほうがいい。ちなみにPyenvでPython3.7以降をインストールするときはこちらを参照。iTerm2のカラーテーマ。答えられない人が多いと思う。わかっている人でも「直径を1とするときの円の周囲の長さ」という人も多い。厳密には「円の直径と円周の長さの比率」というのが正しい。いえ、円周率が「円の直径と円周の長さの比率」として使われる事のほうがいまとなっては少なくなっている。円周率は数学や物理学、広くは工学や経済学など幅広い分野で出現してくる不思議な数。「円の直径と円周の長さの比率」以外の意味があるのではないかとすら思えてくる数だ。歴史的には古く、紀元前より円周率という考え方ではないものの、小学校で習う円の半径と面積の関係であったり、中学校以降で習う球の半径と表面積と体積の関係などが知られていた。現代数学では、円周率は厳密な値を求めることに対してあまり興味を持っていない。過去には様々な人達が円周率の厳密な値を求めることに注力していた。紀元前の数学者アルキメデスは、次のような方法で円周率を求めようとした。円を円に内接する正多角形と円に外接する正多角形ではさむことで、円周は内接する多角形の辺の長さの和よりは大きく、外接する円の辺の長さよりは小さいという事実を利用して求めていく。正多角形の辺の数が増えれば増えるほど円に近づくため、徐々に円周に近づいていくというわけだ。この手法によって、円周率は3.14に近い数値であることが明らかとなる。ちなみにこの手法はアルキメデスの時代より2000年のあとに、ドイツの数学者・ガウスによって定式化される「はさみうちの原理」の元となっている。その後も様々な人によって3.14に近かったり遠かったりの円周率の値が導き出されることになる。西洋ばかりでなく中国の学者たちも円周率を計算し、有名なところでは祖冲之が3.1415929まで求めたことが知られている。あとになるが、日本人も村松茂清が3.1415926まで求めている。それまでの数学的に言うといわゆる幾何学(図形を扱う分野)ではなく、例えばフランスの数学者・ド・モアブルは解析的に確率論を用いた手法で円周率を求めたりした。厳密な値を求めることから少しそれて、円周率が無理数であることは知られている。無理数とは、ご存知だろうか。Design3月号あたりを参照いただきたいが、無理数とは「分数で表せない数」である(個人的には実数のうち有理数でない数、と言いたい)。円周率が無理数であることは古代の哲学者(といってしまっていいのか疑問の余地はあるが)アリストテレスによって予想されていた。それを1761年にドイツの数学者・ランベルトによって証明される。円周率は2000年くらい、よくわからない数だったのだ。円周率ついに割り切れる」というニュースを真に受けている人とあったことがある。その後、様々な方法で円周率が無理数であることの証明がされている。無理数である以上、小数点以下の最後の数というのはないのである。1900年代に入ると、コンピュータの登場で躍進する。天才として名高いフォン・ノイマンによるノイマン型コンピュータの開発により、2037桁まで計算された。その後はアルゴリズムの進歩はありつつも、コンピュータの進化によって今回のような莫大な桁数までの円周率が計算されている。それほど膨大な円周率をどのように求めるか。最初は上で図示したとおり、図形によって計算していたが、徐々に解析的な手法での計算方法が編み出され、アルゴリズム化された。知られているが、こういった式は円周率を求めるのには不向きである。円周率を求めるには、収束速度が鍵となる。収束速度とは簡単に言えば、一気にある値に定まる速度である。青いグラフと赤いグラフだと、右に行くに従って赤いグラフのほうがはやく0に近づいていることがわかる。円周率を求める際にも、できる限り早く円周率に近づく数式を使ったほうが効率的である。いくつか有意義な円周率の求め方を紹介する。インドの数学者・ラマヌジャンが発見したラマヌジャン法である。ラマヌジャンは次のような式を考案した。このような数式を求められたのはラマヌジャンくらいのもので、神が教えてくれない限り思いつくわけがない数式をラマヌジャンは発見している。ラマヌジャン法は精度が高く、また収束速度も早いことが知られている。モンテカルロサンプリング法という方法もある。これは数式というよりもアルゴリズムで、正方形の中に正円を書きランダムに点を打って、円の中に点が入る確率を求めるというものである。プログラミングをしてもそれほど難しくなく実装できる。最近まで使われていたかなり精度も高く収束速度も早いアルゴリズムで、ガウス=ルジャンドルのアルゴリズムがある。詳しくはWikipediaを参照してもらえるとわかるが、ラマヌジャン法よりもとてもシンプルに求めることができる。実際に、2009年までの円周率の最高桁数、約2兆6000億桁はガウス=ルジャンドルのアルゴリズムで求められた。今回はどのような方法で求められたのだろう。今回はアメリカの数学者・チュドノフスキー兄弟によって考案されたチュドノフスキーのアルゴリズムが使用された。嫌にならないでほしい。チュドノフスキーのアルゴリズムは次のとおりである。記事を打っているだけでも嫌になってしまったが、今回の結果はこの数式が使われた。Wikipediaに書いてあったため、一応Pythonでのコードの例も記載する。プログラムに起こすと少しは簡単に見えるかもしれない。単純にループして計算しているだけだ。円周率を求めるには、アルゴリズムの選定はかなり重要だ。現実的にはむしろ、コンピュータの性能がものをいうのである。Googleは演算に特化したスーパーコンピュータを持っている。これが今回の結果につながったことは街がないと言える。すごいコンピュータを使えばいいというわけでもない。コンピュータ内でのCPUやメモリの効率化や分散方法など、様々な条件を整えなければならない。数学だけでなく、技術力も試される世界だ。今回、円周率は約31兆桁計算された。これまで人類が知ることができなかった桁の円周率がわかったということである。これは本当に正しいのか?正しいと誰が判断したのか?円周率の正しさを証明するために使われるのはまた数学だ。今回の検証では、2つの数式によって確認された。ベラードの公式は、BBP法よりも高速に計算できることが知られている。ベラードの数式は次のとおりである。ここまで読んだのだから付き-合ってほしい。BBP法は次のとおりである。打ち込んだと褒めてほしい(褒めなくて良い)。これらの数式は高速で円周率を計算できる。「ではこれを使えばいいのではないか?」と思うだろうが、そうは簡単には行かない。ベラードの公式とBBP法は両方とも、任意の桁数目の円周率を高速に求めることができる数式なのである。そのため、すべての桁数を求めることはできるが、その1桁ずつ求めていく必要があるため時間がかかってしまう。そのため、他のアルゴリズムで計算された数式の確認にのみ用いられるのである。数学的にはそれほど新しい技術が使われていないが、Googleの世界最高峰の人材と技術が成し遂げた結果である。漠然と「円周率を求めただけじゃん」と思ってしまうが、上でも言ったとおり、数学的には具体的な円周率を知ること自体にそれほど興味はない。円周率を求めることは、コンピュータの性能を計る手段であり、それが今までの結果を圧倒する計算スピードとなったのである。今後量子コンピュータが完成すれば、おそらく円周率の桁数は兆とか京とかそのレベルではない計算ができるようになるだろう。「2位ではだめなんですか?」とか「三角関数なんて誰が使うんですか?」などと政治家が言っている国では、とても追いつけるものではない。昨日作ったスクリプトをアップデート。いっても、アップデート前にデータベースのバックアップ処理を行うというもの。スクリプト内のSPANの値を変えれば、バックアップデータを残す期間を変更できる。