chomnr / brute

Brute an application that monitors authentication attempts on your server that uses OpenSSH or any protocol. May not be practical, but it is cool.
https://brute.exposed/
MIT License
15 stars 4 forks source link

endpoint becomes unresponsive. #2

Closed chomnr closed 3 months ago

chomnr commented 3 months ago

I noticed that the endpoint became unresponsive. I'm unsure if this is just a one-time thing, but I figure it won't be. After I restarted the container, it became responsive again; I'm currently monitoring it to see what's happening. I don't know if this is exclusive to the GET requests or if it's also happening to the POST. This MIGHT be related to #1, but it shouldn't be because the errors get propagated to the call stack and handled accordingly.

I have noticed that when I visit api.brute.exposed/brute/stats/attack sometimes it takes a little bit to load might be a server issue but unlikely again because I can visit brute.exposed just fine.

There is a ratelimit on GET requests so it might be that. Or there might be an issue with my actix setup.

chomnr commented 3 months ago

As expected the issue happened again it seems that IpInfo is causing the problem.

The first time this command is ran is on bootup but when it gets ran the second time it stalls the program. [2024-08-01T22:04:01Z DEBUG reqwest::connect] starting new connection: https://ipinfo.io/

working on a fix now

chomnr commented 3 months ago

IPInfo is not causing the problem. This time the problem came on quicker than I thought this is when I hooked up the second farm server (so i was getting double the traffic) to brute.exposed. Also both POST and GET requests go unresponsive. Might be something with actix.

chomnr commented 3 months ago

the problem seems to be fixed with https://github.com/notpointless/brute/commit/94eb7a88258588f6c322beacb8c400f2c8ed9ed0

going to leave the issue open until further notice.

chomnr commented 3 months ago

moved to actix-web from axum hopefully that solves the issue. will update