隣の家のWi-Fiの電波が届いていたので使ったのだと思いますが、えらい被害になっている情報を発見しました。
https://it.srad.jp/story/19/11/22/1552231/
最近の無線ルータはセキュリティの強度もよくなっているのだとは思いますが・・。
暗号化の認証をかけていなかったのでしょうかね。
利用する場合は、提供元がはっきりしていて暗号化キーのあるWiFiを使いましょう。
フリーソフトやLinux系OSのインストーラのISOなど、インターネット上から自由に入手できるソフトウェアにはよく、”チェックサム”と呼ばれる値がついていることがあります。
このチェックサムとは何かというと、
ある関数を使って特定のデータを計算すると必ず同じ値が得られ、1ビットでもデータが異なった場合は異なった値が出力されるアルゴリズム=ハッシュ関数
によって出された、ダウンロード対象ファイルのハッシュ値のことです。
つまり、公開する側が正規のファイルのハッシュ値を計算したものをを公開しておくことで、そのファイルを入手した人が同じハッシュ関数を使って”本物のファイルが入手できたのか”を簡単に確かめられるようにしてある、ということです。
例えば、もし何らかの方法でダウンロードするファイルが不正にすり替えられていたとしても、1ビットでも異なれば別のハッシュ値が出力されてしまうため、手元のファイルのハッシュ値と比較することで手元のファイルが改ざんされたものかどうかを簡単に調べることができます。
そんなセキュリティ的にも重要なハッシュ関数ですが、WindowsではGUIのツールがデフォルトで用意されているわけではないため、ハッシュ関数の存在を知っていてもセットアップのめんどくささからあまり使わないユーザーも多いのではないかと思います。
実は、コマンドプロンプト上のコマンドによる操作にはなってしまいますが、Windowsに始めからインストールされている、CertUtil というコマンドで簡単にファイルのハッシュ値を求めることができます。
コマンドの使い方としては
CertUtil -hashfile ハッシュ値を出したいファイルのパス ハッシュ関数
のように指定します。
実行すると下記のようになります。
Microsoft Windows [Version 10.0.18362.476] (c) 2019 Microsoft Corporation. All rights reserved. C:\Users\hoge>CertUtil -hashfile C:\Users\hoge\Downloads\linuxmint-19.2-mate-64bit.iso sha256 SHA256 ハッシュ (対象 C:\Users\hoge\Downloads\linuxmint-19.2-mate-64bit.iso): 56f2d0c2b54be0fd66a8cf35799a69d02d4bfdf546b4f946a0b8af01cbbbd689 CertUtil: -hashfile コマンドは正常に完了しました。 C:\Users\hoge>
上記の例はLinuxMintのOSのインストーラーイメージをハッシュ関数にかけた時の結果です。
56f2d0c2b…の一行がハッシュ値となります。
このハッシュ値を公式サイトで公開されているハッシュ値と照らし合わせます。
ばっちり合致したので、改ざんがないことがわかりました。
こういったひと手間をかけるだけでも、ウイルスの被害などから身を守ることができますので、是非積極的に利用していきたいですね。
最近の有名どころのLinuxディストリビュージョンでは、インストールしてすぐに使用できるような状態でApacheやnginxなどのWebサーバーアプリケーションなどのパッケージを公開しています。
そのため、自分で動作のカスタマイズをしたい場合以外は、ほとんどパッケージをインストールして、ファイルを指定の場所に置くだけで、Webサーバーとして機能させることができます。
ところが、これらのパッケージに含まれるサーバーの設定では、デバッグなどでも利用できるように、少し緩めの設定になっている場合が多いです。
ネット上には公開していないテスト環境としてであれば問題はありませんが、本番環境であったりテスト環境であってもネット上に公開されている場合は、デフォルトのままで使用してしまうと危険な設定が含まれている場合があります。
たとえば、CentOS版のApacheパッケージのデフォルト設定では、HTTPヘッダに
“Server”
“X-Powered-By”
といった内容がつきます。
ServerヘッダにはWebサーバーの種類・バージョンが記載されます。
また、X-Powered-Byにはサーバー側でプログラムを使って処理を行った場合に、どの言語・バージョンを使用しているのか、といった情報が載ってきます。
インターネット上にサーバーを公開する際、使用中のソフトウェアのバージョン情報などがわかってしまうと、悪意ある利用者がどういった脆弱性を用いれば攻撃が可能となるかのヒントを与えてしまうことになり、自分のサーバーが攻撃を受ける危険性を高めてしまいます。
したがって、こういった内部の情報は、可能な限り公開しないようにした方がよいとされています。
これらのヘッダ情報は設定を変更するだけで簡単に非表示にすることができます。
Serverヘッダについては、Apacheでは、
/etc/httpd/conf/httpd.conf
内の
ServerTokens OS
などとなっている部分を
ServerTokens Prod
とするとどのバージョンのApacheを使用しているかを非表示にすることができます。
nginxの場合は”http”ディレクティブ内の”server_tokens”のオプションを”off”に書き換えることで同様の設定ができます。
http {
...省略...
server_tokens off;
...省略...
}
また、PHPを使用していて、X-Powered-Byがヘッダに含まれている場合は、php.iniの
expose_php = On
を
expose_php = Off
に変更することで X-Powered-By の記述そのものを削除することができます。
実際に今動作させているサイトが、どのようなヘッダーを吐き出しているのかを確認することも大事です。
Chrome・Firefoxなどの主要ブラウザでは、F12キーを押すと開発者ツールが開きますが、その中の”Network”タブを確認すると、どんなヘッダが各コンテンツにくっついているのかを確認することができます。
ネット上に公開する際は、どういった情報をサーバーが公開しているのかを調べておくのがおすすめです。
最近またパスワードの使い回しによる被害のニュースが増えている気がします。
対策としては SMS やメール、ワンタイムトークン等、多要素認証も重要があげられていますが、今の被害状況を見る限り、 人間には覚えられない様に毎回パスワードをランダム発行し、クラウド上に残らない、紙やメモ、ファイル等で保管することでほぼ防げると思います。
もしパスワードを保管するクラウドサービスを使う場合は、そのサービスに対しては多要素認証は必須。最悪、パスワードを保管するサービスが漏洩したときの対策も重要。
皆さんも、頭で覚えられるパスワードは設定しないでください。ながければ良いということでは無いが16桁位の英数大小記号入なランダムパスワードがおすすめです。
首里城が焼けてしまいました。
首里城へは一度だけ近くへ見に行ったことがあります。中は入らなかったのですが、なんで入場しなかったかは覚えていません・・・・。
那覇・首里城で火災、正殿など7棟焼失 31日午後鎮火
https://www.nikkei.com/article/DGXMZO51617010R31C19A0CE0000/
まだ原因はわかっていませんが、工事の電源熱による火災なのでしょうか。
クラウド化やアウトソースであまり直に触ることは少なくなりましたが、24時間365日稼働するサーバやネットワーク機器を扱っているので、電源から発生する熱についてはかなり注意しています。ホコリもそうです。
自宅でも、ホットプレートや、ドライヤー、溶接機なども使うとケーブルが熱くなるのですぐわかると思います。
使用容量の大きそうな機器を接続したときは、電源ケーブル握って熱くないか、溶けてないか、確認必要ですね。
また乾燥する季節なので、改めて電源廻り、要確認です。
先日、気になるニュースを見かけました。
CookieはステートレスであるWebの仕組み上ユーザーを識別する数少ない手段となっています。
例えば、会員制サイトでアクセスしてきたユーザーがログイン済みなのか、まったく関係のない(会員ではない)部外者なのか、の判別にはCookieの存在が不可欠です。
Cookieがなければ、ログインを前提とした会員制サイトを作ることは事実上難しくなるでしょう。
正確にはCookieのURLにセッションIDを乗せることで、Cookieを使用しない状態の管理行うことはできますが、URLはCookieよりも漏れやすい情報(ユーザーがURLを意図的に保存しなくても、ブラウザの履歴に残ったり、リファラーという仕組みで分かってしまったりする)ため、URLを盗まれてしまうと第三者が正規のユーザーに成り代わって会員サイトを操作できてしまう”セッションハイジャック”が発生しやすくなってしまいます。
ただし、クッキーレス・セッションにはセキュリティ上の問題がある。というのも、クッキーレス・セッションを利用した場合、(当たり前の話であるが)セッションIDが一般ユーザーの目に直接さらされることになる。つまり、URLさえ分かってしまえば、第三者による「なりすまし」も可能であるということだ。
[ASP.NET]クッキーをサポートしないクライアントでセッション機能を利用するには? – @IT
ただし、このクッキーレス・セッションの脆弱性の問題は、クッキー経由でセッションIDの受け渡しを行った場合でもさほど事情は変わらない。ネットワークをモニタすることで、クッキーの内容などは簡単に盗聴できてしまうからだ。ただ、URLの方が「なりすまし」も「盗聴」も簡単であるという意味で、より危険であるといえる。しょせんは相対的なものといってしまえばそれまでだが、安全性がより重視される局面で、無用にクッキーレス・セッションを採用するべきではない
もちろんURLによるクッキーレス・セッションもシステムによっては適用できる場合もありますが、セキュリティに気を使いたいサイトの場合は当然 Cookieという選択肢が存在しなければなりません。
Cookieという選択肢が取れなくなってしまった場合は、非常に大きな問題です。
そのような技術的な裏側を知ってか知らずかわかりませんが、昨今”個人情報保護”という観点だけを重視してしまい、Cookieを規制しようとする政治的な動きが出てきていますが、正直言って理解に苦しみます。
もっとも、現在多くのサイトで行われている”Cookieを使用することに同意を求める”だけであれば(めんどくさいですが)画面を追加するだけなので問題ありません。
しかし、Cookieの使い方そのものを規制するような動きが万が一出てきた場合、ITインフラそのものを崩壊に追い込んでしまうことも考えられます。
現状”Cookieを規制するようだ”という動きだけニュースになっていて、具体的にどのような規制が行われるのかを説明しているところはまだないようですが、いくらITに詳しくないとはいえ、”知らないから”という言い逃れは許されない問題です。
関係者の方には是非Webの技術やCookieをなぜ使用するのかをきちんと勉強していただいた上で議論していただきたいと思います。
最近、格安で購入できるバッタモンでも満足できる品質に追いついていて、非常に助かります。真似して技量をアップして、より良い製品を作る。原点に戻って腕を磨かなくては。
脆弱性が出たので更新しました。ついでに clamav も出ているので更新準備に入ります。
twitter で見かけましたが、ubound が設定楽なんだとか。bind でも DNSSEC とかしなければ、そう面倒なことは無いと思いますが、powerdns や ubound こういった対応が少なくなるのであれば、手を出してみたい。
最近のUNIX系のOSにおいて、直接rootユーザーとしてログインする代わりに、1コマンド単位でroot権限に昇格できるコマンドとしてsudoが用意されています。
現在では、rootユーザーとしてログインするよりも一般ユーザーでsudoを使用した方が安全といわれていますが、そんなsudoに先日、ちょっとマズい脆弱性が発覚しました。
Linuxの「sudo」コマンドにroot権限奪取の脆弱性。ユーザーID処理のバグで制限無効化 – engadget 日本版
sudoには特定のコマンドのみroot権限で実行可能とするような、各ユーザーに対するコマンド単位での制限を設定することができます。
例えば、設定ファイルやサービスの起動・停止はできるようにしたいが、サーバー自体の再起動・停止はさせないようにしたい…などどいった場合は、対象のユーザーに対してのみshutdownコマンドなどをroot権限で実行することを制限することができます。
ところが今回、sudoコマンドでrootユーザーではなく特定のユーザーとして実行すると、sudoersで指定された制限を無視して、すべてのコマンドをroot権限として実行できてしまう現象が発見されました。
sudo で UID に「-1」または「4294967295」を指定すると root 権限でコマンド実行出来る脆弱性 – らくがきちょう
詳細は上記のリンクを参照いただきたいのですが、一部のコマンドのみsudo経由で実行できるように許可されたユーザーにおいて、ユーザーidが”-1″、もしくは” 4294967295″のユーザーを指定した場合にsudo のバグで制限なくroot権限が発動できてしまう、というのが今回判明した現象です。
なお、もともとsudoを使用する権限が一切ないユーザーについては上記のユーザーidのユーザーとして実行しようとしてもはじかれる為、管理者でない一般ユーザーが管理者権限を行使できてしまう、といったことはないようです。
自分でも更新前のsudoで試してみましたが、昇格はできませんでした。
sudo -u#-1 service nginx reload
[sudo] password for testuser:
testuser is not in the sudoers file. This incident will be reported.
基本的にsudoは完全な管理者として昇格する以外の使い方はあまりされていない印象なので、おそらく影響を受けたユーザーはさほど多くないかと思いますが、もしコマンド単位での制限をかけている場合は、早急にsudoのアップデートを適用すべきでしょう。
来年2020年1月14日で Windows7 のサポートが終了しますが、有料でサポートを購入する事もできる様な情報が出てきました。
米マイクロソフトはこの方針を転換。ボリュームライセンス契約を結んでいるかどうかにかかわらず、あらゆる企業がWindows 7の延長サポートを購入できるようにすると発表しました。
今回の発表で新たにWindows 7 ProfessionalとWindows 7 EnterpriseのESUが、マイクロソフトのクラウドソリューションパートナー経由で12月1日より購入可能になります。
https://www.publickey1.jp/blog/19/windows_72023.html
Windows 7 ESUはデバイスごとに販売され、1年ごとに料金が値上がりしていく予定。
どうしても Windows7 を安全に使い続ける必要がある場合は、ボリュームライセンスでなくてもこの有償サポートを購入する事で維持ができそうです。
ただし年々料金が上がっていく仕組みらしい。
ホモグラフ攻撃とは直訳で人間的図形攻撃です。具体的に何をするかというと、視覚的に似た別の文字を用いてユーザの想定と異なる動作を誘発させます。特に重要で代表的な例はURLにおける攻撃で次例です。
https://www.аррӏе.com/
https://www.apple.com/
上の二つのURLは異なるURLです。上の側だけ英語小文字に似た文字でドメイン名を記述してあります。これでユーザを誤ったURLへ飛ばし、飛び先のページで実行されるコードに悪意あるコードを仕込むことによって本格的な攻撃をします。
この攻撃はユーザの運用によって完璧に防ぐことは困難です。いちいち文字コードや言語情報をチェックしていたらとても耐えられない不便をこうむります。この点、ブラウザがいくらか対策してくれています。例えばGoogle Chromeはο(オミクロン)を使ったgoogle.comへのアクセスを次の様に止めてくれます。
PHPはホモグラフ攻撃の対策(主に踏み台にされないため)としてホモグラフ攻撃用文字列を検出するためのクラスSpoofcheckerを持っています。これを使えば怪しげな投稿やメールアドレスの多くを弾けます。
PHP:Spoofchecker-マニュアル
簡単な使い方は次です。
public function isSafe($value){ $checker = new Spoofchecker(); $checker->setRestrictionLevel(Spoofchecker::制限レベル);// PHPリファレンスに記述はない(!?)が実装されている $checker->setChecks(Spoofchecker::チェックルール); return !$checker->isSuspicious($value);// isSuspicious関数は疑わしい時にtrueを返す }
制限レベルはPHP:Spoofchecker-マニュアルの定義済み定数の内のASCIIからSINGLE_SCRIPT_RESTRICTIVEまで、チェックルールはSINGLE_SCRIPT_CONFUSABLE以下です。デフォルトレベルはHIGHLY_RESTRICTIVE、デフォルトルールはSINGLE_SCRIPTです。詳しい各ルールの説明ドキュメントはPHPリファレンス内に存在しません。
雑に使ってもそれなりに役に立つのですが、せっかくなのでルールの詳細が知りたいです。C言語で構築されたPHPのSpoofcheckerの実装は次です。これを読めば多少わかります。
php-src/ext/intl/spoofchecker at 49a4e695845bf55e059e7f88e54b1111fe284223 · php/php-src
このディレクトリの内部を読むとC言語のuspoof機能を使っていることがわかります。C言語のuspoof機能のリファレンスは次です。
ICU 64.2: uspoof.h File Reference
両方を参照すると制限レベル、チェックルールの二段階設定であることがわかります。
制限レベルはICU 64.2: uspoof.h File Reference#URestrictionLevelで説明されています。日本で使うサービスとしてはデフォルト制限レベルであるHIGHLY_RESTRICTIVEがふさわしいでしょう。HIGHLY_RESTRICTIVEは日本語セット、中国語セット、韓国語セットのいずれのセットの中に納まらない文字列を怪しい文字列として疑うレベルです。
チェックルールはICU 64.2: uspoof.h File Reference#USpoofChecksで説明されています。制限レベルをそのまま適用するRESTRICTION_LEVELが扱いやすそうです。PHPのデフォルト設定はSINGLE_SCRIPTですが、SINGLE_SCRIPTは既に非推奨でRESTRICTION_LEVELに置き換えられます。
リファレンスが不親切で実装まで調査しましたが単に次のように使えばよさそうです。
public function isSafe($value){ $checker = new Spoofchecker(); return !$checker->isSuspicious($value);// isSuspicious関数は疑わしい時にtrueを返す }
ちなみに各制限、各ルールで最上部の例のapple.comが安全ならtrue,違うならfalseにする関数でテストしたところ次結果になりました。読みづらいのは申し訳ないですがコピペとか見ている画面のデザイン変更で対応していただきたいです。
SINGLE_SCRIPT_CONFUSABLE | MIXED_SCRIPT_CONFUSABLE | WHOLE_SCRIPT_CONFUSABLE | ANY_CASE | SINGLE_SCRIPT | INVISIBLE | CHAR_LIMIT | |
---|---|---|---|---|---|---|---|
HIGHLY_RESTRICTIVE | true | true | true | true | false | true | true |
MODERATELY_RESTRICTIVE | true | true | true | true | false | true | true |
MINIMALLY_RESTRICTIVE | true | true | true | true | true | true | true |
UNRESTRICTIVE | true | true | true | true | true | true | true |
SINGLE_SCRIPT_RESTRICTIVE | true | true | true | true | false | true | true |