■Androidで個人情報漏えい対策(DroidWall)
BlackHatでのLookout社の発表について、まぁそういうこともあるだろうとは思っていたものの、実際のところインストール時に「ユーザが許諾を与えているから」というのが免罪符になってしまうのもどうかと思うので（ソースが公開されていてチェックするのがAndroidプログラマであるなら適切な判断もできるかもしれないが、一般ユーザに適切な判断を求めるのは難しい）、せめてもの自衛用にPCにあるようなPersonal Firewallがないかと調べてみた。
アンチウイルスソフトと異なり、この分野はまだ競争があまり無いようで、SMSや受話を選択受信する主にinbound方向のメッセージ向け「Firewall」はいくつかあるものの、送信側のコンテンツフィリタリングや、アプリケーションの外部との通信自体を制御するPersonal Firewallはほとんどなく、ひとつしか見つけられなかった。それが以下。
Droidwall
http://www.cyrket.com/p/android/com.googlecode.droidwall/
このアプリケーションは要rootなのが微妙なところだが、インストールするとその端末にインストールされたアプリケーションを一覧にし、それぞれが3G/WiFi接続時にネットワーク接続を可能にするか選択することができるようになる。残念ながらport単位とか接続先単位の制御ではなく、アプリケーション単位にはなるものの、wallpaper系のアプリが勝手に通信することは防いでくれそうだ。
当面の間、このアプリケーションが利用可能な端末では、思わぬアプリの意図しない通信を制限する手段になってくれると思われる。ただし、Googleはアプリの海賊版対策としてネットワークを利用した認証を進める方向を打ち出しているため、早晩Droidwallの現在の仕様では使えなくなるアプリが出てくる可能性があり、portや通信先を選択可能な機能アップが求められてくる。
今回の発表では「不正な通信」かどうかは現時点で不明となっているようだが、いつ同様の事件が発生してもおかしくはないので、このようなPersonal Firewall系アプリによる対策手段は求められてくると思う。WindowsのZoneAlarmやMacOSXのLittle Snitchのように、通信時にアラームをあげてくれるタイプの製品が登場することを期待したい。
android, firewall, security
Loading...
■Android専用アプリで設定可能な無償UTM GB-Ware
たまたま見つけたのでメモ。無償利用は2Userまでというところが微妙だけど、Home利用なら十分かもしれない。またAndroid専用アプリが用意されているのは珍しいということで紹介。いずれ試してみたい。GB-Wareは主にアプライアンスで販売されているUTM。AstaroやEndianと同類。
GB-Ware（2Userまで無償）
http://www.gta.com/firewalls/gbware2user/
GB-Auth（GB-Ware用Androidアプリ）
http://www.cyrket.com/p/android/com.gta.android.gbauth/
以前調べた無償利用可能UTMの一覧にも追記。
http://blog.isnext.net/issy/archives/218
android, gb-ware, UTM
Loading...
■公開鍵認証方式でsshを利用する
sshdは攻撃されやすいので、できるだけ標準状態からport及び設定を見直すことを推奨。ここではパスワードを使わず公開鍵でsshを利用する。ここではCentOS5サーバの初期状態から設定追加する状況を想定した手順を書いておく。
１）自マシンで鍵を作成する（MacOSXをクライアントとする）
[code]$ ssh-keygen -t rsa -C “myaddress@example.com”[/code]
パスワード入力時にエンターを押すことでパスワード不要の鍵が作成可能
作成が完了すると以下に必要ファイルが作成される
~/.ssh/id_rsa（秘密鍵）
~/.ssh/id_rsa.pub（公開鍵）
上記はRSA鍵の場合。DSA鍵を作成する時は以下。
DSAではid_dsa,id_dsa.pubのファイルが作成される。
[code]$ ssh-keygen -t dsa -C “myaddress@example.com”[/code]
自アドレスを入力するのは後からキーの持ち主を判別するため。
実際に入力するテキストはなんでもOK。
２）公開鍵をサーバに送信する
リモートサーバにid_rsa.pubを送っておく
[code]$ scp ~/.ssh/id_rsa.pub root@xxx.xxx.xxx.xxx:/tmp[/code]
３）rootでサーバにログインしてsshdの設定を変更する
[code]# vi /etc/ssh/sshd_config[/code]
以下の３行を修正
port 10022
PermitEmptyPasswords no
PasswordAuthentication no
４）ssh用アカウント「remoteuser」を作成して公開鍵を登録する
[code] # adduser remoteuser
# passwd remoteuser ←パスワード設定する
# su remoteuser ←ユーザを変更する
$ cd ~
$ mkdir .ssh
$ cat /tmp/id_rsa.pub > .ssh/authorized_keys
$ chmod 0600 .ssh/authorized_keys
$ chmod 0700 .ssh
$ exit[/code]
５）iptablesを修正してsshdを再起動する
[code]# vi /etc/sysconfig/iptables[/code]
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 10022 -j ACCEPT 行追加
[code] # service iptables restart
# service sshd restart[/code]
６）クライアントからsshでアクセスして確認
[code]$ ssh -p 10022 remoteuser@xxx.xxx.xxx.xxx[/code]
うまくいかない時は -vを付けて確認
[code]$ ssh -v -p 10022 remoteuser@xxx.xxx.xxx.xxx[/code]
CentOS5では以下の行はコメントアウトのままで問題ないので外さなくてOK。
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
centos, security, ssh
Loading...
■指定ユーザ以外suできない設定
CentOS5においては、rootのパスワードを知っていればadduserで通常作成したユーザでもsuできてしまうため、セキュリティの観点から指定ユーザ以外はsuできないように設定を行う。
usernameというユーザにsu権限を与える場合の設定。
■設定手順
[code]# vi /etc/login.defs[/code]
以下を追記
SU_WHEEL_ONLY yes
[code]# vi /etc/pam.d/su[/code]
#auth required pam_wheel.so use_uid 行を以下のように変更
auth required pam_wheel.so use_uid
[code]# vi /etc/group[/code]
wheel:x:10:root 行を以下のように変更
wheel:x:10:root,username
[code]# reboot[/code]
再起動して動作確認
centos, security, tips
Loading...
■lm_sensorsによるCPU温度チェック
CentOSを導入したマシンのCPU温度の管理のためlm_sensorsを導入する。CentOSのyumでinstallされるバージョンはかなり古いので、lm_sensorsのHPから直接ダウンロードして最新版を導入。現時点の最新版は3.1.2。
■sensors-detectで自マシンが対応しているか確認
sensros-detectコマンドを使うことでlm_sensorsを導入する前に、自マシンのセンサーが読み取れるか確認することが可能。perlが必要。基本的に全てYESでチェックして、最後の設定書き込みだけNOにしておけばOK。
[code]# cd ~/download
# wget http://dl.lm-sensors.org/lm-sensors/files/sensors-detect
# chmod +x sensors-detect
# ./sensors-detect[/code]
■lm_sensorsの導入
sensors-detectで対応が確認できたら以下の手順で導入。
[code]# wget http://dl.lm-sensors.org/lm-sensors/releases/lm_sensors-3.1.2.tar.bz2
# tar jxvf lm_sensors-3.1.2.tar.bz2
# cd lm_sensors-3.1.2
# yum install bison flex
# vi Makefile
PREFIX := /usr/local
↓
PREFIX := /usr
# make all
# make install
# cp /etc/sensors3.conf /etc/sensors3.conf.org
# cp prog/init/lm_sensors.init /etc/init.d/lm_sensors
# mv ~/download/sensors-detect /usr/sbin/
# sensors-detect[/code]
残念ながらCore i7 860はまだサポートされていないようでcoretempで温度を取得できなかった。検索しても対応の仕方が見つけられなかったので、とりあえず手順だけ書いておく。
centos, lm_sensors
Loading...
■MacOSXで.m2tsをmp4変換
動画編集のため、FullHDカメラで撮影した.m2tsファイルをUSB外付けHDで渡されたのでiMovieで取り込もうとしたところiMovie09では取り込むことができなかった。iMovie08までは時間はかかったものの、できていたはず…と思っていたのだが、とりあえず作業のためmp4に変換することに。
.m2tsファイルをMacで扱う選択肢は少ないが、今回はHandBrakeのNightlyBuildで変換することにした。正式なリリースではないので全てのケースでうまくいくかわからないが、今回はうまく変換できたのでOK。８コアフルに使ってかなり高速で変換してくれるので非常に助かる。使ったのはHandBrake-svn3428-MacOSX.5_GUI_x86_64.dmg。
HandBrake Nightly Build
http://build.handbrake.fr/job/Mac64/
mp4, tips
Loading...
■SNS用高C/Pサーバの構築
現在さくらインターネットで運用しているSNSサーバの維持運用が、データ量やネットワークトラフィック、支払い金額のバランスで厳しくなってきたため、自宅運営のネットワークに移転できるよう専用サーバを構築する。構築条件は現状からスペックを大きく落とすのは厳しいため、以下のように設定する。
現状のサーバ
NEC i120Ra-e1 QuadCore Xeon 2CPU
CPU Intel Xeon L5410 2.33GHz x2
メモリ 8GB
HDD 750GB RAID1
回線 10M共有回線
年間費用 48万円
移行後のサーバ
自作PC Core i7 860 2.8GHz
メモリ 8GB
HDD 500GB 以上（一部SSD）
回線 Bフレッツ100M共用
年間費用想定 12万円（ハード込み）
物理8コアから論理8コアへ、メモリは現状維持、HDDはRAIDを行わない代わりに同居他サーバにバックアップを取得する。SNSデータのパフォーマンス確保のためSSDを導入する。SSDは１年に１回入れ替えを想定する。
■構成パーツ
ケース
Antec NSK3480 ¥10,979（380W 80PLUS電源付）
CPU
Intel Core i7 860 BOX ¥27,090（リテールクーラー利用）
マザー
ASUS P7H55-M ¥7,980
メモリー
Team DDR3 SDRAM PC3-10600 2Gx2 ¥8,750 x2（合計8G）
HDD
Hitachi HTS725050A9A364 ¥6.750（2.5インチ 500G）
SSD
PQI X-25M 約２万（手持ち流用 2.5インチ 80G）
VGA
GIGABYTE GV-NX62TC256D8 ¥2,180（中古）
その他
マウンタ等 ¥2,780
合計金額 約9.5万円相当
■消費電力削減の過程
上記の通りCore i7を採用したため、消費電力に対するパフォーマンスは相対的に優れた構成になっているが、当初これらを組み上げた際はVGAがSapphire ULTIMATE HD4670（RADEON 4670 ファンレス）だったためか、USBメモリから起動したUbuntu10.04で消費電力をワットチェッカーで確認したところ、かなり大きな値を示した。そのためファンレスVGAを交換することでどれくらい消費電力が変わるのか確認してみた。（P＝ピーク/Ｉ＝アイドル）
Sapphire ULTIMATE HD4670 (RADEON 4670) P 112W / I 54W
MSI RX1600XT-T2D256EZ (RADEON X1600XT) P 103W / I 43W
GIGABYTE GV-NX62TC256D8 (GeForce 6200TC) P 93W / I 32W
GF6200TCは低消費電力重視で設計されたチップということもあり、ファンレスのボードであるだけでなく、ヒートシンクの小ささも特徴になっている。じゃんぱらで見つけた時にはどれくらいW数が下がるのか興味深かったが、GF6xxx系は比較的消費電力が大きいシリーズと言うことだったので、それほど期待しすぎてはいけないと思っていた。ところが実際計測してみると、さすがに低消費電力を謳うだけあって、当初より20W近い低減が可能になり、とても効果は高かった。
■静音性
静音性能が比較的高いAntecのケースを利用したこともあり、ほぼ無音に近い（近接していればわからなくはないが、1m離れるとほぼ聴こえない）マシンとなった。深夜でもエアコンの音の方が大きくマシンの動作音は全くわからないほど。
■CentOS 5.5 64bitの導入
CentOS 5.5 x86_64のnetinstall.isoをダウンロードして、USB CD/DVDドライブで起動してインストールを試みるも、なぜかi386のパッケージを要求するためx86_64のパス指定ではエラーになりインストールが不可能。大丈夫かCentOSのメンテナ…。
仕方がないのでx86_64インストールDVDをダウンロードして、こちらからインストール。今度はうまく行き8コア、8Gメモリ、ネットワークも問題なく認識動作。SNSサーバとしての構築プロセスは別途記事にする予定。
centos, pc
Loading...
■UTM専用マシンの静音化
以前書いた以下のエントリーの続き。夏から稼働させるネットワーク用のUTMとして試験的にEndian UTMで常時稼働させる前提で考えた際に、電源とCPUファンが近接しすぎていることによるノイズが（比較的耳障りでないとはいえ）やや気になったので、ACアダプタ化することで静音化したメモ。
UTM専用マシンを低予算で組む（Astaroのインストール）
http://blog.isnext.net/issy/archives/232
■ACアダプタ化キット 日本PCサービス SRD2D080SATA2-24
購入したのは日本PCサービスのSRD2D080SATA2-24。テクノハウス東映で7880円。1000円安価なSRD2D080V21-24と少し悩んだが、5VSBでのPEAKの値が2.0Aと3.0Aと差があり、気持ち余裕のある値の大きいSRD2D080SATA2-24にしてみた。常時起動前提なのであまり問題ない気もするが、少しでも電源が安定してくれる方が安心感がある。
このキットのコネクタ構成はMX1202-BK付属のSFX電源とほぼ同じなので、延長や分岐用ケーブルは不要だった。（電源を取り外したバックパネルの穴はダンボールをカットしてはめ込み）
電源の詳細は以下へ。
http://pc.j-pcs.info/cn12/SRD2D080SATA-24.html
■現状の構成
ケース：岡谷 MX1202-BK Mini-ITX
電源：日本PCサービス SRD2D080SATA2-24
マザーボード：Intel DG41MJ LGA775 Mini-ITX Giga Ethernet RTL8111D
CPU： Intel Celeron DC E3400
メモリ：PQI DDR2-800 1G x2
HDD：Western Digital WD800BEVT
PCIカード：Corega CG-LAPCITXY 100M Ethernet RTL8139D
この構成でSFX電源使用時に最大52W 常時31W程度となっていたものが、最大54W（起動時各種プロセスが起動中の時）常時26Wとなった。常時使用電力が5Wも下がったのは非常に大きい。使用電力量からACアダプタ化しても大丈夫ではないかと推測して今回試してみたが、動作にも問題なく音もほぼ無音（Intelのリテールクーラーは非常に優秀）になったことで効果はとても大きかった。
これだけ静かでパフォーマンスもそこそこ出るようだと、メンテナンス用サーバにもう１台組んでみたいと思ってしまう。
endian, pc, UTM
Loading...
■TOSHIBA Android端末 dynabook AZ レビュー
7月3日秋葉原で行われたASCIIのイベントで先日発表された東芝の新製品「dynabook AZ」の実機をみてきました。 ３台ほど展示がされていて、開催時間直後に行ったことで十分に試す時間がとれたので、簡単なレビューを書いておこうと思います。
製品版レビューを9/2追加しました
http://blog.isnext.net/issy/archives/375
■ハードウェアについて
やはりすごい薄いってのが実感ですね。液晶は日中、それも快晴でこそないものの明るい屋外のイベントにもかかわらず表示は見やすく、かなりキレイな印象を受けました。グレアタイプのため反射は大きいのですが、さすが国産機と思いました（比較対象はUL20AとU100なので…）。
特徴になっているパターン入りの樹脂外装は指紋とかの心配もなく若干安い印象はあるものの実用的だと思いました。展示台が微妙な取り付け具合でしたが、キーボードは妙なヘタリ感もなくペチペチした打ち加減だけどそれなりに使えそう。ファンクションボタン類の配置は慣れるしかないかなと思います。タッチパッド下のクリックボタン部がパーツが強度不足ですぐに壊れそうな感じなのが一番気になりました。
■操作感について
デスクトップ画面、東芝製のランチャーは好みの問題もあると思いますが、キーボードで操作するには悪くないかなと思いました。通常のHOMEっぽい画面も選択できるので使い分けは可能そうです。
心配していたトラックパッドの操作はそれほど違和感ありませんでしたが日本語入力の切り替え動作がいまいち…わかりにくいというか…アプリ毎に切り替わりが一定していないというか、なんだかとても不安定な印象でした。
起動してしまえばそこそこ動作は速いと思いますが、起動時間がちょっと長く感じます。電源ONからデスクトップ表示まで約40秒。実際に日本語入力などデスクトップ操作が軽快に可能になるのに更に10秒以上。数回試した起動時のおよその時間（手動ストップウォッチなので正確じゃないですが）は以下のような感じです。
電源ON→dynabookロゴ表示(6秒)→Androidロゴ表示(18秒)→デスクトップ表示(40秒)
電源オフは3秒ほどで完了。起動中にディスプレイを閉じるとすぐにサスペンドモードになるようですが、ここからディスプレイを開けてもすぐには画面が表示されず、ホームキーや戻るキー、電源ボタンを押してもすぐに戻ってこないので、復帰はなにかキーコンビネーションになっているか、サスペンドからの復帰も数十秒かかっている可能性があります。一応いろいろしてたら画面は戻ってきたのですが、なにで復帰できたのかわかりませんでした。
WiFiでネット接続できたので、標準ブラウザとOperaでいくつかのサイトを表示させてみました。表示自体は決して遅すぎることはないのですが、速いとは言えない印象。縦長ページでのブラウザスクロールはかなり遅い感じ。サクサクというよりカクカク。スクロール操作はタッチパッドの右端を縦になぞることでちゃんとできました。一番快適さを期待したブラウザがこの状態なのはちょっと残念。
操作に関しては、全体的な印象として2GメモリとSSD搭載してUbuntu10.04インストールしたU100の方が全般的に快適という感じです。ただ稼働時間の長さ、薄さ軽さは大きな強みなので意外と売れるような気がします。あとは液晶が比較的キレイでかつ動画再生能力が高いので、そちらの用途では活躍してくれると思います。
■搭載OSについて
TOSHIBA Service Stationというアプリに表示されていた内容は以下です。
アプリケーションバージョン：2010.06.07
Androidバージョン：2.1.4.0021
モデル名：dynabook AZ
型番：PND01J-XXXXXX
設定アプリで表示されていた情報は以下。
モデル番号：TOSHIBA_AC_AND_AZ
ファームウェアバージョン：2.1
ベースバンドバージョン：R1K06
カーネルバージョン：2.6.29-arm2-svn1296 / sl@project-laptop #1
ビルド番号：PAZ0000,4,0021-PVT-r1326
Android携帯同様、3Gの項目もありましたが「SIMが挿入されていません」と表示され、通知バーでは×マーク付のアンテナ表示になっていました。また、TouchPadという設定メニューが追加されていたことを確認しています。
ということで、netbookを大きく上回るのはおそらく稼働時間くらい。全体的には価格的にもnetbook程度だなという印象でした。Tegra2採用ということで動画再生能力を求める向きにはオススメですし、長時間稼働を必要とする用途にもとてもオススメできると思います。Android端末としてソフトウェアやレスポンス的なアドバンテージはあまり強く感じませんでしたが、それを補うハードウェア的な要素（軽量薄型超長時間稼働）があるので、価格次第で検討したいところです。３万円代なら購入してしまうかも…？
android, review
Loading...
■AndroidとSIP/VoIP 2010/06版
Androidの記事をこちらに書くことにしたので、他所に書いておいたものから、こちらネタっぽいものを転載しておくことにします。この記事はjugemで書いていたものをベースに加筆修正しています。
【12/03追記】2010/12版を記事追加しています。最新状況は以下へ。
http://blog.isnext.net/issy/archives/556
ということで、今回は2010/06/13ごろAndroid端末のSIP環境について一部検証？した内容になります。
現在自宅はNTTのひかり電話になっていて、CommuniGate ProのSIPサーバ機能とRSIP（リモートSIP）機能を利用してCommuniGate Proサーバ自体をひかり電話の子機としてRV-230SEにレジスト、iPhoneやデスクトップマシンからCommuniGate Proサーバに自アカウントでSIPレジストして電話を発着信できるようにしています。
ひかり電話では対応するコーデックが、ISDNで使われるコーデック「G.711 μ-Law」のみになるので、これに対応したSIPクライアントを使わないと外部通話はできないことになります。面白いことにiPhoneで利用可能なSIPクライアントのメジャーどころはほとんどG.711 μ-Lawに対応しているらしく外部通話が可能になるのに対して、AndroidのSIPクライントは対応しているものが極めて少ない状況です。
現在のところ通話まで利用可能だったのはfringとLinPhoneくらいのもので、ほとんどがG.711 μ-Lawに対応していないためエラーになり、コーデックとしては対応しているはずのSipAgentは、OSバージョンとの互換性問題かもしれませんが、なぜか音声が一切利用できないという状況でした。
G.711 μ-Law自体はソース公開されているコーデックなので、利用できないものではないと思うのですが、このヘンがAndroidマーケットとiPhoneマーケットの開発者層の差なのか、ツールの差なのかとても不思議な気がします。（たまたまiPhoneでよく使われるSIPライブラリがあってG.711 μ-Lawを含んでいるだけなのかもしれませんが…）
iPhone 4/iOS 4でVoIP用APIがマルチタスク対応になるので、これまでの待ち受け上の不便が徐々に解消される可能性があるとは言え、Android端末でもぜひともひかり電話子機としてアドバンテージを活かせるよう、多くのSIPクライアントがG.711 μ-Lawに対応してくれることを期待したいと思います。
５月前半ごろ試した結果なので現在は多少変わっているかもしれませんが、ひかり電話で試したアプリを以下に。もう数個試した気がするのですが全然NGで記録するのすら忘れていた模様。試した電話経路は WiFi接続でNexus One →CommuniGate Pro →RV-230SE →ひかり電話網 →WillcomPHS電話
・aSIP ×G.711 μ-Law未対応
・LinPhone ○ 通話可能 遅延少ない
・Sipdroid ×G.711 μ-Law未対応
・CSipSimple ×G.711 μ-Law未対応
・fring ○ 通話可能 レジストに多少時間かかる 遅延少々
・SipAgent ×G.711 μ-Law対応なのに音声出ない聴こえない
・Nimbuzz ×SIP未対応…iPhoneではOKなのに…
android, communigate, sip, voip
Loading...
