Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Witam,
pytanie kierowane (wydaje mi się) przede wszystkim do administratorów sieci/usług we 'własnym ekosystemie', ale zostawiam dyskusję otwartą..
W jaki sposób można chronić usługi wystawione 'na świat' przed atakami wykorzystującymi serwery proxy ? Chciałbym dowiedzieć się od Was jakiś konkretnych rozwiązań, ponieważ niedługo będę musiał coś podobnego przeprowadzić i co 'gorsza' będę za to odpowiedzialny..
Pozdrawiam,
Michał
ps. Temat ochrony usług/serwera jest o wiele szerszy, dlatego można się też wypowiadać nie tylko w kontekście proxy, ale głównie tego dot. ten wątek..
Offline
Może napisz coś więcej. Co masz np. na myśli pisząc ataki wykorzystujące serwer proxy?
Offline
Hm.. Chodzi o to, że chcę wystawić usługę opartą o stronę WWW. Dodatkowo powiedzmy, że nie chcę wpuszczać tam ruchu z Azji. Ruch ten oczywiście może być maskowany, m.in. przez proxy.. jak z takim czymś najlepiej walczyć ?
Offline
Nie zwalczysz, a jeśli, to fail2ban jak pacjent będzie pytał tam gdzie go nie chcą, to kop na dupę i do czyśćca i tak np klientów którzy więcej niż np 5 razy chcą wpisać hasło na roota, albo biją na port od ssh
Przed ddosem nie ma w zasadzie jakiejś drastycznie dobrej metody, jak pół Chin zacznie wysyłać requesty to bez cloudflare raczej na pewno serwer przestanie odpowiadać, a nawet z nim wątpliwa jest obrona na bardziej zmasowany atak.
No a proxy tak jak wyżej, jak za dużo razy zapuka gdzie nie trzeba - np na port SSH, czy admina w wordpress, to kop do czyśćca na godzinę, a jak się powtórzy, to na dłużej.
Poza tym najlepiej wyłączyć login po haśle na ssh i wyłączyć root login (ci co się pchają na roota, od razu do czyśćca), a na http, głównie uprawnienia, szyfrowanie, fajnie włączyć tam gdzie są najbardziej "intymne" lokacje np. Weryfikowanie userow po certyfikatami sslowych (p12 client certs), no i jeśli jest możliwość, to po ograniczać uprawnienia na DB
Offline
@morfik, @thomsson - Rozumiem. Jest w tym, co piszesz, jakaś logika :) Dzięki za wypowiedź ;)
Ostatnio edytowany przez mikajlo (2016-05-22 10:32:05)
Offline