All posts by Stanley Chiang

Analyze any URL safely using the Cloudflare Radar URL Scanner

Post Syndicated from Stanley Chiang original https://blog.cloudflare.com/radar-url-scanner-early-access/

Analyze any URL safely using the Cloudflare Radar URL Scanner

Analyze any URL safely using the Cloudflare Radar URL Scanner

One of the first steps in an information security investigation is to gather as much context as possible. But compiling that information can become a sprawling task.

Cloudflare is excited to announce early access to a new, free tool — the Radar URL Scanner. Provide us a URL, and our scanner will compile a report containing a myriad of technical details: a phishing scan, SSL certificate data, HTTP request and response data, page performance data, DNS records, whether cookies are set to secure and HttpOnly, what technologies and libraries the page uses, and more.

Analyze any URL safely using the Cloudflare Radar URL Scanner

Let’s walk through a report on John Graham-Cumming’s blog as an example. Conveniently, all reports generated will be publicly accessible.

The first page is the summary tab, and you’ll see we’ve broken all the available data into the following categories: Security, Cookies, Network, Technology, DOM, and Performance. It’s a lot of content so we will jump through some highlights.

In the Summary tab itself, you’ll notice the submitted URL was https://blog.jgc.org. If we had received a URL short link, the scanner would have followed the redirects and generated a report for the final URL.

Analyze any URL safely using the Cloudflare Radar URL Scanner

The Security tab presents information to help determine whether a page is safe to visit with a phishing and certificates section. In our blog example, the report confirms the link we provided is not a phishing link, but there could easily be phishing scams trying to harvest personal information. We’re excited to enable wider access to our security infrastructure with this free tool.

Analyze any URL safely using the Cloudflare Radar URL Scanner

The Cookies tab can indicate how privacy friendly a website is to its users. We show all the cookies set and their attribute values to do this. In this report, the blog loaded 2 cookies. There’s the Secure flag. You’ll want that set to true as often as possible because this means the cookie may only be transmitted over HTTPS, preventing it from being observed by unauthorized parties. Additionally, cookies set to HttpOnly will be inaccessible to the JavaScript API, potentially mitigating XSS attacks from third-party scripts.

Analyze any URL safely using the Cloudflare Radar URL Scanner

The Technology tab enumerates the technologies, frameworks, libraries, etc that are used to power the page being scanned. Understanding the technology stack of a page can be very useful for when there are outages in a particular service, when exploits in popular libraries are discovered, or simply to understand what tools are most popular in the industry. John’s blog appears to use 7 different technologies including Google AdSense, Blogger, and Cloudflare.

Analyze any URL safely using the Cloudflare Radar URL Scanner

The Network tab shows all the HTTP transactions that occur on the page as well as the hostname’s associated DNS records. HTTP transactions are the requests and responses the page makes to load all its content. This tells engineers where the website is going to load its content. Our report of John’s blog shows a total of 82 requests.

Analyze any URL safely using the Cloudflare Radar URL Scanner

The tab also contains DNS records which are a great way to understand more about the fundamentals of the page. And of course, we at Cloudflare are big advocates for enabling DNSSEC.

Analyze any URL safely using the Cloudflare Radar URL Scanner

The DOM (Document Object Model) tab conveniently collates common information you may be looking for from within the page. We grouped together lists of all hyperlinks and global JavaScript variables. Additionally, we provide the raw HTML of the page for you to further analyze. Our report shows the blog’s landing page has 104 hyperlinks going off to other websites.

Analyze any URL safely using the Cloudflare Radar URL Scanner

The Performance tab presents a breakdown of the time it takes for the website to load. It’s not enough for a page to be secure for users. It must also be usable, and load speeds are a big factor in the overall experience. That’s why we’ve also included Performance Navigation Timing metrics alongside our more security and privacy oriented tabs.

Analyze any URL safely using the Cloudflare Radar URL Scanner

Under the hood, one of the great things about this tool is that the underlying scanning technology uses Cloudflare’s homegrown Workers Browser Rendering API to run all our headless scans. You can follow that link to join the waitlist and try it out for yourself.

In the future, we envision adding features to our scanner to complement the ones from this launch: API endpoints so you don’t need to rely on a GUI, private scans for more sensitive or recurring reports, and also security recommendations with integrations with the Cloudflare Security Center. And since this is a Radar product, not only can users expect the data generated to further enhance our security threat modeling, they can also look forward to us providing back insights and visualizations from the aggregate trends we observe.

The Radar URL Scanner tool’s journey to helping make the Internet more transparent and secure has only just begun, but we’re excited for you all to try it out here. If you have any questions or would like to discuss enterprise level features on your wishlist, feel free to reach out via Twitter at @CloudflareRadar or email us at [email protected].

Dig through SERVFAILs with EDE

Post Syndicated from Stanley Chiang original https://blog.cloudflare.com/dig-through-servfails-with-ede/

Dig through SERVFAILs with EDE

Dig through SERVFAILs with EDE

It can be frustrating to get errors (SERVFAIL response codes) returned from your DNS queries. It can be even more frustrating if you don’t get enough information to understand why the error is occurring or what to do next. That’s why back in 2020, we launched support for Extended DNS Error (EDE) Codes to 1.1.1.1.

As a quick refresher, EDE codes are a proposed IETF standard enabled by the Extension Mechanisms for DNS (EDNS) spec. The codes return extra information about DNS or DNSSEC issues without touching the RCODE so that debugging is easier.

Now we’re happy to announce we will return more error code types and include additional helpful information to further improve your debugging experience. Let’s run through some examples of how these error codes can help you better understand the issues you may face.

To try for yourself, you’ll need to run the dig or kdig command in the terminal. For dig, please ensure you have v9.11.20 or above. If you are on macOS 12.1, by default you only have dig 9.10.6. Install an updated version of BIND to fix that.

Let’s start with the output of an example dig command without EDE support.

% dig @1.1.1.1 dnssec-failed.org +noedns

; <<>> DiG 9.18.0 <<>> @1.1.1.1 dnssec-failed.org +noedns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8054
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dnssec-failed.org.		IN	A

;; Query time: 23 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Thu Mar 17 10:12:57 PDT 2022
;; MSG SIZE  rcvd: 35

In the output above, we tried to do DNSSEC validation on dnssec-failed.org. It returns a SERVFAIL, but we don’t have context as to why.

Now let’s try that again with 1.1.1.1’s EDE support.

% dig @1.1.1.1 dnssec-failed.org +dnssec

; <<>> DiG 9.18.0 <<>> @1.1.1.1 dnssec-failed.org +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34492
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)
;; QUESTION SECTION:
;dnssec-failed.org.		IN	A

;; Query time: 15 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Fri Mar 04 12:53:45 PST 2022
;; MSG SIZE  rcvd: 103

We can see there is still a SERVFAIL. However, this time there is also an EDE Code 9 which stands for “DNSKey Missing”. Accompanying that, we also have additional information saying “no SEP matching the DS found” for dnssec-failed.org. That’s better!

Another nifty feature is that we will return multiple errors when appropriate, so you can debug each one separately. In the example below, we returned a SERVFAIL with three different error codes: “Unsupported DNSKEY Algorithm”, “No Reachable Authority”, and “Network Error”.

dig @1.1.1.1 [domain] +dnssec

; <<>> DiG 9.18.0 <<>> @1.1.1.1 [domain] +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55957
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 1 (Unsupported DNSKEY Algorithm): (no supported DNSKEY algorithm for [domain].)
; EDE: 22 (No Reachable Authority): (at delegation [domain].)
; EDE: 23 (Network Error): (135.181.58.79:53 rcode=REFUSED for [domain] A)
;; QUESTION SECTION:
;[domain].		IN	A

;; Query time: 1197 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Mar 02 13:41:30 PST 2022
;; MSG SIZE  rcvd: 202

Here’s a list of the additional codes we now support:

Error Code Number Error Code Name
1 Unsupported DNSKEY Algorithm
2 Unsupported DS Digest Type
5 DNSSEC Indeterminate
7 Signature Expired
8 Signature Not Yet Valid
9 DNSKEY Missing
10 RRSIGs Missing
11 No Zone Key Bit Set
12 NSEC Missing

We have documented all the error codes we currently support with additional information you may find helpful. Refer to our dev docs for more information.