GoBGPでBGPフルルートmrt injectionでnext-hop-self & set ip next-hopする方法
- 構成図
- フルルートのinject
- ①GoBGPでnext-hop-self(next-hop: 192.168.100.60)
- ②GoBGPでset ip next-hop(next-hop: 192.168.100.1)
- FRR1側のIPv4出力(set ip next-hop)
- FRR1側のIPv6出力(set ip next-hop)
GoBGPで①next-hop-self , ②set ip next-hopを実現する方法。
構成図
フルルートのinject
gobgp mrt inject global rib.20220311.0600
①GoBGPでnext-hop-self(next-hop: 192.168.100.60)
[global.config] as = 65000 router-id = "192.168.100.60" [global.apply-policy.config] export-policy-list = ["next-hop-self"] [[neighbors]] [neighbors.config] peer-type = "external" neighbor-address = "192.168.100.61" peer-as = 65001 [[neighbors]] [neighbors.config] peer-type = "external" neighbor-address = "192.168.100.62" peer-as = 65002 [[neighbors]] [neighbors.config] peer-type = "external" neighbor-address = "fd00:192:168:100::61" peer-as = 65001 [[neighbors]] [neighbors.config] peer-type = "external" neighbor-address = "fd00:192:168:100::62" peer-as = 65002 [[policy-definitions]] name = "next-hop-self" [[policy-definitions.statements]] name = "statement1" [policy-definitions.statements.actions.bgp-actions] set-next-hop = "self"
②GoBGPでset ip next-hop(next-hop: 192.168.100.1)
[global.config] as = 65000 router-id = "192.168.100.60" [global.apply-policy.config] export-policy-list = ["set-ip-nexthop-v4","set-ip-nexthop-v6"] [[neighbors]] [neighbors.config] peer-type = "external" neighbor-address = "192.168.100.61" peer-as = 65001 [[neighbors]] [neighbors.config] peer-type = "external" neighbor-address = "192.168.100.62" peer-as = 65002 [[neighbors]] [neighbors.config] peer-type = "external" neighbor-address = "fd00:192:168:100::61" peer-as = 65001 [[neighbors]] [neighbors.config] peer-type = "external" neighbor-address = "fd00:192:168:100::62" peer-as = 65002 [[defined-sets.neighbor-sets]] neighbor-set-name = "ns-ipv4" neighbor-info-list = ["192.168.100.61","192.168.100.62"] [[defined-sets.neighbor-sets]] neighbor-set-name = "ns-ipv6" neighbor-info-list = ["fd00:192:168:100::61","fd00:192:168:100::62"] [[policy-definitions]] name = "set-ip-nexthop-v4" [[policy-definitions.statements]] name = "v4-statement1" [policy-definitions.statements.conditions.match-neighbor-set] neighbor-set = "ns-ipv4" match-set-options = "any" [policy-definitions.statements.actions.bgp-actions] set-next-hop = "192.168.100.1" [[policy-definitions]] name = "set-ip-nexthop-v6" [[policy-definitions.statements]] name = "v6-statement1" [policy-definitions.statements.conditions.match-neighbor-set] neighbor-set = "ns-ipv6" match-set-options = "any" [policy-definitions.statements.actions.bgp-actions] set-next-hop = "fd00:192:168:100::1"
FRR1側のIPv4出力(set ip next-hop)
frr1(config-router-af)# do show ip bgp neighbors 192.168.100.60 received Network Next Hop Metric LocPrf Weight Path *> 1.0.0.0/24 192.168.100.1 0 65000 6939 13335 i *> 1.0.4.0/22 192.168.100.1 0 65000 6939 4826 38803 i *> 1.0.4.0/24 192.168.100.1 0 65000 6939 4826 38803 i
FRR1側のIPv6出力(set ip next-hop)
frr1(config-router-af)# do show bgp neighbors fd00:192:168:100::60 received-routes Network Next Hop Metric LocPrf Weight Path *> 2001::/32 fd00:192:168:100::1 0 65000 6939 i *> 2001:4:112::/48 fd00:192:168:100::1 0 0 65000 6939 112 i *> 2001:200::/32 fd00:192:168:100::1 0 65000 6939 2914 2500 2500 i *> 2001:200:900::/40 fd00:192:168:100::1 0 65000 6939 2516 7660 7660 7660 i
【RFC5925】BGP MD5認証の代替案 TCP-AO(TCP Authentication Option)
BGPのpeer認証は一般的にRFC 2385(Protection of BGP Sessions via the TCP MD5 Signature Option)で提案されているMD5を利用しているのが一般的ですが、この案を廃止し、代替案としてTCP-AO(TCP Authentication Option)が提案されています。
https://conference.apnic.net/50/assets/files/APCS790/The-TCP-Authentication-Option.pdf
TCP-AO(TCP Authentication-Option)とは
TCP-AO(TCP Authentication-Option)とは、RFC5925,RFC5926で提案されている
トランスポート層の認証を行うためのTCP option(Kind 29)です。
RFC7454(BGP Operations and Security)では、MD5よりTCP-AOを優先すると良いと提案されています。
本記事は、NANOG80(It is Time to Replace MD5)、APRICOT51、APNIC50を元に調べた情報のメモ書きです。
詳細は、NANOG80のスライド及びRFC5925、RFC5926をご参照ください。
RFC 5925 - The TCP Authentication Option
設定に関しては、Ciscoのマニュアルが分かりやすかった。
TCP-AOのメリット
TCP-AOを利用することで、既存のMD5に比べて主に以下の利点があります。
1. BGPやLDPなどの長時間持続しているTCPコネクションに対する攻撃への対策強化
2. 既存TCPコネクションを持続したまま、共有鍵の変更が可能
3. 複数の認証アルゴリズムのサポート
■BGP認証なしの場合
以下の攻撃を受け、TCPのセッションがresetされたり、
乗っ取りなどが発生する可能性がある。
-Blind insertion attack
–Reply attack
■Blind insertion attackの手法
- ルータAは、ルータBとのBGPセッションを維持
- ルータC(攻撃者)は、ルータBに毎秒数個の偽装パケットを送信
- ソースIPアドレスをルータA(スプーフィング)
- TCP/179 RSTパケット, ランダムなシーケンス番号
- ルータBは、シーケンス番号が無効のため、パケット破棄
- いずれルータC(攻撃者)は有効なシーケンス番号のパケットを送信
- BGPセッションがリセットされる
■BGP MD5認証[rfc 2385]
- 送信ノードと受信ノードに事前共有鍵を設定
- 送信ノードの手順
1. 各TCPセグメントのメッセージ認証コード(MAC)を計算する
2. MACの計算にMD5を利用
3. TCPセグメントと事前共有鍵を使ってMACを計算する
4. 各TCPセグメントにMD5署名オプションを含める
5. MD5 signature optionにMACを含める
- 受信ノードの手順
1. 受信したTCPセグメントごとにMACを算出
2. 計算したMACと受信したMACが一致しない場合はパケット破棄
■MD5の問題点
- 共有鍵の変更時、TCPコネクションをリセットする必要がある(共有鍵はそのまま)
- 認証アルゴリズムの俊敏性が求められる
- MD5は衝突の弱点あり
■認証に関する新しい要望
- TCPセッションをリセットすることなく事前共有鍵を変更可能
- 複数の認証アルゴリズム
■TCP-AOのコンセプト
- MKT (Master Key Tuple)
- 各ノードに1つ以上のMKTが設定される
- トラフィックキーの生成に使用
- トラフィックキー
- 各TCPセグメントのMACを生成するために使用
- TCP認証オプション
- TCPセグメントを認証するために使用
- MAC、KeyID、RNextKeyID を含む
- KeyIDは，MACの生成に使用されたMKTとトラフィック・キーを識別
- RNextKeyは、受信ノードが次のセグメントのMACを生成する際に使用するMKTおよびトラフィックキーを特定
■MKT
- TCPコネクションの識別子
- 送信元アドレス、送信先アドレス、送信元ポート、送信先ポート
- ワイルドカード可
- TCPオプションフラグ（MACでカバーされるTCPオプションを決定)
- 識別子
- 送信用、送信：送信セグメントのKeyIDの生成に使用
- 受信時、受信：インバウンドセグメントのKeyIDを解決するために使用
- 認証アルゴリズム
- マスターキー
- 鍵導出アルゴリズム
- 各ノードは1つ以上のMKTで構成されています。
- 各ノードはそれぞれのMKTから4つのトラフィックキーを得る
>Send_SYN_traffic_key,Receive_SYN_traffic_key,Send_other_traffic_key,Receive_other_traffic_key
- 各ノードは、どのMKTがアクティブであるかを独自に判断
- 方法はRFC5925の範囲外
- 多くの実装では、各MKTの開始時刻と終了時刻を指定しています
■認証
- 送信ノードの手順
- 各TCPセグメントのメッセージ認証コード(MAC)を計算する
- 適切な認証アルゴリズムを使用
- TCP セグメントとアクティブなトラフィックキーを使って MAC を計算
- 各セグメントに TCP-AO を含める
- TCP-AO の署名オプションには、MAC、KeyID、および RNextKeyID が含まる
- 受信ノードの手順
- 受信したTCPセグメントごとにMACを算出
- 受信した KeyID に関連するアルゴリズムとトラフィックキーを使用
- 計算したMACと受信したMACが一致しない場合はパケット破棄
■シーケンス番号のロールオーバ
TCPは、32bitsのシーケンス番号を使い回す(ロールオーバー)。
回避策として、シーケンス番号に加え疑似ヘッダの32bitsを拡張し、64ビットのシーケンス番号スペース(SNE)を利用することでリプライ攻撃を阻止。
■MD5とTCP-AOのオプションミスマッチ
TCP-AOとMD5の同時利用は、RFCで禁止(MUST NOT)されていますが、Cisco社の場合、
対向機器でTCP-AOオプションを未サポート時に接続できるオプションが存在します。(動作未確認)
"accept-ao-mismatch-connections"
TCP-AOオプションなしでピアから接続を受信したときに、接続を非TCP-AO接続として受け入れるオプション。
■NAPTなどを利用するミドルボックス(FWなど)を中継する場合の問題点
- IPアドレスまたはポートを変更しないミドルボックスはサポートする。
- TCP MSSやWindow Scaleなどを変更するミドルボックスではMACの計算で失敗する場合がある。
Ciscoには「"include-tcp-options":MACの計算にTCP-AO以外のTCPヘッダを見ない」があるため、
ミドルボックス対策の設定なのではないかと思う(用途不明)
■実装状況
- ノキア SR OS 16.0.R15, 19.10.R7, 20.5.R1 (Juniper社との相互運用性テスト済み)
- シスコ IOS XR 6.6.3および7.0.1以降は安定している
- ジュニパーネットワークス：20.3R1
- Huawei社：2021年第2四半期を目標とする
- Arista："スケジュールについてはノーコメント"、"我々はそれに取り組んでいる"
■関連ソリューション
RFC 5082: GTSM(The Generalized TTL Security Mechanism (GTSM))
後で読む。
■参考資料
RFC 2385 - Protection of BGP Sessions via the TCP MD5 Signature Option
RFC 5925 - The TCP Authentication Option
RFC 5926 - Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)
RFC 7454 - BGP Operations and Security
JANOG43の発表を聞いてSRv6サービスチェイニングを試してみた
JANOG43のDAY1でSRv6についての発表を聞きました。
“SRv6でサービスチェイニングをやってみた”という発表が非常に分かりやすく、
自分もLinuxでSRv6を動かすことが出来るのではないかと思い、実際に検証を行ってみました。
動作環境
ESXi6.5
-Ubuntu18.10 (Linux Kernel 4.18) 6台
- SRv6動作マシン 4台
- クライアント/サーバ 2台(各1台)
SRv6はkernel 4.10以降で動作するとのことで、
CentOSではまだ3.x系のため、kernelをビルドし直す必要があるため、
今回はUbuntuを採用しました。
Linux Kernelの対応状況については下記を参照ください。
SRv6 とは(ざっくり)
Segment Routingは最短経路”以外”を指定することが可能です。
経由したいサービス(End)のSegment ID(SID)のリストをEdgeルータで挿入します。
※詳しくはInternet-Draftまたは、下記スライドを参照。
構成図
今回は、ワンアーム構成ではなくツーアーム構成で試しています。
動作イメージ
SRv6の設定
共通設定 (R1,R2,R3,R4)
SRv6を起動するサーバには、全て下記を設定。環境に応じて適宜書き換え。
root@srv6:/home/uchy# vim /etc/sysctl.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.seg6_enabled = 1
net.ipv6.conf.default.seg6_enabled = 1
net.ipv6.conf.ens161.seg6_enabled = 1
net.ipv6.conf.ens224.seg6_enabled = 1
root@srv6:/home/uchy# sysctl -p
Client
sudo ip -6 route add fd:192:168:6::/64 via fd:192:168:1::2 dev ens192
R1(SRv6-1)
root@srv6-1:/home/uchy# vim /etc/iproute2/rt_tables
100 local1
101 local2
ip -6 route add fd:192:168:6::/64 encap seg6 mode encap segs fd:192:168:2::2,fd:192:168:4::2 dev ens224 table local1
ip -6 route add fd:192:168:6::/64 encap seg6 mode encap segs fd:192:168:3::2,fd:192:168:5::2 dev ens161 table local2
sudo ip -6 route add fd:192:168:2::1 encap seg6local action End.DX6 nh6 fd:192:168:1::1 dev ens256
sudo ip -6 route add fd:192:168:3::1 encap seg6local action End.DX6 nh6 fd:192:168:1::1 dev ens256
サービスチェイニング設定(AまたはBの設定を投入)
A: sudo ip -6 rule add from fd:192:168:1::1 table local1
B: sudo ip -6 rule add from fd:192:168:1::1 table local2
R2(SRv6-2)
sudo ip -6 route add fd:192:168:2::2 encap seg6local action End dev ens224
sudo ip -6 route add fd:192:168:4::1 encap seg6local action End dev ens192
R3(SRv6-3)
sudo ip -6 route add fd:192:168:3::2 encap seg6local action End dev ens224
sudo ip -6 route add fd:192:168:5::1 encap seg6local action End dev ens192
R4(SRv6-4)
root@srv6-4:/home/uchy# vim /etc/iproute2/rt_tables
100 local1
101 local2
sudo ip -6 route add fd:192:168:1::/64 encap seg6 mode encap segs fd:192:168:4::1,fd:192:168:2::1 dev ens224 table local1
sudo ip -6 route add fd:192:168:1::/64 encap seg6 mode encap segs fd:192:168:5::1,fd:192:168:3::1 dev ens224 table local2
sudo ip -6 route add fd:192:168:4::2 encap seg6local action End.DX6 nh6 fd:192:168:6::2 dev ens161
sudo ip -6 route add fd:192:168:5::2 encap seg6local action End.DX6 nh6 fd:192:168:6::2 dev ens161
サービスチェイニング設定(AまたはBの設定を投入)
A: sudo ip -6 rule add from fd:192:168:6::2 table local1
B: sudo ip -6 rule add from fd:192:168:6::2 table local2
※アドレスがfd00:xx::xxではなく、fd:xx::xxになっているのは見間違いです。。
SRv6の疎通性確認
Client -> R1 -> R2 -> R4 -> Serverの経路のキャプチャ
Client->R1間のキャプチャ
R1->R2間のキャプチャ
R2->R4間のキャプチャ
R4-Server間のキャプチャ
IPv6ヘッダのRouting HeaderにSIDのリストが格納されていることが分かります。
まとめ
JANOG43の発表を元にSRv6を動かして見ました。本ブログでは設定内容がほとんどでSRv6の動作の解説を特に行っていません。 詳しくはInternet-DraftやJanog43のDAY1の資料をご覧ください。とりあえず手を動かして動作を確認してみたいという方のお役に立てれば良いと思います。
Cisco Start 841MJでDS-Lite環境を作る(RA編)
Cisco 841MJでDS-Liteを構築しました。
既存の記事に載っているCisco製品を使ったDS-Lite環境の場合、
・DHCP-PDを使用した例が多くRA(router advertisement)環境を用いたものが少ない
・クライアント側にIPv6アドレスが設定できているものが見られなかった
という2つの理由があり、今回の構築を試みた。
コンフィグ例は以下です。
B4#show run
!
hostname B4
!
ip dhcp excluded-address 192.168.1.0 192.168.1.100
!
ip dhcp pool DHCP
network 192.168.1.0 255.255.255.0
default-router 192.168.1.254
dns-server 8.8.8.8
!
no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef
!
!
bridge irb
!
interface Tunnel10
description To:MF
ip address 192.0.0.2 255.255.255.248
tunnel source GigabitEthernet0/5
tunnel mode ipv6
tunnel destination 2404:8E00::FEED:101
bridge-group 1
!
interface GigabitEthernet0/4
description To:CLIENT
ip address 192.168.1.254 255.255.255.0
ipv6 nd other-config-flag
bridge-group 1
bridge-group 1 input-type-list 200
!
interface GigabitEthernet0/5
description To:MF_AFTR
no ip address
ipv6 address autoconfig default
ipv6 enable
ipv6 nd other-config-flag
bridge-group 1
!
ip route 0.0.0.0 0.0.0.0 Tunnel10
!
access-list 200 permit 0x86DD 0x0000
access-list 200 permit 0x0800 0x0000
bridge 1 protocol ieee
bridge 1 route ip
!
end
詰まりそうな部分の解説
①トンネルインターフェースのアドレスについて
トンネルのアドレスには、
interface Tunnel10
ip address 192.0.0.2 255.255.255.248
RFC6333で決まったものを使用していますが、
このIPアドレスは仮に1.1.1.1/32でも動作します。
トンネルのIPアドレスを設定しない場合は、デフォルトルートがルーティングテーブルに載らないため、通信ができなくなります。
②IPv6パススルーの設定をするとトンネルインターフェースがUpしない問題
interface GigabitEthernet0/5
bridge-group 1
上記のIPv6パススルーの設定を入れているとトンネルインターフェースが
Upしてくれない時があったので、一時的に設定を外してトンネルインターフェースをUｐさせた方がいいかもしれません。
具体的に以下の方法を行えば、トンネルインターフェースはUpします。
interface GigabitEthernet0/5
no bridge-group 1
interface Tunnel 10
shut
no shut
interface GigabitEthernet0/5
bridge-group 1
クライアント側のPCにIPv6のグローバルアドレスが反映されるまで1分程度かかったのでそれも注意した方が良さそう。
トンネルインターフェースがUpすると自動で以下のコンフィグが追加されていた。
ip domain list flets-east.jp
ip domain list iptvf.jp
通信フロー
・IPv6の通信は、RAを直接クライアントPCへ送るためIPv6パススルー
・IPv4の通信は、C841までは、DHCPで取得したアドレスでIPv4、その先はIPv4 over IPv6通信を行います。
確認方法について
B4ルータ(C841M)
#show ip int brief
トンネルインターフェースのDown/Up確認
#show ipv6 int brief
IPv6のグローバルアドレスを取得できているか
#show int tunnel 10
トンネルインターフェースのDown/Up & トンネルインターフェースの状態確認
クライアントPC(Windows10)
> ipcconfig
> ipconfig /release
> ipconfig /renew
以下の記事を参考にさせていただきました。
DS-Lite 接続確認機種情報 (Cisco 1812J)
http://www.mfeed.ad.jp/transix/ds-lite/contents/cisco_1812j.html
15分で出来るRaspberryPi(Linux)でDS-Lite(IPv6/IPv4)
Raspberry Piで安定してDS-Lite(IPv6/IPv4)が使えるかを試してみました。
DS-Liteについては以前ブログで紹介しました。
DS-Liteを一言でいうと既存技術を組み合わせて、IPv6とIPv4通信の共存を実現する技術です。
前提としてプロバイダがDS-Liteの接続が出来る契約をする必要があります。
IPアドレスの打ち間違えに気づかず、無駄に3時間消費してしまったが(慣れたら)簡単にDS-Liteを設定できます。
今回はファイアウォールなどの設定していないため注意が必要です。
※DS-Liteで使用するIPv6はグローバルアドレスです。
今回構築した全体図を以下に示します。
詳細：
Raspberry Pi:Raspberry Pi2
OS:Raspbian
eth1:USB NIC (Logitec LAN-GT JU3)
設定は以下のページを参考にした。
参考ページ
http://www.iij.ad.jp/company/development/tech/techweek/pdf/141128_0.pdf
Linux Hacks: HOWTO: ipv6-ipv6 tunnel and ip4-ipv6 tunnel in linux
Vyatta改めVyOSでDS-Liteを使う(IIJmio+フレッツIPoE) — どこか遠くでのんびり怠惰に暮らしたい
基本的には上の参考ページ1を見れば簡単に構築できます。
Raspberry Piの設定
①eth1の設定(/etc/network/interfacesに以下を追加)
iface eth1 inet static
address 192.168.200.1
netmask 255.255.255.0
設定が終わったら、
$ sudo /etc/init.d/networking restart
$ sudo ifdown eth1
$ sudo ifup eth1
②eth0側の設定(IPv4 over IPv6トンネリング)
ローカル(eth0)のGlobal IPアドレスを確認
$ ifconfig -a または $ip addr show
IPv6トンネルの設定
- カーネルモジュールのロード
- トンネリングの接続設定
- トンネルインターフェースの有効化
$ sudo modprobe ip6_tunnel
$ sudo ip -6 tunnel add ip6tnl1 mode ipip6 remote 2404:8e00::feed:100 local 2409:xxx::xxxx dev eth0
$ sudo ip link set dev ip6tnl1 up
この時点でデバッグなどで
$ ping6 xxxx::xxxx
を使った。（外部ホストにping6が届くはず）
③ルーティングの設定
デフォルトルートの設定
$ sudo route add default dev ip6tnl1
IPv4アドレスのフォワーディングの許可
$ sudo sysctl -w net.ipv4.ip_forward=1
MacBookの設定
アドレス：192.168.200.1
ネットマスク：255.255.255.0
デフォルトゲートウェイ：192.168.200.1
DNS：8.8.8.8
以上で設定は終わり。
DS-Liteの接続が出来ました。
MacBookで実際に色々なサイトを問題なく見れました。
$ifconfig -a を使うとトンネルインターフェースで通信していることを確認できます。
$topコマンドで調べた結果、Raspberry PiのCPU使用率は3〜8%で、メモリも1GB中200MBくらいであった。
また、MacBookProで4k動画も見たが問題なく視聴できることを確認できました。
以下サイトでRTX1200をつかう時と回線速度が変わるかを計測をした。
Speedtest.net by Ookla - The Global Broadband Speed Test
①Raspberry Pi2
UL:14Mbps、DL:58Mbps
②RTX1200
UL:21Mbps、DL:65Mbps
速度に大きな違いはなかった。
思った以上に安定して接続できています。
Raspberry Pi2の威力素晴らしい。
ネットワークカメラについて調査した
今、ニュースでは全世界にあるネットワークカメラ(IP camara)の一部が閲覧可能になり話題となっている。
なぜ、全世界のカメラは閲覧可能な状態になっているのか？
どのようにネットワークカメラを探索しているのか自分なりに調査してみた。
●前提として、ネットワークカメラはインターネットに繋ぎ、遠隔から閲覧・監視するという用途で使う人がほとんどである。
同時にインターネットに繋ぐということは、他のインターネットに繋いだ誰でもデバイスから閲覧可能の状態になることを表している。(※全部にあてはまらない)
外部に公開する必要がない場合は、クローズドなネットワークにカメラを収容し、外部からのアクセスをさせないことが大切である。
現在流出(?)しているネットワークカメラのほとんどがパスワードなしに閲覧できる状態になっている。
-このような状態を回避する一番簡単な対策はパスワードを付けることである。これを怠ると誰でもカメラを閲覧できる状態になってしまうので注意が必要である。その他、アクセス制御や認証機能を追加する方法もある。
●ネットワークカメラを閲覧・探索できる理由
カメラが特定される理由は主に2つあると考えた。
内容は極めて単純なものである。
①グローバルアドレスで80番ポートとしてカメラを公開している
これはIPアドレスを総当り攻撃することで特定が可能になる
②メーカ毎にカメラにアクセスできるURL（パス）とポート番号がだいたい決まっている
メーカのホームページではネットワークカメラで開放するポート番号を掲載しているケースが多数見受けられた。
また、製品ごとにアクセスできるURLがまとまったサイトも発見できた（以下のページ）。
これらより、以下のことが推測できる。
P社の場合
・URL1：「http ://<IPアドレス>:ポート番号/cgi-bin/camera」
・URL2：「http ://<IPアドレス>:ポート番号/SnapshotJPEG?Resolution=640x480&Quality=Clarity」
よく使用されるポート：80,81,82,6001,6002,6003,8001,8080,50000,50001,60001
S社の場合
・URL：「http ://<IPアドレス>:ポート番号/oneshotimage」
A社の場合
・URL:「http ://<IPアドレス>:ポート番号/mjpg/video.mjpg」
①IPアドレス、②ポート番号、③パスがマッチングすればカメラの探索が可能になる。
例えば存在するIPアドレスを探索した後、そのIPアドレスとURLのパスを固定にし、ポート番号だけを変化させていく。その際、URLの存在チェックを行いマッチングしたものがネットワークカメラへのアクセスURLであると分かる。
これはPHPを使っても実装が出来る。
（※悪用厳禁）
LAN上にカメラがあってもグローバルにカメラが見えているのは、UPnP(NATトラバーサル)が動作しているとからだと考えられる。
ITレポート（動向／解説） - NATトラバーサル---端末を識別可能にする「NAT越え」、実現手法は用途によりまちまち（上）：ITpro
その他分かったこと
NASでも似たような現象が起こっている
ネットワークカメラの探索モジュールは結構出回っているらしい。
そもそも何年も前からこのような問題が起きている。
おわりに
ネットワークカメラがどのように探索されているかについて調査をし報告した。カメラが誰にでも見えるようになっているのはパスワードやセキュリティ対策をせず、初期設定のまま運用しているからだと考えられる。
これらはカメラを設置する本人の知識不足に起因する問題である。
Insecamを見ると、日本で閲覧可能なカメラ台数が多いことから、セキュリティ意識が低いのか、単にカメラ台数が多いのかが不思議な感覚になった。
YAMAHA RTX1200を買って自宅でDS-Lite(IPv6/IPv4環境)の設定をした話
これらの問題を解決する一つとしてDS-Liteという技術があることを知り(※1)(※2)、中古のYAMAHA RTX1200(２万円弱:1万8000円前後)を衝動買いして自宅での運用・構築の挑戦をしてみた。
(※1)
(※2)
DS-Liteを構築してみると意外と簡単ではあったがRTX1200を使ったDS-Liteの設定の情報量が少なくところどころでつまづくことがあった。
DS-LiteとはIPv6網(アクセス網/NGN)を使ってLANでIPv6/IPv4環境を実現するトンネリング技術である。従来のインターネット接続環境では、NATの処理は主にローカルエリア（LAN）とISPの2ヶ所で行っているが、DS-LiteではISP側の1ヶ所でNATを行うのでLAN内でのNATをなくすることができる。
もっと詳しくDS-Liteを知りたい方は以下のページを参照すると良い。
http://www.janog.gr.jp/meeting/janog26/doc/post-dslite-kashimura.pdf
結論として現状から何が変わったか
- 回線速度が上がった（環境による）
- NATをLAN内で行わなくなった
- PPPoEをやめてIPoEになった
- IPv6が利用可能になった（プロバイダのオプションの変更でも実現できるらしい）
- （予定）200Mbpsの契約だけど1Gbpsで接続する(※3)(※4)
DS-Liteを構築するのに必要なこと
ISPの契約は2つ以上契約することが可能なので、前に使っていたプロバイダは後日解約することになった。
インターネット接続環境（フレッツ光使用者）はおおまかに
という構成になっている
フレッツv6オプションの契約(所要時間3分:使えるまで1時間)
NTT東日本を利用の方は、以下のページからNTT東西から届く「開通のお知らせ」という封筒に入ってある「COPまたはCAFから始まる番号」と「アクセスキー」を入力してログインしフレッツ・v6オプションの契約をする
その後、約1時間後にNTT東西から工事完了のお知らせが来る
プロバイダの契約(所要時間10分：使えるまで1時間以内)
以下のサイトからmioIDを発行してIIJ Fiberaccess/NFを契約する。
契約時にはフレッツv6オプションと同様に「COPまたはCAFから始まる番号」が必要である。
その後、1時間以内に「ready to start」という件名のメールが来て使用可能になり料金が発生する
RTX1200の設定を行う
インターネット接続の物理構成は
ルータ購入後、必要な人はファームウェアのアップデートをすすめる。
中古で購入したため設定の初期化を行う。
#cold start
YAMAHAルータへのコンソール画面接続は主に2パターンある
- Telnet接続(シリアルケーブルなし)
- シリアルケーブルで接続
以下のサイトがコンソール画面への接続方法である。
接続方法は好みの方法を選択する。
Mac Bookを使用かつシリアルケーブルを使用する方はターミナルで以下のコマンドを使用することでコンソール画面に接続できる
ls -l /dev/tty.*
cu -l /dev/tty.usbserial-〇〇
screen /dev/tty.usbserial-〇〇
RTX1200のデフォルトのIPアドレスは192.168.100.1/24です。
初期化後はパスワードは設定されていないのでログイン画面ではEnterキーを入力する。
RTX1200は前面パネルLAN1、LAN2、LAN3となっており、それぞれを独立したLANとして使用することが出来るらしい。
今回はLAN2がWAN側、LAN1をローカルのネットワーク用のセグメントとして運用することにした。
YAMAHAルータでは管理者モード・一般モードがあり、設定は管理者モードにして行う。
管理者モードへの変更は以下である。
$administrator
以下のページを参考にルータの設定を行った。
最終的なRTX1200の設定は以下である。
ip route default gateway tunnel 1
ip filter source-route on
ip filter directed-broadcast on
ipv6 prefix 1 ra-prefix@lan2::/64
ip lan1 address 192.168.100.1/24
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1 o_flag=on
ipv6 lan1 dhcp service server
ipv6 lan2 dhcp service client ir=on
tunnel select 1
tunnel encapsulation ipip
tunnel endpoint address 2404:8e00::feed:100
ip filter source-route on
ip filter directed-broadcast on
ipv6 prefix 1 ra-prefix@lan2::/64
ip lan1 address 192.168.100.1/24
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1 o_flag=on
ipv6 lan1 dhcp service server
ipv6 lan2 dhcp service client ir=on
tunnel select 1
tunnel encapsulation ipip
tunnel endpoint address 2404:8e00::feed:100
ip tunnel mtu 1500
ip tunnel secure filter in 55 1
ip tunnel secure filter out 2 dynamic 1 2 3 4
ip tunnel tcp mss limit auto
ipv6 tunnel secure filter in 3 1
ipv6 tunnel secure filter out 2
tunnel enable 1
ip filter 1 reject * * * * *
ip tunnel tcp mss limit auto
ipv6 tunnel secure filter in 3 1
ipv6 tunnel secure filter out 2
tunnel enable 1
ip filter 1 reject * * * * *
ip filter 2 pass * * * * *
ip filter 55 pass * * icmp * *
ip filter dynamic 1 * * ftp
ip filter dynamic 2 * * domain
ip filter dynamic 3 * * tcp
ip filter dynamic 4 * * udp
ipv6 filter 1 reject * * * * *
ipv6 filter 2 reject * * * * *
ip filter dynamic 3 * * tcp
ip filter dynamic 4 * * udp
ipv6 filter 1 reject * * * * *
ipv6 filter 2 reject * * * * *
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.100.2-192.168.100.191/24
役にたった、コマンド
show config
show status tunnel 1 ←IP-IPトンネルではIPv4通信のみを行う(?)
show ipv6 address
ping6 x.x.x.x
※MTUサイズが1448でなく、1500でも通信できたのがなぜなのかはまだ分かっていません。
[1]設定の手順はIPv6 IPoE
※この時点ではIPv6に対応したwebサイトしか接続できない
[http://[2a03:2880:2040:7f01:face:b00c::1]]
[2]IP-IPトンネルの設定
これでIPv4のアドレスにも対応したネットワーク接続ができる
[3]その他、フィルタリング
セキュリティを強化します
これはYAMAHAの公式サイトなどを参照して適宜行う。
tunnel endpoint address 2404:8e00::feed:100のアドレスの設定は、自分がNTTの東西どちらを使っているかでIPv6アドレスが変える必要がある。以下のサイトを参考にIPv6アドレス(gw.transix.jp)を設定すると良い。
PPPoEもやめて、NATもISPに任せることが出来ました(CGN)。
のサイトで夜間に検証したところ、
DL：40Mbps➝80Mbps
UL：10Mbps➝20Mbps
になりました。
フレッツ光のハイスピードタイプなら回線速度が200Mbps➝1Gbpsになったんだけどな。
まだYAMAHAのルータの設定になれていないので、これから設定の勉強していこう。
詳しい人に教えて欲しい。。。
