セキュリティ

IE では特定の URL を任意のセキュリティゾーンに指定できるが、その際の https 限定オプションは入力チェックとしてしかか機能せず、実際のサイト接続時にはチェックされない。

- 任意のサイトをイントラネットゾーンや信頼済みサイトゾーンに設定可能

Internet Explorer は、ウェブサイトをいくつかの「ゾーン」に分類し、それぞれ異なるセキュリティ設定を適用することができる。インターネットゾーンのサイトは厳格なセキュリティを適用し、イントラネット内のサイトは身内なのでゆるいセキュリティで利便性を優先する、といったことができる。

この設定はインターネットオプションの「セキュリティ」タブで設定できる。たとえば、イントラネットゾーンとして扱いたいサイトがある場合は「イントラネット」を選び、「サイト」ボタンを押し、「詳細設定」ボタンを押すことで URL を設定する画面に入れる。ちなみに設定画面には以下のように書いてある。

このゾーンに Web サイトを追加/削除できます。このゾーンのすべての Web サイトには、このゾーンのセキュリティの設定が適用されます。

- 「このゾーンのサイトにはすべてサーバーの確認 (https:) を必要とする」オプションは入力時のチェックでしかない

私の所属するチームでこの機能を実際に試していたところ、以下のオプションが有効にならないんだけど、という相談を受けた。

このゾーンのサイトにはすべてサーバーの確認 (https:) を必要とする(&S)

このオプションを有効にしても、http しかサポートしていないサイトに接続できてしまったとのこと。私の環境でも同じ現象が出た。

テスト環境は、OS が WindowsXP Professional With Service Pack2、IE が IE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 だ。

いろいろ試しているうちにわかったことが、このオプションは入力時にしか機能せず、接続時には機能しないということだ。さも接続時に https かどうかをチェックして、そうでなければイントラネット扱いしないという動きをしてくれそうな文言だが、そうではない。サイトの URL を入力する時にしか効かない入力チェックでしかない。

確かに、「このゾーンのサイトにはすべてサーバーの確認 (https:) を必要とする」チェックボックスをオンにしている場合、https: で始まらない URL をゾーン設定の URL として入力すると以下のメッセージが出る。

イントラネット

このゾーンに追加したサイトには、https:// prefix を使用する必要があります。この prefix は、セキュリティで保護された接続を保証します。

ここまではいい。しかし、ここの URL にはドメインだけを入力することもできる。オプションの挙動を把握していない人は以下のようなことをしてしまうだろう。

チェックを外した状態で http://sonic64.com や https://sonic64.com を設定。オプションをオンにすれば https の接続のみイントラネット扱いとしてくれることを期待し、チェックボックスをオンにして http://sonic64.com にアクセスする。この例では、ユーザーの期待に反してすべてのサイトが見事にイントラネットゾーンとして扱われてしまう。

また、チェックボックスをオンにする前に入力した http や ドメイン指定のサイトも入力チェックの対象外。この挙動は理解できなくもないが、設定済みのサイトに https: 以外で始まるものがあるという警告くらいは欲しい。

非常にわかりにくい。なぜこんな不完全な機能なんだろう? また、この不完全な機能でも、オプションの文言を工夫して入力時にしかチェックしないことを明示すればユーザーを適切に誘導できるはず。なぜそうしないんだろう?

暗号化に WEP しか使えないニンテンドーDS は無線 LAN のセキュリティを弱くする。

これは 2006-01-29 の「ニンテンドーDS を考慮した無線 LAN のセキュリティ設定」では本筋ではないので書かなかった。ユーザーの設定で解決するには難しく、完全に解決するには機器の買い増しなどが必要になるし、「より強固なセキュリティ」よりも「最低限のセキュリティ」を重視したからだ。

- ニンテンドーDS が WEP しか使えないという問題の本質

WEP よりも強度の強い AES (Advanced Encryption Standard) などを使っている 無線 LAN ネットワークにニンテンドーDS が参加する場合、ニンテンドーDS が使用可能な WEP までネットワーク全体の暗号の強度を落とさなければならない。

ネットワーク全体で AES などが使えなくなる。ニンテンドーDS が WEP しか使えないという問題の本質はここにある。

2006-01-29 では「WEP128 を使って通信を暗号化すればいい」と書いたが、WEP は暗号強度が弱いので本当は AES を使いたいところ。しかし、ニンテンドーDS が参加すると無線 LAN 全体で WEP を使わなければならなくなる。無線 LAN における暗号は、そのネットワークに参加するすべてのクライアントが使える方式を選択しなければならないからだ。

ニンテンドーDS だけ WEP を使って、他のクライアントは AES を使うということができればいいのだが、それをするためには後述する何らかの方法で 無線 LAN アクセスポイントを追加しなければならない。

- 解決方法は 無線 LAN アクセスポイントの追加

根本的な解決策は、ニンテンドーDS 専用の無線 LAN アクセスポイントを追加で設置することだ。

たとえば、IEEE 802.11b と IEEE 802.11a を同時使用可能な無線 LAN アクセスポイントを使う。ニンテンドーDS を IEEE 802.11b + WEP で接続し、他のクライアントは IEEE 802.11a + AES で接続すればよい。私の使っている無線 LAN アクセスポイント AirStation WHR-G54S では IEEE 802.11b にしか対応してないので、買い換えになってしまうけど。


または、Wi-Fi USB コネクタを使い、既存の無線 LAN アクセスポイントとチャンネルを離してそれぞれ独立した無線 LAN ネットワークとして運用する。

ただ、それだけのためにわざわざ Wi-Fi USB コネクタを買うのも不経済だ。PC を立ち上げていないと使えないし。

- ニンテンドーDS が AES に対応してくれればなあ・・・

SCE の PSP (プレイステーションポータブル) はファームウェアのバージョンアップで AES への対応を果たした。PSP はコンテンツ保護のために AES をハードウェアで処理する機能を持っているようなので、それを活用するようにしただけなのかもしれないけど、とにかく実現したことは素晴らしい。

“PSP”(プレイステーション・ポータブル）｜“PSP” システムソフトウェア アップデート
http://www.playstation.jp/psp/update/ud_01_hty.html

PSP システムソフトウェア バージョン 2.50の更新内容　[2005.10.13]

［ネットワーク設定］のセキュリティ方式に［WPA-PSK(AES)］を追加しました。

結局、ニンテンドーDS が AES をサポートしてくれれば済むことだが、コストをかけられないゲーム機では難しいのだろう。2006年3月発売予定と発表されたニンテンドーDS の軽量化版「ニンテンドーDS Lite」が AES をサポートしてくれればいいのになあ、と思ったりもしている。現行のニンテンドーDS よりも1800円高い価格設定とのことだし、やってくれるとうれしいんだけどな。

- 補足 AES (Advanced Encryption Standard) とは

AES について、Airstation のヘルプから引用。

AES

AES(Advanced Encryption Standard)は、次世代の標準暗号とし て米国NISTで採用されたデータの暗号/複合化方式です。このエアステーシ ョンではIEEE802.11i(WPA)を用いた場合、データの暗号化方式として指定 することができます(AES/CCM)。 従来の暗号化方式と比較し、第三者からの攻撃・改竄などに対して強く、 セキュリティを大幅に強化することができます。また、このエアステーショ ンはAES暗号/復号化のための専用ハードウェアを持っており、速度低下など のデメリットを受けずに強力な暗号を使用することができます。 また、AESを利用するためには、接続する無線LAN機器全てがAESをサポート している必要があります。

私は速度と強度のバランスがとれている AES が好き。AES については 2004-04-30 の「暗号技術入門 秘密の国のアリス を発注」で書いた「暗号技術入門」がわかりやすかった。2004-11-09 の「GMail をバックアップストレージとして使う」でも暗号化は AES256 を使っているし、2005-08-16 には「C# でファイルを暗号化・復号化する」というメモも書いた。

私はニンテンドーDSのWI-FIコネクションを利用した通信を行うために無線LANを導入した。ニンテンドーDSを繋ぐ事を考慮した無線 LAN アクセスポイントのセキュリティ設定についてのメモ。

- 私の無線 LAN 環境

ちなみに、私が利用している無線 LAN アクセスポイントは 2005-11-18 の「ニンテンドーWi-Fiコネクション用 無線LANルータ/アクセスポイント選び」で購入した、バッファローの AirStation WHR-G54S という無線 LAN ルータだ。私の無線 LAN には ニンテンドーDS のほかに、PC2台も接続している。

私はすべて手動で設定した。「AOSS」や「らくらく無線スタート」などの自動設定システムを使うと、セキュリティ的に甘い設定になってしまうかもしれないし、何より私はエンジニアなのでセキュリティと使い勝手のバランスをどう取るかを自分で決めたかったからだ。

- セキュリティ的に弱い無線 LAN を使っているとどうなるのか

無線 LAN のセキュリティが弱いままだと、以下のような事態を招くおそれがある。

他の人に勝手に無線 LAN に接続されてしまう。
無線 LAN では、何も制限していない場合は電波が届けばだれでも接続できてしまう。近所の子供がマリオカートのWIFI対戦のために接続してくるくらいならかわいいものだが、特定のサイトを攻撃する際の踏み台や、掲示板に殺人予告を書くために使われる恐れもある。

無線 LAN を流れるデータを読み取られる。
こっちは実際はあまり問題にならない。盗聴されると困るデータは、最初から暗号化されて通信することが多いからだ。ただ、Windows ファイル共有などではデータが暗号化されないので、財務データを記録したファイルなどを無線 LAN 上でやりとりするのはリスクがある。新たな情報漏洩の口ができるという意味で、有線の LAN のときよりはリスクが増えてしまう。

- ニンテンドーDS を接続する無線 LAN で最低限設定すべきセキュリティの項目は3つ

私が無線 LAN アクセスポイントに設定した項目は3つ。とりあえずこれだけやっておけば大丈夫。実は、この3項目はニンテンドーDS を接続するしないに関係なく、無線 LAN セキュリティの基本だ。

・指定した MAC アドレスを持つクライアントのみ接続許可する。
・SSID を知っているクライアントのみ接続許可する。
・WEP128で通信を暗号化する。

上記はどれか一個で十分というものではない。できる限りすべて実施しておくことが重要。攻撃側は一番弱いところだけを突けばよいので、防御側の私は弱いところをできる限り減らすようにする必要があるからだ。

- 指定した MAC アドレスを持つクライアントのみ接続許可する

MAC アドレスというのはネットワーク機器一つ一つに割り振られた ID。クライアントの MAC アドレスを無線 LAN アクセスポイントに事前に登録しておき、登録された MAC アドレスを持つ機器からの接続だけを許可する。

ただし、MAC アドレスを好きな値に変更できるクライアントもあるので、MAC アドレス自体を知られてしまうとクライアントを偽装されてしまう。MAC アドレス制限だけでなく、他の対策と組み合わせることが重要。

ニンテンドーDS 本体の MAC アドレスは、WI-FI コネクション設定画面のオプションで「本体情報」を見ることで確認できる。00-09-BF-64-64-64 などと表示される。

- SSID を知ってるクライアントのみ接続許可する

無線 LAN クライアントからアクセスポイントに存在確認要求があったとき、SSID が一致しないときは要求を無視するようにする。これにより「SSID を知っているクライアントだけにアクセスポイントが見える」という状態にすることができる。

SSID も MAC アドレスと同じく知られてしまうと効果がない。やはり他の対策と組み合わせることが重要。

ニンテンドーDS の WIFI 接続先設定画面で、無線 LAN アクセスポイントの SSID を入力できる。

- WEP128で通信を暗号化する

データを WEP キーを使って暗号化し、「WEP キーを知っているクライアントのみ通信ができる」という状態にすることができる。

ただし、WEP128の暗号化は強度が弱く暗号解読ツールも出回っているので、暗号化しているから絶対通信内容が漏洩しない、というわけではない。つまり他の対策と組み合わせることが重要。

暗号化方式には他に AES と TKIP があるが、ニンテンドーDS は AES も TKIP もサポートしていないので、これらを選ぶとニンテンドーDS を接続できなくなってしまう。WEP64 というのもあるが、WEP128よりも暗号化強度が弱い。現在のところ、WEP128 がニンテンドーDS で使用できる一番強固な暗号だ。

追記。おいでよ どうぶつの森に付いてきた「ニンテンドー Wi-Fi コネクション ガイドブック」19ページによると、ニンテンドーDS は WEP128よりも強固な WEP152 もサポートしている。しかし、私の AirStation WHR-G54S は WEP128 までしか対応していないので WEP128 を選択した。

ニンテンドーDS の WIFI 接続先設定画面で、無線 LAN アクセスポイントの WEP キーを入力できる。アルファベット13文字または 0-9とA-F までの26文字を入力する。

- 追記

追記。
2006-01-30 に「暗号化に WEP しか使えないニンテンドーDS は無線 LAN のセキュリティを弱くする」という記事を書いた。

タスクマネージャを見ていたら POP3Trap.exe という名前のプログラムが動いている。私には心当たりがない。もしかしてウイルスやスパイウェアか? とドキドキしながら Google で POP3Trap.exe を検索するとヒット。

POP3Trap.exe はウイルスバスターが起動するプロセスだそうだ。POP3 の通信を検疫するため、ローカルに POP3 プロキシを立てて通信を中継している模様。最初は気味が悪いと思ったけど、まあウイルスチェックのためだし仕方ないかな。

Outlook Express だと勝手に POP サーバの設定エントリを localhost に書き換えて POP3Trap を経由するように設定するとのこと。Mozilla Thunderbird だと今のところそういった設定に書き換えられることは無いみたいだけど。

scp と sftp について調べていると、正しい自動実行についての文書を見つけた。cron から scp や sftp を自動実行しようと考えている私には役に立つ文書だ。

- 「専用のパスフレーズなしの鍵を作って権限限定」がベスト

正しいssh/scpの自動運転は ぴろ日記
http://www.banana-fish.com/~piro/20040609.html#p06

おねがいだからパスワード入力をexpectで自動化なんつーバッド・ノウハウをWebで広めないでくれ。(略)
あとcronとかからssh/scpするのにssh-agentでパスフレーズ入力を自動運転ってのもバッド・ノウハウな。

正しいssh/scpの自動運転は:

自動運転専用の鍵をパスフレーズなしで作成する。
でもって、その鍵を使ってやれることを、いかにして必要最小限の作業だけに制限するかを考える

が正解(現時点では)。

必要最小限の作業に制限する方法としては、

毎回完全に同じコマンド(引数含めて)しか実行しないなら、authorized_keysでcommand='...'を使って実行できるコマンドをそれだけに制限。
ファイル転送用途だけなら、scponlyとかの転送用途に限定されたシェルをリモートのアカウントのシェルに設定する。
上記2つのケースには該当しないけれど、特定のコマンドに実行を制限したい時はrestricted shellとか。
可能ならchroot patchをあてたsshdを使ってchroot環境作るのも良い。
あるいはauthorized_keysのcommand='...'機能を使って強制的に特定のコマンドを実行された場合に、本来リモートから(ssh host 'cmd...'等で)与えられたコマンドラインが環境変数SSH_ORIGINAL_COMMANDに保存されるのを利用して、SSH_ORIGINAL_COMMANDを自前で安全に処理するコマンドを作るとか。

とかって方法が考えられる。さらに、どうしても必要最小限のコマンドに制限できない場合は、接続元のホストを制限した上で接続元ホストの方を守るのと、実行されたコマンドのログをacct等で確実に取る(必要ならアラートも飛ぶようにする)。

なるほど、鍵でできることを限定することが先決か。あとは変なイベントが上がったときに検出する仕組みを作っておくってことね。

あと、意外に多い誤解が、「パスフレーズなしの秘密鍵は(パスワード認証における)パスワードなしと同じくらい危険」とか、(略)
秘密鍵のパスフレーズは秘密鍵ファイルを暗号化してるだけのもんです。逆に言うと秘密鍵ファイルを悪者に盗まれてしまったら、たとえパスフレーズが設定されていても、↑のCrack ( http://www.crypticide.com/users/alecm/ ) みたいなオフライン攻撃が可能、つまり悪者は手に入れた秘密鍵をどっか別の安心して作業ができるマシンでじっくり辞書攻撃なり総当り攻撃なり使ってパスフレーズを探すことができる。

なので、「秘密鍵を他人に渡さない」ということの方が、パスフレーズを設定することよりも遥かに重要。パスフレーズはいざという時の時間稼ぎでしかない。

それが分かれば、ssh-agentやkeychain使うより、いさぎよくパスフレーズなしにしちゃった方がいいってのも分かると思う(自動運転の場合ね)。だって、適切なパーミッションが設定されている秘密鍵ファイルを盗める人間(rootとか)なら、常駐しているssh-agent/keychainも乗っ取れるでしょ。パスフレーズ設定してる意味がない。「なんかの拍子にssh-agentのプロセスが死んじゃってて(めったにないけど)、自動運転に失敗した」とか、「サーバをリブートするたびに、パスフレーズ入力してssh-agent起動しないといけない(運用担当者全員にパスフレーズ教えないといけない)」とかって、余計な手間が増えるだけ。

確かに。再起動の度に ssh-agent 起動はやだなあ。ここでまた運用ミスが発生しかねないし。だったらパスフレーズ無しの方が理にかなってる。結局セキュリティは利便性とトレードオフになることが多い。今回の件では妥当な判断だと思う。

- 自動実行用の鍵作成

というわけで実際に権限を限定してみる。今回は authorized_keys2 レベルの話。ファイアウォールとか OS の話は別次元。そういうのは ssh に限らないレベルの話なのですべてやってあることが前提。

自動実行専用の鍵を作成。-N オプションでパスフレーズを指定できる。今回は空で作成した。

$ ssh-keygen.exe -t dsa -N "" -f ~/.ssh/auto_execute

生成した公開鍵 ~/.ssh/auto_execute.pub に from="*.example.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty オプションを付加し、リモートサーバの ~/.ssh/authorized_keys2 に追加。

下記は公開鍵の例。引用の際に改行を入れてしまっているが、実際は一行。

# 2004-11-22 追記。
# 以下の公開鍵のオプション指定では権限を限定できていない。
# 権限を限定できている公開鍵の例は、
# 後述の「できることを限定した自動実行用の鍵で ssh 接続してみる」の項を参照。

from="*.example.com",no-port-forwarding,no-X11-forwarding,
no-agent-forwarding,no-pty ssh-dss AAAAB3NzaC1kc
3MAAACBAKZhqMdcujcJgGOCIsi+PrmkEEaAy/gpRPpB3Q5OA
wNG+PwTdU5O8/NPde64wNux4XNUB7XkV2eXWfaTZRYyYe0oC
XeJMh2LKZ/a/F3Wu283uuExSZhbkt3Dcv3+u6oyjBzIfNU+P
(以下略)

2004-11-22 追記。上記の鍵に付けたオプションだけでは無意味という指摘を頂いた。

ssh scp sftp の正しい自動実行方法
http://www.banana-fish.com/~piro/20041122.html#p01

えっと、authorized_keys自体を書き換えられる権限を、パスフレーズなしの鍵に与えてしまうと、結局ノーガードと同じことになってしまうです。悪い人の鍵でなんでもできるようにしたauthorized_keysをリモートにscpして一丁あがり。

あと、これも時々目にする勘違いだけど、「no-pty」は仮想端末とれなくなるだけで、シェルが取れなくなるわけじゃないので、仮想端末取らないで「ssh remotehost '/bin/sh' < 悪のスクリプト」とかやるだけの話。

指摘の通り、上記の鍵では ~/.ssh/authorized_keys2 に scp されることを防げないので意味がない。

また、command="" が無い場合、以下のようにシェルに直接コマンドを送り込むことができる。試したら authorized_keys2 の中身がローカルの端末に表示された。

$ echo "cat .ssh/authorized_keys2" |ssh -i /home/hiroaki/.ssh/auto remotehost.example.com -l hiroaki

結局、commnad="" を使えない場合は、「正しいssh/scpの自動運転は」 http://www.banana-fish.com/~piro/20040609.html#p06 で提示されていた方法で権限を限定する必要がある。

- 指定したオプションの説明

sshd.0
http://www.unixuser.org/~euske/doc/openssh/jman/sshd.html
authorized_keys ファイルの形式 から抜粋。

authorized_keys ファイルの形式

from="pattern-list"
        このオプションをつけると、公開鍵認証に加えて、クライアントのホス
        トをチェックできるようになります。カンマで区切ったリモートホスト
        名 (canonical name) のパターン列が指定できます (`*' および `?' が
        ワイルドカードとして使えます)。このリストには「〜でない」という否
        定 (negation) を入れることもできます。その場合はパターンの先頭に
        `!' をつけてください。否定つきのパターンにホストの canonical name
        がマッチした場合、この鍵は許可されません。このオプションはセキュ
        リティを上げるためにつけられました: 公開鍵認証それ自体は、(鍵を除
        いて) ネットワークやネームサーバ、その他ありとあらゆるものを信用
        しません。しかし、もし何物かが何らかの方法で鍵を盗むことができれ
        ば、その鍵を使って世界のどこからでもログインできてしまうことにな
        ります。このオプションは、そのような盗まれた鍵を使うことをより困
        難にします (もしこれを使おうとするなら、鍵のほかにネームサーバや
        ルータまでも手を入れなくてはならないからです)。

(略)

command="command"
        このオプションを使うと、認証にこの鍵が使われたときは必ずここで指
        定されたコマンドが実行されるようになります。ユーザが (訳注: クラ
        イアント側で) 指定したコマンドは無視されます。クライアント側が仮
        想端末を要求していれば、ここで指定されたコマンドは仮想端末上で実
        行されます。そうでなければ端末なしで実行されます。 8-bit クリーン
        な通信が欲しい場合は、仮想端末を要求してはいけません。あるいは
        no-pty オプションを使ってください。コマンド文字列中に引用符 (")
        を入れたいときは、バックスラッシュを前につけてください。このオプ
        ションは、ある公開鍵には特定の操作だけしかさせないようにするのに
        有効です。例として、リモートバックアップだけをさせて、それ以外な
        何もさせないような鍵がつくれます。クライアントの TCP/IP や X11 転
        送は、明示的に禁止されていない限り可能なので注意してください。こ
        のオプションはシェル、コマンドまたはサブシステムの実行に適用され
        ます。

no-port-forwarding
        認証にこの鍵が使われたときは TCP/IP 転送が禁止されます。クライア
        ントがポート転送を要求しても、すべてエラーになります。これはたと
        えば command オプションの指定されている接続などで使われます。

no-X11-forwarding
        認証にこの鍵が使われたときは X11 転送が禁止されます。クライアント
        が X11 転送を要求しても、すべてエラーになります。

no-agent-forwarding
        認証にこの鍵が使われたときは、認証エージェントの転送が禁止されま
        す。

no-pty  端末の割り当てを禁止します (仮想端末の割り当てが失敗するようにな
        ります)。

- できることを限定した自動実行用の鍵で ssh 接続してみる

前述の no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty を指定した scp/sftp 用の鍵を使い、putty で sshd に接続。TCP 接続はできるが、

Server refused to allocate pty

と表示されてシェルに入れなかった。no-pty の効果だな。ちなみに putty は CTRL + D で終了できた。

2004-11-22 追記。
前述の通り、上記は仮想端末が割り当てられていないだけで、シェルは使用可能となっている。できることを限定したければ、command="" を指定するか、scponly などのシェルを割り当てる必要がある。

今回は command="" を使う方を試してみた。以下は公開鍵の例。引用時に改行を入れているが、実際は一行。

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,
command="echo $SSH_ORIGINAL_COMMAND; umask 077; f=backup`date +%F-%H%M%S`.tar.bz2.encoded; echo $f; cat >/home/hiroaki/backup/$f;,from="*.example.com"
ssh-dss AAAAB3NzaC1kc
3MAAACBAKZhqMdcujcJgGOCIsi+PrmkEEaAy/gpRPpB3Q5OA
wNG+PwTdU5O8/NPde64wNux4XNUB7XkV2eXWfaTZRYyYe0oC
XeJMh2LKZ/a/F3Wu283uuExSZhbkt3Dcv3+u6oyjBzIfNU+P
(以下略)

ローカルから接続してみる。

$ echo "cat .ssh/authorized_keys2" |ssh -i ~/.ssh/auto $remote_host -l $remote_user
Pseudo-terminal will not be allocated because stdin is not a terminal.

backup2004-11-22-235811.tar.bz2.encoded

リモートに生成された backup2004-11-22-235811.tar.bz2.encoded の中身は以下のようになっていた。

cat .ssh/authorized_keys2

scp も試してみる。

$ scp -oIdentityFile=~/.ssh/auto file $remote_user@$remote_host:~/backup/test
scp -t /home/hiroaki/backup/test

command="" のおかげで、~/backup/test は生成されずに済んだ。

SSH を使ってリモートサーバにログインするために、PuTTY をインストールして環境設定するためのメモ。

PuTTY は今までも使っていたけど、LAN の中にあるサーバに接続するだけだったので、SSH じゃなくて Telnet をメインに使っていた。本当は LAN の中でも SSH を使う方が望ましいんだけど。

- ダウンロード

hdk の自作ソフトの紹介
http://hp.vector.co.jp/authors/VA024651/#PuTTYkj_top
executable files (PuTTY version 0.55 にパッチをあてた実行ファイル puttyjp.exe) をダウンロード。

PuTTY Download Page
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.h ...
pageant.exe と puttygen.exe をダウンロード。putty-0.55-installer.exe の方がまとめてインストールされるので楽かも。

- PuTTY で SSH2 用の鍵を作成

puttygen.exe を起動し、RSA や DSA などの鍵タイプとビット数を指定して Generate を押す。プログレスバーの下の空欄でマウスを動かせ、という指示が出るのでマウスをテキトーに動かす。動かさないとプログレスバーは進まない。マウスを動かすと進む。これを利用して、「だるまさんがころんだ」みたいにして遊ぶこともできる。絶対勝てないけど。

鍵の生成が終わったら、パスフレーズを入力。"Save Public Key" と "Save Private Key" のボタンで公開鍵と秘密鍵を保存。この段階では puttygen.exe はまだ終了しないように。

- PuTTY で作成した鍵を OpenSSH 用の鍵に変換

PuTTY で作成した鍵は、そのままでは OpenSSH では使えないので変換する必要がある。そのままでは、

Server refused our key

などとサーバに拒否されてしまう。

ssh-keygen コマンドで変換しても良いし、テキストなのでコピーアンドペーストしてもいい。
今回はコピペを使う。puttygen.exe の Public key for pasting into OpenSSH authrized_keys file: と表示されている部分をコピーして、先ほど保存した公開鍵ファイルの中身を全部上書きする。

ssh-keygen コマンドを使った変換は、
＠IT：鍵交換方式のsshでアクセスするには
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/429usekeys ...
がわかりやすい。

- サーバに公開鍵を配置

接続先サーバのホームディレクトリにある .ssh ディレクトリに公開鍵 authrized_keys2 を配置する。ファイル名は authrized_keys2 にしておこう。authrized_keys2 のパーミッションは 600、.ssh のパーミッションは 700 にする。これ以外のパーミッションだと接続できない場合がある。

- PuTTY に使用する秘密鍵とログインIDを指定

PuTTY を起動し、PuTTY 設定ウインドウで「接続」を選び、「自動ログインのユーザ名」に接続先サーバのログインID を指定。「SSH」の「認証」を選び、「認証のためのプライベートキーファイル」に秘密鍵のパスを指定する。あとは「セッション」で接続先サーバ名とポートを選び、今回設定した内容に名前をつけて保存しておく。

- 相手先に接続

相手先サーバに初めて接続する場合、相手の鍵は既知の鍵ではないので、その鍵を信頼するか尋ねられる。今回は未知の鍵なので Yes を選択する。既知の鍵なのにこの警告が出たら、鍵がすり替えられているかもしれない。

あとは秘密鍵のパスフレーズを入力すればログイン完了。

- pageant.exe で鍵の管理とパスフレーズ自動入力

pageant.exe を使うと、パスフレーズが必要な場面で自動入力してくれる。pageant.exe を起動し、 Add Key ボタン押して秘密鍵ファイルを指定する。パスフレーズを聞いてくるので入力すると、pageant.exe に秘密鍵が登録される。この状態で先ほど設定したサーバに PuTTY で接続すると、自動的にログインできる。

秘密鍵ファイルの拡張子を pageant.exe に関連づけておけば、秘密鍵ファイルのダブルクリックで pageant を起動して pageant.exe に登録することができる。もちろんパスフレーズを尋ねられるけど。パスフレーズを Windows のスタートアップに登録しておくのも便利かも。

- 参考

＠IT：Windowsからssh 2でLinuxにログインするには
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/416usessh2 ...

＠IT：鍵交換方式のsshでアクセスするには
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/429usekeys ...

＠IT：Linuxでsshの鍵を作成するには
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/432makessh ...

あとは Google で検索すればどうにでもなる。スクリーンショット付きの解説ページもあるし。

ポートノッキングとは、ある特定の順番でポートを叩いたときだけ接続を許可する仕組み。コードは見ていないが、きっと SYN を監視しているんだろう。

japan.linux.com | ポートノッキング批判
http://japan.linux.com/security/04/08/13/0250213.shtml
表題は「ポートノッキング批判」だけど、ポートノッキングそのものを批判してるんじゃなくて、セキュリティ関連の技術についての考え方や使い方についての記事だった。

ポートノッキングという仕組みはこの記事を読んで初めて知った。面白い機能だ。単体では信頼性に難があるが、既存の技術と組み合わせればセキュリティをより強固にできる。

この記事を読んでいると「内密チャンネル」や DNS を使ってトンネリングする「TCP over DNS」を想起させる。とくに重要そうに見えないデータには別の意味があり、そこに大事な情報が隠されているってシチュエーション、なんだかワクワクする。

内密チャンネル
http://www.dd.iij4u.or.jp/~okuyamak/Information/convert_chan ...

TCP over DNS
http://www.nantoka.com/~kei/diary/?200311a&to=200311041# ...
http://61.203.92.65/~fkz/daiary/200406.html#d020858

暗号化と認証を必要とするサービスをインターネット上に作ることになった。この分野は、設計の誤りがユーザの不利益に直結するシビアなもの。「最低限の学習をするために、暗号や認証技術についての本を読んでおこう」と思い立ったとき、真っ先に候補として頭に浮かんだのがこの本。

暗号や認証技術は要求される前提知識が広範に渡っていて追いかけきれなかったり、高度な数学の知識が必要というイメージを私は持っている。でも、結城さんの本ならば、難しいことでもかみ砕いて書いてあるだろうという期待もある。ウェブでの反応を見ている限り、期待どおりの易しい記述になっているようだ。

結城さんの日記 http://www.hyuki.com/diary/ を読んでいたので発売されていたことは知っていたんだけど、まだ必要ないかなと思って購入を見送っていた。

「認証技術 パスワードから公開鍵まで」も良いかなと思ったけど、まずは結城さんの本を読んで、不足があったら買ってみることにした。

stone や SoftEther をはじめとするトンネリングツールを使わせないために、外部への SSL を全部 drop しちゃえ、という書き込みをいろんなところで見かけた。多少は効果はあると思うが、デメリットが多すぎる。出張の切符手配サイトとか、財形預金サイトとか、少額備品購入とか、401K の運用指図サイトとか、SSL を使ってるサービスはいろいろ考えられるな。確認してないけど、Windows Update も SSL 使ってるそうな。デメリットを許容できるからといって drop したとしても、またすぐ他のトンネリング方法が出てきてイタチごっこになる。管理者側のとるべき対策は、組織内規定の強化、啓蒙と教育なんじゃないかな。