공용 재귀 DNS 서버-iptables 규칙

Linux 컴퓨터에서 공개 재귀 DNS 서버를 실행합니다. 우리는 DNS 증폭 공격에 사용되었습니다. iptables이러한 공격을 완화하는 데 도움이되는 권장 규칙이 있습니까?

확실한 해결책은 아웃 바운드 DNS 패킷을 특정 트래픽 수준으로 제한하는 것입니다. 그러나 공격이 대상 IP 주소로의 트래픽을 차단하기 위해 좀 더 영리한 것을 찾고자했습니다.

조언과 제안을 검색했지만 모두 "공개 대상 재귀 이름 서버를 실행하지 마십시오". 안타깝게도 변경하기 쉽지 않은 상황이 발생하지 않으면 문제가 발생할 수 있습니다. 이는 이러한 공격이 문제가되기 전에 10 년 전에 이루어진 결정 때문입니다.

"내 문제가 아님"시나리오의 모든 종류의 악의는 실제로 귀하의 잘못이 아니며 "어려운"또는 "어려운"정도에 관계없이 적절한 조치를 취함으로써 100 % 해결되어야 합니다. 재귀 서버를 엽니 다 .

단계적 철회 : 고객에게이 서버가 X 날짜부터 종료 될 것이라고 알립니다. 그 후에는 DNS 서버 사용을 막기 위해 패치를 설치해야합니다 (있는 경우). 이것은 항상 이루어집니다. Sysadmins, 네트워크 관리자, 헬프 데스크 담당자, 프로그래머? 우리 는 그것을 얻는다 ; 벤더 / 서비스 제공 업체 / 파트너가 X 날짜 이후에 무언가 사용을 중단하라고 알려주는 표준 운영 절차 때문에이 단종은 항상 발생합니다. 우리는 항상 그것을 좋아하지는 않지만 IT에서의 삶의 사실입니다.

현재 장치에이 문제가 없다고 말하면 펌웨어 업데이트 또는 패치로이 문제를 해결했다고 가정합니다. 나는 당신이 말한 알고 당신이 장치를 건드릴 수 없어, 그러나 확실하게 그들은 할 수 있습니까? 나는 그들이 당신에게 기본적으로 집에 전화를이 상자를 허용하는 경우, 그들은 정말 할 수 없다, 말은 그 일을 누가에 대한 항문 무엇 그들의 장치; 그들이 아는 모든 것에 대해 리버스 프록시 설정을 할 수 있으므로,이를 수정하는 패치를 설치하거나 그들 자신의 DNS 서버를 사용하도록 지시 하지 않는 이유는 무엇입니까 ? 확실히 당신의 장치는 DHCP를 지원합니다; 나는 그렇지 않은 네트워크 장치 (오래된 / 연약한 / 홀수)에 대해 생각할 수 없습니다 .

그렇게 할 수 없다면, 다음으로해야 할 일은 재귀 서버에 액세스 할 수있는 사람을 제어 하는 것입니다. 누가 그것을 사용하고 있는지, 어떻게 "알기가 어렵다"고 말하지만, 특정 트래픽을 찾아서 포기할 시간입니다. 합법적이지 않습니다.

이들은 "준 군사 / 정부"조직입니까? 아마도 그들은 그들이 소유 한 합법적 인 넷 블록의 일부일 것입니다. 이러한 장치는 동적 IP 뒤의 홈 라우터가 아닙니다. 찾아. 장치에 DNS 서버에 액세스하는 데 사용할 넷 블록 / IP 주소 만 확인할 수있는 경우 펌웨어 또는 제품 교체를 강요하지 않고 문제를 설명하고 문제를 해결하는 방법을 설명하십시오 .

이러한 방식으로 항상 이루어집니다. 엑스트라 넷 액세스 또는 HL7 리스너를 이러한 방식으로 의료 파트너에게 제한하는 여러 고객이 있습니다. 그건 그렇게 어렵지 않다양식을 작성하고 트래픽을 예상해야하는 IP 및 / 또는 넷 블록을 제공하려면 익스트라 넷에 액세스하려면 IP 또는 서브넷을 제공해야합니다. 그리고 이것은 거의 이동 목표가 아니기 때문에 매일 수백 개의 IP 변경 요청이 너무 많아지는 것은 아닙니다. 수백 개의 서브넷과 수천 개의 호스트 IP를 가진 자체 넷 블록을 소유하는 대규모 캠퍼스 병원 네트워크는 나에게 정기적으로 제공합니다. 내가 기대해야 할 소수의 IP 주소 또는 서브넷; 다시 말하지만, 이들은 랩톱 사용자가 항상 캠퍼스 주변을 돌아 다니는 것이 아닙니다. 왜 끊임없이 변화하는 IP 주소에서 UDP 소스 패킷을 볼 수 있습니까? 분명히 나는 ​​여기에 가정을하고 있지만, 100 대 미만의 장치에 대해 생각하는 것만 큼은 아니라고 내기 할 것입니다. 예, 긴 ACL이 될 것입니다.

어떤 이유로 통신 채널이 열려 있지 않거나 누군가가 너무 두려워하거나 레거시 장치 소유자에게 연락하여이를 제대로 수행 할 수없는 경우 정상적인 사용 / 활동의 기준을 설정해야 공식화 할 수 있습니다. DNS 증폭 공격에 참여하는 데 도움 이 되는 다른 전략도 있습니다.

오래 실행 tcpdump되면 들어오는 UDP 53에서 필터링을 수행하고 DNS 서버 응용 프로그램에서 자세한 로깅을 수행 해야합니다. 또한 새 장치를 추가 하지 않고 단순히 레거시를 제공 하기 때문에 소스 IP 주소 / 넷 블록 / geoIP 정보 수집을 시작하고 싶습니다 (미국의 모든 클라이언트가 있습니까? 다른 모든 것을 차단하십시오). 기존 설치에 대한 서비스.

또한 요청한 레코드 유형과 도메인, 대상 및 빈도 를 이해 하는 데 도움이됩니다 . DNS 증폭이 의도 한대로 작동하려면 공격자가 큰 레코드 유형 (1)을 기능 도메인 (2).

1. "대형 레코드 유형": 재귀 DNS 서버로 분석 할 수 있으려면 장치에 TXT 또는 SOA 레코드가 필요합니까? DNS 서버에서 유효한 레코드 유형을 지정할 수 있습니다. BIND와 아마도 Windows DNS에서 가능하다고 생각하지만 파고 들어야합니다. DNS 서버가 SERVFAILTXT 또는 SOA 레코드에 응답 하고 그 응답이 의도 한 페이로드보다 10 배나 작은 경우. 스푸핑 된 피해자가 여전히 SERVFAIL서버로부터 이러한 응답을 받고 있기 때문에 여전히 "문제의 일부"입니다. 그러나 적어도 그 결과를 망치지 않고 아마도 DNS 서버가 수집 된 목록에서 "상장 해제"됩니다. 봇은 시간이 지남에 따라 "협력"하지 않습니다.

2. "기능 도메인": 유효한 도메인 만 허용 할 수 있습니다. 서버가 작동하려면 Windows Update, Symantec 등이 필요한 강화 된 데이터 센터 설정에서이 작업을 수행합니다. 그러나이 시점에서 발생하는 피해를 완화시키는 것입니다. 서버가 여전히 위조 된 소스 IP에 응답하기 때문에 피해자는 여전히 서버에 대한 공격을 NXDOMAIN받거나 SERVFAIL서버로부터 응답을받습니다. 다시 Bot 스크립트는 결과에 따라 열린 서버 목록을 자동으로 업데이트하여 서버를 제거 할 수 있습니다.

또한 응용 프로그램 수준 (예 : 메시지 크기, 클라이언트 당 요청 수 제한) 또는 방화벽 수준 (다른 답변 참조)에서 제안한 것처럼 일종의 속도 제한을 사용하지만 다시 한 번 설명하겠습니다. 합법적 인 트래픽을 제거하지 않도록 몇 가지 분석을 수행해야합니다.

조정 및 / 또는 교육을받은 침입 감지 시스템 (여기서는 기준선이 필요함)은 시간이 지남에 따라 소스 또는 볼륨별로 비정상적인 트래픽을 감지 할 수 있어야하지만, 오 탐지 및 실제로 공격을 막고 있는지 확인하십시오.

하루가 끝나면 모든 노력이 가치가 있는지 또는 올바른 일이 완료되었다고 주장 해야하는지 궁금해해야합니다. 처음에는 문제가 없습니다.

속도 제한의 종류에 따라 다릅니다.

제한 속도 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대신 limitIP를 사용하면 대상 IP 당 속도가 제한됩니다. 즉, 한도에 도달 한 8.8.8.8에 5 개의 패킷이 hashlimit있으면 8.8.4.4로 패킷이 전송되는 것을 방지 할 수 있습니다. 8.8.8.8이 최대가되면 여전히 8.8.4.4에 도달 할 수 있습니다.

한계를 초과하는 패킷을 삭제하지 않으려면 실제로 원하는 것이 tc입니다. tc많은 버스트 트래픽보다는 꾸준한 스트림을 얻기 위해 흐름을 조절합니다. 들어오는 쪽에서 패킷은 응용 프로그램에 느리게 전달되지만 모두 순서대로 도착합니다. 나가는 패킷은 가능한 한 빨리 응용 프로그램을 떠나지 만 일관된 스트림으로 와이어에 배치됩니다.

tc많이 사용 하지는 않았지만 다음 은 DNS에 쉽게 적응할 수있는 ICMP 속도 제한 의 예입니다 .

스푸핑 된 쿼리에 대한 응답을 잠재적으로 완화하기 위해 수행 할 수있는 작업은 다음과 같습니다.

먼저 보안 채널의 로그를보고 스푸핑되는 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, 오프셋 0, 플래그 [없음], 프로토 : UDP (17), 길이 : 45) 10.11.12.13.51169> 01.02.03.04.domain : 4215+ ANY ? . (17)
        0x0000 : 4500002d b5430000 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 규칙을 추가하면 루트에서 모든 레코드를 요청하는 스푸핑 쿼리의 95 % 이상을 차단한다는 것을 알았습니다.

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

마일리지가 다를 수 있습니다. 도움이 되길 바랍니다.

tcLinux에서 아웃 바운드 포트 53 UDP에 대한 규칙 사용 및 큐잉 :

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'인 모든 패킷에 대해 10mbit 로 제한됩니다. 방화벽 표시는 방화벽 내부에만 있으며 패킷을 수정하지 않습니다. 큐잉 규율에 의해 패킷을 처리하기 만하면됩니다. 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 상자에서 하루 정도의 패킷 추적으로 시작하십시오. 여기에서 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 

이것은 이상적이지 않습니다. 초당 더 적은 수의 패킷을 허용하고 더 높은 버스트를 갖는 것이 좋습니다.

다음은 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