一般公開の再帰DNSサーバー-iptablesルール
Linuxマシンでは、公開の再帰DNSサーバーを実行します。 DNS増幅攻撃に使用されてきました。これらの攻撃を緩和するのに役立つ推奨されるiptablesルールはありますか？
明白な解決策は、発信DNSパケットを特定のトラフィックレベルに制限することです。しかし、攻撃が被害者のIPアドレスへのトラフィックをブロックするように、もう少し賢いものを見つけたいと思っていました。
私はアドバイスと提案を探しましたが、それらはすべて「公開されている再帰的なネームサーバーを実行しない」ようです。残念ながら、変更するのが容易でないものは、そうしないと壊れるという状況に戻っています。これは、これらの攻撃が問題になる前に10年以上前に行われた決定によるものです。
本当にあなたのせいではなく、「難しい」か「難しい」かに関係なく、適切なアクションをとることによって100％解決する必要がある/できる「私の問題ではない」シナリオのすべての種類の悪臭、そしてそれは- 開いている再帰サーバーを終了しています。
段階的に廃止：このサーバーはX日で廃止されることをお客様に伝えます。その後、DNSサーバーを使用しないようにパッチをインストールする必要があります（パッチがある場合）。これは常に行われます。システム管理者、ネットワーク管理者、ヘルプデスク担当者、プログラマー？我々getそれ;ベンダー/サービスプロバイダー/パートナーがX日付以降に何かの使用を停止するように指示するための標準の操作手順のため、この寿命末期の事態は常に発生します。私たちはいつもそれが好きというわけではありませんが、それはITにおける日常の事実です。
現在のデバイスではこの問題は発生していないとのことなので、ファームウェアのアップデートまたはパッチでこの問題を解決したと思います。 あなたがデバイスに触れることができないと言っていたのを知っていますが、確かに彼らは触れることができますか？つまり、これらのボックスが基本的にあなたに電話をかけることを許可しているのであれば、デバイスに誰が何をしているのかについて、実際にはそれはありません ;あなたは彼らが知っているすべてのリバースプロキシ設定を持つことができるので、なぜこれを修正するパッチをインストールさせないか、または彼ら自身のDNSサーバーを使用するように彼らに伝えてください。確かにデバイスはDHCPをサポートしています。私はでないネットワークデバイス（古い/ frail/oddは関係ありません）を考えることができません。
それができない場合、次に行うことは制御です誰が再帰サーバーにアクセスできるか：誰がどのように、どのように使用しているのかを「見分けるのは難しい」と言いますが、今がその時です確かに、正当ではないトラフィックをドロップし始めます。
これらは「準軍事/政府」組織ですよね？まあ、それらはおそらく彼らが所有する正当なネットブロックの一部です。これらのデバイスは、動的IPの背後にあるホームルーターではありません。探し出す。それらに連絡し、問題と方法を説明してくださいファームウェアまたは製品の交換を強制しないことで、それらに多くのお金を節約しますデバイスがあなたのアクセスに使用するネットブロック/ IPアドレスを確認できる場合のみDNSサーバー。
これは常に行われています。私は、エクストラネットアクセスまたはHL7リスナーをこの方法でヘルスケアパートナーに制限している顧客が何人かいます。それはそれほど難しいことではありませんフォームに記入して、トラフィックを期待する必要があるIPおよび/またはネットブロックを提供することです。エクストラネットへのアクセスが必要な場合は、IPまたはサブネット。そして、これはめったに移動するターゲットではないため、毎日数百のIP変更要求が殺到するわけではありません。数百のサブネットと数千および数千のホストIPを備えた独自のネットブロックを所有する大規模な病院のネットワークは、日常的に私に与えます私が期待している少数のIPアドレスまたはサブネット。繰り返しますが、これらは常にキャンパス内を歩き回っているラップトップユーザーではありません。そのため、絶えず変化するIPアドレスからのUDPソースパケットが表示されるのはなぜですか。明らかに、私はここで仮定をしているのですが、100未満のデバイスに対しては、あなたが思うほどではありません。はい、それは長いACLになるでしょう、そして、はい、それはいくつかのメンテナンスと通信（ガスプ！）を必要としますが、それを完全にシャットダウンする以外に次善の策です。
何らかの理由で通信チャネルが開いていない場合（または、誰かがあまりにも恐れているか、これらのレガシーデバイスの所有者に連絡して適切にこれを行うことができない場合）、通常の使用/アクティビティのベースラインを確立して、計算できるようにする必要があります。 DNS増幅攻撃への参加を助ける（ただし防止はしない）いくつかの他の戦略。
長時間実行するtcpdumpは、着信UDP 53でのフィルタリングとDNSサーバーアプリケーションでの詳細なロギングを機能させる必要があります。また、あなたが言っているように、adding新しいデバイスがあれば、既存のインストールにレガシーサービスを提供するだけです。
これはまた、理解するのに役立ちます要求されているレコードタイプ、およびどのドメイン、誰が、どのくらいの頻度で：DNS増幅が意図したとおりに機能するためには、攻撃者は- 大きなレコードタイプ（1）を機能するドメイン（2）に。
「大きなレコードタイプ」：再帰DNSサーバーで解決できるようにするには、デバイスにTXTまたはSOAレコードが必要ですか？ DNSサーバーで有効なレコードの種類を指定します。BINDとおそらくWindows DNSで可能だと思いますが、掘り下げる必要があります。DNSサーバーが
SERVFAILで応答する場合TXTまたはSOA records、and leastthat）応答は1桁（または2桁）意図されたペイロードよりも小さいです。明らかに、スプーフィングされた被害者がサーバーからSERVFAIL応答を受信するため、まだ「問題の一部」ですが、少なくともそれらをハンマーで処理しておらず、おそらくDNSサーバーは、ボットが「協調」しないためにボットが使用する収集リストから「リストから除外」されます。「機能するドメイン」：有効なドメインのみをホワイトリストに登録できる場合があります。これは、サーバーが機能するためにWindows Update、Symantecなどが必要なだけの強化されたデータセンター設定でこれを行います。ただし、この時点で引き起こしている被害を軽減しているだけです。サーバーは引き続き偽造に応答するため、サーバーからの
NXDOMAINまたはSERVFAIL応答で被害者は攻撃されます。ソースIP。この場合も、ボットスクリプトは結果に基づいてオープンサーバーリストを自動的に更新する可能性があるため、サーバーが削除される可能性があります。
他の人が示唆しているように、アプリケーションレベル（メッセージサイズ、クライアントごとのリクエスト数など）またはファイアウォールレベル（他の回答を参照）のいずれかで、何らかの形式のレート制限も使用しますが、ここでも、正当なトラフィックを殺していないことを確認するためにいくつかの分析を行う必要があります。
調整またはトレーニングされた侵入検出システム（ここでもベースラインが必要です）は、時間の経過とともにソースまたはボリュームごとに異常なトラフィックを検出できるはずですが、誤検知を防ぐために定期的にベビーシッター/チューニング/モニタリングを行う必要があります。 /または実際に攻撃を防止しているかどうかを確認します。
結局のところ、このすべての努力がそれだけの価値があるのか、それとも正しいことが行われ、それによってそもそも問題が解消されると主張するだけなのか、疑問に思う必要があります。
これは、実行するレート制限の種類によって異なります。
iptablesによるレート制限は、実際には着信パケットを制限するためのものです。制限に達するまでのパケットはフィルターに一致し、指定されたターゲットが適用されるためです（例：ACCEPT）。おそらく、フィルタに一致しないDROPパケットへの後続のターゲットがあるでしょう。また、iptablesにはQUEUEターゲットがありますが、独自のキューイングアプリケーションを提供する必要があるユーザースペースにパケットを渡すだけです。発信パケットをレート制限することもできますが、実際には発信トラフィックのドロップを開始したい人はほとんどいません。
iptablesレート制限の低下：
iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP
hashlimitではなくlimitを使用すると、宛先IPごとにレート制限が適用されます。つまり、8.8.8.8への5つのパケットが制限に達すると、パケットは8.8.4.4に送信されなくなりますが、hashlimitを使用すると、8.8.8.8が最大の場合でも、8.8.4.4に到達できます。 。
制限を超えたパケットを破棄したくない場合は、tcが本当に必要です。 tcは、大量のバースト性トラフィックではなく、ニースの安定したストリームを取得するようにフローを規制します。着信側では、パケットはアプリケーションへの配信が遅くなりますが、すべて順番に到着します。発信パケットでは、アプリケーションを可能な限り高速で離れますが、一貫したストリームでネットワークに配置されます。
私はtcをあまり使用していませんが、これが レート制限ICMP の例です。これは、おそらくDNSに簡単に適応できます。
スプーフィングされたクエリへの応答を潜在的に軽減するためにできることの1つを次に示しますが、いくつかの作業が必要です。
まず、セキュリティチャネルのログを見て、なりすましのIPアドレスを見つけます。
次に、次のようにそのソースIP（10.11.12.13）を使用してtcpdumpを実行します。
tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S
あなたはこのようなものを得るでしょう：
18：37：25.969485 IP（tos 0x0、ttl 52、id 46403、offset 0、flags [none]、proto：UDP（17）、length：45）10.11.12.13.51169> 01.02.03.04。ドメイン：4215+ ANY？ 。 （17） 0x0000：4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-。C..4 ....... 0x0010：0102 0304 c7e1 0035 0019 0e89 1077 0100。 ...... 5 ..... w .. 0x0020：0001 0000 0000 0000 0000 ff00 0100 ..............
楽しい部分です！ http://tools.ietf.org/html/rfc1035 でrfc1035を開き、セクション4.1.1に進みます。
それでは、tcpdumpの結果を変換し、パケットレベルのフィルターを作成するために使用できるパターンを理解します。
ヘッダーのIDは0x1Cで始まるため、0x1Eにいくつかのフラグ、0x20にQDCOUNT、0x22にANCOUNT、0x24にNSCOUNT、0x26にARCOUNTがあります。
これにより、実際の質問は0x28に残ります。この場合、NAMEはnull（ROOT）、QTYPE = ANYは0xFF、QCLASS = INは0x01です。
長い話を簡単に言うと、次のiptablesルールを追加すると、ROOT IN ANYレコードを要求しているスプーフィングされたクエリの95％以上がブロックされることがわかりました。
iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP
あなたの走行距離は異なる場合があります...これが役立つことを願っています。
送信ポート53 UDPのLinuxでtcおよびキューイング規則を使用する：
IFACE=eth0
tc qdisc add dev ${IFACE} root handle 1: htb default 0
tc class add dev ${IFACE} parent 1: classid 1:1 htb rate 10mbit burst 20m
tc qdisc add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1
ファイアウォールマークが「1」のパケットの場合、discを10メガビットに制限して設定します。ファイアウォールマーキングはファイアウォールの内部にのみあり、パケットを変更しません。キューイング規則によるパケットの処理のみ。 iptablesを使用してファイアウォールのマーキングを行う方法は次のとおりです。
iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1
必要に応じて、信頼できるサブネットや宛先を除外するように変更します。 -o eth0シェーピングを送信パケットのみに制限します。お役に立てれば。
これらのデバイスはまだサポート契約中ですか？その場合は、お客様に連絡してください。インターネットは過去10年間に少し進化したことを知らせてください。これらのデバイスに名前解決を提供し続けるためには、クエリを期待するSRC IPを知る必要があります。不明なクライアントにサービスを提供できなくなる最大6か月後の日付を設定し、それを維持します。これは業界ではかなり一般的です。これらのデバイスがサポート契約の対象ではなくなった場合...ビジネス上の判断のように聞こえます。あなたの会社は、もはや収益を上げなくなった古代の製品にリソースを費やすつもりですか？
これらは特殊なデバイスのように聞こえますが、正当なクエリを期待するドメインを合理的に予測できるほど特殊なデバイスですか？ bindはビューをサポートし、それらのドメインに対してのみ再帰を行うパブリックビューを作成します。
これを学習の機会として使用します。まだ行っていない場合は、バグを修正する機能のない製品のリリースを停止してください。これがバグです。確かに、遅かれ早かれこのデバイスを早期にEOLするもの。
Nanogのどこかから、これ：
iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP
これは理想的ではありません。 1秒あたりのパケット数を減らし、バーストを高くする方がよい場合があります。
私は、外部に直面する再帰リゾルバに依存するすべてのクライアントのリストを作成しようと思います。 DNSボックスで1日程度のパケットトレースを開始します。そこから、認識して承認するトラフィックを許可するiptablesルールの作成を開始します。デフォルトでは、最終的にはトラフィックを53/tcpおよび53/udpにドロップします。それが何かを壊すならば、あなたのルールを微調整してください。