DnsSpoof forges replies to arbitrary DNS address / pointer queries on the internal LAN. This is useful in bypassing host name based access controls, or in implementing a variety of efficient network controls.
In a corperate network DnsSpoof can be used to efficiently point clients to internal machines instead on externally mounted ones. Or, it can be used to keep clients from going to certain host names that are not allowed by policy rules.
A really good use of DnsSpoof is to redirect lan clients to an internal server through a DNS query instead of using routing or firewall rules. Lets say you have a web server and it has two interfaces. Once interface is on the outside of the LAN called web.com and one interface is on the inside called web.internal.lan. The ip for web.internal.lan is 10.10.10.1. Many of your users just want to use the external name web.com because it is easy to type and they do not have to remember to use one name on the inside and on on the outside. This is where DnsSpoof comes in. You want your user to use the internal name because the LAN is a lot faster than the external network or you might have to pay for the bandwidth.
You can use the DnsSpoof damon to intercept queries from the lan clients for web.com and respond with the ip address for web.internal.lan (10.10.10.1). The best part is DnsSpoof will only intercept host names you configure the daemon to look for. All other queries go right to your internal DNS server like normal.
You could also setup DnsSpoof to stop clients from going to any hostname you choose. Lets say you have a policy that restricts your users from going to monster.com for one reason or another. You could setup a script to resolve all of the ip addresses accociated with the hostname, but those may change unexpectedly. You can simply tell DnsSpoof to respond to any query to monster.com with another ip like localhost.
First, you must install DnsSpoof on the dns server. DnsSpoof is part of a collection in the "dsniff" collection. dsniff is a set of tools for network auditing and penetration testing. dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy passively monitor a network for interesting data (passwords, e-mail, files, etc.). arpspoof, dnsspoof, and macof facilitate the interception of network traffic normally unavailable to an attacker (e.g, due to layer-2 switching). sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI.
You should be able to find packages for "dsniff" for your distribution or you can simply download the dsniff source from monkey.org.
Once dsniff is in place and dnsspoof is installed we need to setup the config file that will tell the daemon how to act. In the following /etc/dnsspoof.conf file you can see the two examples we talked about before. We are going to send any query for web.com to the internal web server interface 10.10.10.1 and monster.com to localhost (127.0.0.1). You can have as many listing as you need.
Here is an example /etc/dnsspoof.conf configuration file. When dnsspoof sees the host name listed here it will send the ip address back to the client.
## moneyslow.com - /etc/dnsspoof.conf 10.10.10.1 web.com 127.0.0.1 monster.com
The dnsspoof deamon will be running on the internal dns server in our example. The DNS server, bind for example, is listening on port 53. DnsSpoof does not listen on a port, but instead listens to the traffic coming in on the currently used bind port 53. If a query comes in that dnsspoof needs to respond to it intercepts the stream and responds to the LAN client with the answer by itself. Bind is never included in the conversation.
To start DnsSpoof use the following line. You can also put this line into the /etc/rc.local to start the daemon on boot.
/usr/sbin/dnsspoof -f /etc/dnsspoof.conf
What is the error, "webmitm: bind: address already in use" ?webmitm stands for "web man in the middle". webmitm transparently proxies and sniffs HTTP / HTTPS traffic redirected by dnsspoof(8), capturing most "secure" SSL-encrypted webmail logins and form submissions. webmitm may be trying to bind to the same port as another daemon.
Can you tell me more about DNS Spoofing?
Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. Clients need to be cautious in assuming the continuing validity of an IP number/DNS name association.
In particular, HTTP clients SHOULD rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous host name lookups. Many platforms already can cache host name lookups locally when appropriate, and they SHOULD be configured to do so. These lookups should be cached, however, only when the TTL (Time To Live) information reported by the name server makes it likely that the cached information will remain useful.
If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS.
If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes. As network renumbering is expected to become increasingly common, the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability.
This requirement also improves the load-balancing behavior of clients for replicated servers using the same DNS name and reduces the likelihood of a user's experiencing failure in accessing sites which use that strategy.
How about more information about the dsniff suite?
Check out the Frequently Asked Questions on monkey.org.