『真琴 on Twitter: "これ、7pay側は「よくわかんない全部ベンダーのせいタダでやれ7/11までに必ずやれペナルティも払え」とか言い出したらしく、関連PJにいた知人たちから「いい案件ない？明日逃げる」って連絡がとんできたｗ https://t.co/PD7t6jzeKK"』へのコメント政治と経済 真琴 on Twitter: "これ、7pay側は「よくわかんない全部ベンダーのせいタダでやれ7/11までに必ずやれペナルティも払え」とか言い出したらしく、関連PJにいた知人たちから「いい案件ない？明日逃げる」って連絡がとんできたｗ https://t.co/PD7t6jzeKK"
艦隊これくしょんへのDoS攻撃についてまとめみた - piyolog
2019年1月10日頃から、DMMが運営するゲーム「艦隊これくしょん」に対してDoS攻撃とみられる影響（Twitter公式では「飽和接続攻撃」と表現）により、接続障害が発生しています。ここでは関連情報をまとめます。 艦これ運営側が報告する攻撃の状況 段階的に攻撃対象のサーバーへ集中攻撃を仕掛けている。 データベースを含めた攻撃を受けている可能性がある。 対象はプラットフォームではなく、艦これが稼働するサーバーに対して行われている。 攻撃送信元は海外を起点とするもの。 詳細は報告を避けるが通常のDDoS攻撃ではない攻撃も含む。 艦これ運営側の対応 上流回線業者の協力を得て対策に当たっている。 ユーザーへ通信状況に応じた対応（サービス利用や課金の一時的な見合わせ）を呼びかけ。 イベント開催期間を5日間延長。 関係当局への届け出等、業務妨害行為に対する必要な措置を取る。 DDosMonでのDoS
docomo Online Shopへの不正ログインとiPhoneの不正購入についてまとめてみた
NTTドコモの運営するオンラインショップサイトに不正ログインが行われ、iPhoneが勝手に購入される被害が多数出ていると報じられました。ここでは関連情報をまとめます。 関連する公式案内 2018年8月14日 不正なアクセス対策としての「2段階認証」ご利用のお願い 2018年8月15日 ドコモオンラインショップにおける2段階認証開始について 2018年8月22日 ドコモオンラインショップにおける商品受取方法の変更について インシデントタイムライン 日時 出来事 2018年7月下旬 NTTドコモがオンラインショップサイトへのリスト型攻撃を検知。 2018年8月2日頃 Twitter上で不正ログインなどのツイートが出始める。*1 2018年8月5日 ユーザーから連絡を受け、NTTドコモがiPhoneの不正購入を把握。*2 ： NTTドコモが不正購入への対策を実施。 2018年8月13日 NTTド
米グーグルの設定ミス、なぜ日本の大規模ネット障害を引き起こしたのか？ | 日経 xTECH（クロステック）
「ネットワークの誤設定により、インターネットサービスにアクセスしづらくなる障害が発生した。ご不便、ご心配をおかけしたことをお詫びする」――。2017年8月25日昼ごろ日本国内で発生した大規模な通信障害。これについて米グーグルが、原因となる誤設定があったと、謝罪の意を8月26日に表明した。 当初より識者の間では、「グーグルから送られてきた大量の経路情報が引き金になったのではないか」との見方が強かった。実際にその通りだったわけだ。 とりわけ大きな影響を受けたのが、NTTコミュニケーションズとKDDI、そしてこの両社の通信サービスを利用していた法人・個人だ。インターネットの接続から各種ネットサービス、金融取引、モバイルSuicaのような決済サービスにまで影響が及んだ。 ただグーグルは、同社がいう「ネットワーク誤設定」が、人為的ミスなのか、ソフトや機器の不具合によるものなのかまでは明らかにしていな
システム移行メンテナンスにおける一部時間帯に更新されたデータが消失した原因のご報告 - Mackerel お知らせ #mackerelio
Webオペレーションエンジニアの id:y_uuki です。 2017年8月7日に、メンテナンスの完了報告及びデータ消失とカスタムダッシュボード、式監視の不具合に関するお詫びにてお知らせしたメンテナンス作業時間中のデータ消失について、本エントリにて技術的な観点から原因の詳細をお伝えいたします。 概要 2017年8月7日(日本時間)に、オンプレミスデータセンターからAWSへ、Mackerelをシステム移行するためのメンテナンスを実施しました。 メンテナンス開始時間である14:30以降のデータ同期に失敗していたPostgreSQLデータベースサーバへの意図しないフェイルオーバーが、メンテナンス作業途中の15:30に発生した結果、14:30から15:30の間に更新されたデータを消失しました。 移行作業後のアプリケーションの動作確認中に、特定時間帯のデータを消失していることを発見し、データの復旧を
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch