Skocz do zawartości
crazyluki

Problem z blokowaniem botów/ bruteforce attack

Polecane posty

Ty także.

Zacznijmy od tego:

 

Wyjaśnij mi, jaka jest różnica, czy polecenie

iptables -A INPUT -p tcp --dport 22 -j DROP

wykonam sobie z poziomu ssh, czy też wykonam wplecione w skrypt?

Tak czy siak utracę dostęp do serwera, więc poza względną wygodą zmiany czegoś-tam to nie widzę przewagi jednym nad drugim.

 

 

Tu żaden IDS nie jest potrzebny. Wystarczy nakłonić kernel, aby blokował tych delikwentów, którzy łączą się z czymś innym, niż wystawione przez nas usługi.

 

 

Jak już mówimy o exploitach, to duża część z nich ma na celu eskalację uprawnień roota, więc i na porcie 22 wtedy sobie coś odpalą...

 

 

PHP? Chyba na stockowej konfiguracji apt-get install apache2 php5

Jeśli się troszkę posiedzi (wyrzucenie modułów posix, blokada funkcji dl, exec, system itp., pseudo-open_basedir i parę innych rzeczy) to nie wykonasz poleceń systemowych.

 

A jeśli nawet, to na samym końcu przychodzi ipt_owner, który pozwoli brutalnie wyciąć szkodnikom dostęp do świata zewnętrznego smile.png

 

no to teraz wyczysc sobie firewalla bo chcialbys od poczatku zaczac sobie ustawiac jego konfiguracje...

 

php to był przykład, sposobów jest 1000ce

 

 

Pokaż jakiś remote exploit który wyłączał serwer openssh, bo nie przypominam sobie niczego w galęzi 4.x/5.x.

 

Nigdy nie padł mi sshd, nigdy też nikt nie przełamał się przez niego do systemu bez wcześniejszej autoryzacji.

To znaczy, że źle ?

 

Każdy serwer zabezpiecza się pod kątem jego zastosowania w sieci.

Zabezpieczenie via kernel na zakres portów sprawdza się w danych środowiskach, inaczej by nie powstało i nie było by go już.

Jednak serwery mają tysiące zastosowań i nie na każdym są konta shell czy inne usługi wywołujące potencjalne zagrożenie dla wykonania niebezpiecznego kodu, czy później uruchomienia programu na określonym porcie.

 

Utrzymując odpowiednia politykę bezpieczeństwa nie zajdą takie procesy o których piszesz.

Nie będzie wtedy też naruszeniem uruchomienie serwera OpenSSH na porcie 1024-65000.

 

 

nie komentuję.

 

no widzisz, mi sie nie raz zwiesilo ssh na serwerach produkcyjnych z prawdziwego zdarzenia

 

mam dla Ciebie doskonala lekture http://pl.wikipedia.org/wiki/Security_through_obscurity

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Cóż, widać merytoryczność twojej wypowiedzi skończyła się na odpyskówkach, a szkoda...

 

no to teraz wyczysc sobie firewalla bo chcialbys od poczatku zaczac sobie ustawiac jego konfiguracje...

Jak odetniesz sobie dostęp, to tak czy siak nie wyczyścisz reguł firewallowych bez fizycznego dostępu.

Ba. W przypadku klepania polecenie po poleceniu to puścisz hard-reboot przez jakąś listwę pdu i serwer wróci.

Powiadasz, że archiwum byś chciał... history | grep iptables ;)

A w przypadku init-scriptu restart nie przejdzie, bo po nim i tak załaduje te regułki wink.png

 

 

php to był przykład, sposobów jest 1000ce

No cóż, wymień te tysiące innych sposobów na środowisku nawet i hostingowym.

Powtórzę: owszem, exploitów jest od groma. Ale duża część z nich prowadzić ma do eskalacji uprawnień, a wtedy to user sobie dowolneco dowolniegdzie odpali i o tym wiedzieć nie będziesz wink.png

Kwestia tylko ROZUMIENIA i WIEDZY jak przed różnymi takimi trickami się pozabezpieczać.

Ot chociażby linijka

 iptables -A OUTPUT -m owner ! --uid-owner 0 -p tcp --sport 1234 -j DROP

która w miarę skutecznie twoje tezy o wielkim niebezpieczeństwie portów >1024 podważa wink.png

 

A jak ktoś przebrnie przez to? To i pewnie ma taką zdolność, co by i odpalić sobie aplikację na porcie <1024 wink.png

Edytowano przez kafi (zobacz historię edycji)
  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrys

W sumie to Kafli wyczerpał temat...

 

no widzisz, mi sie nie raz zwiesilo ssh na serwerach produkcyjnych z prawdziwego zdarzenia

 

mam dla Ciebie doskonala lekture http://pl.wikipedia....rough_obscurity

To chyba nie dobrze? Cudowna lektura, jednak myślę że pomyliłeś forum, a na pewno ludzi.

 

Więc podsumowując możemy ustawić port 1024-65000 dla usługi OpenSSH, nie zawiesi nam się i nikt nie uruchomi w to miejsce aplikacji przy sensownie ustawionym serwerze.

Zmiana portu na wyższy uchroni serwer przed różnymi skanowaniami przez boty, co polecamy użytkownikom.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@BOFH: przy założeniu, że z Twoim systemem jest wszystko ok ( chociaż nie jest skoro sshd Ci często "pada" ),

w jaki sposób chcesz wymusić SIGSEV na procesie macierzystym sshd, aby móc się zabindować na porcie...

nawet nie 22 ( co może tylko root ), niech będzie 2255 ( który lubię ja i jest powszechnie dostępny ) ?

 

To co napisałeś jest prawdopodobne do wykonania tylko i wyłącznie wtedy jeśli via UID > 0

uda Ci się wywieźć proces macierzysty nasłuchującej usługi ( uruchomionej z UID 0 ) na manowce.

( pomijam już fakt chmod 0600 na klucze SSH i niemożność ich wykorzystania prze alternatywny daemon...) Ciekaw jestem jak Tobie się to uda. Biorąc pod uwagę architekturę sshd,

a także fakt, iż nawet kernel shitowego systemu posiada z dnia na dzień coraz więcej zabezpieczeń,

pomijając te oczywiste, daje Ci osobiście większą szansę na wygraną w lotto aniżeli na hack sshd.

 

P.S. Nie czepiam się. Chcę pogadać. Jeśli wolisz, to zapraszam na PW.

  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

szczerze to stracilem chec na wypowiadanie sie, serio nie mam ochoty na takie jalowe dyskusje i wymyslanie na pokaz, bo omijanie wbudowanego security, a nastepnie latanie dodatkami jak iptables to samo za siebie mowi jak ktos sie nadaje na admina, polecam takie opowiesci na rozmowie rekrutacyjnej, to z pewnoscia praca sie trafi...

 

jesli sadzisz ze zablysles tym wpisem iptables to chyba Cie rozczaruje, bo to jedna z glownych metod zabezpieczania m.in. serwera www po przez np. blokowanie polaczen wychodzacych...

 

btw, sadzisz ze na przykladowo honeypot wyskocza ci ostrzezenia ze odcisk sie nie zgadza? kiedy nie bedziesz sie laczyc na ssh w rzeczywistosci? eh... potestuj

 

no kernel posiada co raz to wiecej zabeczpien, a jak widac ludzie wola je omijac, niz stosowac... sub system audytu w kernelach 2.6 to jeden z najlepszych IDS, taki szczegol, a 3/4 nie wie nawet jak z tego korzystac...

 

btw, ssh mi czesto nie pada na 1 systemie czy serwerze, czy nawet marce, tylko co jakis czas sie wiesza i nie jest to niczym nowym zreszta... jak masz pare serwerow to wiadomo ze statystycznie bedzie sie wieszac rzadko, a jak masz kilka klastrow serwerow to troche inaczej wyglada sprawa...

 

co do skryptu z firewallem, to sprawa wyglada tak, ze jak go odpalisz to wyczyscisz konfiguracje i zbudujesz nowa, a jak sobie to samo wkleisz to wyczyscisz i odetniesz dostep, chyba proste i logiczne, ale widze ze niektore osoby wola dalej szukac dziury w calym tak samo jak z powyzszym wiec dam sobie jak juz pisalem spokoj, bo szkoda czasu na takie "dyskusje"...

Edytowano przez B0FH (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×