Live data from Hacker News

I use zip bombs to protect my server

idiallo.com

351–360 of 467 posts

Re: I use zip bombs to protect my server

#351

Earlier quoted context omitted.

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

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.

I'd put fake paper namers (doi.numbers.whatever.zip) in order to quickly keep their attention, among a robots.txt file for a /papers subdirectory to 'disallow' it. Add some index.html with links to fake 'papers' and in a week these crawlers will blacklist your like crazy.

Re: I use zip bombs to protect my server

#352

These days, almost all browsers accept zstd and brotli, so these bombs can be even more effective today! [This]( https://news.ycombinator.com/item?id=23496794 ) old comment showed an impressive 1.2M:1 compression ratio and [zstd seems to be doing even better]( https://github.com/netty/netty/issues/14004 ). Though, bots may not support modern compression standards. Then again, that may be a good way to block bots: eve…

If you nest the gzip inside another gzip it gets even smaller since the blocks of compressed '0' data are themselves low entropy in the first generation gzip. Nested zst reduces the 10G file to 99 bytes.

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

Re: I use zip bombs to protect my server

#353
post #52

Earlier quoted context omitted.

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.

> 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.

In a practical sense, how's that different from creating a N-byte partition and letting the OS return ENOSPC to you?

Re: I use zip bombs to protect my server

#354
post #324

Earlier quoted context omitted.

DrupalCMS is a new project that aims to radically simplify for end users https://new.drupal.org/drupal-cms

> Drupal > new Pretty sure Drupal has been around for like, 20 years or so. Or is this a different Drupal?

Drupal has been around for a while, but I've never heard of "Drupal CMS" as a separate product until now.

It appears Drupal CMS is a customized version of Drupal that is easier for less tech-savvy folks to get up and running. At least, that's the impression I got reading through the marketing hype that "explains" it with nothing but buzzwords.

Re: I use zip bombs to protect my server

#355

Earlier quoted context omitted.

Those files are designed to exhaust the system resources before you can even do these kinds of checks. I'm not particularly familiar with the ins and outs of compression algorithms, but it's intuitively not strange for me to have a a zip that is carefully crafted so that memory and CPU goes out the window before any check can be done. Maybe someone with more experience can give mode details. I'm sure though that if i…

Not really. It really is that simple. It's just dictionary decompression, and it's just halting it at some limit. It's just nobody usually implements a limit during decompression because people aren't usually giving you zip bombs. And sometimes you really do want to decompress ginormous files, so limits aren't built in by default. Your given language might not make it easy to do, but you should pretty much always be…

I honestly thought it was harder. It's still a burden on the developer to use the tools in the intended way so that the application isn't vulnerable, so it's something to keep in mind when implementing functionality that requires unpacking user provided compressed archives.

Re: I use zip bombs to protect my server

#356

Earlier quoted context omitted.

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

There's a lot of essential functionality missing from WordPress, meaning you have to install plugins. Depending on what you need to do. But it's such a bad platform that there really isn't any reason for anybody to use WordPress for anything. No matter your use case, there will be a better alternative to WordPress.

You can use WordPress as a static site generator: https://simplystatic.com/

Then WordPress is just your private CMS/UI for making changes, and it generates static files that are uploaded to a webhost like CloudFlare Pages, GitHub Pages, etc.

Re: I use zip bombs to protect my server

#357

I sort of did this with ssh where I figured out how to crash an ssh client that was trying to guess the root password. What I got for my trouble was a number of script kiddies ddosing my poor little server. I switched to just identifying 'bad actors' who are clearly trying to do bad things and just banning their IP with firewall rules. That's becoming more challenging with IPV6 though. Edit: And for folks who write t…

> I sort of did this with ssh where I figured out how to crash an ssh client that was trying to guess the root password. What I got for my trouble was a number of script kiddies ddosing my poor little server.

This is the main reason I haven't installed zip bombs on my website already -- on the off chance I'd make someone angry and end up having to fend off a DDoS.

Currently I have some URL patterns to which I'll return 418 with no content, just to save network / processing time (since if a real user encounters a 404 legitimately, I want it to have a nice webpage for them to look at).

Should probably figure out how to wire that into fail2ban or something, but not a priority at the moment.

Re: I use zip bombs to protect my server

#358
post #341
post #307

Earlier quoted context omitted.

Could server-side includes be used for a html bomb? Write an ordinary static html page and fill a with infinite random data using . or would that crash the server?

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.

No other scripts. Hide the link to the bomb behind an image so humans can't click it.

Re: I use zip bombs to protect my server

#359
post #283

Earlier quoted context omitted.

I wonder if I could create a 500TB html file with proper headers on a squashfs, an endless ... with no closing tags, and if I could instruct the server to not report file size before download. Any ideeas?

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 " "|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

I like it. :)

Re: I use zip bombs to protect my server

#360

I deployed this, instead of my usual honeypot script. It's not working very well. In the web server log, I can see that the bots are not downloading the whole ten megabyte poison pill. They are cutting off at various lengths. I haven't seen anything fetch more than around 1.5 Mb of it so far. Or is it working? Are they decoding it on the fly as a stream, and then crashing? E.g. if something is recorded as having read…

Try content labyrinth. I.e. infinitely generated content with a bunch of references to other generated pages. It may help against simple wget and till bots adapt. PS: I'm on the bots side, but don't mind helping.

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.
Post reply on HN