Does Fly have any sort of firewall/IP blocking?

Probably not surprisingly, my fly logs pretty often have attempts to find known vulnerabilities - wp-index.php and eval-stdin.php and something called stalker_portal and a bunch of others. I’m guessing it’s pretty impossible to have a business like Fly and not have people know your IP range, and bots just crawl those IPs constantly? I’m not sure if it would help much in practice but I’m wondering if there’s any way to block the IPs making those requests, without modifying my application code which seems a bit hacky/overkill. Some sort of simple equivalent to AWS WAF I suppose, though I’m not very experienced with that product.

1 Like

It’s something we’ve been looking into doing. Probably as another HTTP “handler” in fly.toml.

Those bots are usually harmless, but they’re annoying.

1 Like

I just ran into this myself having only just got started with fly.
Any recommendations at this time? These bots make the app request logs noisy

Any news on this @jerome ?

I would like to use Preset with Postgres on Fly and I really wouldn’t want to leave a port open to anyone.

We don’t have an ETA on this yet, but it’s also unrealistic to imagine blocking all bot networks, as they change IPs often.

What might make more sense - and is something you can do today - is to run a small proxy in front of your app. For WAF support, there are some open source modules available. For Postgres, you could use a similar approach but enable an allow list using Nginx or something simpler like Haproxy.

Thanks for the suggestion @joshua .

I’m not trying to block bots though. I want to whitelist an IP so that Preset (and maybe other external services) can access PG securely.

You really should not open your Postgres up to the world. And I, personally, wouldn’t use a DB tool that needs to access Postgres over a public IP to do its job. These companies should provide an agent of some kind you can run alongside your DB.

If you really, really want to use one, haproxy is the best way to do this. What I would do is create a separate gateway app running haproxy, then configure haproxy to only allow connections from specific IPs.

1 Like

But how come it’s standard practice to connect to PG using a connection URL?

Because they can, really. It’s pretty much Heroku’s fault. It’s been a bad idea to open Postgres up to the internet for at least a decade, but enough people use Heroku that BI tools haven’t had to do anything better.

The good ones solve this with VPC peering or a sidecar/agent.