Jak to w końcu jest z tym rootem?

[mynod3 0]

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 Maj 12, 2013 przez mynod3 (zobacz historię edycji)

[N0Name 48]

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

[mynod3 0]

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.

[Miłosz 2311]

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

[Gość patrys]

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

[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.

 

[Pan Kot 1535]

 

 

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 .

 

 

 

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ć).

[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 ?

[Pan Kot 1535]

@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 .

[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

 

 

Nie no żart

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

[elcct 159]

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.

[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...

[PapaSmerf 497]

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.

[kafi 2425]

 

 

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

[Pan Kot 1535]

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).

[elcct 159]

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) ?

[d.v 1409]

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

 

Eeerrrmmm... QUE?

[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.v 1409]

@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.

[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

[elcct 159]

@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.

[d.v 1409]

@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.

[Pan Kot 1535]

 

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ł .

 

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 .

[kafi 2425]

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.

[kovalsky 22]

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.