|
|
対策もなにも、この内容が事実ならば、「ハァ？」ということ。対応レベル＝品質レベルととらえると、こういうのは使えませんね。内部のエンジニアの品質も悪いんでしょう。きっと。まともならもっとまともな対応策などの提案が有るはずです。そもそも、サイトがねらわれれば、IPアドレスなんて変えるのは全く意味がありません。DNSからひいて探してくるでしょうし、サイトがねらわれているのであれば、名前を変更しても、ドメイン名を変更しても、見つけてくるでしょう。所詮いたちごっこなのです。
実際に出来る対応は事業者側での対応。あとは、利用者側としては、可能であれば上位回線が埋まるような攻撃を受けたときのことを想定して、裏口(物理的に違う網)を用意するということ。いわゆるフレッツや専用線などを使ったVPNや広域イーサーなども該当しますし、よくある構成です(大規模になればなるほど)。実際に私がIRCサーバを運用していたときも、syn flood, udp floodなど日常で届き、サービス側の回線真っ黒けになることも。なので、攻撃の種類にもよりますが、物理的に分離、インターフェースも分ける(vlanなんか、役に立ちません)というのが一般的。クラウドサービスやVPSなど仮想化向けサービスになった時点で、ネットワークは共通化されていたりすることもある為、網内(バックボーン〜エッジ含む)に入ってしまったら他のも影響うけるから、借りているサーバー以前に周りの巻き沿いなども有るため、事業者としては対応しなければならなくなるでしょう。また、事業者の立場としては正直面倒でもあるし、対応に迫られると、正直出て行ってほしいというのはあるけど、そうなった時点で事業者がは技術的、コスト的に見捨てたということですね。まあ、バックボーン全体を上回るトラフィックの流入はどうしようも無かったり
*1
しますが、対応可能なトラフィックの範囲内であれば、入り口でフィルタなどを行う方法はあるでしょう。
現実的にこういうのは、いたちごっこなので手での対応は難しいところはあるでしょうけど、多くの攻撃のケースの場合、srcがバラバラ
*2
ということは、そこまで多くないです。時間的にも長時間続くことは余りありません。とはいっても、そうとも限りませんが傾向的に、という話しです。IRCを運用していたときは、長時間続く攻撃が多かったですが…。Webサイトの場合比較的快犯などのことも多く、長時間続くことは珍しいと思います。
*3
網内からの攻撃トラフィックで帯域が埋まるようなケースは、事業者からすれば管理管轄内なので、不正パケットを出しているユーザのトラフィックの締め出しでも良いでしょう。まあ、正直面倒な事には違いないですけどね。にしても、ドメイン変更という事を言い出したGMOクラウドのお客様対応した担当者の低脳な対応には、ちょっとあきれる物が有りますね。まだ、DNSが向いている限り、サーバを落としていても攻撃は続けられ、syn flood / udp floodされている場合は、サーバが生きているか死んでいるかは関係有りません。また、ppsが多い場合、幾らサーバの性能を上げても、CPUやメモリの数を増やしても、NICが先に当たります(10Gだったらずいぶん緩和されますけど)。また、カーネルが一旦受けるわけで、そこのコストはバカになりませんから、同一ホスト上に有るvmはパフォーマンス面で影響を受けるでしょう。また、テーブルが埋まる恐れもあります。
話しを戻して、攻撃を受けたことが不正アクセス若しくはウィルスの感染と決めているのも明らかにおかしい話しです。明らかに、連携が出来ていない、フロントのお客様対応の判断が非常に残念で、適切にエスカレーションをされているようには思えない感じが残念でした。
ということで、Twitterでも話題になっていますが、
そのため、GMOクラウドにおいては「DDoS攻撃は、ドメイン名を変更すれば解決できる可能性が高い」といった対策の提案があったりしました。
とあることから、GMOクラウドでは、gmocloud.com 宛のドメインにDDoSがきたら、ドメイン名の変更をして、解決するようです。これが、共有サーバで、サブドメインを払い出しているケースはどうするんでしょうか。この理屈なら、全部変更なんでしょうね…。てことで、みんな、F5アタックしちゃえば、変更するんですかね...
さらに、記事を読んでいると...
GMO「こちらの第三者というのは意図的でなくとも該当します。現状、お客さまのドメインがDDoS攻撃を受けれる状態になっておりますので、お客さまが 無自覚 でDDoSを誰かに行わせているという解釈になります。」
私「上の方に代わっていただけますでしょうか?」
斜め上を行く回答。某社のどこぞの回答みたいで楽しい。私が見たのはもっと斜め上だったので、あきれてしまったが(笑
ということで、GMOクラウドを使おうとは思わなくなりました(-人-)ﾅｰﾑｰ...
事実だとするならば、事業者として本当にこれでいいのですか？> 青山さん
最近ふと思うのは、トップが元エンジニアで、且つ有る程度のプライド、ポリシーを持っていて曲げれないところは曲げれないという思想を持っていないと、今回みたいに、現場も含めていい加減な事に感じになってしまうような気がします。某社ではモロ当てはまりましたし。
*1:
ここは、Transitの上位と相談、対応できる関係を築いておくこと、Community等を使って、トラフィックの制御、広告の範囲を制限するなどをして、完全ではないものの、被害を最小限にすることも出来ますね。地道な作業ですが正直私はやりたくないです…w。ここは、事業者としての力量でしょう。いくつか完全ではないけど、出来る対応方法はありますね。ていうか、そんな作業に張り付きたくねぇから、出て行ってくれと言いたいのもわかるけどねw。まあ、即座に判断出来る人は熟練者ぐらいでしょうか。でも、そういう人ほど引きこもりたいものですw
*2:
prefixなど、比較的固まったブロックの範囲内が複数程度
*3:
私が見ている環境と違うケースも十分にありうるけど、一つの意見として。
＊
[Linux] Debian "Wheezy" 7.5 Kernel再構築
先日新しいVMware ESXiの新規構築に、生活環境を移そうとし、ついでにメンテナンスをしようとたら、Kernel Panicしてしまい、起動しないいことが判明したので、再構築していた。理由は、完全なオペミス。経緯を説明すると、昨年のいつか忘れた頃に、Debian 6 の時に、apt-get dist-upgrade としたまま放置し再起動せず半年以上。その後、パッケージをインストールしたりしていたら、どうやら環境が壊れてしまい、長期間再起動していなかったこともあり、自動的にfsckが走るようになっていたり、initrdが更新されていないなど、いろんなところで不具合が出ていた。そういうわけで、Debian 7.5 へシステムの再構築。実はDebian5の頃からアップデートをして使っていたんだよなぁと。ずいぶん長い間お世話になった旧環境。幸いにも、移行前のvmは電源を落としていないので、まだ、起動した状態なので、データはそこからrsyncすればよいので、比較的楽。
つーわけで、インストール後、source address routing がちゃんと動かない。ip rule が旨く入らない・・・なんでだ、バグかしら？とおもい、調べていて、以前動いていたスクリプトでもだめで、defaultに向かってパケットが流れてしまう、なぜだということで、バージョンが変わったことによりなにか変わったのかと検証するために、kernel を再構築していた。最終的には、スクリプトを移植する際に、IPアドレスの打ち間違えが原因だったのだが...
理解するために、色々と改めて良い勉強になったので、結果ヨシとしよう。
以前、debian でmake-kpkg でカーネルの再構築をしていたのと少し方法が変わっているので、記しておく。
新システムでカーネルをビルドしたくないので、ビルド用のマシンを新規、最小インストールを行い、ビルド環境としておく。今回、fakerootを使っていないので、そこはご了承を。
ビルド環境の構築は簡単で、コマンド一発でほとんど必要な物が入る。
# apt-get install kernel-package libncurses-dev
libncurses-dev は make menuconfig をつかって、CUI方式でカーネルパラメータを変更する場合に必要だ。Suggested(提案リスト)には入っているだけで、インストールはされないので、一緒にインストールをしておこう。
実行したらこれだけのパッケージが入る。
# apt-get install kernel-package libncurses-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
autopoint binutils build-essential cpp cpp-4.7 dpkg-dev fakeroot g++ g++-4.7 gcc gcc-4.7 gettext
git git-man intltool-debian libalgorithm-diff-perl libalgorithm-diff-xs-perl
libalgorithm-merge-perl libc-dev-bin libc6-dev libcroco3 libcurl3-gnutls libdpkg-perl
liberror-perl libffi5 libfile-fcntllock-perl libgettextpo0 libglib2.0-0 libglib2.0-data libgmp10
libgomp1 libitm1 libmail-sendmail-perl libmpc2 libmpfr4 libquadmath0 librtmp0 libssh2-1
libstdc++6-4.7-dev libsys-hostname-long-perl libtimedate-perl libunistring0 linux-libc-dev make
manpages-dev po-debconf rsync shared-mime-info libncurses-dev
Suggested packages:
binutils-doc cpp-doc gcc-4.7-locales debian-keyring g++-multilib g++-4.7-multilib gcc-4.7-doc
libstdc++6-4.7-dbg gcc-multilib autoconf automake1.9 libtool flex bison gdb gcc-doc
gcc-4.7-multilib libmudflap0-4.7-dev libgcc1-dbg libgomp1-dbg libitm1-dbg libquadmath0-dbg
libmudflap0-dbg libcloog-ppl0 libppl-c2 libppl7 binutils-gold gettext-doc git-daemon-run
git-daemon-sysvinit git-doc git-el git-arch git-cvs git-svn git-email git-gui gitk gitweb
linux-source kernel-source docbook-utils xmlto grub grub2 jfsutils mcelog
oprofile pcmciautils ppp reiserfsprogs squashfs-tools xfsprogs quota btrfs-tools glibc-doc
libstdc++6-4.7-doc make-doc libmail-box-perl
The following NEW packages will be installed:
autopoint binutils build-essential cpp cpp-4.7 dpkg-dev fakeroot g++ g++-4.7 gcc gcc-4.7 gettext
git git-man intltool-debian kernel-package libalgorithm-diff-perl libalgorithm-diff-xs-perl
libalgorithm-merge-perl libc-dev-bin libc6-dev libcroco3 libcurl3-gnutls libdpkg-perl
liberror-perl libffi5 libfile-fcntllock-perl libgettextpo0 libglib2.0-0 libglib2.0-data libgmp10
libgomp1 libitm1 libmail-sendmail-perl libmpc2 libmpfr4 libquadmath0 librtmp0 libssh2-1
libstdc++6-4.7-dev libsys-hostname-long-perl libtimedate-perl libunistring0 linux-libc-dev make
manpages-dev po-debconf rsync shared-mime-info libncurses-dev
0 upgraded, 49 newly installed, 0 to remove and 0 not upgraded.
Need to get 54.6 MB of archives.
After this operation, 142 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
あとは、ビルドしたいカーネルを
http://www.kernel.org/よりダウンロードをして、カーネルをカスタマイズする。
今回は、3.2系の最新版(3.2.59)を持ってくることにして、ビルドした。
Debian 7.5 の初期状態でインストールされている、3.2.0-4-amd64 のカーネルコンフィグは、下記の場所に有るのでこれをベースに必要箇所だけ書き換えると良いで。不要なのは外してもイイですし、必要なのは追加すればよいのです。
/boot/config-3.2.0-4-amd64
てことで、今回、root 環境で作業しちゃうので、ざくざくとコマンドメモを。
# wget wget -4 -c https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.59.tar.xz
# xzcat linux-3.2.59.tar.xz | tar xvf -
# cp /boot/config-3.2.0-4-amd64 /root/linux-3.2.59/.config
今のカーネルは、7zで圧縮されているんですね…。あと、後で教えてもらったのは、GNU tarでも簡単に展開できるよと。BSD tarでは楽なのは知っていたけど、ここまで良くなっているとは…時代を感じます。
ex)
# tar xvf linux-3.2.59.tar.xz
あとは、差分の変更箇所の確認。結構面倒です。
# cd linux-3.2.59
# make oldconfig
面倒であればマージせずすっ飛ばして、
# make menuconfig
これでもいいかもしれません。
あとは、カーネルをビルドするだけ。私は今回VMwareの環境で、メモリを4GB、4Core割り当てたので、make opt に -j 8 としたかったので、変数に入れておきます。設定しないとCPU全然使えませんでした。かなり遊んでた…
# export CONCURRENCY_LEVEL=8
あとは、カーネルのビルド及びカーネルパッケージの作成です。
make-kpkg clean && make-kpkg --initrd --revision=2014.05.21.01 kernel-image kernel_headers
念のため、私の環境でどの程度時間がかかりか、timeをつけておいた。
結果こんなかんじ。
real 29m2.036s
user 66m40.958s
sys 8m4.190s
ビルド中、DL360G6 Xeon X5570 の環境では、電源の消費電力がずどーん！
通常時100弱W程度のものが、190Wまでふくれあがるというので驚きものですね。
参考に、CONCURRENCY_LEVEL の変数を定義した場合としなかった場合の様子でも。
未定義
10:46:10 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
10:46:11 all 20.60 0.00 5.03 0.00 0.00 0.00 0.00 0.00 74.37
10:46:11 0 15.15 0.00 5.05 0.00 0.00 0.00 0.00 0.00 79.80
10:46:11 1 1.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 98.00
10:46:11 2 49.49 0.00 9.09 0.00 0.00 0.00 0.00 0.00 41.41
10:46:11 3 17.00 0.00 4.00 0.00 0.00 0.00 0.00 0.00 79.00
CONCURRENCY_LEVEL=8
10:47:15 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
10:48:17 all 90.34 0.00 9.50 0.00 0.00 0.16 0.00 0.00 0.00
10:48:17 0 89.50 0.00 10.12 0.00 0.00 0.38 0.00 0.00 0.00
10:48:17 1 90.69 0.00 9.28 0.00 0.00 0.03 0.00 0.00 0.00
10:48:17 2 90.65 0.00 9.14 0.00 0.00 0.21 0.00 0.00 0.00
10:48:17 3 90.51 0.00 9.49 0.00 0.00 0.00 0.00 0.00 0.00
完全にCPUを使い切っているのがわかる。無駄が無くて良い。
さて、これでパッケージが出来たはずなので、一つ上のディレクトリへ移動し、パッケージが有るか確認しましょう。
# cd ..
# ls -ld linux*
drwxrwxr-x 25 root root 4096 May 21 12:12 linux-3.2.59
-rw-r--r-- 1 root root 65617552 May 18 23:34 linux-3.2.59.tar.xz
-rw-r--r-- 1 root root 7772480 May 21 12:13 linux-headers-3.2.59_2014.05.21.01_amd64.deb
-rw-r--r-- 1 root root 33947520 May 21 12:11 linux-image-3.2.59_2014.05.21.01_amd64.deb
こんな感じで出来ているはずなので、後は、パッケージのインストールでOK!
# dpkg -i linux-image-3.2.59_2014.05.21.01_amd64.deb linux-headers-3.2.59_2014.05.21.01_amd64.deb
後は再起動して様子を見ましょう。
＊
[SPAM] Google Comupute Engine: Google Cloud Platform と思われるところからspamが着た
こういうコメントスパムがこの日記に着た。基本的にこの日記のコメントは、POSTする際に、APNICからJPへ割当のされた空間からしか、書き込みが出来ず、それ以外のものについては、BASIC認証で、test / test と入力しないと、POST出来ないように設定している。そんななか、次のIPアドレスからコメントスパムがきたので、ちょっと晒す。
456789 8018 root 1400730515 機械式時計 機械式時計
http://xxxx/product/p1/index.html 8.35.201.45
機械式時計、それは主に認定されたスイスの天文台を介して行われますでの時計のデザインに
統合され..
IPアドレスは、8.35.201.45 で、このIPを調べたところ、
Google Comupute Engine: Google Cloud Platformということ。WHOISの情報では次のようになっている。
NetRange: 8.35.200.0 - 8.35.207.255
CIDR: 8.35.200.0/21
OriginAS:
NetName: LVLT-GOOGL-2-8-35-200
RegDate: 2012-06-12
Updated: 2012-06-12
Ref: http://whois.arin.net/rest/net/NET-8-35-200-0-1
OrgName: Google Inc.
OrgId: GOOGL-2
Comment: *** The IP addresses under this Org-ID are in use by Google Cloud customers ***
Comment: Please direct all abuse and legal complaints regarding these addresses to the
Comment: GC Abuse desk (google-cloud-compliance@google.com). Complaints sent to
なぜ、このspam botが引っかかったのかわからないが、アクセスログを見たときに、大量に引っかかったので前後の一部について切り出してみる。
8.35.201.53 - - [22/May/2014:12:48:15 +0900] "POST /diary/board.cgi HTTP/1.1" 401 1328
"http://tomocha.net/diary/board.cgi?act=write"
"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36 AppEngine-Google;
(+http://code.google.com/appengine; appid: s~dotaeryanyong)"
8.35.201.48 - - [22/May/2014:12:48:20 +0900] "POST /diary/board.cgi HTTP/1.1" 401 1328
"http://tomocha.net/diary/board.cgi?act=write"
8.35.201.52 - - [22/May/2014:12:48:32 +0900] "POST /diary/board.cgi HTTP/1.1" 401 1328
"http://tomocha.net/diary/board.cgi?act=write"
8.35.201.45 - test [22/May/2014:12:48:34 +0900] "POST /diary/board.cgi HTTP/1.1" 200 2328
"http://tomocha.net/diary/board.cgi?act=write"
URI以降はすべて同じだったので、割愛した。
明らかに、認証というトラップを通過して、コメントスパムを行っている。
とりあえず、初めて着たのでネタにしたが、Googleへabuseを送っておこう。
＊
[SPAM] 三井住友カードのフィッシング(そもそもここのクレカもってない)
特価コムに登録していたアドレスに新たなフィッシングメールが来た。
前回、
情報漏洩、流出したと書いたのは、昨年の12/25。指摘しても尚、通販などのサイトの閉鎖などは無く、継続していたが、翌年(今年2014年)の1/31にプレスリリースを出した。
今までは、スクエニなどのフィッシングが主だったが、今回はクレジットカードのvpassを奪い取ろうとするフィッシングメール。だんだんエスカレートしている。責任を取って特価コムはつぶれるべきだ。ろくな対応もしなかったためだ、こういう会社は害でしかない。
届いたメールのヘッダを含む全文
*1
は次の通り。
Return-Path: <www-data@nnaweb3.nemetschek.net>
X-Original-To: xxxx-tokka@example.jp
Delivered-To: xxxx@example.jp
Received: from mx1.example.jp (mx6.example.jp [IPv6:2001:db8:1:1000::25])
by mail.example.jp (Postfix) with ESMTP id 54B665C81F
for <example-tokka@example.jp>; Wed, 21 May 2014 19:55:43 +0900 (JST)
Received: by mx1.example.jp (Postfix, from userid 99)
id 1AB217281E9; Wed, 21 May 2014 19:55:43 +0900 (JST)
Received: from Mx.Vectorworks.Net (mx.vectorworks.net [207.10.60.91])
by mx1.example.jp (Postfix) with ESMTP id 7A0FE7281E4
for <xxxx-tokka@example.jp>; Wed, 21 May 2014 19:55:40 +0900 (JST)
X-Envelope-From: www-data@nnaweb3.nemetschek.net
X-Envelope-To: xxxx-tokka@example.jp
Received: From nnaweb3.nemetschek.net (207.10.60.85) by Mx.Vectorworks.Net
(MAILFOUNDRY) id zNNo9uDVEeOGrQAl for xxxx-tokka@example.jp;
Wed, 21 May 2014 10:55:12 -0000 (GMT)
Received: from www-data by NNAWeb3 with local (Exim 4.72)
(envelope-from <www-data@nemetschek.net>)
id 1Wn09R-0003HQ-2j
for xxxx-tokka@example.jp; Wed, 21 May 2014 02:37:21 -0400
Date: Wed, 21 May 2014 02:37:21 -0400
Message-Id: <E1Wn09R-0003HQ-2j@NNAWeb3>
To: xxxx-tokka@example.jp
Subject: =?UTF-8?B?5LiJ5LqV5L2P5Y+L44Kr44O844OJ44CQ6YeN?=
=?UTF-8?B?6KaB44CR?=
X-PHP-Originating-Script: 33:mails.php
From: welcome@vpass.ne.jp <welcome@vpass.ne.jp>
Content-Type: text/html; charset=utf-8
Mime-Version: 1.0
Content-Transfer-Encoding: BASE64
X-URIRBL: No, test=check_uri.pl, version=1.50
CQk8cD7ph43opoHjgarjgYrnn6XjgonjgZs8L3A+DQoNCgkJPHA+5pio5LuK44CB5LiA6YOo44Gu4
4K744Kt44Ol44Oq44OG44Kj44Gu44Gc44GE5byx44Gq44ON44OD44OI44K344On44OD44OX44Gq44
Gp44KI44KK44Kv44Os44K444OD44OI5oOF5aCx44KE44OR44K544Ov44O844OJ44Gq44Gp44GM5ry
P44GI44GE44GZ44KL5LqL5Lu244GM55m655Sf44GX44Gm44GK44KK44G+44GZ44CCPGJyIC8+DQoJ
VnBhc3NJROOBiuOCiOOBs+ODkeOCueODr+ODvOODieOCkuS7luOBruOCteOCpOODiOOBqOS9teeUq
OOBl+OBpuOBhOOCi+WgtOWQiOOBq+OBr+OAgea8j+OBiOOBhOOBl+OBn+aDheWgseOCiOOCiuOAge
aCquaEj+OBruOBguOCi+esrOS4ieiAheOBq+OCiOOCi+ODjeODg+ODiOOCt+ODp+ODg+ODlOODs+O
CsOOBp+OBruaCqueUqOOBruWPr+iDveaAp+OCguOBlOOBluOBhOOBvuOBmeOAgjxiciAvPg0KCVZw
YXNzSUTjgYrjgojjgbPjg5Hjgrnjg6/jg7zjg4njga/ku5bjga7jgrXjgqTjg4jjgafjga/kvb/nl
KjjgZvjgZrjgavjgIHlrprmnJ/nmoTjgavjgZTlpInmm7TjgYTjgZ/jgaDjgY3jgb7jgZnjgojjgY
bjgYrpoZjjgYTjgYTjgZ/jgZfjgb7jgZnjgII8YnIgLz4NCglWcGFzc0lE44O744OR44K544Ov44O
844OJ44Gu44GU5aSJ5pu044Gv44GT44Gh44KJ44KS44GU6Kan44GP44Gg44GV44GE44CCPC9wPjxi
ciAvPg0KDQoJCTxwPjxhIGhyZWY9Ind3dy5wYW5rby5jb20udHcvSW1hZ2UvY3NzLyN4eHh4LXRva
2thQGV4YW1wbGUuanAiPuKGklZwYXNz5oOF5aCx54Wn5Lya44O75aSJ5pu0PC9hPjwvcD4NCg0KCQk=
BASE64をdecodeすると、次の通り。
<p>重要なお知らせ</p>
<p>昨今、一部のセキュリティのぜい弱なネットショップなどより
クレジット情報やパスワードなどが漏えいする事件が発生しており
ます。<br />
VpassIDおよびパスワードを他のサイトと併用している場合には、漏えいした
情報より、悪意のある第三者によるネットショッピングでの悪用の可能性も
ございます。<br />
VpassIDおよびパスワードは他のサイトでは使用せずに、定期的にご変更いた
だきますようお願いいたします。<br />
VpassID・パスワードのご変更はこちらをご覧ください。</p><br />
<p><a href="www.panko.com.tw/Image/css/#xxxx-tokka@example.jp">
→Vpass情報照会・変更</a></p>
おまえなぁ…よく言うよという内容…。
*1:
BASE64に含まれるメールアドレス及び、ヘッダ上の固有の情報の一部はマスクしています
NDRPUDQ0T280NENCNUx1VjVMcUw0NEdONDRHKzQ0S0o0NEd0NDRPODQ0R0w0NEdxNDRHQjQ0Q0NEUW9O
Q3VPRGx1T0RxZU9EZytPQ3IrT0JxdVM4bXVla3Z1T0JyK09DZ3VPQmh1T0JpT09CaU9PQ2orT0FnZWVX
c3VPQ2pPT0JuK09BZ2cwS0RRcmpnYWpqZ1lMamdvdmt2SnJucEw0bzU3V1E1cWVMNXB5czVaRzk0NEdn
NDRHajQ0R2Y0NEdvNDRHVDQ0S05LZU9CcXVPQ2srT0JwdU9BZ1RMbHVxYmx2NXpsaTUvamdaZmpnYWJq
Z0lIb2tMM2pnYWpqZ1pYamdvempnSUVOQ2cwSzQ0S280NE84NDRLNDQ0S240NE96NDRPSTU3V001NVN4
NDRHbjQ0R1U1b3lINVpDTjQ0R240NEtxNDRPVjQ0S2g0NE84NDRHTjQ0R2Y0NEd1NDRHbjQ0Q0I1Yitj
NVl1ZjQ0R1g0NEdmNDRLSjVwdTQ2YUdlNllHNDZJQ0Q0NEdyNkpDOTQ0R2g0NEdmNDRHajQ0R200NEND
RFFvTkN1T0JoT09DaE9PQWdlaUJ0K1dMbWVlMWpPYXR0T2FidU9PQnIrV0ZyT21XaStPQmwrT0JwdU9D
aStPQm9PT0NqZUtBcHVPQWd1T0JuZU9Dak9PQ2t1T0J2K09CcHVPQ3F1T0RsZU9Db2VPRHZPT0JsK09C
cHVPQ2krT0NrK09CbU9PQ2crT0JxdU9CaE9PQnJ1T0JpK09BZ3VPQnFPT0FnZzBLRFFya3U1WGt1b3Zq
Z1l6amdhcmpnWVRqZ0lIamc0dmpnN3pqZzRqamdJTG5sSi9tdEx2b3NydmpncExqZ2FyamdwUGpnYWpv
c3JqamdadmpnYTNqZ2JEamdJSU5DZzBLNVlXSTVwZWw0NEd2NXArUVJFUGpnYXZqZ1lyamdZVGpnYWJq
Z1lMamdhUGpnWi9ucDRIbmlhbmpnYTdsbTU3bGo0N2pncExqZ1puamdiN2pnWnZqZ1ovamdJST0=
暗号...
＊
[Life] HootSuiteじゃなくて、ow.ly のアカウント削除した
ow.ly のアカウントやっと削除出来た。
タブレットで撮影していた写真をupしていたら、どうやら、EXIF情報てんこ盛りだったので、アカウントを削除することにした。
アップロードされたファイルを見る分には、EXIFは消されるんだけど、辿っていくとオリジナル写真を表示できるのだが、そのオリジナル写真にEXIFが入っていたからだ。以前はEXIF消していたのを確認して使っていたんだけどね…。仕様変更したのか、私の確認ミスだったのか、不明ですが…。
ということで、EXIFが残っているようで、位置情報もばっちり。ということで、ファイルを削除しようとしたら、一個一個消すしか出来なくて、しかも一個一個確認ダイアログが表示される。ファイル数が5000近くもあるので、削除するのは非現実的なため断念。
参考:
https://help.hootsuite.com/entries/23163243-Deleting-Ow-ly-Files
そのため、アカウントを削除しようとしたら、削除する項目がない。私のアカウントはそもそも、非公開で且つ、hootsuiteのアカウントをフォローされていないので、hootsuiteのアカウントに対して、DMを送ることもmentionをとばすことも出来ない。
アカウントの削除可能なのは、HootSuiteのアカウントだけで、ow.ly側のアカウントが連動して削除され、画像が削除されるか不明。サービスも連携しているだけで別物（だとおもわれる)。よって、HootSuite Help Desk に有る方法は怖くて使えない。
参考：
https://help.hootsuite.com/entries/21651301-cancelling-your-free-hootsuite-account
ということで、FBから英語でアカウントを削除してほしいというと、ファイルの削除をできるよと先ほどの案内のリンクが届くが、5000ファイル近くもあるので、非現実的なので、アカウントを削除してほしいと伝えたら、1週間後に削除されていた。
参考：
https://www.facebook.com/hootsuite/posts/10151100286513821
あー、つかれた。
＊
[Neta] 徘徊ぐるぐる。
感激過ぎる。そのほかのこの方のアカペラ、一人合唱など、すべてすばらしい。なんか、雰囲気、なおくんに似ているのは気のせい!?
独りでやさしさに包まれたなら
【アカペラ】Close To You
【アカペラ】So much in love
【男声合唱】少年時代
【男声合唱】さらに高いみち
ああ、満足。
その他この方のリストは、
shuttoken.tumblr.com へ。
＊
[Neta][Other] 生首、といいたい信号機が落ちていた
＊
[Car] 修理後の車を回収
無事に車が修理完了したという連絡を受けたので、三郷方面まで受け取りに。
現在ETC割引が無くなってしまったので、外環を走ると510円という値段の為、しかも、8%になったので、その分、値上がりしているので下道。
無事に受け取った後、行きつけの自動車工場へ持って行き、リアのデフオイルを交換。こちらは純正のCUSCO製を使用せず、
TOTAL TRANSMISSION DA 85W140のオイルを使用中。
ちなみに純正の指定オイルよりこちらの方が静かで乗りやすい。
今回は、3000kmでと言うことだったが、5000km(2ヶ月半)で交換。
実際にそれだけ載っていたが全然違和感がなかったということで、実際にオイルの汚れを確認したところ、黒くはなっている物のまだまだ大丈夫だったので、次回は、7000km程度で様子を見ましょうと。
基本的にはラリー走行というより、高速走行が多いため、デフロックすることがあまりなく、オイルも汚れないのではないかってこと。競技車両じゃないしね。
オイルを交換したとき、きついハンドルの切り方をしたとき、少しなめらかになったかな?ってぐらいだけど、体感的には余り変わらなかった。ちょくちょく様子を見ながら、交換サイクルをきめていきませう。本日のお会計は3500円。
Naverまとめ「
本日勃発！すき家ストライキ騒動まとめ #すき家ストライキ」
「
【衝撃】ネットでの風評被害やストライキの影響ですき家が瀕死状態 現地画像まとめ #すき家ストライキにも上がっているが、肉の日の29日にストライキが有ると言うことで、あえて、近くのすき家にいってみました。
ゼンショー曰く、
すき家の従業員にストライキ呼びかけ、ネットで拡散 閉店は「1店舗もなし」ということで、
「すき家ストライキ」が広がり始めたのは２１日夜。ネット掲示板「２ちゃんねる」に「ストライキやるか」「５月２９日はニクの日ということでスト決行」などの書き込みが相次いだ。
２２日にはツイッターでも話題になり、フォロワーの多いジャーナリストらも呼応し、一気に拡散した。
すき家を経営するゼンショーホールディングスはこうした動きを把握していた。個人で入れる労組の組合員の１人が同社工場でストをしたが、広報担当者は２９日、「従業員組合から要求は来ておらず、ストライキで閉店した店はない。第三者委員会の提言を受けて労働環境の改善に取り組んでいく」とした。
（朝日新聞デジタル「すき家、ニクの日にスト？ ネットで拡散も実現はせず」より 2014/5/30 05:33）
ということ。しかし、画像には、ストで営業停止している写真がいくつか見られるので、実際にどうかなということで、尋ねてみた。
そもそも家の近くのすき家は、ドライブスルーが普通に有るような田舎なんだが、
パワーアップ中ということで、そもそも人がおらず、
閉店(Naverまとめ)。駅の近くの別の店舗へ足を運んでみた。
そしたら、営業しているようで、牛丼を頼もうと、入店。店内には、10人ほどの客。私はささっと、カウンターへ座り、時計を見ながら何分でオーダーを取りに来るか、注文の品が出てくるか、何人でまわしているか確認。
店舗スタッフは2人のようで、お昼の12時頃。カウンターの席に着いても、お茶も注文も取らず、他の片付けをしており、こっちに来る様子は無い。時計をちらちらと見ていたら、4分後にオーダーだけを取りに来たので、「お茶が来ていないのですが。」といいつつ、注文。
オーダー後、1分程度で出てきたので非常に優秀。
伝票はこちら。
全然ネタにならず面白くない。ちなみに店舗には、アルバイトの募集があるか確認してみたところ、募集が無かったので、おそらくここは良店舗なんだろうと思った。ネタにならず。無念。
＊
[食] 29の日にちなんでいくどんでホルモン
＊
[食] 原宿のカフェ
原宿にあるカフェ。お店の名前は判らなかったのですが、カフェラテを頼んだらとてもカワイイのが。
クマー!!
ほっこり、幸せになりました。
アジアンダイニングサモサというチェーン系で、ワンコインでカレーがいただける。以前、
新橋(2014/03/13)でいただいた時、日替わりはトマトたっぷりなやつだったけど、今回は違うカレーだったので、入ってみた。昼間から打合せであちこち出歩いていて、お昼を食べ損ねていたので、ちょうど腹ごしらえ。
カレー。
辛さは辛くといったので、おもったより辛めに仕上がっていた。まあ、いいっか(笑
今回頂いたのは新橋よりおいしかったので、当たり。ラッキー。おいしゅうございました。
サモサ 神田店
03-3252-0044
東京都千代田区鍛冶町2-12-1 神田一番街高架下共同ビル 1F
＊
[遊び] 富士急ハイランド
富士急ハイランドのあと、その足でほうとう専門店小作。
4月にも一度きているのですが、量が明らかに多いのを知っているので、今回は二人で1つ。
きのこほうとう。二人でもお腹いっぱい…げふり。ただ、かぼちゃは、他のより少ないようでした。
柚子七味がおいしい。ああ、満足…。さて、大月経由で秩父方面にいきますかね。
一緒にいた人がインプレッサをのって、大月〜奥多摩ルートでわしゃわしゃ楽しそうに走っていました。
私はあそこのルート嫌いです(笑
ほんと、山道好きな女子同士の旅でしたｗ
Diary for 8 day(s)
