Public Facing Recursive DNS Servers-iptables rules

Linuxマシン上で公開の再帰DNSサーバーを実行します。DNS増幅攻撃に使用されています。iptablesこれらの攻撃を軽減するのに役立つ推奨ルールはありますか？

明らかな解決策は、アウトバウンドDNSパケットを特定のトラフィックレベルに制限することです。しかし、攻撃が被害者のIPアドレスへのトラフィックをブロックするように、もう少し巧妙なものを見つけたいと思っていました。

私はアドバイスや提案を探しましたが、それらはすべて「公開された再帰的なネームサーバーを実行しないでください」と思われます。残念ながら、そうしないと簡単に変更できないものが壊れるという状況に陥っています。これは、これらの攻撃が問題になる前に10年以上前に下された決定によるものです。

「私の問題ではない」シナリオのすべての種類のリークは、実際にはあなたのせいではなく、それがどのように「困難」または「難しい」かに関係なく、適切なアクションをとることによって100％解決されるべきであり、それがあなたを終わらせている再帰サーバーを開きます。

段階的に廃止：このサーバーはX日付で廃止されることをお客様に伝えます。それ以降は、DNSサーバーを使用しないようにパッチをインストールする必要があります（パッチがある場合）。これは常に行われます。システム管理者、ネットワーク管理者、ヘルプデスク担当者、プログラマー？我々は取得して、ベンダー/サービスプロバイダー/パートナーがXの日付以降に何かの使用を停止するように指示する標準操作手順のため、この寿命の終わりは常に起こります。私たちは常にそれを好むわけではありませんが、ITの人生の事実です。

現在のデバイスではこの問題はないと言っているので、ファームウェアの更新またはパッチでこの問題を解決したと思います。デバイスに触れることはできないと言っていましたが、確かにできますか？私は、彼らはあなたに、基本的に携帯電話の家にこれらのボックスを許可している場合、彼らは本当にすることはできません、意味そのやっているかについて、肛門何そのデバイスへ。知っているすべての人のためにリバースプロキシをセットアップすることができます。そのため、これを修正するパッチをインストールしたり、独自のDNSサーバーを使用するように指示したりしないでください。デバイスがDHCPをサポートしていることは確かです。ネットワークデバイス（古い/壊れた/奇数であるかどうかは関係ありません）は考えられません。

それができない場合、次に行うことは、再帰サーバーにアクセスできるユーザーを制御することです。誰がどのようにそれを使用しているかは「わかりにくい」と言いますが、特定のトラフィックを見つけてトラフィックをドロップし始めます合法ではありません。

これらは「準軍事/政府」組織ですよね？まあ、彼らはおそらく彼らが所有する正当なネットブロックの一部です。これらのデバイスは、動的IPの背後にあるホームルーターではありません。探し出す。デバイスがDNSサーバーへのアクセスに使用するnetblock / IPアドレスを確認できる場合にのみ、ファームウェアまたは製品の交換を強制しないことで、問題とそのコストを節約する方法を説明します。

これは常に行われます。エクストラネットアクセスまたはHL7リスナーをこのようにヘルスケアパートナーに制限する顧客がいくつかいます。それはだことは難しいことではありませんフォームに記入してIPおよび/またはネットブロックを提供するために、トラフィックを期待する必要があります。エクストラネットへのアクセスが必要な場合は、IPまたはサブネットを提供する必要があります。そして、これはめったに移動するターゲットではないので、毎日何百ものIP変更要求が殺到するわけではありません。予想される少数のIPアドレスまたはサブネット。繰り返しますが、これらは常にラップトップユーザーがキャンパスのあちこちを歩き回っているわけではないので、なぜ絶えず変化するIPアドレスからのUDPソースパケットを見ることになるのでしょうか。明らかに私はここで想定しているのですが、100台未満のデバイスについてはあなたが考えるほど多くはないと思います。はい、それは長いACLです、そしてはい、

何らかの理由で通信チャネルが開いていない場合（または誰かがこれらのレガシーデバイスの所有者に連絡することを恐れて適切に行うことができない場合）、通常の使用法/活動のベースラインを確立して、策定する必要がありますDNS増幅攻撃への参加を支援する（ただし、防止はしない）他の戦略。

長時間実行tcpdumpすると、着信UDP 53でフィルタリングが機能し、DNSサーバーアプリケーションで詳細なログが記録されます。あなたが言うように、新しいデバイスを追加するのではなく、単にレガシーを提供しているので、ソースIPアドレス/ネットブロック/ geoIP情報の収集を開始したいと思います（あなたのすべてのクライアントは米国にいますか？既存のインストールへのサービス。

これはまた、あなたが理解するのに役立ちます、そしてどのようなドメインのために、誰と、どのくらいの頻度で、レコードタイプが要求されているものを意図した通りの仕事にDNS増幅のために、攻撃者が要求できるようにする必要があります：大型レコードタイプを Aに（1）機能ドメイン（2）。

1. 「大規模なレコードタイプ」：再帰DNSサーバーで解決できるようにするには、デバイスにTXTまたはSOAレコードも必要ですか？DNSサーバーで有効なレコードタイプを指定できる場合があります。BINDとおそらくWindows DNSで可能だと思いますが、掘り下げる必要があります。DNSサーバーがSERVFAILTXTまたはSOAレコードに応答し、その応答が意図したペイロードよりも1桁（または2）小さい場合。明らかに、あなたはまだ「問題の一部」です。なぜなら、スプーフィングされた被害者はまだSERVFAILあなたのサーバーからそれらの応答を受け取っているからです。ボットは「協力しない」ために時間をかけて使用します。

2. 「機能しているドメイン」：有効なドメインのみをホワイトリストに登録できる場合があります。これは、サーバーが機能するためにWindows Update、Symantecなどのみを必要とする、強化されたデータセンターのセットアップで行います。ただし、この時点であなたが引き起こしている損害を軽減しているだけです。サーバーは偽造されたソースIPに応答するため、被害者はサーバーから攻撃を受けNXDOMAINたりSERVFAIL応答したりします。繰り返しますが、ボットスクリプトは結果に基づいてオープンサーバーリストを自動的に更新することもあるため、サーバーが削除される可能性があります。

また、アプリケーションレベル（つまり、メッセージサイズ、クライアントごとの要求の制限）またはファイアウォールレベル（他の回答を参照）で、他の人が示唆しているように、何らかの形式のレート制限を使用しますが、もう一度、正当なトラフィックを殺さないように分析する必要があります。

調整および/または訓練された（ここでもベースラインが必要です）侵入検知システムは、ソースまたはボリュームごとに時間の経過とともに異常なトラフィックを検出できる必要がありますが、誤検知を防ぐために定期的にベビーシッター/チューニング/監視を行う可能性があります/または実際に攻撃を防止しているかどうかを確認します。

結局のところ、あなたはこのすべての努力がそれだけの価値があるのか​​、それとも正しいことを行うことを主張するべきなのか、そもそも問題を解消しているのかと疑問に思う必要があります。

それはあなたがしたいレート制限の種類に依存します。

レート制限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つのパケットが制限に達するとhashlimit、8.8.4.4 へのパケットの送信が妨げられますが、8.8.8.8を最大にすると、8.8.4.4に到達できます。

あなたが制限を超えたパケットを落としたくないなら、あなたが本当に欲しいのはtcです。tc大量のトラフィックを集中させるのではなく、安定したストリームを得るためにフローを調整します。着信側では、パケットはアプリケーションへの配信が遅くなりますが、すべて順番に到着します。発信パケットでは、アプリケーションは可能な限り高速になりますが、一貫したストリームでワイヤ上に配置されます。

tcあまり使用していませんが、DNSに簡単に適応できるICMPのレート制限の例を次に示します。

スプーフィングされたクエリへの応答を潜在的に緩和するためにできることの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.domain：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の場合はヌル（ROOT）、QTYPE = ANYの場合は0xFF、QCLASS = INの場合は0x01です。

長い話を簡潔にするために、次のiptablesルールを追加すると、ルート内のレコードを要求しているスプーフィングされたクエリの95％以上がブロックされることがわかりました。

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP

あなたの走行距離は異なる場合があります...これが役立つことを願っています。

tcアウトバウンドポート53 UDPのLinuxでの分野の使用とキューイング：

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

discファイアウォールマークが「1」のパケットには、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により、シェーピングが発信パケットのみに制限されます。お役に立てれば。

私は、あなたの外部に面した再帰的リゾルバーに依存するすべてのクライアントのリストを作成しようとします。DNSボックスでの1日程度のパケットトレースから始めます。そこから、iptablesルールの作成を開始して、認識および許可するトラフィックを許可します。デフォルトでは、最終的に53 / tcpおよび53 / udpへのトラフィックがドロップされます。それが何かを破るなら、ルールを微調整してください。

あなたがいるネットワークの「位置」に応じて[複数のbgpフィードを持っているか、インターネットの「端」にある-スタブネットワークとして）ソースアドレスのなりすましを防ぐためにuRPFのようなものを試すことができます。

他の情報源。

これらのデバイスはまだサポート契約中ですか？もしそうなら、あなたの顧客に手を差し伸べる。インターネットは過去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秒あたりのパケット数を少なくして、バーストを大きくする方が良い場合があります。

以下は、DDOS攻撃に対して数回使用したソリューションです。完璧ではありませんが、私を助けてくれました。解決策は、cronによってN分（1、2、3など）ごとに呼び出され、スクリプト内の指定された接続よりも多くの接続を作成しているIPをブロックするスクリプトで構成されます。

#!/bin/sh

PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"

netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp