「RSA」を含む日記

■anond:20240629085310

Akiraの場合

Akira Ransomwareは、近年特に注目されているランサムウェアの一つで、その動作は高度で多様な手法を取り入れています。以下に、Akiraランサムウェアの動作について詳しく説明します。

動作の概要

侵入経路

Akiraは主にフィッシングメール、リモートデスクトッププロトコル（RDP）の悪用、既知の脆弱性の悪用などを通じてシステムに侵入します。特に、未修正のソフトウェアやシステムの脆弱性を狙うことが多いです。

初期感染と展開

システムに侵入すると、Akiraはネットワーク内で横移動を試みます。これは、ネットワーク内の他のデバイスにも感染を広げるためです。横移動には、認証情報の窃取や利用可能なネットワーク共有の探索が含まれます。

暗号化プロセス

ファイル暗号化の前に、Akiraはターゲットシステムの特定のディレクトリをスキャンし、暗号化対象のファイルをリストアップします。次に、強力な暗号化アルゴリズム（通常はAESとRSAの組み合わせ）を使用して、ファイルを暗号化します。

最近のバージョンでは、部分的な暗号化手法（インターミッテント暗号化）を採用することで、暗号化速度を上げつつ、検出を回避する手法が確認されています​ (Bitdefender)​。

データの窃取

暗号化に加えて、Akiraは重要なデータを盗み出し、そのデータを公開することで二重に脅迫することがあります。これにより、被害者に対する身代金要求の圧力を強化します。

身代金要求

暗号化が完了すると、被害者のデスクトップに身代金要求メッセージが表示されます。このメッセージには、データを復号化するための手順と支払い方法が記載されています。通常、暗号通貨（ビットコインなど）での支払いが求められます。

特徴的な技術

RustとC++の利用

Akiraの一部バージョンはRustというプログラミング言語で書かれており、これによりコードの安全性が向上し、セキュリティ研究者による逆コンパイルが難しくなっています。また、C++で書かれたバージョンも存在し、多様な環境での実行が可能です​ (CISA)​。

VMware ESXiの標的化

Akiraは特にVMware ESXi仮想マシンを標的とすることが多く、これにより企業の仮想環境全体に影響を与えることができます。

多層的な攻撃手法

Akiraは単純なファイル暗号化にとどまらず、データ窃取やネットワーク内での横移動、他のマルウェアの導入など、多層的な攻撃手法を組み合わせています。これにより、攻撃の成功率を高め、被害者に対するプレッシャーを強化します。

Permalink | 記事への反応(0) | 09:00

ツイートシェア

■anond:20240309075252

世界最大の素数は、RSA社の金庫にしまわれている(たぶん嘘)。

Permalink | 記事への反応(1) | 13:57

ツイートシェア

■「SSL/TLSの鍵交換にRSAは使われない」「電子署名=秘密鍵で暗号化は間違い」

こんなしょーもないことを何年も言い続けてる病人、ヤバくね？

Permalink | 記事への反応(1) | 23:36

ツイートシェア

■anond:20221014012607

IMFが一昨日発表してますね

ご参照ください

IMF Growth Forecast: 2023

USA🇺🇸: 1%

Germany🇩🇪: -0.3%

France🇫🇷: 0.7%

Italy🇮🇹: -0.2%

Spain🇪🇸: 1.2%

Japan🇯🇵: 1.6%

UK🇬🇧: 0.3%

Canada🇨🇦: 1.5%

China🇨🇳: 4.4%

India🇮🇳: 6.1%

Russia🇷🇺: -2.3%

Brazil🇧🇷: 1%

Mexico🇲🇽: 1.2%

KSA🇸🇦: 3.7%

Nigeria🇳🇬: 3%

RSA🇿🇦: 1.1%

http://IMF.org/WEO-oct22 #WEO

Permalink | 記事への反応(0) | 01:40

ツイートシェア

■anond:20210718103715

たとえば、RSAの暗号理論は計算機の有限時間内の演算が難しいという特性を使っているわけじゃん。つまり「暗号化されたものは確実に復号できるという特性を持ち、かつ有限時間以内に割り切れる可能性がほぼ無い」という特性を持つことは数学的にも正しく、計算機科学でも成り立つ事実じゃん。SHA-1 がハッシュ暗号として脆弱なのは、異なるファイルで同じハッシュ値を作れることが PoC されたことであって、数学的に脆弱性が解読されたわけじゃないだろ？もし、数学的にこの脆弱性がわかっていたら、もっと早い段階でハッシュの衝突が起きていたと思うのだが、違うのかい？一応は SHA-1 で衝突が起こることは数学的に予期されていたが、これだけハッシュ破りに時間がかかったのだから、有用性はあったとはおもうけどね。

Permalink | 記事への反応(0) | 15:54

ツイートシェア

■メインストーリー5章の感想とそのほか

はてぶ匿名初めてなのではてな記法使えません。

ディアソムニア寮箱推しです。

大前提として、ディズニー映画の知識はウェブであらすじ見ましたくらいしかありません。ツイステの元ネタは原作の方読んでたし映画はわざわざ見なくていいかなって……実写のマレフィセントは見ました。

リドルとジャミルの贔屓も意見を目にするまでちらっとも思ってませんでした。意見を見ても「まあリドルくんはマブダチの寮長だから我々のお母さんポジだもんな……」とか考えてました。シェフまでは。ジャミルに関しては意識もしてませんでした。後編2までは。

5章で気になった点を、読みやすさとか考えずに書いていきます。ても更新遅すぎて気になったところあんまり覚えてません。長いので読み返す気もあんまりわかないです。あとキャラディスが入ると思います。ごめんなさい。

【前半：エペルに話してたヴィルさんの自論超腹立った】

ここのシーンあまりにも嫌いなので記憶から消し去ってるんですけど、

エペルは強い男らしい筋肉がなりたい自分の姿で、それとは真反対である愛らしいしぐさに嫌悪感を抱いているような描写があったと思います。それに対してヴィルさんは、男らしいだなんて前時代的な考え！みたいな感じのことを言ってましたよね。そしてここがTwitterで絶賛されてたと思います。

私はここの部分ピンポイントで嫌いです。いや確かに好きな服を着て振る舞うのはいいかもしれないし、そういう感じで絶賛されてましたけど、それ嫌がってる人にお前の考えは古い！！！って言って強要してるの地獄でしょ。少なくとも私は嫌です。

ていうかエペルには外見に似合う可愛さを要求しておきながら自分は悪役の仕事断るやん！相手がネージュくんだったからなのかもしれんけど！なに！？自分の発言覚えられへんのか……！？　エペルにあんなこと言うんなら受けろやその仕事……（この時点ではこういう矛盾を意図的に配置してオーバーブロッドの伏線にするんだろうな〜と考えていました）

【後編：最終章にむけた準備を進めてるのはわかるけどユニーク魔法なんとかならんかったん？】

呪いのジュースは詳しい人が言ってるし割愛します。多分これTwitterで「カリムの特技が毒の判定だからヴィルの仕込んだ毒をカリムが見つけるんだ！」ってめっちゃ言われてたから公式がそういう展開避けたんじゃないですか？知らんけど。1つ言うなら、殺意を隠せてない暗殺はちょっとずさんすぎる……です。　ちなみにここが原作映画の踏襲！とかも知りません。私の知ってる狩人は「可愛い子に命乞いされたわ〜まあここで殺さなくてもこんな所で生きられんし女王の命令は達成できるしな！逃がしたろ！」ってイノシシの肝持って帰った人です。詳しい人教えてください。

簡単に言うと、ポムフィオーレ寮の話なのにユニーク魔法判明したポムフィオーレ生がヴィルさんのヤツだけなのはおかしい、です。1年生の元田舎ヤンキーエペルが持ってないのはともかく、ルークのユニーク魔法は匂わせもないやん。正確に狙った位置に何かを投げるってマレウス様もできますしユニーク魔法ではないし。もしかして目分量で身体測定できるやつがそうですか？そんなこと言われたら泣くが……？

あとポムモブ生でなさすぎて悲しい。2章の方がでてたやん、バトルもしたし。もしかしてポムメイン章は2章だった……？？

【後編：見せ場全部マレウス様が持ってったじゃん…………】

ディアソムニアのオタクなので、唐突に出てくるマレウス様とかシルバくんとかしか見えてないんですけど、それでもあの時のマレウス様の登場はおかしかったと思います。どこの世界にその章の主役たちより目立ってるその後のメインする人がおんねん。ツイステッドワンダーランドにいます。まあマレウス様は強いから……で済ませられるほど穏やかなオタクでは無いです……。

あとヴィルさんのオーバーブロッドを知ってる人数が少なすぎる。少なくとも今まで各寮生は目の当たりにしてたのに今回ぶっちぎりで少ない。モブ生の存在覚えてます？

【後編：ジャミルソロパートいきなり何？】

これを言ってる人すごく多いので私の簡単な感想のみ書きます。

練習の時に、

ヴィル「オーディションの時にダンスが1番上手かったのアンタだから、ソロパート入れるけどいいわね？」

ジャミル「わかった」

くらいのやり取り入れろよ……なんで「あ〜ジャミルはダンスが得意だから、映えるしソロパート入れたんかな〜」ってこっちが察さなきゃいけないんだよ。推理小説か？　推理小説でもこんなことしませんが？

まあ単純にリズミック班との連携不足ですよね。絶対報告足りてないわ。でもソシャゲはスケジュールがギリギリになりがちなので（メンテ中に実装するやつ頑張って作ってるとかある）最終チェックする時間なかったんだと思います。

【後半：なんで出場者が投票権持ってんの？】

そもそもあれってVDCの出場者に投票権が無ければ良かったんですよ。

わかってる範囲でNRCの出場者は『ヴィル、エペル、ルーク、カリム、ジャミル、エース、デュース』の7人で、RSAの出場者って『ネージュと7人のドワーフ』で8人じゃないですか。もう出場者の人数差で公平ではないですよね。まあたかが1票差ですけど……いやすみません1票差でナイトレイブンカレッジ負けたんでした。

あと個人的にネージュくんはNRCに投票して欲しかったな……ほら……ネージュくん、「ヴィーくんたちのすごかったから、僕NRCに投票したんだ！」くらい言いそうじゃないですか……？そうしたらヘイトも下がったと思いません……？

世界規模の大会に見えなかったなあの意見は私もそう思います。合同文化祭？

【後編：ヤッホー斉唱なに？】

そこは校歌でしょ（日本人並感想）

NRC側にヤッホー歌うことを提案してくるなら、ネージュくん側もNRCの曲歌って欲しかったですね。ちょっとネージュくんに高望みしすぎたかな……まあみんな高校生だし仕方ないかな…………

これに関しても既に散々言われてるのでこれ以上は言いません。

まあミュートでツイステやってるのでみんなが何を歌ってたのかTwitter見るまで知らなかったんですよね。困った時は脳内で蛍の光を流しておけの精神に基づき当時私の中では全員蛍の光歌ってました。

推したちに盲目な自分でも、結構違和感のあるシナリオだったなと思います。前半が多少読み応えあっただけに残念です。

ルークの壁紙の裏って獲物の隠し撮りだと思ってたけどつまりあれってネージュくんのブロマイドなんですよね。ネージュくん要素、ちょっとでもあればな……こんなことにはならんかったやろうなあ……

マレウス様がマニア気質があるので正直7章怖いです。今回の不満点って推しではないから、冷静に見れてたとは思うんですが、7章で同じようなことされたらブチギレると思います。すみません既にマスターシェフと茨の信奉者の件でキレてます。

お目汚し失礼いたしました。

Permalink | 記事への反応(1) | 05:23

ツイートシェア

■ツイステ5章でヴィランが勝てなかった話

ツイステ5章後編2配信されましたね。

ライターのせいでルークとネージュがヘイトサンドバッグになってるのが辛い。

あの展開ならサンドバッグになるのが当たり前で擁護ができなくて辛い。

これはこの二人が悪いんじゃなくて展開が悪い、ネージュに対してはライターからの悪意すら感じる。

ヴィランがヒーローを打ち倒すと言うのはやっちゃいけないというこの世界のルールは分かってます。ディズニーではヴィランが勝っちゃいけないし。

でも示し方が最悪。

マジフト大会でNRCが負け続けているというのは理由がありました。

RSAはチームワークが完璧で、NRCは我が我がと自分ばかりで他人を顧みないスタイルだから。これは負ける理由が明らかですし、真っ当だから救いもある。

個人プレーが悪いとは言いませんが、ここで示された理由なら、ヴィランでも改心(皆で協力)したら勝てるチャンスがありそうで希望を持てます。

でも5章は？

私はVDCがダンス甲子園のような、本当にプロを夢見てたりする子たちが日々研鑽して努力をして優劣を競い合うガチの大会だと思っていました。

NRCがガチで仕上げてきたRSAに負けるなら、それは仕方なかった。

ヴィランが負ける世界という摂理に照らし合わせたとしても、こっちがしてきた努力を相手が上回ったのだろうという背景があるから納得できます。

でも結果は、ヴィランは真っ当に努力を重ねたとしても、ヒーローが同じ舞台に立って仕舞えば、それが例えパフォーマンスにすらなってない思い出作りのお遊戯会だとしても負けてしまうということを示されただけだった。

本当に何を伝えたかったのか分からない。

RSAが優勝しNRCが勝てないのは分かっていました。でもどうしてお遊戯会にした？

悪役が悪役たりえるのって悪いところがあるからでは？

真っ当に努力して、しようとした悪いことも未遂に終わってこの結末って何？

ネージュがお遊戯会で出場したこと、そしてルークの一票で負けてしまった設定にしたこと、そしてあのタイミングでネージュファンであることを明かしてしまったこと、それが本当に最悪でした。

ルークがネージュに入れた理由は納得できるものです。

けれど、それによって勝敗が決し、ルークを戦犯に仕立てあげるストーリーは一体誰が喜ぶのか分かりません。

原作忠実とか狩人の役目とか、まず示し方が最悪です。原作忠実の話が見たいなら原作見ます。

タイミングも内容も失望するしかできない事でヴィルとプレイヤーを裏切るのが狩人の役目なら、そもそもVDCに出ないで欲しかった。

重ね重ね言いますが、世界の摂理は分かります。ナイトレイブンカレッジに所属してる時点で正義には勝てません。

彼らには悪いところがあり、だから勝てない。

そう信じていただけに、真っ当に努力をした人間はヒーローのお遊戯会に負けてしまうという5章は本当に心底、大嫌いです。

Permalink | 記事への反応(1) | 13:30

ツイートシェア

■公開鍵暗号方式を理解するのってなかなか難しい

anond:20200608212713

元エントリーの人がどこまで理解しているか不明だけど、自分が初心者だったときこういう説明がほしかったという話をしてみる。

暗号方式、特に公開鍵暗号の理解が難しいのはいくつか理由がある。

①物理的なものに例えられない

②素朴な利用例が少なく応用的な利用がいくつもある

③実際の利用例はアプリの一機能になっていて見えづらい

また、ざっくりした概念以上のものをきちんと理解しようと思うと

④何がどのくらい安全で何がどのくらい危険かセキュリティ的な概念の説明

⑤数学的な仕組みの説明

が必要になり、これがまた挫折の原因になる。

ここでは自分的にこういう順番で概念を把握していったという流れを書いてみる。

利用者から見た公開鍵暗号の特徴

まず、物理的な錠前や書留郵便をイメージするのはあきらめてほしい。

あくまでもデジタルデータを別のデジタルデータに変換して再び元に戻すためのものだ。

公開鍵暗号登場以前は、パスワードを使って変換（暗号化）して、同じパスワードを使って元に戻す（復号化）という共通鍵暗号の時代が長く続いた。

そこに、ひとつの大発明があった。

それが暗号化のパスワードと復号化のパスワードで異なるものを使うという技術だ。

・特殊な数学的アルゴリズムでパスワード１から、それと対になるパスワード２を生成する

・パスワード２からパスワード１を逆算することは困難

・パスワード１で暗号化したものがパスワード２で復号できるだけでなく、その逆つまりパスワード２で暗号化したものがパスワード１で復号できる（※）

今はその数学的アルゴリズムまで理解する必要はない。ただそういうことが可能になったというだけでいい。

パスワード１（秘密鍵）を自分以外が見られないように保管して、パスワード２（公開鍵）を通信相手に渡せば暗号通信ができそうということは理解できると思う。

ちなみにこのパスワードの長さは、プログラムで生成した100桁以上の数字が使われることが多く、それを定型的な千文字程度のテキストにして使われるのが一般的。

ツールで生成すると千文字程度のテキストファイルが秘密鍵用と公開鍵用の2個できる。

これだけの桁数なので暗号化復号化の計算はそれなりに時間がかかる。（※）

（※） このあたりは一般的な公開鍵暗号というよりRSA公開鍵暗号特有の話も混ざってます。詳しくは専門書参照

応用的な利用

次にこの発明を使ったらどういうことができるだろうか、応用できる先を考えてみよう。

(a)秘密鍵で暗号化した文書を送るね。公開鍵は〇○○だよ

誰でも最初に思いつく例だけどシンプルすぎて共通鍵と変わらなくありがたみがない。

(b)僕にメッセージを送るときは僕の公開鍵で暗号化してね（いわゆる公開鍵暗号）

これだと「僕」以外は秘密鍵がなく復号できないので安全。

メッセージの送信先を間違って別人に送ってしまっても他人は読めないし、経路のどこかで盗み見や内容の一部を改竄されたりすることがない。

メッセージに返信するときは今度は「僕」ではなく相手の公開鍵を使って暗号化する。

(c)本文を毎回全部暗号化すると時間がかかるから共通鍵を君の公開鍵で暗号化したものを送るね。それを君の秘密鍵で復号したら以降は高速な共通鍵暗号で通信しよう（鍵交換）

共通鍵暗号の高速性というメリットを利用できて、かつ生の共通鍵がネットに流れるリスクを排除した良いとこ取りの方式。

(d)暗号化しない本文と、本文から計算したハッシュ値を秘密鍵で暗号化したものを送るね。公開鍵で復号化したハッシュ値がそっちで計算したハッシュ値と同じなら本文は改竄されてないよ。

それからこの暗号化は僕しかできないから確かに僕から送られた文書、僕から送られた内容であると保証できるよ。（電子署名）

この「電子署名」の実現により、さらに次のような応用が可能になる。

(e)ログイン時に毎回パスワードを打つと見られたりして危険だからユーザ名等に署名したものを送るね。公開鍵で復号（検証）OKならログインさせて（公開鍵認証）

(f)僕は信頼できるよ。これがAさんの署名入りのお墨付き。検証してみて。

Aさんは信頼できるよ。これがBさんの署名入りのお墨付き。検証してみて。

Bさんは信頼できるよ。これが世界一信頼できる人の署名入りのお墨付き。検証してみて。

（サーバ証明書）

アプリの一機能としての見え方

前項のようなやりとりはほとんどアプリが自動的にやってくれるので、コンピュータ技術者以外の人が公開鍵や秘密鍵を直接扱う機会は現状ほとんどないと思う。

ウェブブラウザのアドレス欄に鍵マークが表示されていたらそれは鍵交換やサーバ証明書技術が使われていて、鍵マークを右クリックすると証明書を表示できる。

メールアプリでも最近は自動的に鍵交換やサーバ証明書が使われている。

もしメールアプリにPGPの設定オプションがあればそこで公開鍵と秘密鍵を設定すると特定の相手と本格的な暗号化メールがやり取り可能になる。

サーバ操作するコンピュータ技術者だと公開鍵認証もよく使われていて、ツールで生成した公開鍵をサーバに登録してログインに利用してる。

Permalink | 記事への反応(1) | 20:11

ツイートシェア

■anond:20180728230300

virtually all：事実上すべてって訳す人いるの?と思いましたが…

WordReference.com - Language Forums - virtually allで、

virtually allは、ほぼ全て(almost, but not quite, all)だと思うんだけど、どうよ?

地域(BE or Au E or RSA E or any other E)によって違いがあったりするの? という感じの質問が出ていたので、

それを参考にするといいと思います。

てか、何故、正答例を載せておかないかな…もしかして、そこが初心者の間違いの1つだったのか?

Permalink | 記事への反応(0) | 21:33

ツイートシェア

■五輪開会式の入場行進を「いろは順」にしたら

• 上記配列は日本開催の時にしたが、順位はそのまま。
• 国・地域名の表記は https://www.joc.or.jp/games/olympic/code/ に拠ったが、右記は変更した:「西サモア→サモア」「英領→イギリス領」「米領→アメリカ領」
• 日本語文字列照合順番になってたらいいなあ。

Permalink | 記事への反応(0) | 23:03

ツイートシェア

■応用情報技術者試験を受けてきました

anond:20170911232449

上の日記を書いた増田です。

こんにちは。

試験、受けました。

ことさら話題にするようなことでもないかもしれませんが、せっかくなので書きます。

これから受ける人などの参考になれば幸いです。

プロフィール

30代。

普通科高卒。

製造業。

プログラミング歴は数ヶ月。

それまではExcelWordがちょっと分かるくらいだった。

言語はVBA、VB、バッチ。

一ヶ月に100行書いてるかどうかといった感じ。

製造現場で身体を動かしながら、改善の種を探している。

所持資格はTOEIC700、日商簿記2級など。

基本情報は受けたことがない。

初受験。

動機

内製のソフトがC++でできていて、これを色々弄くれるようになればあんなところやこんなところまで自動化できるなあ、でも何も知らないまま弄るのはちょっと怖いなあ…

そうだ、勉強しよう！

合格すればついでに報奨金(10万)も貰えるしね！

勉強期間、学習時間

8月半ば、受験申込期間の締め切りギリギリに試験の存在を知り応募。

勉強期間は2ヶ月ほど。

平日は1日1〜2時間。土日は1日3〜5時間。まったく勉強しなかった日が10日ほど。

体感的な総学習時間は100時間ほど。

学習方法

最初に、ネットで評価の高かった合格教本という本を買って読んでみた。

基本情報の知識もない状態だと、書いてあることがもうほんとにまったく分からず、挫折しそうになった。

方針を変えて、応用情報技術者試験ドットコムで過去問道場をひたすら回した。

分からない言葉はネットで調べて、これはと思う説明に出会ったらOneNoteにひたすらコピペした。

最後の2週間はドットコムでユーザー登録をし、理解度で問題を色分けするようにした。

最後の1週間でピヨ太くんのサイト(正式名称長い)を見つけ、分からない言葉はまずこのサイトで検索するようにした。

午後対策は過去問を本番と同じ時間で4回分解いたくらい。

合格教本は結局ほとんど読まなかった。

午後の選択問題

受験前は、

• 経営
• アーキテクチャ
• ネットワーク
• 組込み
• 情シス
• プロマネ
• サビマネ
• 監査

…のどれかを選ぼうかなと考えていた。

いわゆるストラテジ、マネジメント系科目だけで固めても良かったのだけど、組込みなんかは普段の生活からイメージしやすいし、2時間半の長丁場ならテクノロジ系科目を間に挟んだ方がほどよく頭のリフレッシュになるかなーと思っていた。

実際の試験では、

• 経営
• 組込み
• サビマネ
• 監査

…を選んだ。

試験当日(午前)

試験会場に時計がなかったので、時計が無い状態で受験した。

机上に置けるような時計は持っていなかったし、まあ午前だけなら時計が無くても大丈夫だろうとタカをくくっていた。

問題を順当に最後まで解いて、全て順番通りにマークされてることを確認してから、手を挙げて外へ出た。

出てからスマホの電源を入れて時間を確認した。

15分ほど余っていた。

試験当日(午後)

さすがに午後は時計が無いとマズイと思い、休憩中に買ってくる。

セキュリティ(必須問題)の設問1で長考してしまい、20分ほど経っても解答用紙の半分が埋まっていない状態。

とりあえず他の問に移り、最後に余った時間でセキュリティに戻る方針にシフト。

経営はぱっと見簿記の知識が生かせそうだと思い選んだのだけど、「固定長期適合率」がどういう計算式なのか見当がつかない。

早々に切り上げる。

組込みの設問1でまたも長考、ほぼ解答を埋められたものの、結局40分ほど費やす。

この時点で残り1時間と少ししかなく、かなり焦る。

サビマネ、監査は焦りから問題文の通読ができず、設問を最初に読むようになり、結果読み返しが増えてしまった。

監査を終えたところで5分くらい余ったので、這々の体でセキュリティに戻る。

なんとか穴埋めし、フィニッシュ。

午前とは逆に、始終時間との戦いだった。

自己採点

午前は78.75点。

午後は厳しめで53点、甘めで66点(TAC基準)。

セキュリティ、サビマネ、監査の点数がかなり流動的。

午前は問題用紙に選んだ選択肢に○する余裕があったのだけど、午後はそれがなくなって、問題解くのに必死で自分が何を書いたかしっかり思い出せない。

色々と書いたけれど、そういう訳で正直受かってるかまったく分からない。

配点、部分点次第といったところ。

怖い。

感想

午前の対策は簡単だ。

ただ過去問を解くだけのロボットと化せばいいだけ。

体感3割〜4割くらいは過去問の流用で問題ができあがる。

いわゆる一般常識で解ける問題も多い。

午後の対策が難しい。

午後対策でよく見られるのは「国語の読解力をつける」というアドバイスだが、読解力というのは漠然としていてレベルの向上も分かりづらい。

今の私なら、以下の順番で勉強を進めるかもしれない。

• 過去問を解く(試験本番で選択する時間を考え、制限時間は1問につき30分ではなく、29分くらいにする)
• すぐに答え合わせはせず、問題文に何が書いてあるか、頭の中で具体的にイメージできるようになるまで、時間をかけて読み込む
• 制限時間ありの解答と、なしの解答を並べ、先ほど出来上がったイメージから論理的に正誤の判断を導けるようにする
• 答え合わせをし、自分の作り上げた論理と他人の論理が乖離していないか確認する
• 以下、繰り返し

ま、受かってたらやらないんだけどね！

そもそも、「試験に合格するための勉強」に終始して、最初の動機がなおざりになっちゃった感が否めません。

「公開鍵暗号方式といえば、RSAだよね！知ってる知ってる」

…でもそれらがなんなのかはよく知らない、みたいな。

一つ確実に「分かった」と胸を張って言えることは、

分からないことは、調べればいい。

分かる人に、聞けばいい。

ってことですかね。

受かってなかったとしても、もう受けないかもしれませんね。

はぁ…10万欲しいなぁ…

以上で終わりです。

最後まで読んでいただきありがとうございます。

お疲れ様でした。

Permalink | 記事への反応(1) | 23:57

ツイートシェア

■anond:20160426145507 の続き

anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)

「普通の実装における」OAuth の代替品

適切な OAuth ベースの設計とはどのようなものか

ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

• ユーザが自分のアカウントに直接アクセストークンを生成できるようになっており、そのトークンを自分の統合したいソフトウェアに自分で施すことができるので、ばかげた要求や危険な転送やリダイレクトを回避できる。
• client_secret が、一般的なパスワードのように平文のまま渡されるデータとして機能するのではなく、それ自体では暗号学的な共通鍵であり、そこから認証コードを生成するようになっているシステムなので、ばかげた要求や危険な転送やリダイレクトを回避できる。この種のシステムでは一般的に、ユーザが自分の認証情報さえ持っておらず、SSO (シングル・サインオン) の仕組みを使うだけである。

とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。

Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。

ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。

JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。

これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

Permalink | 記事への反応(2) | 15:03

ツイートシェア

■LINE Engineers' Blog に掲載された記事を読み解こうとして力尽きた

http://developers.linecorp.com/blog/ja/?p=3591

Letter Sealing って何でしょうか。私気になります。

必要な範囲で、原文を引用しています。原文は先に引用元のアドレスと閲覧日時を記し、引用記法によって地の文と識別できるようにしています。

長すぎ；読まない

ECDHとAES256-CBC 使ってみた。通信相手の認証については読み取れない。

暗号化通信の流れ

図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています。

この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものの LINE のサーバーが受信したところで復号されて平文で保存され、サーバーから受信者までの通信路は暗号化されていると理解できます。文脈から、この流れを変えたいのであると推測できます。

SSLと公開鍵暗号

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：

加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っています。ユーザーに対してLINEアプリを提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバが接続されたときだけLINEサーバでのみ解析できる暗号化された安全なチャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全な暗号化を実現できます。

SSL はすでに時代遅れの代物で、 2015年秋現在は皆さん TLS を利用されていることでしょう。 Web ブラウザで SSL 2.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。

TLS では、公開鍵暗号方式や共通鍵暗号方式、電子証明書、暗号学的ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。

RSA に代表される公開鍵暗号方式は一般的に AES に代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。

このため TLS では、通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。

仮にメッセージの暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります。

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：

ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。

これは上で説明したとおり SSL や TLS でも行っていることです。

RSA を用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート（アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類）は、その通信路が安全であると判断できるか否かを決める大切な情報です。

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：

既存のRSA方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。

DH および ECDH による共通鍵暗号に用いる鍵の交換は SSL や TLS でも実装されており近年では広く使われています。 SSL より軽いと主張し、 SSL や TLS が公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。

なお SSL や TLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています。

つまり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは（ほぼ）独立です。

共通鍵暗号と暗号利用モード

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：

ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。

メッセージ認証と組み合わせない CBC はビット反転攻撃に弱いことが知られています。 GCM ではデータの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。 AESを GCM で利用するのは、 最近の TLS の実装では広く用いられており、 Google や twitter も利用しています。

CBC も CBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。

解決されない鍵管理問題

図6 のとおり、 ECDH で共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。

ここからは安易なパターンの想像ですが、通信相手の公開鍵情報は LINE ユーザー情報の一部として LINE サーバーで管理されており、必要に応じて安全な通信路を用いて LINE サーバーから取得するようなものではないかと思います。公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。

公開鍵と秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービスの要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵を LINE サーバーに預託していないことを祈るばかりです。

ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。

2015年10月17日 10時16分追記

先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。

ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全な通信路を確立する目的で ECDH 鍵を用いる場合、 LINE サーバーが用いる秘密鍵の漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージを暗号化する場合、ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます。通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH 鍵漏洩のリスクを天秤にかけて PFS を採用しないという判断かもしれません。

通信の秘密という観点ではメッセージの内容だけではなく誰と通信したか (または、していないか) という情報も守りたくなります。宛先を LINE サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。

Permalink | 記事への反応(0) | 00:27

ツイートシェア

■サーバ初心者がWebサービスを公開するうえで考えたこと

先だって、自作のWebサービスを公開しました。

http://www.radiosonde.net/

これまで他の人に用意してもらったサーバで自分のプログラムを動かしたことはありましたが

自分自身で一からサーバをセットアップしたことはほとんどなかったので、いろいろとハマりました。

作業を進める上で困ったり考えたりしたことを書いていきます。

ちなみにサーバ自体はさくらのクラウド、OSにはCentOSを使用しているので、それ前提のお話になります。

SSHとファイヤーウォールの設定

最初にサーバを起動してから速やかにSSHとファイヤーウォールの設定を変更しました。

はてブなんかでも定期的に話題になっているのでおなじみですね。

・SSHのポートを22以外の別のポートに変更する

・rootによるリモートログインを禁止する

・パスワードログインを禁止し、鍵認証を有効にする

・念のためrootのパスワードを潰しておく

・SSHやHTTP(S)など、どうしても公開しなければならないポート以外は遮断する

・SSHのポートについてIP制限が行えるならば尚良い

さらっと書きましたが、設定をミスって自分自身もログインできなくなり、何度かOSの再インストールを繰り返しています。

後から気付いた事ですが、さくらのクラウドではクラウド管理画面のリモートスクリーン経由でローカルログインできるので

別にOS再インストールしなくてもiptablesの設定を変更できたんですよね...

逆に言うといくらファイヤーウォールとSSHを設定しても管理画面にパスワードログインの環境が残ってしまうので

パスワードの管理には引き続きしっかり気を使う必要がある。ということでもあります。

Webアプリの動作が重い

httpd,php,mySQL,memcachedなど必要なサービスをインストール、設定し

作成したWebアプリのプログラムを乗せて動かしてみました。が、動作が重いような...

開発環境ではさくさく動いていたのに、本番環境ではどのページ遷移ももっさりしています。

abで計測してみたところ、開発環境のおよそ2分の1のスコアとなってしまいました。

開発環境が仮想2コアのメモリ1Gだったのに対し、本番環境が仮想1コアのメモリ2Gと

CPUの性能について半減しているのでそのせいかな、と思いつつ設定を見なおしていたところ

特に使っていないと思われたipv6を停止した途端にパフォーマンスが改善されました。

ページ遷移に伴うもっさり感が解消され、abの計測結果も開発環境と遜色ない結果が出ています。

デフォルトで有効になっていたipv6の影響により余計な処理が走っていたのかもしれません。

サーバから送信したメールが迷惑メールと判定される

パフォーマンス改善に喜んだのも束の間、会員登録などの処理でWebアプリからメールを送信したところ、Gmail宛のメールがことごとく迷惑メールと判定されるという事案が発生。

spfの設定を行なう、メールの内容について吟味するなどの回避策を試してみましたが一向に改善されません。

試しにHotMailとexciteのメールアカウントに送信したところ、そちらではそもそもメールを受け付けてもらえずエラーコードが返って来る始末。

困り果てていたところ、エラーの内容からサーバのIPがspamhousにスパム送信元として登録されていることが判明しました。

postfixのホスト名の設定がデフォルトで「localhost.localdomain」などとなっており、それをそのまま使っていたためにGmailがスパム送信元として通報してしまったようです。

設定を修正し、spamhousに解除依頼を提出。事なきを得ました。

KVSの変更

クラウドを利用すれば、サーバを停止することなく簡単な設定でスケールできるようになる。

と、自分で勝手に思い込んでいたせいなのですが、消えては困るデータの一部をmemcachedに保存する実装を行なっていました。

実際のところさくらのクラウドではサーバを完全に停止しなければプラン変更を実施できないし

そもそもサーバが落ちたらどうするんだよ。ということで、急遽KVSを変更する必要に迫られました。

速度の低下が気にかかったため、いくつかの候補を実際に動かし

phpのスクリプトから1万件のデータ読み書きを行うという形でmemcachedと比較してみたところ次のような結果に。

さすがに読み書きそれぞれmemcachedが最速ですが、読み出しについてはhandlersocketも負けていません。mySQLから普通にSELECTしてもmemcachedの2倍程度の時間しかかからないという結果が意外でした。

しかしながら書き込みのほうではhandlersocketもmemcachedの10倍近くの時間がかかっており、少々速度的な影響が気になってきます。memcachedの倍のパフォーマンスを記録したという記事を見たことがあるので、設定、チューニングについて生かしきれていない部分があるのかもしれないとも思いましたが、知識が不足しているところで無理をすると問題が発生した時に対処できないと考え、候補から除外することとしました。

結局、今回の用途では読み込み処理より書き込み処理のほうが圧倒的に多いことも考慮し、kyotoTycoonを採用しました。実際の利用箇所に組み込んでabで計測してみたところ、だいたい30%程度のパフォーマンス低下にとどまっており、これなら許容範囲かと考えています。

mySQLのレプリケーションが止まる

実行系と参照系に分ける形でmySQLのレプリケーションを行なっていたのですが、度々レプリケーションが停止する現象が発生しました。

一部のテーブルについて肥大する可能性が考えられたため、参照系に接続するプログラムで使わないテーブルをレプリケーションから除外していたのが原因です。

例えばtabelAをレプリケーションし、tableXをレプリケーションしないという設定にしたうえで

実行系でINSERT INTO `tableA` SELECT `value` FROM `tableX`などといったクエリを発行すると、参照系にtableXが無いためエラーが発生して止まってしまいます。

レプリケーションするテーブルを限定する場合はプログラム側でも注意を払わないと危険です。当たり前ですが。

サーバ監視にmonitを使用

監視といえばcactiやnagiosが定番なのかもしれませんが、設定が複雑そうで尻込みし、monitを使用することにしました。

簡単な設定でloadaverageやメモリ、HDDの使用量をチェックできるほか

httpdやmysqldなどといったサービスのプロセスを監視し、もし落ちていたら自動で起動してくれるので助かります。

Webアプリの秘匿

パスワード保護を行うとしても、サイト全体の管理画面など自分しか使わないプログラムはWebに晒しておきたくない。

というわけで、一部のWebアプリを秘匿する設定を行いました。

管理画面のWebアプリを9999番など閉じているポートに設置した上で、SSHを利用したトンネルを掘ります。といっても

ssh -t -L 9999:localhost:9999 user@xxx.xxx.xxx.xxx

上記のようなコマンドで管理画面のWebアプリを置いたサーバへログインするだけです。

ブラウザのアドレス欄にhttp://localhost:9999/と打ち込めば、接続が開いている間のみアクセス可能になる感じですね。

サーバにログインできる人でなければ実行できないことなので、気分的にある程度安心します。

SSHでログのバックアップ

自動でログのバックアップを行いたいと考えたのですが、パスワード無しの鍵でログインして転送する形には抵抗がありました。

調べてみたところ、authorized_keysに公開鍵を記入する際の設定で、その鍵でできることを制限するという手段があるようでした。

具体的には、authorized_keysに

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="some commands" ssh-rsa AAAAB3NzaC1yc2EAAA...

などとして公開鍵を追加しておくと、その鍵でログインした直後にcommand=""の部分で設定したコマンドを実行して接続を終了する挙動となり

接続のフォワードもできなくなるため、パスワード無しでも鍵の流出に関するリスクを最低限に留めることができるというわけです。

commandの実行結果は標準出力から受け取ることができるので、例えばcommand=""の部分にファイルの内容を表示する処理を設定していたとすれば

ssh -i .ssh/no_password_key user@xxx.xxx.xxx.xxx > /path/to/file

などとしてログインの結果をファイルに書き込むだけで、簡単にファイルの転送が実現できます。

まとめ

他にも大小さまざまな問題に行きあたりましたが、忘れてしまったor書ききれないのでここまでとします。

たった1つのサイトを公開するにしても問題というのは尽きないものだと実感させられました。

今は基本的な情報だけでなく、ちょっと突っ込んだ内容でも検索で解決していけるので嬉しいですね。手がかりを残してくれた先達に感謝することしきりです。

現状ではひとまずの見切りを付けて公開していますが、より堅牢で負荷に強いサーバとなるよう、随時チューニングを行なっていこうと考えています。

最後に

作ったWebサービスについて少し書きます。

サイト名は「Radiosonde」

個人サイトや小規模な商業サイトなどプロモーションにあまりお金をかけられないサイトを主な対象とした、無料で出稿できる広告ネットワークサービスです。

既存のサービスで近いのは「あわせて読みたい」や「zenback」、各社提供のRSS相互リンクサービスなどになるでしょうか。

広告としての体裁がある分、それらより若干積極的な性質になるのではと考えています。

現時点ではサービス本体のプロモーションに苦心するという本末転倒そのものの状況でありますが、もしよろしければ見ていただけると嬉しいです。

Permalink | 記事への反応(1) | 16:58

ツイートシェア

■匿名性の無さ

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://anond.hatelabo.jp/20111006234714

http://twitter.com/i315 さんでしょうか

さてわたしも不登校なわけですが，お前とはどうかんがえても方向性が違うので
ただおもしろがって見ているだけにしますね!!!!

sora_h でした!!! 匿名性ないね!!!

追記: http://twitter.com/#!/Glass_saga/status/124131595606167554 ということでPGP署名を施しました．
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQEcBAEBAgAGBQJOlaZiAAoJEIHMzVZz47asMIsH/0AUmA8eAkXrtNzDVX7asUYs
5FO06sNUxMYZEeVDTyOwDsYxjPkDnW7QGe7na7ZRHFm1/WeaYepRhvf7Q4QePCjX
B0ZTPwt0liQpRecZIwh615UmDVv5nd6wLJiNNQZqJQc+CMfeT1tzqr/nwuqfTJSz
wU1MeVBVaxKbpl+iOIDGu/nbXlcTsNSE0gKieTuLFcoHOmXyKDwbF27+s2vt0TkK
oBwJZWZVCQRHTMCLSRc/iAaQnV6zjQpeRPVxyd8fzuLedcArKYGDQsgvpPP7Gycy
yxPuJHc5q5Q5LiHVYkcMQ1FzzGTKy7U0b5MIkm6es6qMutPTOM3CA7BA6fuGDgw=
=qKpD
-----END PGP SIGNATURE-----

gpg: Signature made Wed Oct 12 23:38:26 2011 JST using RSA key ID 73E3B6AC

gpg: Good signature from "Shota Fukumori <sorah@tubusu.net>"

追記2: リンク先だけ抜粋しときます

http://anond.hatelabo.jp/20111006234714

http://twitter.com/i315

http://twitter.com/Glass_saga/status/124131595606167554

Permalink | 記事への反応(1) | 23:23

ツイートシェア

■http://anond.hatelabo.jp/20100610112133

その解析に、現存するＰＣでは生きてるうちに終わらない程度の演算が必要であればいい。

なるほど。指定ツールでのビルド時にRSAとかでキーを生成しして自作ゲームのバイナリに埋め込むわけですね。

でもそれってコピーしたゲームのソースを、その指定コンパイラを使ってリビルドしてキーを付加すればいいだけ

なんじゃないかな。キー生成がブラックボックスでもコピー＋キーは生成できちゃうような。

ばらまく人に「指定ツール導入」＆「それなりの知識」という負担が増えるから多少はましな気もしますが、現状でも

ROMから抜くのはど素人じゃできないわけで、そんなに難しい話じゃない気が。

まあ、こういう方法があるのに、それをやらない、というなら自作文化はその程度の代物だった、ということで、

より納得しながら、滅びるのを眺められますｗ

PARは別に違法性ないよね？　メモリ改造ツールはマジコン問題とは切り離していいんじゃないかな。

Permalink | 記事への反応(2) | 11:46

ツイートシェア

■Rubyを最大63%高速化した中学生

@ITにて、＠ITの「Rubyを最大63%高速化した中学生は超多忙！」というインタビュー記事が公開されています。

これまで、Lispの“仏さま”竹内郁雄氏、東大博士課程の女性プログラマ五十嵐悠紀氏、プログラミング言語Cyanを開発した高校生　林拓人氏、その続編（「国語ができる（＝日本語できちんとした文章が書ける）人じゃないとプログラムは書けない」という竹内郁雄氏の発言の解説）に続く、連載物の一つである。

今回の記事の筑波大駒場付属中の3年生金井仁弘氏は、/.Jでも告知があった「セキュリティ & プログラミングキャンプ 2009」に参加し、Ruby1.9がRuby1.8よりフィボナッチ数列の計算で低速化しているのに着目、構造体の判定メソッドの一部をループの外に出すことで最大で約63%、全体で約8%の高速化に成功したと言う。また「RSA解読のためのフェルマーの小定理の証明」を授業で行っているなど、色々と興味深い内容だ。

皆さん、中三の夏に何してました？

Permalink | 記事への反応(3) | 21:40

ツイートシェア

■キモい趣味

20代半ばの理系な男ですが、合コンとかで初対面の人に趣味を聞かれたとき、

無難に「読書・映画」と言ってしまいます。

でも実は人には言えないキモい趣味を幾つか持っているので、

これが、どれぐらいキモいのか判別お願いします。

・素因数分解

趣味歴4年。

数ある素因数分解法をプログラミングで実装したり、

新しい素因数分解法を考えたりしています。

現在は数体ふるいに目処が付き、楕円曲線法に興味があるところです。

目指すはRSAチャレンジ！

・将棋

趣味歴3年。

主にハンゲームでやってます。300戦ほどして、勝率は6割ぐらい？

定石を覚えつつ、勝ったり負けたりの毎日。

（ハンゲだと終盤の詰め力が身につかないので、どうもなぁ…）

ネット将棋じゃ強くなれないのかと思って、将棋教室に通いたいと思っているのだけれど、なかなか機会が……。

・小説

趣味歴1年。

書きたい物語を溜め込む毎日。

プロットの書き方などは知らず、ただ駄文を書き連ねています。

誰にも見せないし、どこにも発表する予定は無いです。

以上３つです。土日はこの趣味で、生涯の研究課題＝素数、遊び＝将棋、妄想＝小説　としてパソコンに向かっています。

やっぱりどれも初対面の相手に言うべきことじゃないですよね………。

Permalink | 記事への反応(5) | 01:16

ツイートシェア

■フィッシング詐欺組織がトロイの木馬を併用する新攻撃

EMC傘下のセキュリティ企業RSAは4月21日、「Rock Phish」と名乗る犯罪組織がフィッシング詐欺とトロイの木馬を併用した新たな攻撃を仕掛けていることが分かったと伝えた。

　RSAによると、Rock Phishは欧州を拠点とする犯罪組織で、2004年以来、金融機関を狙ったフィッシング詐欺を仕掛けている。RSAの推定では世界各国で起きているフィッシング詐欺の50％以上はRock Phishが関与。ユーザーをだまして偽サイトで入力させたパスワードなどを使って、銀行口座から現金を盗み出している。

　今回この組織が、新たに「Zeus」というトロイの木馬の亜種を使い始めたことが判明したという。スパムなどから偽サイトに誘導されたユーザーは、そこで銀行口座などの情報を入力しなかったとしても、知らないうちにマルウェアに感染させられる。

　Zeusは感染したユーザーのコンピュータから個人情報などを収集し、外部に送信するトロイの木馬。これまでに150種類以上の亜種が出回っている。

　しかも今回のケースでは、Googleを思わせるURLを使ってマルウェアがホスティングされているため、セキュリティソフトも通過してしまう可能性があるとRSAは伝えている。

SEOスパム　検索スパム

SEO スパム

Permalink | 記事への反応(0) | 10:17

ツイートシェア