Zapobiegasz brutalnym atakom na MySQL?

Muszę włączyć sieć dla MySQLd, ale za każdym razem, gdy to robię, serwer zostaje brutalnie zmuszony do zapomnienia. Niektóre skrypty zgadywania haseł zaczynają wbijać się w serwer, otwierając połączenie na porcie 3306 i próbując na zawsze losowych haseł.

Jak mogę temu zapobiec?

Do SSH używam denyhosts, który działa dobrze. Czy istnieje sposób, aby denyhosts działało z MySQLd?

Zastanawiałem się również nad zmianą portu, na którym działa MySQL, ale jest to mniej niż idealne i tylko rozwiązanie zatrzymania przerwy (a jeśli odkryją nowy port?)

Czy ktoś ma jakieś inne pomysły?

Jeśli robi się inaczej, korzystam z MySQL 5.x na FreeBSD 6.x.

Nie znam żadnych pakietów oprogramowania typu Denyhosts dla MySQL, ale mam kilka rozwiązań:

• Ogranicz logowanie do określonych adresów IP. Nie należy używać%, aby umożliwić wszystkim hostom połączenie z serwerem.
• Jeszcze bardziej bezpieczne, skonfiguruj iptables, aby umożliwić dostęp do 3306 tylko z autoryzowanych adresów IP.
• Tuneluj ruch do skrzynki za pomocą ssh, a następnie połącz się przez localhost
• Zmodyfikuj skrypty Denyhosts lub BFD, aby analizować dzienniki dostępu mysql i blokować wszelkie próby użycia siły brutalnej w zaporze

Edytuj :

Aby odpowiedzieć na swój komentarz, spróbuj tego :

iptables -A INPUT -p tcp -s 202.54.1.50 --sport 1024:65535 -d 202.54.1.20 --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s 202.54.1.20 --sport 3306 -d 202.54.1.50 --dport 1024

Gdzie .20 to MySQL, a .50 to zdalnie łączący się adres IP.

1: Zmień port z 3306. Nie ze względu na lepsze bezpieczeństwo, ale aby obciążyć serwer, aby poradzić sobie z atakami fałszywego logowania

2: Utwórz certyfikat SSL i włącz go na serwerze MySQL (i tak trzeba zaszyfrować połączenie klient-serwer)

3: Utwórz jeden lub więcej certyfikatów klienta (wszyscy klienci muszą mieć certyfikat, a oprogramowanie klienta musi być skonfigurowane, aby z niego korzystać). Jeśli Twoimi klientami są .Net , musisz przekonwertować certyfikat klienta na format pkcs12, ale łatwo to zrobić, zobacz ten przewodnik.

4: Ustaw konto użytkownika MySQL tak, aby wymagało certyfikatu klienta x509, a następnie atakujący potrzebuje poświadczeń logowania ORAZ certyfikatu klienta (możesz nawet podać hasło do certyfikatu klienta, a atakujący również musi tego wymagać).

Skorzystałem z tego przewodnika, aby utworzyć certyfikaty i pliki kluczy, ale istnieje wiele przewodników.

Wolę używać mojego połączenia SSH, aby uzyskać dostęp do mojego Linux-a dla celów administracyjnych, a nie dla dostępu klienta.

Korzystając z MySQL Proxy, możesz napisać mały skrypt LUA, który przyjmuje kombinację użytkownik / hasło, ale czeka X sekund na przetworzenie loginu, jeśli żądanie połączenia pochodzi z niezatwierdzonego zakresu adresów IP.

Ponadto można dodać trochę dodatkowej logiki do skryptu LUA do czarnych zakresów adresów IP po trzech nieudanych próbach.

Ogólnie rzecz biorąc, jest to technicznie wykonalne, ale idę z innymi zaleceniami, aby tunelować przez SSH lub VPN do wspólnego, białej listy (przez FW lub w inny sposób) zakresu adresów IP.

dlaczego nie zezwolić na dostęp do portu mysqld tylko z bezpiecznych hostów?

Chociaż nie jest to „prawdziwa” odpowiedź - nie wiem, dlaczego trzeba ją wystawiać bezpośrednio na świat zewnętrzny.

Nie możesz włączyć ssh na tym polu i użyć tunelowania, aby uzyskać dostęp do silnika db?

Lub każde inne rozwiązanie VPN, aby uzyskać do niego dostęp (przychodzi na myśl openvpn).

Nie jest to prawdziwe rozwiązanie problemu, ale może pomóc, jeśli po prostu uruchomisz serwer na innym porcie. Większość tych botów skanujących jest prawdopodobnie zaprogramowana tak, aby sprawdzały tylko 3306. To nie rozwiąże problemu, ale prawdopodobnie dostaniesz o wiele mniej skanów, po prostu zmieniając port.

Uważam, że połączenia powinny być zaporowe: szybkie i przyjemne. Istnieje wiele samouczków dla iptables i cokolwiek innego :)

Możesz także zainstalować cronjob na hostach klientów, który uruchomi coś na serwerze, aby zapora nie blokowała znanych hostów.

używanie ssh do tuneli byłoby najlepsze, ale możesz spróbować użyć fail2ban zamiast denyhosts, ponieważ myślę, że ma on na celu monitorowanie większej liczby różnych aplikacji, więc nie powinno być problemu z dodaniem do niego dziennika mysql.

Sugestia do rozważenia w sekcji my.cnf-ini [mysqld]

max_connect_errors=10  # to limit hacker/cracker attempts to guess a password.

aby uniknąć setek prób w 90 sekund. Odetnij je przy 10 próbach.

Rozważ raz dziennie FLUSH HOSTS, aby wyczyścić uprawnione osoby próbujące korzystać z twojego systemu, które NIE MOGĄ zapamiętać swojego hasła. Może za kilka dni to osiągną.