Live data from Hacker News

I use zip bombs to protect my server

idiallo.com

51–60 of 467 posts

Re: I use zip bombs to protect my server

#51

I protected uploads on one of my applications by creating fixed size temporary disk partitions of like 10MB each and unzipping to those contains the fallout if someone uploads something too big.

What? You partitioned a disk rather than just not decompressing some comically large file?

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.

Re: I use zip bombs to protect my server

#52

Earlier quoted context omitted.

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. When you realise it's a zip bomb it's already too late. Looking at the file size doesn't betray its contents. Maybe applying some heuristics with ClamAV? But even then it's not guaranteed. I think a small pa…

What are you talking about? You get a compressed file. You start decompressing it. When the amount of bytes you've written exceeds some threshold (say 5 megabytes) just stop decompressing, discard the output so far & delete the original file. That is it.

That assumes they're using a stream decompressor library and are feeding that stream manually. Solutions that write the received file to $TMP and just run an external tool (or, say, use sendfile()) don't have the option to abort after N decompressed bytes.

Re: I use zip bombs to protect my server

#53
Back when I was a stupid kid, I once did

    ln -s /dev/zero index.html
on my home page as a joke. Browsers at the time didn’t like that, they basically froze, sometimes taking the client system down with them.

Later on, browsers started to check for actual content I think, and would abort such requests.

Re: I use zip bombs to protect my server

#55

Earlier quoted context omitted.

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. When you realise it's a zip bomb it's already too late. Looking at the file size doesn't betray its contents. Maybe applying some heuristics with ClamAV? But even then it's not guaranteed. I think a small pa…

What are you talking about? You get a compressed file. You start decompressing it. When the amount of bytes you've written exceeds some threshold (say 5 megabytes) just stop decompressing, discard the output so far & delete the original file. That is it.

Depending on the language/library that might not always be possible. For instance python's zip library only provides an extract function, without a way to hook into the decompression process, or limit how much can be written out. Sure, you can probably fork the library to add in the checks yourself, but from a maintainability perspective it might be less work to do with the partition solution.

Re: I use zip bombs to protect my server

#57
post #7

Earlier quoted context omitted.

Something like https://xeiaso.net/notes/2025/anubis-works/

I did actually try zip bombs at first. They didn't work due to the architecture of how Amazon's scraper works. It just made the requests get retried.

So first, let me prefix this by saying I generally don't accept cookies from websites I don't explicitly first allow, my reasoning being "why am I granting disk read/write access to [mostly] shady actors to allow them to track me?"

(I don't think your blog qualifies as shady … but you're not in my allowlist, either.)

So if I visit https://anubis.techaro.lol/ (from the "Anubis" link), I get an infinite anime cat girl refresh loop — which honestly isn't the worst thing ever?

But if I go to https://xeiaso.net/blog/2025/anubis/ and click "To test Anubis, click here." … that one loads just fine.

Neither xeserv.us nor techaro.lol are in my allowlist. Curious that one seems to pass. IDK.

The blog post does have that lovely graph … but I suspect I'll loop around the "no cookie" loop in it, so the infinite cat girls are somewhat expected.

I was working on an extension that would store cookies very ephemerally for the more malicious instances of this, but I think its design would work here too. (In-RAM cookie jar, burns them after, say, 30s. Persisted long enough to load the page.)

Re: I use zip bombs to protect my server

#58
post #39
post #27

I am ignorant as to how most bots work. Could you have a second line of defense for bots that avoid this bomb: Dynamically generate a file from /dev/random and trickle stream it to them, or would they just keep spawning parallel requests? They would never finish streaming it, and presumably give up at some point. The idea would be to make it more difficult for them to detect it was never going to be valid content.

You want to consider the ratio of your resource consumption to their resource consumption. If you trickle bytes from /dev/random, you are holding open a TCP connection with some minimal overhead, and that's about what they are doing too. Let's assume they are bright enough to use any of the many modern languages or frameworks that can easily handle 10K/100K connections or more on a modern system. They aren't all that…

That's clear. It all comes down to their behavior. Will they sit there waiting to finish this download, or just start sending other requests in parallel until you dos yourself? My hope is they would flag the site as low-value and go looking elsewhere, on another site.

Re: I use zip bombs to protect my server

#59
post #54

Is there any legal exposure possible? Like, a legitimate crawler suing you and alleging that you broke something of theirs?

Please, just as a conversational piece, walk me through the potentials you might think there are ?

I'll play the side of the defender and you can play the "bot"/bot deployer.

Post reply on HN