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

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カードを挿入してください。”

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

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

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

[間もなくGoogle ChromeでSSL必須化。確認しておくべきこと。] SSLって何?

いよいよ、前から予告されていたSSL必須化(HTTP(非暗号化)接続というだけで警告を表示するようになる仕様変更)がChrome 68から適用されます。

いよいよGoogleが本気。Chrome 68から全HTTPサイトに警告! – 常時SSL Lab.

もしあなたがサイトを運営していて、SSLを利用可能にしていない場合、画像の下のな表示がアドレスバーに常に表示されるようになります。
回避するためには、サイトをSSLに対応させないといけません。

そもそも、SSLとはなんぞや…という方のために、簡単に説明します。
SSLを理解する前に、インターネットの仕組みを簡単に簡単に理解しておく必要があります。

今は家にPCやスマホ・タブレットが複数台ある、という方は多いと思います。
複数台のPCやタブレットなどを同時にインターネットへ接続するために、ルーターを設置している方が多いと思います。

細かい説明は割愛しますが、ルーターを設置すると、大抵の場合はそこにLANと呼ばれるネットワークが構築され、そのLAN全体をルーターを介してインターネットに接続することで、ルーターに接続されている複数台の端末が、同時にインターネットへ接続できるようになります。

簡単に言ってしまえば、インターネットというのは、ルーターやLANを相互に接続してできた巨大なネットワークなんです。
つまり、インターネット上には、自宅に設置したルーターのように、あなたの通信を中継する機器をいくつも経由して、目的のサイトへたどり着けるようになっています。


引用元:JPRS

そしてこの”通信を中継する機器”は、仕組み上誰でも設置が可能です。

また、インターネットのベースとなった仕組みでは、”一部の経路が切断されても、他に通信経路があれば通信を継続できるようにする”仕組みになっています。
先程書いたように、インターネットはネットワークを相互につないでいる構造になっているので、目的のサイトにたどり着くまでの経路は何通りもあります。

そのうちのどの経路が選ばれるかは一定ではなく、状況に合わせて、最も最適なルートが選択されます。

つまり、自分がインタ―ネットへ送信した情報がどの経路を通過するのかはわからない(決まっていない)のです。

通信経路は固定ではなく、かつ経由する機器もだれのものかわからない…そんな仕組みなので、例えばもし経由する経路上にサイバー犯罪を企てる人が設置した機器を経由してしまった場合、自分が送信した解読された場合はその内容が盗まれてしまったり、改変されたりしてしまう可能性が出てきます。

もしその時に自分が送っていた情報がパスワードやクレジットカード情報だったら…最悪ですよね。

そうならないために、自分が送付する情報を”暗号”にして、自分と通信相手にしか解読することができないようにする仕組みがあります。

これが、SSL(TLS)と呼ばれるものです。

SSLを利用するためには自分のサイトが動いているサーバーに、SSL証明書をインストールする必要があります。
SSL証明書は発行を行っている”認証局”と呼ばれる業者から取得する必要があります。

通常は有料で、有効期限があるので、有効期限が近づくたびに購入しなおす必要があります。

ただし、最近はLet’s Encryptという、更新するまでの期間が短い代わりに無料で利用できるSSLもあります。

これでSSLをサイトに導入して対応完了…!と行きたいところですが、まだ他にも気を付けないといけない点があります。

また次回説明します。

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

QNAPのNASが凄すぎて最早ただのサーバ機と化している件

知人が自宅サーバー代わりにQNAPのNASの利用を検討しているとのことで、自分も気になって調べていたところ、QNAP製NASに搭載されているOS”QTS”の操作を実際に体験できる公式のライブデモサイトを発見。

ライブ・デモ – QNAP

早速触ってみました。
日本からの利用の場合は、ライブデモ-Asiaを利用すればOKかと思います。


/私、QNAPのNAS。こっちはQTSのログイン画面。\

既にNASのログイン画面とは到底思えない装い。
その完成度にビビりつつも早速ログイン。

ログインID/PWはデモページ入り口に記載されているものを入力すれば入れます。

ログインに成功するとようこそ画面が出現。
そのままチュートリアルを読み進め、ウインドウを閉じると

iOSとGnomeを足して2で割ったような(?)UIが出現。
ブラウザのバーとかなかったら普通にPC用のOSに見間違いそうな完成度です。

NASストレージ内に保存されたファイルや

Nasの動作設定などもわかりやすい画面で確認・設定ができます。

が、そんなところでとどまらないのがこのQTS。
なんと普通のスマホやPCと同様にアプリをインストールすることで様々な機能を追加することができます。
さすが、伊達にOSと呼ばれはいないようですね…

しかししかし、OSたるもの、どんなアプリが対応しているか、というのも非常に重要なポイントです。
ということで、早速アプリストアをチェック

開いてみて驚いたのはその対応アプリの多さ。

めっちゃあるwwww

まずすごいのは、NASなのに

CMSがうごいちゃう!

NASなのに…


DHCPサーバーや仮想スイッチをたてれちゃう。

極めつけは…

えっNASなのにNode.jsやRuby on RailsやPostgreSQLも動くの…
普通に開発環境として使えちゃうじゃないですかやだー!!

ストレージ内に保存された音楽をブラウザ上やLAN内のDLNA機器などを経由して再生できるメディアプレイヤー機能

フォトライブラリなど、マルチメディア周りの機能も充実しています。

ちなみに、

S3互換のオブジェクトストレージサーバーアプリもあるので、S3とほぼ同じようなAPIをたたいてファイルを取得できるようにすることもできるようです…ヒェー((

ちなみのちなみに、
RAID対応NASですので、搭載HDDの状態も勿論画面上から確認できます。

ここでふと気づいてしまいました…

自分が自宅サーバーでやりたかったことの大半….
もしかしてQNAP NASでできてしまうのでは….

できれば気付きたくなかったですが、これだけのものをアプリストアからインストールするだけで、しかもブラウザ上のGUIから自在にコントロールできるという簡単さは目から鱗レベルによくできています。

今回見た画面は飽くまでQTSのデモ版なので、実際にインストールして動かしたりとかまではできないので、実際の動作感までは分かりませんが、”自宅でサーバー動かしたいけど難しい操作は覚えたくない…”という人にとっては夢のようなガジェットかもしれません。

ここまでくると、本体のお値段が気になってきたので、現時点でのお値段をAmazon.co.jpで調べてみました。


HDDスロットが2つの、恐らくエントリーモデルと思われる製品。

約2万3千円という、標準的なNASに比べると結構しますが、下手に新品のPCを買うよりもお得かもしれません。

自宅サーバー歴5年の自分ですが、ここにきて心変わりの危機に瀕しております。

めっちゃほしい…

QNAP

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

GDPRの影響でWhois情報公開が停止する可能性

EUのGDPR(EU一般データ保護規則)の影響ががついにWhoisデータベースにまで及びました。

ドメイン所有者の連絡先などが含まれる「WHOIS」データがGDPR発効の影響で一時的に非公開になる可能性 – Gigazine

GDPRはEU圏内に住む人々の個人情報について、所定の許可なく公開することを禁止する法律で、特徴的なのは域外の企業や事業者に対しても適用される点。
具体的には、一人でもEU圏内の人の個人情報を登録しているサービスでは、GDPRに則らないと制裁をうけるということです。

発効を前に、対象になった企業や団体が対応に追われている状況ですが、最近のニュースで特に大きな影響を受けるだろうとされるサービスが浮上してきました。
それが、世界中のgTLDドメインを管理するICANNによるWhoisデータベースです。

ICANNでは、Whoisにドメイン取得者の情報を登録することを義務付けており、従わない場合はドメインの登録を停止、取り消される規約になっていました。
この情報の中に住所や取得者の氏名などの個人情報が含まれています。
gTLDは世界的に使われているドメインなので、当然EU圏内の人もドメインを登録しているはずです。結果的にこのGDPRの影響をもろに受ける形になりなり、ICANNはWhoisの制度を見直さざるを得なくなりました。

現在、ICANNでは議論がされているようですが、答えが出るのに相当な時間がかかるため、GDPR発効までに対応版Whoisを構築することは難しく、暫定的な対応としてWhoisデータベースの公開制限や停止が行われる可能性が浮上しているようです。

ICANNのWhois情報公開の意義としてドメインの不正利用や犯罪の防止の目的もあり、今回のICANNの対応に対して、海賊版コンテンツに悩む各国の著作権団体からは抗議も上がっているようです。

GDPR規制によるWHOIS情報の制限に権利者団体が反発「海賊版の取り締まりを難しくする」 – P2Pとかその辺のお話R

ここからは個人的な意見ですが、僕はむしろ今回のGDPRによって、Whois情報が非公開化することは、”インターネットの個人利用”という観点からよかったのではないかなと考えています。

というのも、Whoisデータベースに氏名や住所などを載せないといけないのは企業だけではなく、ドメイン取得するすべての利用者が対象になります。
勿論ドメインを取得するのは法人だけとは限らないので、個人でドメインを取得する場合は自宅の住所なども公開する必要があるのです。

こんな状況でドメインを登録してしまうと、ドメインから一般の人に自分の住所が特定されてしまったりなどかなりリスクが高く、かといって自分のドメインを取得できない場合、個人的にサーバやサイトを建てる際にかなり制限を受けてしまう(SSL証明書が取得できないなど)の問題があり、”個人のサービスやサイトを公開するのに自分の自宅の住所をさらさないといけない”状態になっていました。
最近ではパブリッククラウドの普及などで、個人でも普通にサーバーを持つ時代になっていますし、この”法人を前提”としたWhoisの仕組みについて、個人的にかなり疑問に思っていました。
また、対応策としてレジストラによってはWhois代行公開サービスを提供している場合もありますが、ICANNの方針的に、いつ禁止されるかもわからない状況でした。

今回のGDPRの影響で結果的にWhoisの”だれでも情報にアクセスできる”状況の見直しが必要になったことで、Whoisの情報公開方法が見直され、”個人ユーザーにやさしい”Whoisの仕組みになることを期待したいと思います。

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

[要注意]MySQL 5.7からは初期状態でrootにランダムなパスワードが設定されている

先日、自宅のPCにUbuntu 18.04 LTSをインストールしたことを書きましたが、18.04でデフォルトになっているMySQLのバージョン”5.7″からMySQLのrootユーザーのパスワードが初期状態で自動設定される仕様に変更になったようです。

MySQL 5.7 をインストールしたら最初に行うセットアップ – WEB ARCH LABO

初期設定をする際、このことを全く知らなかったため、いつも通りmysqladminでrootパスワードを設定しようとしたのですが、何度やってもaccess deniedになり、パスワードなしてrootにログインすることもできなかったのでかなり焦りました。

ちなみにUbuntu 18.04の場合、初期状態であれば

sudo mysql

と、ユーザ名・PWすべて省いて実行したとことパスワード無しでログインできました。わかるかッ!!!
ちなみに、設定したrootパスワードも、デフォルトで一定期間後にパスワード変更が求められるらしく、その際はパスワードを変更しない限りログインできなくなるようです。(設定の記述で無期限化は可能。)

とかなりセキュリティ的に厳しい仕様になっていますので、これから使われる方はご注意ください。

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