2

I have a whole bunch of these Bro SSL logs:

ts      uid     id.orig_h       id.orig_p       id.resp_h       id.resp_p       version cipher  server_name     session_id      subject issuer_subject  not_valid_before        not_valid_after last_alert      client_subject  client_issuer_subject cert_hash
1400549762.341095       CxQQ9A2UpLjNzAkPWf      10.1.40.137     60327   212.83.158.5    443     TLSv11  TLS_DHE_RSA_WITH_AES_256_CBC_SHA        www.k5ywywl5lg7xah.com  -       CN=www.ddhy63tk5szqlp.net       CN=www.smszdsv6f.com    1388448000.000000     1409529600.000000       -       -       -       601ac9c406965863aae95863ef08ae08
1400560864.711898       Cc8n8M385BQ1LVUCY       10.1.40.137     47728   107.150.27.198  9001    TLSv11  TLS_DHE_RSA_WITH_AES_256_CBC_SHA        www.psoejykjni.com      -       CN=www.kevl77x7xltanvj7erf.net  CN=www.j4mkawjx2yfsfxpvirx5.com       1372291200.000000       1402876799.000000       -       -       -       aa0ae7dee4dcc97371b37bfc59045e3e

Can anyone explain these connections? They generally last 180-190 seconds. I can't find any documentation on these apparently random domains.

When I first saw these log entries, I thought I had some kind of botnet infection. But I've read that the ports seen (443, 9001, 8181, etc.) are used in Tor. And after I uninstalled the Tor package, I saw no more connections like these.

Improve this question

1 Answer 1

Reset to default
2

These requests are meant to detect DNS resolvers that fake answers for non-existant domains.

This feature was added for relays in Tor 0.1.2.13 (released 2007-04-24):

- Workaround for name servers (like Earthlink's) that hijack failing
  DNS requests and replace the no-such-server answer with a "helpful"
  redirect to an advertising-driven search portal. Also work around
  DNS hijackers who "helpfully" decline to hijack known-invalid
  RFC2606 addresses. Config option "ServerDNSDetectHijacking 0"
  lets you turn it off.

See the relevant manpage entry:

   ServerDNSDetectHijacking 0|1
       When this option is set to 1, we will test periodically to determine whether our
       local nameservers have been configured to hijack failing DNS requests (usually to
       an advertising site). If they are, we will attempt to correct this. This option
       only affects name lookups that your server does on behalf of clients. (Default: 1)
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .