サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
gblogs.cisco.com
投稿者:Martin Lee、Vanja Svajcer 2017 年は、WannaCry や BadRabbit などの自己増殖型のワーム攻撃や、世界中の組織に影響を及ぼしたさまざまな脆弱性が話題を集めた、サイバー セキュリティにとって波乱の 1 年でした。2017 年、Talos の研究者は、数多くの新しい攻撃を発見しました。たとえば、CCleaner などの正規のソフトウェアに仕込まれたバックドア、M.E.Doc 社などのハイテク企業をターゲットにしたもの、Nyetya の初期拡散を招いたものなどです。とは言え、これらの大々的に報じられた攻撃は、セキュリティ システムが日々防御しているもののごく一部に過ぎません。 この記事では、最も頻繁にトリガーされた Snort シグネチャを調査した結果判明したことをいくつか取り上げます。調査の対象は、Cisco Meraki システムがレポートし
Cisco Talos では、ほぼすべてのコンピュータで使用されている、Intel、AMD、Qualcomm、ARM プロセッサに影響する 3 つの新しい脆弱性を認識しています。現在、この問題に関する調査は進行中であり、これらの脆弱性のエクスプロイトはまだ確認されていませんが、それはまだ発生していないという意味ではありません。Talos では、これらの脆弱性の存在を実証するために開発された、エクスプロイト コードが公開されていることを確認しています。 これらの問題には、次の CVE エントリが割り当てられています。 Meltdown:攻撃者はユーザ スペースからカーネル メモリにアクセスできます。 データ キャッシュの不正な読み取り(CVE-2017-5754) Spectre:攻撃者は、他のユーザが実行中のプログラムからメモリの内容を読み取ることができます。 分岐先のインジェクション(C
京都府庁からシスコに派遣で来ております山本です。さて、今回の記事も前回に引き続き、インタビュー記事になります。私と同じように公務員でありながら IT 系企業等に派遣され、公務と異なる環境で仕事をされている方々にそこでのワークスタイルの違いや日々の気づきをお伺いすることで、「公務職場の更なる可能性」をご紹介できればと思います。 今回は、練馬区役所からあのアリキリで有名な働き方改革応援企業のサイボウズに派遣されている榎本雄太さんにインタビューをさせていただきました。 山本: サイボウズに派遣された経緯をお聞かせください。 榎本雄太さん(以下、榎本):民間企業のノウハウやカルチャーを勉強し区政に活かそうという練馬区独自の研修制度により、サイボウズに派遣されています。1 年間の研修派遣で、私は昨年の前任者から続いて 2 人目になります。意外に思われるかもしれませんが、28 年度から始まったこの派遣
データセンター/仮想化 Cisco ACI とは何なのか(1) 「ACIをシンプルにL2/L3スイッチとして考えてみる」 シスコの Application Centric Infrastructure(ACI)は、2014年 8月のリリースから 3年以上が経過し、今や非常に実績豊富なソリューションとなってきました。国内外多くのお客様にご採用いただき、国内における実績も毎年倍増を続けています。導入先の業種は多岐にわたり、小規模から大規模まで様々な使われ方をしています。 リリース当初、私たちは ACI を紹介する際に「これまでのネットワークとは大きく違う革新的なソリューションである」ということをあまりにも強くアピールし過ぎていたようです。そのため、既存のネットワークの導入・管理とは全く異なる管理手法が必要となると誤解され、お客様・パートナーの皆様から「私には ACI はまだ早そうです」と言われ
New Era of Networking におけるセキュリティ シスコは、企業や組織に対応した「新しい時代のネットワーキング」として、ルールやポリシーの変更作業や、ネットワーク基盤で発生している問題やその影響範囲などを、直感的に実行把握できるインテントベース ネットワーキングを発表しました。その中では、変更と監視が連携した自動運転が強調されていますが、同時に、ネットワーク全体で脅威活動の検出と緩和も必須要件とされ、暗号化トラフィックを復号化せずに検出する ETA(Encrypted Traffic Analytics)機能が全体を囲むように位置づけられています。 このブログでは、以前に NetFlow 技術を使ってトラフィックの異常、すなわちセキュリティ インシデントを見つける取り組みを紹介しました(「ネットワーク内部を可視化し、異常検出を行うフローコレクター」)。その記事では、Flow
先日の BGP インシデント [*1] は影響の大きいものでした。シスコの比較的旧い L3 スイッチでは、TCAM 容量溢れのため SW フォワードに切り替わり、スイッチをリロードしないと復旧しないという問題が発生し、ご迷惑をおかけしてしまいました。そのため、関連するアカウントチーム はお詫びと事態収拾に努めました。 しかししかし。言ってみればこの動作は仕様どおりの動作であり、以前から何度となく注意喚起が行われています [*2]。しかもインターネット経路数は、 トラフィックを細かく制御するニーズが高まっているためか、IPv4 アドレス枯渇後も増加し続けています(Route-Views データによると IPv4 経路は現在 70万を越えています [*3])。従って、このようなインシデントがなくても、いずれにせよ根本的な対処が必要でした。 でもそうは言っても、突然の 10万経路の誤広報は厳しい
Cisco DNA(Digital Network Architecture)で発表した「The Network. Intuitive.」では、Cisco Catalyst 9000 シリーズに加え、ネットワーク コントローラやデータ分析プラットフォームなど、ソフトウェア面が強調されました。その他にも、あまり国内では取り上げられていませんが、Cisco IOS-XE そのものの実装も大きくリフレッシュされ、内部的にも洗練され、Open IOS-XE として新たに発表されています。 内部アーキテクチャについては、こちらのブログで詳しく解説されていますので、ぜひご覧ください。従来の操作感を保ったまま、内部データベースや機能群の分離を行い、コンテナによるアプリケーション ホスティングなどを段階的に実現しました。その他にも、YANG データモデルが本格的に実装され、いよいよ Netconf をはじ
概要 大規模なランサムウェア攻撃により、スペインの Telefonica、英国のNHS(国民保健サービス)、米国の FedEx といった各国の組織が影響を受けています。この攻撃を引き起こしているマルウェアは「WannaCry」として知られています。これはランサムウェアの亜種です。 WannaCry は TCP ポート 445 番(Server Message Block/SMB)を広範囲でスキャンする能力を備えており、ワームと同様の仕組みで拡散します。ホストを侵害してファイルを暗号化すると、Bitcoin による身代金の支払いを要求します。注意が必要なのは、ネットワーク内部を限定的にスキャンして拡散場所を特定する以上の能力を WannaCry が備えていることです。つまり、他の外部ホストで検出された脆弱性を突き、インターネット上で拡散する能力も備えています。 Talos が WannaCr
本ブログでは何度か、ネットワークの可視化や異常検知について投稿してきました。最終的に得られる効果は「セキュリティ対策」や「投資計画」や「インフラの見直し」などのアクションに繋がり、特にわかりにくいとされるネットワークが「わかりやすく」表現されるのは重要なことです。今回の記事では、それらを支えるネットワーク装置の進化について、深掘りしてみたいと思います。 さまざまなデータ=価値を提供するネットワーク さて、それらの基盤となるネットワークそのものが、いったいどれだけの内容を計測し、蓄積または出力できるのか、最終的にはそこがキーになります。特に専門的なプローブ(解析専用の箱)や特別な機能を使わずに、コストダウンしながらネットワークが蓄積するデータ種別を増やし、生み出す価値に貢献するか?が技術仕様やメーカーが努力する部分です。 「土管」から「かしこい面」へ 元々は通信事業者向け装置で長年使われてき
次世代データセンター ネットワークのコア テクノロジーとして、VXLAN(Virtual eXtensible LAN)への注目度が高まっています。今回は、VXLAN をおさらいしつつ、NX-OS でのコンフィグレーションを紹介したいと思います。 VXLAN の実装方式 仮想ネットワーク技術の代名詞的な存在である VXLAN には、ネットワークの構成手法として 3 つの方式があります。 VXLAN EVPN(Ethernet VPN)方式 OVSDB 方式 Multicast 方式 (1) VXLAN EVPN(RFC 7432 / draft-sd-l2vpn-evpn-overlay) この方式は、MP-BGP を用いてホストの IP アドレスや MAC アドレス、VNI、VTEP(VXLAN Tunnel End Point) peer 情報などを各 VTEP デバイス(NVE [N
ハイパーバイザーを利用した仮想マシン技術は、2000 年代後半から急速に広がり、仮想マシンの利用は普遍的なものになりました。その後、2010 年代になると、ハイパーバイザーを必要としない Linux コンテナ技術に注目が集まるようになり、最近では、様々なところでコンテナ技術が活用されるようになっています。 シスコでも早くから製品の中でコンテナ テクノロジーを利用していて、例えば IOS-XR 6.0 からはルータの管理用 LXC(Linux Container)と制御用 LXC に別れたアーキテクチャを採用していますし、ルータ上に独自コンテナを作ることができます。他にも、例えば、以下の用途でコンテナ技術が活用されています。 ルータのコントロールプレーンの分離(IOS-XR、NX-OS) アプリケーションのホスティング(IOS-XR、IOS-XE、NX-OS) Docker によるマイクロサ
お問い合わせ | フィードバック | このサイトについて | サイトマップ | ご利用条件 | 情報セキュリティ基本方針 | プライバシー | クッキーポリシー | 商標 免責事項 本サイトに情報を掲載する個人(管理人を含みます)は、シスコの社員である場合があります。本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、シスコの意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、シスコや他の関係者による推奨や表明を目的としたものではありません。このサイトは一般公開されています。機密情報はこのサイトに掲載しないでください。各利用者は、本Webサイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本Web サイトの利用に関するあらゆる責任からシスコを免責することに同意したものとします。ま
複数のサーバやクラウドの構成管理に使われる Ansible が 2.1 にアップデートされ、このバージョンから Network Automation がコア モジュールとして正式サポートされています。その一環として、Cisco IOS、Cisco IOS-XR、Cisco NXOS に関するモジュールも Ansible でサポートされるようになりました。この投稿では Cisco IOS に関するモジュールを試してみて、次回以降で具体的なユースケースをご紹介したいと思っています。 現状、IOSに関するモジュールは以下の3つです。 ios_command – Run arbitrary commands on ios devices. ios_config – Manage Cisco IOS configuration sections ios_template – Manage Cisco
クラウドデモ環境「Cisco dCloud」については、パートナー様向けのデモの環境としてだけではなく、ゲスト ユーザでも利用できる簡単な検証・ラボ環境としても便利に使えるインフラとして紹介してきました。この 8月、Cisco dCloud はさらに大きな進化をしました。 dCloud とは? 簡単に dCloud を復習します。 dCloud は、 常に最新のソリューションを利用できる環境を提供します。cisco.com のアカウントさえあれば、すでにインストールおよび初期設定された状態で、デモ シナリオを読みながらデモや検証を進めることができるのです。これにより、学習やデモ環境のためのセットアップ時間を大幅に短縮することができます。 dCloud を利用するのに必要な cisco.com のアカウントは誰でも取得できるので、ある担当者が学習したことを別の担当者に伝えるというナレッジ ト
ベテラン SE であれジュニア SE であれ、IT エンジニアであれば誰しも、IT 的「遊び心」を持っていることでしょう。つまり、「やってみて楽しい」「動いた!」「こんなことできるの!?」といった感動とともに、手を動かして“遊 ぶ”ことに楽しみを見いだし、熱中した経験があるはずです。 ちょっとした動作検証のつもりが深夜まで熱中したり、うっかり休日を潰してしまったり…。そして、新たな発見を人に話したくなるし、より多くの人で面白みが共有されて盛り上がれば、うれしくなる…。そんな中から技術的な課題解決策やテクニック(小ネタ)が生まれ、実際に業務にも結びつけば、こんなに楽しいことはありません。 自宅サーバを構築・運用したり、業務用ルータを家庭用途に使ったり、家族の IP トラフィックをこっそり監視・分析したりと、エンジニアは自宅でも IT 的娯楽を楽しんでいるものです。最近では Cisco Sta
前回までのブログでは、シスコでの気づきを概略的に紹介してきましたが、今回は、私が以前まで働いていた京都府(地方自治体)とシスコとの働き方の違いについて一度整理し、どういった気づきや意識の変化があったのかを総括的に振り返ってみたいと思います。 シスコに来て、4 か月になりますが、言葉では表現しきれないほど、多くの気づきがありました。とにかく今までの働き方に無駄が多かったこと、そして働き方、働く環境を変えること(働き方改革)の重要性を強く感じました。上記で紹介したような、今まで何気なく行っていた一つ一つの仕事のやり方に無駄があり、いかに時間コストを意識した働き方ができていないかということに気づかされました。 もちろん、今までの京都府(地方自治体)での働き方や働く環境を否定するわけではありませんが、シスコのワークスタイルに触れて、「京都府ももっとこういった部分は柔軟にできるはず」とか、「こういう
ルータ、スイッチで構成されたネットワーク基盤上を流れるトラフィックのパターンを「フロー」として識別し、フローごとに流量を測定する NetFlow という技術があります。以前はハイエンド機種での実装が中心でしたが、近年では、Cisco 800 シリーズのようなローエンド ルータや、Cisco Catalyst 3850/3650 シリーズあるいは Catalyst 2960-X シリーズ(一部機能制限あり)といった固定構成型の LAN スイッチでも、活用できるようになってきています。 パケットサンプリングより詳細、パケットキャプチャより軽量 NetFlow は、あらかじめ装置内部でフローキャッシュを作成し、余分な情報は取り除かれた状態でバイナリで出力されるため、パケットキャプチャ技術と比較すると解析もしやすく非常に軽量という特長があります。その一方で、全パケットを対象にキャッシュ化されること
先日の Cisco Live 2016 Berlin で IOS XE における Open Service Container が発表されました。これから数回にわたって、このOpen Service Containerについて紹介したいと思います。 Cisco ASR 1000、ISR 4000、CSR 1000V、Catalyst プラットフォーム等で採用される IOS XE は、ベース OS として Linux を利用しています。そして、ネットワーク機能を提供する IOSd(IOSデーモン)は Linux 上で Linux プロセスとして動作しています。こういったアーキテクチャのおかげで、ルータやスイッチのハードウェア資源(CPU、メモリ)を使って、KVM(Kernel-based Virtual Machine)もしくは LXC(Linux Containers)上に別のアプリケーシ
アーキテクチャ ネットワーク アーキテクチャ考 (16) 「モジュラー性・オープン性とパッケージング、そしてダイクストラ」 これまで私は至るところで、「仮想化アーキテクチャでは、モジュラー性・オープン性が重要。垂直統合してしまったら意味が無い。」と述べてきました。 今でもその考えは変わっていません。コモディティ化した汎用ハードウェアと仮想化アーキテクチャで実現するソフトウェア中心のシステムは、新たなサービスの柔軟かつ迅速な展開、小規模スタートや実験的展開、顧客の細かい要求に応じたテーラーメイド サービスなどに、大きな価値を発揮します。これらは、これまで周到な設備計画が必要だったハードウェア中心のシステムでは実現できなかったことです。しかし、その機能の性能最適化をしたければ、目的に特化したハードウェア システムの方が、コスト、スペース、電力等、あらゆる面で適しています。既に機能が固定化されて
SDN/NFVは、アーキテクチャ変遷の一つの可能性です。通信事業者は、それまでのハードウェアを中心とした基盤設備的なアーキテクチャから、ソフトウェアを中心としたより柔軟で迅速なアーキテクチャにシフトしようとしています。そのため、「アーキテクチャ変遷」を大きなテーマの一つとしているこのBlogでも、SDNやNFVについてのいくつかの、総論的な話題を取り上げてきました。 しかしこの辺でそろそろ一旦振り返り、次のステップに踏み出したいと思います。そこで今回は、振り返りのきっかけになったことと、今後考察して行きたいことを書きます。 Network Programmabilityと宣言的プログラミング 対立する価値の統合 White Box SwitchとForwardingのコモディティ化 Traffic Modelの変化とこれからの可能性 1. Network Programmabilityと宣
前回の投稿では、仮想化における運用面の課題を書きました。今回は、もう 1 つの大きな課題である性能面を検討します。 1) 仮想化環境における転送性能最適化について 仮想化アーキテクチャのインフラストラクチャとなるサーバは CPU に特化したハードウェアであるため、当然、NPU(Network Processing Unit)や ASIC(Application Specific Integrated Circuit)に比べると転送性能は低いです。さらに、ハードウェアで行う割り込みや I/O などの各種処理を仮想化レイヤにてエミュレーションする必要があるため、オーバヘッドが大きくなります。 これまで、データセンターの仮想化においては、転送性能よりも柔軟性やスケーリングといった効用の方が大きく上廻っていたため、あまり転送性能の最適化は問題視されてこなかったのだと思います。しかし、通信事業者の
仮想化アーキテクチャの周辺は日々進化していて、落ち着く暇がありません。この春 Cisco は、通信事業者向けの、仮想化環境における Orchestration Layer アーキテクチャとして、ESP(Evolved Service Platform)を発表しました。しかしこれは製品でもなくソリューションでもなく、概念的フレームワークであるため、現場は扱いに困ります。この概念的フレームワーク、深く読めば、ACI(Application Centric Infrastructure)や InterCloud などとも共通する遠大な構想に裏付けられているのですが、いざ、このフレームワークを見せられても、それだけでは何も言っていない。具体的な解を提供しないといけないときに、遠大な構想などを持ち出したら、お客様からは話をはぐらかしているように捉えられてしまいます。この辺が最近感じている難しさであり
最近、「オーケストレーション」という言葉を耳にする機会が増えました。仮想化された要素を構成し、モニターし、柔軟なサービス提供に役立てるために、オーケストレーションは重要な役割を果たします。ETSI NFV(Network Function Virtualization)アーキテクチャを見ても、End-to-End Reference Architecture の大きな部分を、「Management and Orchestration」が占めています。(NFV 参照アーキテクチャについては、以前のエントリをご参照ください。)そこでは、Management and Orchestration の最上位に「Orchestrator」というエンティティが位置づけられていますが、では Orchestration、そして Orchestrator って一体何なのでしょう。本日は、オーケストレーションの
シスコのサンノゼにあるオフィスには社内保育園があることは、以前から聞いていました。しかしながら、実際に海外出張に同行させて利用したという話は聞いたことがありませんでした。ある時、息子(6才)に「アメリカに行ってみたい?」と聞いてみたところ「行きたい」との返事。そこで、実際に息子を連れて出張に行ってきましたので、その様子をレポートします。 シスコの本社があるサンノゼのタスマン通りの両側には、数十棟のシスコ オフィスが並んでいます。多くの従業員が働くこのエリアに、2ヶ所の社内保育園が設置されています。いずれも民間の保育事業提供者によって運営されていますが、利用できるのはシスコの従業員であり、セキュリティもシスコ社内と同じものが適用されています。そこには毎日通う子供たちもいますが、それ以外にも臨時で預かってもらう一時保育(英語ではBackup care)のプログラムも用意されており、年間20日程
日本時刻で2月5日水曜日の早朝(6時15分)、「Hydrogen Released」と本文内に大きく書かれた OpenDaylight のアナウンスメールが届きました。当初は去年の12月の早い時期にリリース予定だったのですが、少し遅れて正式にダウンロードと利用が可能になりました。2013年2月に OpenDaylight のプロジェクト メンバーが Santa Clara Marriot ホテルに集まってキックオフミーティングが開催されてから約一年、最初の成果がリリースされました。 Cisco Japan Blog の中でも、SDN、NFV、仮想化全般に関する記事がたくさん取り上げられていますが、OpenDaylight について触れられることがなかったので、正式リリースを祝して触れてみたいと思います。 SDN とコントローラ市場の背景 さて、すでに Software Defined Ne
ここ数年、データセンターのネットワーク インフラの進化には目覚ましいものがあります。なかでも、レイヤ2 ネットワークの技術は著しく進歩しており、ネットワークの大規模化に伴い、スパニングツリー プロトコル(STP)に代わるネットワーク設計が次々と登場しています。 STP をベースの L2 ネットワーク設計に携わったことのあるネットワーク エンジニアの方であれば誰でも、どこにブロッキング ポートを配置するか、ファームウェアの更新やスイッチの交換作業時には人的な作業ミスによってループが発生することがないように細心の注意を払う、といった経験があるはずです。しかし自分のネットワーク設計の経験からも STP だけに頼ったレイヤ2 大規模ネットワークは正直作りたくないと考えています。 それはいまや世の中はクラウド時代となり、サーバは仮想化され、インフラ リソースは柔軟性(仮想マシンの移動への対応)、迅速
細々と、ネットワークアーキテクチャに関する連載を続けています。今は希有のアーキテクチャ揺籃期ですから、書いておきたいことがどんどん溜まってきます!が、筆無精、遅筆のためなかなか進みません。前回、NFV(Network Function Virtualization; ネットワーク機能仮想化)を取り上げましたが、今回はその続きを書きます。 NFVにおける-ilities この連載の初回(序論)で、「あるシステムの性質や能力(-ilities)を規定するのはそのシステムのアーキテクチャである」ということを書きました。(特性や能力を表す英単語は Availability、Scalability、Flexibility、Security、Extensibility、Elasticity… のように -ility という語尾がつくことが多いことから、それらが「-ilities」 と総称されます。)
略を説明しますと、HT は、阪神タイガースではなくハイパー スレッディング。EIST は、Enhanced Intel SpeedStep Technology。TB はターボ ブーストです。上表の値はあくまでも参考値であり、設置場所などの動作環境や搭載している HDD やアダプターなどのコンポーネント、その他条件で異なります。目安としてご覧ください。なお、これらの項目以外は同一です。 まず C1E/C6。C1E/C6 は、クルマに例えるならアイドリングストップです。CPU がアイドル状態の時に C-State を変化させて CPU を眠らせ電力消費を削減します。C1E と C6 は眠りの深さの違い(C6 の方が深い)と考えたらいいと思います。より節電を意識する場合は有効にするといいのですが、立ち上がりに若干のタイムラグ(遅れ)があるので、パフォーマンス最優先の場合は無効にするのがいいでし
前回のブログ記事では「アーキテクチャ変遷」の一例として SDN(Software Defined Networking)を取り上げました。SDN についてはまだまだ書かなくてはならないことが残っていますが、それらはひとまず今後に廻し、今回は NFV(Network Function Virtualization)を取り上げます。 NFVとは NFV とは Network Function Virtualization の略で、「ネットワーク機能の仮想化」を意味します。欧州電気通信標準化機構(ETSI, European Telecommunications Standards Institute)(*) が NFV ISG (Industry Specification Group) を立ち上げ、米国や日本などヨーロッパ以外の通信事業者も加わって積極的に活動を行っているため、今、SDN と
次のページ
このページを最初にブックマークしてみませんか?
『gblogs.cisco.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く