Metricon: Name Server Log Data

Speakers: Fruhwirth, Proschinger, Lendl, Savola

“On the use of name server log data as input for security measurements”

 

CERT.at ERT

  • coordinate sec efforts & inc resp for IT sec prblms on a national level in Austria
  • constituted of IT company security teams and local CERTs

 

Why name server data?

  • CERT.at is mandated to inform and facilitate comm.
  • DNS data is a rich data source, easily obtainable
  • DNS logs usefulness increased if you can get them from the largest number of users

 

DNS 101

  • gTLDs & ccTLDs
  • ccTLDs have local policies
  • Passive collection will enable determination of IP addr changes, NS changes & domains/IP but impracticable to have sensors everywhere

 

DNS Reporting View

DNS view is a matrix for stakeholders and security chain/measurements

Vuln CERT | Large Co | SME | User

Exp
Threat
Risk
Countermasure
Incident

third dimension – field of view – DNS hierarchy changes view picture

 

4 example use cases CERT.at worked on:

Aurora

  • CnC server was based on dynamic DNS

/me: their matrix analysis makes it easy to see where DNS logs provided insigne to signs of vuln, severity of threat per stakeholder, whether it was something an org could have identified on their own (data source)

 

Conficker

Pseudorandom domains B-250 regs/day, C-450 .at domains/day

Aconet CERT runs nameservers and a sinkhole

CERT.at uses the DNS data to generate warnings

/me: the table view shows that you can both detect with DNS and deploy countermeasures with DNS (and what org can do what)

 

Kaminsky DNS Bug

CERT.at used logs to score resolvers

score = port changes/queries & ports/min  (higher score == better)

they were able to see how quickly servers were patched (very interesting view)

/me: the chart is a bit hard to read but it shows the difficulty of not having a larger view of DNS to help detect subtle issues like this one

 

Stuxnet

CnC attempts visible in DNS logs

/me: the chart shows that if you knew the domains, you could have detected in your own network

 

There are blind points: lack of visibility in top-down view; DNS can’t really show severity

info exchange on signs of exploited vulns; focus on info exchange of incidents

[side-talk: how do we incent folks to share data… “ask nicely!”…]

[side-talk: what % did not know who CERT.at was? 80% of crit infra knew; highly dependent on sector; CERT.at deliberately hired across sectors to help promote /me: good q]

[side-talk: good discussion on CERT practices; how they detect and then how they engage constituents]

Cover image from Data-Driven Security
Amazon Author Page

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.