Skocz do zawartości
mynod3

Jak to w końcu jest z tym rootem?

Polecane posty

W każdym poradniku security jaki przeczytałem jest napisane, żeby konto roota wyłączać i logować się na userze po sudo. Ale z tego co widzę wielu doświadczonych użytkowników na tym forum konta root jednak używa. Tak na chłopski rozum wydaje mi się to sensowne bo skoro sudo daje pełne możliwości roota to jaki jest sens blokowania jego konta? Wiem, że sudo można ograniczyć do pewnych czynności i wtedy ma to sens ale za dużo z tym zabawy jak dla mnie.

 

Spotkałem się też z twierdzeniem, że podczas pracy na roocie wszystkie aplikacje pracują z prawami root co stwarza niebezpieczeństwo, w syt. gdyby ktoś przechwycił np. apache. Dodatkowo jest jeszcze podobno taka kwestia, że są sposoby przechwycenia roota nawet bez hasła. Jak to jest w praktyce, jeśli chciałbym używać roota z kluczami?

 

Dodatkowo mam jeszcze pytanie jak to jest z tym emailem roota. Kilka aplikacji typu csf ma opcje wysyłania maila do roota ale ten mail ma postać root@localhost czy jakoś tak. Gdzie te maile trafiają, jak zmienić email roota, czy jest możliwe żeby zrobić tak, aby maile trafiały na zewnętrzną skrzynkę typu wp.pl? :)

 

Takie troche może pytania podstawowe ale ciężko jest usystematyzować więdzę jadąc tylko na howtoforge :/ Także z góry dzięki za pomoc!

Edytowano przez mynod3 (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Zapewne chodzi o wyłączenie logowania się na roota poprzez ssh, wtedy możesz się logować na konta "xxx" i przelogować na roota.

Nie jestem w 100% pewny ale chyba o to chodzi :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Zapewne chodzi o wyłączenie logowania się na roota poprzez ssh, wtedy możesz się logować na konta "xxx" i przelogować na roota.

Nie jestem w 100% pewny ale chyba o to chodzi :)

 

 

Nie, chodzi mi o to czy korzystanie z roota logując się poprzez klucze rzeczywiście jest bezpieczne i czy wtedy nie ma (poza zdobyciem klucza prywatnego) możliwości przejęcia systemu. Czy tak można robić czy jednak lepiej wyłączyć i korzystać z sudo i jak to wpływa na bezpieczeństwo aplikacji czy tutaj coś się zmienia czy dla np. nginxa nie ma to znaczenia czy siedzisz na roocie czy na userze. Według mnie chyba nie ma ale chciałbym to ogarnąć na 100% :)

 

No i jak skonfigurować maila do roota na zewnętrzną skrzynkę, żeby alerty wychodziły poza serwer.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Wspomniany serwer www uruchamiasz na jego własnym użytkowniku, ewentualnie tworzysz jakiegoś. Dla Apache jest to np www-data lub apache.

Udostępnij ten post


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

Nikt normalny nie blokuje logowania przez ssh na konto root i nie używa do pracy w konsoli sudo ;-)

  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Łukasz Tkacz

@patrys

Dokładnie. Normalni ludzie działają tylko na koncie root, a jego hasło ustawiają tak jak login aby czasem nie zapomnieć. Sudo? A na co to im. Procesy serwera czy np. PHP tez lecą na tym koncie, aby uniknąć jakichś bezsensownych problemów z uprawnieniami (kto by się bawił). Port ssh domyślny, jeżeli logowanie po kluczu to jest on wrzucony na jakąś super hiper tajna stronę i do pobrania gdy zna się adres, wszystko aby mieć zawsze dostęp.

 

;)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

 

Nie, chodzi mi o to czy korzystanie z roota logując się poprzez klucze rzeczywiście jest bezpieczne i czy wtedy nie ma (poza zdobyciem klucza prywatnego) możliwości przejęcia systemu. Czy tak można robić czy jednak lepiej wyłączyć i korzystać z sudo i jak to wpływa na bezpieczeństwo aplikacji czy tutaj coś się zmienia czy dla np. nginxa nie ma to znaczenia czy siedzisz na roocie czy na userze. Według mnie chyba nie ma ale chciałbym to ogarnąć na 100% :)

 

No i jak skonfigurować maila do roota na zewnętrzną skrzynkę, żeby alerty wychodziły poza serwer.

 

Pokaże Ci to na paru przykładach.

 

Security lvl 1:

Wiemy, że konto ma nazwę "root" i jakieś hasło, SSH stoi na defaultowym porcie 22.

 

Security lvl 2:

Wiemy, że konto ma nazwę "root", ale po wstępnej próbie widzimy, że hasło jest zablokowane. Domyślamy się, że można się zalogować po haśle do jakiegoś usera, ale usera nie znamy, liczba kombinacji wydłuża nam się do liczby astronomicznej.

 

Security lvl 3:

Wiemy, że coś takiego jak root istnieje, ale nie możemy logować się po haśle, a jedynie po kluczu. Nie wiemy gdzie to SSH stoi, a nawet jeśli byśmy wiedzieli to nie znamy loginu usera, który ma włączone logowanie po haśle. Nawet jeśli byśmy poznali i port i usera to i tak ograniczamy się do kilku prób per IP bo na serwerze działa LFD lub inny Fail2Ban.

 

 

Security lvl 4:

Coś takiego jak root nie istnieje, do SSH nie możemy się w ogóle zalogować jako root. Nie wiemy gdzie to SSH stoi, a nawet jeśli byśmy wiedzieli to nie znamy loginu usera, który ma włączone logowanie po haśle. Nawet jeśli byśmy poznali i port i usera to i tak ograniczamy się do kilku prób per IP bo na serwerze działa LFD lub inny Fail2Ban.

 

 

Pomiędzy punkt 2 i 3 można by wstawić jeszcze kilka, ale ograniczyłem to do minimum. W skrócie - klucz SSH to tak naprawdę hasło 4096-znakowe (zależy od liczby bitów podczas generowania) i działa dokładnie w ten sposób. Ja osobiście na serwerze używam wariantu 3. Musisz po pierwsze znaleźć port SSH (to jest wykonalne, ale na pewno nie z jednego IP bo CSF Cię wytnie), następnie odnaleźć właściwą nazwę usera (bo na roota nie wejdziesz), a następnie brute-force'ować tego konkretnego usera. Jeśli na serwerze działa jakikolwiek daemon, który monitoruje takie próby to nawet z milionowym botnetem ograniczyłbyś się do 5 milionów prób, a wystarczy niezbyt długie hasło, żeby tą liczbę zwiększyć. Już w ogóle pomijam fakt, że nawet jak wejdziesz na tego mojego usera to musisz jeszcze złamać zupełnie inne hasło na samego roota, żeby wejść komendą su. No jak ktoś ma sudo to ma ten punkt z głowy wtedy. No i oczywiście zupełnie pomijam fakt, że tak naprawdę mamy jeszcze grsecurity, paxa, a już przy x próbie samego skanu czy brute-force'a serwer by to wykrył i wyłączył jakiekolwiek interakcje z portem SSH jedynie do mojego zaufanego IP i VPN'a, który sobie tam śmiga (a tu logowanie jest wyłącznie po kluczu, a konkretniej to keyu i certyfikacie).

 

Efekt? Śmiem sądzić, że prościej jest mi się włamać na komputer stacjonarny lub bezpośrednio do domu niż do SSH na serwerze :D.

 

 

 

Odnośnie wojny root vs sudo to powiem to tak... W przypadku roota musisz się dostać na roota, a w przypadku sudo na tego konkretnego usera. Bazując na przykładzie wyżej root jest bezpieczniejszy niż sudo, ale na ogół na niezabezpieczonych serwerach sudo jest bezpieczniejsze (bo na roota w ogóle nie można się dostać).

  • Upvote 1

Udostępnij ten post


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

@patrys Dokładnie. Normalni ludzie działają tylko na koncie root, a jego hasło ustawiają tak jak login aby czasem nie zapomnieć. Sudo? A na co to im. Procesy serwera czy np. PHP tez lecą na tym koncie, aby uniknąć jakichś bezsensownych problemów z uprawnieniami (kto by się bawił). Port ssh domyślny, jeżeli logowanie po kluczu to jest on wrzucony na jakąś super hiper tajna stronę i do pobrania gdy zna się adres, wszystko aby mieć zawsze dostęp. ;)

 

 

No i po co pajacujesz ?

Pisałem Ci gdzieś o czymś innym niż "allow root" i korzystaniu z niego w konsoli przez administratora ?

Wyłączenie logowania jedynie utrudni pracę przez dodatkowe prze logowanie, nie dając sensownego zabezpieczenia przed atakiem.

Sudo jest bardzo potrzebne w serwerach dla ich bezpieczeństwa, aczkolwiek nie w pracy z wykorzystaniem SSH przez administratora.

Ostatnio popularny jest Ubuntu, dość dobrze działają na nim platformy IBM/HP/DELL i w ogóle jest cool.

Ale to nie znaczy, że jak w poradniku ala howtoforge mamy komendy z sudo, to jest to dobre rozwiązanie ;)

 

@Archi: nie czytałem, bo takie to długie, a mamy niedziele.

Jednak patrząc po wstępie lvl4, to robimy lvl5 w którym SSH nie jest dostępne z zewnątrz, a dla wybranych mega zaufanych hostów i problem znika ? :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@patrys

A jak, właśnie tak to powinno działać ;). Każdy kolejny lvl - większe bezpieczeństwo, możesz dojechać i do lvl99 z kodami sms na komórkę, ldapem i kluczem 8192-bitowym tylko po to, żeby dostać się do adresu IP i portu serwera OpenVPN, z którego dopiero serwer akceptuje jakiekolwiek żądania na SSH :D.

Udostępnij ten post


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

Dla upartych można też kupić kilka VPSów i logowanie na pierwszego ma tylko IP z domu, logujemy się z pierwszego VPSa na drugiego gdzie tylko zezwolone jest logowanie z VPSa pierwszego i z tego drugiego logujemy się dopiero na serwer docelowy a na każdym jest serwerze na inne konto i inne hasło :D

 

 

Nie no żart :D

Ale nawet brute-force leci kilka i albo serwer atakujący odpuszcza, albo FB blokuje go na jakiś czas i odpuszcza...

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dostęp do serwera tylko osobiście, po skanie siatkówki oka i zbadaniu dna próbki nasienia i tylko na maksymalnie pół godziny - po tym czasie należy powtórzyć procedurę autentykacji.

Udostępnij ten post


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

Dostęp do serwera tylko osobiście, po skanie siatkówki oka i zbadaniu dna próbki nasienia i tylko na maksymalnie pół godziny - po tym czasie należy powtórzyć procedurę autentykacji.

Za dużo trzepania, w przypadku gdy trzeba posiedzieć na serwerze nieco dłużej, np kilka godzin...

  • Upvote 2

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

procedurę autentykacji.

 

Nie ma takiego słowa. Uwierzytelnianie. Ale to tak w kwestii czepiania się ;)

 

Za dużo trzepania, w przypadku gdy trzeba posiedzieć na serwerze nieco dłużej, np kilka godzin...

 

Paweł, ale jakie pozytywy. Ręce sprawniejsze, krążenie się poprawi. Same plusy.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

 

Wiemy, że konto ma nazwę "root", ale po wstępnej próbie widzimy, że hasło jest zablokowane.

Takie coś to tylko przy użyciu backdoora ./szklana_kula.sh

Mnie zawsze się wydawało, że zwracane jest ACCESS DENIED i to niezależnie od tego, czy:

a) konto jest zablokowane

b) konto ma zablokowane logowanie ssh (DenyUsers)

c) konto jest konfigurowane do uwierzytelniania kluczem a realizowane jest logowanie hasłem

d) system odrzuca jakiekolwiek logowanie przy użyciu haseł

 

A co do wyższości sudo nad pracą bezpośrednio na koncie roota: to miało by to sens, ale gdyby osoba pracująca na koncie umiała używać organu zwanego mózgiem. A patrząc na laików oczekujących poradnikuf do wszystkiego czego się da, to w tych poradnikach jest sudo cośtam, a dany delikwent i tak klepie na pałę nie zastanawiając się nawet, co to jest to sudo.

 

Widać czasem kwiatki przeglądając się takim osobom, którym dano Debiana z konsolą roota, a oni machinalnie sudo apt-get install ;)

  • Upvote 2

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Takie coś to tylko przy użyciu backdoora ./szklana_kula.sh

 

Nie do końca, serwer może zwrócić "server sent publickey" w przypadku gdy hasła sa całkowicie zablokowane dla danego konta tj. passwordauthentication usera jest na no, a roota without-password (czyli only key).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Istnieje taki system, że root loguje się używając np. nazwa_uzytkownika jako login, ale w rzeczywistości loguje go jako root

 

Natomiast jak ktoś loguje się jako root, w rzeczywistości loguje go do maszyny wirtualnej z jakimś linuxem po jakimś czasie, która nie ma dostępu do internetu i sieci lokalnej (taki trolling) ?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

"(...) loguje go do maszyny wirtualnej (...) która nie ma dostępu do internetu(...)

 

Eeerrrmmm... QUE?

Udostępnij ten post


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

Może chodziło o to że wprowadza bota do ślepej uliczki gdzie niby się zalogował na roota hurra patrzy a tu zonk bo nic nie może zrobić chociażby pinga puścić do wp.pl :D

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@Kam: dobra, niech będzie, że się komuś będzie chciało. Pozostaje pytanie o sens takiego czegoś. Tracić czas i zasoby, nawet niewielkie, na takie zabawy jest dl;a mnie totalnie poronionym pomysłem. Rozumiem, że elcct podał to jako swego rodzaju "trening umysłowy", czystą teorię, ale znam takich, którzy zaraz będą takie rzeczy wprowadzać w życie, "bo na forum napisali". Z wielu powodów lepiej odradzać takie zabawy, choćby z powodów ekologicznych - każda maszyna zużywa prąd, utrzymanie takiej wirtualki darmowe nie będzie, jakieś tam waty na to pójdą ;)

 

Co do tematu dyskusji, to osobiście jestem zwolennikiem prostych działań. Na roota się na swoje serwery loguję, nie powiem. Po kluczach (kilku różnych), bez hasła, na różnych portach, zdarza się, że i na 22 w przypadku niedużych, mało istotnych serwerków. Klucze mam zapisane na swoim telefonie - jest to jedyna rzecz, którą mam zawsze pod ręką i do której nie mają dostępu inni. Do tego najczęściej jest jeszcze dość restrykcyjny f2b, który śmiało i bez ostrzeżenia rozdaje kopy na prawo i lewo. I niech mi ktoś powie po ch...olerę więcej kombinować? Nigdy, powtarzam, nigdy nie miałem problemu z włamem via SSH. Prędzej ciała dadzą "tfurcy" jakiegoś skryptu czy demona i mniej lub bardziej świadomie pozostawią jakąś lukę, przez którą niepowołane osobniki mogą nabałaganić na naszych serwerach. Demonizowanie zagrożeń stało się nową religią dla niektórych. A prawda jest taka, że najwięcej szkód w ostatnich latach przynoszą nie włamy ale (D)DoS-y, na które lokalne zabezpieczenia gówno pomogą. Poza tym jak nie masz dużego, popularnego serwisu, to raczej nikt z wiedzą nie będzie tracił czasu na włamania, a na "script kiddies" dość "standardowe" zabezpieczenia (wymienione wyżej) wystarczają w zupełności. Jeśli natomiast masz popularny serwis, to masz z niego dość środków, żeby zatrudnić kogoś, kto ma szeroką wiedzę na ten temat i ogarnie ci zabezpieczenia i nie martwisz się takimi rzeczami, a nawet z DDoS w wielu przxypadkach sobie poradzisz, zatrudniając do tego dostawców "chmurowych" typu CloudFlare czy im podobnych.

  • Upvote 2

Udostępnij ten post


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

Łukasz ja to raczej napisałem w formie żartu niż rozwiązania :)

 

Obecnie to chyba najbezpieczniejszy jest lokalny dostęp bez dostępu do internetu hehe :D

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@Kam: dobra, niech będzie, że się komuś będzie chciało. Pozostaje pytanie o sens takiego czegoś. Tracić czas i zasoby, nawet niewielkie, na takie zabawy jest dl;a mnie totalnie poronionym pomysłem. Rozumiem, że elcct podał to jako swego rodzaju "trening umysłowy", czystą teorię, ale znam takich, którzy zaraz będą takie rzeczy wprowadzać w życie, "bo na forum napisali". Z wielu powodów lepiej odradzać takie zabawy, choćby z powodów ekologicznych - każda maszyna zużywa prąd, utrzymanie takiej wirtualki darmowe nie będzie, jakieś tam waty na to pójdą ;)

 

 

Ale ktoś włamując się na wirtualkę popełnia przestępstwo, więc można to zgłosić i jest szansa, że odpowiednie służby się zajmą i delikwent przestanie się włamywać. W przypadku f2b i podobnych takiej możliwości nie ma.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@elcct: znając z autopsji opieszałość naszych prokuratorów w takich sprawach wolę im nawet szanownych napchanych paragrafami głów nie zawracać (czyli po prostu szkoda mi czasu na pierdoły) i wolę sam sobie skutecznie poradzić.

Przy okazji chciałbym pochwalić polską policję, która często dwoi się i troi, żeby obywatelowi pomóc, niestety sama też rozbija się o mur prokuratorskiej biurokracji i urzędniczej niemocy.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Ale ktoś włamując się na wirtualkę popełnia przestępstwo, więc można to zgłosić i jest szansa, że odpowiednie służby się zajmą i delikwent przestanie się włamywać. W przypadku f2b i podobnych takiej możliwości nie ma.

 

Jakbyś się uparł to LFD posiada sam w sobie nawet funkcję informowania mailowo @abuse dla konkretnego providera, tylko kto by się tymi reportami przejmował :D.

 

Nie wiem jak stoi prawo z włamaniami, ale mając logi nieautoryzowanych prób zalogowania chyba też można się tym podeprzeć bo raczej sama próba włamania do np. domu również podlega jakiejś karze, a nie tylko efekt dokonany ;).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Istnieje taki system, że root loguje się używając np. nazwa_uzytkownika jako login, ale w rzeczywistości loguje go jako root

 

Natomiast jak ktoś loguje się jako root, w rzeczywistości loguje go do maszyny wirtualnej z jakimś linuxem po jakimś czasie, która nie ma dostępu do internetu i sieci lokalnej (taki trolling) ?

Jak najbardziej jest. Takie coś zwie się honeypotem.

Wystarczy edytować plik /etc/passwd i zmienić sobie linijkę użytkownika UID=0,

a następnie dodać użytkownika o loginie root z jakimś wysokim uid i przypisać

mu jakąś śmieszną powłokę - emulator terminala, vzctl enter, ssh wlamywacz@1.2.3.4

czy inna zabawka.

  • Upvote 2

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Nie wiem jak stoi prawo z włamaniami, ale mając logi nieautoryzowanych prób zalogowania chyba też można się tym podeprzeć bo raczej sama próba włamania do np. domu również podlega jakiejś karze, a nie tylko efekt dokonany ;).

 

...oj tam. Pewnie ktoś pomylił IP i sfrustrowany próbował się zalogować, a wy już panikujecie, bany jakieś, abuse'y. :P

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ę


×