日次のLogrotateがうまく機能しなかったときのメモ
はじめに
知ってか知らずかLinuxを運用している人は使っているLogrotateですが、あるとき急にログをローテートしてくれない状態になり困ったので、その原因と解決策を述べます。
Logrotateってなに？
Logrotateの目的
Logrotateとは、その名の通りをログをローテートしてくれるツールです。ログをローテートするとは、ログファイルが肥大化しないように各プロセスが現在書き込んでいるファイルを一旦横において、また１から別のファイルに書き始めさせることです。一旦横に置いたファイルは、圧縮するなり削除するなりが可能となります。一つのファイルに書き込み続けるとファイルが肥大化して書き込めなくなる、ディスク容量を等の問題が発生するため、ログローテートはシステムの安定的な運用に必須です。
Logrotateの仕組み
Logrotateコマンドは、cronで日次で実行されるようになっています。
そして、logrotate.confに設定された内容とlogrotate.statusに記録されているローテーションのステータスを確認することで、ログのローテーションを実施します。
おおまかな流れ（syslogと/var/log/messagesの場合）
- /var/log/messagesを、/var/log/messages.1に移動
- 新しいファイル/var/log/messagesを作成
- syslogプロセスの再起動
3のプロセス再起動は、syslogプロセスが新しいmessagesファイルを向くようにするために実施されます。
logrotate.confの設定次第ではこれとは異なる動きをします。
Logrotateが期待通りに動かない
logrotate.confやlogrotate.statusを確認しましょう。多くの場合、そこを確認することで解決します。
しかし、私が直面したのはDailyのcronによるlogrotateが動かなくなったという事象です。マニュアルでlogrotate /etc/logrotate.confを実行すると期待通りに動作しました。もちろんlogrotate.statusも問題ありませんでした。
原因は、前回cronで実行されたlogrotateプロセスが完了せずに残っていたことによるものでした。プロセスをKillすることで問題なくDailyで動くようになりました。
まとめ
色々検索してもでてこなかったので、備忘のために残しておきます。同じように困った人の助けになればと思います。
# なんだかんだ困ったときはサーバのリスタートが手っ取り早いです。
人生におけるリスクやコストと子育ての意味
以下記事を読んでちょっとひっかかったので、私の考えを述べたいと思います。
子どもがいることの幸せや嬉しさを、ロジックで説明することは出来ない: 不倒城
リスクやコストで人生をはかる人に「子育ての意味」は届くのだろうか - シロクマの屑籠
子供を育てることのリスクやベネフィットを単純にその人「個人」で捉えた場合は、上記記事にあるように、ハイリスクでかつリターンが不明瞭であり、投資先としてはよいものではないと思います。それよりは、自分自身に時間と金を投資するほうがリターンが確実にみえるでしょう。
ただ結局子育てって、生物としての多様性だったり、家族の子孫繁栄だったりに結びつく話で、単純に「個人」だけを評価のものさしにする話ではないように思います。人間という生物が作り出した種を生き残らせるすべこそ、世代交代による多様性の確保であり、そこにこそ子育ての意味があるのではないでしょうか？
もちろんしんざきさんの記事中（一つ目の記事）で記載されていました子育ての中で「幸せを感じる・嬉しさを感じる」気持ちは、私も二児の親ですし、よく分かります。この辺の感性は恐らく生物の本能としてプログラムされているものなのではないでしょうか？このため、本能より理性（ロジック）が強ければ、子供を産み育てようとならないのもうなずけます。
つまるところ、性行為だって、何のためにやっているんだという話となりますが、性行為は三大欲求に位置づけられるほど強い欲求となっています。これは、性行為と子育てが本来地続きとなっているもので、性行為をしたら子育てもついてくるものだったため、生物の本能としてそこまで子育て欲求を強く作らなかったのでしょう。「避妊」という技術を生み出したことによって、その性行為からつながる子育てが分離されてしまい、人間という生き物の子孫繁栄システムのバグが明らかになった結果が、現代の少子化なのではないでしょうか？
Caller ID（発信元）偽装とその対策
はじめに
Robocallと呼ばれる自動電話による通知は、日本ではあまり主流ではないですが、アメリカでは多く利用されています。クレジットカードの不正利用の確認であったり、病院予約の確認等、様々な場面で使われています。
一方で、自動電話の仕組みにのっかって詐欺を働こうとするソーシャルエンジニアリングが流行っています。
本稿では、世の中で起きている実際の事件を紹介するとともに、アメリカではどのような対策が進んでいるかご紹介したいと思います。
Appleを騙った詐欺の事例
Apple Phone Phishing Scams Getting Better — Krebs on Securityで紹介されている例を挙げたいと思います。この例では、iPhoneの仕様とあいまって非常に巧妙なものとなっています。
1.ユーザへAppleからと思われる自動電話がかかってくる。（複数回同一の発信元から電話をかかってくる）
2.ユーザが電話に応答したところ自動音声で、「Apple IDを管理する複数のサーバが侵害された。指定された電話番号に電話してください」という内容が流れる。
3. 指定された番号にかけると、「Appleのカスタマーサポートです。待ち時間は、XXです。」といった音声が流れ、最終的にサポートとつながり、情報をとられる。
以下が実際にかかってきた電話の履歴画面ですが、Appleの番号でかかってきているかのように表示されます。
発信元の偽装はなぜできる
上記の例では、攻撃者はAppleの番号を偽装していますが、これはなぜ可能なのでしょうか？
これは、電話事業者間の電話の取次ぎの仕組みに由来します。ある電話事業者Aの番号から、電話事業者Bの番号へ電話を発信する際、AとBで接続するところで発信元の番号を指定して、電話の発信を行います。このため、発信者番号指定サービスなども存在している。日本の携帯電話事業者は、海外からの発信について厳密にチェックするようになり偽装は難しくなったものの、IP電話や固定電話等からの接続など多岐にわたるため、厳密にチェックすることが厳しい状態にす。
アメリカでの対策状況
法的な対策
アメリカでは深刻な問題になっているため、州や連邦での法律が整備されてきています。
違法な発信元偽装を行った場合の罰金額の強化や電話事業者の監視プロセス（電話事業者が積極的に違法な自動音声をブロックすることを容認する法律）の整備などを目的にした法律で、ここ2,3年様々な州で導入が進んでいます。
Federal Communications Commisions（米国連邦通信委員会）は、下記に述べる技術的な対策を2019年中に実装するよう各電話会社に求め、各社それに応じている*1
技術的な対策（SHAKEN/STIR）
SHAKEN/STIRとは、Signature-based Handling of Asserted Information Using toKENs (SHAKEN) and the Secure Telephone Identity Revisited (STIR) standardsの略であり、電話事業者間で接続する際の発信元番号の検証方法について定めた基準です。
発信元番号は発信元の事業者によって署名され、接続先の事業者によってその署名を検証することで、発信元番号の偽装がないか検証することが可能となっています。検証がうまく通らない場合は、発信を拒否し、受電側に発信しないようにする仕組みです。
まとめ
対策は進んでいますが、攻撃する側と守る側は常にいたちごっこです。新たな偽装方法で、技術的な対策も回避するケースもでてくるのではないかと思います。
個人レベルで出来ることは少ないですが、企業のサポートはユーザからリクエストしない限りは電話をかけてくることは通常ないため、疑ってかかるべきです。また、こういった詐欺が行われていることを知識として持っているだけで、大きな対策になりますので、周囲の友人・知人にも共有いただければと思います。
ぜい弱性対応のあるべき姿（Equifaxの事件を振り返って）
はじめに
以前に、ぜい弱性対策こそ、いの一番でやるべきセキュリティ対策であるということをお伝えしました。とはいえ、実際のところ、様々なシステムを運用している中で、ぜい弱性をそもそも認知できていない、ぜい弱性が発見されたところで全て対応できないというケースも多いのではないでしょうか？
本記事では、ぜい弱性が発見された際にどのような対応していくべきかのガイドをお伝えしたいと思います。
shoulders-of-giants.hatenablog.com
ぜい弱性対応の不備で発生した大規模情報漏えい
米Equifaxの情報漏えい事件は、ご存知でしょうか？
1億5000万人もの個人の情報が漏洩しました。その個人情報には、名前や住所、生年月日、運転免許証、さらにはSocial Security Numbersまで含まれていた可能性があり、史上最悪の事件と言われています。
このEquifaxの情報漏えい事件は、ぜい弱性対応の不備で発生したものです。Equifaxの提供するWebサービスで利用されているApache Strutsのぜい弱性をつかれたことにより情報漏えいにつながったといわれています。Equifaxの担当者は、Apache Strutsのぜい弱性を認識していたにもかかわらず、パッチ未適用なまま放置されてしまいました。Apache Strutsのぜい弱性は非常に有名なものであったため、ぜい弱性公開の2日後にはEquifaxのサーバに当該ぜい弱性の有無を確認するスキャンが行われており、5日後には実際に攻撃者は侵入に成功したといわれています。
ぜい弱性対応の流れ
Equifaxのような不幸な事件が発生しないように、企業においてはぜい弱性対応のプロセスが明確に定義されている必要があります。
大きな流れとしては下記の通りです。
- システムの利用しているソフトウェアの把握
- ぜい弱性情報の収集
- ぜい弱性が発見された際の対応
1,2については、ぜい弱性管理ツールを利用するのが手っ取り早いかと思います。
3.については、明確な定義がなければ、各システムの担当者や情報セキュリティの担当は、各々の判断でパッチ適用を実施してしまいます。それでは、本当に適用すべきパッチが未適用なまま放置されてしまう可能性があります。
では、3.のぜい弱性が発見された場合の対応ですが、どのような対応をとればよいでしょうか？
ぜい弱性対応のあるべき姿とは？
ぜい弱性対応は、事前の準備が非常に重要になります。
Equifaxから、以下の点が大事であることが学べると思います。
- ぜい弱性の情報を届くべき人のところに届けられるようにする
- 自システムにおけるぜい弱性の有無の検証方法の明確化にする
- ぜい弱性の緊急度に応じて優先度付けを行う
コミュニケーションパスの定期的な確認、ぜい弱性管理ツールの利用方法の明確化などを実施し、ぜい弱性が発見された際は漏れなく担当者が確認できる仕組みづくりが必要といえます。3つ目のぜい弱性の緊急度については、詳細に述べたいと思います。
ぜい弱性の緊急度
ぜい弱性の緊急度が組織として定義されていることにより、システムの担当者は容易に「すぐに」対応すべきぜい弱性かそうでないかを判断できます。万が一、ぜい弱性をつかれてしまい情報漏えいした場合にも、組織を守る、担当者を守る意味でも、ぜい弱性の緊急度とその対応方針は非常に重要な規定となります。
以下の4つの観点からぜい弱性の緊急度を定義することをお勧めします。
攻撃元のネットワーク × 攻撃条件の複雑性 × 攻撃可能性 × 攻撃成功時の影響
- 攻撃元のネットワーク
インターネットから攻撃可能か、隣接ネットワークなら可能か、対象デバイスへの物理アクセスが必要か - 攻撃条件の複雑性
認証が必要、長時間の攻撃試行、複数のぜい弱性の連鎖が必要など - 攻撃可能性
ぜい弱性の対象プロダクトの世間の知名度、PoCコードあり、実際に攻撃あり - 攻撃成功時の影響
ぜい弱性のあるプロダクトを利用しているシステムが、重要な情報を保持しているか、ダウンした場合の影響が大きいか
これらに基づき、緊急度が高なら2日以内にパッチ適用、緊急度中なら1ヶ月以内にパッチ適用、緊急度低なら3ヶ月以内にパッチ適用等定めるとよいと思います。
なお、ぜい弱性の緊急度の判断をCVSSに基づいて実施しているという方もいると思いますが、現時点でCVSSはあまり有効な指標とはいえません。*2
まとめ
Equifaxの事件を振り返りながら、ぜい弱性対応のあるべき姿を述べました。
企業の担当者は、不足している点について改めて見直してみるとよいのではないでしょうか？
人のぜい弱性（スマホを落としただけなのに）
はじめに
ぜい弱性対策が、まず第一に実施すべき対策だということを以前の記事で述べましたが、それはシステムのぜい弱性対策だけではなく、人のぜい弱性対策も同様です。
企業の情報セキュリティにおけるWeakest Linkはなにかと聞かれたときは、私は「人」だと答えるようにしています。成功している攻撃の多くは、ソーシャルエンジニアリングを起点としています。映画にもなった小説「スマホを落としただけなのに」を読むといかにソーシャルエンジニアリングが怖いものか理解できますので、ぜひ一度読むことをお勧めします。攻撃者はあの手この手でユーザの情報を取得し、だまそうとしてきます。
スマホを落としただけなのに (宝島社文庫 『このミス』大賞シリーズ)
- 作者: 志駕晃
- 出版社/メーカー: 宝島社
- 発売日: 2017/04/06
- メディア: 文庫
- この商品を含むブログ (3件) を見る
本記事では、実際に世の中に起きている事件を例にあげつつ、取るべき対策について述べたいと思います。
ソーシャルエンジニアリングとは？
ソーシャルエンジニアリングとは、一言で言うと詐欺のテクニックです。オレオレ詐欺は、典型的なソーシャルエンジニアリングです。
昨今では、インターネット上に様々な個人情報をみなさん載せていますので、攻撃者は容易に情報収集ができ、攻撃（詐欺）に利用することができます。
Facebookで、趣味の情報や誕生日、どの辺りに住んでいるかなどが簡単に入手できてしまいます。LinkedInでは、どのような上司のもと働いているかなどもわかります。
これらの情報を使って、攻撃者は巧みに知人などになりすまし情報を奪ったり、金銭を奪ったりします。パスワードを類推するのにも悪用されます。
ソーシャルエンジニアリングによる事件
日本航空（JAL）さんが、不正な口座に3億円以上もの大金を振り込んでしまった事件は記憶に新しいと思います。
tech.nikkeibp.co.jpGoogleやFacebookも同様に計$100 Million（約110億円）を振り込んでいます。
いずれもEメールをたくみに利用した詐欺でしたが、昨今はそれ以外にも携帯電話（スマートフォン）を狙った攻撃もはやってきています。コミュニケーションの起点がスマートフォンになってきていることから、攻撃者にとっては格好のターゲットとなっています。
- Vishing - 音声通話を利用した詐欺（Voice Phishing)
- SMSishing - SMS（メッセージ）を利用した詐欺（SMS Phishing)
- そのほか、Facebook Messenger等のアプリを通じた詐欺
ソーシャルエンジニアリング対策
月並みですが、エンドユーザの教育が非常に重要になります。みなさんも年に1回ほど、会社から情報セキュリティ研修を受けさせられていませんか？各従業員の意識こそが企業にとっての最終防衛ラインです。
各エンドユーザが実際に世の中にどういう脅威があって、詐欺にだまされた場合どのような結果につながるのか認識いただくことで効果的な対策が可能になります。
また、一度の教育だけではなく、継続的に教育を行うことが重要です。一般的には、PhishmeやKnowBe4といったツールを使って、訓練用のPhishingメールを従業員に送り、開封状況を確認するなどして、継続的な教育および改善を行っているケースが多いです。
まとめ
筆者自身、クロネロヤマトという明らかに詐欺メールだと分かるようなPhishingにひっかかりそうになったことがあります。クロネコヤマトが荷物を届けてくる予定だったので、危うくひっかかるところでした。自分に身近な内容でPhishingがきたら簡単にひっかかってしまうのではないでしょうか？攻撃者は、Facebook等を通じて、情報を収集できます。
自分には無関係という意識がPhishingにひっかかる原因にもなりますので、情報セキュリティ教育の実施をお勧めいたします。
そのほかにも
情報セキュリティ対策で一番にやるべきこと
はじめに
Ransomwareをはじめとしたマルウェア感染、Spamメール等、企業だけでなく個人レベルでも情報セキュリティについて意識する必要が出てきています。
ウイルス対策ソフトいれておけば十分と考えている企業、個人もいるかもしれませんが、ウイルス対策ソフトよりも優先的に対策すべきことがあります。
それは、ぜい弱性対策です。なぜ、ぜい弱性対策が一番重要であるか説明したいと思います。
ぜい弱性対策とは
ぜい弱性対策とは一言で言うと、弱いところを塞ぐ対策です。家で例えてみますと、壁に開いたのぞき穴を塞ぐであったり、ピッキングされにくい錠前にするといったことです。
ぜい弱性対策は、パッチ管理、脆弱性管理のツールを導入して、各PC・サーバにあるぜい弱性を可視化したうえで、緊急度に応じてパッチ適用、ワークアラウンドの適用を実施する対策です。個人レベルでは、ソフトウェアの自動更新設定でだいたいはまかなえると思います。最近のウイルス対策ソフトはぜい弱性チェックもしてくれる製品もありますので、そちらを活用するのもよいかと思います。
なぜ、ぜい弱性対策が大事か
OSやソフトウェアは、人が作るものですので、どうしたってぜい弱性が作りこまれてしまいます。そのぜい弱性を狙って多くの攻撃者が攻撃してきます。
年間14,714ものぜい弱性が発見されています。*1
その数は、年々増えています。
ウイルス対策のほうが大事という方もいるかもしれませんが、家の例で例えてみると分かりやすいと思います。家に泥棒が入られたあと追い出す仕組みを用意するよりは、そもそも入られないようにするほうが大事だというのは同意いただけると思います。
最近は、新種のマルウェアが毎秒4件も作成されているという統計がでています*2。ウイルス対策では限界があることも分かると思います。
企業におけるぜい弱性対策
企業においては、ぜい弱性対策の重要性はわかっちゃいるけど、業務影響があるからといって、なかなかパッチ適用ができていないところもあると思います。このような場合は、企業としてぜい弱性検知時の適用ポリシーを明確にすることをお勧めします。企業としてリスクをどこまでとるかを明確にすることでもあるため、担当者レベルで二の足を踏まずに済み、ぜい弱性の緊急度合いに応じて速やかなパッチ適用が可能になります。
サーバやPCの設定の堅牢化もコストのかからない有効なぜい弱性対策ですので、積極的に実施されることをお勧めします。OpenSCAPといったセキュリティ設定のチェックツールなどを活用すると、必要な堅牢化設定も可視化できます。
まとめ
世の中で発生しているセキュリティインシデントは、ぜい弱性起因のものが非常に多いです。それはゼロデイと呼ばれる未知のぜい弱性ではなく、大半は既知のぜい弱性によるものです。設定ミスであったり、パッチの未適用であったり、残されたぜい弱性を攻撃者は巧みについてきます。まだぜい弱性対策が実施できていない企業は、すぐにでも開始されることをお勧めします。
*1:cvedetails.comから筆者が集計
日本企業も知るべきCCPA (California Consumer Privacy Act)について
はじめに
CCPAとは、カリフォルニア版のGDPRだと言われているカリフォルニア州法です。
GDPRが呼び水となって、昨今のプライバシー情報への関心の高まりから、カリフォルニアでも消費者のプライバシーに関する法律が制定されました。
2020年1月に有効にされるが、GDPR同様にカリフォルニア州内の事業者のみに適用されるわけではなく、カリフォルニアの居住者にサービス提供する事業者に適用される法律です。つまり、CCPAは日本企業にも適用されます。
本稿では、CCPAについて簡単にご紹介したいと思います。
- そもそもCCPAってなに？
- 保護対象の情報はなに？
- 規制を受ける対象はなに？
- タイムラインは？
- GDPRとの違いは？
- おまけ（成立の経緯）
そもそもCCPAってなに？
California Consumer Privacy Act （CCPA）とは、消費者に自身の個人情報の取り扱いをコントロールする権利を与えるための法律です。
2018年の6月にカリフォルニア州政府によりカリフォルニア市民からの要望を受け*、法律として制定され、2020年1月より有効にされます。
*おまけをご覧ください。
CCPAは、消費者に大きく以下4つの権利を与えます。
- 知る権利
- オプトアウトする権利（消費者の情報を第三者に売却することをとめる権利）
- 削除する権利
- 消費者情報提供によらず同一のサービスを受ける権利
知る権利
消費者は、事業者がどのような個人情報を収集し、どう利用されているか知る権利。具体的に下記の通りです。
- 収集された個人情報の種類とその内容
個人情報の収集時に、収集する個人情報の種類とその利用目的を消費者に提示する必要があります。 - より詳細な個人情報の内容
どこから収集されたか、個人情報の収集/売却の目的、第三者への提供と提供先の種類、具体的に収集された個人情報の内容 - 個人情報の売却
過去12ヶ月間に売却または提供された個人情報の種類およびその目的
1,2については、事業者は無料で提供する義務がありますが、12ヶ月の間に2回まで対応すればよいとされています。
また、消費者からリクエストを受けてから45日以内に回答をする必要があります。（加えて、本人確認をする必要があります）
オプトアウトする権利
消費者の個人情報を事業者が売却することを、消費者が拒否する権利。
一度消費者が拒否した場合は、今後消費者から許可がない限りは、個人情報の売却はできません。さらに、少なくとも12ヶ月は、消費者に売却の許可を求めてはいけないことになっています。
また、子供（１６歳以下）に関しては、そもそも売却する前に許可を取る必要があります。（オプトアウトではなくオプトイン）
削除する権利
事業者のもつ個人情報の削除を依頼する権利。
本人確認後実施する必要があります。
消費者情報提供によらず同一のサービスを受ける権利
上記の3つの権利を行使したとしても、変わらず同一のサービスを受ける権利。
保護対象の情報はなに？
CCPAでは、個人情報（Personal Information）を保護対象としていますが、一般的にいう個人情報とは様相が異なります。一般的な個人情報は、個人の特定が可能な情報（PII）としてることが多いが、CCPAでは「特定の個人あるいは家庭に対して、直接的ないし間接的に識別、関連、説明、結び付け、あるいは合理的にリンク可能な情報」と定義しています。CCPAでは個人情報に、家庭を識別する情報も含まれていることが大きな特徴といえます。
また、条文中に個人情報の例が列挙されているが、非常に広範な情報を対象としているとみることができます。デバイスの識別情報やオンライントラッキング情報、さらには統計的に個人や家庭を特定する"Probabilistic Identifiers"も対象としています。
一方で、個人を特定不可能にすることについての定義も記載されており、それに従った情報は個人情報でないとすることができます。
規制を受ける対象はなに？
CCPAは、カリフォルニアの居住者の情報を収集・管理する、営利事業者のうち、以下のいずれかを満たすものを対象としています。
a) $25 million 以上の年間売上がある
b) 年間50,000件以上の個人情報をやり取りする
c) 売上の50%が、個人情報の売買によるものである
さらに、同一ブランドで事業を行っている企業の子会社・親会社も規制対象となります。
たとえば、XYZ株式会社という会社が上記の条件を満たす場合、その子会社であるXYZ Systems株式会社も、本規制を受けるということです。逆もまた然りであり、子会社が上記条件を満たす場合は、親会社も本規制を受けます。
このため、海外展開している企業はCCPAに準拠する必要があるか気をつける必要があるといえます。
タイムラインは？
2020年1月に有効にされ、2020年7月までには強制化されるといわれています。現段階では、修正を加えている状況であり、またカリフォルニア州政府からより明確な指針がでるとされています。
GDPRとの違いは？
カリフォルニアのGDPRといわれるものの、共通点は大きく以下二つです。
- 消費者に自身の情報をコントロールする権利を与えるという考え方
- 域外の事業者を対象とする点
それ以外は、共通点はほとんどなく、GDPRのほうが、情報漏えいの場合の通知やセキュリティ対策、情報の域外転送について等様々な領域をカバーしている、
消費者に与える権利についても異なっており、GDPRのほうがより詳細に様々な権利を与えています。（どのように情報を消費者に公開するか、忘れられる権利、修正する権利等）
GDPRがより広い範囲を対象にしているが、GDPRに準拠したからといってCCPAに準拠できているとは限らない点も、注意が必要であす。（オプトアウトの仕組みなど）
おまけ（成立の経緯）
CCPAの成立の背景は興味深いので、簡単に紹介します。
CCPAは、法案が提出されたからわずか数日で、サインがされ通った法律です。
この背景として、カリフォルニアの「市民が法律を作成できる仕組み」（Ballot Initiative)があります。CCPAと同種の法案が2018年11月に、このBallot Initiativeにより提出されようとしていました。63万人もの市民の署名が集められており、法律として成立するものと見られていました。しかし、Ballot Initiativeによって、法律が制定された場合、その修正のハードルが非常に高いものとなります。（州政府が修正を独自に加えられず、別のBallot Initativeによってしか変更できない）。Ballot Initiativeのスポンサーが、州政府に対して、もしJune29までにCCPAをサインしたら、Ballot Initiativeであげている法案は取り下げることを提言され、州政府はそれに従った形です。
このような背景から、早急な法案成立がなされました。
