Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Security Features Nobody Implements - SANS Internet Storm Center SANS ISC InfoSec Forums

Watch ISC TV. Great for NOCs, SOCs and Living Rooms:

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Security Features Nobody Implements

"Nobody" may be wording it a bit strong. But adoption of these security features is certainly not taking off. If you can think of any features I forgot, then please comment:


That is probably my favorite issue. DNSSEC "fixes" on of the most important protocols. Without it, spoofing is always possible, and in some cases not even terribly hard. I think there are a number of reasons it is not implemented:

  • If you implement it, there is a good chance that you make your domain non-reachable if you mess up. 
  • Implementation is far from straight forward. In particular depositing the key signing keys with your parent zones could be easier.
  • There are few public examples one could point to recently, showing how the failure to provide DNSSEC led to a breach.

So in short: high risk low gain. Insider tip: Some registrars like make it dead simple to enable DNSSEC for zones hosted with them.

HTTPS Key Pinning

Unlike DNSSEC, key pinning is a somewhat new-ish feature, and may not even be supported by all browsers. But while I think you would be hard pressed to find a recent breach that was caused by a site supporting SSLv3 (and we all turned that off. or?), there are multiple examples where certificate authorities issued keys to the wrong party. If anything, our statistics about revoked certs sort of tell the story. But surveys find that less then 1% of sites implement key pinning. I think the issue is similar like with DNSSEC: if you mess up, you take your site down, but there is at least a low perceived risk of actually becoming a victim of a fraudulent certificate. Also, while pretty much any audit tool flags SSLv3 as a big risk, key pinning isn't considered much of a risk at this point.

first-party-only Cookie Attribute

This cookie attribute is supposed to prevent cookies from being sent if javascript is used to send a request, and the javascript wasn't loaded from the site it sends the request to. This can cause numerous issues with cross site request forging, but also helps with the BREACH attack, in particular in its newer implementations. For this one you got a decent excuse: Nobody supports it. Server side configurations do not allow you to enable this feature, and the only client that will support it right now is the yet to be released next version of Google Chrome. Also: the standard is still in draft from and hasn't been approved as an RFC yet

Outbound Firewall Rules

Ok, there are people that implement them, but I still see a lot of networks that don't. Most see a firewall still as a device that blocks inbound connections. Firewalls do that just fine, but the security improvement of inbound filtering is marginal if you only block ports that your server isn't listening on anyway. On the other hand, preventing a server from downloading a backdoor, or connecting to a command and control channel, can be huge. In reality, setting up good outbound filtering can be difficult. Web servers may need to connect to cloudbased webservices, so IPs will change. Anti-Malware tool updates are also often hosten on CDNs, making it difficult to sensibly control them.

Monitoring DNS Logs

Most people watch firewall logs very carefully. Unless you look just at your outbound logs, there is probably little "interesting stuff" that you will find in your firewall logs. Is it really important for you to know that a kid in China just ran nmap against your systems? On the other hand, DNS logs are full of interesting and actionable information, in particular if you are looking at your recursive name servers. You will find infected systems resolving C&C server host names, covert channels and all kinds of good stuff.

Digitally Signed E-Mail (just added this one later...)

"A user clicking on a link in an e-mail or opening and attachment" is probably how 80% or more of recent breach reports start. But still, I see hardly anybody digitally signing e-mail. Sure not an absolute protection, but wouldn't it help if the mail server stripped attachements from e-mails not signed?

Anything else? I considered "using an IDS properly", "not reusing passwords", as other topics to talk about.


Johannes B. Ullrich, Ph.D.

I will be teaching next: Application Security: Securing Web Apps, APIs, and Microservices - SANSFIRE 2022


4511 Posts
ISC Handler
Apr 7th 2016

"Anti-Malware tool updates are also often hosted on CDNs"

Update services need to use consistent, documented DNS names. Modern UTMs allow one to create definitions using DNS lookups, but it's useless if it's not documented.

On the "outbound" firewall filtering side, to my surprise the default rule for outbound traffic in Microsoft Azure from the VM to the Internet is to ALLOW.
Making exfiltration easy...
I would also put HSTS in this category.

3 Posts
Quote:"A user clicking on a link in an e-mail or opening and attachment" is probably how 80% or more of recent breach reports start.

If clicking said link or opening said attachment results in execution of some attacker provided binary or script: whitelisting prevents execution (on Windows; see or for proven solutions).

On *x, permissions of newly created files don't allow execution in the first place; if you want to go a step further: use mount -onoexec /home
yes. HSTS certainly fits. A bit more common then key pinning, but could still be used more. Should CSP be listed too? (I am having issues with CSP myself... which is why I left it off :/)

4511 Posts
ISC Handler
Oh. yes! Windows Software Restriction Policy!! I guess you can tell that I am not a Windows guy :)

4511 Posts
ISC Handler
DNS logs...

I made sure we diligently keep DNS logs, including blocking all out bound DNS to enforce the internal DNS server

But I have never seen/found a tool that makes surveillance practical or easy.

In my mind, DNS logs is for forensic analysis, once you know what to look for... and that is usually when it's too late.

I did find an article recently about an IOC in DNS logs, and I ended up grepping each and every file...

What else is there to do ?

14 Posts
Change Control, Actual change control not enter a change for metrics purposes.
SELinux. The first thing I do when setting up a new Linux server is to set SELinux to permissive so that it doesn't break whatever else I was going to set up on that server. Maybe this is wrong and I just need to learn how to use it correctly, but why such a barrier? If it's adds that much complexity, I don't have much incentive to use it...

1 Posts
The recommendations here are pretty solid.

1) Most places don't utilize egress filtering, and that limits the detective/protective controls in which a FW/IPS could be utilized to address malicious outbound traffic. Also remember that you are going to need to turn on SSL de-inspection on your web-filter, IPS/IDS to ensure that you can peek inside SSL/TLS traffic, because the bad guys are utilizing these mechanism's to exfiltrate data, and contact C2's to download more malicious code.

2) As for DNS log monitoring, the concept is good but the devil is in the details, unless you have a known/updated listing of C2 IP's or DNS addresses monitoring the logs for these requests could be a futile and time expensive exercise. I am not saying with the right automation (Splunk, SEIM, Integration of Threat Intelligence, along with log aggregation from multiple network resources mean you wont find value in what you are looking for (known or suspected evil traffic). What is learned from these tools plus free resources like and others can give the Sec Ops folks a leg up on attackers.

3) Email, it seems that everyone is a bit "click-happy" these days, and sure enough malicious payloads as attachments on emails are a favorite target for nation states, spear phishing and regular phishing. Again AV or and email gateways can be bypassed, so folks its really about controlling code execution on your end-points (AKA Whitelisting), so even if your user does something stupid, your business isn't paying the price for it, and you end up learning more from the attackers than they learn from you.

4) Lastly, if you don't learn from your mistakes you are doomed to repeat them, again security operations and network security in general is alot of design/preparation and ultimately execution when the stuff hits the fan. So learn from your mistakes or what you discovered from your incident response activities and re-evaluate the controls in your business, organizations to ensure that the last successful attack against your computing infrastructure is well understood, a root cause analysis is agreed upon by the technical stake-holders and courses of action are put in place.

Edward Ziots,
IT Audit Management

8 Posts
What about DANE?
As it is dependent of DNSSEC, its plausible that's not deployed much.

About those two, I have a little problem with DNSSEC and DANE.
It further zentralizes the ssl/tls and DNS infrastructure. It is true, that we have to much of CA's, but dropping them all in favour of only one US based CA? I don't know, whether I am comfortable with it.
Also the usage of alternative DNS infrastructures is quite difficult.
1 Posts
Route Authorization Records on BGP routers

SPF Hard-Fail (The majority of configured SPF seems to be set to soft-fail by the source. And most people don't even drop if hard-fail is configured. I see tons of inbound spam & malspam that could be blocked this way.)

John McCash

10 Posts
Quoting Mr.Prontissimo:DNS logs...

I made sure we diligently keep DNS logs, including blocking all out bound DNS to enforce the internal DNS server

But I have never seen/found a tool that makes surveillance practical or easy.

In my mind, DNS logs is for forensic analysis, once you know what to look for... and that is usually when it's too late.

I did find an article recently about an IOC in DNS logs, and I ended up grepping each and every file...

What else is there to do ?

What I would recommend is sending DNS logs to an SIEM such as splunk. What we do is leverage the search feature with a plugin that allows us to alert on high entropy domains such as the randomly generated ones used for C2 communication. To help with this you can download the top 100k sites to filter out "normal" traffic for such an alert. You could also use Bro on an interface that has access to outbound traffic and leverage the Threat intel feeds so Bro can alert on known malicious traffic.
I would add decryption of TLS (I guess we shouldn't be using SSL anymore, right?) traffic both inbound and outbound is crucial now a days.

21 Posts
As far as DNS log monitoring goes:
In my situation (small service provider shop with a handful of name servers), I wrote a script to grep logs daily and email me a digest of sorts - top queries, sources, excessive hits dropped by iptables rules, cache queries denied. It's concise enough I can review it daily in a few minutes, and when you're familiar with normal data it's easy to spot outliers. I've caught some minor infections on internal user and client systems this way. Not practical for larger environments and admittedly not very scientific, but it's another tool in your security layer belt and better than nothing.

5 Posts
I'm relatively new to the security world but I realize DNS has it's security issues. That being said, how do you retain DNS records from your servers?

We have MS AD servers providing DNS and firewall only allowing udp 53 from those out to the DMZ DNS servers and then on to the ISP DNS... If I get a request from a users machine to external 53, it's easy to pinpoint the problem but if I get it from the internal DNS server to a non-dmz dns server, how does one narrow down the culprit? (ie: this morning, I saw one internal DNS server trying to access link-filetransfer.com1 on udp 53... a little alarming)

Thanks for any input!

3 Posts
Anything else?

What about diligent, proactive monitoring of firewall and IDS logs?

5 Posts
How about adding SPF, DKIM, and DMARC to the list?

Also, to continue the DNS activity monitoring discussion, there are service offerings (i.e. OpenDNS) that address many of the difficulties associated with this task (log volume, man power, etc.). Other options include using robust on-premises DNS management solutions like InfoBlox or next-gen firewall features (from Check Point, Palo Alto, etc.) that detect known C&C/malware domains, identify domains created w/ domain generation algorithms, and block DNS tunneling.

2 Posts
Would add Split DNS and no default gateway to internet.

Most orgs miss that low hanging fruit that gives you unique insights.


3 Posts
Ah Monitoring DNS logs...I've asked this question before & didn't get a straight/practical answer: How exactly do this on a Windows (DNS) server/ in a Windows shop? How to turn on DNS logging & how do I know it's working?

51 Posts

Sign Up for Free or Log In to start participating in the conversation!