無事 Debian Wheezy 環境でも Iceweasel 29.0 が使えるようになりました。
2014年4月30日水曜日
Debian の Iceweasel も 29.0 へアップグレード
mozilla.debian.net に Debian 用の Firefox こと Iceweasel のアップグレードが到着していました。
無事 Debian Wheezy 環境でも Iceweasel 29.0 が使えるようになりました。
無事 Debian Wheezy 環境でも Iceweasel 29.0 が使えるようになりました。
ブラウザ Firefox 29.0 登場
新しい Firefox 29.0 が登場しました。
メールクライアントの Thunderbird と同じユーザーインターフェースとなっていました。
今までインターフェースと異なっていることから、ちょっと設定にちょっとまごついてしまいました（笑）。
個人的には、ブラウザとメーラーの統一感があってよい感じがします。読者さんはどう判断されますか？
メールクライアントの Thunderbird と同じユーザーインターフェースとなっていました。
今までインターフェースと異なっていることから、ちょっと設定にちょっとまごついてしまいました（笑）。
個人的には、ブラウザとメーラーの統一感があってよい感じがします。読者さんはどう判断されますか？
FreeBSD 9.2 に p5 (TCP) アップデート
FreeBSD 9.2 に p5 アップデートが到着していました。
どうも TCP 関連の脆弱性を改善した模様です。通信に関わる内容なので結構重要そうです。
早速 再ビルドを行っておきました。おそらくカーネルの再ビルドだけで大丈夫かと思いますが、私はいつものようにユーザーランドを含めて再ビルドを行いました。
# svn update /usr/src
Updating '/usr/src':
U /usr/src/UPDATING
U /usr/src/sys/conf/newvers.sh
U /usr/src/sys/netinet/tcp_reass.c
Updated to revision 265125.
どうも TCP 関連の脆弱性を改善した模様です。通信に関わる内容なので結構重要そうです。
20140430: p5 FreeBSD-SA-14:08.tcp
Fix TCP reassembly vulnerability. [SA-14:08]
早速 再ビルドを行っておきました。おそらくカーネルの再ビルドだけで大丈夫かと思いますが、私はいつものようにユーザーランドを含めて再ビルドを行いました。
# cd /usr/src
# make buildworld && make buildkernel KERNCONF=MYKERNEL
# make installkernel KERNCONF=MYKERNEL
# make installworld
# reboot
2014年4月27日日曜日
Debian Wheezy のカーネル・アップデート
久しぶりに Debian Wheezy のカーネルがアップデートされました。
その他 samba の更新や tzdata, gstreamer などの更新が行われました。
いつものことですが、今回もどのような改良・改善が行われたのかは不明です。
linux-image-3.2.0-4-686-pae-3.2.57-3
その他 samba の更新や tzdata, gstreamer などの更新が行われました。
いつものことですが、今回もどのような改良・改善が行われたのかは不明です。
2014年4月23日水曜日
Dynamic-DNS の老舗 Dyn の無料アカウント終了
ダイナミック DNS の老舗の Dyn （旧 dyndns）の無料アカウントが2014年5月7日（水）に終了してしまうようです。
各無料アカウント・ユーザへ有料アカウントへの移行を促すメールを発送しているようです。
我が家ではすでに no-ip の無料アカウントへ移行しているため、とりあえず問題はありません。もしもまだ Dyn の無料アカウントを利用している読者さんがいらっしゃいましたら注意をしてください。
しかしこのところ無料のメールサービスなど次々と廃止されているようです。やはり無料でサービスを継続することは難しいようです。私もそろそろダイナミック DNS のサービスも IP 電話の Asterisk で利用しているため、有料サービスへの移行を検討する時期になってきたように感じます。
各無料アカウント・ユーザへ有料アカウントへの移行を促すメールを発送しているようです。
我が家ではすでに no-ip の無料アカウントへ移行しているため、とりあえず問題はありません。もしもまだ Dyn の無料アカウントを利用している読者さんがいらっしゃいましたら注意をしてください。
しかしこのところ無料のメールサービスなど次々と廃止されているようです。やはり無料でサービスを継続することは難しいようです。私もそろそろダイナミック DNS のサービスも IP 電話の Asterisk で利用しているため、有料サービスへの移行を検討する時期になってきたように感じます。
Debian Wheezy に Icedove 24.4.0 到着
mozilla.debian.net の Icedove 17.0.10 を使い続けていました。何故かアップグレードが行われていませんでした。当然ずっと気になっていました。
ところが突然 Icedove 24.4.0 が到着しました！
いつものようにアップデート・マネージャでそのままアップグレードしました。
インストールされたファイルは次の二つでしたが、何故か日本語パックのバージョンが微妙に古いものでした。しかし日本語表示をはじめ、特に問題もなく動作しています。
ところが突然 Icedove 24.4.0 が到着しました！
いつものようにアップデート・マネージャでそのままアップグレードしました。
インストールされたファイルは次の二つでしたが、何故か日本語パックのバージョンが微妙に古いものでした。しかし日本語表示をはじめ、特に問題もなく動作しています。
icedove-24.4.0-1~dev7u1
icedove-l10n-ja-1:24.3.0-1~deb7u1
MSE による Windows XP 起動不良からの回復
2014年4月15日から Windows XP が起動しなくなってしまいました。いわゆる「ようこそ」の画面からログインをした後、そのままフリーズをしてしまうものです。フリーズと言ってもカーソルは動いており、完全なフリーズ状態ではありませんでした。ただその後は、キーを一切受け付けない状況で、電源ボタンの長押しによるパソコンの強制遮断しかありませんでした。
どうしたものかと思っていたところ、ネット上で Microsoft Security Essentials による Windows XP の起動不良があることを知りました。
参考 URL
サポート切れのWindows XP搭載PCが起動不能となる問題をMicrosoftが修正
http://gigazine.net/news/20140421-windows-xp-boot-problem-fixed/
どうも Microsoft Security Essentials（以下 MSE と表記）の問題のようで、アップデート（ Antimalware Engine 1.1.10502.0 ）をすれば問題を解決できるということでした。
しかし既に起動不良となっていて、セーフモードでも起動しない状況となっていました。
そこで Puppy Linux を使って、この MSE の起動を抑止して Windows XP を起動させてみました。
問題の Windows XP が起動しないパソコンへ Puppy Linux Precise-5.7.1 の CD を挿入して、通常起動させました。
左下にある sda1 （Windows の C ドライブ）をクリックして開きます。
そして次のディレクトリへ移動します。
ここにいくつかのファイルがありますが、四つある exe ファイルをリネームして MSE の起動を抑止させることとしました。.exe を .bak へ変更しました。本当はどれか一つをリネームすれば大丈夫だと思われますが、どれか解らないため、すべての実行ファイルを変更しておきました。
このリネームが終了したところで、Puppy Linux を終了して Windows XP を起動させます。
するとどうでしょう！ 無事 Windows XP が起動しました。
ここで先ほど Puppy Linux 上でリネームした実行ファイルの名前を元に戻しました。ここで MSE だけを起動させてアップデートを試みるべきでしたが、私は単純にアンインストールをして、再度インストールをしようとしました。
しかし MSE は、もう Windows XP へインストールすることができないようです！
もう殆ど使用することのなくなった Windows XP ですので、もう MSE なしで使用していこうと思っています。
読者さんは MSE のアンインストールをするのではなく、是非 MSE のアップデートを試みるようにしてください。おそらく MpCmdRun.exe を起動すれば MSE が起動すると思われますので、MSE の起動後にアップデートを試みてください。
どうしたものかと思っていたところ、ネット上で Microsoft Security Essentials による Windows XP の起動不良があることを知りました。
参考 URL
サポート切れのWindows XP搭載PCが起動不能となる問題をMicrosoftが修正
http://gigazine.net/news/20140421-windows-xp-boot-problem-fixed/
どうも Microsoft Security Essentials（以下 MSE と表記）の問題のようで、アップデート（ Antimalware Engine 1.1.10502.0 ）をすれば問題を解決できるということでした。
しかし既に起動不良となっていて、セーフモードでも起動しない状況となっていました。
そこで Puppy Linux を使って、この MSE の起動を抑止して Windows XP を起動させてみました。
問題の Windows XP が起動しないパソコンへ Puppy Linux Precise-5.7.1 の CD を挿入して、通常起動させました。
左下にある sda1 （Windows の C ドライブ）をクリックして開きます。
そして次のディレクトリへ移動します。
/mnt/sda1/Program Files/Microsoft Security Client/
ここにいくつかのファイルがありますが、四つある exe ファイルをリネームして MSE の起動を抑止させることとしました。.exe を .bak へ変更しました。本当はどれか一つをリネームすれば大丈夫だと思われますが、どれか解らないため、すべての実行ファイルを変更しておきました。
msseces.exe
MpCmdRun.exe
MsMpEng.exe
Setup.exe
このリネームが終了したところで、Puppy Linux を終了して Windows XP を起動させます。
するとどうでしょう！ 無事 Windows XP が起動しました。
ここで先ほど Puppy Linux 上でリネームした実行ファイルの名前を元に戻しました。ここで MSE だけを起動させてアップデートを試みるべきでしたが、私は単純にアンインストールをして、再度インストールをしようとしました。
しかし MSE は、もう Windows XP へインストールすることができないようです！
もう殆ど使用することのなくなった Windows XP ですので、もう MSE なしで使用していこうと思っています。
読者さんは MSE のアンインストールをするのではなく、是非 MSE のアップデートを試みるようにしてください。おそらく MpCmdRun.exe を起動すれば MSE が起動すると思われますので、MSE の起動後にアップデートを試みてください。
2014年4月18日金曜日
Debian Wheezy の OpenSSL が再びアップデート
先日 OpenSSL のアップデートしたばかりの Debian Wheezy ですが、再びアップデートが到着していました。
前回のアップデート（...+deb7u6）では、ソースコードの変更なしに heartbeat 機能を無効とするオプションを付加してビルドしただけのものだったようですが、今回はどのような対策が加えられたものなのでしょうか？ 詳細は不明です。
libssl1.0.0-1.0.01e-2+deb7u7
openssl-1.0.01e-2+deb7u7
前回のアップデート（...+deb7u6）では、ソースコードの変更なしに heartbeat 機能を無効とするオプションを付加してビルドしただけのものだったようですが、今回はどのような対策が加えられたものなのでしょうか？ 詳細は不明です。
ekiga.net が復旧？
数日前から何故か接続不可能となっていた VoIP(sip) サービスの ekiga.net が復旧していました。
公式ウェブサイトにも障害の情報がなかっただけに、どうしたものかと思っていました。自分自身のアカウントのパスワード変更などを急遽行なってみたり、いろいろと対応してしまいました。
滅多に使わない ekiga.net でしたが、使おうとしたときに限ってこんなことになるなんて！ おかげで一般回線を使っての通話となってしまいました（涙）。
公式ウェブサイトにも障害の情報がなかっただけに、どうしたものかと思っていました。自分自身のアカウントのパスワード変更などを急遽行なってみたり、いろいろと対応してしまいました。
滅多に使わない ekiga.net でしたが、使おうとしたときに限ってこんなことになるなんて！ おかげで一般回線を使っての通話となってしまいました（涙）。
2014年4月17日木曜日
FreeBSD php5-5.4.27_1 へアップデート
先日までインストールが停止されていた php5-5.4.27 ですが、ようやくアップデートが到着してインストールが出来るようになりました。
新しいバージョンは php5-5.4.27_1 です。
おそらく OpenSSL の Heartbleed 対策と思われます。
FreeBSD 9.2 で採用されている OpenSSL は、古いバージョンの 0.9.8 で、今回問題となった Heartbeet 機能を使用していないため、問題は発生しないということです。
何かよく解りませんが、これで OpenSSL 関連の騒動も収束してくれることを願っています。
新しいバージョンは php5-5.4.27_1 です。
おそらく OpenSSL の Heartbleed 対策と思われます。
FreeBSD 9.2 で採用されている OpenSSL は、古いバージョンの 0.9.8 で、今回問題となった Heartbeet 機能を使用していないため、問題は発生しないということです。
何かよく解りませんが、これで OpenSSL 関連の騒動も収束してくれることを願っています。
2014年4月13日日曜日
Puppy Linux Precise-571JP の OpenSSL を更新
OpenSSL の HeartBleed 問題に対応するために、対策済みの OpenSSL を Puppy Linux Precise-571JP へインストールしました。
下記の URL を参考にしました。
Puppy パッケージマネージャを使って更新しました。
Puppy パッケージマネージャを起動したあと、「パッケージマネージャの設定」で新しく「 ubuntu-precise-main 」にチェックマークをつけて「ただちに更新」のボタンを押して、リポジトリを最新状態にします。
そして Puppy パッケージマネージャの画面へ戻って、リポジトリを「 ubuntu-precise-main 」にラジオボタン（丸ボタン）を選択したあと、検索窓から「libssl」を検索します。
すると「libssl1.0.0_1.0.1」に緑色のチェックマークが入っていてインストール済みとなっていますが、これをクリックしてインストールを開始します。
上書きインストールが完了しましたらバージョンチェックをします。
仮想端末 urxvt 上から OpenSSL のバージョン確認コマンド（ビルド時刻の表示オプション付き）を実行します。
UTC 時間の2014年4月7日となっていましたら、インストール成功となります。今後新しい対策済みのバージョンが出てきましたら、上記のビルド時刻よりも新しいものとなります。
これで安心して SSL 通信ができそうです。
下記の URL を参考にしました。
OpenSSL の重大バグ（パピーリナックス日本語フォーラム）
http://sakurapup.browserloadofcoolness.com/viewtopic.php?t=2581
Puppy パッケージマネージャを使って更新しました。
Puppy パッケージマネージャを起動したあと、「パッケージマネージャの設定」で新しく「 ubuntu-precise-main 」にチェックマークをつけて「ただちに更新」のボタンを押して、リポジトリを最新状態にします。
そして Puppy パッケージマネージャの画面へ戻って、リポジトリを「 ubuntu-precise-main 」にラジオボタン（丸ボタン）を選択したあと、検索窓から「libssl」を検索します。
すると「libssl1.0.0_1.0.1」に緑色のチェックマークが入っていてインストール済みとなっていますが、これをクリックしてインストールを開始します。
上書きインストールが完了しましたらバージョンチェックをします。
仮想端末 urxvt 上から OpenSSL のバージョン確認コマンド（ビルド時刻の表示オプション付き）を実行します。
# openssl version -b
built on: Mon Apr 7 20:31:55 UTC 2014
UTC 時間の2014年4月7日となっていましたら、インストール成功となります。今後新しい対策済みのバージョンが出てきましたら、上記のビルド時刻よりも新しいものとなります。
これで安心して SSL 通信ができそうです。
FreeBSD php5-5.4.27 がインストール停止中か
（全面的に内容の記述を変更しました）
当初 OpenSSL の問題でインストールの停止が行われていると記述しておりましたが、インストールの停止の原因については不明です。
なお php5 が使用する OpenSSL は FreeBSD のシステム（ワールド）の中のものをそのまま使用しているようです。そのため phoinfo 情報を確認すると FreeBSD のバージョンと一緒でした。
当初 OpenSSL の問題でインストールの停止が行われていると記述しておりましたが、インストールの停止の原因については不明です。
なお php5 が使用する OpenSSL は FreeBSD のシステム（ワールド）の中のものをそのまま使用しているようです。そのため phoinfo 情報を確認すると FreeBSD のバージョンと一緒でした。
2014年4月12日土曜日
再び FreeBSD apache-2.2.27_2 へアップデート
先日アップデートしたばかりの apache 2.2.27 ですが、再びアップデートが ports へ到着しました。今回は 2.2.27_1 から 2.2.27_2 となりました。
いつものことながら、どんなアップデートがあったのか不明なまま portupgrade での更新です。とりあえず我が家で httpd は動いています。
いつものことながら、どんなアップデートがあったのか不明なまま portupgrade での更新です。とりあえず我が家で httpd は動いています。
2014年4月11日金曜日
fetchmail で受信エラー
FreeBSD で稼働中の我が家のサーバでメールの受信エラーが発生しました。
新しいメールが受信できなくなってしまいました。
fetchmail を使って各プロバイダのメールサーバからメールを受信しているのですが、この受信をして imap サーバへメールの配送ができなくなっているようです。
/var/log/maillog を調べてみると、こんな感じです！ どうも迷惑メールが問題を起こしているようです。
そこで手動で fetchmail を起動させてみました。
どうも sendmail が名前の解決ができないことによる配送エラーを発生しているようです。
ネット上を「sendmail does not resolve」で検索してみると、名前の解決ができないメールも配送してしまう設定がありましたので、これを設定してみることとしました。
設定するのは sendmail 本体の設定ファイル（freebsd.mc、freebsd.submit.mc）ではなく、本ホスト固有の設定ファイルの方です。
ここへ上記の「 FEATURE(`accept_unresolvable_domains') 」を追記します。
私の場合、SMART_HOST の設定をしているので、この直後の部分へ挿入しました。
後は設定を反映させます。（make で作業をします。）
これで再度 fetchmail を手動で動作させたところ、受信エラーとなっていたメールも無事受信と配送をしてくれました。
このあと、再度設定を元に戻しました。再び受信エラーが発生するようでしたら、恒久的に設定変更の必要を考えたいと思っています。
新しいメールが受信できなくなってしまいました。
fetchmail を使って各プロバイダのメールサーバからメールを受信しているのですが、この受信をして imap サーバへメールの配送ができなくなっているようです。
/var/log/maillog を調べてみると、こんな感じです！ どうも迷惑メールが問題を起こしているようです。
Apr 11 13:55:01 freebsd-server sm-mta[26067]: s3B4s14c026067: from=, size=3035, class=0, nrcpts=0, bodytype=7BIT, proto=ESMTP, daemon=IPv4, relay=localhost [127.0.0.1]
そこで手動で fetchmail を起動させてみました。
fetchmail: SMTP error: 451 4.1.8 Domain of sender address sboupda+err＊＊＊＊@fjsdgs.hiuoh.biz does not resolve
reading message ＊＊＊＊@localhost:1 of 82 (3035 octets) not flushed
どうも sendmail が名前の解決ができないことによる配送エラーを発生しているようです。
ネット上を「sendmail does not resolve」で検索してみると、名前の解決ができないメールも配送してしまう設定がありましたので、これを設定してみることとしました。
FEATURE(`accept_unresolvable_domains')dnl
設定するのは sendmail 本体の設定ファイル（freebsd.mc、freebsd.submit.mc）ではなく、本ホスト固有の設定ファイルの方です。
/etc/mail/"ホスト名".mc
ここへ上記の「 FEATURE(`accept_unresolvable_domains') 」を追記します。
私の場合、SMART_HOST の設定をしているので、この直後の部分へ挿入しました。
後は設定を反映させます。（make で作業をします。）
# cd /etc/mail
# make
# make install
# make restart
これで再度 fetchmail を手動で動作させたところ、受信エラーとなっていたメールも無事受信と配送をしてくれました。
このあと、再度設定を元に戻しました。再び受信エラーが発生するようでしたら、恒久的に設定変更の必要を考えたいと思っています。
2014年4月10日木曜日
FreeBSD apache 2.2.27_1 へアップデート
昨日 openssl 関係のアップデート（heartbleed 対策）が FreeBSD をはじめ、各 linux ディストリビューションへ届きました。その関係なのでしょうか？ 今日は、FreeBSD の apache 2.2.27 のアップデートとなる 2.2.27_1 が到着していました。ssl 関連の部分でも更新があったのでしょうか。更新内容については不明です（笑）。
いつものように portupgrade で更新をかけておきました。
とりあえず我が家での動作は問題ないようです。
いつものように portupgrade で更新をかけておきました。
とりあえず我が家での動作は問題ないようです。
2014年4月9日水曜日
Debian Wheezy も openssl のアップデート
Debian Wheezy も openssl-1.0.0-1.0.1e-2+deb7u6 へアップデートしました。
なぜか一緒に openssh-server や openssh-client , openssh が更新されました。
これで Debian も FreeBSD も SSL 通信の対策が出来たようです。
なぜか一緒に openssh-server や openssh-client , openssh が更新されました。
これで Debian も FreeBSD も SSL 通信の対策が出来たようです。
FreeBSD 9.2 p4 アップデート（openssl）
FreeBSD 9.2 に p4 アップデートが到着しました。
アップデートの内容を /usr/src/UPDATING で確認しました。
やはり openssl への攻撃に対する対応のようでした。
ここにある「 ECDSA Cache Side-channel Attack in OpenSSL. 」の言葉は初めてみました。
Ebury の攻撃方法なのでしょうか。（ openssh と openssl を勘違いしていました。 Heartbleed 対策だそうです。）
この 「 ECDSA Cache Side-channel Attack in OpenSSL. 」の他にも NFS サーバのデッドロック現象の対策も行われたようです。我が家では NFS は使用していないので、このデッドロック現象については不明です。
FreeBSD の公式ウェブサイトでは本アップデートについての記述はまだありませんが、近くあるものと思われます。そこで最小限度のアップデートの方法が案内されると思います。
私はいつものようにワールドとカーネルを全部再ビルドすることで対応しました。
# svn update /usr/src
Updating '/usr/src':
U /usr/src/UPDATING
U /usr/src/sys/conf/newvers.sh
U /usr/src/sys/fs/nfsserver/nfs_nfsdserv.c
U /usr/src/crypto/openssl/crypto/ec/ec2_mult.c
U /usr/src/crypto/openssl/crypto/bn/bn_lib.c
U /usr/src/crypto/openssl/crypto/bn/bn.h
リビジョン 264285 に更新しました。
アップデートの内容を /usr/src/UPDATING で確認しました。
20140408: p4 FreeBSD-SA-14:05.nfsserver
FreeBSD-SA-14:06.openssl
Fix deadlock in the NFS server. [SA-14:05]
Fix for ECDSA Cache Side-channel Attack in OpenSSL. [SA-14:06]
やはり openssl への攻撃に対する対応のようでした。
ここにある「 ECDSA Cache Side-channel Attack in OpenSSL. 」の言葉は初めてみました。
この 「 ECDSA Cache Side-channel Attack in OpenSSL. 」の他にも NFS サーバのデッドロック現象の対策も行われたようです。我が家では NFS は使用していないので、このデッドロック現象については不明です。
FreeBSD の公式ウェブサイトでは本アップデートについての記述はまだありませんが、近くあるものと思われます。そこで最小限度のアップデートの方法が案内されると思います。
私はいつものようにワールドとカーネルを全部再ビルドすることで対応しました。
2014年4月8日火曜日
FreeBSD bash-4.3.8 へアップグレード
FreeBSD の ports に bash-4.3.0_1 から bash-4.3.8 へのアップグレードが到着していました。
我が家の FreeBSD マシンでは tcsh を使っていますが、何かの ports で関連して自動的にインストールされたものでした。
しかしすぐに関連した ports もすぐに判明しました。数日前にアップデートが到着していた qpopper-4.1.0_2 がインストールエラーで停止していたのですが、これが bash のアップデートに伴って無事インストールも完了しました。メデタシでした。
我が家の FreeBSD マシンでは tcsh を使っていますが、何かの ports で関連して自動的にインストールされたものでした。
しかしすぐに関連した ports もすぐに判明しました。数日前にアップデートが到着していた qpopper-4.1.0_2 がインストールエラーで停止していたのですが、これが bash のアップデートに伴って無事インストールも完了しました。メデタシでした。
2014年4月6日日曜日
Debian Wheezy の Openssh のアップデート
あの話題となっていた openssh を使って侵入すると言われる rootkit の ebury 対策なのでしょうか？ Debian Wheezy に openssh の本体 並びに サーバ、クライアントのソフトウェアのアップデートが到着していました。
今回のアップデートは ssh ポートを公開しているサーバなどでは確実に更新しておく必要がありそうです。
なお公開されている ssh ログインについては、チャレンジレスポンス方式のログインなどを禁止して、公開鍵方式でのログイン方式にすることが安全性を高めるとされています。
1. 公開鍵でログイン
ログインユーザーの公開鍵をサーバ・マシンの ~/.ssh/authorized_keys2 へ追加する。
公開鍵の作り方は ssh-keygen で検索して調べてください。なお鍵の種類は DSA ではなく RSA がお奨めです。
2.チャレンジレスポンス認証を抑制
初期値 yes → no
参考URL
Debian Bug report logs - #742513
If server offers certificate, doesn't fall back to checking SSHFP records (CVE-2014-2653)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513
Ebury SSH Rootkit - Frequently Asked Questions
https://www.cert-bund.de/ebury-faq
openssh-client-1:6.0p1-4+deb7u1
openssh-server-1:6.0p1-4+deb7u1
ssh-1:6.0p1-4+deb7u1
Debian Squeeze の場合
openssh-client-1:5.5p1-6+squeeze5
openssh-server-1:5.5p1-6+squeeze5
ssh-1:5.5p1-6+squeeze5
今回のアップデートは ssh ポートを公開しているサーバなどでは確実に更新しておく必要がありそうです。
なお公開されている ssh ログインについては、チャレンジレスポンス方式のログインなどを禁止して、公開鍵方式でのログイン方式にすることが安全性を高めるとされています。
1. 公開鍵でログイン
ログインユーザーの公開鍵をサーバ・マシンの ~/.ssh/authorized_keys2 へ追加する。
公開鍵の作り方は ssh-keygen で検索して調べてください。なお鍵の種類は DSA ではなく RSA がお奨めです。
sFTP などで公開鍵 id_dsa.pub をサーバ・マシンへ転送する。
$ cat id_dsa.pub >> ~/.ssh/authorized_keys2
2.チャレンジレスポンス認証を抑制
初期値 yes → no
/etc/ssh/sshd_config
# Change to no to disable PAM authentication
# ChallengeResponseAuthentication yes
↓
ChallengeResponseAuthentication no
3. root でのログインの抑制
初期値で no となっているはずですが、yes の場合には変更
/etc/ssh/sshd_config4.対策終了後に sshd を再起動
# PermitRootLogin yes
↓
PermitRootLogin no
# /etc/init.d/sshd restart以上で $ ssh サーバURL だけで、パスワードの入力問い合わせがなく、自動的にサーバへログインできるはずです。
参考URL
Debian Bug report logs - #742513
If server offers certificate, doesn't fall back to checking SSHFP records (CVE-2014-2653)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513
Ebury SSH Rootkit - Frequently Asked Questions
https://www.cert-bund.de/ebury-faq
2014年4月5日土曜日
FreeBSD php5-5.4.27 へアップグレード
このところ FreeBSD の php5 の話題続きですが、本日も php5 のアップグレードの内容です。
ports へ php5 の新しいアップグレードが到着しました。php5-5.4.26 から php5-5.4.27 への更新です。これに伴って mod_php5 も mod_php5-5.4.26,1 から mod_php5-5.4.27,1 へ更新となりました。
我が家では、とりあえず問題なく動作しているようです。
ports へ php5 の新しいアップグレードが到着しました。php5-5.4.26 から php5-5.4.27 への更新です。これに伴って mod_php5 も mod_php5-5.4.26,1 から mod_php5-5.4.27,1 へ更新となりました。
我が家では、とりあえず問題なく動作しているようです。
 |
| php5-5.4.27 のビルドオプションの設定画面 |
 |
| mod_php5-5.4.27,1 のビルドオプションの設定画面 |
2014年4月4日金曜日
早速 mod_php5 のアップデート
FreeBSD の ports へ mod_php5 （apache 用の php5 モジュール）のアップデート（mod_php5-5.4.26,1）が到着しました。
先日なんだかんだで新規にインストールした ports ですが、もう更新でした。
何故か php5 の本体の更新はありませんでした。 いったい何か変わったのでしょうか？
とりあえず portupgrade で更新してみましたが、問題なく動作しているようです。
先日なんだかんだで新規にインストールした ports ですが、もう更新でした。
何故か php5 の本体の更新はありませんでした。 いったい何か変わったのでしょうか？
とりあえず portupgrade で更新してみましたが、問題なく動作しているようです。
2014年4月2日水曜日
FreeBSD www/mod_php5 をインストール
perl5 のアップデートを終了した後、関連する ports も更新したところ、php5 が動かなくなってしまいました。
php5 本体のバージョン確認をしたところでエラーとなるため、かなり重症でした。
この問題は php.ini の見直しで対応可能でした。 「 allow_call_time_pass_reference 」の項目をコメントアウト（; を行頭に追加）すれば動作するようになりました。
しかし今度はウェブサーバの apache での動作が異常となってしまいました。
バージョン情報などを確認する info.php をブラウザから表示させようとすると、info.php をダウンロードするようになってしまいました。
念の為に httpd.conf の確認をしましたが問題無さそうでした。そこで apache 用のモジュール libphp5.so を探したところ、なんと！存在していませんでした。
どうも今回のリビルドで消失してしまったようです。そこで php5-5.4.26 のビルドオプションを確認してしました。
すると apache 用のモジュールを作るオプションがありませんでした（涙）。
いったいどうしたものかとネット上を検索してみると、apache 用のモジュールを作る ports (www/mod_php5) が存在していることを知りました。そこでこの ports をインストールしてみました。
インストールが完了した後、apache を再起動させました。
これで apache 上で php5 が動作するようになりました。
しかし不思議なのはどうして以前のビルドでちゃんと apache 用のモジュールが作られたのか？でした。 もしかして以前からバージョンで使用していたオプションがそのまま引き継がれていてモジュールを勝手に作ったのでしょうか？ とにかく不思議な現象です。
php5 本体のバージョン確認をしたところでエラーとなるため、かなり重症でした。
$ php -v
Fatal error: Directive 'allow_call_time_pass_reference' is no longer available in PHP in Unknown on line 0
この問題は php.ini の見直しで対応可能でした。 「 allow_call_time_pass_reference 」の項目をコメントアウト（; を行頭に追加）すれば動作するようになりました。
;allow_call_time_pass_reference = On
しかし今度はウェブサーバの apache での動作が異常となってしまいました。
バージョン情報などを確認する info.php をブラウザから表示させようとすると、info.php をダウンロードするようになってしまいました。
念の為に httpd.conf の確認をしましたが問題無さそうでした。そこで apache 用のモジュール libphp5.so を探したところ、なんと！存在していませんでした。
$ ls /usr/local/libexec/apache22/libphp5.so
ls: /usr/local/libexec/apache22/libphp5.so: そのようなファイルまたはディレクトリはありません
どうも今回のリビルドで消失してしまったようです。そこで php5-5.4.26 のビルドオプションを確認してしました。
すると apache 用のモジュールを作るオプションがありませんでした（涙）。
いったいどうしたものかとネット上を検索してみると、apache 用のモジュールを作る ports (www/mod_php5) が存在していることを知りました。そこでこの ports をインストールしてみました。
# portinstall www/mod_php5
インストールが完了した後、apache を再起動させました。
# apchectl restart
これで apache 上で php5 が動作するようになりました。
しかし不思議なのはどうして以前のビルドでちゃんと apache 用のモジュールが作られたのか？でした。 もしかして以前からバージョンで使用していたオプションがそのまま引き継がれていてモジュールを勝手に作ったのでしょうか？ とにかく不思議な現象です。
FreeBSD perl5-5.16.3_9 へアップデート
FreeBSD の ports へ perl5 のアップデートが到着していました。
perl5-5.16.3_8 から perl5-5.16.3_9 へのアップデートです。
いつものように portupgrade で更新しておきました。 単純に perl5 の本体だけの更新だけで問題ないと思われますが、念の為に関連する ports も更新しておきました。
perl5-5.16.3_8 から perl5-5.16.3_9 へのアップデートです。
いつものように portupgrade で更新しておきました。 単純に perl5 の本体だけの更新だけで問題ないと思われますが、念の為に関連する ports も更新しておきました。
# portupgrade -fr perl5
2014年4月1日火曜日
FreeBSD のビルドオプション WITHOUT_X11 の変更
FreeBSD のビルドオプションとして /etc/make.conf へ「 WITHOUT_X11 」を設定していました。これはもちろんサーバとして使用しているマシンなので、X 関係が全く不要であったためです。
しかし本日 cups の新しいバージョン 1.7.1 をインストールするために、関連する ports の cairo を X11 対応のオプションで再ビルドしなければならなくなり、そこで以下のようなビルドオプションの設定の見直しを求められたため、「 OPTIONS_UNSET=X11 」へと変更しました。
上記の「 OPTIONS_UNSET=X11 」へのビルドオプションの変更によって、上記の警告は表示されなくなりました。このところ FreeBSD のビルドオプションの見直しが多くなって来ましたが、本格的にビルドオプションの見直しが必要となってきているように感じました。
しかし本日 cups の新しいバージョン 1.7.1 をインストールするために、関連する ports の cairo を X11 対応のオプションで再ビルドしなければならなくなり、そこで以下のようなビルドオプションの設定の見直しを求められたため、「 OPTIONS_UNSET=X11 」へと変更しました。
You are using the following deprecated options: WITHOUT_X11
If you added them on the command line, you should replace them by
WITH="" WITHOUT="X11"
If they are global options set in your make.conf, you should replace them with:
OPTIONS_UNSET=X11
If they are local to this port, you should use:
graphics_cairo_UNSET=X11
上記の「 OPTIONS_UNSET=X11 」へのビルドオプションの変更によって、上記の警告は表示されなくなりました。このところ FreeBSD のビルドオプションの見直しが多くなって来ましたが、本格的にビルドオプションの見直しが必要となってきているように感じました。