働きすぎ防止！ FDM管理のFTDで時間外業務の遮断 #Cisco

はじめに

この記事はシスコの同志による Cisco Systems Japan Advent Calendar 2021 の 2枚目の 19 日目 として投稿しました。今年もカレンダーが２つあります！！
2021年版(1枚目): https://qiita.com/advent-calendar/2021/cisco
2021年版(2枚目): https://qiita.com/advent-calendar/2021/cisco2
2020年版(1枚目): https://qiita.com/advent-calendar/2020/cisco
2020年版(2枚目): https://qiita.com/advent-calendar/2020/cisco2
2019年版: https://qiita.com/advent-calendar/2019/cisco
2018年版: https://qiita.com/advent-calendar/2018/cisco
2017年版: https://qiita.com/advent-calendar/2017/cisco

記事概要

Next-Generation Firewall (NGFW) 製品の便利な機能の一つに、タイムベースACL (Time-based ACL) があります。指定した時間や日時、曜日に、通信を許可したり拒否できる機能です。

Ciscoの NGFW製品である Firepower Threat Defense (FTD) は、オンプレミス管理方式として以下2つをサポートしており、タイムベースACLのサポート状況と設定方法が異なります。

	Firepower Device Manager (FDM) 管理	Firepower Management Center (FMC) 管理
管理方式	・FTDに直接管理して設定や管理が可能・別名オンボックス管理	・専用の管理サーバー(FMC)経由で複数FTDを統合管理
特徴	・NGFWの主要機能を利用可能 (アプリ制御、URLフィルタ、IPSなど) ・UIは軽快に動作し、設定も簡単・小～中規模向け	・NGFW 及び NGIPSとしてのフル機能を利用可能・専用サーバのため長期イベント保存が可能・障害や侵害時の管理者への自動通知やレポート機能・中～大規模向け
タイムベースACL	・Version 7.0から限定サポート・GUI非対応。API経由で設定必要	・Version 6.6からフルサポート・GUIから設定や確認が可能
コスト	・無償	・有償 (例: FMC Virtual利用時はライセンスと、FMCのインストール用サーバ必要)

FMC管理はフル機能が使え企業のセキュリティ保護において超頼れる相棒です。一方、FDM管理は UIが軽快に動作し設定も簡単かつ無料のため、すぐNGFW使いたい！というシーンにはピッタリ。そのため、一長一短です。

なお、タイムベースACLは、FMC管理の場合はGUIから簡単に設定できるのですが、FDM管理の場合はGUI設定がまだ未サポートのため REST API経由での設定が必要です。

REST APIって聞くと、ちょっとワクワクしませんか？ただ、FDMの REST API の利用は超簡単です。

ということで、今回の記事は、FDM管理のFTD バージョン 7.0.1 の利用環境を想定して、ちょっとワクワクするかもしれない REST APIを利用したタイムベースACLの設定方法を紹介します。

想定利用シーン

タイムベースACL 導入前

業務時間外もメールやチャット、ビデオ会議ができると、ついつい、定時後もチャットや会議したり、残業しがちに・・
仕事の切れ目が曖昧に

タイムベースACL 導入後

業務時間外になるとメールやチャット、ビデオ会議を全て通信遮断。帰宅を促す
日中業務の効率化を促したり、残業代の削減効果も

机上の設計

業務時間外とするタイムレンジの定義

FTDはUTCベースのため UTC時間も把握しておきます。UTCとの時差は9時間です。

業務時間外 (JST)	業務時間外 (UTC)
平日 19:00～翌8:00 休日 0:00～23:59	平日 10:00～23:00 休日 0:00～23:59

業務時間外に遮断するアプリケーションやURL例

今回は超メジャーな以下2つのアプリケーションの、業務時間外での通信遮断を試みます。

Office 365 (メールやファイル共有、など)
Webex by Cisco (オンラインMeetingやチャット、など)

各アプリケーションの通信要件は以下のWebサイトなどで確認可能です。

構成と設定の概要

以下のような通信構成を仮定し、業務時間外の Office 365 や Webex 間の通信の遮断設定を、FDM経由でFTDに行うものとします。

以下の順で設定と動作確認を行います。
1. タイムベースACLルールの仮作成
2. RESET API を利用しタイムレンジ設定
3. RESET API を利用し作成したACLにタイムレンジを紐づけ
4. タイムベースACLルールを通信遮断用に書き換え
5. 動作確認

なお、タイムベースACLを正しい時間に作動させるには、NGFW製品が正しい時刻をもったNTPサーバーと同期してるかも非常に重要です。仮にNGFWがNTPと同期していない場合は機器の時刻は少しずつずれていくものですので、適用タイミングがずれてくことになりかねません。そのため、社内もしくは外部の信頼できるNTPサーバーと時刻同期されることをお勧めします。例えば日本の場合は、有名な公開NTPサーバーとして、NICTの ntp.nict.jp などがあります。

設定と動作確認

1. タイムベースACLルールの仮作成

FDM経由でFTDにアクセスし、ポリシー > アクセス制御にアクセスします。

+ボタンをクリックし、アクション許可の新規ルールを追加し、適当なタイトルをつけて保存します。

画面右上の設定デプロイボタンを押して、仮作成したタイムベースACLルールをFTDデバイスに適用します。

2. RESE TAPI を利用しタイムレンジ設定

GUIからのタイムレンジの設定や確認ができないため、まずは FTD API を利用しタイムレンジ設定を行います。

FTD APIでは、設定に JavaScript Object Notation (JSON) オブジェクトを利用するため、業務時間外のレンジを UTCで JSONフォーマットで任意テキストエディタ等で事前に作成しておきます。例えば以下は、UTC で平日 10:00～23:00、休日全日の JSONフォーマットでの設定例です。"name"に好きな名前を、制御したいタイムレンジに合わせて"days"や"dailyStartTime"を適宜書き換えを行ってください。

{
  "name": "OFF-DUTY-HOURS",
  "recurrenceList": [
    {
          "days": [
        "MON","TUE","WED","THU","FRI"
      ],
      "recurrenceType": "DAILY_INTERVAL" ,
      "dailyStartTime": "10:00" ,
      "dailyEndTime": "23:00" ,
      "type": "recurrence"
    },
    {
          "days": [
        "SAT","SUN"
      ],
      "recurrenceType": "DAILY_INTERVAL" ,
      "dailyStartTime": "00:00" ,
      "dailyEndTime": "23:59" ,
      "type": "recurrence"
    }
  ],
    "type": "timerangeobject"
}

次に、FDMにアクセスし、画面右上の詳細オプション内の API Explorer をクリックします。

TimeRangeをクリックし、POST /object/timeranges の body欄に先ほど作成したJSON形式のデータをペーストし、TRY IT OUT ! ボタンを押します。

Response Codeが 200 でしたら成功です。

補足：仮に失敗した場合は、JSONの書き方が間違ってる可能性があります。エラーメッセージを参考にしながら構文などを見直してみてください。よくある間違えは、","が多いとか、"で囲い忘れとか、{}の囲いが足りない、などがあげられます、私の場合。

Response Body欄の出力の一部は後ほど利用しますので、テキストエディタなどにペーストしておきます。

{
  "version": "fshby3bc5hrxn",
  "name": "OFF-DUTY-HOURS",
  "description": null,
  "effectiveStartDateTime": "Started",
  "effectiveEndDateTime": "Never End",
  "recurrenceList": [
    {
      "days": [
        "MON",
        "TUE",
        "WED",
        "THU",
        "FRI"
      ],
      "recurrenceType": "DAILY_INTERVAL",
      "dailyStartTime": "10:00",
      "dailyEndTime": "23:00",
      "type": "recurrence"
    },
    {
      "days": [
        "SAT",
        "SUN"
      ],
      "recurrenceType": "DAILY_INTERVAL",
      "dailyStartTime": "00:00",
      "dailyEndTime": "23:59",
      "type": "recurrence"
    }
  ],
  "timeRangeObjectId": 2,
  "id": "3bb51c42-57fd-11ec-876c-5940c709de0f",
  "type": "timerangeobject",
  "links": {
    "self": "https://192.168.1.1/api/fdm/v6/object/timeranges/3bb51c42-57fd-11ec-876c-5940c709de0f"
  }
}

3. RESET API を利用し 作成したACLにタイムレンジを紐づけ

項番１で作成したタイムベースACLルールにタイムレンジを紐づけるために、まずタイムベースACLのIDを確認します。

AccessPolicy をクリックし、GET policy/accesspolicies/{parentId}/accessrules 内の parentIdに「default」とと入力してから、TRY IT OUT !! ボタンを押します。

Response Body に既存のルール一覧が出力されるため、項番１で作成したタイムベースACLルールの確認と、該当箇所をテキストエディタなどにペーストしておきます。

項番１で仮作成したタイムレンジACLルールは、"timeRangeObjects"の [] 内が空で、Value が何も設定されていないことを確認できます。項番２で作成したタイムレンジオブジェクトのResponse Body欄に含まれていた versionや name、id、type を埋め込み、{}で囲います。

タイムレンジオブジェクトの Value 追加前

   {
      "version": "ggfs6di7zk2ph",
      "name": "Off-duty hours URL block",
      "ruleId": 268435461,
      "sourceZones": [],
      "destinationZones": [],
      "sourceNetworks": [],
      "destinationNetworks": [],
      "sourcePorts": [],
      "destinationPorts": [],
      "ruleAction": "PERMIT",
      "eventLogAction": "LOG_NONE",
      "identitySources": [],
      "users": [],
      "embeddedAppFilter": null,
      "urlFilter": {
        "urlObjects": [],
        "urlCategories": [],
        "type": "embeddedurlfilter"
      },
      "intrusionPolicy": null,
      "filePolicy": null,
      "logFiles": false,
      "syslogServer": null,
      "destinationDynamicObjects": [],
      "sourceDynamicObjects": [],
      "timeRangeObjects": [],
      "id": "f328b38e-57e9-11ec-876c-b71b38a6b55f",
      "type": "accessrule",
      "links": {
        "self": "https://192.168.1.1/api/fdm/v6/policy/accesspolicies/default/accessrules/f328b38e-57e9-11ec-876c-b71b38a6b55f"
      }
    }

タイムレンジオブジェクトの Value 追加後

   {
      "version": "ggfs6di7zk2ph",
      "name": "Off-duty hours URL block",
      "ruleId": 268435461,
      "sourceZones": [],
      "destinationZones": [],
      "sourceNetworks": [],
      "destinationNetworks": [],
      "sourcePorts": [],
      "destinationPorts": [],
      "ruleAction": "PERMIT",
      "eventLogAction": "LOG_NONE",
      "identitySources": [],
      "users": [],
      "embeddedAppFilter": null,
      "urlFilter": {
        "urlObjects": [],
        "urlCategories": [],
        "type": "embeddedurlfilter"
      },
      "intrusionPolicy": null,
      "filePolicy": null,
      "logFiles": false,
      "syslogServer": null,
      "destinationDynamicObjects": [],
      "sourceDynamicObjects": [],
      "timeRangeObjects": [
        {
         "version": "fshby3bc5hrxn",
         "name": "OFF-DUTY-HOURS",
         "id": "3bb51c42-57fd-11ec-876c-5940c709de0f",
         "type": "timerangeobject"
        }
       ],
      "id": "f328b38e-57e9-11ec-876c-b71b38a6b55f",
      "type": "accessrule",
      "links": {
        "self": "https://192.168.1.1/api/fdm/v6/policy/accesspolicies/default/accessrules/f328b38e-57e9-11ec-876c-b71b38a6b55f"
      }
    }

PUT /policy/accesspolicies/{parentId}/accessrules/{objId} を開き、以下を入力してから TRY IT OUT !! ボタンを押します。

parentIdは「default」を入力
objIdはタイムベースACLルールのIDを入力 (上記例の場合は f328b38e-57e9-11ec-876c-b71b38a6b55f)
bodyにタイムレンジオブジェクトのValueを追記したJSONを入力

Response Codeが 200 でしたら成功です。

画面右上の設定デプロイボタンをクリックします。

「デプロイ今すぐ」ボタンをクリックし、FTDデバイスにタイムベースACLルールを適用します。

補足：タイムベースACLルールの適用時は通信処理エンジンであるSnortの再起動が発生するため、通信影響がごく短時間発生する恐れがあります。そのため、デプロイは通信影響の少ない時間帯に実施がおすすめです。うまくデプロイできない場合は一度 FDMの再起動を行うと改善することがあります。どうしてもデプロイできない場合は、その他の操作 > すべて破棄を選択して変更を廃棄してから、最初からやりなおしてみましょう。TRY IT AGAIN !!
　

4. タイムベースACLルールを通信遮断用に書き換え

まず遮断対象のドメインもしくは FQDN を把握しておきます。今回は以下のドメイン名を利用します。なお、FTDは「office365.com」といったドメイン名で設定することで、「outlook.office.com」や「www.office365.com」といったFQDN(=ホスト名＋ドメイン名)も制御可能になります。

Office 365	webex by cisco
office.com office365.com office.net outlook.com onmicrosoft.com sharepoint.com onedrive.com	wbx2.com ciscospark.com webex.com webexcontent.com

補足：上記はアプリケーションで利用される主要ドメインの抜粋のため、ざっくり通信遮断には有効ですが、一部通信はできてしまう恐れがあります。しっかり通信遮断をしたい場合は、各製品のメーカーの公式サイトに記載の全ドメイン・FQDNやIPアドレス、TCP/UDPポートを確認して利用するようにしてください。

オブジェクト > URL にアクセスし、通信制御したいドメインもしくは FQDN を、予め、URLオブジェクトやURLオブジェクトグループとして登録しておきます。例えば以下の設定例の場合、OFFICE 365と WEBEXというURLグループオブジェクトに、各ドメインを含んだURLオブジェクトを集約してあります。

ポリシー > アクセス制御に移動し、タイムベースACLルールの編集ボタンをクリックします。なお、GUIからはタイムベースオブジェクトの設定状況は確認できませんので、後ほどCLIでの確認方法を紹介します。

タイムベースACLルールに以下の設定変更を行います。

アクションをブロックに変更
URLタブ内に、Office 365 と webexの遮断用の URLオブジェクトもしくは URLグループオブジェクトを設定
ロギングタブ内の、接続の開始時と終了時を有効

ポリシーに設定したルールは、上から順に処理されます。タイムベースACLルールのドラッグ＆ドロップ操作で、既存の許可・信頼ルールよりも上に配置し、業務時間外時は指定ドメインのブロック処理が優先して行われるようにします。

画面右上の設定デプロイボタンをクリックした後、設定をデプロイします。

5. 動作確認

本記事の設定例の場合、日本時間で平日は 19:00～翌8:00 までタイムベースACLルールが動作し、通信制御が行われます。

17:50時点では LAN側端末から Office 365 や webex のサイトにアクセス可能であることを確認できます。

19:00以降に LAN側端末から再度 Office 365 や webex のサイトにアクセスを試みると、アクセス不可にかわってることを確認できます。

Outlookアプリケーションの送受信もすすみません。

Webexアプリケーションもオフライン表示となりチャットが困難です。Webex ミーティングを開始することもできません。これで仕事から解放される！？

FDMにアクセスし、監視 > イベントビューア > Connection を見ると、Office365 や webex 宛の通信が Block されていることを確認できます。

FTD CLIから、show time の UTC時刻が、事前定義されたTime Range内に入ったため、Rule: Off-duty hours URL block が動作していることを確認できます。

> show access-control-config
      --- 略 ---
---------[ Rule: Off-duty hours URL block ]---------
    Action                : Block
       Source ISE Metadata    :
    Users
    URLs
      URL Entry           : OFFICE365 (group)
                              office.com - office.com
                              office.net - office.net
                              office365.com - office365.com
                              onedrive.com - onedrive.com
                              onmicrosoft.com - onmicrosoft.com
                              outlook.com - outlook.com
                              sharepoint.com - sharepoint.com
      URL Entry           : WEBEX (group)
                              ciscospark.com - ciscosp> show access-control-config
      --- 略 ---
---------[ Rule: Off-duty hours URL block ]---------
    Action                : Block
       Source ISE Metadata    :


ark.com
                              wbx2.com - wbx2.com
                              webex.com - webex.com
                              webexcontent.com - webexcontent.com
    Logging Configuration
    DC                    : Enabled
      Beginning           : Enabled
      End                 : Enabled
      Files               : Disabled
    Safe Search           : No
    Rule Hits             : 1772
    Variable Set          : Default-Set
    Time Range            : OFF-DUTY-HOURS
      Daily Interval
       StartTime          : 10:00
       EndTime            : 23:00
       Days               : Monday,Tuesday,Wednesday,Thursday,Friday
      Daily Interval
       StartTime          : 00:00
       EndTime            : 23:59
       Days               : Saturday,Sunday

------------[ Rule: Inside_Inside_Rule ]------------
    Action                : Fast-path
       Source ISE Metadata    :

> show time
UTC -       Wed Dec  8 12:13:38 UTC 2021
Localtime - Wed Dec 08 07:13:41 EST 2021

詳細な処理状況をデバッグしたい場合は、system support trace コマンドが便利です。検査対象の通信の送信元や宛先のIP/Portを指定してから有効にすることで、マッチする通信の処理状況を確認できます。以下出力例の場合、outlook.office365.com (IP=40.101.147.114)宛の通信を検知しブロックしていることを確認できます。（注：Traceの有効化と確認は処理負荷が高いため、検証環境や、通信量と影響の少ない時間帯に実施しましょう。）

\> system support trace

Enable firewall-engine-debug too? \[n\]: y
Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.1.5
Please specify a client port:
Please specify a server IP address:
Please specify a server port: 443

WARNING: Running trace with generic filters might cause CPU spike !
Monitoring packet tracer and firewall debug messages

192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 Packet: TCP, ACK, seq 2883074173, ack 1909232047
192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0)
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 Starting AC with minimum 1, 'Off-duty hours URL block', and SrcZone first with zones 2 -> 1, geo 0 -> 0, vlan 0, source sgt type: 0, source sgt tag: 0, ISE sgt id: 0, dest sgt type: 0, ISE dest sgt tag: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0

192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1, 'Off-duty hours URL block', time range object'OFF-DUTY-HOURS' status 'active'
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 pending rule order 1, 'Off-duty hours URL block', URL
192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 Firewall: pending rule-matching, 'Off-duty hours URL block', pending URL
192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 Snort id 1, NAP id 1, IPS id 0, Verdict PASS
192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 Packet: TCP, ACK, seq 2883074173, ack 1909232047
192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 AppID: service HTTPS (1122), application Exchange Online (2810)
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 Starting AC with minimum 1, 'Off-duty hours URL block', and SrcZone first with zones 2 -> 1, geo 0(0) -> 0, vlan 0, source sgt type: 0, sgt tag: 0, ISE sgt id: 0, dest sgt type: 0, ISE dest\_sgt\_tag: 0, svc 1122, payload 2810, client 1296, misc 0, user 9999997, min url-cat-list 0-0-0, url outlook.office365.com, xff
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1, 'Off-duty hours URL block', time range object'OFF-DUTY-HOURS' status 'active'
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 custom host matcher using: outlook.office365.com
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 custom host matcher url without slash passed
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 match rule order 1, 'Off-duty hours URL block', action Block
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 Logging SOF with rule\_id = 268435461 ruleAction = 4 ruleReason = 0
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 MidRecovery data sent for rule id: 268435461,rule\_action:4, rev id:189281433, rule\_match flag:0x2
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 HitCount data sent for rule id: 268435461,
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 deny action
192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 Firewall: block rule, 'Off-duty hours URL block', drop
192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 Snort: processed decoder alerts or actions queue, drop
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 Deleting session
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 deleting firewall session flags = 0x38803, fwFlags = 0x1000, session->logFlags = 8002b08008c0
192.168.1.5-55146 > 40.101.147.114-443 6 AS 1-1 I 1 Logging EOF as part of session delete with rule\_id = 268435461 ruleAction = 4 ruleReason = 0
192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 Snort id 1, NAP id 1, IPS id 0, Verdict BLACKLIST
192.168.1.5-55146 - 40.101.147.114-443 6 AS 1-1 CID 0 ===> Blocked by Firewall

応用

今回はインターネット向け通信の遮断を行いましたが、タイムベースACLは様々な通信の制御に利用可能です。以下にユースケース例を紹介します。

タイムベースACLの活用例：

クラウドアプリケーションの利用時間の制御
内部サーバーの利用時間の制御 (例：深夜や土日はアクセスさせない)
協力会社やゲストユーザの通信インフラの利用時間の制限
毎週 ● 曜日はノー残業DAYにして 18時以降は通信遮断
自宅にFTD導入し子供の閲覧サイトの時間制限 (例：19時以降は勉強で利用するWebサイト以外は全遮断)

ちなみに、以下の画像は今回検証に利用した我が家の、Cisco Firepower 1010 君です。将来は娘の閲覧サイトの時間制限に利用しようと企んでます。自宅に検証機があると検証や資料作成が捗るのでお勧めです！（え、自宅にはいらない？）

最後までお読みいただきありがとうございました。皆様、良いネットワークライフを！

免責事項

本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、シスコの意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、シスコや他の関係者による推奨や表明を目的としたものではありません。各利用者は、本Webサイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本Web サイトの利用に関するあらゆる責任からシスコを免責することに同意したものとします。