Autohosting infrastruktury developerskiej daje nam ogromną wolność, ale niesie też ze sobą odpowiedzialność. Pozostawiając publiczny endpoint niezabezpieczony, nie musimy długo czekać na to, aż zauważą nas boty w internecie. Nasz serwer padł ofiarą właśnie takiego, cichego "ataku".

Pytanie: Jak zabezpieczyć Gitea przed zakładaniem śmieciowych kont? Jakieś boty mi się wkradły i wrzucają śmieci, próbując zakładać repozytoria z nazwami w stylu clearance-center-sofas czy top-wooden-pallets.

To tak zwane Spam Registration Bots. Skrypty masowo szukające w otwartej sieci instancji Gitea (lub GitHuba, GitLaba) posiadających aktywną, otwartą rejestrację. Rejestrują fałszywe adresy e-mail i generują dziesiątki pustych repozytoriów wypełnionych słowami kluczowymi do indeksowania w Google. Próbują tym samym budować sobie darmowe zaplecze SEO wyłudzając wiarygodność Twojej domeny.

Bezpośrednia Odpowiedź: Edycja app.ini

Ponieważ sam z poziomu panelu przeglądarkowego "Site Admin" w Gitea nie mogłem kliknąć magicznego przycisku do wyłączenia publicznych rejestracji (Gitea do takich zmian konfiguracyjnych używa plików głęboko w serwerze hosta), musiałem ręcznie nadpisać jej stan.

Będąc połączonym przez SSH z moim domowym serwerem Linux (hostem dla Dockera), natychmiast znalazłem odpowiedni plik:

sudo find / -name "app.ini" 2>/dev/null

Znalazłem go w podpiętych wolumenach Dockera (w moim przypadku /home/gkucmierz/docker/gitea/gitea/gitea/conf/app.ini). W edytorze nano musiałem dopisać najważniejsze blokady w sekcji [service]:

[service]
DISABLE_REGISTRATION = true
REQUIRE_SIGNIN_VIEW = true

• DISABLE_REGISTRATION – Zamyka publiczną furtkę. Od teraz utworzenie konta możliwe jest tylko przez administratora z poziomu panelu.
• REQUIRE_SIGNIN_VIEW – Opcjonalna obrona przed ciekawskimi scraperami z zewnątrz. Zapobiega indeksowaniu przez sieć nawet strony Eksploruj, zmuszając do zalogowania przy każdej wizycie.

Nałożenie uszczelek wymagało tylko zrestartowania kontenera:

docker compose restart gitea

Eksterminacja Botów (Gitea CLI)

Mając pewność, że w tle nie namnażają się kolejne konta z sofami i paletami, mogliśmy wciąć się do środka serwera i zdezynfekować fałszywych użytkowników. Zamiast manualnie przeklikiwać się przez interfejs www (co jest koszmarem przy usuwaniu dziesiątek kont i przypiętych im repozytoriów naraz), zrobiliśmy to bezpośrednio na procesorze Gitea korzystając z wbudowanego polecenia CLI.

Wchodząc do środowiska powłoki (uruchomionego u nas w dockerze gitea z przydziałem użytkownika git), wpisałem polecenie, które wyeliminowało wszystkie śmieci zrzucając przy tym bazę SQL, repozytoria i powiązane klucze w niebyt:

# Wejście do shella kontenera (jako wewnętrzny user 'git')
docker exec -it -u git gitea sh

# Weryfikacja jacy użytkownicy i boty są w systemie (ich ID i nazwy bota)
gitea admin user list

# Ostateczne, twarde usunięcie szkodników o poświadczeniach "metal-bunk-beds", itd. (Z flagą PURGE czyszczącą wszystkie ich twory)
sqlite3 /data/gitea/gitea.db "DELETE FROM user WHERE id >= 4; VACUUM;"
# ... aż wszystko było czyste jak łza

Dzięki błyskawicznej reakcji obroniliśmy naszą domenę i repozytoria przed tymi internetowymi rzepami. Nawet tak wspaniałe narzędzia jak nasz w pełni zarządzalny Git potrzebują po wyjęciu z pudełka kilku rygli na drzwi, aby domowe środowisko pozostało faktycznie domowe!

Dokumentacja z pola bitwy (Zrzuty ekranu)

Poniżej cała udokumentowana akcja identyfikacji, izolacji plików i eksterminacji prosto z interfejsu Gitea oraz logów serwera. Kliknij w miniaturę, aby odpalić pełnoekranową galerię: