レイヤ4以下のセキュリティの話題

レイヤ4以下のセキュリティの話題
ネットワークオリエンテッドな記事も含む。

イーサネット（有線）をオシロスコープで測ってみる

2台のCiscoルータをこんなものを挟んでリンクアップさせる。
オシロで測れる周波数は上限200Mhz。BASEバンド変調のbpsとどう絡むのか不明だが一旦、
Speedを10Mbpsの固定にする。

なかなか上手く波形が出ない中、この２つの端子間で、電圧変動を観測、

動画を取ってみた。https://youtube.com/shorts/IS477BRRO7Q?feature=share


今後は再送攻撃（colasoftのPacketBuilder等を使って）　をすると同じ波形が繰り返し出るのか、確認してみたい。

ーつづく－

nmapが参照しているDNSサーバがそもそも偽物の場合の挙動

　→FakeDNSではWindows10（以降）を騙せない時があるので
　　→FortigateをFakeDNSで騙す
　　　→そのFortigateのDHCPサーバでnmap積んだWindowsを騙す
方針で行くつもり。
　→実践は後日。

トランスペアレントモードのFortigateに　VRRP/HSRP/STPの制御フレーム/パケットを「通過」させる

Cisco編
■2台のルータ間にトランスペアレントモードのFortigateを挟み、VRRPを疎通させる
結果
Router#show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Gi0/5              1   100 3609       Y  Backup  192.168.84.2    192.168.84.254
Router#
自身はBackUpになっている＝Masterを発見できている。

■2台のルータ間にトランスペアレントモードのFortigateを挟み、HSRPを疎通させる

結果
Router#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi0/5       1    100   Standby 192.168.84.1    local           192.168.84.254
Router#

自身はBackUpになっている＝Activeルータを発見できている。

NEC編

こんな

こんなで

2台のIXをトランスペアレントモードFortigateに挟んだ。
VRRPは正常に動いた。

L2編
■2台のL2SW（Cat2960とAruba2530）間にトランスペアレントモードのFortigateを挟み、STPを疎通させる
コンフィグ（一部）
　・Cat2960
　　　spanning-tree mode rapid-pvst
　　　spanning-tree vlan 1 priority 61440　→ArubaとSTP喋れていれば、Rootにならない。
　・Aruba2530
　　　spanning-tree 1 path-cost 20
　　　spanning-tree force-version rstp-operation
結果（Cat2960）

Switch#show spanning-tree | i root
             This bridge is the root
Switch#
結果（Aruba2530）
HP-2530-24G-PoEP# sho spanning-tree | i root
  CST Root Port        : This switch is root
HP-2530-24G-PoEP#

両方ともrootになっている＝Arubaとの間でSTPが喋れていない様だ。

→Cat2960とAruba2530を直結してみる
結果（Cat2960）
Switch#show spanning-tree | i root
Switch#
結果（Aruba2530）
HP-2530-24G-PoEP# show spanning-tree | i root
  CST Root Port        : This switch is root
HP-2530-24G-PoEP#
Cat2960はRootじゃなくなっている＝Arubaと会話できている＝FortigateがBPDUを遮断する事が証明された。

ではCat2960同志では？
コンフィグ（一部）：1号機
hostname Switch
spanning-tree mode rapid-pvst
spanning-tree vlan 1 priority 61440
コンフィグ（一部）：2号機
hostname Switch002
spanning-tree mode rapid-pvst

結果（Cat2960の1号機）
Switch#show spanning-tree | i root
             This bridge is the root
Switch#
結果（Cat2960の2号機）
Switch002#show spanning-tree | i root
             This bridge is the root
Switch002#

→Cat2960同士でもSTPが会話できていない！

直結の場合
結果（Cat2960の1号機）
Switch#show spanning-tree | i root
Switch#
結果（Cat2960の2号機）
Switch002#show spanning-tree | i root
             This bridge is the root
Switch002#

そこでこのコマンド

config system interface
edit インタフェース名
set stpforward enable
next
end

を入れると。。

ルートブリッジじゃない＝他機とSTP喋れる様になってる！

ー他、OSPF、EIGRP、BGP等でも確認する予定ー
　→ユニキャストかマルチキャストか、より　パケットかフレームか
　　の方が重要かも。igmpでも通してみようか。。。

　　→となるとcdp、vtp、dtp、pagp、lacpとか他にも気になるものは沢山ある。

セキュリティアプライアンスにありがちな、「電源断時にイーサネットをバイパスする」機能　→電源断時にAutoMDIが効かなくなる現象への対策

Auto-MDIのON/OFFとSpeed/Duplexは「別途」設定できる

Catalystの有名な仕様として、Speed/Duplexを固定にすると、Auto-MDIは無効に
なる、と言うのがあったけど5年くらい前から

・「デフォルトで有効のまま」
・無効化したければ明示的に設定する
になっています。
interface GigabitEthernet0/1
 switchport access vlan 2
 switchport mode access
 speed 1000
 no mdix auto

SSHで同じ文字が連続しても、ハッシュ値は変わっていて欲しいが。。。

SSHって「1文字1発」でパケット飛ぶのだっけ？？ひとまず、ciscoのbanner motdに同じ文字を沢山入れて、
banner motd ^C
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaa
^C

この後、
　　パケットをキャプチャ
　　　→SSHでフィルタ（3wayHandShakeを除去するため）
　　　　→show banner motdの１回目→テキスト化
　　　　→show banner motdの２回目→テキスト化

上記２つのテキストをエクセルに貼り、
　　重複の削除　→　ソート　→　マクロとか使って連続スペースを１個の
スペースに変換する。

結果

衝突してる奴が結構ある？？？？

もっと深く踏み込んでいく予定。　ーつづくー

IPSECをnmapでスキャンする

　→もうちょっと研究が必要な様子。
※中途半端な記事が多い理由＝アイデアの書き出しを先行させているためです。

IPSECで鍵の長さを変えると、IPヘッダのサイズは影響を受ける？

以前実験済み。エビデンス探索中。再試験する方が早いかも。結論としては「MTUが変わる」だったりする。

通信中にDNSのAレコードが変更になったら？

とある本番環境で、

UTMでFQDNホワイトリストを使っている。
この環境で、アップロードが「途中」で失敗する事象が発生している。

ログには、https://xxx.xxx.xxx.xxx（生IP）を遮断したログが出ている。

　→ローカルプロキシで確認しても、上記生IPは登場しなかった。
　　→ダイナミックに生成されるURLがワイルドカードに沿っていない訳では無さそう。
　　→キャプチャしたところ、フラグメントしたところで通信が遮断されている事が
　　　判明した。
　　　メーカによるとフラグメントしたパケットはキャッシュで許可される、との事。
　　→UTMはFQDNを名前解決ではなく、「文字列」で判断し、通信を制御してるのだ
　　　そうな。マジスカ仕様。

　　→通信中、FQDNでPingを打ち続けたところ、　　
　　　通信中にAレコードが変わってしまう事が判明。

　　→「通信中にAレコードが変わってしまえば、キャッシュ効かないよね」
　　　との仮説が成り立つ。
　　→名前解決するタイプのＵＴＭに交換したところ、事象は解決した。

→下記はこの結論を導くまでの事前検証。
　実際に、通信中にAレコードを変更してみよう。
　→方法
　　→EX-Pingを打ちつつ、FakeDNS（サーバ類の設定方法は
　　「検証用サーバ構築例」で）

にて、Ａレコードを変更する。

途中でIPアドレスが変更になっている。

WireSharkで見てみると、
192.168.200.238がサーバなので、Aレコードの変更は「クライアントが
何か聞きに行く」訳では無い「っぽくて」サーバから発信される事が判明。

→当たり前としか言いようが無いのだが検証で確認してみる。

「っぽい」とするのは何故か　→　TTLが切れたらクライアント自らAレコードを
機器に行くのか　が未判明だから。では疑い深い検証の続き。

→DNSサーバをFakeDNSからBlackJumboDogに変更する。
　→こんな感じに設定する。（設定方法は「検証用サーバ構築例」参照）

今回重要な部分は下記の赤枠で、「ttlを短くする」こと。→15秒に設定。
　→本当は4つとも変更する必要は無いかも知れない。

で、クライアントからPingする。

C:\User\>ping bbbb.aaaa

bbbb.aaaa [8.8.8.8]に ping を送信しています 32 バイトのデータ:
8.8.8.8 からの応答: バイト数 =32 時間 =5ms TTL=116
8.8.8.8 からの応答: バイト数 =32 時間 =5ms TTL=116
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=116
8.8.8.8 からの応答: バイト数 =32 時間 =5ms TTL=116

クライアント側でDNSをキャプチャした結果、

15秒になっている。
で、動画を取っている訳ではないのでここでエビデンスを上げれないのが口惜しいが
いつまで経っても「自動的に再取得」はしない模様。（だってキャッシュがあるもん
あたりまえよねえ）→つまりttlが切れたもキャッシュを持ち続ける。
　→数日経ったら記憶が曖昧に。。（アップロードできなくても自分のために動画を撮っておくべきか）

いま言える事。
　　・DNSサーバ側で突然Aレコードが変われば、解決結果は直ちに反映される。
　　・ttlが切れても通信が無い限りクライアントは新たにリクエストはしない。

ttlが切れても、キャッシュは消えないはず、を下記で検証。
Ping-tで打ち続けつつ、DNSのキャプチャを続ける。

で、、、、所謂「仕様通り」であることが証明できた。

麗しのL2ループ

L2で意図的にループを起こして観察したことが無かったので、改めてやってみた所、
己の無知を思い知る事に、、、

①元のMacアドレスがあるInterfaceはログに現れない
（実は有名？）

②当該MacアドレスのあるInterfaceを抜線しても、Flapは止まらない（当たり前）
③当該MacアドレスのあるInterfaceを抜線後、更にMacアドレステーブルをクリアしても、止まらない。（連発してクリアしまくるとどうなるのだろう？）
:Start
sendln 'clear mac address-table dyna'
pause 1
goto Start
的な。

ふと気になったのが「3つのインタフェースから、同一のMacアドレスを受け取ったら
どうなるの？と言う事。結果は下記。（送信元Macアドレスをはaaaa.aaaa.aaaaをIPSendwinで偽造。）

ーつづく－

Forti-WLCとCisco-WLCを共存させる

ざっと書くと下記２パターン

・L2ローミング

L3ローミング

ーつづくー

CiscoAP‐WLCの検証

　モニターモードのAPって何を出来るか、をとことん追求してみたい
　後日執筆予定。

Wi-Fiローミング時のMacFlapを意図的に起こす（L2でのモバイルIP)

以前実験済みだが、エビデンスが少ないので再実験してから記載する予定。
・FortiAP、市販AP、モバイルバッテリー、昇圧器（USB5を12Vに）、30ｍのLANケーブルを用意。

・検証内容
①普段使っている家庭用APと同じSSIDを　上記家庭用APから吹かせる。（30メートル程離す。APの電源はUSBモバイルバッテリーを12vに昇圧して使用する）
　→この時、MacFlapを頻繁（15秒に2回以上、だったかな、、）に起こす方法を探ってみる。
　→MacFlapが起こればOK。（2つのAPにはCatalystを挟んでログを記録する）
　
②Forti-wifiと同じSSIDを　上記FortiAPから吹かせる。（30メートル程離す。APの電源はUSBモバイルバッテリーから供給する。※FortiWifiのWLCは当然有効にする）
　→FortiWifiとFortiAPにはCatalystを挟む。キャプチャでMacFlapの代わりにG-ARPが飛んでいることを確認する。）

はい。今日から連休です。3児のパパとしてはNWの実験よりも優先する事があります。
また今度お会いしましょう。あーでもその後すぐNW構築で数日出張するので、この記事のこと思い出すのは結構未来になると思います。

番外編：純粋にNWの話

スパツリの備忘録

　ブリッジモードのセキュリティアプライアンスを既存構成に組み入れると何かと
 　トラブルが多い。
　遷移状態を完全に把握しておかないと、後々困ったりするので復習と備忘

ーつづく－