dsa認証のやり方（FreeBSDとwindows）

前々回の投稿でパスワード認証を禁止したが，その際，dsa認証を使うのがよい，と書いた。今回はその具体的な方法を書いておこう。筆者はいろいろな都合で，windowsマシンからFreeBSDのマシンに入って作業をすることが多い。なので，(1) FreeBSDの場合，(2) MacintoshのOS-Xの場合，(3) windowsのPuTTYを使う場合，について書いてみる。

FreeBSD：sshサーバーに対する辞書攻撃の防御

FreeBSDでsshをあげているが，かなりの頻度で辞書攻撃されている。webサーバーをあげていて，知り合い（同窓会）を相手にしているので，誰かのマシンがウィルスに感染でもしているのだろうか？基本的にこのサイトは誰にも言ってないから，どっかから情報が漏れているに違いない。ま，でも知られた以上は仕方ないので，攻撃を遮断しないといけない。一応passswordログインはできないようにしているが，攻撃されている間は何度もアクセスしてくるので，回線に負荷をかけるし，auth.logは増えるし，とにかく気に入らない。ということで辞書攻撃の対策を探ってみた。検索語は「FreeBSD 辞書攻撃」としてGoogleにお世話になった。幾つか出てきたが，挑戦してみたのは，ktj Dragonさんのサイト。maxlogins.plというPerlスクリプトを使うパターンらしい。やり方は，何度もsshでアクセスしようとするIPをブラックリストとして，ログファイル（/var/log/maxlogins）に書き込むらしい。で，それを使って /etc/hosts.allow で /var/log/maxlogins にあるIPからの接続を拒否してしまうらしい。

FreeBSD：やっとsshdでパスワードによるログインを禁止できた

今まで数年FreeBSDを運用してきたが，ひとつだけ解決できていない問題があった。それはsshdへのパスワードによるログインの禁止。よくネットで検索すると，/etc/ssh/sshd_configで

PasswordAuthentication no

として，

/etc/rc.d/sshd restart

とすればよい，と書いてあるが，これがうまくいかない。何故かパスワードでログインできてしまう，ということが多々あった。jail環境下でweb siteをあげたりしているので，どうしてもパスワードログインができないようにしかったのだが，それがやっとできた。どうしたかというと，/etc/ssh/sshd_configで

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

とした。特に2行目のChallenge...が必要だった。これがないとどうもパスワードでのログインに挑戦させてくれてしまうようだった。これを「no」にしたとたん，パスワードによるログインができなくなってしまった。これってどのリリースからあるんやろ？以前の場合はこれを気にしなくてもパスワードによるログインを禁止できたのかなぁ？このChallenge...はデフォルトでyesになっている。それやったら折角「PasswordAuthentication no」ってしてもあかんやん。sshd_configのコメントにも何か書いておいてほしいなぁ。今までの/var/log/auth.logやdaily_status_security.logなんかを見ると，辞書攻撃のオンパレードになってる。これで一気に辞書攻撃が減るかなぁ？？？
　ちなみにパスワード認証を禁止するためには他の認証方法が必要。ワンタイムパスワードやdsa認証，rsa認証など多数あるけど，とりあえずはdsa認証ぐらい使えるようにしておきましょう。
======================================================================
(追記)
やっぱり辞書攻撃は減らなかった。辞書攻撃が減らないのは考えてみたら当然。辞書攻撃はいろんなuser名でログインを試みる攻撃なので，たいていがInvalid userになって認証まですすめない。一方パスワード認証を禁止した効果は認証しようとして初めて現れる。そりゃ辞書攻撃は減らないわなぁ。仕方ないから次の投稿「辞書攻撃」に挑戦してみた。

ソースを見せない

ajaxという技術（簡単に言うとJavaScriptをうまく活用して，動的なページを作るって技術，だと思っている）を使うと，web siteのソースコードが見えなくなる，ということに気づいた。というか，他の人が作ったサイトでソースが見えないことがあったから気づいただけだけど。普通の人にソースを見せないようにしようと思えば，< div id="xxxx"> < /div>という空のdivisionを用意しておいて，< body onload="OpenPage()">のように読込みと同時にJavaScriptでidがxxxxというdivisionにページを読ませればいい。OpenPage()には当然メインの部分を読み込ませる命令を書かないといけないけど，prototype.jsなどを使うと簡単に読み込ませることができる。だから知らない人には中身を見せなくてすむ。ただし，ツールを使えば簡単に見ることはできる。だってブラウザで実行してるんだもん，ソースは原理的に見えるはず。具体的には，例えば，JavaScriptistってサイトがあるが，そこでJavaScript入門みたいなページで，firefox用のツールがいろいろ載ってる。その中のWeb Developer Toolbarというやつなら，実行結果を反映したソースを表示する，ってのがあって，簡単にソースを読めてしまう。でも知らない人にはわからないから，お遊びで中身を見せないようにしておいて，隠しページを置くと楽しめるかもしれない。ただし，隠しページは検索エンジンにはスパムサイトと判断されることがあるらしいので，あまりまじめなサイトでは遊ばない方がいいかもねぇ。
ちなみにFreeBSD 7.0で，perl 5.8.8が動いている環境だと，JISコードで書いたページでも読み込ませるファイルはUTF-8で保存してないと文字化けしてしまった。内部でutf-8を使っているというのはどうやらほんとらしい。でもなんでそれでいいんだろう？

FreeBSD：Unicodeにはまる

今回もFreeBSDネタ。以前もちょっと書いたが，今回も文字コードの話。最近のPerl (Perl 5.8.8や5.8.9) では，内部処理ではutf8を使っているらしい。でもunix上では未だにeucが使われていたり，windowsやmacintoshではshift_jisを使っている。そこで必要なのが文字コードの変換。apacheで表示させる時に，どの文字コードを使うのかは，アプリケーション次第。新しく作ったサイトはいきがってutf8にしてみたが，net上に落ちてるスクリプトはshift_jisだったりする。以前，アクセスログを取り，解析，表示してくれるスクリプトを拾ってきた。windowsを念頭においているのか，文字コードはshift_jisで書かれていた。別にそれはよいのだが，このアクセスログ解析スクリプトが表示する検索文字列がよく文字化けする。おかしいなぁ，と思ってブラウザの文字コードをutf8にしたら文字化けしてたところだけちゃんと見えて，今までちゃんと見えていた検索語が化ける。しばらくそのまま使っていたが，どうも気になって仕方ない。そこで，ちょちょいと調べてみた。
　拾ってきたスクリプトでは文字コード変換にはjcode.plを使っていた。ところが，jcode.plはutf8に対応していない。だからutf8があると表示が文字化けしていたのか。ところで，４つ前の投稿にも書いたが，最近のperlではモジュール，Jcode.pmとEncode.pmを使うみたい。投稿を書いた時にはEncodeモジュールを使ったのだが，その使い方は、
---------------------------------------------------
cgiのトップに

use Encode;
use Encode::Guess qw/ shiftjis euc-jp utf8 7bit-jis /;

と書いておき、

$in_name = encode('utf8', decode('Guess', $in_name));

とすると、もとの文字コードを推定して、utf-8に変換してくれる。
---------------------------------------------------
ってな感じだった。今回もutf8に対応していないjcode.plのconvertルーチンを使っているところを探して，encodeとdecodeを使って，

$in_name = encode('shiftjis', decode('Guess', $in_name));

としてShift_JISに変換してやればいけるはず，だった。
　ところが，これがうまくいかない。解析ルーチンのcgiが途中で止まってしまう。どこで止まっているかと言うと，utf8の文字列が出てきたところ。そこで止まって，それ以上表示してくれない。困った。apacheのエラーログ，/var/log/httpd-error.logを見ると

shiftjis or utf8 at /usr/local/lib/perl5/5.8.8/mach/Encode.pm line 166, 
     referer: http://xxxxxxxxxxx/yyy.cgi

とでる。おや？これはもしや推定時に困ってるのか？と思い，ネットで検索。「perl Encode」などで検索していると，http://www.bugbearr.jp/?Perl%2FUnicodeというページにたどり着いた。そこには「自動判定したい場合は、Jcode.pm を使う。(Encode::Guess は望ましい動作をしないようだ…)」と書いてある。下の方の「文字コードを自動判別させるには」という所を見ると，どうやらEncodeモジュールの推定はちょっと甘くて，shift_jisかutf8かを決めてくれないみたい。Jcodeモジュールはどっちかわからない時にも，ある程度推定して，文字コードを特定するみたい。そこで，上記サイトにあるように，トップの方で

use Jcode;

と宣言しておいて，

my $sjis = jcode($str)->sjis;

としてみた。そしたらうまくいった。うーん，やっぱりperlは奥が深いですねぇ。
======================================================================
(追記)
後日、自分で記事を参考にしたのだが、Jcode.pmをどうやってインストールしたのか忘れてしまっていた。どうしたかというと、FreeBSDなので、

/usr/ports/japanese/p5-Jcode/

からインストールした。/usr/ports/japanese/p5-jcode.pl/はjcode.plをインストールしてしまうので、間違えないようにしましょう。

FreeBSD：portupgradeにはまる

今日も前回と似たようなネタ。FreeBSDでサーバーを立ち上げようとしてる。マシンが遅いから，なかなかソフトウェアのインストールが終わらない...ぶつぶつ。
　ところで，今日の話題はportupgrade。私にFreeBSDを教えてくれたやつは，基本はdefaultと言って，option設定もあまり追加しないし，portupgradeもあまりしない。何故って，下手にportupgradeするとアプリケーションがよく動かなくなることがあるから。でも私はセキュリティのこともあるし，と思って毎回upgradeしてしまう。で，よくトラブルに巻き込まれる。今回は今までの経験をメモしておこう。

FreeBSDで無線LAN

FreeBSDのrelease 7.1をインストールしてみた。理由はあまったノートをwebサーバーにしようと思っているから。FreeBSDのインストールは，インストールCDのイメージを取ってきて，CDからインストール。でもそれは起動だけに使って，インストールするファイルはネット上からHTTP-proxyを通して取ってくる作戦にしてみた。いろいろなアプリケーションはcvsupでportsを最新にしてからインストールした。インストールはこれまでデスクトップで数台行ってきたので，大きな問題なく完了。設定ファイルも他のFreeBSDマシンからコピーすればよいので，さっさと作業できた。

AjaxとBubbleToolTips

これもweb絡みのお話。ちょっとネットでAjaxについて調べてみた。一番興味を引かれたのはアムステルダムのサッカーチームだったけど、これはちょっと領域外。問題のAjaxは一言で言うと、JavaScriptを使って、ページの再読み込みをあまりさせないで、かつ、マウスの動きに応じてボタンの色が変わったり、写真が入れ替わったりするってやつみたい。同窓会のページはcgiで再読み込みしまくってるから、Ajax風にできないかと思って少し挑戦したけど、めんどくさくなってやめちゃった。それでも何かおもしろい事できないかと思って、メニューボタンの上にマウスを持って行くと、色が変わるようにしておいた。これは色の違う画像を用意しておいて、onMouseOverで違う色の画像に置き換えて、onMouseOutで元の色の画像に戻してるだけだけどね。
　それと、大きめの集合写真の顔の辺りにマウスを持ってくると、人名を吹き出しで表示するようにしてみた。どうしたかというと、BubbleToolTipsと<area>タグを使ってみた。BubbleToolTipsは簡単に風船状の吹き出しをつけてくれるスクリプト。基本的にJavaScriptで書いてある。だけど、今回の用途にはちょっと改造が必要だった。それは<area>タグに対して作用するようにしたかったから。

cgiとutf8とphpとjs

（追記）2017/6に，FreeBSD で fine-uploader を使ってみた（その1）というのを書いた。 そこでは fine-uploader という JavaScript のライブラリを使ったファイルのアップローダーについて書いている。 Uber Uploader はすでに古く更新されていないので，fine-uploader など新しいアップロードライブラリを使うことをお薦めする。

---

（追記）2011/8時点での Uber-Uploader の最新版である Uber-Uploader 6.8.2 についてはUber-Uploader 6.8.2 の使い方（その1）で述べているので，参考にしてみて欲しい。

---

最近、同窓会に出席して同窓会のwebを担当することになった。とりあえず簡単に、と思って作り出したが、これまでいくつか作ってきたwebで培った技術を使いたくなってしまった。とりあえずはcgiを使ってメニューなど並べてみたりした。当初、JISコードで作ってみたが、最近の趨勢としてはUTF-8で作るようになりつつあるみたいなので、途中でページを全てUTF-8にしてみた。FreeBDS上に作っているのだが、最近はnkf -wでUTF-8にしてくれるようになっていた。いつのまに...
　さらに、そこにBBS（掲示板）を載せてみた。一から作るのはめんどくさいので、世の中に落ちてるcgiのソフトを拾ってきて，載せておいた。一発で動くかと思ったが，これが意外と手間取った。トラブった原因としては，一つには文字コードの問題。当初JISコードでwebを作っていたので、JISコードにしてみたら，全角の「：」などが文字化けして実行時にひっかかかる。そこで仕方なくShift_JISにしたらうまくいった。これはUTF-8にするのはかなり手間なのでやめておいた。それと改行の問題。もともとwindows用に書かれているらしく，改行コードがunix用になってなかった。そのままだとこれがうまく働かない。仕方ないのでこれも改行コードを変更してみた。ここでもnkfが活躍した。というか、FreeBSD上で他の方法を思いつかなかっただけなのだが。nkf -dってすると改行コードがLFのみになるみたいやった。あと，cgiが実行可能となっている下に作業用のdirectoryを置いておいたが，そこにある画像ファイルが表示されなかった。どうやらcgi実行可能なdirectoryの下に置いてはいけないみたい。これはcgi実行directoryから出したらうまくいった。でもBBSってみんな使うのかなぁ？

るーにー

気分がすぐれないなぁ。なんか面白いことないかなぁ？そういえば昨日マンチェスターとガンバの試合をテレビでしてた。ちょっと気になるから見てしまった。どっちを応援してたかというと，どっちも。そりゃガンバにも意地を見せて欲しいと思ったが，相手が悪すぎるよなぁ。それにしても後半２－１になってからのマンチェスターの攻撃はすごかった。ガンバの守備は何してるの？って感じで翻弄されてた。基本的に運動量が違うのだろうか？でも早さが全然違ってたよなぁ。あれってやっぱり世界でもまれないと身につかないものなのかなぁ？でもマンチェスターもガンバに3点取られるってあかんよなぁ。ま，ガンバも頑張ったということでしょう。そういえばテレビではやたらロナウドロナウドって叫んでたけど，ロナウド一人でサッカーしてるわけじゃないのになぁ。一人だけすごくても簡単には勝てないのよねぇ，サッカーって。個人的にはルーニーのプレーが好きやなぁ。あの飛び出しと，ゴール前であわてずにゴールする感覚ってそこらにはいないよなぁ。あれぞフォワードって感じがするんやけど，どやろ？