著者アーカイブ takahashi

takahashi 著者:takahashi

Gitバンドルのbashを使ってWindowsのcmdをUnixっぽくしてみる

クライアントマシンのOSはもっぱらWindowsを使うことがほとんどなのですが、サーバーはLinux/Unix系OSを使用することが多いです。
現行Windowsでは、OSに必要な操作はほぼGUIで完結するので、CUIで触るのはLinux系OSがほとんどでした。

ところが、開発やサーバー管理などをしているとWindowsを使っていてもCUIに頼らないといけない場面というのがでてきます。
普段使い慣れているLinuxとかなり使い勝手の違うWindowsのシェルは、いざ触ってみると戸惑うことが多いです。
また、Linuxは未だにCUIで使われる機会がおおいためか、CUIベースのツールはかなり充実しています。これらのツールは、さくっとサーバーの状態を確認したいときに非常に便利なのですが、Windowsでは標準で搭載されておらず、インストールもちょっと手間がかかるものも多いです。

かといって、何か操作する度にLinuxが動いているマシンにログインするのはちょっと面倒です。
そこで、Unix/Linux系で使えるポピュラーな機能の一部をWindowsに導入できないかなーと考えていろいろ調べていました。

VMで動かすとファイルのやりとりとかいろいろ不便。
かといってCygwinやWSLみたいにガッツリUnixライクな環境までは必要ない。

という方向けの、Windows上でネイティブに動く、簡単に”UNIXっぽい操作環境”を作る方法を紹介します。

実は、あるツールを入れていると、簡単にWindowsのコマンドプロンプトをUnixっぽくできます。
バージョン管理ツールのGitです。

実はGitをインストールすると、Unix/Linuxで非常によく使われるシェル”bash”のWindows版がついてきます。

今回はこれを利用します。
Gitのインストールが完了していれば

C:\Program Files\Git\bin

あたりのフォルダの中に、
“bash.exe”
というファイル名でインストールされているかと思います。
これをコマンドプロンプト上で開けるように、環境変数内の”Path”に、C:\Program Files\Git\binを追加しておきます。


スタートから”環境変数”と検索して”環境変数を編集”をクリックします。


“ユーザー環境変数”内のPathを選択し、”編集”をクリック


“新規”をクリックして、

C:\Program Files\Git\bin

を追加します。

これで準備完了。
コマンドプロントで

bash

と入力すると、なんとWindows上のcmdでbashが使えてしまいます。(※WSLとコマンド名がかぶってしまったため、別の名前で起動するように書き換えています。)


lsやcat tail grep mv cp などの基本的なコマンドはこのbash.exeを起動するだけで使うことができます。

ちなみに、Windowsにインストールされているコマンドもbash上から実行が可能です。

それ以外の基本的なコマンドは、以前紹介したchocolateryでインストールすれば、そのままbash上でも使えます。
なお、bash起動時のaliasの設定などは、LinuxやUnixと同様に、自分のユーザーフォルダに”.bashrc”ファイルを作成して記述すれば読み込んでくれます。

cmdやPowerShellがちょっと使いづらいなーと感じたときに、bashに切り替えるだけで、操作がかなりしやすくなって便利です。
LinuxerやUnixerなWindowsユーザーの皆さんは是非試してみてはいかがでしょうか?

takahashi 著者:takahashi

Torの仕組み

よくハッカーが出てくる映画で、「クソッ、複数の海外サーバーを経由されていてアクセス元が特定できない!!!」なんて展開がよく出てくるかと思います。
実際のところ、現実でそんなことが可能なのかと思ってしまいますが、実際に複数のノードを経由することで自分のアクセス元情報を隠して相手サーバーに接続することができる仕組みが存在します。
しかも、それを利用するのに映画に出てくるハッカーのような特別な知識は必要ありません。誰でも利用できます。

この仕組みは”Tor”とよばれています。
名前を聞いたことがある方は多いのではないでしょうか。

Torの仕組みはちょっと面白いです。
まず、Torを使ったネットワークでは、デフォルトで必ず3つのノードを経由するようになっています。

匿名通信「Tor」はどういう仕組みなのか分かりやすく解説 – Gigazine

◆リレーのタイプ
デフォルトではTorは3つのリレーを経由することになっています。この3つのリレーはそれぞれ特定の役割を担っています。

・ガードリレー(Guard Relay)
Torネットワークの入り口部分にあるリレーが「エントリー/ガード リレー」です。安定して高帯域を持つと示されたリレーがガードリレーに選ばれます。

・中間リレー(Middle Relay)
「中間リレー」はガードリレーから出口リレーへトラフィックを中継するリレーです。このリレーを配置することで、ガードリレーと出口リレーがお互いの情報を得られないようにしています。

・出口リレー(Exit Relay)
「出口リレー」はTorネットワークの終端にあるもので、その名の通り通信の出口となる部分です。出口リレーが最終的な目的地にトラフィックを送ることになります。

以下の図はTorネットワークでの経路を簡単に示したもの。ユーザー(Client)はTorネットワークの入り口となるガードリレーから中間リレーを経由し出口リレーに到着し、最終的な目的地となるウェブサイトなどに到着するというわけ。もちろんこの経路は複数あるリレーの組合わせなので、一定時間ごとに変更されるようになっています。

ただ、これだけではまだ完全に安全とは言えません。
各ノードに、どのIPのユーザーのデータがどこへルーティングされたかが各ノードに記録される可能性があるためです。

そこで、TorはTorネットワークへ情報を送信する前にデータを暗号化し、さらにノードを経由するごとに多重に暗号化をかけていくことで、どのネットワークからアクセスされたのかを、最終的に把握できないようにしています。
これにより、Torネットワークでは、提供される各中継ノードが信頼できなくてもセキュア性を保てる設計になっています。


Gigazineより引用
一見するとただのアンダーグランドなツールに見えてしまいますが、なぜこんな仕組みが存在しているのでしょうか。
そこには社会的な理由があります。

それは、インターネット上の自由な表現を政治的な検閲や弾圧から守る必要があるからです。
日本に住んでいるとピンとこないですが、国によっては、インターネット上での情報取得や、発言を検閲し、意図的に制限、場合によっては懲罰を行う国があります。
しかし、インターネットは本来的に自由な空間です。誰でも自分の好きな意見を発信し、好きなように表現をすることができます。
そのインターネットに対して、言論の統制を目的とした介入を行う国が、残念ながら出てきてしまいました。

自由な表現を保護するため。自由な発言しても迫害を受けないように保護するため。
Torは自由な思想が認められない国々にいる人々の人権保護に、一役買っているというわけです。

どんな技術も、使い方次第では薬にもなるし、毒にもなります。そしてそれは強力であればあるほど影響力も大きくなります。
Torが強力なのは必然でした。”権力”という、強力な圧力に勝てるだけの物が必要だったからです。

願わくば、Torのような仕組みに頼らなくてもインターネットを安心して自由に楽しめるような世の中になってほしいものですが、現状を見るとその日が来るのはまだまだ先のことなのかもしれません。

takahashi 著者:takahashi

世界中のサイバー攻撃を地図上に可視化しているサイト

サイバー攻撃という、かつては映画にしか出てこなかったようなワードが当たり前のように聞こえてくるようになってしまった昨今。
そんなサイバー攻撃の状況を、地図上にわかりやすく可視化するサービスを提供しているところがあります。

今回は、個人的に分かりやすいと思ったサイトをいつくか紹介します。

NORSE

NORSEは運営元のNORSE社が世界各地に設置したハニーポット(一見脆弱性対策されていない、攻撃者が攻撃しやすいように見せかけわざと攻撃させることでその攻撃手法を解析する目的で設置されるホスト)から受け取ったデータを解析し、発信元と発信先、使用プロトコルを地図上に可視化してリアルタイムに表示しているサイトです。

プロトコルごとに色分けされており、視覚効果もビームを打った/打たれたような表現になっていて非常に分かりやすいです。
見ていると常に何かしらドンパチやっている様子がうかがえますが、まれに大量のトラフィックが見えることがあり、”あっ、集中攻撃されているな…”というのがよくわかるときもあります。

CYBERTHREAT REAL-TIME MAP(カスペルスキー)

有名なセキュリティソフトベンダーであるカスペルスキーが運営しているサイバー攻撃可視化サイトです。
こちらはカスペルスキー社製の各製品から報告された脅威の統計をリアルタイムで表示しているようです。

セキュリティソフトが検知する情報なので、ネットワーク経由の攻撃だけでなく、ウイルスやスパイウェア、脆弱性の検出なども表示されます。

Digital Attack Map(Google)

こちらはGoogle Ideas提供の攻撃可視化サイト。
内容としてはDDoS攻撃元の発信元と発信先を可視化しています。

自分が確認した時点でも、常時攻撃のトラフィックが表示されていて、ちょっと衝撃的です。
ただ、どういった仕組みで取得されているのかがよくわからかったので、何を基準にしてDDoSと普通の通信を見分けているのかは不明です。
もしかすると、一部通常の通信も混じっているかもしれませんね。

ちなみに、UI的にはちょっと見づらいですが、日本でもNICTという団体が可視化サービスを公開しているようです。
NICTERWEB – NICT

見ていると世界中のサイバー攻撃の規模の大きさにただただ驚くばかりです。
もし自分がこれらの攻撃の対象になってしまったら…そんな最悪な事態を想定しながら、できるところから対策していきたいですね。

takahashi 著者:takahashi

昔のMac OS(System 7)やWindows 3.xがブラウザ上で動作するサイト

僕は昔からちょっとしたOSマニア(といってもとりあえず一通り触りたいだけ)で、Windowsは勿論、MacOSとLinuxディストリのいくつか、ChromeOS、iOS、Andoridと現代のいろいろなOSは一通り触れてきました。
現行のどのOSでも、設計思想は違えど非常に使いやすいUI/UXをもつGUIを供えており、どれか一つのOSに振れたことがある人であれば、他のOSをさわっても基本操作はだいたい一目でわかるぐらいに簡単に操作できるようになっています。

各OSの設計思想の違いを感じることができるのが”OS弄り”の楽しさであるのですが、触っているうちにふと、”じゃあこのOSの黎明期はどんなUIだったのだろう”という興味がわいて来ることがあります。

そんなわけでいつか機会があれば触ってみたいなーと思っていたのですが、古いOSのインストールディスクはなかなか入手できる代物ではないですし、入手できたとしても、現行の物理マシンや仮想マシン上で動くのか、といった問題があり、なかなか動く形で触る機会というのはありませんでした。

そんな中、先日ネットサーフィンをしていたらこんな記事を発見。

懐かしのMac OS System 7をブラウザ上でエミュレートして再現できる「PCE.js」- Gigazine

Internet Archive、System 7のアプリを利用できるコレクションを公開 – スラド

なんとブラウザ上で古いOSを動作させることができるサイトがあるらしい!
早速触ってみました。

サイトを閲覧するや否や、Machintosh Plusをモチーフをした絵が表示され、絵の画面部分に、本当に昔のMacOS(System 7)が起動しました。


シャットダウンもリブートも行うことができます。

最初に出てくる”Kidpix”は…

お絵かきソフトでした。

ちなみに、Mac以外にもWindowsの旧バージョンも見ることができます。

さわっていて気づいたことは、MacOSは白黒の時代に販売されたOSでも、デザインはほぼ似ており、簡単ながらエフェクトもすでについていたことには驚きました。
また、Windows3.0も思った以上にカラフルで、操作しやすさを考えていることがよくわかりました。

今のOSといろいろな部分を比べてみると、それぞれのOSの特徴や違いは再発見できてとても面白いと感じました。
興味のある方は見てみてはいかがでしょうか。

takahashi 著者:takahashi

[あなたのVPNは大丈夫?]VPNサービス利用の注意点

最近大幅に普及してきた公衆無線LAN。
ものによってはパスワードを入れなくても接続が行える無線LANもあり非常に便利ではあるのですが、これらの無線LANは無線で送受信されるデータが暗号化されておらず、だれでも簡単に傍受可能であることは有名な話です。

最近では対策としてVPNサービスを利用して通信経路を暗号化するユーザーも多くなっているようです。
VPNとは簡単に言うと、暗号化技術を使ってインターネット上に「仮想的に自分専用の通信線を引く」ことができる技術です。
VPNを使えば、例えば遠隔地からインターネット経由で自宅のLANや会社のLANに直接接続しているのと同じ状態を実現することができます。

VPN – ネットワーク入門サイト

つまり、一度VPNのコネクションさえ確立してしまえば、たとえどんな経路を使っていたとしても自宅や職場の拠点のLANに安全に接続できる…!
…なんて思っている方が多いのではないでしょうか?

確かに、VPNを利用すれば、自分のPCからVPNサーバー(ゲートウェイ)までの通信の安全性は(暗号が解読されない限り)担保されます。
しかし、その先の経路についてはVPNの保護のはんいがいであり、第三者の目にさらされる可能性があります。
なぜなら、VPNは飽くまで遠隔地のLANに接続する機能であり、そこから目的地までのアクセスはVPNでつないだ接続先のネットワークが担当することになります。
そこにながれるデータはVPNによる暗号化はされていないので、同じ接続先のLANに接続する人や、そのLANの管理者、さらにその上位のネットワークの管理者に傍受される可能性も考えなければいけません。

アクセス先が自宅のLANや社内LANであれば、同じLANに接続するのは身内の人間のはずなので、たとえ見られたとしても問題はさほどないでしょう。
ただし、もし接続先がVPNサービス業者が提供するような、公衆VPNのようなものの場合、場合によっては同じLANに接続する別の利用者や管理者によって自分の通信がのぞき見される可能性があることを頭の片隅に置いておく必要があります。
つまり、VPNサービス提供業者が確実に信頼できるところであればいいのですが、もしあまり信頼できない、ということであれば、安全性のレベルとしては公衆無線LANに直接接続するのとさほど変わらなくなってしまう、ということになります。

Android5.0以降でVPNに接続すると、こんな警告が通知領域に表示されます。

上記のようなことがあるので、注意してくださいね。という警告です。
ただ、ここまではっきりと警告が出てしまうとちょっとびっくりしてしまいそうな人も出てきそうですね。

ちなみに、VPNサーバーは必ず業者のサービスを利用する必要はなく、ある程度の知識とVPN接続先にするネットワークに十分な帯域があれば、だれでも自分のネットワークに設置することができます。

自分の場合は、Raspberry Pi 3SoftEther VPNというフリーのVPNサーバーソフトをインストールして利用しています。
自分の自宅のネットワークを経由してインターネットへ接続するので、どこかのVPNを借りるよりも個人的には安心できるかなと思います。
普通のPCにもインストール可能なので、是非検討してみてはいかがでしょうか?

インターネット上ではあらゆる仕組みが動いていますが、その基本的な動作を理解していないと落とし穴にはまってしまうことも少なくありません。
ざっくりとでも仕組みを理解して、インターネットをより便利に使いこなしていきたいですね。


参考:
今さら人に聞けないVPN入門…VPNの神話をはぎ取る – TechCrunch Japan

takahashi 著者:takahashi

Let’s Encryptが待望のワイルドカード証明書発行をついに開始!

今週はSL証明書のあれこれについていろいろいろ取り上げていますが、以前から紹介しているLet’s Encryptからついに、ワイルドカード証明書の正規版発行が開始されました!
ワイルドカード証明書と ACME v2 へ対応 – Let’s Encrypt 総合ポータル

ワイルドカード証明書とは、任意のサブドメインに対して設定することができるSSL証明書です。
通常、SSL証明書は暗号化をサポートしたいサイトのドメインやサブドメインごとに取得する必要があります。
例えば

example.com

というドメインに対して証明書を取得していたとします。
このドメイン用に発行した証明書を、例えば

a.example.com

に対して適用しようとしても、違うドメインとして判定され、SSLエラーとなります。

小規模なサイトであれば、使用するドメイン名は1つだけだったり、少なくて済むので数個の証明書を取得しておくだけで済みます。
しかし例えば何らかのWebサービスを運営していて、機能ごとにサブドメインを分けていたり(例えば画像サーバー、Webサーバー、DBサーバーにそれぞれ別のサブドメインを割り当てていたり)、不特定多数のサブドメインが生成されるような仕組みの場合は、ドメインごとにSSLを取得しなければならないとなるとかなり大変です。

そんな状況に対応するため、SSL証明書には”ワイルドカード証明書”と呼ばれるものがあります。
ワイルドカードとは「*」という記号でよくあらわされ、「すべて」を意味する記号としてよく使われます。
例えば、先ほどの例でいうと、
*.example.com
というSSL証明書を取得しておけば、*の部分に何が入っても適用対象となるので、
a.example.com
にも
b.example.com
にも、
hogehoge.example.com
にも同じ証明書を適用できます。

そんな素晴らしいワイルドカード証明書ですが、1枚で複数のドメインをサポートできる分、結構高額なお値段となっており、個人で使おうと思ってもなかなか購入できませんでした。
今回、Let’s Encryptでこのワイルドカード証明書を無料で発行できるようになったため、高い料金を支払わなくても(独自ドメインを持っていれば)だれでも取得可能となりました。

取得方法については、先日のACME v2とほぼ同じ手順で可能かと思いますが、DNSチャレンジレスポンス認証が必須となるということで、DNSが外部からの自動書き換えに対応していないDNSを利用している方は、更新のたびに書き換える必要が出てくる点は注意が必要です。

自分のサーバにも適用予定なので、また成功したら方法をご紹介したいと思います。

takahashi 著者:takahashi

Raspberry Pi 3 ModelBをマイナーアップグレードした新型ラズパイ発表

先日、新型のRaspberry Piのリリースがアナウンスされました。

Raspberry Pi 3 Model B+発表。CPU、Wifi、LAN高速化、PoEサポートで価格は据置き – Engadget 日本版

Pi 3 Model Bからの主な変更点としては
・プロセッサーのグレードアップ
・無線LANが5GHz帯、802.11acにも対応
・Gigabit LANポート搭載
・PoE(Power over Ethernet)対応
の3点です。

プロセッサーは 1.2GHz、4コアのBroadcom製SoC から BCM2837から1.4GHz駆動4コアのBCM2837B0へ変更され、少しスペックが上がっています。
また、耐熱策を実施し、高温状態でも従来よりも高いクロック数を維持できるようになったとのこと。

次に無線LANが5GHz帯、802.11acという従来よりも早いWi-Fiの規格に対応。
また、イーサネットポートは待望のGigabitについに対応したようです!
ただし、基盤との接続はUSB2.0ベースとのことで、上限は理論値で300Mbpsとのこと。

最後に、LANケーブル経由で電源を供給できるPoEにも対応し、PoEに対応したLAN環境であれば、ラズパイにUSB電源をつながなくても動作させることができるようになるようです。

地味なバージョンアップですが、今までネックに感じていた通信速度が改善されたのはとてもうれしいですね。
これだけのスペックがあれば、小規模なWebサーバーとして使用しても、十分さばけそうです。

自分の自宅には、一つ前のRaspberry Pi ModelBがあるのですが、早速B+も追加で買おうか今から悩んでいます(笑

Raspberry Pi 3 Model B+ – Raspberry Pi

takahashi 著者:takahashi

ACMEv2を使って Let’s Encrypt実装予定のワイルドカード証明書を発行してみた

先日、テストサーバー向けのSSL自己証明書の発行手順をご紹介しましたが、実はGoogleChromeでは利用できないことがわかりました。

Chrome58で、HTTPSの自己証明書が NET::ERR_CERT_COMMON_NAME_INVALID になる場合の対応 – TORICO 技術開発ブログ

GoogleChrome バージョン58から、SSL証明書のCN(コモンネーム)欄ではなく、SANと呼ばれる記述内を参照するように仕様変更されました。
そのため、折角オレオレ証明書を発行しても、今までの方法ではChromeからアクセスすると無効なSSL証明書として扱われてしまいます。

対策については、上記のサイトで解説されていますが、見た感じかなり手間がかかりそうだったため、今回は別の方法を使いたいと思います。

以前から紹介している、無料でSSLを発行してくれるサービス、”Let’s Encrypt”ではSSL取得の際の自動認証の手順をプロトコルとしてまとめた”ACME”というものがあります。

Automated Certificate Management Environment – Wikipedia

このACME、現在バージョン2のベータ版が公開されており、正式版も間もなくリリースされる予定にになっています。
この新しいバージョンでは、ワイルドカード証明書の発行がサポートされる予定です。

本物のワイルドカード証明書が入手できるようになるのは正式版を待つ必要があるのですが、一般的に信頼されていないテスト用のCAを用いた”なんちゃって証明書”であれば既に発行することができます。
テスト用の証明書を信頼された証明書として使用するには自己証明書同様にCA証明書をOSにインストールする必要があるのですが、SANの設定などの面倒な部分についてはすべて自動で行ってくれるため、自力で自己証明書を作るよりはかなり楽です。

今回は、こちらの方法を使ってテスト用の証明書を発行してみます。

Let’s EncryptにてACME v2でワイルドカード証明書を発行 – Qiita

curl https://get.acme.sh | sh #本家からacmeインストーラーをダウンロードして実行

インストールに成功すると、実行したユーザーのホームフォルダ内に新しく.acme.shフォルダが生成されます。

cd ~/.acme.sh

で.acme.shフォルダ内に移動します。
この状態で、次のコマンドを実行します。

acme.sh --test --dns --issue -d .example.com #example.comのワイルド証明書発行のテスト

発行テストを行うと、DNSチャレンジレスポンス用のキーが発行されます。

[root@hoge .acme.sh]# ./acme.sh --test --dns --issue -d *.example.com
...省略...
[Thu Mar 15 21:25:28 JST 2018] Add the following TXT record:
[Thu Mar 15 21:25:28 JST 2018] Domain: '_acme-challenge.example.com'
[Thu Mar 15 21:25:28 JST 2018] TXT value: '[チャレンジレスポンス用のキー]'
[Thu Mar 15 21:25:28 JST 2018] Please be aware that you prepend _acme-challenge. before your domain
[Thu Mar 15 21:25:28 JST 2018] so the resulting subdomain will be: _acme-challenge.example.com
[Thu Mar 15 21:25:28 JST 2018] Please add the TXT records to the domains, and retry again.
...省略...

結果の指示通りに、下記のようなレコードを対象のドメインを管理しているDNSサーバーに設定します。

_acme-challenge.example.com                  IN      TXT     "[チャレンジレスポンス用のキー]"

これで準備完了です。
実際に証明書を発行してみます

acme.sh --renew -d *.example.com

DNSの設定に誤りがなければ認証に成功し、証明書がインストールされ、証明書のパスが表示されると思います。
現在はテスト発行のみなので、現時点で信頼済みの証明書として利用するにはrootCAのインストールが必要です。
先日ご紹介した手順で、こちらのrootCAをインストールします。

あとは本物の証明書同様にWebサーバーに証明書を設定し、https://でアクセスすればSSL経由でのアクセスができるようになっているかと思います。

なお、今回はドメイン所有権の確認方法にDNSチャレンジレスポンス認証を利用していますが、更新のたびにキーが変わるようで、更新時にDNSへ再設定が必要になります。(Amazon Route53のようなAPI経由でのレコード書き換えに対応したDNSであれば自動化できます。)
ちょっとめんどくさい…という人はwebrootなどの他の認証方式を使うことをお勧めします。

最近はセキュリティの問題などで、SSL周りもかなり複雑になってしまっていますが、ACMEのような仕組みがあると、だれでも簡単に発行ができるので、価格だけでなく使いやすさの面でも役立ちそうですね。

今後本物のワイルドカード証明書の発行が始まっても(おそらく)同じ手順で設定できると思いますので、気になる方は是非試してみてください。

takahashi 著者:takahashi

突如発生した無線LANの電波が停止する怪現象。原因は気象レーダーとの電波干渉

会社で無線LAN経由でインターネットに接続していたところ、突如として無線LANの接続が不安定になる事態が発生。
自分のPCの調子がおかしいのかと思っていたら、周りの人も何人か同じ現象にあっていた模様でした。

ネットワーク担当の方に後で聞いたところ、原因は”気象レーダーの電波を無線LAN親機が検出したため”だとのこと。
日本で使用されている無線LANに対応した機器で、”IEEE802.11a”という規格に対応したものには、気象レーダーの電波を検知した際に、気象レーダーと同じチャネルの電波を自動で停波(別チャネルに自動切り替え)する機能(DFS)がついています。
これは日本国内統一で規定されていて、以下のルールで動作するようです。

・アクセスポイントは、起動後60秒間は電波を出さずに、気象レーダなどのレーダ波がないか確認しなければならない。
・レーダ波は6割以上の確率で検出できなければならない。
・レーダ波を検出した場合は、W52またはW53の他の空きチャネルに変更しなければならない。
・レーダ波を検出したチャネルに対しては、検出後30分間は電波の送出を行ってはならない。
・レーダ波を検出後、そのチャネルで通信していた子局は送信を10秒以内に停止する必要がある。
・上記の条件で送信を停止するまでの送信時間の合計は260ミリ秒以内でなければならない

今回はこれが原因で、無線LANのチャンネルが突然変更されてしまったために、通信が不安定になる現象が起きてしまったようです。

参考にしたサイトの一つのBuffalo社の記事では、室内で検出することは稀だと説明されていますが、別のサイトでは”どこでも受信してしまう可能性がある”という見解もでています。

世界標準11a Q&A集 – Buffalo

新5GHz帯と電波法関連の法改正について – 高速無線LAN情報局

最近引っ越した、11a対応の無線LANルーターを初めて買ったけど、どうも調子が悪い。
と感じている皆さんは、もしかすると電波干渉が原因かもしれません。

かつてなんでも有線でしか接続できなかった時代を考えれば、無線通信が普及してきて自由度が増したと感じていましたが、無線は無線でややこしい制約があるのですね…

安定性を考えると、やっぱり有線は最強なのかもしれない。

————
※この記事は、以前自分が別サイトに投稿した記事を一部修正したものです。

takahashi 著者:takahashi

memcachedにDDoS攻撃の踏み台にされる脆弱性が発覚。利用している方はすぐに確認を。

先日、メールでさくらインターネットから注意喚起の記事が届きました。

【重要】memcachedのアクセス制御に関する注意喚起 – さくらインターネット

WebサーバーなどでWebページ表示の高速化を行う目的で、memcachedというプログラムを利用することがあります。
このmemcachedですが、実はローカルにある必要はなく、例えばWebサーバーが動作している環境とは別のマシンにmemcachedをインストールし、Webサーバーから参照する…ということも可能になっています。

このmemcachedの機能を悪用して踏み台とし、特定のホストに対してDDoS攻撃を仕掛けることができてしまうようです。

memcachedを悪用する攻撃は国内でも多数観測–IIJ – ZDNet

memcachedが初期設定ではホスト上の全てのネットワークインターフェースでTCPやUDPの11211ポートに対する着信を受け付けるため、インターネット上の不特定多数のホストからの通信を受け付けてしまう可能性があると解説。リクエストに対してレスポンスにおけるメッセージサイズが大きくなるため、これを悪用して通信量を増幅させることでDDoS攻撃を仕掛けることが可能になる。

対策前のmemcachedはデフォルトで外部からの通信を受け付ける設定になっていたとのことで、入れっぱなしでアクセス制限などを設けていないと、DDoS攻撃に悪用されてしまう可能性があるとのこと。
ごくごく一般的に使われているものなので、最近のディストリビュージョンではパッケージマネージャーなどでサクッとインストールできるようになっているものが多いです。
使っていなくても、何かの機会にインストールしている可能性もありうるので、サーバー管理者の方は一度確認をされた方がいいかもしれません。