The other side, the flowers are not open
* DNS Server Detection Method:
This article focuses on the BIND server. The following experiment targets BIND9 service installed on Solaris10 (Version: 9.2.4 ).
The BIND server can detect exceptions in two ways: query to identify exceptions or View CACHE records to identify exceptions.
1) identify exceptions through query
This function requires the BIND log audit function to be enabled. First, run the rndc command to check whether the log audit function is Enabled:
-Bash-3.00 # rndc status
Number of zones: 6
Debug level: 0
Xfers running: 0
Xfers deferred: 0
Soa queries in progress: 0
Query logging is OFF <-- the OFF here indicates that the query log audit function is not enabled yet.
Server is up and running
The next step is to enable the query record:
-Bash-3.00 # rndc querylog <-- this command is a query record switch command
Check the status ^_^ again.
-Bash-3.00 # rndc status
Number of zones: 6
Debug level: 0
Xfers running: 0
Xfers deferred: 0
Soa queries in progress: 0
Query logging is ON <-- ON indicates that query log audit is enabled.
Server is up and running
In this step, edit the BIND configuration file named. conf:
-Bash-3.00 # vi/etc/named. conf
Add the following Audit Configuration content blocks:
++ ++
Logging {
Channel audit_log {
File "named. log" versions 3 size 20 m;
Severity info;
Print-time yes;
Print-category yes;
};
Category default {audit_log ;};
Category general {audit_log ;};
Category security {audit_log ;};
Category config {audit_log ;};
Category resolver {audit_log ;};
Category xfer-in {audit_log ;};
Category xfer-out {audit_log ;};
Category policy {audit_log ;};
Category client {audit_log ;};
Category network {audit_log ;};
Category update {audit_log ;};
Category queries {audit_log ;};
Category lame-servers {audit_log ;};
Category database {audit_log ;};
};
++ ++
* Note: you only need to activate "category queries {audit_log ;};". However, to ensure the comprehensiveness of the log Content...
Finally restart named:
-Bash-3.00 #/etc/init. d/named restart
Now we can view the log directly through tail:
-Bash-3.00 # tail-f/var/named. log
It may contain many query records similar to the following:
Aug 06 02:27:29. 364 queries: client 192.168.20.197 #13939: query: demonalex.3322.org IN
Aug 06 02:27:30. 406 queries: client 192.168.20.197 #13940: query: demonalex.3322.org IN
Aug 06 02:27:30. 994 queries: client 192.168.20.197 #13941: query: demonalex.3322.org IN
Aug 06 02:27:31. 529 queries: client 192.168.20.197 #13942: query: demonalex.3322.org IN
Aug 06 02:27:32. 043 queries: client 192.168.20.197 #13943: query: demonalex.3322.org IN
Aug 06 02:27:32. 554 queries: client 192.168.20.197 #13944: query: demonalex.3322.org IN
Aug 06 02:27:33. 034 queries: client 192.168.20.197 #13945: query: demonalex.3322.org IN
Aug 06 02:27:33. 511 queries: client 192.168.20.197 #13946: query: demonalex.3322.org IN
Aug 06 02:27:33. 972 queries: client 192.168.20.197 #13947: query: demonalex.3322.org IN
Aug 06 02:27:34. 436 queries: client 192.168.20.197 #13948: query: demonalex.3322.org IN
If a large number of records with the same query content and consistent source port ("#" followed by the source port) are found, it may be a precursor to DNS cache poisoning. However
It is not appropriate to draw a conclusion too early. Let's take a look at one of the following methods :)
2) identify exceptions by viewing CACHE records
BIND itself does not provide the function of directly viewing the CACHE, but we can run the rndc command to DUMP the CACHE to DUMP. If you suspect that the BIND server has a DNS Cache
You can check for viruses in the following ways:
-Bash-3.00 # rndc dumpdb
-Bash-3.00 # cat/var/named/named_dump.db
The text file named_dump.db contains the DNS record of the current BIND known, but we mainly focus on the records queried by the client, such:
========================================================== ======================================
; Authanswer
Demonalex.3322.org. 54 A 219.137.123.41
========================================================== ======================================
We can use commands such as nslookup to switch to other DNS servers and query the above records to check whether the BIND has been attacked by cache poisoning.
.
* DNS Client Detection Method:
The client detection method depends on the operating system type. If it is a WINDOWS system, you can set the DNS server in the NIC as 'suspected to be cached
Then, use ipconfig to check the DNS cache of the current host:
Ipconfig/displaydns
Or use commands such as nslookup to perform real-time checks. If the nscd service is not installed by default in UNIX/LINUX systems, DNS slowdown is not available.
Therefore, you can only use commands such as nslookup to perform real-time checks.
* References:
In rhel5, configure DNS server logs written by candon123, the original URL:
Http://candon123.blog.51cto.com/704299/141616
The original URL of "DNS cache poisoning (cache poison) Problem Analysis and Suggestions" written by Ma Futai:
Html> http://hi.baidu.com/zoufutai/blog/item/1b380ffb56ee9f156d22eb0b.html
Yfhe wrote BIND9 detailed log, original URL:
Http://www.chinaunix.net/jh/16/212998.html