it-swarm-ko.tech

루트 사용자를 비활성화해야합니까?

루트 암호를 제거하고 원격 로그인을 비활성화하고 기본적으로 관리자가 Sudo를 사용하여 관리 작업을 수행해야합니까?

alt text

21
jldugger

내 모든 서버에 루트 계정이 비활성화되어 있습니다 (sp_pwdp 로 설정 *). 모든 루트 액세스에 Sudo이 필요합니다. [1] 이것의 목적은 모든 수퍼 유저 활동을 감사하여 사람들이 시스템에 수행 된 작업을 볼 수 있도록하는 것입니다.

좀 더 하드 코어 한 옵션을 사용하려면 Sudo 로그 파일에 기록하고 (syslog와는 반대로) 파일을 추가 전용으로 만들 수 있습니다 (Linux에서는 chattr 사용, 또는 BSD에서 chflags). 이렇게하면 나중에 아무도 감사를 편집 할 수 없습니다.

[1] 또한 루트 쉘을 실행하지 않거나 루트 프로세스에서 쉘 이스케이프를 수행하는 정책이 있습니다. (Sudo sh -c '...'하지만 파이프 라인이나 리디렉션을 수행합니다.)

16

나는 강조 루트 사용자를 비활성화하지 않는 것이 좋습니다. 루트 로그인 비활성화 또는 제한 (securetty and via sshd_config and via PAM and via what have you) 허용하거나, 루트의 권한을 제한하거나, 루트 역할을 분할합니다 ( RSBAC 방법과 유사합니다.)하지만 제발, Please , 암호를 제거하여 루트 계정을 비활성화하지 마십시오. 그렇지 않으면 sulogin을 (를) 통해 시스템에 로그인 할 수 없게됩니다. sulogin는 fsck에 의해보고 된 심각한 오류의 경우 내가 아는 모든 initscript에서 사용됩니다. 즉, 루트 파일 시스템이 손상되면 시스템에서 잠 깁니다.

명확히하기 위해 : "비밀번호를 제거하여 루트 계정을 비활성화"한다는 것은!로 끝나는 다양한 메커니즘을 의미합니다. 또는/etc/shadow의 비밀번호 필드에 * 또는 유사합니다. "암호를 입력하라는 메시지가 표시되지 않도록 루트 로그인 메커니즘을 변경하십시오"라는 의미가 아닙니다.

15
Mihai Limbăşan

모든 서버에서 루트 계정을 활성화했습니다. 모든 관리자는 자신의 사용자가 있으며이를 통해 로그인해야합니다. 거기에서 그들은 루트로 전환합니다. (루트 ssh가 비활성화 됨)

관리자 수를 낮게 유지하십시오. 해당 서버에서 실제로 루트 액세스가 필요한 사람 만 암호를 가지고 있습니다.

나는 Sudo의 팬이 아닙니다. 루트 셸에 대해 'Sudo bash'를 수행하는 것은 너무 쉽습니다. 나는 이것이 비활성화 될 수 있다는 것을 알고 있지만 왜 귀찮게합니까? 관리자 작업을 수행하고 서로 대화 할 수있는 사용자를 제한하십시오. 루트 터미널이 무인으로 열리지 않도록하는 정책이 있습니다. 그래서 그것은 로그인, su, 일을하고, 로그 아웃합니다.

참고 : 저는 상당히 작은 회사 (직원 50 명)에서 일하며 파트 타임 관리자 2 명 (윈도우 1 개/1 리눅스) 만 있습니다. 이 방법은 사용자가 훨씬 더 많을 때 최선이 아닐 수 있습니다. 나는 개인적으로 여전히 Sudo를 사용하지 않을 것입니다. 루트 활동을 기록하는 다른 방법이 있습니다.

3
Gert M

루트 암호를 비활성화하는 것은 잘못된 "좋은 생각"입니다. 당신이 그것을 필요로 할 날, 당신은 정말 그것을 필요로 할 것입니다. (구성에 따라 단일 사용자 모드로 로그인해야 할 수 있습니다.)

루트 원격 로그인 비활성화는 관련이있을 수 있지만 로컬로 로그온 할 수있는 경우에만 가능합니다.

그리고 예, Sudo는 모든 서버에 설치되어야합니다. 유용하고 구성하기 쉽습니다. 왜 사용하지 않습니까?

2
Benoit

루트에 대한 SSH 액세스를 비활성화하고 사용자 (종종 개발자)가 ssh 키를 사용하도록 요구합니다. 너무 많은 사전 공격이 있고 SSH 포트를 변경하는 것은 우리에게 선택 사항이 아닙니다.

이렇게하면 좋은 암호를 작성하는 다른 사람의 능력을 신뢰할 필요가 없습니다. 내부에 있으면 관리자 만 Sudo에 대한 권한을 갖습니다.

2
pablasso

이 스레드가 정말 오래되었다는 것을 알고 있지만 링크 된 기사 논리에 몇 가지 주요 결함이 있으며 "rant'ie"느낌이 듭니다. Sudo는 화이트리스트와 블랙리스트를 모두 허용합니다. 링크 된 기사에 지정된대로 검은 색뿐만 아니라 AAA (인증, 승인 및 감사) 개념을 건너 뜁니다. su & Sudo는 등급별 인증과 책임을 모두 허용합니다.

시나리오 1 관리자가 실수로 일부 불량 코드를 시스템에 도입하고 루트로 로그인하여 코드에 완전한 액세스 권한이 있으며 관리자는 무슨 일이 일어 났는지 알 수 없습니다. 최소한 등급별 로그인 (예 : su/Sudo)을 사용하는 경우 불량 코드가 상승 된 권한을 사용하려고하면 인증하라는 메시지가 관리자에게 표시됩니다. 권한이 상승하지 않으면 최소한의 손상을 초래하는 사용자 권한에 국한됩니다.

시나리오 2 불량 관리자가 정보를 얻고 변경하려고합니다. 그들은 콘솔 (물리적 콘솔 액세스, HP iLo/유사 또는 vGuest 콘솔 액세스)에 연결하고 루트로 로그인하여 원하는대로 수행합니다. 콘솔 액세스 권한을 얻는 데 사용되는 명명 된 계정/액세스 카드가 없으면 감사 추적이 많지 않을 것입니다.

  1. 그들이 정말로 그들이 말하는 사람인지 확인하십시오. 신원 도용은 문제가 아니라 신원 확인입니다.
  2. 승인을 확인하고 그때 필요한 것만 제공하십시오. 등급별 승인을 통해 필요할 때 승격 할 수 있습니다.
  3. 모든 것을 감사하고 기록을 보유하여 누가, 무엇을 언제 어디서했는지 알 수 있습니다. 가급적 이유도
2
Mike

Owl 보안 배포 (및 Solar 디자이너)의 저자는 신중하게 정당화 된 관점을 가지고 있습니다. 예를 들어, 답변 https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-Sudo-su-or-login/ 참조 8660 # 866 그들의 주장을 발표하기 위해. 수퍼 유저 작업을 감사하는 문제 (어떤 사람이 무엇을했는지)도 그들의 관점에서 해결됩니다 (기본적으로 해결책은 여러 이름을 가진 여러 루트 사용자를 갖는 것입니다).

모든 사람이 모든 루트 명령에 대해 Sudo를 정책으로 사용해야합니다. "Sudo bash"등을 실행할 이유는 없으며, 무지로 인한 편의 또는 자신의 흔적을 가리기위한 것입니다.

루트 계정에 대한 로그인을 직접 비활성화하면 심각한 문제가있을 때 시스템을 고칠 수있는 능력이 손상됩니다.

관리자가 자신으로 로그인하고 루트로 실행되는 모든 명령에 대해 Sudo를 실행하도록 설득 할 수없고 셸에서 벗어나지 않도록하려면 기술적 인 해결책이없는 심각한 문제가있는 것입니다.

1
carlito