+
+ {item.title}
+{item.body}
+
+
+
+ For founders shipping with AI
+
+ + Your app shipped in a weekend. Your server is under attack since Monday. +
++ The most common way to ship a product now: an idea on Friday, an app built + with AI over the weekend, live on a server by Monday. The code arrives in + days. What usually does not arrive with it is the boring layer: log + monitoring, a ban list for scanners, a plan for which interpreter versions + run where. Those were never the fun parts. They were what the security + review, the ops person, or three painful weeks used to add. +
++ That gap is where the early attacks land. Not because AI writes worse code, + but because the box serving your app is public from hour one and nobody is + reading its logs. This is what that traffic looks like, and how to cover it + without writing a single detection rule. +
+
+
+ Install StackdogApp
+
+
+ What early attacks look like
+
+ New deployments get three kinds of attention
+
+ {earlyAttacks.map((item) => {
+ const Icon = item.icon;
+ return (
+
+
+ );
+ })}
+
+ + A favorite illustration of the gap: one harmless 24 MB form field sent to a + stock php:8.3-apache container, no exploit code anywhere in it, and the error + log recorded PHP dying in "Unknown on line 0" while parsing the + request. A weekend app has forms, default memory limits, and nothing watching + that line. +
+
+ Install the boring layer
+
+ Five minutes, no detection rules to write
++ StackdogApp ships the detections instead of asking you to write them. Install + it before you announce the product. +
+
+
+
+
+
+
+
+ Two things matter in the settings. Web roots are where shells get dropped,
+ so list every docroot you serve. And bans are read from log lines, so host
+ web server logs must be listed in STACKDOG_LOG_SOURCES;
+ container logs are discovered on their own.
+
+ Set the ban policy before you need it. Five flagged requests from one + address within five minutes is a ban; one stray request never bans anyone. + Bans lift by themselves after 30 minutes, so a mistake costs half an hour, + not a customer. Put anything in the allowlist whose ban would take you + down: office and VPN addresses, uptime monitors, load balancers. Private + and local addresses are never banned in the first place. +
++ Then verify: drop a harmless test file into a web root, watch the alert + arrive, remove it. If nothing arrives, check the log paths first. The full + walkthrough lives in the{' '} + + quick start + + . +
+
+ What it turns on for you
+
+ The detection layer, already written
+
+ {detections.map((item) => (
+
+
+
+ ))}
+ {item.title}
+{item.body}
++ Deeper detail for each of these:{' '} + + PHP shell detection + {' '} + and{' '} + + how the ban layer compares to fail2ban + + . +
+
+ Honest limits
+
+ What it does not do
++ A security tool that oversells changes what you do, and that is how incidents + happen. So, plainly: +
+
+ {limits.map((limit) => (
+
+ + {limit} +
+ ))} +
+ The first-weeks checklist
+
+ Before the launch post goes out
+
+ {checklist.map((item) => (
+
+ + + {item} +
+ ))} ++ The code an AI writes for you is a product. The server it runs on is an asset + under attack from day one. StackdogApp is the boring layer that notices and + reacts while you keep building features. +
+
+
+ Get started
+
+