IPv6アドレススキャン攻撃:Geekなぺーじ
IPv4では、アドレススキャン攻撃やポートスキャン攻撃は日常的に行われています。 ファイアウォールなしの状態でグローバルIPv4アドレスに接続していれば、すぐに攻撃を観測できます。 IPv6でもアドレススキャン攻撃は発生しています。私の家のネットワークでも、IPv6でのアドレススキャン狙いと推測されるトラフィックを簡単に観測できました。 ただ、いまのところ、私の家では、実際に利用しているIPv6アドレスを外部から発見できているようなスキャンの形跡を発見できておらず、主にステートフルDHCPv6や手動設定でのIPv6アドレスを探しているように見えました。 やはり、IPv4と比べると、IPv6の方がIPv6アドレススキャン攻撃の難易度は高いのだろうと思います。 ということで、IPv6でのアドレススキャン攻撃や、その他方法によって、稼働しているIPv6アドレスをどのように探すのかに関して解説して
MACアドレスの再利用は、みんなが思っているよりもはるかに一般的:Geekなぺーじ
MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF
3.0.0.0/8がAmazonに:Geekなぺーじ
3.0.0.0/8がAmazonに割り当てされたIPv4アドレスに変わっています(via Hacker News)。 表面的に見えているのは、IPv4アドレスの移転ですが、恐らく、IPv4アドレス売買によってAmazonへと登録が移転されたものだと思われます。 このIPv4アドレス移転により、AmazonはIPv4アドレス空間全体の1/256を新たに使えるようになります。 3.0.0.0/8は、以前は、GE(General Electric Company)に割り当てられていました。 しかし、最近1年ほどで4回に分けてAmazonへと3.0.0.0/8が移転されています。 ARINのwhoisを見ると、3.0.0.0/8は、3.0.0.0/9と3.128.0.0/9に分けれて登録されています。 両方とも、組織は「Amazon Technologies Inc. (AT-88-Z) 」とあり
すごいIPv6本を無料配布！:Geekなぺーじ
2021年12月20日追記：第2版できました！ IPv6を解説した「プロフェッショナルIPv6」をラムダノート株式会社から出版しました。 初版は456ページになりました。紙版の厚さは23mmになる予定です。 現時点で、IPv6に関して世界で最もまとまっているIPv6本であると個人的に考えています。 「プロフェッショナルIPv6」は、株式会社日本レジストリサービス様、BBIX株式会社様、NTTコミュニケーションズ株式会社様、日本ネットワークイネイブラー株式会社様、クラウドファンディング(「すごい技術書を一緒に作ろう。」という企画です)でのみなさまによるサポートにより実現しました。 IPv6に関する技術情報を広く公開するという趣旨に賛同いただき、本書の執筆と制作、公開にあたって多大な協賛をいただきました。ありがとうございます！！！ 「プロフェッショナルIPv6」は、通常の書籍として5000円で
アカマイの新たなバックボーンネットワーク:Geekなぺーじ
RIPE 75のライトニングトークで、アカマイが、自社トラフィックを運ぶための専用バックボーンネットワークを構築していることを発表しました。 Christian Kaufmann - ICN Akamai 発表資料(PDF) アカマイは、ユーザに近いところにCDN用のキャッシュサーバを置くために、世界各地に拠点を構築しています。 そういった拠点は、たとえば、ISPの中に構築されたりしています。 これまで、アカマイは拠点間の通信にはパブリックなインターネットを利用していました。 発表では、個々に孤立していたことを示すために各拠点を「島 (islands)」と表現しています(islandsという表現は、RFC等でも割と良く使われます)。 世界中の様々なAS内に拠点を築き、その拠点間トラフィックもパブリックなインターネットを利用していたことは、アカマイの非常に大きな特徴であったとも言えます。 し
IPv6アドレスのテキスト表記 - RFC 4291とRFC 5952:Geekなぺーじ
コンピュータの中で扱うときにはIPv6アドレスは128ビットの情報として扱われますが、その128ビットを人間が理解するために文字列で表記することもあります。 IPv4の場合は、「192.0.2.100」のように8ビットごとに「.（ドット）」で区切るドット付き十進表記 (dotted decimal notation)で表現されますが、IPv6の場合は16ビットごとに「2001:db8:11aa:22bb:33cc:44dd:55ee:66ff」のように「:（コロン）」区切りの十六進法で表現されます。 IPv6表記には省略を行うことを前提とした表記ルールがあります。 IPv6アドレスをテキストでそのまま全部書くと長くなりがちなためです。 IPv6の表記に関して注意が必要なのが、2006年に発行されたRFC 4291定義されたIPv6表記法では同じIPv6アドレスに対して複数の表記方法が存在す
奇妙なIPv4アドレス表記:Geekなぺーじ
IPv4アドレス表記といえば、ほとんどの人が「ドット付き十進表記 (dotted decimal notation)」による記述を連想すると思います。 しかし、ドット付き十進表記ではない奇妙な表記が使えることもあります。 機種依存するものの、たとえば、127.0.0.1の代わりに、127.1、0x7f.0x1、0177.0x1、2130706433を使うこともできます。 ドット付き十進表記ではなく、単なる十進数表記、16進数表記、8進数表記、それらが混ざったドット付き表記なども使えてしまうのです。 Webブラウザによっては、上記表記をそのまま解釈します。Webブラウザのアドレスバーに、変なIPv4アドレス表記を入れると、次のようになる場合もあります。 これは、getaddrinfo()、gethostbyname()、inet_aton()などが、上記表記をIPv4アドレスとして受け入れて
Google誤設定によるインターネット障害とBGPルータのメモリ問題:Geekなぺーじ
2017年8月25日の大規模インターネット障害の続きです。 Googleの誤設定によってBGPルータの性能が低下したかも知れないという話の背景を紹介します。 BGPで大量の経路を受け取ってしまうと動作が不安定になるBGPルータが存在するのは、BGPルータに搭載されているTCAM(Ternary Content-Addressable Memory)というメモリに関連します。フルルートが、BGPルータに搭載されたTCAMの容量を超える規模になってしまったので、著しくBGPルータの性能が落ちるなどしてネットワークが不安定になるというものです。 TCAMは、CAM(Content-Addressable Memory)と呼ばれるメモリの一種です。メモリといえば、パソコンなどで利用されるDRAM(Dynamic Random Access Memory)を思い浮かべる方々が多いと思いますが、DRA
GoogleがBGPでリークした情報の中身を見てみよう:Geekなぺーじ
2017年8月25日の大規模インターネット障害の続きです。 オレゴン大学がRouteViewsというサイトで、BGPフルルート情報を公開しています。 今回、Googleがリークしてしまった経路情報をRouteViewsで確認することができます。 http://archive.routeviews.org/bgpdata/2017.08/UPDATES/updates.20170825.0315.bz2 RouteViewsで公開されているデータは、MRTというフォーマット(RFC 6396参照)で保存されているので、何らかのツールで解析する必要があります。 今回は、RIPE NCCが管理しているbgpdumpというツールを使いました。 RouteViewsのデータから、Googleによる誤設定データを最初に観測できるのは、3時17分37秒(UTC)のところです。 Verizon(AS 70
Geekなぺーじ : BGPを解説してみた
2009年2月17日にインターネットが壊れました。 今回の障害はチェコのISPが出してしまった経路情報によって世界各地のルータが機能不全に陥るという事態へと発展したようです。 先日の記事で、流れた経路情報の詳細などを紹介しましたが、「BGPとは何か？」や「そもそもルーティングとは何か？」を知らなければ何を言っているのか意味不明な解説記事だったと思います。 そこで、今回は「インターネットの仕組み」そのものを解説しながら「何が起きたか？」を解説しようと思います。 対象としている読者は、IT系の知識はあるがIPによる通信そのものに関しての知識は無いエンジニアです。 なお、本来ならば正確さを確保するために解説すべきである細かい点は、あえて解説しないようにしているのでご注意下さい。 そもそもインターネットとは何か？ まず、最初に「インターネットとは何か？」を説明したいと思います。 Inter-net
2017年8月25日の大規模インターネット障害:Geekなぺーじ
先週の金曜日、Googleが誤った経路をインターネットに流したことによって、大規模な通信障害が発生しました。 大きな影響を受けたのが日本のOCNとKDDIだったとされていますが、様々な事業者が影響を受けたようです。 ネットワーク障害 グーグルが設定誤りで謝罪 グーグルが謝罪 大規模ネット障害、装置の誤操作が原因 ニュース解説 - 米グーグルの設定ミス、なぜ日本の大規模ネット障害を引き起こしたのか？：ITpro BGP leak causing Internet outages in Japan and beyond 8月25日に発生した大規模通信障害をまとめてみた 今回の障害は、世界中の組織とBGP(Border Gateway Protocol)で繋がっている巨大なネットワークを持つ「Googleだからこそ」の事例と言えそうです。 ここでは、その理由を紹介します。 ネットワークのネットワ
IPv6基本仕様のRFC 2460が廃止:Geekなぺーじ
IPv6の基本仕様を規定したRFC 2460が廃止されました。RFC 2460が発行されたのは1998年なので、IPv6の基本仕様を規定したRFCが廃止されるのは約19年間ぶり、2回目の廃止です。今後は、RFC 2460を廃止するRFC 8200がIPv6の基本仕様を規定したRFCになります。 Internet Protocol, Version 6 (IPv6) Specification 今後、IPv6の基本仕様に関して勉強、参照、紹介などをする場合には、今回廃止されたRFC 2460ではなく、RFC 8200を利用する必要があります。 RFC 8200が発行されるまでに行われてた議論や、6月時点におけるIETFでの議論に関しては、先月、NTTコミュニケーションズ株式会社の西塚要さんが書かれた記事が素晴らしいので、是非そちらをごらんください。 Internet Watch: 20歳を超
「ひとりで何でもできるエンジニア」は勝手に育つ:Geekなぺーじ
「スタートアップベンチャーはスーパーエンジニアを求めるけどエンジニア界隈と起業家界隈で想像しているスーパーエンジニアの定義が違う件」という記事が話題です。 その中で、「「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」」として、以下のように書かれています。 「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」 起業家の方が知らない側面として 現在バリバリ活躍しているエンジニアのほとんどが得意領域を持っていて それ以外の分野については出来る人であっても「平均点以上」ぐらいの活躍しか出来ないということです。 そして優秀なエンジニアの方はそのことをよくわかっています。 たまに化け物みたいな化け物がいて物理からインフラからアプリケーションからUI/UX ネイティブアプリ開発からwebマーケティングに資産管理まで全部出来ちゃう人もいますが その人を望む事は「年収1000万の
Real World HTTPはスゴ本:Geekなぺーじ
Real World HTTPの献本ありがとうございます。Webトラフィックを運ぶプロトコルとして利用されているHTTPの解説書として、HTTP 1.0、HTTP 1.1、HTTP 2.0のプロトコルだけではなく、ブラウザやサーバが何を行っているのかを含めて解説しています。 Real World HTTPの凄いところは、過去の経緯をふまえつつ、HTTPという軸で実際に使われている部分とそうでない部分を明確にしつつ解説されている点です。 しかも、範囲は非常に広いです。HTTPと関連する話として、たとえば、TLS、WebRTC、RSS、RDF、OGP、JSON、GeoLocation、RESTful APIなども解説されていますし、勘違いが発生しやすいno-cacheやno-storeなどに関しても解説されています。 すべての項目に関して詳細に解説されているわけではないものの、それぞれかなりし
LINEも「ギガが減る」を観測していた:Geekなぺーじ
今年1月に開催されたJANOG 39にて、LINE Corporationの三枝氏が「LINEサービスを運用して見えてきた課題」というタイトルで発表を行っています。 その中で、「月間平均Response Timeとの乖離」というタイトルで、以下のスライドがあります。 この図では、日本、タイ、台湾のレスポンスタイムが示されていますが、「日本は月末にResponse Timeが悪化していく傾向がある」とされています。 Twitter、Spotify、JPNAP(インターネットマルチフィード)での「ギガが減る」を昨日から紹介していますが、LINEでも同様の現象を観測しています。 やはり日本のインターネットトラフィックの最近のトレンドとして、月末に向けて通信品質が悪化するという傾向があるようです。 参考 Twitter Loves Japan Spotifyの日本インフラ 日本のインターネットも月
なぜIPv6とIPv4の名前解決は別々に行なわれるのか？:Geekなぺーじ
www.example.comなどの「名前」に対応するIPアドレスをDNSサーバに問い合わせるとき、IPv4とIPv6に関する名前解決を単一の問い合わせで行うことはできません。そのため、DNSサーバに対して、IPv4に関する問い合わせと、IPv6に関する問い合わせを、別々に2度行う必要があります。 これは、DNSサーバに対しての問い合わせが単一のレコードに対してしか行えないためです。 Aレコード（IPv4アドレス）の問い合わせと、AAAAレコード（IPv6アドレス）の問い合わせは、それぞれ別々のレコードに対する問い合わせなので、両方を同時には行えないのです。 ただし、「IPv4とIPv6に関するDNSサーバへの問い合わせは別々に行わなければならない」というのは、事実上の話であって、「仕様上そうなっている」と言い切れるのかどうかは微妙かも知れません。 DNSに関するRFCは、悪名高いRFC
RFCの正規文書がXMLに:Geekなぺーじ
インターネットに関連するプロトコルなどを規定するRFC(Request For Comments)の正規文書のフォーマットが、これまでのplain-text ASCIIからXMLへと変わります。そのためのRFCが、RFC 7990 - RFC 7998として策定されました。 RFC 7990 RFC Format Framework RFC 7991 The "xml2rfc" Version 3 Vocabulary RFC 7992 HTML Format for RFCs RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs RFC 7994 Requirements for Plain-Text RFCs RFC 7995 PDF Format for RFCs RFC 7996 SVG Drawings for R
「すごいエンジニア」は凄いエンジニアになることを目指してないかも:Geekなぺーじ
「すごいエンジニア」が一部界隈で話題になっています。 「すごいエンジニア」が目指すもの 私がこれまでに「この人は凄いなぁ」とか「この人には一生かなわないなぁ」と思った「すごいエンジニア」は、次のようなイメージがあります。(ここでは、元記事の文脈に沿って「エンジニア」をという単語を主に「IT系の」として表現します。) 何かに没頭する能力が高い。 好奇心旺盛。 技術に関連する話題で議論している時、すごく楽しそうに話をする。 飲み会で語り合う話題は、基本的に技術に関連する話か興味を持っている何かに関連する話を好む。無難な世間話でジャブを打ち合うような飲み会は苦手。 技術に関連する資料を読むのが好き。勉強しているという意識はなく、単に楽しいから調べている。もしくは、調べ始めたら色々と気になって深堀りした結果として知識が増えただけ。 もともと英語が得意、もしくはIT関連の調べ物や発表等で必要だったか
LACNIC、IPv4アドレス在庫枯渇の最終段階入りを発表:Geekなぺーじ
LACNIC(The Internet Addresses Registry for Latin America and the Caribbean)が、IPv4アドレス在庫枯渇の最終段階(Phase 3)に入ったことを発表しました。 LACNIC Announces the Start of the Final Phase of IPv4 Exhaustion LACNICは、4段階の「IPv4枯渇フェーズ(IPv4 Depletion Phase)」を定義していました。 IPv4アドレス在庫が/9よりも多い枯渇前の段階をPhase 0、/9以下になった状態をPhase 1、/10以下になった状態をPhase 2、/11以下になった最終段階をPhase 3としています(参考)。 今回、LACNICのIPv4アドレス在庫が/11以下となるPhase 3になったことで、今後は過去にIPv4ア
IPv6でセキュリティがスカスカになってませんか？:Geekなぺーじ
さくらインターネットが、VPSの標準OSイメージでIPv6設定デフォルト無効化を発表しました。 さくらのVPS、標準OSイメージの仕様変更のご連絡 (IPv6設定デフォルト無効化) 発表では、以下のようにあります。 初期状態のおけるセキュリティ向上のため、以下のOSについてIPv6のデフォルト無効化を実施いたします。 有効化手順につきましては、ヘルプページをご用意しておりますのでそちらをご確認ください。 個人的には、IPv6が普及しつつある現状に対する一歩先を行く対応だと思いました。 流石だなぁと。 気づかずに放置されるIPv6セキュリティ 現段階では、IPv6環境でのセキュリティが放置されがちです。 IPv4環境とIPv6環境のセキュリティの差に関して述べられている発表が昨年ありました。 ITU/APNIC/MICT IPv6 Security Workshop : Securing t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
