dns-oarc 2015.05

https://indico.dns-oarc.net/event/21/contributions

随机子域名DDOS攻击、开放递归用于DDOS攻击

增加递归侧的各项处理,弱化根的作用,减轻TLD的压力

DNS多数问题也根源于协议层面DNS查询应答没有双向认证、DNS应答包的放大性、DNS分层服务流量透传,以及实际操作中开放递归的滥用、分层授权后由TTL决定的更新时间不均

A Day in the Life of a DNS Resolver

欧洲小开放递归

DDOS查询包约占递归总查询量的11%~12%;DDOS查询包中,85%~99%都是随机子域名攻击,此外为放大查询攻击。

A countermeasure of random subdomain attacks (Aggressive negative caching with NSEC)

中间的递归否定缓存溢出,影响正常用户递归访问体验

即使递归通过NSEC/NSEC3记录确认了NXDOMAIN,递归仍要去权威查询,确认是否存在泛域名配置。

Draft改进就是如果确认了NSEC/NSEC3 & NO WILDCARD,递归可以直接返回NXDOMAIN:

Caching of Negative DNS records(微软)

不同的权威软件、服务器返回的否定应答TTL策略相差较大,可能不直接按照SOA MINIMAL记录来设置,而是自己设定一个值。

Alexa Top 100w域名中,4.6%设的过高,0.1%设的过低。

否定缓存的TTL设置长短,影响记录误删除故障的恢复时间。建议SOA TTL 与 Min TTL 时间一致,且 < 3600s

Dealing with large DNS packet floods

Cloudflare Anycast  + 域名分散配置NS(例如域名A用NS1,NS2域名B用NS3、NS4)

Iptables bpf (速度快,支持复杂匹配):https://github.com/cloudflare/bpftools

直接查询 1k pps -> answer,间接查询 recursor 200k pps -> answer,伪造包查询 100m pps -> drop

Anycast : 非本地ip -> block;白名单recursor ip列表。

Drilling down into DNS DDoS Data Nominum

通过open resolver间接攻击的,一般是多ip (>1000)低流量

通过恶意IP攻击的,一般是大查询量 > 1000qps,IP数少;rutgers.edu

随机子域名攻击影响正常用户查询;权威流量限制可以有效保护未被攻击的域名体验,但对于被攻击的域名会有影响。

{random}.www.appledaily.com.tw 在40分钟内总查询量 735M,client 10.6M;攻击流量37.9M,攻击client 79.7 thousand,avg attack client qps = 0.2。

{random}.rutgers.edu 在60分钟内总查询量1.01billion,client 11.1Million;攻击查询19.1Million,client 238;avg qps / client = 22。

对合法查询域名的白名单;对随机域名查询的黑名单。

Everyday attacks against Verisign-operated DNS infrastructure

Verisign .com / .net 共 130 million 域名, A-root, J-root

110 billion DNS query/day

17个大节点(major internet exchange points)

69+ 小节点(regional sites): .com / .net / J-root

网络:2+ Tbps 防御带宽(还在扩),EDGE节点支持BGP FlowSpec牵引攻击流量清洗

服务器:所有zone data载入内存数据库

过滤:核心路由器acl/flow spec/qos/mpls te;负载均衡系统 pkt size/query type/rate limits;实时自动化清洗 snmp + netflow + routing policy adjustments / filter deployment

自研dns软件

快速分配、调整查询资源;应用层过滤优先快速部署、往源端压

一些策略启动可能存在副作用,例如,block traffic / rrl

真实递归攻击

如果QNANME正好是NXDOMAIN,那么针对该QNAME的随机LABEL攻击会透传到上一级DNS 设施;有时候根也看得到。

开始过滤之后,递归启动重试风暴,流量本来打3million qps,可以冲到14 million qps。

递归最好对重试做限速,一般会重试4~5次;100%过滤随机QNAME攻击流量会倒逼流量增长 => RRL(有副作用);与递归联系(不现实);TLD处理(授权之后流量未必过TLD);把随机攻击的域名引到特定的NS处理(反应时间问题)

EDNS0=9000,一般就是512、1024、2048、4096

ANY/DNSKEY查询放大攻击:入32bit,出2000+bit;大范围的IP地址;伪造源

zz.com式攻击:verisign被用作反射器,此时,需用RRL

涨带宽,涨单机性能,分散部署

RRL细调,避开OS层协议栈用户空间开销(0-copy),单机解析性能优化 6 million qps / 10 Gps

可扩展性,网络层多路传输;

Observations on DNSSEC and ECDSA in the wild

DNSSEC实际部署采用的加密算法探测,RSA/ECDSA,后者支持比例较小,但相对RSA的长度较短

Popularity ranking for domains based on DNS traffic

借鉴TF-IDF算法的思路,WORD -> DOMAIN, DOCUMENT -> SRC IP。

暂未考虑TTL的影响,以及根据SRC IP的重要性区分权重。

Query name minimization and authoritative server behavior Verisign

www.example.com :

简单的方案:com. => root , example.com. => com. , www.example.com. => example.com. ;中间有返回NXDOMAIN,则迭代查询立即停止

稍复杂的方案:中间查询NS记录;最终才查真实query type;对上级隐藏真实查询内容。

可能导致权威无法返回较优的结果(上层只查NS而非发具体域名具体QTYPE);越上层cut的越多。

CDN用起来可能有问题。举了www.ietf.org.cdn.cloudflare.net.的例子,中间查cdn.cloudflare.net.是NXDOMAIN(而非NODATA),直接断掉。

NXDOMAIN is an authoritative indication that the queried name doesn’t exist in the DNS (and that nothing below it exists either).

多层域名DDoS攻击;中间查询变多。

对根隐藏这个力度有点大。

Signing DNSSEC answers on the fly at the edge: challenges and solutions!

小查询量域名占多数;分布式网络(34个数据中心);

RR动态生成;避免zone walking

Live Sign海量rrsig data,无法离线预测(这个主要是CDN业务的特殊性,应答与地理位置有关)

NSEC3没大用,NSEC5还没做。

三个关键点:速度;否定应答;密钥管理

目标:small size( key / signatures),not require full zone files

自研DNS,后端采用数据库,支持dynamic answers,cname flattening等等

DNSSEC做为”filter”应用到answer上

ECDSA P256 签名速度比 RSA1024 快 3倍以上,用go重写之后加速21倍

NSEC3太重,调整成RFC4470/RFC4471推荐的white lies模式,类似于wildcard。也就是,当+dnssec时,把NXDOMAIN转成NOERROR,指向泛域名的RR。

Cloudfare 只sign NOERROR,true lies,域名配NSEC/RRSIG。

只是做一次签名,不需db lookup / zone walking。

此时,NSEC需区分NXDOMAIN,以及空RR:https://datatracker.ietf.org/doc/draft-ogud-fake-nxdomain-type/

查存在域名的不存在RR时,还是要查DB里的NSEC关系,然后在NSEC应答里全部返回。

ZSK分散到edge,KSK集中管理。

多个域名共用相同的KSK/ZSK。

The iDNS attack (resolver loop)

通过glue ns的多层NS授权,放大10倍攻击第三方;或者使得多层NS查询使得递归cache过多无效信息同时消耗CPU。

RFC1034只写了避免出现无限loop,没有具体约定,编程各自实现。

www.example.com -> NS1.EXAMPLE.COM -> NS2.EXAMPLE.COM/NS3.EXAMPLE.COM
-> NS4.EXAMPLE.COM/NS5.EXAMPLE.COM -> NS[6-16].EXAMPLE.COM (受害IP)

Update on experimental BIND features to rate-limit recursive queries

Client 查询量上涨;SERVER返回NXDOMAIN/SERVFAIL应答量上涨

时延,丢包,内存消耗,连接耗尽

递归检测到异常流量,临时充当“LIE”目标域名的权威(LOCAL ZONE/ DNS-RPZ),攻击结束后自动/手动恢复,all queries返回NXDOMAIN。可能误判。

直接应答SERVFAIL而非hold住等timeout(减轻递归压力)

递归监测 ratio = timeout / success(per server),自动调整阈值

SERVFAIL上升一般是权威被打僵了;NXDOMAIN上升可以启动LIE模式。

SERVFAIL/DROP/NXDOMAIN 哪个好。

可能要白名单。

内置auto-DNS-RPZ模块。

持久性的good RRSET(non-expiring),其实就是优先保证的东西。

Zonemaster - do we need another DNS testing tool?

开源的域名zone配置检查工具

sudo cpan -i Zonemaster

sudo cpan -i Zonemaster::CLI

https://github.com/pawal/zonemaster-collector



blog comments powered by Disqus

Published

19 May 2015

Tags