Skocz do zawartości
  • 0

[Zlecenie]Blokada komend :)


XeVeDo

Pytanie

Witam chciałbym prosić o skrypt do zabezpieczenia serwera mianowicie ma on robić tak konsola nie może wykonać żadnej komendy(wyświetla się komunikat) i aby wykonać komendę z konsolki trzeba zrobić tak "$ %KOMENDA%" i żeby bez tego $ komenda nie działała i tez whitelist chodzi mi o zabezpieczenie itemshopu(rcon) i w tej bialej liscie np komenda "pex user %NICK% group set vip" żeby nie trzeba było wpisywać $ ponieważ atakujący możne poznać jak to wykorzystać :) i to na stałe pex user jedyna wartosc, która może się zmienić to nick jak zmieni się np. vip na admin to komenda się nie wykona.

Edytowane przez XeVeDo
Odnośnik do komentarza
Udostępnij na innych stronach

10 odpowiedzi na to pytanie

Rekomendowane odpowiedzi

  • 0

Ale kombinujesz, robisz sklep z głową, nie dajesz nikomu niezaufanemu dostępu do maszyny i jesteś bezpieczny. Żadnych skryptów, żadnych dolarów w konsoli. Tylko byś sobie życie utrudniał, a potencjalny włamywacz jak dostanie sie do konsoli to i tak wszystko będzie mógł już zrobić.

Odnośnik do komentarza
Udostępnij na innych stronach

  • 0

@Bielecki Nikt nie ma dostępu do maszyny, ale gdy trafi się exploit na linuxa to lipa :) i mój item shop od bojawiem55 jest zabezpieczony ioncube więc trochę podejrzliwie na niego patrze, ponieważ nie mogę zajrzeć w kod mi chodzi, tylko że jak ktoś znajdzie lukę w IS/vps nie mógł nic zrobić na vps stroi tylko itemshop a reszta serwera na titanaxe więc to ma sens bo do titana będzie to trudne :) a utrudnianie życia eee tam kwestia przyzwyczajenia.

 

@piotrus131102 A.(konsola)Wpisujesz komendę /op %nick% -> Blokada(wiadomość)

B.(konsola) wpisujesz komendę $ /op %nick% ->komenda się wykonuję

C.(konsola) wpisujesz komendę /pex user %nick% group set vip (komenda wykonuje się pomimo braku $ ponieważ znajduję się na białej liście)

D.(konsola) wpisujesz komendę /pex user %nick% group set admin(komenda blokowana jak w A)

Edytowane przez XeVeDo
Odnośnik do komentarza
Udostępnij na innych stronach

  • 0
Godzinę temu, XeVeDo napisał:

@Bielecki Nikt nie ma dostępu do maszyny, ale gdy trafi się exploit na linuxa to lipa :) i mój item shop od bojawiem55 jest zabezpieczony ioncube więc trochę podejrzliwie na niego patrze, ponieważ nie mogę zajrzeć w kod mi chodzi, tylko że jak ktoś znajdzie lukę w IS/vps nie mógł nic zrobić na vps stroi tylko itemshop a reszta serwera na titanaxe więc to ma sens bo do titana będzie to trudne :)

Hostujesz serwer dla 1000 osób? 500? Nie sądzę. Więc szanse, że ktoś będzie próbował się wbić są niskie.

A nawet jeśli - exploit na Linuksa? To tracisz całą maszynę. Są wartościowsze rzeczy niż włamanie się do Twojego IS, ie. botnet. Rób regularnie update i backupy i tyle. Użyj klucza publicznego zamiast hasła i, jeśli jesteś paranoikiem, zmień sobie port do ssh. Ja mam wielu wrogów, którzy chętnie by mi rozwalili całego dedyka, ale jakoś nikomu się jeszcze włamać nie udało, mimo że ostatnio zaglądam tam dość rzadko.

A jak masz obfuscowany IS i mu nie ufasz, to sobie go zmień, zawsze może tam być backdoor - bardziej tym bym się martwił, niż faktem, że ktoś Ci wbije na maszyne.

I na serwery hostowane włamać się wcale nietrudno, na pewno łatwiej, niż na z głową zabezpieczonego VPS/dedyka.

Odnośnik do komentarza
Udostępnij na innych stronach

  • 0

Właśnie z powodu nmapa (którego notabene możesz na tyle znacznie spowolnić, że np. u mnie potrzebujesz kilku maszyn, żeby w sensownym czasie skanować porty) uważam, że zmiana portu jest bez sensu, aczkolwiek blokuje to maszyny, które globalnie skanują otwarty 22-gi i testują popularne dane logowania - a tu z kolei wchodzi wyłączenie logowania plain textem i zostawienie wyłącznie klucza publicznego.

Edytowane przez Bielecki
Odnośnik do komentarza
Udostępnij na innych stronach

  • 0
38 minut temu, XeVeDo napisał:

co do zmiany portu ssh to jedne polecenie nmap ;D

Masz racje, ale boty skanują zwykle standardowe porty (tj. do SSH port 22) i to właśnie w ramach obrony przed nimi sie go zmienia, jednak bardziej zaawansowany bot nadal jest w stanie poznać port, o ile jest otwarty w firewallu. I według mnie ograniczenie połączeń na port SSH i/lub port RCON dla zaufanych adresów IP jest chyba najlepszym rozwiązaniem w tym przypadku.

A jeżeli autor nie ufa itemshopowi to może ograniczyć nowe połączenia z serwera na którym jest IS tylko do połączeń na port RCONa a na serwerze na którym jest odpalony Minecraft zrobić proxy filtrujące do RCONa które będzie akceptowało komendy tylko według warunków jakie sobie tam zaprogramuje (pod warunkiem, że są to dwa osobne serwery). Potem zablokować port do "prawdziwego" RCON, a port proxy do RCONa odblokować dla zaufanych adresów IP. Mimo wszystko, są serwery po wymienione wyżej 500 osób które nie stosują takich zabezpieczeń i jak narazie większość dobrze sie trzyma, więc nie wiem czy jest sens sie w to bawić.

 

P.S. Takie proxy do RCONa możesz w łatwy i przyjemny sposób w Pythonie zrobić, polecam :)

Edytowane przez Toranktto
Odnośnik do komentarza
Udostępnij na innych stronach

  • 0
2 minuty temu, Toranktto napisał:

według mnie ograniczenie połączeń na port SSH i/lub port RCON dla zaufanych adresów IP jest chyba najlepszym rozwiązaniem w tym przypadku.

Z RCONem się zgodzę. Z SSH nie. Z tego prostego powodu, że dopóki nie masz zapewnionego statycznego IP (a w Polsce w większości jest właśnie dynamiczne), to ustawisz, a za tydzień się już nie zalogujesz i będziesz liczyć tylko na szczęście, jeśli firma z której masz maszynę daje dostęp przez przeglądarkę (ie. OVH).

Odnośnik do komentarza
Udostępnij na innych stronach

Nieaktywny
Ten temat został zamknięty. Brak możliwości dodania odpowiedzi.
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...