I use zip bombs to protect my server

As a former boss used to say: "Unlimited is a bad idea."

That doesn't necessarily need to be in the request itself.

You can also limit the wider process or system your request is part of.

Circa 1997 a coworker lamented that he had signed up for some email list, and attempts to unsubscribe weren’t working (more of a manual thing, IIRC). I made the suggestion to set up a cronjob to run hourly, to send an email request to be unsubscribed. It would source a text file containing the request to be unsubscribed. And with each iteration, it would duplicate the text from the file, effectively a geometric progression. The list owner responded about a week or so later, rather urgently requesting that my coworker cut it out, saying that he would remove him from the list. Apparently the list owner had been away on vacation the entire time.

Back then things like postmaster@theirdomain and webmaster@theirdomain were read by actual people. Also the whois command often worked.

You can also find out who owns a general group of IP addresses, and at the time they would often assist you in further pinpointing who is responsible for a particular address.

I always liked the RP DNS record (https://www.rfc-editor.org/rfc/rfc1183) but no one seems to know about it or use it any more. The only reason my servers don't have one now is because route53 doesn't support it.

tech-c / abuse addresses were commonly available on whois.

That's why everyone else is lazy and just ping google.com

What was it about NT that made an admin unnecessary? Just marketing?

I never found this out, but there was some feature where NT would try to negotiate an encrypted connection to communicate and that’s the port it was connecting on. It’s a long time ago. It’s possible the box had been pwned, and that was command/control for a botnet or something. Lots of internet-facing windows boxes were at the time because MS security was absolutely horrendous at this time.

I had a ton of trouble opening a 10MB or so png a few weeks back. It was stitched together screenshots forming a map of some areas in a game, so it was quite large. Some stuff refused to open it at all as if the file was invalid, some would hang for minutes, some opened blurry. My first semi-success was Fossify Gallery on my phone from F-Droid. If I let it chug a bit, it'd show a blurry image, a while longer it'd focus. Then I'd try to zoom or pan and it'd blur for ages again. I guess it was aggressively lazy-loading. What worked in the end was GIMP. I had the thought that the image was probably made in an editor, so surely an editor could open it. The catch is that it took like 8GB of RAM, but then I could see clearly, zoom, and pan all I wanted. It made me wonder why there's not an image viewer that's just the viewer part of GIMP or something.

Among things that didn't work were qutebrowser, icecat, nsxiv, feh, imv, mpv. I did worry at first the file was corrupt, I was redownloading it, comparing hashes with a friend, etc. Makes for an interesting benchmark, I guess.

For others curious, here's the file: https://0x0.st/82Ap.png

I'd say just curl/wget it, don't expect it to load in a browser.

I once encoded an entire TV OP into a multi-megabyte animated cursor (.ani) file.

Surprisingly, Windows 95 didn't die trying to load it, but quite a lot of operations in the system took noticeably longer than they normally did.

Why use squashfs when you can do the same OP did and serve a compressed version, so that the client is overwhelmed by both the uncompression and the DOM depth:

yes "<div>"|dd bs=1M count=10240 iflag=fullblock|gzip | pv > zipdiv.gz

Resulting file is about 15 mib long and uncompresses into a 10 gib monstrosity containing 1789569706 unclosed nested divs

Yes, servers can respond without specifying the size by using chunked encoding. And you can do the rest with a custom web server that just handles request by returning "<div>" in a loop. I have no idea if browsers are vulnerable to such a thing.

Looks like something I should add for my web APIs which are to be queried only by clients aware of the API specification.

Nah, back then we paid for bandwidth by the kb.

ln -s /dev/urandom /dev/zipbomb && echo 'Boom!'

Ok, not a real zip bomb, for that we would need a kernel module.

You yourself explain how it could've worked: Plenty of webservers are or were not chroot'ed.

I guess it depends on the server's implementation. but, since you need some logic to decide when to serve the html bomb anyway, I don't see why you would prefer this solution. Just use whatever script you're using to detect the bots to serve the bomb.

I remember reading about that some years ago. It involved Windows NT.

https://www.google.com/search?q=windows+nt+bug+affects+ship

Bad bot

Can you hand edit to create recursive file structures to make it infinite? I used to use debug in dos to make what appeared to be gigantic floppy discs by editing the fat

But the bot likely only automatically unpacks the outer layer. So nesting doesn't help with bot deterrence.

Wouldnt that defeat the attack though as you arent serving the large content anymore

Last time I checked, the tab keeps loading, freezes, and the process that's assigned to rendering the tab gets killed when it eats too much RAM. Might cause a "this tab is slowing down your browser" popup or general browser slowness, but nothing too catastrophic.

How bad the tab process dying is, depends per browser. If your browser does site isolation well, it'll only crash that one website and you'll barely notice. If that process is shared between other tabs, you might lose state there. Chrome should be fine, Firefox might not be depending on your settings and how many tabs you have open, with Safari it kind of depends on how the tabs were opened and how the browser is configured. Safari doesn't support zstd though, so brotli bombs are the best you can do with that.

Hosting WordPress myself for 13 years now and have no problem :) Just follow standard security practices and don't install gazillion plugins.

Never use that junk if you value your sanity, I think you mean.

I once worked for a US state government agency and my coworker was the main admin of our WordPress based portal and it was crazy how much work it was to keep working.

Ditto to self-hosting wordpress works fine with standard hosting practices and not installing a bazillion random plugins.

Hey, I check /wp-admin sometimes when I see a website and it has a certain feel to it

I do the same. Great way to filter our security scanners.

I did essentially the same thing. I have this input in a form:

    <label for="gb-email" class="nah" aria-hidden="true">Email:</label>
    <input id="gb-email"
           name="email"
           size="40"
           class="nah"
           tabindex="-1"
           aria-hidden="true"
           autocomplete="off"
    >

    .nah {
      opacity: 0;
      position: absolute;
      top: 0;
      left: 0;
      height: 0;
      width: 0;
      z-index: -1;
    }

We use to just call those honeypot fields. Works like a charm.

Oh that is great.

apart from blind users, who are also now completely unable to use their screenreaders with your site

“aria-hidden” would spare those users, and possibly be ignored by the bots unless they are sophisticated.

Manual banning is about the same since you just book /56 or bigger, entire providers or countries.

Automated banning is harder, you'd probably want a heuristic system and look up info on IPs.

IPv4 with NAT means you can "overban" too.

I think they are suggesting the range of IPs to block is too high?

Maybe it’s easier to circumvent because getting a new IPv6 address is easier than with IPv4?

Weird that text browsers just ignore all the attributes that hide elements. I get that they don't care about styling, but even a plain hidden attribute or aria-hidden are ignored.

true, but you can make the link text 'do not click this' or 'not a real link' to let them know. I'm not sure if crawlers have started using LLMs to check pages or not which would be a problem.

Same, using ipsets, and a systemd {service,timer} for updating the lists.

Undoubtedly. If you go poking around most any security product (the product I was referring to was not in the EDR space,) you'll see these sorts of issues all over the place.

is that endpoint detection and response?

This doesn't work if you pay bandwidth and CPU usage for your servers though.

Wouldn't this just waste your own bandwidth/resources?

Kinda wonder if a "content labyrinth" could be used to influence the ideas / attitudes of bots -- fill it with content pro/anti Communism, or Capitalism, or whatever your thing is, hope it tips the resulting LLM towards your ideas.

I currently cannot tell without making a little configuration change, because as soon as an IP address is logged as having visited the trap URL (honeypot, or zipbomb or whatever), a log monitoring script bans that client.

Secondly, I know that most of these bots do not come back. The attacks do not reuse addresses against the same server in order to evade almost any conceivable filter rule that is predicated on a prior visit.

Doesn't deal with multi-file ZIP archives. And before you think you can just reject user uploads with multi-file ZIP archives, remember that macOS ZIP files contain the __MACOSX folder with ._ files.

https://github.com/uint128-t/ZIPBOMB

  2048 yottabyte Zip Bomb

  This zip bomb uses overlapping files and recursion to achieve 7 layers with 256 files each, with the last being a 32GB file.

  It is only 266 KB on disk.

Seems like a good and simple strategy to me. No real partition needed; tmpfs is cheap on Linux. Maybe OP is using tools that do not easily allow tracking the number of uncompressed bytes.

Yes I'd rather deal with a simple out of disk space error than perform some acrobatics to "safely" unzip a potential zip bomb.

Also zip bombs are not comically large until you unzip them.

Also you can just unpack any sort of compressed file format without giving any thought to whether you are handling it safely.