Bad DNS Query for Date & Time

[Michael D. Berger]

On Thu, 01 Sep 2011 07:27:16 +0000, Duncan wrote:

[...]
> I am by no means an expert on this, and don't run CentOS, but from the
> description and what I know (and perhaps what I only think I know =:^P
> ), it /looks/ to me like EITHER something's misconfigured and you're
> getting dbus queries on the IP network as DNS queries, OR you're
> mistaking routine dbus query traffic for DNS.
> 
> Because those weird names look very much like traffic that I'd suppose
> would be dbus based, and dbus traffic does occur over a socket altho at
> least here it's a UNIX socket, not IP (but perhaps it can be IP for
> network transparency? actually, it appears it can according to the dbus-
> daemon (1) manpage).  If they're somehow going out as DNS queries, that
> is quite disturbing indeed, but if instead, you're somehow mistaking
> dbus traffic for DNS, and/or if your wireshark sniffer net is set too
> broadly so it's catching both, that would explain the whole otherwise
> rather disturbing indeed situation.
> 
> Qt has a GUI-based dbus interface browsing tool, qdbusviewer (part of
> the qt-gui package here on Gentoo, likely part of the general qt4
> package on most distros), that you can use to explore a bit, altho I
> don't imagine you'll see any *.desktop filenames there, but maybe you'll
> see something that you can connect with the sniffing you're doing, and
> getting more informed about dbus can't hurt even if it doesn't turn up
> anything related to this.
> 
> You can also try using netstat (and/or checking the config) to see what
> dbus sockets are being used, and see if that corresponds to what
> wireshark is reporting.
> 
> Also, if you have any sort of remote-X desktop stuff going on, it could
> be related to that.
> 
> 
> That's about all I can suggest ATM, but this discussion is rather
> interesting (as in disturbing!) indeed.  I do hope you post what's going
> on when you get to the bottom of this, as the potential of this sort of
> information leakage occurring has security and privacy implications I
> don't particularly like, but at the same time, I find it hard to believe
> it's by design or could be easily overlooked, so something's GOTTA be
> seriously screwed somewhere, either in your config or in your detection
> methods, one of the two, and I really HOPE it's your detection methods,
> because the alternative really IS quite disturbing, to the point I'll
> certainly find it easier to sleep when I know that all this is resolved.

WireShark is showing what look like real DNS queries.  It
is true that I had my interface set to "any", which might
support your suggestion that I am reading the bus, so I
set the interface to eth0.  The problem persists.

But in any case, I also get DNS responses to the bad queries
from external locations such as 151.197.0.38, which ARIN
identifies is a Verizon location, and which I can successfully
ping. Therefore it would appear the DNS queries are real.

Now I ran netstat as you suggested.  There is plenty there that
makes me nervous, for example:
   /var/run/dbus/system-bus-socket
   /tmp/ksocket-root/kdeinit4__0
and much more.  I would not be surprised if some internal socket
were internally confused with eth0.  netstat has numerous options,
and I would be happy to receive suggestions on their use to get
better information.

I agree that something looks "seriously screwed", I most certainly
will post whatever solution I find.  (I note that I could punt and
use iptables -j QUEUE (as I do for other purposes) to parse and
block the bad DNS, but I hope for a better solution.)

Mike.

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.