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

takahashi 著者:takahashi

nginxでnet::ERR_CONTENT_LENGTH_MISMATCHが出た時の対処法

今まで普通に動いていたサイトが、ある日突然正常に表示されなくなるという問題に遭遇。
Chromeの開発者ツールで調べると

net::ERR_CONTENT_LENGTH_MISMATCH

上記のメッセージが大量に発生しており、サイトのアセットの読み込みに失敗していたようでした。
ERR_CONTENT_LENGTH_MISMATCHはヘッダーのContentLengthと実際に受け取ったバイト数が違うと発生するようです。

nginxでのERR_CONTENT_LENGTH_MISMATCHの解決法 – Qiita

いろいろなサイトを見てみると、サーバーにNginxを使っている場合、サイトのキャッシュの保存が失敗したときに先程のエラーが出現するようで、その場合は指定パスに書き込み可能なディレクトリを用意すれば解消するようです。

しかし、今回問題が発生した環境では、該当のログが見当たらなかったため、問題が発生していたサイトのキャッシュを禁止する方法で対策してみました。
変更としてはnginxの設定ファイルを下記のように修正します。

server {
  server_name  .example.com;

  listen          443;

  ssl on;
  ssl_certificate       /path/to/hoge.crt;
  ssl_certificate_key   /path/to/hoge.key;

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
  proxy_set_header X-Forwarded-Host $host; 
  proxy_set_header X-Forwarded-Server $host; 
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Fowarded-Proto \$scheme;
  proxy_max_temp_file_size 0; #この記述を追加
  location / {
    proxy_pass https://localhost:8081;
  }
}

これでnet::ERR_CONTENT_LENGTH_MISMATCHエラーが消滅し、とりあえず無事サイトが表示されるようになりました。
しかしなぜ突然こんなエラーが出るようになってしまったのか…原因は分かっていないので、さらに調査が必要そうです。

参考サイト
Consul Web UIで画面が表示されない時の対処法 – Qiita

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

GoogleがGoogle Chrome 69をリリース。テスト中だった新UIがついに正式版に。

GoogleがGoogle Chrome 69をリリースしました。

New in Chrome 69 – Google

新バージョンに更新してまず最初に目につくのがツールバー部分のデザインの変更でしょう。

以前
Google Chrome Ver.68でChromeの新しいデザインが利用可能に。
でご紹介したテスト中の新UIが、正式版として実装されたものと思われます。

Chrome68で実装されていたテスト版のUIはこんな感じでした。

正式版ではタブの追加ボタンが再び右端のタブの右側に戻り、直感性が上がりました。
また、今までアプリモードでは右クリックメニュー以外からは一切メニューにアクセスできませんでしたが、

タイトルバーから一部メニューにアクセスできるようになりました。
アプリ上から拡張機能の設定も行えるため、さらに便利になりそうです。

そして今回の最も多きな変更はやはりSSL関連。

SSLが有効となっているサイトの表示が、ついに灰色の鍵マークとなり、Chromeの”SSLは適用されていて当たり前”という考え方がより色濃く感じられるようになりました。

なお、次バージョンのChrome 70 では、ついにhttpサイトへつないだ際に文字入力をすると、赤文字の”保護されていません”表示が行われるように変更されるとのことです。

Google Chrome、HTTPSサイトの「保護された通信」を非表示に 「デフォルトで安全が前提」 – ITMedia エンタープライズ

Chrome 69からHTTPSの表記が変化!Chrome 70以降も要チェック! – 常時SSL Lab.

まだSSL対応をしていない皆さんはお早めに。

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

テストサーバーの仮想マシンに大量のI/Oエラー… 調べたらホストマシンのディスク不良だった件

今朝会社に来て、テストサーバーのシェルに接続しようとしたところ、接続できない状態に。

今回接続できなくなったのは、Windows上に建てたLinux仮想サーバーでした。ホストOS側のWindowsはリモートデスクトップで何とか接続することができたので状況を確認すると…

ほぼすべての仮想マシンでIOエラーが出ていました…

このマシンは以前からやや不安定な挙動は見せてはいたのですが、ドライバのアップデートやメモリの増設を行った後、暫くは問題なく稼働してはいました。
が、再びIOエラーが出てしまったので流石にハードを疑わざるを得なくなってきました。

案の定、S.M.A.R.T.情報を確認したところ回復不能セクタも出ていた模様。
ホストOS側でも読み込みに失敗する症状も出始めていたので、HDDを交換することになりました。

S.M.A.R.T.情報を監視するアプリを入れて置けばメールでの通知もできたとのことで、テスト環境とはいえ、怪しいと思った時点で監視ツールを入れておけばよかったなとちょっと後悔です。

CrystalDiskInfo – Crystal Dew World

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

有線LANはあるけど無線LANがない…! そんな時に役に立つWIndowsで逆テザリング(Hotspot化)する方法

最近はビジネスホテルなどでも無線LANが標準で提供されるところも増えてきました。
しかし一部のホテルや施設などでは未だに有線LANだけの提供だけ、というところがある場合もありますし、どこかの場面で急に無線LANが必要になる場合もあるかもしれません。

特に、スマートフォンなタブレットなどの端末は有線LAN接続が困難な機種が多いので、いざというときに有線LANしか使えない環境だと不安です。

そんな状況下のとき、もし無線・有線LAN搭載のWindows 10 PC一台さえあれば簡単に解決することができます。

通知エリアの無線LANアイコンを押すと、

”モバイルホットスポット”というアイコンがあるのがわかるかるかと思います。
実はこれが今回の目的の機能になります。

モバイルホットスポットって何だろう? – テザリング機能の使い方 – マイナビニュース パソコン

モバイル回線をスマホなどを通じてPCに提供することを”テザリング”と呼ぶのに対し、ホットスポット機能はPCが接続するネットワークをスマホなどのWi-Fi端末へ流す使われ方が多い為、しばしば”逆テザリング”と呼ばれます。(やってることはテザリングとほぼ変わりません。)

実は他のOS(macOS、Linux)でも”逆テザリング”する機能はありますが、Windowsには標準で、他OSにはない仕組みを持っています。
それは1つのWi-Fiアダプタを仮想的に分割し、Wi-FiからWi-Fiへネットワークを中継することができる機能です。

基本的に他OSでは、別のネットワークアダプタのネットワークを”逆テザリング”することしかできません。
つまり、共有する元のネットワークにつながるネットワークアダプタとWi-Fiの電波を端末に発信するネットワークアダプタはハード的に別でないといけません。
一般的にノートPCではWi-Fiアダプタと有線LANポートをひとつづつ備えている構成が多いかと思いますので、この場合は有線LANでつないでいるネットワークをWi-Fiから飛ばす、というような使い方に限られます。

しかしWindowsでは、Wi-Fiアダプタでネットワークにつないだまま、同じWi-Fiアダプタから他の端末に対してWi-Fiのアクセスポイントを提供することができます。
この機能はVirtual Wi-Fiと呼ばれています。

また、Windows 10ではBluetoothを搭載していればBluetoothのPANプロファイルを使って逆テザリングすることもできます。

 

Bluetoothを除く上記の機能は、正式なGUIが実装されたのはWindows 10からですが、機能自体はWindows 7から利用することができます。

Windows 7をお使いで、GUIでホットスポットのON/OFFを行いたいのであれば、

Virtual Router

を使うと実現できます。

いざというときにWi-Fiルーターが必要になった際に役に立ちそうですね。

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

恐ろしすぎる”SIMハイジャック”の恐怖

ネットニュースの記事で、こんなニュースが流れてきました。

電話番号が奪われてしまうSIMハイジャックの脅威とは? – Gigazine

によると、アメリカではある日突然、SIMカードが”乗っ取られて”しまう”SIMハイジャック”なるサイバー攻撃が増加しているようです。

上記の記事によると、アメリカのMNOであるT-Mobile社を利用するユーザーの端末のもとに、ある日突然SIMカードが更新されたというメッセージが届き、それ以降その端末がモバイルネットワークへ接続不可能となってしまったとのこと。
ユーザーの家族がユーザーの番号へ電話をかけたところ、全く知らない人物が電話に出て、SIMをハイジャックしたことを暴露した…という流れ。

被害にあったユーザーは電話番号で認証情報を連携していたSNSや各Webサービスのアカウントをごっそり乗っ取られてしまったそうです。

そしてこの原因が驚くことにキャリアの本人確認不足。
その気になればだれでも手に入ってしまう情報のみで本人を断定し、まったくの第三者に対して、SIMを再発行して渡してしまったようです。

こちらの記事も、同様の被害にあい、仮想通貨を奪われてしまったユーザーのケースです。

ハッキングで仮想通貨を盗まれた海外の投資家がTモバイルを告訴!なぜ仮想通貨取引所ではなく携帯電話会社を訴えたのか、詳細まとめ! – やさしいビットコイン入門講座

こちらの記事では何故か訴訟した側を叩くような流れになっていますが、本人確認を怠った時点で明らかにT-Mobile側の落ち度であり、多数の被害者がいるにも関わらず今のところ対策が注意喚起のみという、通信事業者としてあり得ない事態となっています。

最近のサイバー攻撃は、システムからそれを管理する”人”を対象としたものにシフトしています。システムの技術的な”あら”を探すより、それを管理する管理者を騙した方がはるかに簡単だからです。
管理者が”クラッキング”されている現状が続く以上、どんなに堅牢なシステムを築いたところで全くの無意味となってしまうでしょう。

ちなみに、日本国内では法律で厳密な本人確認が義務付けられており、手続きを行う際は必ず身分証の原本が求められるようになっているなど、しっかりとした個人認証が行われています。

携帯電話の犯罪利用の防止 – 総務省

失敗を犯した存在に後ろ指を指すのは簡単です。
モバイルネットワーク事業者に限らず、何らかのサービスを提供している立場に自分自身がいる場合は、本人確認は厳密に行うように心がけていきたいですね。

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

PostgreSQL “対向(peer)認証に失敗しました” エラーが出るときの対処法

PostgreSQLでちゃんとユーザーにログイン権限とパスワードを設定しているのに、

psql: FATAL:  ユーザ "postgres" で対向(peer)認証に失敗しました

のようなエラーが出てしまった場合の対処法です。

そもそもPeer認証とは

CentOS6でPostgreSQLインストール – My Octopress Blog

Peer認証とは、カーネルからクライアント上のシステムユーザ名を取得し、PostgreSQLデータベースユーザと同一である場合のみ接続が許可される仕組みです。

つまり、Postgresql内のユーザーとUNIXユーザで、ユーザー名が一致してさえいれば認証情報なしでログイン出来てしまう仕組みです。

パスワードを打たなくてもいいのは楽ですが、例えばユーザーごとに権限を変えて置いて、場合によって使い分けたいときや一時的に別のpsqlユーザーとしてログインしたいときなどはかなりやりづらいですし、psql側でユーザーを作る際に、同名のUNIXユーザーも追加する必要が出てくるのでとてもめんどくさいです。

この挙動を変更するには、pg_hba.conf (だいたいpsqlのデータフォルダか/etcにあるはずです。)を編集します。
ファイルを開くと

#ローカルで動いているpsqlへアクセスする場合
local   all             all                                     peer
#他のクライアントからpsqlへアクセス可能にする場合(例)
host    all             all             127.0.0.1/32            peer

などとなっているか、あるいはコメントアウトされているかと思いますので、これを書き換えます。

#ローカルで動いているpsqlへアクセスする場合
local   all             all                                     md5
#他のクライアントからpsqlへアクセス可能にする場合(例)
host    all             all             127.0.0.1/32            md5

パスワード認証させたい場合は”peer”の部分を”md5″に変更して保存し、psqlのデーモンを再起動させます。

これで再度ログインを行えば、今度はパスワードを求められ、正しい情報を入力すればどのユーザーでもログインできるようになるかと思います。

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

Apache 2.2系で”_default_”の重複エラーが出るときの解決法

今回、少し古めの環境を再現する必要があったため構築作業を行っていたのですが、少しハマったので備忘録。

Apache2.2系とCentOS6を使ったテスト環境を作成していたのですが、設定完了し、configtestを行ったところ…

# apachectl configtest
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
[Tue Jul 17 14:41:13 2018] [warn] _default_ VirtualHost overlap on port 80, the first has precedence
Syntax OK

とのエラーが。
“_default_” の指定はVirtualHostで指定されたどのドメインにもマッチしなかった場合や、IPアドレスでアクセスされた場合に使われる”デフォルトの”VirtualHostを指定するときに使います。
超簡単に書くと

<VirtualHost _default_:80>
    ServerName example.com
    DocumentRoot /path/to/directory
</VirtualHost>

のように指定すると、すべてのVirtualHostで記述のないホスト名で接続された場合や、VirtualHostディレクティブで指定されていないIPでアクセスされた場合は、この”_default_”が指定されたVirtualHostの設定が適用されます。
デフォルトの動作を定めるオプションなので、全設定ファイル中1箇所でしか指定できません。
この_default_の指定を複数個所で指定してしまった際に出てくるエラー(Warning)が

_default_ VirtualHost overlap on port 80, the first has precedence

です。
ただ、今回の場合”_default_”は一か所でしか指定していなかったにもかかわらず、上記のエラーが出てしまっているのでちょっと首をひねっていました。
Warningなので無視をしてもApacheを動かすことはできますが、予期しない動作をしてしまうことがあるので直しておきたいところ。

いろいろ調べたところ原因が判明しました。

Apache2.2系でVirtualHostする場合は”NameVirtualHost *:80″の指定が必要

Apache2.2系の場合、VirtualHostを設定する場合はNameVirtualHostを指定する必要があります。
指定するときは

NameVirtualHost 対象のIPアドレス:対象のポート

とします。
IPアドレスが定まっていない、あるいはサーバに割り当てられているIPすべてに適用したい場合は

NameVirtualHost *:80

と指定することも可能です

“_default_ VirtualHost overlap”エラーはこのNameVirtualHostが指定されていないときも出力されるようで、今回はこれが原因でした。

ただし、Apache2.4からはNameVirtualHostは指定しなくてもエラーは出ません。(NameVirtualHostの指定なしでVirtualHostを指定できます。)
これから新しい環境を作る際にApacheを用いる際、大抵の場合はApache2.4を使われるかと思いますので気にする機会は少ないかとは思いますが、Apache2.2系の環境を作られる機会があった場合は注意が必要です。

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

Apacheをどう設定しても403になる時はSELinuxを疑え!

ここ最近、サーバーを構築する機会が何度かあったのですが、Apacheの構築中しばしば同じところでハマることがあったので備忘録。

Apacheでは通常、公開するディレクトリ(ドキュメントルートとするディレクトリ)のアクセス権限を下記のように与えてやれば、Webブラウザからのアクセスが可能になります。
例えば、

#2.2系
<Directory /var/www/html>
Order Deny,Allow
Deny from All
</Directory>
または
#2.4系
<Directory /var/www/html>
Require all granted
</Directory>

とすれば
/var/www/html
配下がアクセス可能になるはずです。
勿論、OS側のアクセス権限も調整する必要がありますが、Directoryディレクティブを設定し、なおかつOS側のファイルアクセス権限も問題ないはずなのに、ブラウザで開くと何故かステータスコード403(Forbidden)が返され、コンテンツが見えない、といった事情が起こりました。

ドキュメントルートのディレクトリよりもさらに上のディレクトリに、実行権限がついてるかどうかを確認したり、権限を一括で書き換えたりなど行いましたが、一向にアクセスできず。

いろいろ調べたところようやく原因に多とりつきました。

SELinuxです。

SELinuxはアクセス制御を行うモジュールで、米国NSAがオープンソースで提供しています。

非常に強力なのですが、サーバーのように一般的によくアクセスされる場合は障害になることも多いので、基本的には無効にします。
ただ最近は、インストール時に既に無効になっているものも多いのですが、今回使ったCentOSの場合はデフォルトで有効になっていたようで、SELinuxが動いていることに気づかずにそのまま作業してしまっていました。

SELinuxの設定の確認は

getenfotce

とすると確認ができます。

無効化すは

setenfotce 0

でできますが、これだけだとOSを再起動した際に復活してしまうので、

/etc/selinux/conf

SELINUX=enforcing

の記述を

SELINUX=permissive

に変更しておきます。
これで、再起動時もSELinuxが無効のままにしておくことができます。

なんど設定しなおしてもうまくいかない…!という方は一度SELinuxの設定を確認してみてください。

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

SIMを入れていないスマホなどに表示される”緊急通報のみ”は本当に緊急通報できるのか?

一度は気になった方も多いはず。

SIMなしスマホや、無効なSIMが入っている端末で”通信事業者なし”といったメッセージの代わりに”緊急通報のみ”と表示される場合があります。
“緊急通報のみ”と出ている以上、逆に緊急通報であればできてしまうのではないか?と思ってしまいますが、実際のところはどうなのでしょうか?

携帯回線を契約していないのに、電話ができてしまうのでしょうか。

流石に試す勇気はなかったので、ネットで調べてみたところ、面白いことがわかりました。

  • 日本では実際に緊急通報することはできない。

「緊急通報のみ」の表示で、緊急通報はできるのか? – 格安SIMのSNS
によると、日本において、たとえ”緊急通報のみ”と表示されていても、実際に緊急通報することはできないようです。

結果、かかりませんでした。

一回バイブして電話は切れました。何回か試しても、やはりバイブして電話が切れるだけです。繋がらないじゃんと思い、119番も試してみましたが、同じく繋がりませんでした。

こんな感じで、実際にはかからなかったようです。
理由として、日本特有の決まりがあるようです。

【ハウツー】「SIMカードなし」のiPhoneは緊急電話できる? – いまさら聞けないiPhoneのなぜ – Livedoor News

iPhoneは携帯電話としての機能を備えるため、ここ日本では電気通信事業法に基づく制約を受けます。電気通信事業法 端末設備等規則 第28条の2には、「移動電話端末であって、通話の用に供するものは、緊急通報を発信する機能を備えなければならない」と定められ、国内で販売されるすべての携帯電話には緊急通報機能の装備が求められます。ロック画面に「緊急」ボタンが用意され、ロック解除することなく特定の番号 — 110(警察)と118(海上保安)、119(消防および救急)の3種類 — にかけられるのはそのためです。

しかし、日本国内での利用に関していうかぎり、SIMカードを抜いた状態では緊急電話をかけることができません。ダイヤルの画面を表示することはできますが、ダイヤルしても呼び出し音は鳴らず反応しません。この仕様はソフトバンク、au/KDDI、ドコモのいずれで契約したiPhoneも同様です。

日本でSIMカードなしの緊急電話ができない理由は、非アタッチ状態(携帯電話通信網に接続していない状態)での電波送出が法律上認められていないことにあります。SIMカードを抜いたiPhoneは非アタッチ状態ですから、ここ日本では緊急発信を求められない、だからSIMカードを抜いた状態では緊急電話をかけることができない、ということになります。

ただし、
「緊急通報のみ」の表示で、緊急通報はできるのか? – 格安SIMのSNS
によると

噂によると外国ではSIMカードを入れていないスマホでも、緊急通報はできるそうです。

とのこと。

  • SIMなしでも緊急通報できる国

ならば実際に通報できる国はどこなのかという話ですが、いろいろ調べましたが、確かな情報は出てきませんでした。
ただし、

緊急通報とローミング – 無線にゃんこ

によると、韓国ではできるようです。

  • 日本でも契約中のデータ専用SIMならかけられる可能性がある。

一方、日本で音声通話不能なSIMであっても、データSIMの場合はつながる可能性があるようです。
データSIMって緊急電話使えたんですか! – マイネ王

実はデータ専用SIMであっても、電話番号は必ずすべてのSIMに割り当てられています。
また、携帯電話網自体には”アタッチ”しているため、法律的にはクリアできます。

あとは音声回線に接続させてもらえるかという部分ですが、

mineo(au)ということは、VoLTE simを使っていますよね。
それが使えた理由のような気がします。
VolLTEの場合は、通話も3G回線ではなくLTE回線上でデータ通信と同じような仕組みでやっているから、データsimを使って119や110宛てに発信されたときに、auの基地局側でそれを拒絶するような仕組みになっていないのだと思います。

あくまでも推測でしかないですが、データsimにも電話番号はきちんと割り当てられているので、理論的にはできても不思議ではないですよね。

というコメントもあり、通信会社の設定次第、というところになりそうです。

  • 実際に試してみた

“日本では通話できない”ということがほぼ確実に分かったので、思い切って実際に確かめてみました。

丁度社内に、解約済みの無効SIMが刺さったXperia Ultraがあったので、この機種で実験してみます。

オペレータ部分に”緊急通報のみ”と表示されています。

緊急通報番号を入れ、恐る恐るコール開始。

“接続できません、有効なSIMカードを挿入してください。”

と表示され、やはりかけることはできませんでした。

結論として、日本においては”緊急通報のみ”と表示されていても、実際に緊急通報することはできませんでした。
ただし、先程あげた国などでは緊急通報できるということで、海外旅行時の万が一の時のために頭の片隅に入れておいても損はないかもしれませんね。

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

クラックされてしまったWPA2の改良版、WPA3策定が完了

Wi-Fiは物理的な接続である有線LANと違い、電波が届く範囲内であればどこにいても接続が可能です。
そのため、物理的なケーブルであれば、不正につないでいる人を見つけることは大抵は難しいことではありませんが、無線であるWi-Fiの場合は電波が届けば接続出来てしまうので、誰かが不正に接続していても気づかないことがあります。

そういった場合を防ぐために、Wi-Fiには”パスワードがわかる人しか繋げられない”ようにする機能があります。
この機能、つまりWi-Fiの認証と暗号化の機能はいくつか規格があるのですが、いままで破られにくいとされていた”WPA2″が主流として使われていました。

ところがこのWPA2の認証を突破できてしまう”KRACKs”という攻撃方法が発見され、その堅牢性は崩れることになりました。

WPA2の脆弱性「パッチで対応可能」 Wi-Fi標準化団体が見解 – ITMedia

WPA2は業界共通の”標準規格”のため、簡単にアップデートすることは難しく、当面はパッチで対応する形でしのいていました。

そして今回、WPA2のアップデート版であるWPA3がついに策定されました。

新しいWi-Fiセキュリティ規格「WPA3」登場 – ITMedia

WPA3は、WPA2との互換性を維持しつつもKRACKsなどへの対策もされているとのこと。

 WPA3では、WPA2デバイスとの相互運用性を維持しながらPMF(Protected Management Frames:管理フレーム保護)を必須とした。また鍵確立手法を従来のPSK(Pre-Shared Key:事前共有鍵)から新しいSAE(Simultaneous Authentication of Equals:同等性同時認証)に変更。ハンドシェイクの手順や認証の再試行回数を変更して各種攻撃への耐性を上げた。

今後発売される機器にはWPA3が搭載されることになりそうです。
また、ファームウェアアップデートが可能な機種でも、もしかすると利用可能になるかもしれません。

今後の動きに注目していきたいですね。

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