ネット上のアクセスボリュームをUPさせ効率の良い集客をご提案します。

カテゴリー「テクニカル」の記事

雑学:2段階認証におけるSMSの遅延について考察

 / テクニカル, トピックス


最近弊社へのサービス問い合わせで某サービスの2段階認証を顧客アカウントでログインしないといけない場面があった。結果的にログインできなくて話はクローズしましたが、以前から不思議に思っていた事ではありパスコードが合わなかったりSMSが届かなかったり、遅延して20分近く経ってから届くこともあり従来認識していたSMSに対する信頼性に疑問を感じていた。
SMSは元々メッセージのための仕組みではなくて携帯電話が現在どの地域で使われているかモバイルキャリアセンターにあるLR(ロケーションレジスター)が状態把握するためにSMSのパケットを送ってポーリング(定期チェック)するためのものだ。その隙間がかなり空いているのでメッセージを乗っけてしまえというのがSMSの始まりだ。



SMSはガラケーの時代の初期は非常に使われることが多かったがキャリアメールが登場してからは利用が大幅に減りました。そのかわりMMSや別方式の送信方法が生まれバリエーションは増えたが決定打はスマホの登場だ。完全にインターネットの技術で送信できるためもはやSMSでのメッセージは使われなくなるだろうと思っていたが4,5年前からSMSゲートウェイサービスが増えて認証のワンタイムパスワード送信で送られる需要が急増した。



ここで、一旦話は前に戻すがSMSは携帯電話(スマホが)モバイルセンター側で位置を把握できている状態(電波が届く状態)ならほぼリアルタイムに送受信できる仕組みだ。故に最近の一部のサービスでSMSが遅延してしまうのは不思議とは思っていたところではあったが、問い合わせでの2段階認証のトラブルは今回改めてSMSゲートウェイサービスを調べるきっかけを作ってくれた。



現在2段階認証はメジャーどころのサービス(SNS、決済系、ショップ)では当たり前に普及している。その中の通知手段は色々選択できるがSMSを使った通知が一番多そうだ。実際に便利なのだがここ数ヶ月で頻繁に通知遅延を起こすようになってきたので不思議と思っていたがFBで疑問を投げたところ、運良く知り合いの社長がSMSゲートウェイサービスを提供していて原因を教えていただくことができた。



つまりSMSは基本リアルタイムで送受信できるのだが、サービスで使われている2段階認証のような通知サービスは通知トランザクションが沢山発生するため、SMSの一次受付のシステムがサービス会社側で用意されそこでパスコード生成とメッセージ生成を行い蓄積しSMSゲートウェイサービスに送信しているのだ。だから一時受付システムでの糞詰まりはよくおこるのだそうだ。

更にSMSゲートウェイサービスが日本にある場合、海外にある場合で更に状況が違ってくる。海外の場合複数のキャリアを跨いでリレーしながら交換機が配送するため遅延が生じてしまうのだ。たしか日本ではVodafoneが海外への電話通信の窓口になっているはずだ。AmazonはまさにSMSゲートウェイや一時システムが海外に有るため影響を受けやすい。更にキャリア間のSMS契約が容量で決まっているため、一定時間に受け付けられるSMS数はキャリア毎に決まっているそうだ。フリーSIMだとドコモ、au、ソフトバンクとMVNO業者が契約しておりその間で交わされている仕様やリミッターはベンダーによって様々だ。だからどのベンダーのSIMを使っているかで一定時間にSMSを受け付ける契約状況が違ってくるのはうなずける話。フリーSIMは料金が固定で安いので当然絞りはあるのは間違いない



最後に二段階認証のパスコード発行は一時システムの待ち行列に入ると糞詰まりを起こすと、ユーザ側はついつい再送信をしてしまう。しかし吐き出される順番はFirst in First Outで吐き出されるため、古いパスコードが送られてくるのだ。この状況だとサービス側の持っているコードとコードジェネレータが持っているのが同期取れていないと錯覚してしまう。届かないと思ったら、詰まっているSMSを一旦吐き出させて30分、1時間くらい間を空けて再開するのが良い。

SELinuxを有効のままでWEBデフォルトフォルダ以外のデータ更新を許可

 / Linux Tips, Security Tips, セキュリティ日記, テクニカル, ノウハウ


まっさらのLinuxに新規の場所へWEBのドキュメントルートを作りApacheを起動させると、よくエラーが生じることがあると思います。あるいはWORDPRESSのバージョンアップが出来ないとかフレームワークの更新ができないとか似たようなエラーを体験された方は多いのではないでしょうか。これは概ねお察しの通りSELinuxが有効になっているため起きているのですが、よくある処置はSElinuxをOFFにすることを勧めているケースが殆どです。しかし、SELinuxはセキュリティを高めるための仕組みですから有効のままで使いたいですよね!ということで、そのような場合の設定方法をご紹介いたします。

Apache HTTP Server が使うフォルダーを新規で設定する場合

デフォルトでは/var/www/htmlのみWEBフォルダーとして許可されているので任意の場所にドキュメントルートを設置するなら下記のように指定を行ってください。その後にApacheサーバを再起動すると動作する可能性が高いと思います。

特定のフォルダファイル(画像、文書)をHTML経由で許可、直接ダウンロードは禁止。

 / Linux Tips, テクニカル, トピックス, ノウハウ


例えば、特定サイトのHTMLからリンクされているPDFやWORD,EXCELファイルはブラウザで開けるが、直接URLダイレクトや検索結果のPDFリンクは開けないようにしたいという要望はよくあると思います。通常HTMLやプログラミング言語はサイトの入口を制御しているフレームワーク等のコントローラーでページ制御するため細かいアクセス制限をかけられるのですが、画像やその他の文書ファイルになってくるとどちらかといえばWEBサーバ側の制御配下であるため思ったようにファイルを隠蔽できないという悩みを抱えているエンジニアも多いと思います。今回はちょとした設定でできる制御方法について説明したいと思います。


Apacheの設定でリファラーチェックを入れHTMLからクリックで表示、直接URL指定、検索結果PDFリンクは非表示に!

直接ブラウザでファイルオープンをさせないための上位フォルダーをDirectoryディレクティブで指定しフィルターします。

これでApacheを再起動すれば適用です。.htaccessでやるなら再起動も不要でしょう。

細かくファイルの拡張子まで指定してやりたければFilesディレクティブでパターンマッチさせれば良いと思います。

Apacheのディレクティブで表示結果に出さないよう抑え込む場合

ApacheにおけるSSL設定品質の肝。SSLCipherSuite及びSSLProtocol (POODLE対策)

 / Linux Tips, Security Tips, セキュリティ日記, テクニカル


今はGoogleのオールSSL化の推進によりかなりサイトがSSL接続仕様に変わってきた。しかし、実際のところそれで安心してはならない。SSLの設定のさじ加減というか塩梅によってはダメダメなケースもあるのです。その中でも一番肝と思うディレクティブ設定に以下のパラメータ設定がある。


暗号化通信の方式と暗号化アルゴリズムの選択

下記の設定はタイトルを表す通りの設定を行うApacheのディレクティブです。

  • SSLProtocol
  • SSLCipherSuite

脆弱性のある通信方式

SSLの通信方式には2014年10月に判明したSSL3.0およびTLS 1.0 / TLS 1.1の脆弱性があります。これを「POODLE」という名前で呼んでいます。 もともと、Googleの研究チームがSSLの解析を行い、2014年10月14日に、SSL3.0に関する脆弱性について重大なレポートを行ったのがきっかけです。POODLEは「POODLE(Padding Oracle On Downgraded Legacy Encryption)」の略称でSSL 3.0を有効にしているサーバに問題があると報告していましたが、その後TLS 1.0 / TLS 1.1の一部も問題ありと追加で報告されました。故にApacheでSSLを設定する際にデフォルトで設定していると脆弱性のある通信方式を許容するためセキュリティホールができてしまうのです。つまり、この対策は危険なプロトコルスィートを抑え込む設定が必要となります。

Apacheで行うべき設定

下記は、デフォルトではコメントアウトか、設定がないかもしれません。SSLのコンフィグ設定で追記して登録してください。危険ということで完全な抑え込みの設定をしてしまうと古いブラウザが対応できない場合があるためSSLProtocolの「-TLSV1」を入れるか、入れないかは正にさじ加減かなと思います。

設定後にテストを行う

設定ができたら評価をおこなってください。評価でA+取れるようにがんばってください。今はSNS等も評価がBレベルだとデベロッパーサイトでAPI登録を受け付けてくれないようになってきています。またGoogleもある一定期間の後にSSLの設定レベルの判別を明確にしてゆく話もありますので暗号化スィートの設定は非常に大事です。SEO的に大きな影響をもたらすので今後はApache要の設定となるでしょう。

SSLの設定レベルの品質評価

Python3 Bottleフレームワーク入門(その12)- ReverseProxy方式 Bottle連携SSL Apache起動

 / Linux Tips, Python Bottle Framework, テクニカル, トピックス, ノウハウ


前回の章ではWSGI方式で行ったが今回はRverseProxy方式のApache連携を紹介する。ReverseProxy方式は透過型のProxyで内部で動作しているhttp方式のWEBサーバをお手軽に安全にラッピングしてくれる方式である。内部サーバのコンテンツ作りに不安があるならこの方式が良いと思います。また、内部のシステムが簡単にhttpsに置き換えられないなら、この方法で強引に変更できれば簡単にすみますね!非常に便利なリバースプロキシーです


転送先内部サーバー

いつものごとくありがちなサンプルコード。127.0.0.1で設定しておくと更に安全な接続になります。ローカルホストは外部から接続できませんので。

Apacheのリバースプロキシー設定

ほんのすこしだけ手を加えればリバースプロキシーになります。ProxyPassとProxyPassReverseの箇所だけです。Proxy先のpythonサーバ&プログラムはスレッドセーフになっていることが前提です。

リバースプロキシー起動

サイトにアクセスする例

/hello/の後に任意の文字列を入れてください。ページボディに表示されます。

尚、予めテストサーバにIPアドレスを割り当て名前をWindowsのHostsに登録しておけば下記のように名前ベースのホスト名で実験ができます。



Python Bottle Framework入門 全12回
1.基礎編サーバ起動
2.リクエストメソッド
3.ORM Peewee (MySQL)
4.ORM Peewee CRUD
5.Cookie And Session
6.Abort and Redirect
7.マルチスレッドWEBサーバ
8.デーモン化
9.Json
10.WSGI on SSL
11.Apache連携起動(外部WSGI) SSL接続
12.Apache連携起動(ReverseProxy)SSL接続

合わせて読みたいPython MySQL操作関連

TOPへ戻る

AGA 成長因子