YaC2013で開催されたDaOS円卓会議の参加者は、既存のすべての推奨事項について、誰もネットワークのセキュリティに対処しようとしていないと非常に不満を述べました。 つまり、少なくともIPスプーフィングに対処するために、まず（通信事業者と）自分で始めなければなりません。
deny ip any any
from
deny ip any any
ものはさらに詳しく見ることができ、監視ログの例にすぎ
deny ip any any
。
当社のネットワークは、加入者、ピアパートナー、アップリンクを備えたプロバイダーです。
最初に、サブスクライバーへの最初のインターフェイス（1つ） int1 、および単純なアクセスアクセスリスト：
10 permit icmp any any (1483430 matches) 20 permit tcp any any established (26903 matches) 30 permit ip 10.100.x.0 0.0.0.255 any (923840 matches) 40 deny ip any any (201 matches)
許可されたICMP、すでに確立された接続、および加入者ネットワークの接続部分からのトラフィックのみ。 出会ったものを見ます。
加入者からの拒否
1.多くのパブリック送信元アドレスと1つのパブリック宛先アドレス。 アドレスはいずれも当社のものではありません。
denied tcp 81.200.20.77(64112) -> 25.189.67.187(44335) denied tcp 46.147.230.241(60676) -> 25.189.67.187(44335) denied tcp 95.154.77.187(49623) -> 25.189.67.187(44335) denied udp 95.54.131.126(10000) -> 25.189.67.187(44335) denied udp 95.221.80.35(20743) -> 25.189.67.187(44335) denied tcp 212.92.250.137(52335) -> 25.189.67.187(44335) denied tcp 93.124.112.244(62817) -> 25.189.67.187(44335)
この場合、宛先アドレスは英国国防総省に属するブロックの一部です。 これはネットワークの連帯の現れであるように思われます。世界中でDDoS対策ツールを使用する必要はありません。 しかし、実際には、トラフィックがトンネルを通過せず、一般的なルーティングスペース、つまり英国を通過すると、違法なグローバルIPアドレスでHamachiを制御できなくなります。
2.ソース-ネームサーバー、主に本物：
ネットワークにローカル
denied udp 10.10.0.2(domain) -> 169.254.32.112(31049) denied udp 10.10.1.2(domain) -> 169.254.37.66(52758) denied udp 10.10.1.2(domain) -> 10.75.144.128(36985)
グーグル
denied udp 8.8.8.8(domain) -> 172.22.81.195(7116) denied udp 8.8.8.8(domain) -> 169.254.32.112(17726) denied udp 8.8.8.8(domain) -> 169.254.32.112(21974)
メガホン
denied udp 83.149.22.14(domain) -> 172.22.81.195(32844)
ビーライン
denied udp 217.118.66.243(domain) -> 10.193.166.57(31159) denied udp 217.118.66.243(domain) -> 10.205.222.222(42160) denied udp 217.118.66.243(domain) -> 10.204.57.217(53646) denied udp 217.118.66.243(domain) -> 10.198.108.220(2125)
MTS
denied udp 217.74.244.2(domain) -> 10.108.170.22(31425) denied udp 217.74.244.2(domain) -> 10.77.119.212(43896) denied udp 217.74.244.3(domain) -> 10.86.224.44(25234)
プライベートアドレス
denied udp 192.168.1.1(domain) -> 169.254.48.228(59050)
宛先には、ネットワークに属するアドレスがありません。 ただし、サーバーは本物であるため、場合によっては、サブスクライバーのプロバイダーに現在接続されているか、以前に接続されていたアドレス指定の内部構造が明らかになる可能性があります。
3.多くのパブリック送信元アドレス（加入者ネットワークのアドレス）と加入者ネットワークの1つの宛先アドレス：
denied udp 5.76.188.102(6881) -> 10.100.178.87(49001) denied udp 178.185.77.225(14548) -> 10.100.178.87(16414) denied udp 83.149.44.138(3251) -> 10.100.178.87(64375) denied tcp 10.100.38.30(51167) -> 10.100.178.87(64375) denied udp 178.216.69.13(1375) -> 10.100.172.135(21787)
興味深いことに、このトラフィックのソースはノードであり、正確なアドレスが宛先として指定されています。
4.フォームを前のバージョンに閉じますが、宛先アドレスはネットワーク内の既知のノードのいずれにも属さないプライベートアドレスです。
denied udp 82.238.44.240(42300) -> 172.16.8.83(52987) denied udp 82.255.186.101(20344) -> 172.16.8.83(52987) denied tcp 79.31.185.28(53369) -> 172.16.8.83(52987) denied tcp 10.100.34.79(50984) -> 192.168.137.1(13472) denied tcp 10.100.236.119(54821) -> 192.168.137.1(13472) denied tcp 188.244.185.76(2503) -> 192.168.137.1(13472) denied udp 86.176.51.60(36740) -> 169.254.12.28(29970) denied udp 171.7.208.183(27161) -> 169.254.12.28(29970) denied udp 24.53.252.132(24874) -> 169.254.12.28(29970) denied udp 89.110.5.117(36505) -> 172.20.10.4(14957) denied tcp 80.255.155.125(60134) -> 172.20.10.4(14957) denied tcp 128.70.16.74(51952) -> 172.20.10.4(14957) denied tcp 178.140.142.84(64797) -> 10.0.16.19(61789) denied tcp 88.215.186.103(59343) -> 10.0.16.19(61789) denied tcp 80.77.41.98(54474) -> 10.0.16.19(61789)
ここでは、前の場合と同様に、トラフィックの送信元ノードには、インターフェイスの宛先アドレスとして指定されたアドレスの1つがあります。 これらの2つのケースは謎のままでした-誰が、どのように、そしてなぜですか？
5. 1つのプライベート送信元アドレスと多くのパブリック宛先アドレス（サブスクライバネットワークからのアドレス）：
denied udp 192.168.0.17(45927) -> 93.185.249.103(43213) denied tcp 192.168.0.17(52596) -> 82.208.126.93(58025) denied udp 192.168.0.17(45927) -> 46.72.40.240(19047) denied udp 192.168.0.5(22475) -> 188.18.233.101(42763) denied tcp 192.168.0.5(57165) -> 109.61.147.132(46895) denied udp 192.168.1.3(28199) -> 136.169.166.182(42584) denied udp 192.168.1.3(28199) -> 94.41.133.198(46843) denied udp 192.168.0.101(43137) -> 10.100.44.151(49393) denied udp 192.168.0.101(43137) -> 10.100.26.39(20080) denied udp 192.168.0.101(43137) -> 10.100.72.63(35692)
おそらく最も説明可能です。 アドレスは一定であるため、メインインターフェース、または加入者のネットワーク内の別のデバイスで2番目に設定されるか、アプリケーションの1つで使用されます。
多くの場所で見られる上記のオプションは最も普及しており、残りは孤立したケースにすぎません。
6.ソース-プロバイダーのネットワークのパブリックアドレス：
denied udp 203.0.113.18(26585) -> 213.67.20.238(6112)
7.目的-プロバイダーのネットワークのパブリックアドレス：
denied udp 62.148.7.195(17278) -> 203.0.113.65(40178) denied udp 62.148.7.195(19176) -> 203.0.113.65(40180) denied udp 62.148.7.195(16186) -> 203.0.113.65(40182) denied udp 62.148.7.195(19970) -> 203.0.113.65(40184)
これらのケースは説明する価値があります。すべての加入者がNATの背後にあり、プライベートアドレスを持っているため、ネットワーク上のプロバイダーのパブリックアドレスの外観は、宛先アドレスのようにまったく普通ではありません。
8.このコンテキスト、アドレス、プロトコルでも「奇妙な」：
denied 154 73.246.67.151() -> 128.106.162.245() denied all 175.223.240.56() -> 64.0.0.0() denied tcp 64.8.0.1(61445) -> 0.0.0.1(128)
私たちが調査して説明したもののほとんどは、故意または悪意のあるアクションには適用されません。多くの場合、これらは、2番目のプロバイダー（通常3Gモデム）をさまざまなトンネルプログラム（Hamachi、最初のケース）またはP2Pクライアント。
ピアパートナーごとに拒否
次に、ピアリングパートナーint2からのトラフィックを見てみましょう。BGPインターフェイスと既知のパブリックアドレスのみです。 アクセスリストはもう少し複雑で、前のものに加えて、プライベートネットワーク用の個別のルールが作成されました。
10 permit icmp any any (1360250 matches) 20 permit tcp any any established (199798954 matches) 30 permit bgp host 192.0.2.1 host 192.0.2.2 (11887 matches) 40 permit ip 192.0.2.0 0.0.0.255 203.0.113.0 0.0.0.255 (775443105 matches) 50 deny ip 10.0.0.0 0.255.255.255 any (1280 matches) 60 deny ip 172.16.0.0 0.15.255.255 any (2 matches) 70 deny ip 192.168.0.0 0.0.255.255 any (1335 matches) 80 deny ip 169.254.0.0 0.0.255.255 any 90 deny ip 127.0.0.0 0.255.255.255 any 100 deny ip host 0.0.0.0 any 110 deny ip host 255.255.255.255 any 120 deny ip any any (540 matches)
前のACLに関連
deny
および
permit
ルールの一致数の比率に注意する価値があります。 理解できないものは少なく、200,000許可につき約1拒否です。前の例では、これは1対5000の比率です。これは、パートナーに存在し、サブスクライバーには存在しない制御されたネットワーク構造の存在を示しています。 しかし、この場合も、何かが漏れています。
1.規則50.60.70-私たちにもピアリングパートナーにも属さないプライベートアドレスからパブリックアドレスへのアクセス：
denied udp 192.168.0.101(6881) -> 203.0.113.251(6881) denied udp 192.168.0.249(47597) -> 203.0.113.147(23392) denied udp 10.112.112.112(63973) -> 203.0.113.249(42873) denied tcp 192.168.0.57(57055) -> 203.0.113.38(37654)
多くのイベントはありませんが、このケースには前のセクションのオプション5と共通点があると仮定できます。
2.しかし、ip any anyが突然予期されるイベントを示したのを拒否します-ピアリングパートナーに属していないパブリックアドレスからインターフェイスアドレス192.0.2.2にアクセスしようとします。
denied udp 5.255.68.168(7678) -> 192.0.2.2(123) denied udp 84.105.139.67(42440) -> 192.0.2.2(161)
このアドレスはグローバルにルーティング可能であり、ネットワークセキュリティの強度をテストしたい人が不足することはありませんでした。 公平には、内部ネットワークで同様のケースが発生しますが、別の保護メカニズムによって遮断されることに注意する必要があります。したがって、上記の例ではこれは目立ちません。
インターネットからの拒否
インターネットのint3に何が期待できるかはまだわかりません 。 アクセスリストは以前と同じですが、既知のアドレスからだけでなく、すべてのアドレスからアクセスできるようになりました。
10 permit icmp any any (142814260 matches) 20 permit tcp any any established (29633491483 matches) 30 permit bgp host 198.51.100.1 host 198.51.100.2 (1727903 matches) 40 permit ip any 203.0.113.0 0.0.0.255 (23122741548 matches) 50 deny ip 10.0.0.0 0.255.255.255 any (447026 matches) 60 deny ip 172.16.0.0 0.15.255.255 any (121911 matches) 70 deny ip 192.168.0.0 0.0.255.255 any (191732 matches) 80 deny ip 169.254.0.0 0.0.255.255 any (1733 matches) 90 deny ip 127.0.0.0 0.255.255.255 any (3415 matches) 100 deny ip host 0.0.0.0 any (46 matches) 110 deny ip host 255.255.255.255 any (9 matches) 120 deny ip any any (1278 matches)
すぐに注目に値するのは、0.0.0.0や255.255.255.255など、さまざまなソースアドレスです。 それ以外の場合は、ピアリングパートナーとほぼ同じです。
1.パブリックルーティングスペースからプロバイダーのパブリックアドレスへのプライベートアドレス：
denied udp 192.168.0.106(61104) -> 203.0.113.84(18636) denied tcp 10.0.3.49(54996) -> 203.0.113.243(21603) denied udp 10.240.77.25(38170) -> 203.0.113.106(25175) denied tcp 172.20.56.135(49995) -> 203.0.113.210(60623) denied tcp 10.60.33.69(49388) -> 203.0.113.206(54312)
2.最初のケースと同じですが、ソースとしてネットワークからのパブリックアドレス：
denied udp 203.0.113.18(56425) -> 203.0.113.21(6502)
3.ピアリングパートナーの場合と同じ、ルーターのドッキングアドレスへのアクセス：
denied udp 116.10.191.170(6000) -> 198.51.100.2(22) denied udp 5.152.192.210(5135) -> 198.51.100.2(5060)
今回は、SSHおよびSIPポート。
それがおそらくすべてです。 外部接続との基本的な違いは、アドレス以外へのアクセスの試行がないことです。 すべてのパケットは必要な場所に届きましたが、常にこの状況で適切なアドレスからではありませんでした。 また、相対的な観点では、外部ネットワークからのナンセンスフライは、自社のサブスクライバからのものよりはるかに少ないです。 つまり、ネットワーク上の管理者の存在は、ほとんどすべての問題を解決します。
もちろん、ネットワークセキュリティの専門家ではないので、私はこの行またはその行が禁止されていることを常に理解しているわけではありませんが、上で述べたように、ほとんどが構成エラーであるという悪意のあるものは何もなかったようです いずれにせよ、警戒し、外部の脅威から、そして主に内部の脅威から身を守ってください。