カテゴリーアーカイブ インフラ

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

  • この記事いいね! (0)
著者:ym

Adaptec RAID maxView Storage Manager でファームウェアバージョンアップ

 
遠隔 IMPI 経由で、Adaptec RAID コントローラのファームウェアバージョンアップをする為、試行錯誤しました。
 
 
 
まずは Adaptec RAID maxView Storage Manager の USB ブートイメージファイルを Adaptec サイトからダウンロードしてきます。ISOイメージをマウントさせ、起動。
 
 
しかし、そのUSBブートイメージには新ファームウェアは無いのでWindowsでVHDイメージをFAT32で作成してWindowsへマウント、ファームウェアを格納して、Windowsから切り離しておきます。
更に、拡張子 vhd を img へ変更して IPMI のイメージマウント機能でアタッチ。
アタッチすると、USBブートして起動している Storage Manager 側で検出され、maxView のファームウェア選択が出来るようになります。
 
 

遠隔でBIOS更新とか、ファームウェア更新というのは大変。

無事バージョンアップが完了しまいた。

FreeBSD で arcconf getconfig 1 をすると、kill -KILL も出来ないプロセスとなってしまう症状があるのでバージョンアップをしたのですが、これで解決できるとよいが。

  • この記事いいね! (0)
takahashi 著者:takahashi

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

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

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

NORSE

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

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

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

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

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

Digital Attack Map(Google)

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

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

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

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

  • この記事いいね! (0)
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

  • この記事いいね! (0)
takahashi 著者:takahashi

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

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

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

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

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

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

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

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

  • この記事いいね! (0)
takahashi 著者:takahashi

[要注意] nginx バーチャルホストで複数ポートかつSSL有効化したら平文通信できなくなった話

家のサーバーのnginxの設定をしていたら完全にドジってはまったのでそのメモ。
自分のサーバー環境は諸事情でリバースプロキシ経由でウェブサーバー本体に接続する構成に変更中でして、Nginxをリバースプロキシとして設定していました。
構成は以下の通り。

自分のサイトは、もともとそれぞれサブドメインを割り当てたバーチャルホストが複数稼働している環境だったため、nginx側もバーチャルホストに対応すべく下のような設定にしていました。

すると

BadRequestのエラーが。
いろいろ試してもエラーが解消されず頭を抱えていたのですが、調べていたら以下のサイトを発見。

nginx連載6回目: nginxの設定、その4 – TLS/SSLの設定 – インフラエンジニア way
https://heartbeats.jp/hbblog/2012/06/nginx06.html

>sslディレクティブをonに設定すると、SSLが有効になります。ただし、listenディレクティブでsslパラメータを指定したときには不要です。

>ssl on;

>listenディレクティブにsslパラメータを付けると、そのポートでSSLを有効にして待ち受けるようになります。そのポートに関して後述するsslディレクティブをonにしたのと同じ動作になるため、sslディレクティブの記述は不要になります。

>listen 443 ssl;

あっ、なるほど…!
ssl on;
の記述をしてしまうと
server{}
内で定義されている全ポートにsslが有効になるので、80番ポートでアクセスしてもssl通信と解釈されてしまい、エラーが出ていたようです。
443ポートだけsslにしたい場合は

listen 443 ssl;

とだけ指定しておけば443ポートだけsslを有効にできるようです。

てっきり
“ssl on;”
を入れないとsslが有効にならないものと勘違いしていました(苦笑

さっきの設定を修正すると以下のようになりました。

これでnginxを再起動したところ、無事80番ポートの平文通信と443ポートのSSL通信両方ともできるようになりました。

分かってしまえばなんともくだらない間違いですが、大分焦りました。

もっと勉強せねば…


この記事は、以前筆者が書いた記事を一部変更したものです。

  • この記事いいね! (0)
著者:ym

WinSCP で AWS S3 ファイル操作

WinSCP が Amazon S3 に対応した様です

FFFTP はメンテ停止公表後、 2.0 リリースに向けて活動しているようですが、私自身はワンタイムパスワードとか使う機会はないので、すべて WinSCP になりました。ディレクトリ同時移動、SCP、SFTP、SSH トンネル越え SCP などにも対応しているので便利。

設定も簡単でした。Amazon S3 を選択して、アクセスキーとシークレットを登録するだけ。

AWS CLI もよいけど WinSCP コマンドでスクリプト制御もありかな。

  • この記事いいね! (0)
takahashi 著者:takahashi

Linux(Unix)のscreenの外からコマンドを実行する方法

LinuxやUnixでSSHにつなぎながら作業する際、時間のかかる処理を行わせたりでしばらく放置しておく機会と言うのはしばしばあります。

そんなときに、途中でインターネット接続が切れてしまうと最悪です。また、トラブル以外でもは会社の業務終了時間になって退社する時するなどでマシンの電源を落とさないといけない場面があったりします。

そんなときにscreenコマンドは便利です。
サーバー側に仮装のターミナルを作成し、そこで様々な処理を実行することが出来ます。
途中でSSHが切断されてしまっても、screenはサーバーの中で動作しているので、処理も続行されます。途中で処理させながらscreenターミナルから抜けることも、再度入ることも可能です。

また、スクリプトを簡易的にデーモンっぽく動作させる使い方もできます。

このscreenコマンドですが、実は外部からコマンドや文字列を与えることができるのはご存知でしょうか。

例えば、s1という名前でスクリーンを作成し、

$ screen -S s1

s1スクリーン内でpythonのプロンプトを起動しておきます。

$ python

Python 2.7.5 (default, Aug  4 2017, 00:39:18) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 

このs1スクリーンに、外からs1の標準入力に対して文字列を入力したい場合、
まず、ctrl+a d でスクリーンをデタッチした後で、

$ screen -S s1 -X stuff 'print "Hello world!"
'`echo -ne '\015'`

とした後、再度screen -r s1 でアタッチすると

>>> print "Hello world!"
Hello world!
>>> 

と表示されているはずです!

これは例えば、screenで実行中のプログラムに文字列を渡したい時や、特定のscreenでのみ定期的にプログラムを実行したいときに有効です。

予めシェルスクリプトにしておけば、cronで回すことも出来ます。
便利なので、ぜひ一度試してみてはいかがでしょうか?

参考サイト:
Minecraftサーバをscreenとcronでプラグインを使わずに自動再起動する – 純規の暇人趣味ブログ

別ターミナルで動いているscreenに外部からコマンド実行 – 戯術者の日記

  • この記事いいね! (0)
takahashi 著者:takahashi

WindowsへのMeltdown対策によるCPUベンチマークの変化をMSが公表。旧CPUでは著しい速度低下も。

先日、Microsoftが気になるデータを公表しました。

プロセッサの脆弱性、Microsoftの対策パッチでパフォーマンス大幅低下も – IT Media エンタープライズ

先日発覚したCPUの脆弱性 Meltdown/Spectre の脆弱性対策としてMicrosoftが公開したWindowsへの対策パッチを適用した際のベンチマークを比較したところ、IntelCPUの 第6世代にあたるSkylake以降は特に目立った速度低下はないものの、第4世代にあたる Haswell以前のIntelCPUは相当な減速が確認された、という内容です。
特にHaswellを含むそれよりも古いCPUを搭載したWindows Server機はかなりのスペックダウンが発生する可能性があるようです。

Skylakeが初めてIntelから発売されたのが2015年8月ごろになる(Wikipedia)ので、少なくともこれより前に発売されたIntelCPU、およびそのCPUを搭載したPCはすべてこのスペックダウンの影響を大きく受ける可能性があるということになります。

比較的新しいCPUでもスペックダウンの対象になってしまっているという点で、なかなかショッキングな内容です。
ちなみに、僕が現在所有しているマシンは一番新しいもので第5世代のbroadwellのマシンなので、全滅でした。

なお、LinuxOSにおいても影響が出ているようです。
CPU脆弱性Meltdownのパッチ適用でベンチマークスコアが25%低下した – Qiita

ここまで影響が大きいと、ゲーム用のマシンや企業向けサーバーなどののスペックダウンに各方面からの悲鳴も聞こえてきそうですね。
現にAWSでかなり影響が出ているという報告もあるようです。
チップ脆弱性の修正パッチが招いた、サーヴァーの性能低下という「二次災害」の深刻度 – WIRED

引き続き、Intelや各OSベンダーがさらなる対策を行ってくれることを祈ります。

  • この記事いいね! (0)
takahashi 著者:takahashi

NginxでBASIC認証をプロキシするときの注意点

今回。hamamatsu-gnss.orgのサーバー切り替えを行ったのですが、移行先サーバでサービスの再起動後何故かBASIC認証が通らなくなる問題が発生。
80番ポートはWebページとポートを共有しているので、webサーバーとntripサーバーの前にNginxを置いて、ドメインで通信を振り分けています。
旧サーバーでは問題なく動いていたのですが、まったく同じ設定をコピーした新サーバーでは、RTKLIBからntripへ401ステータスで接続できなくなってしまいました。

ちなみに直で新サーバー側のntripへ接続すると、認証も問題なく通り、ログにも異常は見られなかったので、原因がNginxなのは間違いなさそうです。

認証の要らないsourcetableはNginx経由でも問題なく表示できたため、恐らくBASIC認証の際に必要なヘッダ情報が渡せていないのだろうと推測しました。
そこでいろいろ調べてみると、参考になりそうなサイトを発見。

Nginx を認証プロキシとして使う – Docker-docs-ja

正常にプロキシするには

      proxy_pass                          http://example.com;
      proxy_set_header  Host              \$http_host;   
      proxy_set_header  X-Real-IP         \$remote_addr; 
      proxy_set_header  X-Forwarded-For   \$proxy_add_x_forwarded_for;
      proxy_set_header  X-Forwarded-Proto \$scheme;

の記述が必要だったのですが、新サーバーの設定ファイルと見比べたところ

proxy_set_header  X-Forwarded-Proto \$scheme;

の記述が抜けていることがわかりました。
この一行を追記し、Nginxをリロード、もう一度試してみると…

無事接続できました!

Nginxはプロキシする際、バックエンドへ渡すヘッダー情報を自由に指定・編集することができるので、抜けがあると今回のようなことが起きます。
Nginxでシステムを構築した際は、こういう部分も気を付けてチェックしたいですね。

いやーしかし、今回は症状がちょっと奇妙だったのでちょっとだけ焦りました…(笑

  • この記事いいね! (0)