パスワードの「定期的な変更は不要」について思うこと
総務省の「パスワードの変更について方針転換」が話題になっています。
（以下は総務省のページリンク）
設定と管理のあり方｜IDとパスワード｜どんな危険があるの？｜基礎知識｜国民のための情報セキュリティサイト
ニュースサイトなどを見ると、「定期的な変更は不要となった」という部分が非常にクローズアップされているような気もしますが、これは上記リンクのページの上部にある「安全なパスワードの設定」を満たすことが大前提のお話だと思います。
当たり前ではありますが、「123456」みたいな脆弱なパスワードを設定しておいて「定期的な変更は不要」はさすがに「無し」です。（インターネット上のシステムなら結構早い段階で突破されます）
ちなみに会社の業務においては「定期的な変更が必要」な有効な場合もあると思います。
例えば複数人が共通で一つのアカウントを使う場合とか・・・。（業務においてはよくある話）
この場合、共通アカウントを使っている担当者の一人が「別部署に異動した」とか、「退職した」という理由で担当業務を外れた場合、そういった過去の担当者の不正利用（内部不正による犯行）を防止するためにも、例えば月１回など強制的に変更を実施したほうが良い場合もあります。
（「異動や退職が発生する都度行えばよい」という考えもありますが、往々にして「現場」ではやらないことが多い気も・・・）
またシステムが「インターネット上にあるか？社内ネットワーク上にあるか？」「扱う情報が機密情報か？それほど重要でもない情報だけか？」といった「システムの特性」によっても、パスワード管理の考え方は変えてもよいと思います。
セキュリティではよく言われることですが「利用者の利便性」と「セキュリティの確保」のバランスを考慮しつつ、「システム管理者」「システム利用者」の双方にとって安全で使いやすい環境を構築していくべきと思う次第であります・・・。
SCANを受けているポートTOP10
ハニーポット用にたてているWebサーバー。
基本的にハニーポットに届く通信とサーバ管理用で必要な通信ポート以外ブロックをしてログに記録しております。
そこで、どんなサービスに対してスキャンが来ているのだろうと思い、ブロックされているポートと件数TOP10をまとめてみました。
【観測環境】
■観測期間：2018年2月18日~3月20日（30日間）
■観測場所：日本国内IP（一か所しかないです。はい）
1位 23/TCP（9690件） ：いわずもがなTelnet
2位 1433/TCP（2882件） ：SQL Severのポート
4位 8545/TCP（1338件） ：？？？
6位 52869/TCP（995件） ：某メーカー製ルータの脆弱性を狙ったSCAN
8位 8080/TCP（ 885件） ：いろんなサービスで使用中
9位 3389/TCP（ 730件） ：リモートデスクトップ
11位以下は下図ご参照
23/TCPへの通信がダントツですね。
いろいろ検索してみるとMirai-Bot関連のSCANのようです。
日本サイバー犯罪対策センター（JC3）のWebサイトをはじめ様々な注意喚起文が出てました。
これによると2323/TCPや52869/TCPも同じもののようです。
きっとMirai亜種とかいろんなものがいるんだろうなぁ。
Miraiはよく使われるアカウントとパスワードをバシバシぶつけてくるとのこと。
これからインターネットに公開しようとするサーバやIoT機器は標準設定や簡単なアカウント・パスワードを使わず、ちゃんと変更をしましょう。
（既存の機器は乗っ取られていないことの確認が必要かも…どうやって？？？）
念願のハニーポットをたててみた！
このブログを始めたころから、どうにかして「自分用のハニーポットをたてて生の攻撃見てみたい！」と思っていたのですが、Linuxの知識も大してなかったため「攻撃されるサーバなんぞ立てられるのか？？？」と、なかばあきらめておりました。
そうしたところ昨年11月にTwitterで以下のようなtweetを発見！！
morihi-socさん作成の「WOWHoneypot」
第2回ハニーポッター技術交流会で発表した資料を公開しました。→ 初心者向けハニーポット WOWHoneypot の紹介 https://t.co/MbUrt1OSju #hanipo_tech
— morihi-soc (@morihi_soc) 2017年11月25日
これは！！と思い、これまでVPS上に「CentOS＋nginx」で立てていた「ハニーポットもどき」のただのWebサーバーを、Ubuntuに切り替えたりして、ようやく正月明けから観察ができるようになりました。
で、ここ1か月ほどログをとってみたところ、2000件ほどのアクセスをいただきました。（ありがたや～ありがたや～）
アクセスの多い先はこんな感じ。（2018年1月2日~2月3日で合計10件以上をリスト化）
第1位の「GET /maneger/html」へのアクセスはApache Tomcatの管理コンソール？への侵入試行のようです。リクエストの中身を見ると認証情報（ユーザID/PASS）をいろいろ変えてお試しされているようです。
第2位の「POST /command.php」は何やらサーバ上に変なファイルを作ろうと大量のechoコマンドを打ってくれておりました。（しかもご丁寧に2回繰り返して…）
だいたい1秒間隔でアクセスがあるので、プログラムで制御されてるんですかね。
ちなみにすべてのコマンドを全部打ち終わると最終的に「.nttpd」というファイルにして、実行しようとするみたいです。（ネットで検索したところ「BitCoinMiner」のファイル？？？）
第3位、第4位は何をしてるのかわかりません…サーバの調査活動？
第5位以降はphpmyadmin系が多いですね。「ただのWebサーバ」でログ見てた時も結構な量のアクセスあったし、「まぁそうだよね」という感じ。
というわけで、こんな感じで引き続き気の赴くままに観察していこうと思います。
（第2位のやつをもう少し深堀してみようかな…）
セキュリティの「多層防御」について考えてみた
セキュリティ対策を考える際によく出てくる「多層防御」という言葉。
「入口対策~内部対策~出口対策」とか「偵察~武器化~~~目的実行」とか、いろんな流れがあるなかで「各段階で有効な対策を組み合わせましょう」という言葉と思っております。
が、いまいち「じゃぁ具体的にどこまで何しなきゃいけないのさ？」というのがモヤモヤしていたので、そもそもどんな具体策があるのかを自分なりに整理してみました。
以下の具体策はこれまでセミナーで聞いたり、セキュリティベンダの営業の方から聞いたり、ブログで見た内容をもとにまとめたものです。
ちょっとカテゴリ違うんじゃない？と思われるものもあるかもしれませんが、あしからず・・・。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
【主に入口対策】
■通信による侵入を防ぐ（決められた通信だけ入れる）
■Webからのマルウェア侵入を防ぐ（攻撃コードを通過させない）
⇒ExploitKitの配置されたWebサイトへつなげさせない（URLブラックリストによる通信遮断）
■メールによるマルウェア侵入を防ぐ（メール添付ファイルの検知）
⇒メールフィルタリングシグネチャ型
⇒メールフィルタリングSandBox型
■PCに外部媒体からマルウェアを侵入させない
⇒アンチウィルスによる検知
⇒外部媒体接続時の自動実行の抑止
⇒外部媒体を接続させない
■不正アプリからのマルウェアを侵入させない
⇒アンチウィルスによる検知
⇒アプリを勝手にインストールさせない
■PCにマルウェアを保存させない
⇒アンチウィルス（レピュテーション型）
⇒特定フォルダ以外ファイルを保存させない
■過去にPCに保存されたマルウェアを見つける
⇒アンチウィルスによるフルスキャン
■PCで攻撃コードを受信させない
⇒ホスト型IPS
⇒不要なWindowsサービスを停止する
⇒Web分離
■PCでマルウェアを実行させない
⇒振舞い検知させる
⇒マルウェアによく使われる拡張子関連付けの変更する
⇒SandBoxで動かして安全が確認できてから実行させる
⇒マクロの無効化
⇒スクリプト関連プログラムの無効化
【主に内部対策】
■情報に触れさせない
⇒ネットワークによるアクセス先の分離
⇒認証によるアクセス制御
⇒権限によるアクセス先の制御
■権限昇格させない
⇒そもそも論としてユーザに管理者権限を与えない
⇒脆弱性対策パッチ
■遠隔操作させない（アプリを起動させないなど）
⇒脆弱性対策パッチ
⇒レジストリを変更させない
⇒タスクを登録させない（バックドアを作らせない）
⇒スタートアップに登録させない
■不審な処理を検知する
【主に出口対策】
■C2と通信させない（PC）
⇒アプリケーションによる通信制御
⇒PCファイアウォールで特定拡張子のOutBound通信をブロックする
⇒EDRによる端末隔離
■C2と通信させない（NW機器）
⇒URLブラックリストによる通信遮断
⇒IPブラックリストによる通信遮断
⇒通信データ内容で通信遮断
⇒プロキシ認証による通信制御
⇒ポートによる通信制御
■情報を持ち出させない
⇒ゲートウェイ機器で特定拡張子の通信を遮断（RARなど）
⇒ゲートウェイ機器で特定容量以上の通信を遮断（2M以上は遮断など）
■情報を読めないようにする
⇒データを暗号化する
⇒データを暗号化し認証サーバと通信できない場合解読できないようにする
【（ついでに）インシデントレスポンス対応】
■追跡できるようにする
⇒イベントログをPCに保存する
⇒ウィルス検知ログをPCに保存する
⇒メールの送受信内容を保存する
⇒FWの通信ログを保存する
⇒プロキシの通信ログを保存する
⇒ADの認証ログを保存する
⇒ファイルサーバの操作ログを保存する
⇒全通信のパケットをキャプチャする
⇒業務サーバの操作ログを保存する
⇒サーバ系機器の管理者アカウントの認証ログを保存する
⇒サーバ系機器の管理者アカウントの操作ログを保存する
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
実現する製品やソリューションはいろいろあります。（そもそもWindowsの基本機能でできるものもあります。）
また、対策自体もたぶん他にもいろいろとあります。
それに、全部実現したからといって完璧に防げるわけではありませんし、おそらく運用やユーザの使い勝手がものすごく大変なことになると思います。
セキュリティ対策はバランスを考えて・・・
ちなみに私の会社でも実際に行っているのはこの中の一部です。
Webアンケートサイトを立ち上げる時に確認すべきポイント
「Webアンケートサイトを立ち上げる時に気にしたほうがよいポイントって何だろう」というポイントまとめてみました。
企業ではいろいろな部門が情報発信や情報収集のためWebサイトを立ち上げると思います。
手っ取り早くユーザの声を集めたいときなどは、アンケート専用のWebシステムをサービス提供する会社を利用する場合も多いと思うので、その視点でまとめました。
特に「ユーザの個人情報を収集する」場合は、情報漏えいリスクを極力低減させるため、「これくらいは対応できてますよね？」と確認し、もし対応が不足している場合は依頼を控えたほう良いと思います。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
【システムの保管場所】
・システムを設置しているデータセンターにおいて、各種対策（入退室管理、防犯管理、持込・持ち出し管理、耐震・耐水・耐火対策 等）が行われていること
【Webシステムのセキュリティ】
・SSLによる通信暗号化が行われていること
・WAF、IPS/IDSによる不正アクセス対策が行われ、監視されていること
・サーバOS、ミドルウェア等へのセキュリティパッチ適用が適切に行われていること
・各サーバにおけるウィルス対策（リアルスキャン、定期スキャン 等）が行われていること
【提供側の運用】
・サービス提供者側のシステムに対する作業履歴が保存され適時チェックされていること
・インシデントが発見された場合、速やかに契約者に対する連絡が行われること
・インシデントが発見された場合、契約者側からのログ提出依頼等の調査に協力すること
【契約者側（サイト管理者）の運用】
・サイト管理者のアクセス権をアカウント単位で適切に設定できること
・サイト管理者による作業履歴が保存され、適時チェックできること
・サイト管理者の認証について、パスワードの条件設定等による認証強化が行えること
・サイト管理画面アクセスについて、接続元IP制限等により接続制限が行われていること
【データの保存状態】
・アンケートデータを保存するＤＢが暗号化されていること
・システム内に保存されるログデータにアンケートの回答内容が書き込まれない仕様となっていること
・サイト閉鎖時などは、アンケートで回収したデータが確実に消去されること
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Webサイトの構築（これくらいはやってて欲しいOS設定編）
どこの企業も一般の方々向けのWebサイトを立ち上げるのは当たり前の時代です。
Webサイト立ち上げのツールや、安い料金でサイトを立ち上げてくれるサイト構築ベンダなど、いまや簡単にサイトの構築ができます。
でもセキュリティ担当やっていると一抹の不安も…
「ちゃんとセキュリティ対策してもらえているのかだろうか…」
ということで「最低限これくらいやっててくれていればいいのではないか？」と思う対策をまとめてみました。
まず基本的なOS部分について…
①ファイアウォールでインターネット側に開放するポートを適切に設定する
ただの商品紹介したいだけなら、とりあえず80番ポートだけ開放でいいと思うんです。SSHでリモートからメンテナンスしたいなら、追加で22番ポートも開ければいいと思うんです。
「何も通信できない状態」から「必要なポートを開放していく」という考え方にしたほうがよいと思うんです。よく分からないから「何も設定しない（＝全ポート開放状態）」はマズイんです…
②管理者用ログインアカウントの設定を不正アクセスされにくいもににする
「root」とか「admin」とか「user」とか「test」とか、ある程度誰でも想像できるアカウントは使わないほういいです。何せリスト化されてますから…
またパスワードも同様で「password」とか「qwerty」とか「password1!」とか使わないほうがいいと思うんです。きっとリスト化されてますから。
③root権限アカウントの直接ログインを禁止する
上記②で『「root」は使わないほうがよい』と書いておりますが、作業時には「root」が必要な時もあると思います。なので、「root」などはログインアカウントとして使えなくし、別アカウントでログインした後「su」コマンドで利用できるようにしたほうがよいです。
これは万が一「root権限で不正ログインされる」＝「サーバーを一発で乗っ取られる」ということを防ぐため
④SSHでリモート接続が必要な場合は、IPアドレスの接続元制限を行う
SSHはほぼ毎日のように不正アクセスする人たちがドアをノックする感覚でログインしようとしてきます。なので、SSHで接続できる接続元IPをファイアウォールで制限かけるべきと思います。
⑤日々の運用でログイン履歴を確認する
毎日１回とか定期的にOSへのログイン記録を見る習慣があったほうが良いと思います。Webサイトであれば、メンテナンスでもしない限りOSへのログインは発生しないはず。予期せぬ時間帯のログインや、メンテナンスでもないのにログインされたりしていないか？などなど。
他にもいろいろと対策はあるし、強化すべきポイントもあると思います。
ただ自分でWebサーバを立ち上げて日々観察してるなかでは、最低限上記くらいやっておけばお遊びで不正ログインしようとする輩からサーバを守れるのでは？と思いました。
ということでOS設定についてはここまで。そのうちWebサーバー系の部分の書こうと思います。
