メニュー
Hard rule about fixed attack destinations (IP and port). Read this before generating rules or planning attacks.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Generate Snort 3.9.7.0 IDS rules from a natural-language operator intent. Use whenever you need to write a new rule, refine an existing one, or recover from a syntax error.
Reuse Snort rules that already fired in past experiments. ALWAYS consult this skill at the start of every cycle BEFORE writing a new rule. Validated rules are known-good detection patterns persisted per attack_id under data/validated_rules/.
How to produce an evasion variant of a previously successful attack. Use this when request_variant=True on the attacker request.
How to execute the selected attack container on the attacker host and interpret the result.
How to map an operator intent to one of the attacks discovered on the attacker host. Use this before calling execute_attack.
Rule-generation refinement playbook for MQTT Brute Force — credential brute force against MQTT brokers on TCP port 1883 using dictionary attacks. Load when the operator intent maps to attack_id mqtt-bruteforce.
| name | attack-destinations |
| description | Hard rule about fixed attack destinations (IP and port). Read this before generating rules or planning attacks. |
The Rules Farmer testbed exposes target services at well-known addresses per protocol family.
These are configured in config.yaml under attack_destinations and resolved by intent
preprocessing before the agents are invoked.
| Family | IP | Port |
|---|---|---|
| MQTT | (from config: attack_destinations.mqtt.ip) | 1883 |
| XRCE-DDS | (from config: attack_destinations.xrce.ip) | 8888 |
The Orchestrator detects the family by scanning the intent for keywords (mqtt, xrce, dds,
rtps) and injects the resolved {ip, port} into the prompt as fixed_destination and into the
AttackerRequest as fixed_destination_ip/fixed_destination_port.
When you write the Snort rule, the destination part of the rule header MUST match the fixed destination:
alert <proto> any any -> <fixed_destination_ip> <fixed_destination_port> (... msg ...; sid:0; rev:1;)
Never invent a different IP or port. Never use any when a concrete fixed value is available.
When you select an attack with port (or target_ip, target, host, broker) as a required
argument, you MUST set that argument to the fixed value from the request:
required_arguments contains target_ip → use fixed_destination_ip.required_arguments contains port, target_port, or broker_port → use fixed_destination_port.When request_variant=True, mutate ONLY the other parameters (rate, payload size, source port,
timing, count, encoding). The destination IP and port stay constant across the base attack and
every variant.
If the agent mutates the destination, the attack lands somewhere other than the testbed's target service. The IDS sees nothing because no traffic reaches the protected port, and the experiment silently looks like a successful detection failure when in reality the attack never happened. This skill exists to prevent that whole class of silent bugs.
If fixed_destination is null in the prompt (the intent did not match a known family
keyword), fall back to the destination IP and port mentioned in the intent text itself. Log a
warning. Prefer asking the operator to clarify rather than guessing.