CyberSecurity Project: Transparent Filtering Bridge (+ Extras) 4.0

Updated on
ThriveDX login error screen

After a brief delay caused by ChatGPT session cookies being corrupted, we're getting back on track with the Transparent Filtering Bridge project.

This week, we're going to try to make Suricata IPS rules with AI, namely ChatGPT (whatever model free users get to use as 9/25/2024) and Bing Copilot. (As as aside, it's kind of annoying that ChatGPT sometimes lets free users have access to higher quality models, but doesn't explicitly notify the user which model is being used.)

Since Suricata caused the OPNsense install to crash (possibly because someone set the default stat logging to 8 seconds), we can't test in OPNsense itself. But I still retain ThriveDX access, so let's see if I can get the rules to run on one of their VMs running Suricata. (This is far from certain, given how janky their VMs/internet connections are.)

The Prompts

As before, the first step of the test is to come up with two prompts to feed into both AI.

Why two? Well, the first is going to be a simple directory traversal detector, looking for ../ or  %2e%2e%2f:

Make me a Suricata IPS rule that does the following:

  • Detects incoming connections containing ../ or %2e%2e%2f.
  • Blocks the connection.
  • Generates a log stating "Detected directory traversal attempt from <source IP> to <destination IP> at <time>".

The second is going to be more complex and based on a TrendMicro report on TeamTNT's credential theft techniques:

Make me a Suricata IPS rule that does the following:

  • Detects incoming connections containing "userfile=@/etc/passwd" or "userfile=@/etc/hosts".
  • Blocks the connection.
  • Generates a log stating "Blocked potential SSH credential theft attack from <source IP> on <destination IP> at <time>."

(Annoyingly, there are no Indicators of Compromise (IoTs) or code examples for the recently revealed Ryzen vulnerability, which was something I wanted to craft rules for.)

ChatGPT - Prompt 1

Here's what ChatGPT generated:

Steps:

  1. Create the rule:

    • Suricata rules generally follow this structure:
    • action protocol src_ip src_port direction dst_ip dst_port (rule_options;)
    • For your case, you'll use alert action (to generate a log) combined with drop action (to block the connection).
    • We'll detect ../ and %2e%2e%2f in the URI.

  2. Rule Components:

    • alert and drop: Both will be used to detect and block.
    • http_uri: To inspect the HTTP request URI.
    • content: To look for specific strings (../ or %2e%2e%2f).
    • msg: To specify a custom log message.
    • sid: Rule identifier (must be unique).
    • flow: Specifies the direction (from the client to the server).
    • metadata: Includes information about the rule type (IPS) and severity.
    • logto: To specify log output.

  3. Example Suricata Rule:

    1. alert http any any -> any any (msg:"Detected directory traversal attempt from <source IP> to <destination IP> at <time>"; content:"../"; http_uri; nocase; sid:1000001; rev:1; logto:"traversal.log";)
    2. alert http any any -> any any (msg:"Detected directory traversal attempt from <source IP> to <destination IP> at <time>"; content:"%2e%2e%2f"; http_uri; nocase; sid:1000002; rev:1; logto:"traversal.log";)
    3. drop http any any -> any any (msg:"Blocked directory traversal attempt"; content:"../"; http_uri; nocase; sid:1000003; rev:1;)
    4. drop http any any -> any any (msg:"Blocked directory traversal attempt"; content:"%2e%2e%2f"; http_uri; nocase; sid:1000004; rev:1;)

Bing Copilot - Prompt 1

Here's Bing Copilot's output:

Sure! Here’s a Suricata IPS rule that meets your requirements:

alert http any any -> any any (msg:"Detected directory traversal attempt from <source IP> to <destination IP> at <time>"; content:"../"; nocase; http_uri; sid:1000001; rev:1;)
alert http any any -> any any (msg:"Detected directory traversal attempt from <source IP> to <destination IP> at <time>"; content:"%2e%2e%2f"; nocase; http_uri; sid:1000002; rev:1;)
drop http any any -> any any (msg:"Blocking directory traversal attempt"; content:"../"; nocase; http_uri; sid:1000003; rev:1;)
drop http any any -> any any (msg:"Blocking directory traversal attempt"; content:"%2e%2e%2f"; nocase; http_uri; sid:1000004; rev:1;)

This rule does the following:

  1. Detects incoming connections containing ../ or %2e%2e%2f.
  2. Blocks the connection if such patterns are detected.
  3. Generates a log with the message “Detected directory traversal attempt from <source IP> to <destination IP> at <time>”.

Feel free to adjust the sid (Signature ID) and rev (Revision) numbers as needed. Let me know if you need any further customization!

ChatGPT - Prompt 2

Now we move onto the second prompt:

Steps:

  1. Understand the context:

    • We need to detect specific strings that might indicate a file inclusion attack.
    • The rule will look for these strings in the HTTP request body or URL parameters.
    • Suricata will generate a log and block the connection.

  2. Rule Structure:

    • Use alert (to generate logs) and drop (to block the connection).
    • Detect the strings userfile=@/etc/passwd and userfile=@/etc/hosts.
    • Use the content option for string matching, http_client_body for detecting the attack within the HTTP request, and nocase to make it case-insensitive.

  3. Example Suricata Rules:

  4. alert http any any -> any any (msg:"Blocked potential SSH credential theft attack from <source IP> on <destination IP> at <time>"; content:"userfile=@/etc/passwd"; http_client_body; nocase; sid:2000001; rev:1;)
  5. alert http any any -> any any (msg:"Blocked potential SSH credential theft attack from <source IP> on <destination IP> at <time>"; content:"userfile=@/etc/hosts"; http_client_body; nocase; sid:2000002; rev:1;)
  6. drop http any any -> any any (msg:"Blocked potential SSH credential theft attack from <source IP> on <destination IP> at <time>"; content:"userfile=@/etc/passwd"; http_client_body; nocase; sid:2000003; rev:1;)
  7. drop http any any -> any any (msg:"Blocked potential SSH credential theft attack from <source IP> on <destination IP> at <time>"; content:"userfile=@/etc/hosts"; http_client_body; nocase; sid:2000004; rev:1;)

Bing Copilot - Prompt 2

Now we move to Bing Copilot:

Here’s a Suricata IPS rule that meets your requirements:

alert http any any -> any any (msg:"Blocked potential SSH credential theft attack from <source IP> on <destination IP> at <time>"; content:"userfile=@/etc/passwd"; nocase; http_uri; sid:1000005; rev:1;)
alert http any any -> any any (msg:"Blocked potential SSH credential theft attack from <source IP> on <destination IP> at <time>"; content:"userfile=@/etc/hosts"; nocase; http_uri; sid:1000006; rev:1;)
drop http any any -> any any (msg:"Blocking potential SSH credential theft attack"; content:"userfile=@/etc/passwd"; nocase; http_uri; sid:1000007; rev:1;)
drop http any any -> any any (msg:"Blocking potential SSH credential theft attack"; content:"userfile=@/etc/hosts"; nocase; http_uri; sid:1000008; rev:1;)

This rule does the following:

  1. Detects incoming connections containing “userfile=@/etc/passwd” or “userfile=@/etc/hosts”.
  2. Blocks the connection if such patterns are detected.
  3. Generates a log with the message “Blocked potential SSH credential theft attack from <source IP> on <destination IP> at <time>”.

Feel free to adjust the sid (Signature ID) and rev (Revision) numbers as needed. Let me know if you need any further customization!

Comparing and Contrasting:

There's some interesting tidbits that came out of this:

  • ChatGPT took the longest time between entering the first prompt and generating a response.
  • ChatGPT's responses provide more information about how Suricata rules operate and how to craft them on your own, making it a better resource for beginner/occassional/intermediate users.
  • None of the ChatGPT responses provided the full set of protocols supported by Suricata, which means referencing the documentation or creating a prompt specifically about that is required to obtain that information.
  • Bing Copilot's responses are much more to the point, making them better for experienced users/people under time pressure.
  • I suspect that using two different prompts in the same session causes some form of response contamination due to improper context cleanup. Both AI seem to default to HTTP being the protocol of choice, which makes sense for the first prompt, but is flat out wrong for the second prompt.*
  • There is a lingering question about the available data on Suricata for training/Retrieval Augmented Generation. If most publicly accessible data is for HTTP Suricata rules, that might bias the results towards generating HTTP rules.

*To be fair, I did not provide either AI with any information regarding the protocol to use for the second prompt. That was intentional, as part of the testing process.

The Unexpected Roadblock

ThriveDX login error screen.

To my lack of surprise, ThriveDX let me down when I needed it, right when a hurricane passed by my part of Florida.

However, OPNsense released a new version with a wide range of updates, so perhaps I can make some progress by redoing the install from scratch...

Related posts