🚀 go-pugleaf

On 2024-11-29, Kazik Kaz <kazik.kaz@no.email> wrote:
> Dzień dobry,
>
> W każdym podręczniku czy też zaleceniach napisanych przez 
> "bezpieczniaka" - jak się wydaje nie będącego nigdy administratorem 
> systemu jest wymaganie, aby nie można było się logować na konto root 
> bezpośrednio. Oczywiście magia działa i pozostaje wtedy czarodziejskie 
> sudo i powielanie bezmyślnie jakichś "leninowskich" idei.
>
> Po zastanowieniu się, można dojść do wniosku, że to nie ma głębszego 
> sensu, bo podczas sudo należy przecież podać hasło uprawnionego 
> użytkownika.
>
> Zatem, jeśli w systemie jest dwóch albo i więcej uprawnionych do sudo 
> użytkowników (np. w firmie 24h na 3 zmiany) to prawdopodobieństwo 
> atakującego wzrasta proporcjonalnie do liczby uprawnionych, dając mu 
> tyle razy większe szanse przechwycenia hasła uprawnionego administratora 
> ilu uprawnionych np. poprzez jakąkolwiek inwigilację któregokolwiek z nich.
>
> Np. konsola serwera (ta "namacalna") z reguły jest fizycznie w 
> wydzielonym pomieszczeniu, więc jakiś tam Myhyta albo Grigorij nie ma 
> tam dostępu - zatem pozostaje problemem dostęp zdalny. Dostęp zdalny 
> może zabezpieczyć klucz SSH, który aby pozyskać, ale należy "wzbogacić" 
> o hasło, bo inaczej nie ma żadnej wartości.
>
> Więc jakie tego sens?
> Czy widzicie jakiś za i przeciw takiemu postępowaniu?

Nie widzę większego sensu w używaniu sudo jeśli jest 2ch lub więcej 
administratorów (doświadczonych) z pełnym prawem dostępu. Sens może być, 
jeśli mamy konieczność wykonywania tylko wybranych poleceń, przez 
wybranych użytkowników, na prawach roota.

Widzę też pewien sens dla początkujących użytkowników (administratorów), 
gdzie MZ istnieje dużo większe prawdopodobieństwo, że taki użytkownik 
działając na powłoce z pełnym dostępem, w którymś momencie się zapomni i 
narobi szkód. Praktyka "sudo polecenie + hasło*" z nieuprzywilejowanego 
konta, daje w takim wypadku okazję aby się ewentualnie zreflektować.

*) a jak za jakiś czas osiągnie etap ALL=(ALL) NOPASSWD: ALL to może już 
wystarczająco czaić, choć pewnie różnie z tym bywa.

-- 
Marcin

W dniu 29.11.2024 o 21:25, Kazik Kaz pisze:
> W każdym podręczniku czy też zaleceniach napisanych przez 
> "bezpieczniaka" - jak się wydaje nie będącego nigdy administratorem 
> systemu jest wymaganie, aby nie można było się logować na konto root 
> bezpośrednio. Oczywiście magia działa i pozostaje wtedy czarodziejskie 
> sudo i powielanie bezmyślnie jakichś "leninowskich" idei.
Jeśli ktoś może używać sudo, to może napisać sudo bash i już ma powłokę 
na prawach roota. Działa to nawet tam, gdzie jest zablokowane 
bezpośrednie logowanie na roota, np. przez ssh. Może więc przestańmy 
zawracać sobie głowę.

mirekc <mirekc@interia.pl> writes:

> W dniu 29.11.2024 o 21:25, Kazik Kaz pisze:
>> W każdym podręczniku czy też zaleceniach napisanych przez
>> "bezpieczniaka" - jak się wydaje nie będącego nigdy administratorem
>> systemu jest wymaganie, aby nie można było się logować na konto root
>> bezpośrednio. Oczywiście magia działa i pozostaje wtedy
>> czarodziejskie sudo i powielanie bezmyślnie jakichś "leninowskich"
>> idei.
> Jeśli ktoś może używać sudo, to może napisać sudo bash i już ma
> powłokę na prawach roota. Działa to nawet tam, gdzie jest zablokowane
> bezpośrednie logowanie na roota, np. przez ssh. Może więc przestańmy
> zawracać sobie głowę.
>

Oczywiście że może, podobnie, jak może z owego roota zrobić "rm -rf /"
IMO to jest kwestia higieny i ostrożności.
Ja np, w swoich skryptach (często jednolinijkowych :) ) robię coś w rodzaju
sudo "<wyciągnij logi których user nie może>" | ...przetwarzaj jako
user...

mógłbym to przetwarzanie robić jako root również w sesji roota, ale po
co? Po ostatniej aferze z xz widać, że nawet binarki nie muszą byc zaufane.
KJ
-- 
http://wolnelektury.pl/wesprzyj/teraz/
można nie mieć nawet żadnego sensownego argumentu, a dzięki odpowiedniej
gestykulacji stworzyć poczucie wiarygodności.
Puls Biznesu

Pan Marcin Debowski napisał:

>> Zatem, jeśli w systemie jest dwóch albo i więcej uprawnionych do sudo 
>> użytkowników (np. w firmie 24h na 3 zmiany) to prawdopodobieństwo 
>> atakującego wzrasta proporcjonalnie do liczby uprawnionych, dając mu 
>> tyle razy większe szanse przechwycenia hasła uprawnionego administratora 
>> ilu uprawnionych np. poprzez jakąkolwiek inwigilację któregokolwiek z nich.

Nic z tych rzeczy. Jak to ma być poważny serwer, to i tak ma wszystkie
hasła zablokowane. Logowanie kluczem z innego komputera (który jeśli
nawet jest wystawiony w Internecie, to w sposób ograniczony, a do tego
bad guyowi trudno odgadnąć, który to).

> Nie widzę większego sensu w używaniu sudo jeśli jest 2ch lub więcej 
> administratorów (doświadczonych) z pełnym prawem dostępu. Sens może
> być, jeśli mamy konieczność wykonywania tylko wybranych poleceń, przez 
> wybranych użytkowników, na prawach roota.

Jest dokładnie odwrotnie. Gdy administrator jest jeden, to do nikogo
o nic nie może mieć pretensji i robi jak uważa. Gdy jest ich więcej,
to warto znać historię logowań każdego z nich.

> taki użytkownik działając na powłoce z pełnym dostępem, w którymś
> momencie się zapomni i narobi szkód.

Określenie SOA#1 (standardowa odpowiedź administratora numer 1: u mnie
działa) skądś się wzięło. Łatwo coś tak spartaczyć, że działa dla 0:0,
a dla innych użytkowników niebardzo. Działanie z uprawnieniami 0:0 jest
po prostu niepraktyczne.

-- 
Jarek

W dniu 30.11.2024 o 13:20, Jarosław Sokołowski pisze:

> Nic z tych rzeczy. Jak to ma być poważny serwer, to i tak ma wszystkie
> hasła zablokowane. 

No ale to taki user nie zrobi wtedy sudo. Chyba, że w suduers ma 
ustawione NOPASSWD, co nie ma wtedy większego sensu.
Albo pozostaje wtedy logować się bezpośrednio na root-a.

Zauważ, że wtedy w tym poważnym serwerze brak hasła root-a lub brak 
hasła uprawnionego użytkownika wyklucza dostęp bezpośrednio z konsoli 
(tej fizycznej, albo wirtualnej).  Trzeba by się wtedy włamywać np. 
przez grub-a :(

Najlepszego,
Kazik

Kazik Kaz <kazik.kaz@no.email> writes:

> W dniu 30.11.2024 o 13:20, Jarosław Sokołowski pisze:
>
>> Nic z tych rzeczy. Jak to ma być poważny serwer, to i tak ma wszystkie
>> hasła zablokowane. 
>
> No ale to taki user nie zrobi wtedy sudo. Chyba, że w suduers ma
> ustawione NOPASSWD, co nie ma wtedy większego sensu.
Mam wrażenie, że chodziło o logowanie (po kluczach) a nie o to co po
zalogowaniu. Poza tym sudo można ustawić tak, żeby prosiło o hasło
docelowego użytkownika. Poza tym wreszcie są inne moduły (na przykład
do) pam nie tylko te do hasła.

> Albo pozostaje wtedy logować się bezpośrednio na root-a.
Nie.

>
> Zauważ, że wtedy w tym poważnym serwerze brak hasła root-a lub brak
> hasła uprawnionego użytkownika wyklucza dostęp bezpośrednio z konsoli
> (tej fizycznej, albo wirtualnej).  Trzeba by się wtedy włamywać
> np. przez grub-a :(
.
Nie.


-- 
http://wolnelektury.pl/wesprzyj/teraz/
My philosophy is: Don't think.
		-- Charles Manson

W dniu 30.11.2024 o 15:40, Kamil Jońca pisze:
> Kazik Kaz <kazik.kaz@no.email> writes:
> Poza tym wreszcie są inne moduły (na przykład
> do) pam nie tylko te do hasła.

... i są marsjanie i inni kosmici i wiele innych modułów PAM. Są też 
takie pam-y na odcisk palca lub wzór siatkówki oka. I co z tego? Też nie 
podajemy hasła.

Ale w efekcie i tak user musi się "zautoryzować" bo np. taki wpis tego 
wymaga:
auth required pam_do.so

Najlepszego,
Kazek

On 2024-11-30, Jarosław Sokołowski <jaros@lasek.waw.pl> wrote:
> Pan Marcin Debowski napisał:
>
>>> Zatem, jeśli w systemie jest dwóch albo i więcej uprawnionych do sudo 
>>> użytkowników (np. w firmie 24h na 3 zmiany) to prawdopodobieństwo 
>>> atakującego wzrasta proporcjonalnie do liczby uprawnionych, dając mu 
>>> tyle razy większe szanse przechwycenia hasła uprawnionego administratora 
>>> ilu uprawnionych np. poprzez jakąkolwiek inwigilację któregokolwiek z nich.
>
> Nic z tych rzeczy. Jak to ma być poważny serwer, to i tak ma wszystkie
> hasła zablokowane. Logowanie kluczem z innego komputera (który jeśli
> nawet jest wystawiony w Internecie, to w sposób ograniczony, a do tego
> bad guyowi trudno odgadnąć, który to).

To nie musi być poważny serwer. Moje wszystkie śmieszne serwery tak 
właśnie mają. To jest raczej standardowa praktyka. Ale przy 
n-uzytkownikach zdecydowanie wzrasta szansa uzyskania dostępu, bo na 
konsoli czy wewnątrz firmy to nadal może być hasło. Gdzieś, na jakimś 
poziomie nie jest to interakcja wyłącznie maszyna-maszyna. 

>> Nie widzę większego sensu w używaniu sudo jeśli jest 2ch lub więcej 
>> administratorów (doświadczonych) z pełnym prawem dostępu. Sens może
>> być, jeśli mamy konieczność wykonywania tylko wybranych poleceń, przez 
>> wybranych użytkowników, na prawach roota.
>
> Jest dokładnie odwrotnie. Gdy administrator jest jeden, to do nikogo
> o nic nie może mieć pretensji i robi jak uważa. Gdy jest ich więcej,
> to warto znać historię logowań każdego z nich.

Bez bicia informuję, że nie pracowałem nigdy na nieco bardziej ludnym 
serwerze z kilkoma adminami, ale co to miałoby dać? Jak ktoś robi coś 
złego to na prawach roota ma zwykle wystarczające środki aby zatrzeć za 
sobą ślady lub uniemożliwić własną identyfikacje. A jeśli tym innym 
osobom ufamy, i są one profesjonalne, to poinformują nas co robiły, mogą 
być jakieś dzienniki, etc. A jak to jest jakaś infrastruktura krytyczna, 
np. dla firmy, to z lekka dziwne byłoby opierać bezpieczeństwo na 
znajomości historii logowań i sudo. Zresztą w kwestii samej 
identyfikacji, dostęp nie musi być przecież po jednym kluczu, więc i 
identyfikacja może być na poziomie klucza, a nie użytkownia, który 
zrobił sudo.

Nb. chyba w tym watku nie wspomniano, z pradawnych czasów pamiętam też 
pomysły tworzenia dodatkowych użytkowników z uid 0.

>> taki użytkownik działając na powłoce z pełnym dostępem, w którymś
>> momencie się zapomni i narobi szkód.
>
> Określenie SOA#1 (standardowa odpowiedź administratora numer 1: u mnie
> działa) skądś się wzięło. Łatwo coś tak spartaczyć, że działa dla 0:0,
> a dla innych użytkowników niebardzo. Działanie z uprawnieniami 0:0 jest
> po prostu niepraktyczne.

Czym się ta niepraktyczność manifestuje? 

-- 
Marcin

Dnia 01.12.2024 Marcin Debowski <agatek@INVALID.zoho.com> napisał/a:

> Bez bicia informuję, że nie pracowałem nigdy na nieco bardziej ludnym 
> serwerze z kilkoma adminami, ale co to miałoby dać? Jak ktoś robi coś 
> złego to na prawach roota ma zwykle wystarczające środki aby zatrzeć za 
> sobą ślady lub uniemożliwić własną identyfikacje. A jeśli tym innym 
> osobom ufamy, i są one profesjonalne, to poinformują nas co robiły, mogą 
> być jakieś dzienniki, etc. A jak to jest jakaś infrastruktura krytyczna, 

Dlatego w poważniejszej firmie pewnie będzie jakieś rozwiązanie typu
PAM (privileged access management), gdzie hasło hasło/klucz root jest 
przechowywane w zewnętrznym systemie poza dostępem admina, a ten uwierzytelnia
się do tegoż systemu swoimi kredkami np. przez LDAP/AD. "Po użyciu" hasło roota 
może być też od razu zmieniane. Ponieważ historia jest wyniesiona poza serwer,
zacieranie śladów na serwerze nic nie da, wiadomo kto kiedy się na roota
logował.

-- 
Dominik Ałaszewski (via raspbianowy slrn)
"W życiu piękne są tylko chwile…" (Ryszard Riedel)
Wyrażam wyłącznie prywatne poglądy zgodnie z Art. 54 Konstytucji RP 
Pisząc na priv zmień domenę na gmail.

Dnia 29.11.2024 Kazik Kaz <kazik.kaz@no.email> napisał/a:

> W każdym podręczniku czy też zaleceniach napisanych przez 
> "bezpieczniaka" - jak się wydaje nie będącego nigdy administratorem 
> systemu jest wymaganie, aby nie można było się logować na konto root 
> bezpośrednio. Oczywiście magia działa i pozostaje wtedy czarodziejskie 

Jedyny plus jaki widzę, to potencjalny włamywacz nie musi zgadywać
nazwy konta (konto root będzie zawsze) i "wystarczy" rozgryźć hasło. 
Oczywiście np. przy logowaniu wyłącznie kluczem (porządnym) rzeczony
włamywacz może sobie je zgadywać ad mortem defecatem, więc tu
samo umożliwienie logowania się na root wiele nie zmienia,
ale jak ktoś w defaultowym konfigu ustawi trywialne hasło na root,
to może mu to tyłek uratować.

Faktem jest, że ważniejsze serwery zwykle i tak nie mają ssh wprost
wystawionego do internetu, można stosować jeszcze np. port knocking,
wynieść ssh na wyższy port a na standardowym wsadzić ssh tarpit,
żeby boty miały zajęcie itd itp. Wyłączenie logowania na roota
jest zalecane, bo ludzie używają haseł typu 123456, taka jest
smutna prawda.

-- 
Dominik Ałaszewski (via raspbianowy slrn)
"W życiu piękne są tylko chwile…" (Ryszard Riedel)
Wyrażam wyłącznie prywatne poglądy zgodnie z Art. 54 Konstytucji RP 
Pisząc na priv zmień domenę na gmail.

Pan Marcin Debowski napisał:

>> Gdy administrator jest jeden, to do nikogo o nic nie może mieć
>> pretensji i robi jak uważa. Gdy jest ich więcej, to warto znać
>> historię logowań każdego z nich.
>
> Bez bicia informuję, że nie pracowałem nigdy na nieco bardziej
> ludnym  serwerze z kilkoma adminami, ale co to miałoby dać?
> Jak ktoś robi coś złego to na prawach roota ma zwykle wystarczające
> środki aby zatrzeć za sobą ślady lub uniemożliwić własną identyfikacje.
> A jeśli tym innym osobom ufamy, i są one profesjonalne, to poinformują
> nas co robiły, mogą być jakieś dzienniki, etc. A jak to jest jakaś
> infrastruktura krytyczna, np. dla firmy, to z lekka dziwne byłoby
> opierać bezpieczeństwo na znajomości historii logowań i sudo.

Nie chodzi o świadome czynienie zła i o zacieranie śladów po tym.
Elementem profesjonalnego podejścia jest założenie, że profesjonalnym
osobom zdarzają się błędy. Z kolei istotą błędów jest to, że nie były
planowane. Więc jak się już pojawiły, to niekoniecznie wszystko widać
w logach. Zatem dobrze jest mieć możliwość jak najszybszego dotarcia
do "naocznego świadka", który sam jeden wie, co robił, choć nie wie
jeszcze, że zepsuł.

>> Określenie SOA#1 (standardowa odpowiedź administratora numer 1: u mnie
>> działa) skądś się wzięło. Łatwo coś tak spartaczyć, że działa dla 0:0,
>> a dla innych użytkowników niebardzo. Działanie z uprawnieniami 0:0 jest
>> po prostu niepraktyczne.
>
> Czym się ta niepraktyczność manifestuje? 

Między innymi tym, co wyżej opisane. Trudniej jest szybko przetestować,
jak wszystko wygląda z punktu widzenia nieuprzywilejowanego użytkownika.

-- 
Jarek

Pan Dominik Ałaszewski napisał:

> Jedyny plus jaki widzę, to potencjalny włamywacz nie musi zgadywać
> nazwy konta (konto root będzie zawsze)

Linux jest w zasadzie wszędzie, więc to prawda. Ale za czasów uniksów
komercyjnych w systemach sprzedawanych w Australii nie było konta
o nazwie "root". Słowo to w ichnim języku uznawane jest za brzydkie,
nie wypada tak nazywać Pana Administratora kochanego. Zamiast tego
był przeważnie "avatar". W zasadzie w Linuksie też nie ma przeszkód,
by zmienić.

> Wyłączenie logowania na roota jest zalecane, bo ludzie używają haseł
> typu 123456, taka jest smutna prawda.

Taka ciekawostka: sshd ma opcję wyłączającą możliwość zalogowania się,
gdy hasło jest puste (dwa dwukropki obok siebie w /etc/shadow). Wtedy
każdy bez problemu może się zalogować lokalnie, ale zdalnie po ssh
już nie.

-- 
Jarek

Dnia Sun, 1 Dec 2024 11:55:09 -0000 (UTC), Dominik Ałaszewski napisał(a):

> (...) Wyłączenie logowania na roota
> jest zalecane, bo ludzie używają haseł typu 123456, taka jest
> smutna prawda.

Jak można wymusić w linuksach stosowanie mocnych haseł?
Mam na myśli najczęściej stosowane dystrybucje typu debian/ubuntu, i
redhat/fedora, suse itp.


-- 
Pozdrawiam.

Adam

On 2024-12-01, Jarosław Sokołowski <jaros@lasek.waw.pl> wrote:
> Pan Marcin Debowski napisał:
>
>>> Gdy administrator jest jeden, to do nikogo o nic nie może mieć
>>> pretensji i robi jak uważa. Gdy jest ich więcej, to warto znać
>>> historię logowań każdego z nich.
>>
>> Bez bicia informuję, że nie pracowałem nigdy na nieco bardziej
>> ludnym  serwerze z kilkoma adminami, ale co to miałoby dać?
>> Jak ktoś robi coś złego to na prawach roota ma zwykle wystarczające
>> środki aby zatrzeć za sobą ślady lub uniemożliwić własną identyfikacje.
>> A jeśli tym innym osobom ufamy, i są one profesjonalne, to poinformują
>> nas co robiły, mogą być jakieś dzienniki, etc. A jak to jest jakaś
>> infrastruktura krytyczna, np. dla firmy, to z lekka dziwne byłoby
>> opierać bezpieczeństwo na znajomości historii logowań i sudo.
>
> Nie chodzi o świadome czynienie zła i o zacieranie śladów po tym.
> Elementem profesjonalnego podejścia jest założenie, że profesjonalnym
> osobom zdarzają się błędy. Z kolei istotą błędów jest to, że nie były
> planowane. Więc jak się już pojawiły, to niekoniecznie wszystko widać
> w logach. Zatem dobrze jest mieć możliwość jak najszybszego dotarcia
> do "naocznego świadka", który sam jeden wie, co robił, choć nie wie
> jeszcze, że zepsuł.

A to nie lepiej zapytać? Wystąpił taki problem, robiliście coś ostatnio 
na bleble.com.ble? Przeciez kolegów będą ze 2-4 sztuki, nie jakaś 
choragiew.

>>> Określenie SOA#1 (standardowa odpowiedź administratora numer 1: u mnie
>>> działa) skądś się wzięło. Łatwo coś tak spartaczyć, że działa dla 0:0,
>>> a dla innych użytkowników niebardzo. Działanie z uprawnieniami 0:0 jest
>>> po prostu niepraktyczne.
>>
>> Czym się ta niepraktyczność manifestuje? 
>
> Między innymi tym, co wyżej opisane. Trudniej jest szybko przetestować,
> jak wszystko wygląda z punktu widzenia nieuprzywilejowanego użytkownika.

Sorry, ale chyba nie rozumiem. Poprzedzanie kazdego polecenia sudo 
wydaje mi się skrajnie niepraktyczne przy jakiejkowlwiek nieco wiekszej 
pracy (medal za cierpliwość tym co w pierwszym poleceniu nie zrobią sudo 
-i), "su - użytkownik" nie potrzebuje sudo. A też mam watpliwości, czy 
praktyka sudo dla bardziej zaawansowanego admina nie jest wręcz 
szkodliwa.

-- 
Marcin

Marcin Debowski <agatek@INVALID.zoho.com> writes:

[...]
>>
>> Nie chodzi o świadome czynienie zła i o zacieranie śladów po tym.
>> Elementem profesjonalnego podejścia jest założenie, że profesjonalnym
>> osobom zdarzają się błędy. Z kolei istotą błędów jest to, że nie były
>> planowane. Więc jak się już pojawiły, to niekoniecznie wszystko widać
>> w logach. Zatem dobrze jest mieć możliwość jak najszybszego dotarcia
>> do "naocznego świadka", który sam jeden wie, co robił, choć nie wie
>> jeszcze, że zepsuł.
>
> A to nie lepiej zapytać? Wystąpił taki problem, robiliście coś ostatnio 
> na bleble.com.ble? Przeciez kolegów będą ze 2-4 sztuki, nie jakaś 
> choragiew.

Czasmi problem zostanie zauważony po jakimś czasie. A po (np) 2
tygodniach można nie pamiętać zbyt dokładnie.


>> Między innymi tym, co wyżej opisane. Trudniej jest szybko przetestować,
>> jak wszystko wygląda z punktu widzenia nieuprzywilejowanego użytkownika.
>
> Sorry, ale chyba nie rozumiem. Poprzedzanie kazdego polecenia sudo 
> wydaje mi się skrajnie niepraktyczne przy jakiejkowlwiek nieco wiekszej 

No nie wiem. Ja jakoś nie mam z tym problemu.

KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/
!07/11 PDP a ni deppart m'I  !pleH

Dnia 01.12.2024 Adam <a.g@poczta.onet.pl> napisał/a:

> Jak można wymusić w linuksach stosowanie mocnych haseł?

Słowa klucze dla wujka G: password policy linux.

-- 
Dominik Ałaszewski (via raspbianowy slrn)
"W życiu piękne są tylko chwile…" (Ryszard Riedel)
Wyrażam wyłącznie prywatne poglądy zgodnie z Art. 54 Konstytucji RP 
Pisząc na priv zmień domenę na gmail.

Dnia Tue, 3 Dec 2024 10:05:12 -0000 (UTC), Dominik Ałaszewski napisał(a):

> Dnia 01.12.2024 Adam <a.g@poczta.onet.pl> napisał/a:
> 
>> Jak można wymusić w linuksach stosowanie mocnych haseł?
> 
> Słowa klucze dla wujka G: password policy linux.

Qrde, dupa jestem :(

Dzięki :)


-- 
Pozdrawiam.

Adam