DNS-rebind attack detected - who asks for it?

[roghan]

Hi All,
it is my first post here, and I'm new to pfSense  :). I have seen a lot of DNS-rebind attacks since a week or more. The system logs show these lines (hundreds of lines!):

Jul 1 11:57:50 dnsmasq[62768]: possible DNS-rebind attack detected: tccapis.com
Jul 1 11:57:50 dnsmasq[62768]: possible DNS-rebind attack detected: tccapis.com
Jul 1 11:51:46 dnsmasq[62768]: possible DNS-rebind attack detected: tccapis.com
Jul 1 11:51:46 dnsmasq[62768]: possible DNS-rebind attack detected: tccapis.com
Jul 1 11:51:45 dnsmasq[62768]: possible DNS-rebind attack detected: tccapis.com
…

I don't know this tccapis.com site/url, and I see this name is resolved in 192.168.1.1 (and so the pfSense firewall blocks it).

I also read other related posts in this forum, but I'm wondering if it is possible to find out who is asking for this site (I mean I want to find out which client or server machine executes these requests). Is it possible?

Thanks!!

p.s.:I see the pfSense version is 2.0.1-RELEASE (amd64).

[johnpoz]

Yes one of their name servers resolves A record for that domain to 192.168.1.1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tccapis.com.                  IN      A

;; ANSWER SECTION:
tccapis.com.            3600    IN      A      192.168.1.1

;; AUTHORITY SECTION:
tccapis.com.            3600    IN      NS      ns2.x-ns.com.
tccapis.com.            3600    IN      NS      ns1.x-ns.com.

;; ADDITIONAL SECTION:
ns1.x-ns.com.          43200  IN      A      95.110.250.7
ns2.x-ns.com.          43200  IN      A      95.110.250.8

If your wanting to know who is looking for it - just do a sniff on pfsense for dns traffic on your lan.  Or great tool for watching dns traffic is http://dns.measurement-factory.com/tools/dnstop/

You can install it on pfsense with simple

pkg_add -r dnstop

[2.1.4-RELEASE][root@pfsense]/root(4): dnstop
usage: dnstop [opts] netdevice|savefile
        -4      Count IPv4 packets
        -6      Count IPv6 packets
        -Q      Count queries
        -R      Count responses
        -a      Anonymize IP Addrs
        -b expr BPF program code
        -i addr Ignore this source IP address
        -n name Count only messages in this domain
        -p      Don't put interface in promiscuous mode
        -P      Print "progress" messages in non-interactive mode
        -r      Redraw interval, in seconds
        -l N    Enable domain stats up to N components
        -f      filter-name

Available filters:
        unknown-tlds
        A-for-A
        rfc1918-ptr
        refused

for example, I set a filter to only look for this domain on pfsense, on my lan interface

[2.1.4-RELEASE][root@pfsense]/root(8): dnstop -n tccapis.com vmx3f1

Then I did something that would attempt to resolve that - and there you go I see the IP of who looked for it - see attachement

[roghan]

@johnpoz:

Yes one of their name servers resolves A record for that domain to 192.168.1.1
[…]

Thanks a lot for your answer  :D!!
I tried to follow your instructions, but I got this error:

pkg_add -r dnstop

Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.1-release/Latest/dnstop.tbz: File unavailable (e.g., file not found, no access)
pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.1-release/Latest/dnstop.tbz' by URL

So, I newly set the repository and I tried to install dnstop (I found only dnstop-20090128.tbz).:

setenv PACKAGESITE ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/amd64/8.1-RELEASE/packages/All/

pkg_add -r dnstop-20090128

Fetching ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/amd64/8.1-RELEASE/packages/All/dnstop-20090128.tbz… Done.

I tried also:

pkg_add -r http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/amd64/8.1-RELEASE/packages/All/dnstop-20090128.tbz

Fetching http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/amd64/8.1-RELEASE/packages/All/dnstop-20090128.tbz... Done.
pkg_add: package 'dnstop-20090128' or its older version already installed

But I'm not able to find the dnstop tool:

dnstop

dnstop: Command not found.

dnstop-20090128

dnstop-20090128: Command not found.

What can I do?

[johnpoz]

not sure why you would fetch 8.1? current pfsense is based off 8.3.. I show the amd64 would be here for 8.3 - Oh, just noticed your not current –> why are you running such an old version of pfsense?  Current is 2.1.4 you said you were new to pfsense, would assume you would install current.

ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.3-release/All/dnstop-20110502.tbz

did you run rehash after the install?  I show the path of the file after installed here on i386...

pkg_info -L dnstop-20110502
Information for dnstop-20110502:

Files:
/usr/local/bin/dnstop
/usr/local/man/man8/dnstop.8.gz

[roghan]

Yes, the pfsense is an old version  :(. It's a brand new job in this company (I work here since 2 weeks) and there are a lot of old and shaky devices. So, it isn't possible to upgrade anything since in the next weeks there is a plan of a total renewal  8).
Anyway, yesterday I tried to use the tcpdump command on the pfsense (rather than dnstop) and it worked greatly:

tcpdump -i interfaceName -vvv -s 0 -l -n port 53

This showed me the "attacker":

192.168.xxx.xxx.62253 > 10.10.xxx.xxx.53: [udp sum ok] 38280+ A? tccapis.com. (29)
10.10.xxx.xxx.53 > 192.168.xxx.xxx.62253: [udp sum ok] 38280 q: A? tccapis.com. 0/0/0 (29)

All the requests come from an employee's iPhone! Apple…..... They are dozens and dozens each day.
Today I want to investigate deeply on it...

[johnpoz]

yup sniff work too..  Great..  Let us know what you figure out..

[kpa]

It might as well turn out to be a false positive. One good reason to hand out RFC1918 addresses on public DNS is to allow VPN users to use public DNS resolvers for name resolution while connected on the VPN.

[roghan]

@johnpoz:

yup sniff work too..  Great..  Let us know what you figure out..

I solved the issue  :). It was more simple than I expected.

As I said, I found out that the "attacker" was an iPhone of an employee. This apple had a lot of web pages opened through Safari, and I just had to close all of them to stop the DNS-rebind attack notifications. Maybe some web-page had a malformed-script or something wrong that caused those requests.

Solved. :D

[johnpoz]

"allow VPN users to use public DNS resolvers for name resolution while connected on the VPN."

Not a very good reason - why would vpn users not use internal dns?  I can see at no point to wanting vpn users using external dns.  Doing so means that your allowing split tunnel - which depending who you talk to is bad security practice.  I have to assume vpn users are connected to your vpn for a reason, why would they need to resolve internal resources from public..

Work devices should be forced tunnel if you ask me, so that filtering can be performed.  Its not the users asset, it is the company - if they want to surf the web use their own resources and shouldn't be connected to the vpn in the first place.

You can debate security issues of split tunneling for sure - if users always need to resolve fqdn to internal IP, might as well have it in the host file on the box ;)

To me putting rfc1918 ips in your public dns is just lazy or lack of understanding of how to have your devices properly resolve your internal devices be it forward or reverse type queries.

[kpa]

Because DNS over the VPN tunnel doesn't always work as expected, especially with Windows clients where any number of factors that are not that well documented can affect the order of in which the configured DNS resolvers are tried. Putting the private addresses in your public DNS will always work at least.

[jimp]

For future reference, if you need to track down who is making a specific query, you need only put "log-queries" into the DNS Forwarder advanced options. Then the resolver log will contain all DNS queries along with the IP addresses which made the requests, for example:

 	dnsmasq[19543]: query[AAAA] packages.pfsense.org from 127.0.0.1