바인드: 쿼리(캐시) './ANY/IN' 거부됨 - DDos 공격인가요?

Question

내 syslog에 다음과 같은 메시지가 떠다니고 있습니다.

Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied

이것이 DDoS 공격인지 아니면 바인드의 이상한 동작인지는 알 수 없습니다.

그래서 저는 24시간 동안 20개 이상의 오류를 생성하는 IP를 차단하는 간단한 fall2ban 감옥을 설정했습니다. 주말이 지나서 확인하고 깜짝 놀랐습니다. 1000개 이상의 IP가 차단되었습니다. 1.1.1.1과 같은 유명한 것을 포함합니다. 그러므로 이것은 옳을 수 없습니다.

내 서버는 Plesk Obsidian을 통해 관리되는 Debian 9입니다. 나는 (내가 아는 한) 바인딩9/named에 대해 특별한 구성을 수행하지 않았습니다. 내 모든 도메인의 기본 ns 서버입니다.

그래서 질문은: DNS 쿼리의 홍수로부터 내 서버를 보호하기 위해 무엇을 할 수 있습니까? 아니면 그냥 무시해야 할까요?

Answer 1

확실하게 말하기는 어렵지만 언뜻 보면 반사 공격 시도(또는 그러한 공격에서 서버를 사용할 가능성에 대한 테스트)일 수 있는 것처럼 보입니다.

이러한 공격의 기본 아이디어는 스푸핑된 소스 IP 주소를 사용하여 UDP를 통해 공개 확인자 서버로 쿼리를 보내 공격 대상(실제로 스푸핑된 소스 IP를 갖고 있는 호스트)에 대한 트래픽을 생성하는 것입니다. 쿼리를 보내는 데 필요한 공격자의 대역폭을 크게 증폭시키기 위해 큰 응답을 사용합니다.

그렇다고 가정하면 그 의미는 다음과 같습니다.

• 당신은 실제 목표가 아니며 단지 대역폭을 "대여"하기 위한 것입니다. 소스 주소는 공격을 받고 있는 것으로 추정되는 사람(또는 서버가 그러한 목적으로 사용될 수 있는지 확인하기 위해 조사하는 사람)입니다.
• 실제로는 작동하지 않았습니다. 이러한 요청을 거부하므로 실제 응답만큼 응답이 크지 않습니다 . ANY. (아마도 처음부터 재귀를 허용하지 않는 것이 좋습니다.)

소스 IP 주소 중 하나가 이기 때문에 합법적인 것처럼 보인다는 귀하의 생각에 대해 1.1.1.1저는 본능적인 반응이 정반대라고 말하고 싶습니다. 이 쿼리의 소스 주소를 보면 1.1.1.1뭔가 이상한 일이 일어나고 있음을 즉시 알 수 있습니다.

• 우리는 그것이 1.1.1.1애니캐스트라는 것을 알고 있습니다. 따라서 이 주소에서 쿼리를 시작하는 것은 끔찍한 생각입니다. 쿼리에 응답하면 응답은 쿼리를 생성한 인스턴스가 아닌 1.1.1.1가장 가까운(BGP 의미에서) 인스턴스로 라우팅됩니다 .1.1.1.1
• 소스 주소 선택을 무시하더라도 Cloudflare 공개 확인자가 서버에 쿼리를 보내는 이유는 무엇입니까 . ANY? 귀하는 권한이 없으며 .귀하에게 문의 사항을 전달할 이유도 없습니다.

즉, 이러한 쿼리가 아마도 "좋지 않은 것"이라는 것이 맞다고 생각합니다.
이제 이 주소로부터의 트래픽을 차단하는 것이 좋은 생각인지는 잘 모르겠습니다. 여기서 문제는 DoS 공격이 쉽다는 것입니다. 누군가는 귀하의 이러한 차단 동작을 이용하여 귀하의 서버가 임의 주소의 쿼리에 대한 응답을 중단하도록 만들 수 있으며, 이는 합법적인 트래픽을 거부하는 데 악용될 수 있습니다.