Provided seafile fail2ban sample just protects any UI brute force attemps but does not protect against API brute force attemps

I just detected in my seafile logs a some brute force attemps. I use the provided fail2ban sample and thought I’m fine but now detected this doesn’t protect any API brute force attempts.

I guess there are fail2ban rules out there which block theses API attempts. Any link to a git repo or any other place in the net is highly appreciated.

Just a comment for the seafile document writers: Please add a disclaimer in the doc for the existing fail2ban sample which makes clear this rule doesn’t protect against API brute force requests. Frankly I expect API fail2ban rules to be part of the seafile documentation :face_with_raised_eyebrow:


I wrote a script which executes a brute force API attack against my seafile server and noticed I get a 429 back after 5 requests. Looks like there is some kind of throtteling implemented in Seafile which is good. Actually I don’t have a botnet handy so all requests were issue from one IP.

My questions:
On which level are requests throttled by seafile? Every request? Every request from an given IP? There are nice DOS attacks against seafile servers I can think of …


I did some additional tests and was able to answer my previous question: Throtteling is done on server base. I started one thread executing a brute force request and in parallel another thread executing normal authorized Seafile requests and they were rejected with 429 :frowning: . I guess all Seafile user requests are rejected with 429 now.

I have no idea why anybody from Seafile development comments on this :frowning:

As far as I can see there is no issue with API brute force attacks because of request throtteling which was my initial concern. But it’s easy to start a DOS against every Seafile server :frowning:


Thanks for posting this. This kind of information really helps deepen the understanding of how Seafile works.

Have you done this from two devices (or at least interfaces) with two different ips?

Good catch :+1: No, I used the same IP :flushed:

I executed the test again with two different IPs and the normal user was able to retrieve data vi API. Given this everything is OK and there is no DOS possible this way against Seafile. :tada:

@shoeper Do you know who’s throtteling the requests? nginx or Seafile server?

1 Like

Seahub is throttling the requests.

1 Like

I have some additions. Rate limiting has been implemented for /api2 I’m not sure about /api and requests to other locations. The login page has its own limitation showing a captcha after some failures.

For more details one would have to look at the seahub source and/or test it out. Looks like these are the default rate limits:

Thank you very much pointing out there exists /api and /api2. /api2 is documented and I didn’t know about /api. I would expect that’s an old api no longer used - is it?

60/minute = 1/s
But this doesn’t map to may test results. If I kick off an anon request every second I get 429. Even when I use 15s sleep I get sometimes 429.

Oh, actually it looks like there is only /api2. Just thought there is /api because there are two manual pages (see

Looks like they should be merged.

I published my small bash script I used to execute API calls on github. Feel free to execute your own tests.