テリロジー 「半公式」エンジニアブログ(仮)

株式会社テリロジー コンサルティング&ソリューション技術統括部

InfobloxのActive Trust(DNS Firewall)でDNSブロッキング

こんにちは。C&S技術統括部の ume です。

私からは Infoblox を使った、DNS によるブロッキングを行う方法をご紹介したいと思います。

DNS を利用したマルウェアの通信制御であったり、
サイトブロッキングの実現であったり、
「DNS ブロッキング」の用途はさまざまです。


Infoblox で簡単に実現する場合は、「 Active Trust 」を使用します。
旧名の「DNS Firewall」の方がしっくりくる方も多いかもしれません。
※今回の例では、Response Policy Zones( RPZ )を使用しています。

 用意するもの

  • Infoblox Trinzicシリーズ( 物理、仮想どちらでも可 )
     ※キャッシュサーバとして動作させる必要があります
  • RPZ ライセンス( Temporary ライセンスでも可 )
  • Internet への接続環境

構成・動作例

 

f:id:teriwriter:20180806211546j:plain

クライアントが参照する DNS サーバで Active Trust(DNS Firewall)を動作させます。この例では Grid 構成で複数の Member 機が DNS のキャッシュサービスを提供している形です。

Infoblox 社が提供する、Internet 上にある脅威情報配信サーバからゾーン転送でデータ( Black List みたいなもの)を取得し
そのデータをクライアントが参照する DNS サーバへ展開します。

設定の流れ

大雑把に設定の流れを記載します。

  1. Infoblox に  RPZ ライセンスを投入
  2. Infoblox の WebUI にログイン
  3. Data Management ⇒ DNS の画面内で「Response Policy Zone」のタブを確認し移動
  4. 必要に応じて System DNS Properties ⇒ Logging Categoryで rpz を有効化する ※Log でブロックを確認する場合は必要
  5. 必要に応じて View を選択
  6. 「Response Policy Zone」のタブ内の Add ボタンをクリックし Add Response Policy Zone Wizard を開く
  7. Add Response Policy Zone Feed を選択
  8. Name 欄に受け取る脅威情報データの名前を入力
     ※ここは受け取るデータの種類によって変わります
  9. Policy Overrideをプルダウンから選択
  10. Member を選択する画面で External Primary にInternet上にあるInfoblox社のサーバを指定、Grid Secondaryに現在WebUIでアクセスしているInfobloxを登録
  11. サービスリスタートを実施し、データを取得

これで設定は完了です。

 

実際の設定

最初は特に設定をしないで、
Infoblox社が配信する脅威情報としてブロッキングの対象とされている
「applemusic.isasecret.com」の名前解決を試してみます。
※2018/08/06現在 

  [ume@umepc01 ~]$ dig @172.16.180.13 +short applemusic.isasecret.com
  93.170.128.166

 

普通に名前解決ができました。

これを解決できないようにします。

 

まずは RPZ ライセンスを有効にした Infoblox に WebUI でログインします。

下の画像はログインした後、該当ページまで移動したところです。

f:id:teriwriter:20180806215708p:plain

 

 

表示された Wizard で「Add Response Policy Zone Feed」を選択します。

画像にも書いていますが、外部からの情報ではなく、ローカルでルールを定義する場合は「Add Local Response Policy Zone」を選択します。

(後述するホワイトリスト定義で使用します。)

f:id:teriwriter:20180806221708p:plain

 

 

脅威情報提供元のサーバ情報を入力します。

実際に使用する際は、Infoblox 社からサーバ情報が提供されます。

f:id:teriwriter:20180806220722p:plain

f:id:teriwriter:20180806220837p:plain

 

サービスリスタートを行って設定完了です。

ゾーン転送でデータが取得できていると、WebUI 上から Export できるようになります。

f:id:teriwriter:20180806220858p:plain

 

動作確認

  [ume@umepc01 ~]$ dig @172.16.180.13 applemusic.isasecret.com

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> @172.16.180.13 applemusic.isasecret.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55065
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;applemusic.isasecret.com. IN A

;; ADDITIONAL SECTION:
base.rpz.infoblox.local. 7200 IN SOA ns1-rpz.csp.infoblox.com. support.infoblox.com. 1533215423 7200 3600 2592001 7200

;; Query time: 2 msec
;; SERVER: 172.16.180.13#53(172.16.180.13)
;; WHEN: 木 8月 06 22:20:01 JST 2018
;; MSG SIZE rcvd: 141

 

 該当レコードの名前解決をしようとしても NXDOMAIN が返ってくるようになりました。

 

 

上記ではInfoblox社が提供する脅威情報を参照する方法を使いましたが、万が一ブロックして欲しくないレコードが含まれている場合など
いわゆるホワイトリストのような定義があると便利ですよね。


そのような場合は、

  • Local Response Policy Zoneを作成
  • 該当のレコードを Passthru で設定する
  • 作成した Local Response Policy Zone を Feed より優先順位を高くする

とすることで対応が可能になります。

 

 
いかがでしたでしょうか。
Infoblox を使って簡単に DNS ブロッキングができることがお分かりいただけたと思います。
もちろん Infoblox 社が提供する脅威情報だけでなく、
他のベンダーが提供している情報や、場合によっては自社で管理している情報を取り込むことも可能です。
ぜひ一度お試しいただければと思います。


それでは失礼いたします。

 

おまけ

Unboundで同じような動作をさせたい場合、
pythonスクリプトで拡張をする機能を使用して、
問い合わせされているドメインがブラックリストに入っていれば
名前解決を続行せずに、NXDOMAIN を即答するように動作させることが可能なようです。

 

Splunkによる脆弱性管理ソリューションとNW監査システムの統合的な可視化

コンサルティング&ソリューション技術部 セキュリティソリューショングループの江口です。

7月19日に、弊社ではダークウェブの脅威と脆弱性リスク管理についてのセミナーを実施し、そのなかで私も「ネットワーク及びプラットフォームの統合的な脆弱性可視化と管理運用」というタイトルで講演させて頂きました。

内容としてはSplunkで脆弱性管理ソリューション「Rapid7 InsightVM」とNW監査システム「RedSeal」の情報のSplunkダッシュボードでの統合的な可視化のデモが主でした。この二つのシステムの情報を可視化することにより、NW側のリスクも踏まえて、どのホストの脆弱性から対処すべきか、ということを容易に解析・検討できるということを説明させていただきました。

f:id:teriwriter:20180731215036j:plain

本記事ではその内容をざっくりと紹介したいと思います。

 

InsightVMとRedSealについて

先に情報の統合の対象とした二つのシステムについて簡単に説明しておきます。

Rapid7 InsightVM

f:id:teriwriter:20180731215014j:plain


Rapid7社が提供する脆弱性管理システムです。脆弱性管理システムを各資産に対して脆弱性のスキャンを行い、脆弱性情報のレポーティングはもちろん、効率的な改善策の提示や改善状況の進捗管理などの機能も提供します。

ちなみに「InsightVM」の「VM」はVirtual Machineではなく、Vulnerability Management(脆弱性管理)の略です。

RedSeal

f:id:teriwriter:20180731215022j:plain


RedSealはNW機器の設定情報などを取得して、FWの設定ミスや、意図したポリシーに反する通信経路、意図しない外部からアクセス可能な経路など、NW側の問題・リスクを解析するツールです。さらにRapid7 InsightVMのような脆弱性管理ツールと連携することで、脆弱性スキャンを実行したホストがどのセグメントに存在するかを把握し、信頼できないNWから攻撃されるリスクを算出することができます。

RedSealについては、本ブログに山内が「15分で分かるRedSeal」(http://terilogy-tech.hatenablog.com/entry/2018/07/07/234256)という記事を上げているので、そちらもご参照ください。

 

運用上の課題

Rapid7 InsightVMのような脆弱性管理ツールを導入すると、自社NW内の資産の脆弱性を可視化することができるようになります。

次のアクションは脆弱性の改善、ということになりますが、すると課題になるのは、

「いったいどのホストから手を付ければ良いのか」

という点です。

Rapid7 InsightVMでは、CVSSスコアだけではなく、その脆弱性を衝くエクスプロイトやマルウェアの有無を考慮して独自のリスクスコアを算出します。これだけでも10段階であるCVSSスコアのみで評価をするよりも優先度づけの指標は増えますが、さらに踏み込んで考えれば、NWの観点からのリスク評価がより参考になるでしょう。すなわち、外部に露出しているサービスを持つホストで、そのサービスに脆弱性があれば優先的に対処すべきと評価できます。そのなかでも内部の資産に対する踏み台となってしまうようなホストがもしあれば、さらに優先度は高くなります。

上記のようなNWの観点からの解析は、RedSealにRapid7 InsightVMのスキャン結果を取り込むことで実現可能です。RedSealは脆弱性を持つホストのNW的なリスクを算出し、リスクスコアを算出してくれます。
なのでこの2製品を連携させればめでたしめでたし・・・

・・・と言いたいところですが、運用を考えるとこの2製品だけの連携では少し課題が残ります。それは、

  • お互いがそれぞれ独立してリスクスコアを算出し、お互いのスコアを参照できない
  • そのため、それぞれのスコアはそれぞれのUIで確認する必要がある

という点です。エクスプロイトなどの存在を踏まえたリスクスコアや、脆弱性の詳しい情報を確認したければRapid7 InsightVMの、NW側の評価を踏まえたリスクスコアを確認したければRedSealのUIを見る必要があるということです。

運用する方からすれば、両者の情報を一つの画面で統合的に確認したい、と思われるところではないでしょうか。

 

当社開発ダッシュボードのご紹介

そこで我々が開発したのが、SplunkでRapid7 InsightVM・RedSealの情報を統合的に可視化するダッシュボードというわけです。このダッシュボードは、Splunkで取得したRapid7 InsightVMとRedSealの情報を関連づけて表示するようになっています。

Splunkへのデータ入力については、RedSealはSyslogによるデータ受信。Rapid7 InsightVMについては、Rapid7公式のSplunkアドオン(InsightVMに対してAPIによるデータ取得を実施する)を用います。以下に簡単に構成を示します。

f:id:teriwriter:20180731214914j:plain

ダッシュボードは計5つ定義しています。以下、一つずつ画面を紹介していきます。

メインダッシュボード

最初に表示されるダッシュボードです。脆弱性情報のサマリを表示します。

f:id:teriwriter:20180731214937j:plain

ホスト情報

ホスト単位に、検知された脆弱性やNW的なリスク(信頼できないNWからの到達可能性や踏み台攻撃を受ける可能性など)を表示するダッシュボードです。また、リスクスコアとして、そのホストの

  • Rapid7 InsightVMでのリスクスコア
  • RedSealでのリスクスコア
  • Downstreamスコア(※RedSealで算出される、ホストが踏み台とされた場合の二次被害のスコア)

がまとめて確認可能です。

f:id:teriwriter:20180731214943j:plain

脆弱性情報

検知された脆弱性の一覧、およびドリルダウンによりその脆弱性を持つホストの一覧を表示するダッシュボードです。

 f:id:teriwriter:20180731214946j:plain

脆弱性・攻撃深度マトリクス

RedSealが解析する攻撃深度(Attack Depth、信頼できないNWからいくつのホストを踏み台とすればそのホストを攻撃可能かの指標)別にホストを分類し、各ホストの脆弱性数・リスクスコア(InsightVMリスク、Redsealリスク、Downstremリスク)の情報を表示します。

 f:id:teriwriter:20180731214940j:plain

攻撃深度については、次のスライドの説明が分かりやすいでしょう。「1」であれば信頼できないNWから直接攻撃されるホスト、「2」であれば直接攻撃されるホストを踏み台として攻撃される可能性のあるホスト。さらにそのホストを踏み台にして攻撃できるホストがあればその攻撃深度は「3」になる・・・といった具合です。

 f:id:teriwriter:20180731214920j:plain

例えば攻撃深度が1で、Downstreamリスクスコアが高いホストが存在した場合、それは「直接攻撃される可能性があり、踏み台とされた場合に二次被害のリスクが高い」ホストであることを意味します。そこで、多少脆弱性の数が少なくとも、このホストの脆弱性対処を優先する・・・といった判断ができるようになるわけです。これが、InsightVMによる脆弱性情報とRedSealによるNWリスクの情報を統合して表示するメリットとなります。

最後に

ざっと弊社開発のSplunkダッシュボードをご紹介させていただきましたが、いかがだったでしょうか。

このダッシュボードは弊社でSplunk Appsとしてパッケージングしており、Splunkにインストールしてお使いいただくことが可能です。弊社では、このダッシュボード、RedSeal、Rapid7 InsightVMを合わせたシステムの導入を承っています。ご興味がありましたら、以下のリンクのご相談フォームにてご連絡いただければ幸いです。

https://docs.google.com/forms/d/e/1FAIpQLSc4ssUncGot36epugounMYxSEMqlk4AzdqYuCIhET27JsZwzw/viewform

ではでは。

 

江口

OneSpan (旧VASCO) のプッシュ通知認証を試してみた

こんにちは。

OneSpan (旧VASCO) 製品を担当している木村と申します。

 

VASCOといえば「ワンタイムパスワード」というイメージをお持ちの方も多いのではないかと存じます。ご存じでない方もインターネットバンキングやオンラインゲーム等で知らないうちにVASCOの「ワンタイムパスワード」をご利用いただいているかもしれません。

 

実はVASCOには「ワンタイムパスワード」以外の製品が御座います。あまり知られていないと存じますので、今回はその中からプッシュ通知を使用した認証をご紹介します。

 

※2018年5月30日にVASCOはOneSpanに社名変更されました。

 

認証の流れ

 

ここでは認証の流れをご紹介いたします。

 

  • プッシュ認証を適用するシステム接続します。実際は業務システム等にあたりますが今回はデモサイトを使用しています。

f:id:teriwriter:20180724110633p:plain

  • ユーザー名、パスワードを入力します。ここまでは従来からのパスワード認証の流れです。

 f:id:teriwriter:20180724110735p:plain

  • スマホにプッシュ通知が届きます。通知をタップします。

 f:id:teriwriter:20180724110754p:plain

  • ここでスマホのロックを解除します。今回は指紋認証です。

 f:id:teriwriter:20180724110808p:plain

  • ログインをするのかを問われます。「YES, I AM」をタップします。

 f:id:teriwriter:20180724110820p:plain

  • ここでさらに指紋認証です。少々冗長な感はありますが、スマホにロックがかかっていない時に備えて必要な手順なのかと思います。

 f:id:teriwriter:20180724110838p:plain

  • デモサイトでログインが成功します。

 f:id:teriwriter:20180724110849p:plain

 

いかがでしょうか。このパターンでは、記憶=パスワード、所有=スマホ、本人=指紋、と認証につかう三要素をすべて網羅していますね。

 

プッシュ通知認証に必要なもの

 

ここではプッシュ通知認証を実装する上で必要なものをご紹介いたします。

大きく分けて以下の3つが必要です。

 

  • 導入先のアプリケーションサーバーにVASCO認証の仕組みを組み込む

ログイン認証にVASCOの認証が介入するよう構築する必要がございます。VASCOではJava、.NET向けのハイレベルAPI、ローレベルのSOAP APIをご用意しております。

  • VASCOサーバー群の導入

認証サーバー、ゲートウェイサーバー、スマホアプリ利用登録(アクティベーション)サーバーを導入する必要があります。こちら弊社にご相談いただければと存じます。

  • スマホにVASCOアプリの導入

Androidであれば、Google Playから、iPhoneであれば、App Storeからアプリをスマホにインストールいただけます。次節でスマホアプリの利用登録の手順をご紹介いたします。

 

スマホアプリの利用登録

 

ここではスマホアプリの初回の利用登録方法をご紹介いたします。

 

  • スマホアプリをインストールします。Androidであれば、Google Playから、iPhoneであれば、App Storeからアプリをスマホにインストールいただけます。次に利用登録を行います。

 f:id:teriwriter:20180724110933p:plain

  • PC等でスマホアプリ利用登録サイトを開きます。今回はデモサイトを使用しています。

 f:id:teriwriter:20180724110947p:plain

  • ユーザー名、パスワードを入力します。

 f:id:teriwriter:20180724110959p:plain

  • カラーコードが表示されます。

 f:id:teriwriter:20180724111010p:plain 

  • アプリを起動してカラーコードをカメラで撮影します。アプリのカメラへのアクセスと通知を許可してください。ちなみにですがカラーコードの認識が早く、スクリーンショットの撮影は断念しました。

f:id:teriwriter:20180724111036p:plain

 

以上でスマホアプリが利用できるようになりました。オンラインで利用登録処理をしていますので簡単ですね。

 

Windowsログオンでプッシュ通知認証を使う

 

ここまででご紹介した仕組みはWindowsログオンでも使用できます。Windows端末にはあらかじめVASCOの認証ソフトウェアをインストールする必要があります。PCI DSS対応等で需要があるWindowsログオンの多要素認証の流れをご紹介します。

 

  • Windows端末のログイン画面を開きます。VASCOが導入されているとログイン画面でプッシュ通知を要求できるようになります。

f:id:teriwriter:20180724111121p:plain

  • ユーザー名、パスワードを入力します。

 f:id:teriwriter:20180724111132p:plain

  • スマホにプッシュ通知が届きます。以降は前述のアプリケーションサーバーの流れと同様です。

f:id:teriwriter:20180724111149p:plain

f:id:teriwriter:20180724111218p:plain

f:id:teriwriter:20180724111230p:plain

f:id:teriwriter:20180724111237p:plain

  • 以上の手順でWindowsにログオンできます。

 f:id:teriwriter:20180724111247p:plain

Windowsにログオンするタイミングで多要素認証を導入することで、各業務システムへ個別に多要素の仕組みを導入しなくても済むケースがあるかと存じます。

 

おわりに

 

今回はVASCOのプッシュ通知の認証についてご紹介しました。

この仕組みを導入することでスマホを活用した多要素認証を導入することができます。

ご興味がございましたら弊社までご連絡ください。

 

 

RedSealを15分で理解する

こんにちは。

ここ数年間、体重が右肩上がりで自己ベストを更新中の山内です。

 

夏に向けてシェイプアップしたボディを手に入れたいと思いつつ、深夜のラーメン&ライスのセットがどうしてもやめられません。 

暑い日が続きますが、そんな日は熱々のラーメンで乗り切っていきましょう!!

 

さて今回は、「RedSealを15分で理解する」と称して記事を書かせて頂きます。

 

そもそも「RedSeal」って何? 

 

今回ご紹介させて頂くRedSealですが、当社のホームページでは「ネットワークセキュリティ監査」や「ネットワークインフラ基盤のサイバーセキュリティー分析ソリューション」とご紹介させて頂いております。

 

正直、RedSealで一体何ができるのか、この説明だけじゃ全然わからないですね。 

 

簡単に言うと「ネットワークデバイスのコンフィグを読み込むことで色んなことができちゃうツール」になります。

 

「RedSeal」でできること

 

「じゃぁ、色んなことって何なの?」というのが、以下の内容になります。

  • ネットワークデバイスのコンフィグファイルを読み込むことが可能
  • 読み込んだコンフィグからネットワーク構成を可視化 
  • コンフィグ内のセキュリティの弱い設定をチェック
  • ネットワークのアクセス経路を可視化
  • あらかじめ設定したポリシーに違反するアクセスリストやFWルールを検出
  • 脅威のあるネットワークからアクセス可能なネットワークをリスト化

 

その他にも、脆弱性スキャナ*1と連携を行うことで、以下が可能です。

  • 脆弱性を持つホストをネットワーク構成上に表示
  • 脆弱性を持つホストへのアクセス経路を可視化
  • 脅威のあるネットワークから脆弱性をつくアクセス経路を可視化

 

そんな当社一押しのRedSealを15分で理解できるスライドをご用意しました。

是非、一読頂ければと思います。

 

RedSealを15分で理解するスライド

from 株式会社テリロジー コンサルティング&ソリューション技術統括部

www.slideshare.net

 

 ではでは。

 

*1:脆弱性スキャナ:サーバなどのデバイスをスキャンし、脆弱性の検出が行えるツール

久しぶりの投稿

統括部長をしているY.Oです。
超久しぶりの投稿になります。

 

# 今日は軽いタッチで書きます。
# ご容赦ください。

 

立ち上げたまではよいが、いつの間にかインターネットの孤島になるブログが多い理由がわかりました。忙しい、に集約してしまえばそれで終わりの気もしますが、私は毎日Slackに駄文を書いているし、やっぱり非公式と言いつつ、オウンドメディアに何かを記すという面倒臭さがこ今の状況を生んでいるのだと思いま~す。今期はブログの投稿をします、みたいなメンバーが数名いましたが、どうですかね・・・。

 

ゴールデンウィークが終わってすぐ、例年より早く当部にも新人さんがやって来ました。新人さん、なんて書き方をしているうちはまだ「お客さん」。例年にも増してインテンシブなトレーニングをしていますので、早く環境に慣れてチームの一員として頑張って欲しいと思います。

 

当部のあるグループのキャッチワードは「ルーキースマート」。
ある本のタイトルと同じです。

 

これから若い皆さんはいろいろなストレスに直面すると思うのです。

・人に心を開くこと
・人と衝突すること
・自分の弱さとぶつかること
・逃げ出したくなること
・新しい事に挑戦しなければならないこと
・常識や通念との葛藤

 

今でも自分はこういったことがつらいこともあります。
特に最後のやつ・・・。

 

でも、ルーキーであることは武器です。

 

新人のくせに言いこと言うね、なんて偉そうな先輩はすぐに追い抜かしてやればいいと思いま~す。自分は似非体育会系みたいな、理解しがたい上下関係なんてクソ喰らえ(あら、お下品)だと思ってます。

 

「義理」というものは日本人の美徳のひとつだと思います。しかしながら、それを逆手に取り背徳の担保にするとか、自分の立場を守るために利用するとか、そういうのはやはりクソ喰らえだと思います(2回目)。

 

ま、すべてがうまく行きますように!

・・・頑張ります。

 

【Linux】仮想インターフェース設定

こんにちは、はじめまして。コンサルティング&ソリューション技術統括部の樋口です。

普段とは毛色を変えて、Linuxのちょっとした技についてお話したいと思います。

みなさんは、LinuxでLANに仮想インターフェースを割り当てるときにどのような方法を利用されていらっしゃいますか?

今回は、debian系のディストリビューションで仮想インターフェースを設定する方法を紹介したいと思います。

 

仮想インターフェース設定方法

通常、仮想インターフェースを追加する際は、/etc/network/interfaces へ下記の様に仮想インターフェースの設定を追記して、service networking restart コマンドを実行するだけかと思います。

 

auto eth3
iface eth0 inet static
 address 192.168.0.10
 netmask 255.255.255.0
 network 192.168.0.0
 broadcast 192.168.0.255

auto eth3_0
iface eth0_0 inet static
 address 192.168.10.20
 netmask 255.255.255.0
 network 192.168.10.0
 broadcast 192.168.10.255

しかし、これでは仮想インターフェースにIPアドレスは設定ができても、MACアドレスは実インターフェースのアドレスを共有していて、仮想MACアドレスをアサインする事ができません。

MACアドレスを指定して仮想インターフェースを作成するには、下記の様に「ip」コマンドを使用する必要があります。

 

ip link add link 実インターフェース名 address MACアドレス 仮想インターフェース名 type macvlan


実行例

ip link add link eth3 address 52:54:00:11:11:11 eth3_0 type macvlan

 ※上記例では、eth3 に eth3_0 の名前で MACアドレスが 52:54:00:11:11:11 のインターフェースを作成しようとしています

 

コマンド実行後に、仮想インターフェースにIPアドレスの設定をおこなえば、仮想MACアドレスを仮想IPアドレスを設定することが可能です。

 

 

 仮想インターフェース削除方法

 

設定した仮想インターフェースを削除するのには、設定した時と逆の手順にて削除する必要があります。

まずは、仮想インターフェースに設定したIPアドレスを解除します。

/etc/network/interfaces へ記述した設定の削除をおこないます。

 

auto eth3
iface eth0 inet static
 address 192.168.0.10
 netmask 255.255.255.0
 network 192.168.0.0
 broadcast 192.168.0.255

auto eth3_0                          ←削除
iface eth0_0 inet static          ←削除
 address 192.168.10.20         ←削除
 netmask 255.255.255.0         ←削除
 network 192.168.10.0           ←削除
 broadcast 192.168.10.255     ←削除

 

上記を削除後、service networking restart コマンドを実行し、IPアドレスを削除します。

削除後、仮想インターフェースにアサインしたMACアドレスを削除するため、下記コマンドを実行します。

 

ip link del link 実インターフェース名 address MACアドレス 仮想インターフェース名

 

 実行例

ip link del link eth3 address 52:54:00:11:11:11 eth3_0

 

実行後、ifconfig -a コマンドから、仮想インターフェースが消えていることを確認します。

 

みなさん、いかがでしたでしょうか?

案外、簡単に仮想インターフェースにMACアドレスを割り当てることができましたね。

この内容が、みなさんのお役立ていただければ、幸いです。

それでは、失礼いたします。

 

今度はPetya / GoldenEye

こんにちは、セキュリティチームの石田&山内(やまうち)です。

 

WannaCry騒動が収束しないうちに、またランサムウェア騒動が起きてますね。

 

まだ一般的な名称が確定してませんが、とりあえず当ブログはBitdefenderさんの「GoldenEye」という名称で記載します。

 

どのようなランサムウェア?

ベースになっている「Petya」はファイルではなくディスクを丸ごと暗号化するタイプのランサムウェアの亜種で、昨年から観測されています。

「GoldenEye」はWannaCryと同様に「MS17-010」を悪用して感染が拡大する様です。

 

サンドボックスに放り込んでみた

詳細は解析中ですが、とりあえず入手したサンプルをサンドボックスに放り込んで挙動を見てみました。

 

GoldenEye f:id:teriwriter:20170628133428j:plain

うーん、「Petya」みたいにMBR書き換えを観測できませんが、ディスク情報読み込んだり、暗号化API叩いたり、再起動したりと怪しい。

Petyaf:id:teriwriter:20170628133436j:plain

一方「Petya」はMBRを書き換えていることが解ります。

 

対策

感染拡大の手法自体WannaCryと同様みたいなので、パッチの適用とFWやIPSで外部からのSMBをブロックするのが一番確実です。

当社も使っていますが、モバイルPC+USBドングルでインターネット接続する場合は必ずパーソナルFWやホストISPを使いましょう。

  

検体情報

  • GoldenEye

  MD5 : 71b6a493388e7d0b40c83ce903bc6b04
  SHA1 :  34f917aaba5684fbe56d3c57d48ef2a1aa7cf06d

  • Petya

  MD5 : af2379cc4d607a45ac44d62135fb7015
  SHA1 : 39b6d40906c7f7f080e6befa93324dddadcbd9fa

 

さすがに、サンドボックスだけでは再起動後の挙動までは解らないので今日はココまで

もう少し解析してから、改めて続きを書こうかと思います。

 

それにしても、このランサムウェアはPCが2台無いと身代金が払えないですね。。。

 

それでは