Nginx hardening

Seafile Server
,
1

I am running CE 9.0.2 in docker deployment.
It seems that the nginx config forwards everything to seahub, even potential attackers scanning the server for vulnerable services. This fills the log with stuff like this:

2022-02-06 23:12:21,039 [WARNING] django.request:224 log_response Not Found: /owa/auth/logon.aspx
2022-02-06 23:22:58,412 [WARNING] django.request:224 log_response Not Found: /admin/config.php
2022-02-07 00:16:13,758 [WARNING] django.request:224 log_response Not Found: /bag2
2022-02-07 00:38:16,179 [WARNING] django.request:224 log_response Not Found: /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
2022-02-07 01:20:02,903 [WARNING] django.request:224 log_response Not Found: /index.php
2022-02-07 03:05:48,151 [WARNING] django.request:224 log_response Not Found: /mifs/.;/services/LogService
2022-02-07 04:05:08,753 [WARNING] django.request:224 log_response Not Found: /login_sid.lua
2022-02-07 04:48:37,677 [WARNING] django.request:224 log_response Not Found: /Autodiscover/Autodiscover.xml
2022-02-07 11:23:54,153 [WARNING] django.request:224 log_response Not Found: /actuator/health
2022-02-07 13:32:44,916 [WARNING] django.request:224 log_response Not Found: /admin/config.php

I wonder if someoen has a good nginx sample configuration that would discard all of these requests. Actually I should be able to discard everything that is not according to the seafile base URL or the letsencrypt paths.
Any hints?

thanks!

2

You certainly could drop everything (return 444 would probably be best) if it’s not a proper Seafile/LetsEncrypt path. I generally use Fail2Ban and monitor the log file using one set of banning rules for invalid authentications and another set of bans for multiple ‘Not Found’ entries. The advantage of using something like F2B is that you can have it set your firewall to drop traffic (iptables or UFW) immediately which uses even less resources than NGINX.

If you drop packets silently using the firewall, the potential attacker gets no response and will (hopefully) move on thinking it’s a dead server. If you go the NGINX route, returning 444 does the same thing – it’s an internal NGINX code for “drop and send no response”. Do not return something like 404 since that still indicates a “live server” and is what django is returning right now anyways (I assume).

If you are new to F2B there’s lots of documentation and examples all over the web. If you need specific help crafting the rules, just give me a shout and I’ll try to help you out.

Also, thanks for reminding me that I have to implement this on my newly upgraded Seafile instance too :stuck_out_tongue:

1 Like