タグ別アーカイブ: AWS

AWS EC2へのSSHに対する攻撃を分析してみた (2015年4月〜6月) | ある研究者の手記

富士通研究所の齊藤さんが発表された「SSHログインセンサによるSTBF(Brute Force attacks with Single Trials)の観測」において 一つのIPアドレスからパスワード試行が1回だけ実施されて、次は別のIPアドレスから試行されて、というのを繰り返すBrute force攻撃が確認されたという 事例が報告されていました。これは、一つのホストからパスワード試行を繰り返すと防御側に目立って接続拒否されたり、 共有されているブラックリストに掲載されてしまい他の環境に対しても攻撃ができなるなることを攻撃者が警戒した結果、 ボットネットのように悪性ホストを大量に所有(またはレンタル)している攻撃者が目立たないように1回だけパスワード試行をして去る、という 一撃離脱型の攻撃が連続して発生しているということだと考えられます。 この攻撃に対してはIPアドレスを基準としたパスワード試行回数制限による対策がほぼ無効化されてしまうということが言えます。

引用元: AWS EC2へのSSHに対する攻撃を分析してみた (2015年4月〜6月) | ある研究者の手記.

AWS EC2へのSSHに対する攻撃を分析してみた (2015年4月〜6月) | ある研究者の手記

今回利用したハニーポットは特にSSHサーバを偽装するわけではなく、 アクセスしてきた接続元のホストに対してSYN-ACKを返すだけで、あとは勝手に相手が送ってくれたデータをせっせと回収します。 ではなぜ22番ポート以外もSSHだとわかったのか?というとSSHの接続確立時に相手が勝手にバナーとして SSH-2.0-PUTTY のような文字列を送ってきてくれるので、そこからSSHをターゲットにしているということがわかります。 なかにはSSH-2.0-paramiko_1.15.2やSSH-2.0-libssh2_1.4.2のように、あからさまにツール使ってますぜと宣伝してくれている やつもいたりします。 しかし先に述べたとおりこちらからは何も情報を渡していないため、相手は攻撃先がSSHサーバであるかどうかを確認などせずに22番以外の ポートに接続をしにきているということがわかります。「ポート番号を変えているからパスワード認証でも大丈夫だよね」とか 「ポートスキャンを止めているからどこがSSHのポート番号かわからないよね」と考えている管理者の方はぜひ設定の見直しをお勧めいたします。

引用元: AWS EC2へのSSHに対する攻撃を分析してみた (2015年4月〜6月) | ある研究者の手記.

AWS EC2へのSSHに対する攻撃を分析してみた (2015年4月〜6月) | ある研究者の手記

観測されたIPアドレスは全部で6,669件ですが、そのうちの約80%にあたる5344件の攻撃元IPアドレスがどれか一つのインスタンスでのみ 観測されているということになります。それぞれのインスタンスはある程度同じレンジにおさまっていたため、 このことから 攻撃者は近接するアドレスに対して何度も出現する可能性が高いとは言えない ということがわかります。 先ほどのポート番号に比べると直接的な対策ができるような類のものではありませんが、例えば自組織で管理されている サーバでSSHの不審なアクセス(Brute forceなど)が発生したさいに他のサーバも利用するブラックリストに追加する、 というような対策はそれほど効果的ではないかもしれません。(もちろん、残り20%は複数インスタンスで観測されているので 無意味ということはありませんが、それでも全インスタンスで観測されたアドレスは約6.5%ほどになっています)

引用元: AWS EC2へのSSHに対する攻撃を分析してみた (2015年4月〜6月) | ある研究者の手記.

米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る - Publickey

NetflixがChaos Monkeyで試していたシステムの中には、同社がバックエンドデータベースとして採用しているNoSQLのCassandraも含まれていました。実は同社の今回のブログはこの部分がいちばんの見所になっています。

Last year we decided to invest in automating the recovery of failed Cassandra nodes. We were able to detect and determine a failed node. With the cloud APIs afforded to us by AWS, we can identify the location of the failed node and programmatically initiate the replacement and bootstrap of a new Cassandra node.

昨年、私たちは落ちたCassandraノードの自動リカバリに取り組むことを決断した。落ちたノードを検出することは可能であり、AWSによるクラウドAPIでそれがどのロケーションなのかを判別できるため、それを置き換え、新しいノードを立ち上げるプログラムを実現した。

この自動化を実現した上で、Chaos MonkeyによるテストにはCassandraが加わり、サーバが落ちても動作し続けるように検証が続いたそうです。

この結果、今回のAmazon EC2のメンテナンスでは、運用中の2700を超えるCassandraノードのうち218がリブートされ、そのうち22ノードのリブートが失敗したにもかかわらず自動的に復旧が行われ、全体としてはダウンタイムゼロでAmazon EC2のメンテナンスリブートを乗り切ったと報告されています。

Netflixのブログは、「パーシステントレイヤー(データベースのような永続的データを担当するレイヤー)であっても、レジリエンス(障害などへの対応力や回復力)の計画を持つべきだ。もしCassandraをChaos Monkeyのテストに加えていなかったら、今回の話は別の結果に終わっていただろう」と結んでいます。クラウド上に展開したシステムをどのように設計し、テストすべきなのか、大きな示唆を与えてくれているのではないでしょうか。

引用元: 米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る - Publickey.

ASCII.jp:ドコモ、AWSの料金システムが複雑なのは「おたがいさま」

AWSの料金についても、大企業としては扱いづらい点もあったという。

「オンデマンドでお金が使えるといっても、予算折衝的には安定的にお金を前払いという方がラク。結果的に安くなるけど、最初の時点で安くなるかどうかは分からないというのは怖い。AWS保険が欲しい」

AWSの料金設定は複雑だ。NTTドコモでは、複数のプロジェクトをまたがって運用している部署がまとめて勘定する「コンソリデーテッド・ビリング」(一括請求)の仕組みを使っているが、運用上の課題があった。

たとえばプロジェクトAが「ワークロードに対して最適化し、RIを戦略的に購入して……」とまじめに考え、プロジェクトBは「まあどうせ会社が払ってくれるんだから何もしなくてよくね?」と適当に考えていたとする。

しかし、請求額が合算されると、Aの努力はBに吸収されてしまうのだ。Bは「なんかしらんけど今月はいつもよりちょっと少なかった」となり、Aは「あれだけ頑張ってんのにやる気なくすわ!」となってしまう。

そこでドコモでは自前のコスト管理ツールを開発。リザーブド・インスタンス(予約金を払うと料金が安くなるAWSのシステム)の有効利用度を見える化し、AWSの料金設計を使いやすくしているのだという。

クラウドならではのスケーラビリティー、為替のように日々変動する料金設計も含めて「AWSは面白い」と栄藤氏。「まあ料金システムが複雑なのはおたがいさまなんだけど」。

引用元: ASCII.jp:ドコモ、AWSの料金システムが複雑なのは「おたがいさま」.

自治体のExcelファイルを“5つ星”オープンデータ化 jig.jpがプラットフォーム開発 鯖江市が採用 – ITmedia ニュース

アマゾンデータサービスジャパンとSAPジャパンが、オープンデータプラットフォームの展開に協力する。サーバには、Amazon Web Services(AWS)を活用。登録データが増え、処理の負荷が重くなってきた段階で、SAPのリアルタイム分析製品「HANA」(High-Performance Analytic Appliance)を導入する。SAPは、顧客の自治体にオープンデータプラットフォームを紹介したり、開発者コミュニティーにアプリ開発を呼びかけるなどの協力も行う。

引用元: 自治体のExcelファイルを“5つ星”オープンデータ化 jig.jpがプラットフォーム開発 鯖江市が採用 – ITmedia ニュース.

リリースの高速化はWebサービス企業にとって最重要である – delirious thoughts

リリースあるいはリリースの高速化自体を目的化するのではなく、その結果としてのビジネス的成果が大事だということは、マネジメントにとっては当たり前なわけで、いちいちいうまでもないことだろう。そもそも、サービスが圧倒的に成長し続けていれば、リリース頻度 = 成果になるはずだ。現状そうでないのであれば、成長速度が遅いということになる。エンジニアが技術を尽くしてリリース速度を向上させたにも関わらずそれが成果に結びつかないとしたら、そこにこそマネジメントの課題がある。

つまり、リリースあるいはリリースの高速化が目的化するなんてことは問題ではない。リリース頻度は多ければ多いほうがいいに決まっている。そのためには、技術を尽くして高速化するべきだ。その上で、その結果としてのリリース頻度の向上が、そのままストレートに成果につながらないことが問題である。そしてそれは、マネジメントの問題だ。リリースの自己目的化を問題視するのは、その意味で、視点がズレているように思える。

リリース頻度を高めることは、我々Webサービス企業にとっては、至上の目標である。なぜなら、不確実な将来に対してはそれ以外に根本的な方法がないからだ(技術的な観点からの将来予測については「「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays」で述べた)。リリースあるいはその速度自体が目的でないのは当然であるが、真の問題は、向上したリリースのひとつひとつを成果に結び付けられる状況を作り出せるかどうかである。

リリースあるいはその速度を目的化してはならない、大事なのはビジネス成果であるという話は一見もっともらしいが、先述の通りマネジメントにおいては当たり前なことなので意味のある議論ではないし、非ビジネス従事者に対しては威嚇的効果しかないだろう。リリースがいかに速く、多量に行われるか、そしてそれらのリリースが自然と成果に結びつく状況を作り出すことこそが、マネジメントの本質的な課題だろうと思う。

引用元: リリースの高速化はWebサービス企業にとって最重要である – delirious thoughts.

エクイニクス、複数クラウドサービスを連携させる「Cloud Exchange」 – クラウド Watch

Equinix Performance Hubは、企業のプライベートネットワークを、エクイニクスのIBXデータセンターに延長するソリューション。企業は自社のインフラと市販の機器を使い、ネットワークやクラウドサービスに、安全かつ確実に接続することが可能になる。

「当社が提供するデータセンターサービスをリパッケージ化したものであり、アジアに展開することで、エンドユーザーの近くにPerformance Hubを設置でき、ネットワークパフォーマンスを最大化する、戦略的なデータセンター活用を実現できる」(古田代表取締役)としている。

3月に北米でPerformance Hubの提供を開始していたが、アジア太平洋地域でのニーズが高まっていることに対応したものだという。

具体的には、ラック、電源、Cross Connect(構内接続)といったエクイニクスのIBXデータセンター内での「ハウジング」、メトロイーサネット、長距離接続(MPLS-VPN)、ISPといった「ネットワーク接続性」、ルーティング、スイッチング、ファイアウォール、SSL-VPN、ロードバランサー、WANアクセラレーションといった「ネットワーク設備」、Amazon Web Services (AWS)、Microsoft Azureなどパブリッククラウドへの広帯域プライベート接続といった「クラウド接続」を提供する。

「データセンターとネットワークインフラ、クラウドコンピューティングとの接続によって、アプリケーションのパフォーマンスを向上させる当社独自のソリューションであり、世界中で一貫したユーザーエクスペリエンスを提供できるのも特徴。広域ネットワークを単純化し、コスト削減を可能にするほか、パブリッククラウドへの直接接続およびハイブリッドクラウドへの移行に向けた事前準備も可能になる。すでに、Chevron(シェブロン)、eBay、およびNVIDIAといったグローバル企業が、世界中のEquinixのデータセンターにおいてPerformance Hubを導入する予定」だという。

引用元: エクイニクス、複数クラウドサービスを連携させる「Cloud Exchange」 – クラウド Watch.

Amazon Web Services ブログ: 【AWS発表】Amazon S3 でバージョン管理されたオブジェクトもLifecycle管理が可能に

本日より、バージョン管理を有効にしたS3バケットに、Lifecycleルールを適用することができるようになりました。 この一見単純な変更により、S3、Glacierおよび、バージョン管理がより有益で便利なものになります。 例えば、最新バージョンのオブジェクトをS3に保持しつつ、古いバージョンはGlacierに移行するといったことをすることができます。 (必要とする可能性が最も高いだろう)最新バージョンはすぐに取得することができますし、古いバージョンも3〜5時間以内に確実にアクセスすることができます。 お客様のユースケースによりますが、最新のバージョンも含めて、全てのバージョンをGlacierに移行したいかもしれません。 オブジェクトを作成してから数日後に各バージョンを期限切れにしたいかもしれません。 この新機能を利用すれば、これらのユースケースに全て柔軟に対応することができます。 この新機能を使用することで、コストの安いGlacierのストレージと、S3のバージョン管理の柔軟性を組み合わせて、全体的なストレージコストの削減に貢献します。

引用元: Amazon Web Services ブログ: 【AWS発表】Amazon S3 でバージョン管理されたオブジェクトもLifecycle管理が可能に.

Amazon Web Services ブログ: 【AWS発表】Amazon S3 でバージョン管理されたオブジェクトもLifecycle管理が可能に

S3のLifecycle ManagementはS3とGlacierを統合し、各オブジェクトのStorage Classを介して、詳細を見ることができます。 Storage ClassがStandard か RRS (Reduced Redundancy Storage)のオブジェクトはS3に保存されています。 Storage ClassがGlacierの場合は、データがGlacierに保存されています。 Storage Classが何であるかに関わらず、オブジェクトはS3 APIおよび他のS3のツールを使ってアクセスすることができます。 Lifecycle Managementを使うと、Transition(Storage ClassをGlacierに変更)とExpiration(オブジェクトの削除)を引き起こす時間ベースのルールを定義することができます。 Expirationのルールを使うと、特定の世代より古くなったオブジェクトを削除することができます。 これらのルールを利用することで、お好みのロールバックウィンドウよりも古くなったオブジェクトを削除を自動的に削除し、ストレージコストを減らしつつ、それまではデータを利用可能にし続けることができます。

引用元: Amazon Web Services ブログ: 【AWS発表】Amazon S3 でバージョン管理されたオブジェクトもLifecycle管理が可能に.