続、Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ
先週の火曜日、3月12日に始まったPublickeyへのDDoS攻撃は今週日曜日、3月18日日曜日の早朝を最後に収まったようです。この記事執筆時点でPublickeyのサーバは平常に戻っています。 この間、読者や広告を掲載いただいているお客様や代理店様にご不便やご心配をおかけし申し訳ありませんでした。 DoS攻撃とは、大量のトラフィックをWebサーバなどに浴びせることでサーバを応答不能にしてしまう攻撃のことです。 前回の報告「Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ」の後、さらにいくつか対策を講じましたので、この記事では前回の報告以後の経緯と講じた対策を記したいと思います。 また、前回の報告では「DoS攻撃」と書きましたが、その後Publickeyのサーバをホスティングしているさくらインターネットのサポート担当の方から、今回の攻撃は分散した箇所から攻撃を受けていると
2022年11月30日のAdGuard DNS部分的ダウンについて
2022年11月30日03:24（東京）に、AdGuard DNSに深刻な障害が発生し、マイアミ、ニューヨーク、ロンドンの3ヶ所のサーバーが影響を受けました。 障害発生中、これら3つの拠点に接続されているすべてのお客様のインターネットが事実上遮断されました。 これは、AdGuard DNSの全顧客の約20％、すなわち1000万人以上の方がインターネットに問題を抱えたことになります。 影響を受けた方に、このような事態になったことを心からお詫び申し上げます。 今後このような問題が発生しないよう対策を講じる所存です。 何が起きたのか 小さなミスがいくつも重なり、問題発生に至りました。 これらのミスは、それぞれ単独なら致命的ではなく、障害を引き起こすものではありませんでした。 しかし、残念なことに、これらのミスが重なったことこそが、より大きなトラブルの原因となりました。 最初のミスは、11月28日
東証、障害の原因を特定 設定値に不備、切り替え失敗
日本取引所グループは同日、調査結果を踏まえ、再発防止策などを検討する調査委員会を設置した。委員長の久保利英明弁護士をはじめ、4人の社外取締役で構成する。 関連記事 東証、10月2日は通常通りの売買へ システム障害を起こし全銘柄の売買を停止していた東京証券取引所は、明日、10月2日は通常通り売買を行うと発表した。 東証のシステム障害、解消は「明日以降」 「バックアップへの切り替え」で異常 東京証券取引所が、システム障害について「明日以降、正常な売買ができるよう対応している」と発表した。 東証にシステム障害 終日、全銘柄売買停止に【更新】 東京証券取引所は10月1日、相場情報に障害が発生したため、朝から全銘柄の売買を停止している。1日は終日売買停止となる。復旧については未定。 “東証を変えた男”が語る、金融業界の伝説「arrowhead」誕生の舞台裏――“決して落としてはならないシステム”がで
システム障害のおわびとまなび - freee Developers Blog
はじめに こんにちは、freee株式会社でCDO（最高開発責任者）をしている平栗です。 2018年10月31日に、freeeで起こしてしまったシステム障害について、その原因と対策、障害からの学びについて共有したいと思います。 この記事はfreee Developers Advent Calendarの22日目になります。 おわび まず、約2時間半にわたりfreeeの全サービスを停止し、皆様に多大なるご迷惑をおかけしましたことを、改めてお詫び申し上げます。 今回の障害を大きな学びと成長の機会とし、今後の再発防止と業務改善に取り組んでまいります。 障害の経緯 2018年10月31日12時34分～15時00分の2時間26分の間、freeeの全サービスを一時停止し、すべてのサービスがご利用できなくなりました。 以下、復旧までの経緯です。 11時24分 特定の機能が利用できなくなっていると、社内から
大規模memcached障害と私 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は ex-mixi Advent Calendar 2017 19 日目のエントリーです。 こんにちは。@bonnu と申します。 株式会社ミクシィには2006年１月から2012年３月末までの間、６年と３ヶ月ほど在籍していました。その後株式会社FreakOut（現在はホールディングスとなっています）に転職。そこからさらに転職を重ね、現在は株式会社GameWithでサーバーサイドを主としたエンジニアをやっています。 ミクシィに入社した当時はまだ社名が株式会社イー・マーキュリーで、入った翌月に社名変更したタイミングでした。なので希少
「ザ・インタビューズ」がサービス終了 「復旧不可能な事象」が発生したため | ねとらぼ
ユーザー同士が匿名でインタビューし合えるサイト「ザ・インタビューズ」が、2016年2月15日をもってサービス終了することが発表された。「復旧不可能な事象」が発生し、サービスの提供・維持が困難になったという。 ザ・インタビューズは、paperboy&co.（現GMOペパボ）が2011年夏にリリース（関連記事）。一時は会員数が40万人を超えるなど人気を博し、2014年2月からはSAKURUG（旧gooyaAd）が運営していた。 2015年12月から長期メンテナンスに突入し、ネット上には「開くたびにメンテナンスになっている」といった声も寄せられていた。運営事務局は「ご愛顧頂きましたお客さまには、この様な結果となりましたことを心よりお詫び申し上げます。申し訳ございません」と謝罪している。 ザ・インタビューズ 譲渡時のリリース
ザ・インタビューズ、“復旧不可能”なためサービス終了に | RBB TODAY
ユーザー同士が相互にインタビューを行えるソーシャルサービス「ザ・インタビューズ」は3日、サービスを終了することを発表した。昨年末ごろよりメンテナンス状態が続いていたが、2月15日をもって、正式に終了する。 「ザ・インタビューズ」は、相手に質問をぶつけインタビューを行えるサイトとして、Paperboy&co.が2011年9月に正式版を公開。2014年2月からはgooyaAd（現SAKURUG）が運営を行っていた。 現在サイトはトップページのみになっており、過去の内容などは閲覧出来ない。サービス終了の理由については「復旧不可能な事象が発生し、サービスのご提供・維持が困難であるという結論に達した」と説明されている。 《冨岡晶》
GitHubが先週木曜日にダウンした原因は、一時的な停電からの連鎖的な障害
日本時間で1月28日木曜日午前9時過ぎから発生したGitHubのサービス障害は、同社のデータセンター内での一時的な停電をきっかけに連鎖的に発生した障害の影響であることが、GitHubのブログに投稿された記事「Update on 1/28 service outage」で説明されています。 GitHubのブログから引用します。 A brief power disruption at our primary data center caused a cascading failure that impacted several services critical to GitHub.com's operation. 主データセンターにおける一時的な停電が連鎖的な障害を引き起こし、GitHub.comの運用にいくつもの深刻な影響を与えてしまった。 GitHubの説明によると、障害が発生したのは協
DC/クラウド/通信事業者サービスの障害事例よせあつめ - # cat /var/log/stereocat | tail -n3
はじめに データセンタ障害の話題がちらほら流れておりますが、その中で見かけた「データセンタでそんな障害あったら意味ねえじゃん」みたいなコメントにちょっと引っかかるところがありまして。まあ確かに電源の二重化云々とかいろいろ災害やトラブルに対する対策はしてますよ。してますけど、でもデータセンタ・オーダーの障害とかも実際あるんですよね。落ちるときは落ちるんですよデータセンタだろうと。信頼性は高いけど100%じゃない。 ということで、じゃあ過去どんな事例があったのか、ざっと事例を挙げてみようと思いました。基本的には過去の私のツイートとかはてブとかネットをざーっと検索して出てくるものを取り上げています。「データセンタ使ってるからオールオッケー」みたいな話ではなくて、その上で・さらにこういうこともあるんだ、という話を見るのに参考にしてもらえれば良いかと思います。 なお、ここで取り上げている事例は、特定
GMO、先週の24時間にわたるサービス障害時にはデータセンター内の約12％が電源喪失。変圧分電盤故障が原因の可能性。監視体制の強化など対策
先週末、2016年1月16日から17日にかけて、GMOインターネットが提供するレンタルサーバやドメイン名登録などのサービスで管理画面が表示できなくなるなどの障害が約24時間にわたり発生しました。 GMOインターネットはWebサイトで影響の範囲や復旧状況などを報告、それによると障害の影響範囲は、お名前.com、レンサバ.comなどに加え、ConoHa byGMO、GMOアプリクラウドなどクラウドサービスまで広範囲に渡っています。 また、障害の原因は「データセンター内における電源設備の一部故障」とされました。 24時間という長時間かつ広範囲に発生した障害の実態はどうだったのか、また原因とされた電源設備の一部故障とはどのようなものだったのか、GMOインターネットの発表は詳細部分について触れられていなかったため、PublickeyではGMOインターネットに対して取材を申し込みました。 GMOインタ
当社複数サービスサイトの表示不可等の事象について | GMOインターネット株式会社
【最終報告】1月17日（日） 14:30現在 この度は当社複数のサービスに障害が発生し、多くの皆様にご迷惑をお掛けいたしましたこと、心よりお詫び申し上げます。 また発生から正確な状況の確認や対策に時間を要し、復旧が遅れましたことを深くお詫び申し上げます。 障害が発生しておりました全てのサービスにおいて安定稼動を確認いたしましたので、 改めて以下に本件のご報告をさせていただきます。 ■発生時刻： 2016年1月16日 14:15頃～1月17日 14:25 ■影響範囲： 以下のサービスをご利用のお客様 ・お名前.com：https://www.onamae.com/ ・かんたんサーバー：http://www.kantan-server.jp/ ・レンサバ.com：http://www.rensaba.com/ ・InterQ Office：http://biz.interq.or.jp/ ・e
Webサービスを常時SSL化しようとして諦めた話
弊社の新規事業でWebサービスを作っていて、セキュリティトレンドの常時SSLってやつをやってみようと思った。 世のWebサービスを見てみるとやっている所が何故かほとんどなく、mixiやニコニコなどの大手もやってないようだ。ニコニコのURLを試しにhttpsにしてみたら繋がらず、mixiはhttpにリダイレクトされる。 うちは新規だから最初からhttps化することで特にデメリットはないと判断、安いSSL証明書を買ってhttpをhttpsにリダイレクトするようにした。技術的な難所はまったくないので問題なく実装完了し、これで安心度がちょっと上がったと思っていたのだが…。 つづく。 続き。 弊サービスではユーザーがYouTubeなどの動画を貼り付ける機能が重要なのだが、テストしてみるとニコニコ動画の埋め込みが動作しなくなっていた。調べてみるとニコ動の埋め込みコードがhttpなせいで、さらに最近のブ
Docker で Web アプリを運用してみた - kotas.tech
Docker してますか！ 実は実験的に Docker で Web アプリを数ヶ月運用しており、色々と試行錯誤してきたので、少しずつアウトプットしていきます。 ちなみに Ruby 製のアプリで、AWS の EC2 上で運用している、小〜中規模ぐらいのものです。 2014-06-16 16:00: 追記あり Docker イメージのビルドについて Dockerfile を普通に書いてます。 今のところ、2層構造にしていて、 ベースとなるイメージ Ruby アプリケーションサーバー (Puma) アプリケーションのソース (git clone) bundle install デプロイされるイメージ (ベースイメージを元に作る) git pull してソース更新 bundle install し直してベースにない gem を入れる asset の precompile という感じでやってます。
冬の日2014〜ioDriveが壊れた日〜 - FAT47の底辺インフラ議事録
ある日 ioDriveを積んでるMySQLスレーブサーバが突然の死。 というか、レプリケーションが止まっていました。 サービスから参照されていないDBではあったので、 特に死んでいても問題にはなりませんでした。 今回つかっていたのはioDrive Duoです。 /var/log/messages確認 とりあえずシステムのログを確認してみると、 Jan 27 05:39:36 hoge-dbs kernel: fioinf HP 640GB MLC PCIe ioDrive Duo for ProLiant Servers 0000:09:00.0: groomer read had error -1024 Jan 27 05:39:36 hoge-dbs kernel: fioerr HP 640GB MLC PCIe ioDrive Duo for ProLiant Servers 00
nabokov7; rehash : ファーストサーバのデータ消失事故、一番の問題を挙げるとしたら？
ファーストサーバのデータ消失事故の件、こちら側(サービス提供してる側)の人達が大人しい気がするのは、やはり明日は我が身だということがよく分かってるからだろうなぁ。 偉そうなコメントをして鼻高々になってると、いつブーメランが飛んでくるか分からない。万全を期していても落とし穴は必ずどこかにある。 それはそれとして、あえてこの件で一番の問題は何だったかと問われたら、僕は「脆弱性の修正パッチをバックアップにも適用する」という修正をしたことだと思う。 脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サー
[PDF] さくらのクラウド・ストレージに関する報告書 2012 年 6 月 25 日
さくらのクラウド・ストレージに関する報告書 Page 1 of 8 SAKURA Internet Inc. さくらのクラウド・ストレージに関する報告書 2012 年 6 月 25 日 さくらインターネット株式会社 代表取締役 社長 田中邦裕 平素よりさくらインターネットに格別のご愛顧を賜り、誠にありがとうございます。 2011 年 12 月中旬から断続的に発生しておりました、さくらのクラウド・ストレージ障害 につきまして、サービスをご利用の皆様に深くお詫び申し上げます。 現行ストレージの障害内容の詳細と新ストレージの提供に関しまして、以下の通りご報告 させていただきます。 1. 障害の概要と原因、その対処 2011 年 12 月 9 日の最初の障害から、2012 年 3 月末まで断続的に障害が発生しておりまし た。個々の障害については発生の都度報告をさせていただいておりましたが、以下に原
「ストレージの事前検証が十分にできなかった」さくらインターネット田中社長、クラウドのストレージトラブルの原因について － Publickey
「ストレージの事前検証が十分にできなかった」さくらインターネット田中社長、クラウドのストレージトラブルの原因について さくらのクラウドで昨年から発生したストレージのトラブルについて、さくらインターネットは今日、詳細な報告書を公開しました。 Publickeyでは同社代表取締役社長 田中邦裕氏、さくらインターネット研究所 所長 鷲北賢氏に対してインタビューを行い、トラブルを引き起こした原因がどこにあり、その教訓は何なのかを聞きました。 ストレージトラブルの教訓は「リスクを引き受けるため、十分に検証せよ」 ──── 「さくらのクラウド」でのストレージのトラブルについて、今回報告書を公開され、また新たな自社製ストレージも発表されました。これまでを振り返っていただくと、トラブルを引き起こした原因はどこにあったとお考えですか？ 田中氏 ストレージ装置の採用時にきちんとしたテストをできていなかった。具
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Zenlogicサポートサイト［IDCフロンティア］
本当は恐ろしい分散システムの話
データセンターとクラウドのIDCフロンティア
