[{TableOfContents}]



!!!Bind Install
*[리눅스에서 Bind 설치|Bind_Install_Linux]

!!!White Domain
*[kisarbl 화이트 도메인 등록|http://www.kisarbl.or.kr]


!!!DNS Server 관련 링크
*[김정균님의 BIND 관련 문서|http://oops.org/?t=lecture&s=bind9]
*[윈도우 2000 DNS 설치 및 구성|http://blog.naver.com/akan1977?Redirect=Log&logNo=40024942625]






!!!dig
{{{
dig @nods.ods.or.kr ods.or.kr axfr
}}}

!!!nslookup
{{{
nslookup www.daum.net
}}}









!!!DNS 보안관련 링크
*[DNS Zone 전송 차단하기 | http://blog.naver.com/lemonaroma98?Redirect=Log&logNo=60018852862]
*[BIND Statistics|http://blog.naver.com/gmmore?Redirect=Log&logNo=140027280763]
*[DNS Cache Poisoning|http://blog.naver.com/lemonaroma98?Redirect=Log&logNo=60022468542]

!!! DNS 보안관련 정리
{{{
존 트랜스퍼
	문제점
		ZONE Transfer를 이용해 DNS서버의 너무 많은 정보를 얻음으로써 크래킹에 사용될 수 있다.
		
		dig 도메인 axfr

	해결 방안
		named.conf의 options항목에 allow-transfer 항목을 추가하여 특정 서버만 zone transfer 할 수 있도록 수정
		options {
			allow-transfer { 192.168.1.30; 192.168.1.20; };
		};


DOS 공격
	문제점 
		당신의 내부 네트웍이 192.168.1.x 서브넷에만 존재한다고 가정하자. 
		이 네트웍의 외부에 있는 머신들은 당신이 관리하는 존에 관해서만 query 할 수 있게 하는 것이 좋다. 
		왜냐하면 DNS를 공격하는 attacker는 대부분 자신이 관리하는 domain에 query 하는 것을 필요하기 때문이다. 
		우리가 소유하지 않은 domain, 즉 외부로 나가는 query를 제한하면 여러 DNS 공격을 예방할 수 있다. 

	해결 방안
	

		named.conf의 option, zone 항목 수정
		option 수정 사항 allow-query { 192.168.1.0/24; };
		zone 수정 사항 allow-query { any; };

		bind의 기술된 zone의 query와 reverse query를 할 수 있으나 그 외의 query는 내부의 호스트들만이 가능하도록 되었다. 

	문제점
		recursive query를 내부 호스트에서만 가능하도록 하자. 
		이것은 resolver library 만을 가진 각각의 host가 name server에 name/IP 매핑을 요청하는 경우이다. 
		각각의 호스트는 dumb.target.jay의 IP를 물어올 것이다. name server는 우선 root server에게 .jay domain를 묻게 된다. 
		root server는 .jay domain을 관리하는 server의 IP를 주게되고, name server는 이 IP로 .traget.jay의 관리 server를 묻는다. 
		이 IP를 받아 dumb.target.jay에 대한 name server 정보를 요청한다. 오직 내부의 호스트만이 name server에 이러한 일을 시킬 수 있어야 한다. 
		외부 호스트들은 자신들의 name server가 있을 것이다. 이러한 외부 호스트들에 recursive query를 허용하면 
		cache poisoning attack과 같은 공격이 가능해 지고 외부 네트웍에 대한 많은 access를 유발하게 된다. 

	해결 방안
		named.conf의 option, zone 항목 수정
		option 수정 사항 allow-recursion { 192.168.1.0/24; };


remote root exploit
	문제점
		root계정으로 수행 중인 dns를 공격하여 성공하게 되면 root권한을 획득하게 된다.
		공격이 성공 하여도 root권한을 획득 할 수 없게 권한이 축소된 named계정을 만들어 실행 시켜줘야 한다.

	해결방안
		named -u dns_user -g dns_group 

Zone Transfer, query
	dns 의 정보를 이용해 크래킹에 이용

dynamic update
	동적업데이트의 버그를 이용한 해킹

recursive query
	재귀호출사용을 막아 dos 공격을 막음

	DNS Cache Poisoning

remote root exploit
	bind의 실행을 권한이 적은 일반 계정으로 수행

zone transfer
허가되지 않은 사용자에게 zone 정보가 유출될 
경우 호스트 종류, 네트워크 구성, 
ip 리스트 등이 노출된다.

dynamic update
DNS 정보의 불법 삭제 및 변경에 악용될 수 있다.

DNS 공격 방식

	풋프린팅(Footprinting) 
		공격자가 중요한 네트워크 리소스의 DNS 도메인 이름, 컴퓨터 이름 및 IP 주소를 알아내기 위해 DNS 영역 데이터를 가져오는 프로세스입니다. 
		일반적으로 공격자는 이 DNS 데이터를 사용하여 다이어그램, 풋프린트 또는 네트워크에 대한 공격을 시작합니다. 
		DNS 도메인과 컴퓨터 이름은 대개 사용자가 도메인과 컴퓨터 이름을 쉽게 기억할 수 있도록 도메인 또는 컴퓨터의 기능이나 위치를 나타냅니다. 
		공격자는 동일한 DNS 원칙을 이용하여 네트워크에 있는 도메인과 컴퓨터의 기능 또는 위치를 알아냅니다.

	서비스 거부 공격 
		공격자가 네트워크에 있는 하나 이상의 DNS 서버에 재귀 쿼리를 집중적으로 보내 네트워크 서비스를 사용할 수 없게 만드는 경우입니다. 
		DNS 서버가 쿼리로 초과되면 결국에는 CPU 사용량이 최대 한계에 도달하여 DNS 서버 서비스를 사용할 수 없게 됩니다. 
		네트워크에서 DNS 서버가 완전히 작동되지 않으면 네크워크 사용자는 DNS를 사용하는 네트워크 서비스를 사용할 수 없게 됩니다.

	데이터 수정 
		DNS를 사용하는 네트워크를 풋프린팅한 공격자가 자신이 만든 IP 패킷에서 유효한 IP 주소를 사용하여 네트워크의 유효한 IP 주소에서 이러한 
		패킷을 보낸 것처럼 하려는 시도입니다. 일반적으로 이를 IP 위장이라고 합니다. 공격자는 서브넷의 IP 주소 범위 내에 속하는 유효한 IP 주소를 
		통해 네트워크에 액세스하고 데이터를 손상시키거나 다른 공격을 수행할 수 있습니다.

	리디렉션 
		공격자가 DNS 이름에 대한 쿼리를 공격자의 제어를 받고 있는 서버로 리디렉션할 수 있는 경우입니다. 
		이후 쿼리를 공격자의 제어를 받고 있는 서버로 보내도록 잘못된 DNS 데이터로 DNS 서버의 DNS 캐시를 오염시키려는 시도도 리디렉션의 한 가지 방법입니다. 
		예를 들어, 쿼리가 원래 example.microsoft.com에 대해 수행되었고 조회 응답이 malicious-user.com 등과 같은 microsoft.com 도메인 외부에 있는 
		이름의 레코드를 제공하는 경우 DNS 서버는 malicious-user.com에 대해 캐시된 데이터를 사용하여 해당 이름에 대한 쿼리를 확인합니다. 
		보안되지 않은 동적 업데이트와 같이 공격자가 DNS 데이터에 쓰기 액세스가 가능할 경우 리디렉션이 발생할 수 있습니다.

	프로토콜 취약점에 의한 공격 방식
		DNS 프로토콜 자체의 결함을 이용해 공격하는 것으로 과도한 로드를 걸거나 메모리 조작으로 인해 정상적인 DNS 서비스를 불가능하게 만드는 것으로 
		서비스거부(DoS)ㆍ분산서비스거부(DDoS) 공격이 예가 될 수 있다.

	DNS 캐시 포이즈닝
		DNS 캐시 포이즈닝에 의한 공격의 경우 호스트명의 IP주소를 변경, 인터넷 사용자를 위조된 웹사이트로 유인하는 등의 
		파밍(Pharming)과 피싱(Phishing)등의 공격이 가능해진다는 점에서 전자보다 더 위협적이다.

	DNS 서버 공격을 통한 파밍 
		대부분의 파밍 공격은 피싱과 마찬가지로 새로운 해킹 기법이나 고도의 기술을 필요로 하지 않는다. 
		국내에는 아직 파밍으로 인한 직접적인 피해 사례가 없으므로 여기서는 주로 해외 사례를 통해 파밍을 이해해본다. 
		몇 가지 피해 사례를 종합해보면 대체로 파밍은 일반적인 도메인 네임 서비스의 취약성(DNS 캐시 중독, DNS 스푸핑, 도메인 하이제킹)을 통해 발생되는 것을 알 수 있다. 
		비록 파밍 피해가 없다하더라도 이런 도메인 네임 서비스에 관한 취약성은 많은 국내 업체들의 서버에서도 동일하게 발견되고 있다. 
		해외의 수많은 파밍 피해 사례에도 불구하고, 국내의 많은 시스템 관리자들이 이런 도메인 네임 서버의 취약성을 대수롭지 않게 여기기 때문이다.

DNS 보안
	Zone Transfer
		문제점
			Zone Transfer를 이용해 DNS서버의 너무 많은 정보를 얻음으로써 크래킹에 사용될 수 있음

		해결 방안
			named.conf의 options항목에 allow-transfer 항목을 추가하여 특정 서버만 zone transfer 할 수 있도록 함

			options {
				allow-transfer { 192.168.1.1; 192.168.1.2; };
			};

	DynamicUpdate
		문제점
			DNS 정보의 불법 삭제 및 변경에 악용될 수 있다.		

		해결 방안
			named.conf파일의 options항목에 allow-update 항목을 추가하여 특정 서버만 DynamicUpdate할 수 있도록 함
			
			options {
				allow-update { 192.168.1.1; 192.168.1.2; };
			};

	서비스거부(DoS)
		문제점
			DNS 프로토콜 자체의 결함을 이용해 공격하는 것으로 과도한 로드를 걸거나 메모리 조작으로 인해 정상적인 DNS 서비스를 불가능하게 함
		
		해결 방안
			named.conf의 options항목에 allow-query 항목을 추가하여 외부로 나가는 query를 제한하고 관리하는 zone에 관해서만 query 할수 있게 함

			options {
				allow-query { 192.168.1.0/24; };
			};

			named.conf의 options항목에 allow-recursion 항목을 추가하여 recursive query를 내부 호스트에서만 가능하도록 설정 하여 네트웍에 대한 많음 access를 제한

			options {
				allow-recursion { 192.168.1.0/24; };
			};
	
	DNS 캐시 포이즈닝(DNS Cache Poisoning)
		문제점
			recursion(순환질의)이 허용하도록 잘못된 구성된 DNS 혹은 취약한 버젼의 DNS에 대해 가능한 공격 임
			호스트명의 IP주소를 변경하여 인터넷 사용자를 위조된 웹사이트로 유인하는 등의 파밍(Pharming)과 피싱(Phishing)등의 공격이 가능해짐

		해결 방안
			named.conf의 options항목에 allow-recursion 항목을 추가하여 recursive qury를 불가능 하게 설정

			options {
				allow-recursion { 192.168.1.0/24; };
			};

	DNS 서버 실행시 일반 사용자 계정으로 실행
		문제점
			root계정으로 수행 중인 dns를 공격하여 성공하게 되면 root권한을 획득하게 된다.
			공격이 성공 하여도 root권한을 획득 못하도록 하여야 한다.	

		해결방안
			권한이 축소된 named계정을 만들어 실행 시켜줘야 한다.
			named -u dns_user -g dns_group 





DOS 공격
	문제점 
		당신의 내부 네트웍이 192.168.1.x 서브넷에만 존재한다고 가정하자. 
		이 네트웍의 외부에 있는 머신들은 당신이 관리하는 존에 관해서만 query 할 수 있게 하는 것이 좋다. 
		왜냐하면 DNS를 공격하는 attacker는 대부분 자신이 관리하는 domain에 query 하는 것을 필요하기 때문이다. 
		우리가 소유하지 않은 domain, 즉 외부로 나가는 query를 제한하면 여러 DNS 공격을 예방할 수 있다. 

	해결 방안
	

		named.conf의 option, zone 항목 수정
		option 수정 사항 allow-query { 192.168.1.0/24; };
		zone 수정 사항 allow-query { any; };

		bind의 기술된 zone의 query와 reverse query를 할 수 있으나 그 외의 query는 내부의 호스트들만이 가능하도록 되었다. 

	문제점
		recursive query를 내부 호스트에서만 가능하도록 하자. 
		이것은 resolver library 만을 가진 각각의 host가 name server에 name/IP 매핑을 요청하는 경우이다. 
		각각의 호스트는 dumb.target.jay의 IP를 물어올 것이다. name server는 우선 root server에게 .jay domain를 묻게 된다. 
		root server는 .jay domain을 관리하는 server의 IP를 주게되고, name server는 이 IP로 .traget.jay의 관리 server를 묻는다. 
		이 IP를 받아 dumb.target.jay에 대한 name server 정보를 요청한다. 오직 내부의 호스트만이 name server에 이러한 일을 시킬 수 있어야 한다. 
		외부 호스트들은 자신들의 name server가 있을 것이다. 이러한 외부 호스트들에 recursive query를 허용하면 
		cache poisoning attack과 같은 공격이 가능해 지고 외부 네트웍에 대한 많은 access를 유발하게 된다. 

	해결 방안
		named.conf의 option, zone 항목 수정
		option 수정 사항 allow-recursion { 192.168.1.0/24; };


remote root exploit
	문제점
		root계정으로 수행 중인 dns를 공격하여 성공하게 되면 root권한을 획득하게 된다.
		공격이 성공 하여도 root권한을 획득 할 수 없게 권한이 축소된 named계정을 만들어 실행 시켜줘야 한다.

	해결방안
		named -u dns_user -g dns_group 

}}}




!!! BIND 명령어
{{{

----------------------------------------------------------------------------------
Tip : 실행명령
----------------------------------------------------------------------------------
/usr/local/sbin/named -p 53 -u named

----------------------------------------------------------------------------------
Tip : 종료명령
----------------------------------------------------------------------------------
kill -9 `cat /var/named/run/named.pid`
/usr/local/sbin/rndc -s 127.0.0.1 stop

----------------------------------------------------------------------------------
기타 명령어
----------------------------------------------------------------------------------
  reload	Reload configuration file and zones.
  reload zone [class [view]]
		Reload a single zone.
  refresh zone [class [view]]
		Schedule immediate maintenance for a zone.
  retransfer zone [class [view]]
		Retransfer a single zone without checking serial number.
  freeze zone [class [view]]
  		Suspend updates to a dynamic zone.
  thaw zone [class [view]]
  		Enable updates to a frozen dynamic zone and reload it.
  reconfig	Reload configuration file and new zones only.
  stats		Write server statistics to the statistics file.
  querylog	Toggle query logging.
  dumpdb	Dump cache(s) to the dump file (named_dump.db).
  stop		Save pending updates to master files and stop the server.
  stop -p	Save pending updates to master files and stop the server
		reporting process id.
  halt		Stop the server without saving pending updates.
  halt -p	Stop the server without saving pending updates reporting
		process id.
  trace		Increment debugging level by one.
  trace level	Cha
  notrace	Set debugging level to 0.
  flush 	Flushes all of the server's caches.
  flush [view]	Flushes the server's cache for a view.
  flushname name [view]
		Flush the given name from the server's cache(s)
  status	Display status of the server.
  recursing	Dump the queries that are currently recursing (named.recursing)
  *restart	Restart the server. 
  * == not yet implemented
  Version: 9.3.1

}}}











!!! BIND nsupdate(동적 업데이트)
{{{

/usr/local/bin/nsupdate 

server 202.30.50.182
update add 8984.978.gs1-eanucc13.id.ods.or.kr. 86400 NS ns.8984.978.gs1-eanucc13.id.ods.or.kr.
update add ns.8984.978.gs1-eanucc13.id.ods.or.kr. 86400 A 202.30.50.182
send
quit

server 202.30.50.182
zone id.ods.or.kr
prereq yxrrset 3698.235.gs1-eanucc13.id.ods.or.kr. 86400 NS lods.repia.com.
update delete 3698.235.gs1-eanucc13.id.ods.or.kr. 86400 NS lods.repia.com.
send
quit

}}}





!!! BIND log
{{{
로그 디렉토리
/var/log/named/*.log    # /etc/named.conf 에서 로그 설정


/var/adm/message
/var/log/named/*
}}}









!!! DNS 각종 질의 방법
{{{

----------------------------------------------------------------------------------
soa 질의
----------------------------------------------------------------------------------
nslookup -type=soa ods.or.kr 202.30.50.180
nslookup -type=soa iata-btic.id.ods.or.kr 202.30.50.180 

----------------------------------------------------------------------------------
FQDN 질의 예시
----------------------------------------------------------------------------------
/usr/local/bin/dig @202.30.50.184 881001.epc-sgtin.id.ods.or.kr NS
/usr/local/bin/dig @202.30.50.184 8984.978.gs1-eanucc13.id.ods.or.kr NS
 
/usr/local/bin/dig @202.30.50.184 1.881001.epc-sgtin.id.ods.or.kr NAPTR
/usr/local/bin/dig @202.30.50.184 1.8984.978.gs1-eanucc13.id.ods.or.kr NAPTR

----------------------------------------------------------------------------------
Tip : 위임받은 도메인 응답에러
----------------------------------------------------------------------------------
dig로 질의시에 NS 레코드로 위임받을 경우 위임받은 서버가 응답을 할 수
없으면 ANSWER SECTION 이 없는 응답을 받는다. 위임하는 서버로 dig질의를
보내는 ANSWER SECTION 을 받을 수 있다.

----------------------------------------------------------------------------------
위임받은 도메인 체크
----------------------------------------------------------------------------------
도메인을 NS레코드로 위임받은 후에는 다음과 같이 검사한다.
dig @위임하는서버 위임받은도메인
dig @위임받은도메인의NS 위임받은도메인

dig @nods.ods.or.kr 1.8984.977.gs1-eanucc13.id.ods.or.kr. naptr
dig @ns.8984.977.gs1-eanucc13.id.ods.or.kr. 1.8984.977.gs1-eanucc13.id.ods.or.kr. naptr


> dig @nods.ods.or.kr 1.8984.977.gs1-eanucc13.id.ods.or.kr. naptr
# ...
# ;; QUESTION SECTION:
# ;1.8984.977.gs1-eanucc13.id.ods.or.kr. IN NAPTR

# ;; AUTHORITY SECTION:
# 8984.977.gs1-eanucc13.id.ods.or.kr. 86400 IN NS	ns.8984.977.gs1-eanucc13.id.ods.or.kr.

# ;; ADDITIONAL SECTION:
# ns.8984.977.gs1-eanucc13.id.ods.or.kr. 86400 IN	A 202.30.50.182
# ...


> dig @ns.8984.977.gs1-eanucc13.id.ods.or.kr. 1.8984.977.gs1-eanucc13.id.ods.or.kr. naptr
# ...
# ;; QUESTION SECTION:
# ;1.8984.977.gs1-eanucc13.id.ods.or.kr. IN NAPTR

# ;; ANSWER SECTION:
# 1.8984.977.gs1-eanucc13.id.ods.or.kr. 86400 IN NAPTR 100 10 "u" "ois+http" "!^.*$!http:#ois1.ods.or.kr/product/df3.xml!" .

# ;; AUTHORITY SECTION:
# 8984.977.gs1-eanucc13.id.ods.or.kr. 86400 IN NS	ns.8984.977.gs1-eanucc13.id.ods.or.kr.

# ;; ADDITIONAL SECTION:
# ns.8984.977.gs1-eanucc13.id.ods.or.kr. 86400 IN	A 202.30.50.182
# ...

}}}