別スレッドで「SOHO/SMB製品の研究を開始する」とか言いつつ、思い入れのあるFortigateについては別途このスレッドで紹介させてください。
体系立てず、だらだら書いて行く予定ですが将来的にはまとめ直す意思はあります。
■防御対象のサーバOS隠蔽
多分他のスレッドで嘘を書いてしまっています。ごめんなさい。
Fortigateはトランスペアレントモードの時ですら、OSスキャンに対して「サーバは僕ですよ」と回答する事が可能です。これはサーバのOSの種類を隠蔽できている、という点でメリットになります。
■HA構成と障害試験
HA構成（2台1組で1台の機械として振る舞わせる構成）以前お仕事をさせて頂いた有名Sierが非推奨としていたので弊社でも採用しません。
HA構成のメリットは「設定内容が自動的に同期する」事で運用の手間が減る事だと考えて居ますが、正副で別の回線を使用する場合にHA構成を採用する事は
インターネットを直接終端出来なくなる＝必要な機器の台数が増える）事を意味しますので採用しない、のが弊社独自の見解となります。
障害試験についてはトランスペアレントモードの構成を中心に掲載して行く予定です。
ありがちなアンチパターンも、掲載する予定です。
※よく見かけるのは「実はスパニングツリードメインが生成されて居なかった」
＝障害試験は一見上手く行くが、実はMacアドレステーブルのタイムアウト（5分間）で切り替わって居ただけだった」と言うパターンです。
この場合、最大5分間の通信断が発生します。Rapidのスパニングツリーであれば「1発フラッドするだけ」が理論値となるので構築担当者の設計ミスとなります。
※こぼれ話
他に書く場所が無いのでここに書きますが、YamahaのVRRPはICMPリダイレクトが有効だったはず。。「他社のVRRPと連携出来ない」原因となり得ます。
YamahaとNECについては現行機種を買ってまで検証する予定は有りません。
2022年前後の半導体不足の折も、数日でメーカ直販出来た様な不人気機種ですのでその脆弱性について日々研究している様な会社も研究者も少ないです。（当時、「弊社なら翌日までにxxx台（3ケタ台）ご用意できます！」と普段しか売りにならない台詞を言ってきた営業姿勢に関しても脳血栓的なものを感じます）
脆弱性が頻繁に発見される機種は「発見して貰い易い」、つまりメリットであり、
滅多に発見されない機種は「誰も研究して居ない」、つまりデメリットである事を宣言させて頂きます。
日本製の機械を弊社は推奨しません。プロレベルのテクニカルライターによって英語で書かれた仕様（資料）が存在しない製品は国際的に通用しません。ITセキュリティ機器としては致命的な欠陥となります。
■FortiSandBox
本物のマルウェアを通過させて検知可否の検証を行います。
入手先は見当がついて居るのですが、囮とするPCを選定中、かつ現在使用して居るFortigateのライセンス期限が間近なので貯金中です。
乞うご期待。
■セキュアDNS（Fortigate自身が発するリクエスト）
DNS通信が乗っ取られないように、認証アリのサーバで名前解決する機能です。
※無効の状態だとこんな感じです。
※有効にするとこんな感じになります。
■オープンリゾルバ対策済みDNSキャッシュサーバとして
通常、ユーザ企業のキャッシュサーバは外部には公開しないはずですがLAN内の端末が乗っ取られた場合、内部から攻撃が可能です。（オープンリゾルバでは無いにも関わらず）攻撃を受けた際どのように振る舞うかを検証します。
ヴァイラスに感染した端末自体の再現は網羅しきれないので行いません。
セキュアDNS有効時、FortigateとPC間のセッションにもセキュリティ機能が働くのか否かを検証します。場合によっては「ブラウザによって＝PCとインターネット上のDNSサーバ間直接セッションを張る」つまり、Fortigateは介在出来ない、が「検証結果」となる可能性があります。
（弊社のサービスは「知識」であり、「機械の転売」では有りません。「出来ない事」「PCだけで対応可能」な事も明示的に発信して行きます。）
他、Fortigateが上位のDNSサーバへ問い合わせる通信が乗っ取られるケースを再現します。
以前、問い合わせ先のDNSサーバをFakeDNSにして実験した際、「騙される」事までは検証済みです。
今回改めて、改めて「乗っ取られる様子」とセキュアDNS機能によって「乗っ取られない」事を検証します。
■セキュアMail
メールをドメイン認証する機能が独立して存在して居ますが、メールを受信してしまってもそこから情報を漏洩させなければ良い（出口対策）と言う考えを適用すると、
URLフィルタリングやセキュアDNS（サーバ側で危険なIPアドレスを検疫する）、C&C（これも、危険と判断されたIPアドレス宛への通信を禁止する機能です）を併用するべきです。
また、掲示板等へ書き込みを行わせるようなボットに感染してもURLフィルタリングによって、掲示板への書き込みそのものを禁止する事が可能です。
※当件についてはビジネス上「熱い」ジャンルなので具体的な方法を無料で公開する事は差し控えます。
※PPAPの禁止が一般化する事で
「メール自体が暗号化されているからファイルはそのまま添付しても大丈夫」
と考える企業は少数派で、実際にはWebストレージを使う事が増えている筈です。
Webストレージのよりスマートな使い方を以下の「WAN最適化～」でも検証して行きます。
■WAN最適化機能
Linuxを（tcコマンドで）回線シミュレータ的に使用し、意図的に品質を悪化させたときFortigateによってどれくらい品質を回復できるのかを検証を行います。
※現在使用中のNASに「同期」と言う項目があるのですがネットワーク冗長と言う意味であった場合、同じNASをもう一台買ってWAN最適化機能がWAN高速化装置「としても」使えるのか検証します。
HTTPSを使用する音声アプリをキャプチャして、RTTやジッタを計測してみても良いかも知れません。
■プロキシサーバ（フォワード／リバース）として
正直「UTM挟んでればプロキシで終端する必要なく無い？」と思うのですが、「この機能じゃなければ出来ない事」を探索します。
クライアントに対向のIPアドレスを知らせたくない場合はリバースプロキシを使う手がありますが
Fortigateがリバースプロキシとして使えるか否かは今後検証します。
■IP Reputation Database（IPアドレスの「評判」を調べる機能）
この機能自体は リンク先スレッド で既に触れていますが、もう少し突っ込んだ検証を行います。
■IPS＆WAF
各種の侵入試験（ペネトレーションテスト）を行い、防御できるか否かを検証する予定です。（個人ブログでは既に発表済みの内容です）
また、C&C IPアドレス（危険とされるIPアドレス）をローカル環境内の他のNW機器に設定し、発信／着信共にブロックされる事を検証します。
ステルススキャンの防御と、メール発報の機能も検証します。（SMTPでしか経験が無いので、未知の方法にチャレンジします）
■セキュアWi-Fi
無線LAN経由で攻撃を行い、通信をブロックする検証を行います。現在Kaliを研究中です。
①不正APの検出
・WLCとして設定されたFortigateの配下にあるAPと配下にないAPが同一のSSID/PSKを
送信している事を発見する機能を検証します。暇を見て追記します。
②下記画像の機能が気になって居ます。Forti-wifiとForti-AP（共に入手済みではあります）を組み合わせて検証してみます。
■Wi-Fiクライアントとして
FortiWi-Fiを他のAP配下に接続します。先ずは下記ペインでWireless-ClientModeをApplyします。
※この後、再起動を求められるので再起動させます。
すると、下記ペインにて接続先のAPを選択する事が出来る様になります。
接続したいSSIDを選択後、Connectを押下し、SecurityModeを「Open」以外に選択するとPSK（事前共有鍵）の入力を求められるので入力し、再度Connectを押下します。
DashBoardのCLIから上記AP経由でデフォルトゲートウェイにPingが出来る様になりました。
この時点ではデフォルトゲートウェイまでしか疎通せず、アップリンクのAP以遠にあるインターネットへは疎通しません。
そこで、デフォルトゲートウェイを手動で設定します。
インターネットへPingが可能になりました。
※下記ペインにて Retrieve default gateway from server. を有効にすると、WifiインタフェースからIPアドレスが失われてしまうのでこの方法は避けた方が良いと思われます。
■QoS
NW機器としてもしっかり機能することの検証（指定したトラフィックの通信量が、設定した上限値を上回らない）を行います。
QoSの性能評価は弊社の強みの1つでもあります。
また、PQと言うレガシな優先制御方式が「ロングパケットをいつまで経っても転送しない」様子を検証で証明します。（このアンチパターンを存じない＝何でもPQに放り込んでしまう、つまりはCPUの動作原理に明るくないNW技術者が多く存在します。）
■VoIP
Web-RTPの時代に今更の「SIPが使う特殊NAT」なんて使わない気もしますが。。。
VoIPについては「Web-RTPプロバイダ」が出鱈目ばかり言ってくるのを次々と論破した事があるので内容を以下に列挙します。
・パケットの内容はRTPでは有りません → Wiresharkで「RTPとして解釈」させたら中身はRTPで
ある事が判明しました。なお、パケットを音声ファイルに変換することまでは可能ですが
スペクトラムを見ると全帯域に拡散している＝暗号化されていた事からその時の事案である
「雑音が入る」原因を特定する事には至りませんでした。
・上記QoSに書くべき内容ですが、Web-RTPプロバイダは「excess burst やcommitted burst」
を理解して居ない場合が多いです。「対向ルータがCiscoだから上手く受け止めてくれる」などと
主張して来たりします。RSVPすら理解して居ない。口頭で双方向に話せば直ぐ化けの皮は
剥が「せ」ますね。
・VoIPに入るノイズの原因は 「ノイズキャンセリングがAI式だから」の場合があります。
オペレータさんの背後から混入する「他人の声」が排除できないのですね。
昔ながらの「背後からの音声の位相を反転させて重畳する」方式が効果的な場合があります。
・電磁波のせい → 数日間スペアナで測りましたが40Mhz～6Ghz帯まで、
「瞬間的に発生する電磁波」は計測できませんでした。
■クラウドサービス＆Webフィルタリング
クラウドサービスは「通信中にサーバが地理的に移動する」事があるため、通信中に対向IPアドレスが変わってしまう事があります。
この仕様によってWebフィルタリングを有効化できない事例が存在します。原因を下記に示します。
通信中、パケットのフラグメントが起こると、某国産有名UTM（YとNの2社）はどちらも通信が途絶えてしまいますが、Fortigateは問題なく通信を継続することが出来ます。
通信が遮断する原因は両メーカーともに同じです。（メーカーに直接確認済み。運用の現場で起こっている事を把握できていない時点で「どうかな」と思いました。）
・DNSを利用せず、パケットのペイロード内の文字列を使ってWebフィルタリングをしているのだが、フラグメントしたパケットは「中身」を読む事が出来ない。
・許可中のIPアドレスは内部的にキャッシュされて居る。
FortigateはFQDNを使ってWebフィルタリングを行うため、この通信断が起こる事は有りません。
（上記国産Y社は販売店にアルゴリズムを確認しただけですが、N社については私が実際に経験した上でメーカーにエスカレーションし確認をしています。
N社の場合は計50回程度試験したうち 6回中5回「以上」この事象が起こりました。Fortigateについては6回連続成功したところで検証を切り上げています。）
この事を弊社環境で再現する形で検証して掲載します。
備忘として、使用するツール類をメモしておきます。
使用するツール
・Cisco800（Webサーバとして使用する。セカンダリIPアドレスを使用し、複数のIPアドレスを設定する）
・FakeDNS
・Httping
■TwiceNAT（クラウドと自社環境が同一IPアドレスレンジである時の対処法）
大した技術ではありませんが、クラウド内と当方のLANが同一セグメントとの理由で導入を諦める例がいまだにある様です。設計者がSSGと同じ方なので（Juniper社はNetScreen「社」を買収しただけ、と言う事は意外と知られて居ない様です。
※実装できるとは限らないので実際に実装して検証を行います。
■FQDNルーティング（DNSルーティング）
Office365のアップデート等、通信量の大きい回線は専用の回線や社内のWSUS（もう廃止されたような気も）を使用すべきですが
DNSが解決するIPアドレスに変更があると、通常の方法ではルーティングを制御することが
出来ません。
このため、DNSの情報を元にルーティングを行います。この事を実際に検証して掲載します。
設定はこんな感じです。アドレスポリシーを作成する際「スタティックルートで使用する」と言うチェックボタンがあるので有効にするとスタティックルート作成のペインが下記のようになります。
■外向けロードバランシング
複数の回線を使っている時、Active/Activeの高コストパフォーマンスを実現します。この事を実際に検証して掲載します。（片方の回線の品質が「常に」低い、アンバランスな構成を使用します）
内向きのロードバランシングも出来ますが死活監視が簡易なものしか出来ないのでWebサーバのロードバランシングは出来ません。
そう言えば、複数のDNSサーバと組み合わせれば一種の広域ロードバランシングも可能な訳ですが、Fortigate自体がDNSコンテンツサーバとして振る舞う事が可能なので
Fortigate単体で広域ロードバランシングが出来ないか検証してみます。
※他のNW機器でTwiceNATさせれば良い（ロードバランシングさせた先で、宛先/送信元を同時にNATさせFortigateにDNSリクエストする）のですが、それは何か違う。。
■スプリットVPN
Office365やSNMP over TLS、DNS over TLS等々、暗号化済みの通信にわざわざIPSECをかけて
パフォーマンスを無駄にしている企業を多く見受けます。
選択した通信（SMB＝NASが使用する通信など）にのみ、暗号化を行う様子を実際に検証して掲載します。
資金の潤沢な企業であればより大型の機械に買い替える事で解決している様ですが弊社のように
SI的な「転売」を行わない＝高価な機械を売りつける事をしないサービスの強みを示せる事案であると考えています。
■SSHインスペクション
他スレッドの「Telnetでサーバのメモリをダンプして検疫する」事から思いついた需要です。
SSHだと暗号化されて居るのでサーバのメモリ内に含まれるマルウェアを検知できなそうですが、インスペクションと併用すれば可能になるかもと。
また、インスペクション機能によってSCP/FTPS/SFTPを遮断しつつSSHだけを許可する、事が
出来ないか（SSHサーバ本体でSCP/FTPS/SFTPを禁止するのでは無く、NW機器側でファイル転送通信を遮断）の検証結果もここに掲載します。
Webサーバのアクセラレーションをするにはパワー足りないに決まってますが、SSHの証明書剥がしは挑戦したいです。下記画像だとどうやってSSH秘密鍵をインストールするのか分かりませんが。。
■ミラーリングしたパケットのフィルタリング
ステートフルに「振る舞わせない」と言う機能があった「はず」なので、トランスペアレントモードと組み合わせれば実現できないか検証します。
ただ、Fortigate単体で「フィルタリングしながらキャプチャする」事が可能なのでトランスペアレントモードでフィルタリングすれば済むような気も。。。
■TimeBaseアプリケーションコントロール（ペアレンタルコントロール）
特定の時間帯のみ、指定したアプリケーション（の通信）を許可します。
下記は
6時～10時は全通信を許可、
それ以外の全時間帯は、動画(Youtube)を遮断して居ます。
IPv4の「親」ポリシーは「許可」、アプリケーションコントロールの「子」ポリシーでVideo/Audioを遮断して適用します。この場合、動画のみが遮断され、他の通信は許可されます。
Youtubeは遮断されますがニュースサイトの動画は遮断されません。
■マルチキャスト
Wifiと組み合わせるときに有効な、宛先Macアドレスをマルチキャストからユニキャストに変換したり、ロードバランスさせたりする機能があるかは「不明」ですがひとまず下記のような制御が出来るようです。VNCとかでクドクド検証するのが面倒なので ひかりTV が我が家にやってきた後で対応します。（本物のパケットで制御する方が検証として意味がありますから）
■レジデンシャルIP攻撃対策
テレワーク勤務者の各家庭に1台ずつ、トランスペアレントモードで配置し、IPS/WAFをWAN/LAN逆方向に検疫させます。検証不要かと。
■Dockerのコンテナ間通信を検疫する
トランスペアレントモードであれば可能かと。追って実機検証してみます。意味あるのか不明ですが（もしかするとVM型の仮想筐体で検証するかもです）