Z dziennika architekta: LLMy, SysOps i jak temu podołać

Jak już się domyślacie, w moim wypadku to jest tak, że jak sobie “ubzduram”, że muszę coś zrobić to muszę, bo się uduszę. Stąd też jak uznałem, że nie ma opcji, muszę skonfigurować modsec tak, żeby ochronić endpoint przyjmujący OTP i endpointa logowania, żeby powstrzymać przed nadmiernym “pingowaniem” za równo przez osoby niepowołane jak i te, które znają passy (po prostu przed userami). Oczywiście, to nie było tak, że zadziałało od razu, a i tak są rzeczy do poprawy.

Jak do tego doszło?

Jak zwykle, słuchając szkolenia dot. OSINT i OPSEC uznałem, że nie mogę siedzieć “bezczynnie”, więc wykoncypowałem sobie, że należy zabezpieczyć system przed potencjalnym ryzykiem wysycenia puli maili na dzień. Na ten moment Mailgun w systemie jest użyty wyłącznie przy logowaniu po OTP, więc o ile nie da się tak łatwo zaspamować endpointów, by wysłały maile w niekontrolowany sposób, tak jeśli ktoś jest zarejestrowanym użytkownikiem i zna hasło - już mógłby to zrobić. Zdecydowałem się na użycie WAF w formie mod_security na Apache, który stanowi u mnie proxy. Była to sugestia podrzucona przez ChatGPT na bazie skróconego opisu mojego setupu, gdzie dałem mu znać, że mod_evasive już jest i mod_security też jest dostępne.

Aktualna konfiguracja

Aktualnie serwer generalnie nie pozwala na zbyt intensywne “pakowanie” requestów, bo mod_evasive wytnie takiego klienta. Ale jeśli ktoś robiłby to wystarczająco subtelnie to wcale nie jest to tak trudne by ogłupić ten mechanizm. Jednak mod_security reaguje samo w sobie na to “co” jest wysyłane, a nie w jaki sposób. Ogólna konfiguracja blokuje rozmiar uploadów, pewne podejrzane standardowe syngatury plików itd. Jednak w moim wypadku, analizując ruch na konkretne endpointy (logowania i OTP) zlicza ilość prób. Jeśli ktoś przegnie, a mod_evasive go nie wytnie to zrobi to mod_security rzucając 429. Nie dość, że API wytnie go w ten sposób, to cały front-end dla bezpieczeństwa również. System na razie jest skonfigurowany na cooldown około 2 minut.

A co jest do poprawy?

Na pewno fakt, że w tym momencie po “cooldown”, znów możemy “zasuwać” z requestami, aż mod_evasive się nie wścieknie (i o ile). Kwestia leży w tym, że na ten moment nie było to konieczne, by robić długotrwały lock out usera po tokenie czy IP, bo mówimy o użytkownikach zarejestowanych (tylko tacy w ogóle mogą coś wysłać), a tych znam osobiście, bo są to albo moi znajomi, albo klienci. A rejestracja w systemie jest niemożliwa, robię to całkowicie manualnie. Nie zmienia to faktu, że zabezpieczeń NIGDY za wiele (oczywiście tak długo, jak długo UX nie cierpi na tym). Dodatkowo, w ramach samych zabezpieczeń - trzeba uszczelnić i poprawić cooldown na mod_evasive, dodać lockouts dłuższe niż na chwile, a także poprawić, aby blokady nie były zbyt widoczne - zamiast blokować, używać cached wyników, a blokować w ostateczności. Aktualna konfiguracja jest ok, bo nie mam wielkiego ruchu, ani zbyt inteysnwnego, jednak jeśli miał bym skalować to do rozmiaru produktu komercyjnego, jest to konieczna zmiana.