FortiGateのSSL-VPN

1.FortiGateのSSL-VPNの特長

FortiGateならではの特徴があります
① ユーザーライセンスの課金がない
② 同時ユーザー接続数が10,000ユーザー以上もサポート可能。
　　※HAも可
　

ということは、HA構成の場合、2倍の料金を払う必要がないのですか？
はい。機械の代金のみで、SSL用の追加ライセンスは不要です。
ユーザーライセンスの課金はないので、コストパフォーマンスに優れています。

③クライントソフトも無償提供。
　 ※FortiClientを利用（IPsec、SSL-VPNのみの利用や、AntiVirusなど包括した ClientSoftとして利用することもできます）

2.SSL-VPNの接続方式

FortiGateでは、多くの他の製品と同様に次の3つの接続形式があります。
①ウェブアプリケーションモード
②ポートフォワードモード
③トンネルモード

①はベーシックな使い方で、httpまたはhttpsを中心としたシステムでのリモートアクセスを可能にします。
http/https以外に FTP、SMB/CIFS、TELNET、SSH、VNC、RDP をサポートします。

②専用アプリケーションで使えるようにしたもので、ポートフォワードと言われるものです。
これは Javaアプレット経由をサポートし、TCPベースの任意のアプリケーションの通信を HTTPSのポート番号に変換し Firewallを通過させ SSL-VPNを実現します。
　
③は、最も多く使われる形式です。レイヤ4で使われるhttpsの通信を、あたかもレイヤ3でで動作させる仕組みです。
PC側に仮想NICと仮想IPアドレスが割り当てられ、あたかも同じネットワークにいるかのような通信ができます。

FortiGateの SSL-VPNの特長は、ユーザーライセンスの課金がなく、且つ UTMを利用できる点にあります。
※クライントソフトも FortiClientを利用できます。（もちろん無償で、IPsec、SSL、AntiVirusなど機能が提供されています。） 

3.Fortigate　SSL-VPNで2要素認証

正直、書きかけの内容なので、特に(2)(3)は信憑性が怪しい。

(1)EメールやSNS、MFAでの認証

基本機能として備わっている。Emailによる2段階認証は、この後に記載する
また、資料としては、以下が参考になる

リモートアクセス 二要素認証 設定ガイド
https://www.fortinet.com/content/dam/fortinet/assets/deployment-guides/ja_jp/fg-6-4-vpn-mfa.pdf

(2)証明書認証

❶どうやって認証？
証明書認証では、いろいろな方法が選べるはず
・正しいクライアント証明書を持っていれば、その証明書の中のCN（メールアドレス）を見てユーザ情報を判断し、ID/PWを入れない
・クライアント証明書を持っているるかどうかだけの判断で、CNを見ないことも可能。みてもいい。ユーザID/PWは別途入れる　・・・こっちのほうが2要素認証だ。

https://www.gleas.jp/news/column/fortigate

❷課題
Q1.クライアント証明書を配布、管理が大変では？また、コピーされない？
Windowsの証明書サービスを使えれば、クライアント証明書をエクスポートできない形で発行できる。ユーザにはサーバにアクセスしてもらい、ID/pwを入れて証明書を取得してもらう。ただ、単純な作業とはいえ、全ての人にこの作業をやってもらおうとすると、意外に大変かもしれない。特にＩＴリテラシーが低い方には。
Q2.証明書エラーがでる？
Webサーバの証明書がローカルの証明書だと、ブラウザで警告が出る。しかし、クライアント認証の場合は、そういった心配はない。

(3)クラウドサービスや外部の仕組みと連携

以下の真ん中の「RADIUS連携」の図にあるように、連携対象システムがFortiGateだと思って、それがRadiusサーバに問い合わせる。ここは連携なので、連携先がハードトークンを使おうが、ソフトトークンを使おうが、何をしようが、連携できる。クラウドサービスも連携できる、と思っている。
https://www.techmatrix.co.jp/product/securid/securid-access.html

(4)E-mailによる認証

トークンやSMSもあるが、手軽なe-mailでの認証を行う場合を説明する。※SMSによる方法は、携帯電話の電話回線を使うので、別途SMSを送信するサービスと契約が必要になるはず。
トークンは無料で2ユーザのライセンスがあるので、メンテナンスで使う分には使えるだろう。
設定であるが、まずは、SSL-VPNの設定を一通り行い、通常のPW認証でログインできるようにする。
では、設定を変更する。

①メールを送信する設定
2要素認証のメール送信用にメールアドレスが必要。このメール送信用に、Gmailなどのアカウントを作成しておく必要がある。→なんかうまくいかないときがあるので、後半に書いた方法も参考に。
メールサーバの設定は、システム＞高度　から設定する。
設定ではあるが、CLIに関しては、以下の設定を張り付けておく
https://kb.fortinet.com/kb/documentLink.do?externalID=FD40488

Configure gmail account in the FortiGate.
#config system email-server
    set server "smtp.gmail.com"
    set port 587
    set authenticate enable
    set username "test"
    set password SGKSDHFK
    set security starttls
end

さて、実際の設定であるが、Gmailの場合、ユーザ名は@gmail.com　をつけ、ポートは465とする。security はsmtpsで成功する。
ただ、GmailやPlalaなどのメールサーバ側でブロックされる可能性があると思う。それはセキュリティの問題なので、警告等が出て、それを許可できればOKだと思う。

【方法2】Fortigateのメールサーバを利用する

以下のサイトからコピペ
https://www.open-circuit.ne.jp/isp/settei/fortigate-ssl-vpn-email.html

config system email-server
set reply-to "noreply@notification.fortinet.net"
set server "notification.fortinet.net"
set port 465
set security smtps
end

設定の確認は以下
show system email-server

②ユーザの認証をE-mailに変える
まず、GUI画面で、該当するユーザにEmailアドレスを設定する。※もちろん、このメールアドレスは、一般的には上でFortiGateに設定したメールアドレスとは異なるはずだ。
だが、残念かがらGUIからE-mailによる二要素認証の設定ができないので、以下のCLIを実行する

conf user local
edit ssl-user1 ←SSLのユーザ名
set two-factor email
set email-to test@ab.dom ←Emailアドレス
end

GUIで確認すると、Eメールベースの2要素認証が有効に設定されている

4.FortiGateのSSL-VPNのセキュリティ強化

ZTNAに比べると、若干弱いような気もしますが、できることは基本的に似ています。

❶ホストチェック
SSL-VPNポータルのところで
ホストチェック、OSのバージョン制限などがある

❷送信元IPアドレスの制限
SSL-VPN設定で「特定ホストへのアクセス制限」にて設定

❸アプリケーションコントロールなどの細かい制御
SSL-VPNの通信も通常のポリシー同様に、アプリケーションコントロールやWebフィルタ、AVなどができる.
設定はポリシーのところで。

その他、サーバ側でのアクセス制御も必要

5.FortiGateのSSL-VPNの脆弱性

5.1 脆弱性と影響

脆弱性による被害が発生している。
たとえば、2023年6月14日のIPAの記事に、任意のコードが実行される可能性があることが記載されている。
https://www.ipa.go.jp/security/security-alert/2023/alert20230613.html

任意とあるので、FortiGateを乗っ取られ、内部に侵入されるリスクがある。

5.2 基本の対策

(1)ファームのバージョンを最新化する
・開発者の情報を参考に、最新版にアップデートする。
・ファームのアップデート方法は、OSによって変わるが、ここを参照いただきたい。
(2)SSL-VPN機能を無効にする
無効化の方法は、バージョンによって変わる
https://community.fortinet.com/t5/FortiGate/Technical-Tip-nbsp-How-to-disable-SSL-VPN-functionality-on/ta-p/230801

❶主に7.台OSの場合
・GUIの場合、VPN > SSL VPN設定　にて、「SSL VPNを有効」のチェックをOFFにする

・CLIは以下である。

# config vpn ssl settings
    set status disable
end

❷古いOS　(6.4.8 and earlier, 6.2.x, and 6.0.x).

# config system interface
    edit ssl.root
        set status down
end

(3)SSL-VPNのPWの初期化
すでに認証が突破され、認証情報が盗まれている可能性があるので、パスワードを初期化しておく

5.3 付則的な対策

ファームを常に最新にするのは負担である。基本的に、SSL-VPNのように、社外から内部に通信するのはリスクを伴うので、必要最小限にする。
たとえば、保守専用で利用しているのであれば、IPアドレス制限が有効である（TCP/IPレベルで攻撃ができない）。
設定方法は、SSL-VPNの設定において、「特定ホストへのアクセス制御」で送信元のIPアドレスを制限することができる。
https://cloud.freebit.com/support/faq/vdc/1755/
または、保守で利用する時間以外はLANケーブルを抜染する。
地味ではあるが、GeoIPで海外からのIPはブロックする。こういうコツコツとした対策の積み重ねが大事だと思う。

以下は、大阪急性期・総合医療センターの報告書（https://www.gh.opho.jp/pdf/report_v01.pdf）からの抜粋です。ここにありますように、必要なときだけ接続するという対策が有効です。

5.8.3. 給食事業者を含むサプライチェーン経由での攻撃防御 　外部からの侵入経路（すなわち、外部接続を伴うネットワーク化が行われている箇所）がどれだけあるのかきちんと棚卸を行い、各事業者と協議を行った。そこでは、リモート接続などの接続方法確認や、原 則、ネットワークセキュリティ機器の監視下に置けるような経路の変更のお願い、そして古いファームウェアが確認されれば更新を促し、最新のパッチ対応を行うなどのセキュリティの強化を行った。そのうえ で外部接続方法の強化を行い、不要なプロトコルの排除、ポート番号の変更、常時接続を原則許可せず、接続する場合には「申請制」にし、接続を管理できるよう管理体制の見直しを行った。

また、同報告書には大事な記載がいくつかある。つまり、Foritgateの脆弱性を突かれたら、即、情報漏えいではない。内部の対策がしっかりしてあるか次第である。

M 病院では、給食サーバーへの侵入は許したものの、その先の電子カルテサーバー群とはパスワード やセグメントが異なり、またゲートウェイ端末を設置したりするなど、二次侵入を防ぐ対策が施されてい た。一方、病院は、サーバーB への侵入を許した時点で、電子カルテサーバー群とのパスワードが共通であ り、セグメントも同一であったため、X によりサーバーB を踏み台にして電子カルテサーバー群に容易に 侵入されている。

ここに記載以外では、入られる可能性もある前提で、その先でも二要素認証含めた認証やアクセス制限の強化をする。認証サーバに関しては、ソフトウェアを最新化し、そしてログを強化して不正な通信を監視することも重要。ただ、以下のように、ADサーバへの攻撃は非常に巧みであり、PCなどからログインすると、Mimikatzなどのツールで認証情報が取られる可能性がある。ADサーバにはローカルでしかログオンしないということも選択肢であろう。
https://atmarkit.itmedia.co.jp/ait/articles/1703/15/news064.html

以下の記載を見てみよう。基本的な対策ができていなかったことが問題であった。ただ、攻撃者は巧みなので、たとえば、アカウントロックさえすればいいというものではなく、Mimikatzなどで認証情報を盗めば、一発でログインできてしまうう。多層防御が必要である。

5.8.4. 侵入後のサイバー攻撃拡大防止策 今回、攻撃を受けた他の医療機関では感染が拡大せず、病院だけ感染が拡大してしまった。要因は、①共通のパスワードを使用していたこと、②アカウントロック設定がなかったこと、③管理者権限で運用していたこと、④一部サーバーにウイルス対策ソフトが導入されていなかったことの、主に 4 点である。

また、興味深いのは、EDRやSOCなど、セキュリティベンダが提案するような対策は実施しないという点である。つまり、お金をかけず、既存の対策でも十分に守れるということである。

5.8.1. セキュリティ強化方針 EDR（Endpoint Detection and Response） 15をはじめとしたセキュリティ製品や SOC（Security Operation Center）などのサービス追加などが、サイバーセキュリティ事故が発生した際には検討される。 当然ながら導入できる状況であれば、導入することが望ましい。しかし、病院が、他の一般的な医療機関 同様、まだその段階にはないこと、また製品やサービスを利用すれば、人的資源が限られている中で運用 負荷が高まることなどから、既存の製品を最大限活用した形でセキュリティを強化することを決定した。