- Sprawdziłem sobie z jakich terminali można się logować na konto roota i jest tego co najmniej z setka
Teraz zastanawiam się co zostawić, może dla bezpieczeństwa tylko: console i tty1.
Kod: Zaznacz cały
# /etc/securetty: list of terminals on which root is allowed to login. # See securetty(5) and login(1). console # Local X displays (allows empty passwords with pam_unix's nullok_secure) :0 :0.0 :0.1 :1 :1.0 :1.1 :2 :2.0 :2.1 :3 :3.0 :3.1 #... # ========================================================== # # TTYs sorted by major number according to Documentation/devices.txt # # ========================================================== # Virtual consoles tty1 tty2 tty3 tty4 tty5 tty6 tty7 tty8 tty9 tty10 tty11 tty12 tty13 tty14 tty15 tty16 tty17 tty18 tty19 tty20 #i dużo dużo więcej
Czy to wystarczy, czy zostawić coś jeszcze? - Jak sprawdzić czy możliwe jest zdalne logowanie na roota?
securetty a logowanie na roota
securetty a logowanie na roota
Witam.
1. Ja wogule nie zezwalał na logowanie sie jako root
2.
Odkemtuj i ustaw na no
2.
Kod: Zaznacz cały
[root@root ~]# vi /etc/ssh/sshd_config
Odkemtuj i ustaw na no
Kod: Zaznacz cały
#PermitRootLogin yes
1. Nie korzystam z sudo. W systemie jest tylko jeden użytkownik (czyli ja) i nie jest dopisany do sudoers. Konto roota ma wiele "mocniejsze" hasło niż użytkownika, więc korzystanie z sudo mija się na mojej maszynie z celem. Zatem muszę mieć możliwość logowania na roota. Jeżeli zostawię w takim układzie plik securetty pusty, to rozumiem, że w razie problemów ze startem systemu (np. padaka Xów), nie będę mógł się zalogować na roota? Dobrze myślę? Chodzi mi tylko o możliwość lokalnego logowania. Czytałem że można też ograniczyć logowanie do jednej wybranej losowej konsoli np (strzelam) wybrać tty63 i ograniczyć możliwość odczytu securetty przez zwykłe konta.
2. Zrobione.
2. Zrobione.
OK. dzięki Znalazłem jeszcze taki opis w sieci. Zdecydowałem, że zostawiam securetty pusty
W pliku /etc/securetty można skonfigurować te urządzenia tty (terminale), na których będzie mógł się logować root.
Zalecamy zakomentowanie wszystkich linii poza vc/1 jeśli używa się devfs i wszystkich linii poza tty1 jeśli korzysta się z udev. Spowoduje to, że root będzie mógł być zalogowany tylko raz i tylko na jednym terminalu.
[TABLE="class: ncontent, width: 100%"]
[TR]
[TD="bgcolor: #bbffbb"]Uwaga: Użytkownicy z grupy 'wheel' wciąż będą mogli stawać się rootem przy pomocy polecenia su - na innych terminalach.
[/TD]
[/TR]
[/TABLE]
[TABLE="class: ntable, width: 100%"]
[TR]
[TD="bgcolor: #7a5ada"]Listing 4.1: /etc/securetty
[/TD]
[/TR]
[TR]
[TD="bgcolor: #eeeeff, align: left"]
(Dla devfs) vc/1 (Dla udev) tty1 [/TD]
[/TR]
[/TABLE]
Tutaj https://www.gentoo.org/doc/en/security/ ... ble&full=1 Zauważyłem właśnie, że w Debianie nie ma grupy wheel.
„Dlaczego GNU su nie obsługuje grupy wheel”
Jest to słynne zdanie w dokumentacji info su , napisane przez Richarda M. Stallmana. Ale nie obawiaj się, obecne su w Debianie używa PAM, więc można ograniczyć możliwość używania su do dowolnej grupy używając pam_wheel.so w pliku /etc/pam.d/su. Poniższy przykład ilustruje ustawienie grupy adm analogicznie do wheel z systemów BSD oraz umożliwia używanie su bez podawania hasła dla członków tej grupy.
Jest to słynne zdanie w dokumentacji info su , napisane przez Richarda M. Stallmana. Ale nie obawiaj się, obecne su w Debianie używa PAM, więc można ograniczyć możliwość używania su do dowolnej grupy używając pam_wheel.so w pliku /etc/pam.d/su. Poniższy przykład ilustruje ustawienie grupy adm analogicznie do wheel z systemów BSD oraz umożliwia używanie su bez podawania hasła dla członków tej grupy.
# konfiguracja anty-RMS w /etc/pam.d/su
auth required pam_wheel.so group=adm
# Członkowie grupy wheel mogą wywoływać su bez podawania hasła
auth sufficient pam_wheel.so trust group=adm
A tak w ogóle to zabezpieczasz system lokalnie czy zdalnie?
https://www.debian.org/doc/user-manuals#securing
https://www.debian.org/doc/user-manuals#securing