< | >

セキュリティ対策、どこまでやるかの判断能力
  • (2013-09-17 17:41:20)
WindwsXPのサポートがもうすぐ切れる。サポートなきあとのXPは無法地帯へと化すのか?(2013/09/17)

怪情報


XPの脆弱情報が、現在、高値で闇取引されているというウワサが聞こえてくる。サポート終了を狙って大規模なアタックを企てる連中もいるとかなんとか。

本当の話かもしれないし、ソフトベンダーやPCメーカーが意図的に流している可能性も空想できる。

生産的でないセキュリティ対策


セキュリティ対策はいくら行っても非生産的な投資。収益が上向くわけでないが、かといってやらなければあっという間にビジネス自体が崩壊するリスクが増大する。

しかし、セキュリティ対策の病的な問題は「いくらやってもキリがない」という事実。いくらでもリソースの投下が可能で、しかも満足に至ることは永遠にない。精神衛生上、非健康的な問題だ。大企業のセキュリティ担当者には心を病んだ人もいるだろう。

セキュリティ対策の程度加減は経営センスか?


本気モードでやるととにかく湯水のようにリソース(労力・体力・時間・コスト)を消費するセキュリティ対策は無関心ではいられないが、・・・である。

セキュリティ担当者に求められるノウハウはセキュリティ対策の知識や情報の前に、やるべきか・やらざるべきか、やるならどこまでやるかを的確に判断できる能力やセンスではなかろうか。リスクの数量化と対策コストとの相関関連図を描けるかどうか。

こんへんは経営センスに属する部分と思われる。セキュリティ対策は情報感度を高く保ちつつ、最低限をベースとした対策が基本になるのではなかろうか。

ところで、XPサポート終了後のXP


「大規模アタック」というウワサがあるが、大規模アタックを企てる人々が仮に存在するとしたら、自分たちが不利になるようなウワサを流すわけがない。真の攻撃者は人知れず忍び寄るものだ。

買い換え需要で、書き入れ時のPCメーカーやMSさんが一番おいしい部分をいただき、この波でも残ったXPユーザーは中小企業や個人ユーザーだろうから、破壊工作を企てるハッカー達のターゲットとしてはおもしろみがない。

自分が考える範囲では散発的なネットバンクなどのアカウント乗っ取りやボットネットの構成マシンとして乗っ取るくらいしか思いつかない。大騒ぎするほどの混乱は来ないと予想している。






< | >

XPモードやXP・Win7のデュアルブートでやる?
  • (2013-09-17 17:28:38)
来年、WindowsXPのサポートが終了することから、セキュリティ上の理由で企業ではWin7やWin8への移行がラッシュ状態(2013/09/17)

大義名分はセキュリティ


その実、思惑と仕込みもあるはず。PC業界のトロール戦略の前ではわかっていても移行するしかない状況を作り出す業界の強力なマーケティングの勝利。政治的なリスク対策コストとも言える。最低でも業務用のPCは保険料として多少は支払うのも人類のしがらみ。

Win7への移行準備


XPを全廃しWin7へ移行することに。準備をはじめると、すぐに問題が出始めている。たいていは古いアプリケーションソフトがwin7に対応していないケース。

一部、Win7(32bit)はOKだが、Win7(64bit)に対応していないケースもある。まず64bitは現時点ですでにあきらめた。

Win7に対応していない古いアプリケーションソフトが、どれだけあるかリストアップ中で、アップデートなどで対応可能なものはアップデートする。

XPモードやXP・Win7のデュアルブートは現実的でない


移行できないアプリで捨てれないアプリはどうする?・・・Win7とXPのデュアルブートも手かもしれない。通常はWin7で使用して、必要なときだけXPで起動する。

考えただけではできそうだが、忙しいときに、いちいちOSのリブートなんかしている光景を想像すると、たぶん、やってられないという気持ちになる。

XPModeもありかと考えたが、昨日試した範囲では使えない機能だった。遅くてわかりにくくて細かな制限があって面倒。もう少し慣れたら使えるのかな?

昨日のテストの時点では毎日、この面倒でどんよりしたXPMを走らせるかと思うと、デュアルブートの方がまだしも気持ちがいいかもしれないと感じた。






< | >

ロリポップ、Wordpressのdbだけを移転
  • (2013-09-05 12:22:29)
ロリポップのWordpressは遅い。使っているうちにユーザー数が増えてくるのだろう。多くのサーバーで非常に遅くなる。そんなときは最新サーバーに乗り換えよう(2013/09/05)

MySQL5.6(SSD採用)に移行しよう



ロリポップでは2013年4月にSSDのMySQLがスタートしている。ありがたい。SSDにして劇的に効果を体験できるか、それはムリだろうが、少し速いかもしれない。

※(結論)速くなったとは思えない。間違って劇的に速くなると引越者ラッシュでクラッシュだから、速くならないようにロリポップさんも調整しているのかな?

バックアップの取り方



・phpMyAgminへログイン


・ターゲットdbのエクスポート
 (1)「詳細 - 可能なオプションを全て表示」をチェック

 (2)フォーマット特有のオプション: → 生成オプション → 追加コマンド →
 「DROP TABLE/VIEW/PROCEDURE/FUNCTION/EVENTコマンドの追加」をチェック

 (3)残りはすべてデフォルトでOK
 「エンコーディングへの変換:」もデフォルトの「なし」で

・ファイルで保存


新dbの作成とインポート



すべてデフォルトでインポート。下記のメッセージとともにエラー発生:

-------------------------------
--
-- データベース: `LAA0085○-wp`
--
CREATE DATABASE `LAA0085○-wp` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
MySQLのメッセージ: ドキュメント
#1044 - Access denied for user 'LAA0085○'@'210.172.144.67' to database 'LAA0085○-wp'

-------------------------------
※下記のようにコメントアウトで解決(MySQLのコメントアウトは「-- 」or「# 」。こんなんでいいのかな?)

# CREATE DATABASE `LAA0085○-wp` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
# USE `LAA0085○-wp`;


※2017/04/16 すべてデフォルトでインポートしようとしたら、エラー続出。今回はエラー箇所と思われるところをコメントアウトしても効果なし → どうやらインポートの時、左カラムの「information_schema」を選択していた。インポートしようとしているデータベースを選択してインポートのこと。




wp-config.phpの書き替え



wp-config.phpをWordpressのフォルダからダウンロードして、データベース名やユーザー名を書き替えてアップロードする。完了。移行作業自体、慣れると10分で終わる。



※2016年の記事 → (WordPress + MySQL)の引越







< | >

SDカードの復旧方法
  • (2013-08-13 17:51:08)
デジカメのSDカードは今時32Gくらいあるので、写真はだいたいSDカードに入れっぱなしになっている。そしてある日、読めなくなるというトラブルが過去数回。復旧できる場合もある(2013/08/13)

トラブルの原因は抜き差し?



SDカードをUSBカードリーダーにさして、それをPCにさす。PCへの抜き差しのとき、SDカードの入り方が中途半端だったりするとデータが損傷するようだ。

トラブル時の現象、「フォーマットしますか?」



今日のトラブルはデジカメに入れると「フォーマットしますか?」と来た。PCに入れても「フォーマットしますか?」と来たので、何かが壊れている。

Recuvaというリカバリーソフト



Recuvaというリカバリーソフトで見るとブートセクターが破壊されていることを推測させるメッセージ。この場合、Recuvaはどうしようもない。

「unable to read boot sector」

ZARというリカバリーソフト



こちらのソフトはブートセクターとは無関係に全データのスキャンをやってくる。

今日のトラブルではほぼすべての写真データをみつけ復旧してくれたように見えたが、実際はクラッシュしている画像も多く、結果的に30%程度は復旧できなかった。

とくに動画は10本ほど撮影していたが、全滅だった。

フォーマット後にRecuvaで再トライ



フォーマットしても画像データは残されているので、フォーマットしてブートセクター修復後のトライもありかも。

ZARとは違ったファイルを救済できたが、ZARの3分の1程度のファイルしか救済できなかった。

ZARとRecuvaを合わせると、少しだけ救済数が多かった。

なお、Recuvaも動画はいっさい復旧できなかった。






< | >

cblog、RSSの止め方
  • (2013-07-24 05:41:42)
PingもRSSもSEO的に効果があるが、RSSを利用して機械的コピーをするサイトに記事を持って行かれると訂正のしようがなくなるデメリットもある。

RSSの止め方:

(1)htmlテンプレート内に記述されているrssのURLを削除すればpingサーバーはRSSページを発見できなくなる可能性がある(ただし、不十分)
<link rel="alternate" type="application/rss+xml" title="RSS" href="http://www.tokyocafe.net/slog/?mode=rss" />

(2)index.php内の下記部分操作
if ($_GET['mode'] == rss)

(3)class\View.php内の下記部分操作
$this->tpl->setVariable('site_rss', SITE_URL . "?mode=rss");





search
layout
admin

[▲page top]