DNSのセキュリティ

## 概要
支援士によく出るんでまとめてみます。結構深くまでつっこむつもりです。
説明わかりにくければごめんなさい
## DNSとは
![POP (8).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3890669/a38f4f0c-ae4d-c5f4-6708-0ecd46d60476.png)
図の通りなのですが、例えば、ドメインを解決しようとしたときに、フルサービスリゾルバに情報があれば、そのまま返すし、フルサービスリゾルバが分からなければ、権威DNSサーバーわかるまで聞き続けるし、っていう仕組み。
めっちゃざっとしてますがこういうものです。ここは他にもっと詳しいサイトがあると思うのでそっち見てください。
ちなみに通信はUDPです。

## DNSキャッシュポイズニング
![POP (9).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3890669/cd4b7a29-fe61-a67d-f8be-105db1e7d0ec.png)
図の通りの攻撃です。
有名だし特に説明は不要かなと思います。
これの亜種があるのでいくつか紹介します。

### カミンスキー型攻撃
DNSの通信は、DNSの問い合わせのDNSクエリとその応答のDNSリプライによって成り立っています。![POP (12).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3890669/60411c46-0937-852c-fa9b-494994ff52b2.png)
DNSクエリを送信するときは、ランダムなIDを持たせます。そして、そのランダムなIDをリプライの時に一緒に送信させれば、正規の応答なんだなとわかります。
ランダムなIDを渡して、別のIDが返ってくれば、それは何か怪しいとなるってことです。
このIDは16ビットのデータ量で、種類でいうと6万5536種類存在します。
これ、裏を返せば、1/6万5536の確率で適当なIDを返しても当たるという計算です。
これを実行したのがカミンスキー攻撃です。
![POP (10).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3890669/2d59ddc2-58b7-cbbb-eb0d-c4f144ef158b.png)
正規の応答より早く、適当なIDを付けた送信を大量に送れば、一つくらい当たるだろうというなんか脳筋なような攻撃です。
これの対策として、待ち構えるポートをランダムにしました。
IDが当たってもポートまで当てなくちゃいけないから、そう簡単に当たらないでしょという算段です。
しかしこれも突破方法は存在して、UDPの通信の特性上、ポートやIDの情報と、データの部分は別のパケットで送信されます。まぁ、送る担当が違うんだなと思えばいいです。
送る担当が違うんで、ポートやIDの情報を担当するのはそのままにして、データ部分を担当する部分を改ざんして、正規の通信に見せかけた改ざんされた通信を行うことができます。

### SADDNS
先ほど、ポートをランダム化させるという話がありました。
このポートのランダム化、に対応したのがSADDNSという手法です。
なんか高度な話なので自分自身詳しく説明できないのですが、ざっくり説明します。
ICMPっていうIP通信のエラーメッセージを送信するプロトコルがあります。こいつ、エラーが出ると送られるんですが、永遠にエラーメッセージを送られても困るので、** ICMP Rate Limit**っていう、エラーメッセージを送信する量を制限する機能があります。
これを使ってポートが開いているかを判断するんです。
まず、ポートが開いていれば、何もないのでエラーメッセージはかえってきません。逆にポートが閉じていればエラーメッセージはかえってきます。ただし、エラーメッセージを返し続けると途中からICMP Rate Limitが機能してエラーメッセージが返ってこなくなります。最終的に空いていても閉じていてもエラーメッセージは返ってこなくなるのですが、この返ってこなくなり方に違いがあるのでそれを見破ってポートを特定するという高度な方法です。
対策としては、DNSSECの導入することです。簡単なのはICMPの機能を排除しまうことだけど、そうすると使い勝手が悪くなるから何とも言えないです。

## DNSリフレクション攻撃
![POP (11).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3890669/6c9c0810-571d-fda6-1b6a-12b5e37bc533.png)
これは画像の通りです。
オープンリゾルバっていうアクセス元を制限しないDNSサーバーがあるんですが、それに対して送信元を偽って大量にDNSクエリを送信することで、大量のDNSリプライを特定のサーバーに送りつけるという方法です。

## ゾーン転送攻撃
DNSでは、プライマリサーバーとセカンダリサーバーに役割を分けることで、システムの冗長性と信頼性を高めることができます。プライマリサーバーは、人が手入力なんですが、セカンダリサーバーはプライマリサーバーから情報を共有してもらいます。それがゾーン転送です。そこでそのゾーン転送を攻撃者に転送させるのがゾーン転送攻撃です。これを防ぐのがTSIGです。
プライマリサーバーとセカンダリサーバー両方に秘密鍵を配置し、秘密鍵で署名して、セカンダリサーバーに送信し、それをセカンダリサーバーの秘密鍵で検証する方法です

## DNSトンネリング攻撃
DNSの通信と偽造して、不正な通信を行うこと。
ごめんなさい。調べてもここよくわかんないです。
わかり次第追記します。

## NDS
悪意ある新規ドメインのことです。新規ドメイン（できて約1か月の間）は、検索エンジンやDNSフィルタリングで十分にチェックされなく、悪用されやすいんです。
新規ドメインを一時的に取得し、悪事を行ってすぐ捨てるみたいなことをしてきます。

## DGA
ドメイン生成アルゴリズムといいます。内容は名前の通りです。
例えば、C＆Cサーバー（悪いサーバー。C2サーバともいう）と通信するときに、毎回同じドメインを使っていると、悪いやつと通信してるんだと判断され通信が遮断されます。しかし、DGAを使ってドメインを変え続けることで、それが悪いドメインなのか害のないドメインなのか識別が難しくなります。そうやってC&Cサーバーは通信を遮断されないようにします。

## DNSのセキュリティといえば？
DNSの攻撃についてひたすら見てきましたが、セキュリティ的には何ができるのでしょうか？

### DNSSEC
DNSセキュリティと検索すると真っ先に出てくるのが、DNSSECです。
ここは丁寧に説明していこうと思います。
![POP (13).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3890669/674046d2-6381-55cc-1902-b1aa1dbfdffe.png)
今の表現力ではこれが限界なのですが、見ていきましょう

１，DNSクエリを受け取ります。ここまでは難しくないですね

２，権威DNSサーバーは、クエリに対するリソースレコード、（例えばあるドメインを聞かれたらそれに対応するIPアドレス）を返信します。それは、当たり前ですよね。そして、それをハッシュ化してそれをZSK（ゾーン署名鍵、これは秘密鍵です）で署名したRRSIGレコードの値も一緒に返します。

３，RRSIGレコードをDNSKEY（ZSKの公開鍵）で復号してみます。そうすると、リソースレコードをハッシュ化した値が出てきます。また、権威DNSサーバーから送られてきたリソースレコードを権威DNSサーバーがハッシュ化した方法と同じ方法でハッシュ化してみます。この時、ハッシュ化した値が二つ出ていますが、これが一致してれば、検証成功です。違いがあれば、どこかしらで誰かしらが悪さをしていると考えられます。


この時、DNSKEY（ZSKの公開鍵）が権威DNSサーバーのものであるという前提条件があります。
その前提条件を保証しているのが、**信頼の連鎖**です。

![POP (14).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3890669/28b3acd0-116a-dc7b-5bb9-a0792a8f7ee3.png)
さぁここが最難関です。
ついてきてください。KSKってのは、鍵暗号方式に使う鍵の名前です。
まず、ZSKの公開鍵（先ほどまでのDNSKEY）を保証するために、同じDNS内にある、KSKの秘密鍵で署名します。
それでそのKSKの秘密鍵に対応するKSKの公開鍵を、一回ハッシュ化して、現在よりも位が高いDNSのDSレコードに追加します。
そしてそのDSレコードをそのDNSが所有する、KSKの秘密鍵で署名します。そして、その秘密鍵に対応する、KSKの公開鍵をハッシュ化して、次に位の高いDNSのDSレコードに追加します。
これをルートDNSまで繰り返します。
これによって、ルートDNSが、悪意ある人の手に渡らない限り、ASKの公開鍵は保証され続けます。
これが、信頼の連鎖です。

### DNSSECについて補足
DNSSECの仕組みは上記の説明の通りなんですが、ちょっと捕捉します。
まず、DNSSECは、通信を暗号化しているものではありません。あくまで、DNSリプライに対しての完全性を保障するものです。
また、DNSSECを拡張したものに**NSEC**というものがあります。NSECは、DNSで、ドメインが存在しないときに、それを証明する役割があります。
NSECにかわりハッシュ化を用いるNSEC3ってのも存在します。

## DoH(DNS over Https）
DNS通信をHTTP上で行うことです。
HTTPSにより通信を暗号化して送ることができます。

## DoT(DNS over TLS)
DNS通信をTLS上で行うことです。
暗号化できます。ポート583で機能します。

以上です。更新があれば追記します