Unlocking Insights: Analyzing Cloudflare Security Logs with AI

Hello, I'm a professional engineer. I've become more familiar with Cloudflare recently, so today I'd like to share another Cloudflare topic.

Cloudflare Security Features

Cloudflare acts as a Web Application Firewall (WAF) between your server and clients. By default, it provides features to configure this WAF and keep logs. It's amazing how much you can do for free!

Recently, Cloudflare has also been focusing on AI-driven bot crawling countermeasures, effectively handling a wide variety of evolving attacks.

For personal blogs operated for free, it becomes an incredibly reliable partner.

About Security Logs

Now, let's get to the main topic!

Where to Check Them

You can check them from the left menu of your desired domain by navigating to 'Security' → 'Analytics'. It looks something like this:↓

Pasted image 20260822155848.png

What Items Can Be Checked

The logs include the following items. You'll likely find most of what you need!

Who and Where From (Origin of Access)

• Country and Network (clientCountryName, clientASNDescription): Reveals the country and network connection (provider or cloud service provider) an access came through! For instance, if access comes from Microsoft (Azure) or Hetzner (a German server company), you can infer, 'Ah, this isn't a regular user's smartphone; it's a bot or crawler running on a server.'

• IP Address (clientIP): Helps identify the attacker's IP.

What Was Targeted and How (Target and Method)

• Targeted Location (clientRequestPath, clientRequestQuery): Helps understand which URL or article on your site (e.g., /hitsuji-makura-review/) was attempted to be viewed, or if an attempt was made to force open a non-existent WordPress backdoor (e.g., /wp-includes/...). This blog also frequently experiences attacks targeting WordPress paths.

• Method (clientRequestHTTPMethodName): Indicates whether it was merely an attempt to view a page (GET) or an attempt to send data and attack (POST).

How Cloudflare Repelled It (Defense Action)

• Action Taken (action): How Cloudflare reacted to that access.

  • block: Completely blocked (e.g., dangerous RCE attacks)

  • managed_challenge: Interposed a browser verification step (suspicious bot countermeasure)

  • link_maze_injected: Injected dummy links to make crawlers get lost

  • skip: Allowed as safe access (e.g., Googlebot)

• Feature Triggered (source): Reveals which defense feature was at work, whether it was the WAF (Web Application Firewall) that prevented it, or Bot Fight Mode that blocked it. This also helps confirm if your custom rules are functioning correctly.

What It's Pretending to Be (User Agent)

• Tool Used (userAgent): Information about what the accessing party claims to be, such as 'I am a Chrome browser' or 'I am Applebot'. By cross-referencing this with the AS number (network information), you can detect things like, 'It claims to be Chrome, but this access is from a data center, so it's a disguised bot.' Cloudflare handles this detection automatically.

Still, Checking Manually Is Tedious!

Right? So, the main theme of this post is to simply throw the JSON file exported using the export function directly to an AI for analysis!

How to Submit

Just 'toss' the JSON file and request something like, 'This is a Cloudflare security log. Please analyze what types of attacks are most frequent, which rules are blocking the most access, etc.' You don't need to worry about personal information being in the logs. (IP addresses have various interpretations depending on the country.)

The Response Received

Below is a slightly edited and summarized version of the analysis results, based on my discretion. This was done using Gemini 3.1 Pro, but other models would certainly work as well.

### 🛡️ Cloudflare Log Analysis Summary

Cloudflare's various defense features are working perfectly, **completely blocking malicious traffic at the edge while cleanly allowing only necessary access.**

1. **Completely blocking WordPress-targeted attacks** (`block`)
        
    - WAF detects and blocks RCE vulnerabilities (CVE-2026-63030) and plugin enumeration attempts. Since this is a Ghost CMS environment, there is no actual damage.     
        
2. **Misleading suspicious exploration bots** (`link_maze_injected`)
    
    - Bots probing for random paths (e.g., `/fzh`) are neutralized by being fed dummy links.
           
3. **Suppressing excessive polling** (`managed_challenge`)
    
    - High-frequency access from podcast apps, etc., is handled by Bot Fight Mode to reduce load. (※ If it's a necessary integration, consider bypass settings.)
           
4. **Smooth passage for legitimate crawlers** (`skip`)
    
    - Search engines like Googlebot and legitimate bots are properly identified and allowed normal access.
        
**Conclusion: Current security settings are highly effective, and a secure state is maintained! ✨**

It became clear that attacks exploiting recently publicized WordPress vulnerabilities are occurring, and that the WAF settings appear to be functioning correctly, at least broadly speaking.

My Thoughts After Trying This

While I did this with Cloudflare logs, I thought it would be incredibly easy and convenient if I could just 'throw' real-world operational logs at it. However, if I were to 'throw' them, I'd need to design the logging with that in mind, so the barrier feels quite high. It might become really exciting if local LLMs are introduced at work...

Analyzing production failures is a race against time, so it seems like a good match for AI.
However, I also feel that its expertise might be limited. It's probably excellent for things like weekly access log analysis, and the implementation hurdle seems lower compared to other operational logs.

In Conclusion

The introduction of AI into the workplace is progressing slowly but surely... It really feels like the scope of an engineer's work is changing.

This article was translated from the original Japanese version (CloudflareのセキュリティログをAIに分析してもらうと面白い) using Gemini API.