”Break in While” なかと〜 の 日記

2014-05-18 PC遠隔操作事件2014年5月16日メール

この事件、自分の生業である情報技術と社会の関係という視点で気になっている。

Twitter を眺めていて見つけたこちらの記事「遠隔操作事件について」が「コメントを募集」とのことで、自分の情報アップデートを兼ねて追ってみたいと思います。(メールの生情報はこちらに

ウイルスジェネレータで作成したウイルスで遠隔操作したようです。

ジェネレータ使用は過去の話として語られているので、これは推定できません。

IP【60.36.185.80】の会社PC

http://fox.2ch.net/test/read.cgi/poverty/1400223985/122

http://fox.2ch.net/test/read.cgi/poverty/1400243283/383

を参照。IPで書いたのは「iesysを会社で作成した」という検察主張と関係しているのではないでしょうか。

どうやって同一人物

例えば同一LANに居ればマルウェア同士が通信できます。スマホを各所でWifi接続してくれればよいでしょう。

他プログラムに感染させる

他プログラムファイルを偽物に置き換えればいいだけです。本物を同時に起動するようにすれば普通はなかなか気づけないでしょう。対象プログラムに拡張機能があればそこにインストールしてもいいかもしれません。

ルート検索さえすれば行った事実はなくてもよかったのでしょうか?。

検索履歴をもとに警察が食いつけばそれで十分でしょう。またルート検索しか使っていないとは言っていないです。

自称真犯人はなぜこのような面倒くさいことをしたと書いているのでしょうか?。

裁判証拠として価値が無いことをメール送信者はレクチャーしてると思います。

iesysのソースコードを片山氏PCに転送するだけでよいはずです。

それでは不十分です。捜査の段階でそこで作成したように見える必要があります。

C#プロジェクトを盗んだとするとここでも矛盾が発生します。

サンプルプログラムを改変実行するぐらいのことはしたと証言しているようです。http://bylines.news.yahoo.co.jp/egawashoko/20140415-00034530/ (私も裁判内容はきちんとフォロー出来ていません)

なぜiesysを作ったのでしょうか?

誤認逮捕が犯人の目標ですから、犯行を実際に行いつつ捜査の餌として作成状況含め痕跡を残す必要があります。一方自分に繋がる踏み台づくりのツールは痕跡を残したくないでしょうから、それと別であるのは不自然ではありません。必要に応じて複数のプログラムやその場限りのスクリプトを必要に応じて作っているとみるのが自然でしょう。


私の今回のメールの印象は、

  • 真犯人であることとの矛盾は無い
  • 第三者や内部情報にアクセスできる関係者である可能性は捨てきれない
  • 秘密の暴露があったかは捜査側は判断できるかもしれない

です。

ボールは捜査側に持たされた格好になりました。真犯人であろうとなかろうと、それが送付者のやりたいことなのでしょう。

追記:考えてみると一番プレッシャーを受けるのは裁判官かもしれませんね。

さらに追記:自演であって収監されたとの速報があった。詳細は続報を待ちたいが、ということになると、現在の日本ではほとんど物的証拠を残さずネット犯罪が可能で、それに対する警察の手法が代用監獄等ということになってしまうのか。バランスが悪くてよろしくないなぁ。

松 2014/05/19 23:26 コメントありがとうございました。

事件にも動きがありましたね。まさかそれはないだろうと思っていた、本人の自作自演の可能性が非常に高くなり、なんだか感強すぎです。

IPが間違っていたのは何だったのでしょうね。秘密の暴露は探せば見つかる情報か、関係者以外は確かめるすべがないと思ってのデタラメと思っていましたが、そういうことなら納得です。

いまさら感がありますが、一応、一部お返事いたします。

>ジェネレータ使用は過去の話として語られているので、これは推定できません。

 確かに、ウイルスジェネレータは過去の話での言及なのですが、iesysが今回のようなあまり細かな遠隔操作は難しいのではないか?ということから、片山氏が遠隔操作されたとするとウイルスジェネレータかなと判断しました。

>例えば同一LANに居ればマルウェア同士が通信できます。スマホを各所でWifi接続してくれればよいでしょう。

 「なるほど、考え付きませんでした。というか、会社のwifiにスマホを接続するとばれたら大目玉ですし、必要性がない限り普通はwifiのパスワード教えてくれないですよね?。まして派遣されてきた社外の人間にまで?」…と思ってました。

 「正直、スマートフォンへの遠隔操作ウイルスの送り込みは完全に嘘だと思っています。(元記事に書いたように導入方法の記述があいまいですし、スマートフォンへの遠隔操作を有効に活用している記述がないので)」…と思ってました。

>他プログラムファイルを偽物に置き換えればいいだけです。本物を同時に起動するようにすれば…

 「それだと別のKickerのような実行プログラムも必要ですが言及されていません。そこまでするなら、そのような機能をiesysにつけるはずです。それにこれを感染とはふつう言わないですし、ポータブルアプリケーションは実行ファイルを直接起動するので、この方法だとばれる可能性が高いですよね?。」…と思っていました。


 全般的につじつま合わせの印象が強いなと思っていました。片山氏を「犯人に仕立て上げる」証拠の残し方に不確定要素が多すぎるからです。きわめて長期間にわたって辛抱強く計画的に行動していたのにです。かと思えば、監視カメラ等を恐れず片山氏の訪れた場所に(時にものすごく早く)証拠を残しに行くような行動派的なところもあり、ちょっとできすぎと思っていました。

 片山氏は現在行方が分からないとのことですが、大丈夫でしょうかね。これ以上おかしなことにならないといいですね。早く事件が解決すればと思います。

2013-08-05

安全な自動化実行の為の ssh 設定(備忘録)

| 11:41


課題

cron やビルド過程の中などの自動実行したい処理の中にリモートマシンで行う内容が有る。ssh や scp で求められる対話的な操作をできるだけ安全な方法で何とかする。またアクセスに必要な情報をより安全に管理したい。


背景

必要な背景知識はほとんど http://www.bugbearr.jp/?ssh_scp%E8%87%AA%E5%8B%95%E9%81%8B%E8%BB%A2 に完結にまとめられているので、そちらを参照。

自動運転の手段として expect や ssh-agent を使う解法を紹介しているのも見かけるが、これは迂回的な対処でありデメリットが多い。

ここでは前掲ページで述べられているパスフレーズ無しの公開鍵暗号を使う方針を採用し、

  • 運用時の手動操作の必要を無くす。
  • 固定的ではあるが複数の操作(自動化実行したい処理内容)がある。
  • 鍵が漏洩しリモートへ接続されてしまっても、被害を出来るだけ小さくする。
  • 自動運転のスクリプト自体と接続に必要な秘密情報を分離する。スクリプトは共同作業者内での共有が可能になるようにする。

という状況設定のもと、具体的なコマンドを備忘録を兼ねて書き出してみる。

解法の方針を要約すると

  • 公開鍵認証をパスフレーズ無しの秘密鍵で運用して対話処理を不要にする。
  • 公開鍵の中の command にリモートでの実行内容を書くことで、実行可能な内容を制限する。
  • 必要に応じて操作毎に鍵ペアを作る事で、出来る事を限定されつつ増やせるようにする。
  • 自動化実行専用のユーザを設ける。
  • ssh -F オプションを使い接続パラメタが、実行コマンドラインにあらわれないようにする。

である。



手順

1. ローカルマシンで操作の種類毎に専用の鍵を作る

リモートで行う操作の種類毎に鍵を作る。ここでの操作毎とは、例えば「バックアップを取る」「更新ファイルを送り込む」「プロセスを再起動する」といったような単位のこと。

mkdir sshkey
chmod 700 sshkey
cd sshkey
ssh-keygen -N "" -f some_operation -C "some_operation"

  • ここでは操作の呼称を some_operation とした。必要に応じて適宜変える。
  • これで、秘密鍵 some_operation と 公開鍵 some_operation.pub が生成される。
  • sshkey は任意のディレクトリ名。
  • パスフレーズは空文字列にして設定しない。その代わりにパーミッションを設定したsshkey に鍵をおさめて他から見えないように管理し続ける。
  • 鍵生成の -C はコメント。必須ではないが、鍵ファイルに書き込まれるので便利の為にここでは指定。

作成したすべての公開鍵を一つのファイル authorized_keys にまとめる。

cat *.pub > authorized_keys


2. authorized_keys を編集する

各の行頭にssh接続した時の制限設定を追加する。例を示す。

command="date >> ssh_log.txt",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC(鍵データ部分中略)1wW+sgrobEn some_operation

  • 上記の例では「ssh-rsa」より前が書き加えた部分。(攻撃された時に他に流用される可能性をなるべく押さえる役割をする。詳細な意味は man sshd の AUTHORIZED_KEYS FILE FORMAT の項を参照。)
  • 追加分の最後(例では ssh-rsa の直前)には区切り文字として空白が必要なので注意。
  • command のダブルクォートの中身に、接続した時にリモートマシンで実行される内容を書く。(sshd の機能により接続した ssh 側のコマンドラインは無視される。)
  • 上記の command の内容はもちろんサンプル。適宜書き換える。万一攻撃者に実行されても被害が最小になるよう注意を払う。
  • $SSH_ORIGINAL_COMMAND を扱おうとすると難易度が上がるので、できるだけ避けた方がいいだろう。

3.接続情報をコンフィギュレーションファイルに書く

ローカルの sshkey/config として次のようなファイルを書く。

Host theServer
    Hostname    server.example.com
    User        restricted_ssh

  • ファイルパーミッションは 600 にする。
  • ssh接続ポート番号をデフォルトから変えている場合はここに Port として書く。
  • 記述の詳細は man 5 sshd_config を参照。
  • restricted_ssh は次のステップで作る自動化作業専用のユーザー名。
  • theServer は例。この後のステップでの記述と一致していればよい。
  • server.example.com はもちろん例。
4. リモート側で ssh 利用の準備をする

自動化作業専用のユーザーを作る。

(これは ssh 関係なく通常のユーザ管理の範疇であるが、)このユーザに対するグループやファイルパーミッションなどを適切に運用する事で、万一攻撃者にアカウントが使われてしまった時にアクセス可能な情報を制限する。

(リモートへ管理作業用アカウントログインした後)
sudo useradd --comment "restricted ssh for automated operation" restricted_ssh
sudo passwd restricted_ssh
su restricted_ssh
cd ~
mkdir .ssh
chmod 700 .ssh/
cd .ssh
touch authorized_keys
chmod 600 authorized_keys
ls -al


5.ローカルから公開鍵(を編集した authorized_keys)を送り込む

(カレントパスが sshkey であると仮定)
cat authorized_keys | ssh theServer -F config "cat >.ssh/authorized_keys"

  • この時は ssh からパスワード入力が求められる。
  • ~/.ssh/authorized_keys のファイルの意味は詳しくは man sshd を参照。
  • -F config で指定しているのは、手順 3 で作ったもの。

6.送った内容をリモート側で確認し、パスワード認証の無効化する

送り込んだ内容になっているか、ファイルパーミッションが正しいか確認する。

ls -al
cat authorized_keys

良ければ管理作業用アカウントへ戻り、自動化作業専用ユーザーのパスワード認証を無効化する。

exit
sudo passwd -l restricted_ssh

ローカルからパスワード認証では利用出来なくなった事を確認する。

ssh theServer -F config

7.実行

リモートの処理の実行は次のようにする。

ssh -T theServer -F sshkey/config -i sshkey/some_operation

  • 操作の種類毎に対応する秘密鍵を -i オプションで指定する。
  • この記述はビルドや cron のスクリプトに書かれることになるので、おそらくプロジェクに関係する比較的多くの人が見る事になるだろう。しかし -F オプションによりホスト名やユーザー名などは作業をしたローカルマシンの config の中にのみ留められる。

補足1:authorized_keys の編集

処理内容を変更する事になりローカルで編集した authorized_keys を送り込む場合、この機構自体を使ってはいけない。そのような設定は攻撃者に authorized_keys を書き換えられてしまうので、わざわざこのようにする意味がなくなってしまうためである。

変更の際には自動化作業専用のユーザーに一時的にパスワードを設定してパスワード認証で再び送り込むようにする。(もちろんリモートで編集しても構わない。)


補足2:鍵生成時のパラメタ

ssh-keygen でタイプや鍵長さを指定する事も出来る。ここではデフォルトを用いた。(資料としてこの手順を残しておくことを考えると、明示するよりもその時々のシステムのデフォルトを使った方が安全なのではないかと考えた)

補足3:~/.ssh/authorized_keys2

文献によっては authorized_keys2 を使うようにと書いてあるが、これは古い仕様であって、OpenSSH ver.3 からは authorized_keys で構わない。

2013-08-04

Mac OSX でファイルのアイコンをビルドスクリプト中で変える方法

| 09:49

Xcodeビルド過程などで作成したファイルのアイコンを、スクリプトで自動で設定する方法について。

分かってしまえばたいした事は無いのだが、検索してもストレートに説明しているページに行き当たらなかったので、まとめておく。

手動で変える方法は検索すると色々見つかるので、プログラマーで無い方はそちらを参照。


手順

1. アイコンファイル(拡張子 icns)を用意する。

2. 次の Ruby 言語で書いたスクリプトを置く。

setIcon_forFile.rb

3. スクリプトを実行する(ようにビルドを整える)。

Xcode の Project > Targets > Build Phases > Run Script などで

/usr/bin/ruby setIcon_forFile.rb <対象ファイルもしくはフォルダー> <アイコンファイル>

とする。



背景

要するに「ファイルにアイコンを指定するには NSWorkspace setIcon:forFile:options:を使う。ビルド過程などで使うのであれば Ruby スクリプトを書いて叩くのがお手軽。」ということ。

調べ初めは、手動で切り替えられるなら同じ事をする AppleScript が書けるだろうと考え AppleScript エディタで記録してみるが反応無し orz。その方向からしばらくさまよったところ http://memogakisouko.appspot.com/AppleScript.html#setFinderIcon が見つかった。その記事では AppleScript から使う方法になっているので、この記事は中身の Ruby スクリプトだけを切り出して整えた(だけ)ということです。

なお、コード片を検索キーにして探したら ChocTop というものが見つかった。ビルドツールということらしいがプロジェクト的には死んでいる風。https://github.com/drnic/choctop/blob/master/lib/choctop/dmg.rb

それぐらいしか見つからなかったのだが、皆どうしているんだろう。Xcodeで用意されているテンプレート以外のものをビルドする人が極端に少ないのか?



補足:アイコンファイルの作成

http://stackoverflow.com/questions/6337787/how-can-i-set-the-icon-for-a-mac-application-in-xcode

https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Optimizing/Optimizing.html

によれば、現在(2013/8)のアイコンファイル(.icns)作成の推奨方式は

  1. iconset という形式で、解像度毎に用意した PNG ファイルを一つのフォルダに収める
  2. iconutil コマンドを使い icns に変換する。

とのこと。(Xcodeアイコンを含むアプリケーションなどをビルドする際には iconutil のステップは自動的に行われる)

なお前掲リンク先には、サイズと解像度毎のファイル一覧が記載されているが、すべての解像度を用意する必要はない。

However, it is not a requirement to have a complete set; the system will choose the best representation for sizes and resolutions that you don’t supply.


/Developer/Applications/Utilities/IconComposer

というツールも有るのだが、これは retina display の high-resolution 対応の時に見捨てられたようだ。(1024pixelが扱えない。resolution の指定が無い。)

画像の品質は気にせずにお手軽に作るのであれば、IconComposer で操作した方が GUI 操作上は楽かもしれない。iconset は、ちまちまファイル名を指定しないといけないので。(もっともテンプレートを一回作ってしまえばそれを書き換えていけばいいので大した事は無いが。)

IconComposer を使う場合は、プレビューpng を開いて全選択&コピーしておいて、IconComposer で各サイズの枠を選択した状態でペースト。で、保存。

2013-03-09 専門外の人に通じるように GUID を説明してみる試み

パソコン遠隔操作事件に絡んで、技術的な単語である GUID が話題に出ていた。やり取りを見ていたら、なんか歯がゆい感じがしたので噛み砕いてみる。


概説

06:01

GUID の目的

GUID は例えば、「このプログラムを開始する」といった処理をプログラム中に書く際に、どのプログラムなのかを指定するのに使われる。

このように GUID は「プログラム中における何か」を特定する目的で用いられる、「何か」につけた名前であると考えて良い。「何か」の実体はプログラムの目的によって様々である。

名前とは言っても実際のところは GUID は単なる整数値である。10進数であらわすと39桁ぐらいになる。プログラム中で「何か」を指定するものであるので、GUID はプログラムの一部として埋め込まれ流通することになる。



GUID の性質

一般に名前をつける際に問題となる事の一つは、名前の重複である(人なら同姓同名)。別のものに同じ名前が付いていると、名前だけでは特定の一つを指せなくなり不便である。GUID では、この重複が起きないようになっている。

GUID は Globally Unique Identifier の略で、これは世界中に居るプログラマが自分が作っているものに名前を付けた時に、

  • 全世界に渡って(=Globally)
  • 重複が起こらない(=唯一である =Unique)
  • 名前(=Identifier 識別するものという意味の専門用語。通常の訳語は「識別子」)

である、ということを表している。


命名(=生成)の方式

重複が起こらないようにする仕組みとしては、何らかの登録簿を作るのが素朴で一般的だろう。しかし GUID ではそのような方式は取っておらず、集中的な管理を行わなくて済むという設計目標の元で規格が作られている。

実際の方法は、時代を追うにしたがい複数の方法が考案されてきた。GUID は整数値なので、ここでの「方法」とはすなわち番号を生成する手順である。


バージョン1:MAC アドレス を用いる方法

MAC アドレスは、パソコンなどを含むネットワークを使う装置の接続口に付けられている数値である。これは GUID とは別の規格により、世界中の機器ごとに異なるように番号が振られている。

そこでこの方法では、MAC アドレスを世界中で重複が起こらないための基礎として利用する。さらに同じ機器で行う生成が重複した値にならないように、生成する際の時刻を利用し、この二つを合成して値を決定する。


バージョン4:乱数を用いる方法

MAC アドレスを用いる方法では、どの装置でいつ生成したのか明らかになってしまう。そこで乱数を用いる方法が定められた。

この方法では GUID を生成しようとするたびに乱数を作り、それを組み込んだ GUID を生成する。

乱数であるので、個別に生成した GUID がたまたま一致してしまう確率は理論上はゼロではない。しかしその確率はきわめて低いので、実用上は問題にならない。)

補足

06:01

Globally Unique であるということ

個別に生成した時に一致しないように設計されているものであるので、一致する値の記録があれば、両者には何らかの関係があると考えられる。


付け直し、付け替え

GUID は単なる数値である。このためプログラマは、その値を好きな時に幾らでも書き換えることは可能である。別のマシンで生成したものを持ってくることも、思いつきで書き換えることも。(おそらく、実行ファイルをバイナリエディタ等で書き換えることも。)


どこに記録されうるか

GUID は以下の場所に記録される、かもしれない。

  • プログラム作成過程で使用したプログラムが書き出したもの
    • プログラムのソースコード
    • プログラム生成する際の中間的なファイル
    • など。
  • 流通するプログラムのファイル(遠隔操作の被害者にダウンロードさせるもの)
  • インストールされた状態の各ファイル(実行ファイルや設定ファイル)
  • インストールする際に書き込んだシステムの記録(レジストリ
  • システムの動作記録ファイル(ログ)

(今回のプログラムでどうなっているのかは知らないで書いています。一般論の可能性として。)


乱数の性質

バージョン4では乱数を使って生成する事になっているが、マイクロソフト社製のソフトを利用して生成した場合に、その乱数の性質は必ずしも明らかではない。乱数を生成する際に、実行環境に固有な情報が使われてそれが何らかの形で残っている可能性はありうる。(もっとも、そのようなことは無いと常識的なプログラマならば信じているが。)

ツイッターでは、大量の GUID があったときに同じマシン由来か分かるかも、という発言もあったが、はて。コンピュータにおける乱数はいろいろと専門的で面倒なことがあるので、これ以上は割愛します。)


MAC アドレス

MAC アドレスはパソコンなどの装置を買ってきた時に既に番号が振られているものであり、パソコンを固体識別するのに使える。

しかし MAC アドレスは技術的には書き換えが可能な場合があり、犯罪の証拠などにおいてはそれだけでは確実な物ではないだろう。(そもそも、装置ごとではなく接続口ごとについた番号なので、通信カードを差し替えるなどの方法でも変わる。)

蛇足

06:02

規格やら

  • GUID はマイクロソフト社が規格を決めたものである。
  • より広い概念として UUID がある。(GUID は UUID の一種。)
  • 普通は16進数表記をして {AE43C25A-BF39-4de2-809B-0A77413E9E3A} のような書式で書く。(これは今手元で生成してみたもの。)

バージョン

  • 今回の事件ではバージョン4の形式のものが見つかっているそうな。(伝聞)
  • バージョン1と4以外も仕様はあるようなのですが、実態としてどうなっているのかは知りません。
  • とりあえず手元の環境では4形式が生成されましたね。(上記の 4de2 の 4 がそれを示している)

一般的な生成の実際

プログラマーが一般に GUID を生成するシーンとしては以下のようなものがある。根っこをたどればおそらく皆同じところに行き着く。

Visual Studio を使っている時

現在では Windows 向けにプログラムを開発するには、マイクロソフト社が販売(あるいは一定の条件で無償提供)している Visual Studio を使用するのが一般的である。

Visual Studio を操作してプログラムに何かを新たに付け加えた際に、Visual Studio が付け加えた要素を指す GUID を生成しプログラムソースの中に書き込むことがある。


GuidGen を使って

マイクロソフトプログラマー向けに GUID を生成するための GuidGen(GUID Generator の略)というプログラムを提供しているので、これを操作して得る方法がある。(これは Visual Studio に付属もしている。)

http://www.microsoft.com/en-us/download/confirmation.aspx?id=17252


プログラムによる生成

プログラムを実行した際に新しい GUID 値が欲しい時に使う方法。プログラミングの領域になるので、簡単にキーワードだけ記しておく:CoCreateGuid、Guid.NewGuid



がぶがぶ。思いのほか長くなったな...

2012-07-07 沖縄 黒島 民宿みやよし荘

沖縄県石垣島から船で25分。八重山にある黒島に今年も6月末に訪れました。いつも同じ民宿に泊っています。のんびり気ままに過ごせる良い宿です。

旅館やホテルなどの宿と比較してしまうと不便なところもあり万人には向かないと思いますが、飾らない離島の姿を楽しみたい人は是非お勧めしたいので紹介を少々書こうかなと思います。


外観

f:id:naqtn:20120625144205j:image:w300

f:id:naqtn:20120625144443j:image:w300

古い宿なので建物や設備は、正直なところまあ何というか、ボロいです。離島の民宿ではよくあることですが、増築を繰り返しているので、よく見るとヘンなところも。今の主人の親の時代に一部手作りで建てたらしいです。納得。


部屋

f:id:naqtn:20120625112443j:image:w300

f:id:naqtn:20100630091238j:image:w300

部屋は6畳の和室が基本になってます。一階には風呂付の部屋もあります。泊ったこと無いので使い勝手は知りません。


窓から

f:id:naqtn:20100630091315j:image:h200 f:id:naqtn:20100630103636j:image:w200

f:id:naqtn:20120622182155j:image:w200 f:id:naqtn:20100630103555j:image:w200

宿は仲本集落の中に建っています。手前には近所の住宅があり、その向こうには牧草地が広がっています。(黒島は畜産(牛の繁殖)が主な産業です。)


食堂

f:id:naqtn:20120625144742j:image:w300

素泊まりも出来ますが食事付きをお勧めします。主人は島人(しまんちゅ、島の出身者)で一度島を出てから料理を学んだそうで、いろいろなバリエーションがあっておいしいです。食べたいものがあったら言っておくと作ってくれるかも。季節とタイミングが合えば島で取れた食材(魚、牛、野菜、野草など)が出てきたりもします。夕食は19時、朝食は8時です。夕日を見たりして食堂へ行くのが遅くなっても大丈夫です。(肝心の食事の写真の手持ちがありませんでした。。。)


ゆんたく

f:id:naqtn:20061022222516j:image:w300

宿の個性が出る夜のゆんたく。この宿では夕食後に飲みたい人が飲み物など持ち寄ってなんとなく始める感じで、参加するのも途中で抜けるも自由です。時々、主人と同世代の島の若者やご近所さんも飲みにやって来ます。天気が良ければ庭のガジュマルの木の下で。夜風が吹くと、とても心地よいです。この島風(しまかじ、しまかぜ)はとても良いものです。

八重山民謡を聞きたかったら主人に頼んでおくと、たぶん弾いてくれます。この唄も宿のお勧めポイントの一つです。


f:id:naqtn:20120625171756j:image:w300

f:id:naqtn:20120625172316j:image:w300

外飼いの猫が宿にお邪魔しにくることがあります。気が向いたら遊んでくれる奴も居ます。嫌いな人も居るでしょうから、人が集まる食事中は追い出しましょう。


クーラーと窓

f:id:naqtn:20120625111950j:image:w200 f:id:naqtn:20120620093252j:image:h200

エアコンが付いている部屋もありますが、窓を開け放して風を通した方が心地よいです。しかしどういうわけか窓に網戸が無く、季節の虫も通り過ぎていきます。ヤモリも普通に天井にへばりついてます。まあ八重山離島とはそういう所です。天気によっては夕方と朝に蚊が出るので蚊取り線香を焚きます。

マンガやらダーツやら

f:id:naqtn:20120625144646j:image:w150,left

本格的に天気が崩れると島の風雨はとても激しく外には出られません。そんな時は昼間から酒を飲むかマンガを読みふけるかひたすらゴロゴロするか。たまにはそんなのも良いものです。


風呂場

f:id:naqtn:20120625131847j:image:w150,right

シャンプーや石鹸はあります。タオル類は無いので持って行きましょう。水道管がなんか無骨にむき出しになってます。離島では島の人は自分たちで直せるものは直します。専門業者が島には居ませんから。


寝具

f:id:naqtn:20120625153138j:image:w150,left

始めて八重山に来た時にちょっと驚いたのがこの寝具。この宿に限らず八重山の古いタイプの民宿ではこんなんですが、ぺらんとした敷布団とタオルケットと枕だけです。ふかふかだと暑いだけですから、こうなのでしょう。でも正直なところ慣れないと背中がちょっと痛くなります。


仲本海岸

f:id:naqtn:20120626141144j:image:w200 f:id:naqtn:20061020124653j:image:w200

宿から自転車で数分で着きます。歩いても行けます。砂浜からスノーケルで海に入ると、ほんのちょっと行っただけで色鮮やかな魚とサンゴを見ることが出来ます。宿から気が向いた時にお手軽に綺麗な海に行ける、ってことでは私が知っている中では一番の浜です。天気、潮の満ち引き時刻、体調に注意して、干潮に合わせて行きましょう。

荷物を自転車や浜に放置しておくとカラスに狙われます。休憩時間の昼飯にしようと思っていたパンを持って行かれたことがあります。波に削られた岩の下に置いておくとよいみたい。(海の様子がうまく撮れている手持ちの画像がありませんでした...)


飲み物

f:id:naqtn:20120625144816j:image:w150,right

冷蔵庫に缶ビールやジュースなどが入っています。取り出す時に自分で伝票に書きこんで、後で宿代と一緒に清算します。豪の者は伝票にビールの正の字を幾つ並べられるかに情熱を注ぎます。泡盛なども同じ方式で買えます。(その昔は伝統的に泡盛は無料だったらしいが。)

お茶類は無料です。水出しのお茶、紅茶ティーバック、一杯取りのドリップコーヒーなどがあります。



送迎

石垣で船に乗る前に電話をして乗る船を伝えておくと、入港に合わせて迎えに来てくれます。(港から宿までは距離があるので徒歩はかなり厳しいです。また、当日の飛び込みの宿泊も受け入れてもらえるようですが、島に渡る前には連絡するのが常識的にも無難です。)

帰りは朝ごはんの時にでも出発予定を伝えておくとよいでしょう。(相談しておけば部屋のやりくりに余裕があれば出発まで荷物を置いといてもらえたりもします。)


自転車

無料で使えます。島ではすぐに鉄が錆びていくものですから、状態を確認して良い奴を選びます。


洗濯

洗濯機を無料で借りられます。洗剤も使えます。午前中にカラッと晴れていたのに午後に土砂降りなんてこともあるので、干している間は空模様に気をつけるべし。



データ

  • 名称 民宿みやよし荘
  • 料金
    • 二食付き 5000円
    • 夕食のみ 4500円
    • 素泊まり 3000円
  • 郵便番号 907-1311
  • 住所 沖縄県 八重山郡 竹富町 黒島 1830
  • 電話 0980-85-4152


まとめ

良い所:食事、ゆんたく、民謡、猫、島風、珊瑚の海。人によっては相性注意:虫、寝具、猫。

目立った観光スポットがある島ではないのでコース的なものもあるわけも無く、楽しみ方はそれぞれ自分で見つけ出すようなところですが、それがまた面白いです。親戚の家に泊る夏休みみたいで。島について知りたいことや、宿への希望があったら主人に気楽に相談してみると良いと思います。


おまけ 2012年〜2013年 の行事予定

2012/7/29 豊年祭
ハーリー、奉納芸能
2012/8/30 - 9/1 旧盆
30, 31 アンガマ、9/2 獅子舞
2012/10月上旬ごろ 結願祭
奉納舞踊
2013/2/10 旧正月
芸能、綱引き。綱引きは観光の人も参加できるそうです。
2013/2/24 牛まつり
 

  • おことわり:一部数年前の写真を使用しました。
  • 行事予定の2012年分の記述が2013になっていました。(7/14修正)