Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement report suppression per-IP to prevent API usage saturation #17

Open
girlbossceo opened this issue Nov 18, 2023 · 0 comments
Open

Comments

@girlbossceo
Copy link

Hi, yesterday I received a weird email saying I exceeded my 5000 API request limit on AbuseIPDB. I found that very unusual because I have never ever exceeded even 1k requests a day, and checked my AbuseIPDB account and saw that I reported the same IP with the same URI 7 times.

image

https://www.abuseipdb.com/check/162.240.159.246

That was weird but definitely was not showing 5000+ reports. I checked my Caddy logs on that same IP and I found that it was scanning my IP and domain hundreds of thousands of times and ListenCaddy was reporting basically every URI because it was an extremely loud scanner (wc -l counts lines in output).

[root@girlcock ~]# grep 'reporting IP to AbuseIPDB' access-2023-11-17T*.log | wc -l
29344
[root@girlcock ~]# grep '162.240.159.246' access-2023-11-17T*.log | wc -l
149519
[root@girlcock ~]# grep 'manager/html' access-2023-11-17T*.log | wc -l
13266
[root@girlcock ~]#

So basically, in one single day, that IP made approximately 100k+ requests to me and ListenCaddy sent reports 29344 times (collectively which obviously exceeded daily 5k request limit), and one of the endpoints that IP was constantly scanning was Apache Tomcat (/manager/html) which ListenCaddy was constantly reporting even though it's the exact same offender and URI.

To avoid future API usage saturation, could suppression be implemented per-IP?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant