Mail Spam Filter Bug?

Bugs
1

I think this may be a bug just reaching out to see if anyone else is getting an issue.
So basically, login for random members keeps showing the following:

"Too many login attempts."
"Too many login attempts."

Error ID:
    1906bb70-2b37-11ec-8e29-bb327559f2ad
----------------------------------------
TooManyRequestsError: Too many sign-in attempts try again in 13 hours
1 Like
2

Hi @rickdonato, have you found a solution or managed to fix this yet?

3

Quick fix => Try this to see if resolves issue when staff unable to login toggle the staff user to suspended and then back to unsuspended.

What does your log say when a user tries to login whilst having issue?

4

Nope not found a solution. Seems to be a bug with Ghost.

5

Hi. Thanks but issue is with members rather then staff

6

@rickdonato what does your hosting setup look like? Is there anything that could cause all requests to ghost to look like they are coming from the same IP? Is there any likelihood that a lot of your members are accessing from somewhere that has a single IP (eg a school campus, large office, etc)?

7

@Kevin Is your suggestion that multiple users are behind a single IP and one user is retrying/brute-forcing etc and preventing the other users to access the site?
So hereā€™s the thing from what I can see and looking at the brute table in the DB. It shows tokens and the number of logins for each. And from what I can see each token represents a user. Therefore is there any logic for recording IPs for any brute force attempts. As it seems everything is done on a per user basis.

Yesterday I logged in fine. This morning I logged out, and then I was unable to log in, due to:

TooManyRequestsError: Too many sign-in attempts try again in 6 days

Really appreciate your help with thisā€¦

8

If youā€™re looking at the brute table there are no tokens there. The key field is a hash of IP address and brute rule so it represents the counts for an IP address not a particular user.

Have you checked your logs to see if thereā€™s anything there that could point to whatā€™s happening?

9

The logs just show that when the user is unable to log in that they are unable to due to the brute-force attempts.

My platform is behind a CDN so in essence, multiple users could be behind a single IP. Is there a safe way to clear the DB table so I can troubleshoot further.
I was thinking DELETE FROM brute. Or are there any other recommendations for troubleshooting?

What is the recommended approach for Ghost and CDNs. As typically most sites will be behind a CDN and have a traffic originating from the regional POP.

Thanks againā€¦

10

You can delete from the brute table, although you may need to restart Ghost afterwards.

Typically a CDN would be set up to forward the end userā€™s IP address so they generally arenā€™t a problem unless improperly configured.

The logs just show that when the user is unable to log in that they are unable to due to the brute-force attempts.

I meant taking more of an analysis approach where you look over the historical pattern of requests and IP addresses so you can develop a picture of whatā€™s happening.

11

Thanks Kevin.

Typically a CDN would be set up to forward the end userā€™s IP address so they generally arenā€™t a problem unless improperly configured.

Are you saying that Ghost and the brute-express tooling supports X-Forwarded-For headers? Or are you referring to something else?

I meant taking more of an analysis approach where you look over the historical pattern of requests and IP addresses so you can develop a picture of whatā€™s happening.

Iā€™m happy to take this approach. But the logs do not show me any IPs, and the brute table has the IPs hashed. Is there a way to get the IPs from the brute table in their true form so I can align to what is happening?

Also interested to know. If I was having this issue after hosting with the platform with Ghost. Would this be something that would be investigated?

Thanks againā€¦

12

Are you saying that Ghost and the brute-express tooling supports X-Forwarded-For headers?

Yes. Ghost enables the trust proxy setting in express. Express behind proxies

But the logs do not show me any IPs

Which logs are you looking at? Your Ghost instance logs should have full request/response header details in them. Usually your proxy server logs would have useful data for IP addresses too.

If I was having this issue after hosting with the platform with Ghost. Would this be something that would be investigated?

Yes. Although itā€™s not an issue that has come up on our hosted platform so far.

13

Thanks.

I checked (via tcpdump and seeing HTTP headers) and I can see XFF being sent via the CDN.
Iā€™ve cleared out the brute table so will monitor. Is there anyway to decode the hash key of the brute table as this would make troubleshooting a million times easier.

Again, thanksā€¦

14

No. Itā€™s a hash so the only way you can verify whatā€™s in there is to know the original data, itā€™s similar to storing password hashes.

You would need to correlate between logs and the hash table timestamps if you wanted to dig into the brute data. It shouldnā€™t be necessary though, your logs should tell you the whole story for access attempts over time and when any limits were hit.

15

Just to close this thread, after clearing the db Iā€™ve had no more issues. Thanks for the help.