IP has been blocked

Help
1

IP: 93.179.113.158
Caddy message:
Activating privacy features… 2019/10/07 17:25:51 get directory at ‘https://acme-v02.api.letsencrypt.org/directory’: acme: error: 0 :: GET :: https://acme-v02.api.letsencrypt.org/directory :: urn:ietf:params:acme:error:rateLimited :: Your IP, 93.179.113.158, has been blocked due to ridiculously excessive traffic. Once this is corrected you may request this be reviewed on our forum https://community.letsencrypt.org , url:

2

Hi @laughsoul

that happens if you use a too old client or if your setup is wrong.

What's your Caddy version? What's your setup?

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

PS: Checking your ip there is nothing visible - https://check-your-website.server-daten.de/?q=93.179.113.158 - no connection is possible.

Normally, that block comes from clients like Kubernetes using a buggy configuration or a too old version. Perhaps you have an error in your configuration.

1 Like
3

Have you tracked down what was causing the excessive traffic and fixed it?

How long have you had that IP address? Has it always been blocked?

2 Likes
4

@laughsoul Do you happen to be using a script similar to https://github.com/search?q=caddy+"%24{email}%40gmail.com"&type=Code ?

5 Likes
5

Specifically, are you using V2Ray? We’ve seen a lot of problem clients in our logs lately that were sending tons of traffic from Caddy, and it looks like it might be from V2Ray. We’ve blocked those clients for now, but we’d like to work with you and the V2Ray authors to try to figure out why all these clients are sending so many requests.

What’s your domain name? Do you have a certificate?

6 Likes
6

A little more detail on the problem clients:

  • They have a Caddy User-Agent.
  • They request /directory, /acme/new-nonce, and /acme/new-acct in a tight loop, but never seem to issue a certificate.
  • They all have fake email addresses like 136289714176@gmail.com (not a real email address from the logs, I just made this up).

Thanks to eagle-eyed @mholt from Caddy, who spotted that V2Ray has a script that seems to generate such fake email addresses for a Caddy config: https://github.com/myaerliya/rliya/blob/e9ab14add2c5f44222748967ff106f8fb0c81681/src/caddy-config.sh.

If anyone knows the V2Ray maintainers and would like to get in touch, please let them know!

6 Likes
7

@laughsoul Can you confirm that Caddy is able to write to and read from its $CADDYPATH? (Default $HOME/.caddy)

Caddy will only make a user account if it doesn’t have one on disk already.

My guess is that Caddy was unable to write the user account to disk, encountered an error at startup, and systemd was configured to restart Caddy endlessly in a tight loop without regard for exit code.

Caddy should not be automatically restarted if it exits with code 1: https://caddyserver.com/docs/cli#exit-codes

V2Ray should also be modified to use real email addresses.

6 Likes
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.