루트 권한을 얻는 가장 안전한 방법은 sudo, su 또는 login입니까?


120

권한이없는 사용자가 손상된 경우에도 루트 계정을 안전하게 유지하고 싶습니다.

우분투에서는 기본적으로 "보안상의 이유로"sudo 만 사용할 수 있습니다. 그러나 텍스트 모드 콘솔에서 로그인을 사용하는 것보다 안전한지 확실하지 않습니다. 침입자가 일반 사용자로 코드를 실행할 수 있으면 잘못 될 수있는 일이 너무 많습니다. 예를 들어 별칭을 추가하고 PATH에 항목을 추가하고 LD_PRELOAD 및 X11 키로거를 설정하여 몇 가지만 언급하면됩니다. 내가 볼 수있는 유일한 장점은 시간 초과이므로 로그 아웃하는 것을 잊지 않습니다.

su에 대해 똑같은 의심이 있지만 시간 제한조차 없습니다. 일부 작업 (특히 IO 리디렉션)은 su에 더 익숙하지만 보안 측면에서는 더 나쁩니다.

텍스트 모드 콘솔에서 로그인하는 것이 가장 안전한 것 같습니다. 공격자가 PATH 또는 LD_PRELOAD를 제어 할 수있는 경우 init에 의해 시작되므로 이미 루트입니다. X에서 실행되는 프로그램은 키 누르기 이벤트를 가로 챌 수 없습니다. X에서 실행되는 프로그램이 [ctrl] + [alt] + [f1]을 가로 챌 수 있는지 (콘솔처럼 보이는 전체 화면 창을 열 수 있는지) 또는 Windows에서는 [ctrl] + [alt] + [del]과 같이 안전합니다. 그 외에도 내가 보는 유일한 문제는 시간 초과가 없다는 것입니다.

그래서 뭔가 빠졌습니까? 우분투 사람들은 왜 sudo 만 허용하기로 결정 했습니까? 방법의 보안을 향상시키기 위해 어떻게해야합니까?

SSH는 어떻습니까? 일반적으로 root는 SSH를 통해 로그인 할 수 없습니다. 그러나 위의 논리를 사용하는 것이 가장 안전한 방법은 아닙니다.

  • SSH를 통한 루트 허용
  • 텍스트 모드로 전환
  • 루트로 로그인
  • 다른 기계에 ssh
  • 루트로 로그인 하시겠습니까?

ssh 솔루션에서 다른 상자에서 잠재적으로 압축 된 상자에 ssh하고 싶습니까? 1 / 그렇다면, 당신의 생각의 기차를 따라 가기 위해서는 다른 상자가 타협되지 않도록해야합니다. 2 / 아니라면 같은 문제가있는 것입니다.
asoundmove

@asoundmove : 내 ssh 상황에는 root @ hosta, root @ hostb, stribika @ hosta, stribika @ hostb의 4 명의 사용자가 있습니다. 공격자가 임의의 코드를 두 stribika로 실행할 수 있다고 가정하면 (모든 플러그인과 플래시 플러그인을 실행 한 후) 여전히 안전한 루트 액세스를 원합니다. 따라서 두 상자 모두 부분적으로 손상 될 수 있습니다.
stribika

답변:


105

보안은 항상 절충에 관한 것입니다. 그냥 금고에있는 유명한 서버처럼, 분리, 바다의 하단에있는 root대부분의 모든 액세스 할 수있는 방법이 없다면 보안.

귀하가 설명하는 것과 같은 LD_PRELOAD 및 PATH 공격은 이미 귀하의 계정이나 최소한 닷 파일에 액세스 할 수있는 공격자가 있다고 가정합니다. 도우는 전혀 잘 것을 방지하지 않습니다 - 그들이 당신의 비밀번호가있는 경우, 결국, 필요 나중에 당신을 속여 시도하지하는 ... 그들은 단지 사용할 수 있습니다 sudo 지금 .

Sudo가 원래 의도 한 것, 프린터를 관리하는 것과 같은 특정 명령을 "하위 관리자"(아마도 실험실의 대학원생)에게 위임하는 것이 중요합니다 . sudo를 사용하여 모든 것을 수행하는 것이 지금 가장 일반적으로 사용되는 것은 아니지만 프로그램이 해결해야 할 문제 일 필요는 없습니다 (따라서 엄청나게 복잡한 구성 파일 구문).

그러나 sudo-for-unrestricted-root 또 다른 보안 문제인 루트 암호 관리 효율성을 해결합니다. 많은 조직에서 이들은 사탕처럼 지나가고 화이트 보드에 쓰여져 영원히 같은 경향이 있습니다. 액세스 취소 또는 변경이 큰 생산 번호가되므로 큰 취약점이 남아 있습니다. 혼자 추적 할 수 - 심지어 도전이 무엇 비밀번호 무슨 기계의 트랙을 유지 알고 있는 하나.

대부분의 "사이버 범죄"는 내부에서 온다는 것을 기억하십시오. 루트 암호 상황을 설명하면 누가 원격 로깅을 사용하여 무엇을했는지 추적하기가 어렵습니다.

귀하의 홈 시스템에서는 두 개의 암호를 기억하지 않아도되는 것이 더 편리하다고 생각합니다. 많은 사람들이 단순히 동일하게 설정했거나 더 나쁜 것은 초기에 동일하게 설정 한 다음 동기화하지 못하게하여 루트 암호를 썩게했을 가능성이 있습니다.

비밀번호 감지 트로이 목마 ssh 데몬은 내가 본 실제 시스템 손상의 90 %와 같은 위치에 배치되므로 SSH에 비밀번호 를 전혀 사용하지 않는 것이 위험합니다. SSH 키를 사용하는 것이 훨씬 낫습니다. 이것은 원격 루트 액세스를위한 실행 가능한 시스템 일 수도 있습니다.

그러나 문제는 이제 암호 관리에서 키 관리로 옮겨졌으며 ssh 키는 실제로 관리하기가 쉽지 않다는 것입니다. 사본을 제한 할 수있는 방법이 없으며 누군가가 사본을 만들면 암호를 무차별로 강제하려는 모든 시도가 있습니다. 키를 이동식 장치에 저장해야하고 필요할 때만 마운트해야한다는 정책을 만들 수 있지만이를 적용 할 방법이 없습니다. 이제 이동식 장치를 분실하거나 도난 당할 가능성이 있습니다.

최고의 보안은 일회성 키 또는 시간 / 카운터 기반 암호화 토큰을 통해 제공됩니다. 이러한 작업은 소프트웨어에서 수행 할 수 있지만 변조 방지 하드웨어가 훨씬 좋습니다. 오픈 소스 세계에는 WiKiD , YubiKey 또는 LinOTP 가 있으며, 독점 헤비급 RSA SecurID도 있습니다. 중대형 조직이나 보안에 민감한 소규모 조직의 경우 관리 액세스를위한 이러한 접근 방법 중 하나를 살펴 보는 것이 좋습니다.

그러나 현명한 보안 관행을 따르는 한 실제로 관리 번거 로움이없는 가정에서는 과잉 일 것입니다.


sudo를 기본 방법으로 만들 때 우분투 개발자가 생각한 것에 대해 많은 것을 밝히기 때문에 이것을 대답으로 받아 들일 것입니다. 원격 로깅도 좋은 생각처럼 보이고 syslog-ng를 사용하고 있다고 가정하면 모든 컴퓨터가 다른 컴퓨터에 모두 기록되도록 설정하기가 너무 어렵지 않아야합니다. 텍스트 모드로 전환하고 전체 루트 액세스를 위해 거기에서 로그인하는 현재 관행을 고수하겠습니다. 권리의 하위 집합을 위임하는 것은 확실히 sudo를 사용하는 좋은 방법이며 내가 고려하지 않은 방법입니다.
stribika

7
sudoWindows Vista의 사용자 계정 컨트롤과 매우 유사합니다. 둘 다 실제로 보안 을 강화 하지 않고 통제 된 방식으로 보안을보다 쉽게 줄일 수 있도록 설계되었습니다 . 그러나 때문에 그들은 쉽게 일시적으로 저 마찰 방식으로 권한을 상승 할 수 있도록, 당신은 따라서 보안을 강화, 장시간 동안 높은 권한으로 실행할 필요가 없습니다. (이것은 유닉스에서 큰 문제가 아니었지만 Windows에서는 전환이 너무
힘들

비밀번호 스니핑 트로이 목마 SSH 데몬? ssh 데몬을 교체 할 수 있으면 이미 루트가있는 것입니다.
psusi

@psusi : 예, 시스템에서; 여러 시스템간에 디렉토리 서비스가 비밀번호를 공유하는 환경에서는 이러한 방식으로 타협이 확산되기 쉽습니다. 단일 시스템 인 경우에도 손상이 감지 된 후 다시 설치 한 후 모든 사람의 비밀번호를 다시 프로비저닝해야하는 번거 로움이 있습니다.
mattdm

1
회사의 모든 root비밀번호 를 변경하는 데 따른 잠재적 인 어려움은 Ops Report Card 의 최종 항목으로 언급되어 있습니다.
와일드 카드

30

이것은 매우 복잡한 질문입니다. mattdm 은 이미 많은 요점을 다루었습니다 .

su와 sudo 사이에서 단일 사용자를 고려할 때 su는 암호를 찾은 공격자가 즉시 루트 권한을 얻을 수 없다는 점에서 조금 더 안전합니다. 그러나 공격자가 로컬 루트 홀 (상대적으로 드문 경우)을 찾거나 트로이 목마를 설치하고 su를 실행할 때까지 기다리면됩니다.

Sudo는 여러 사용자가있을 때 콘솔 로그인보다 이점이 있습니다. 예를 들어, 시스템이 원격 위조 방지 로그로 구성된 경우 항상 sudo를 마지막으로 실행 한 사람 또는 계정이 손상된 사람을 찾을 수 있지만 콘솔에서 누가 루트 암호를 입력했는지 알 수 없습니다.

우분투의 결정이 부분적으로 단순성 (기억해야 할 암호 하나)에 관심이 있고 공유 시스템 (비즈니스 또는 가족)에 대한 보안 및 자격 증명 배포 용이성에 관심이 있다고 생각합니다.

Linux에는 인증을위한 보안주의 키 또는 기타 보안 사용자 인터페이스가 없습니다. 내가 아는 한 OpenBSD에는 아무것도 없습니다. 루트 액세스가 우려되는 경우 실행중인 시스템에서 루트 액세스를 비활성화 할 수 있습니다. 루트가 되려면 부트 로더 프롬프트에 무언가를 입력해야합니다. 모든 사용 사례에 적합하지는 않습니다. (* BSD의 보안 수준 은 다음과 같이 작동합니다. 보안 수준이 높으면 보안 수준을 낮추거나 탑재 된 원시 장치에 직접 액세스하는 등 재부팅 없이는 할 수없는 일이 있습니다.)

루트가 될 수있는 방법을 제한하는 것이 항상 보안을위한 것은 아닙니다. 세 번째의 멤버 기억 보안 화음 : 기밀성 , 무결성 , 가용성을 . 시스템에서 자신을 잠그면 사고에 대응하지 못할 수 있습니다.


그들이 당신의 암호를 찾을 수 있다면, 쉽게 쉽지 않은 것처럼 쉽게 루트 암호를 찾을 수 있습니다. 또한 sysrq-k를 안전한주의 순서로 사용할 수 있습니다.
psusi

리눅스는 보안주의 키를 가지고있다 . 커널 문서를
보아라

@btshengsheng 리눅스는 는 "보안주의 키"를 가지고 있지만, 그것을 밖으로 구성 할 수 있기 때문에, 당신은 특정 시스템에서 작동 있다고 확신 할 수 없습니다. 또한 키보드 레이아웃에 의존하므로 키 중 하나를 다시 할당하여 무시할 수 있습니다. 그것은 것 이라고 는 "보안주의 키"하지만 그것은 아주 법안에 적합하지 않습니다.
Gilles

9

보안 OpenWall GNU / * / Linux 배포판의 설계자들은 su(루트가되기 위해)와에 대한 중요한 의견을 표명했습니다 sudo. 이 글을 읽고 싶을 것입니다 :

불행히도 su와 sudo는 미묘하지만 근본적으로 결함이 있습니다.

suSolar Designer 의 결함 및 기타 사항 을 논의하는 것 외에도 Solar Designer는 다음과 같은 특정 사용 이유를 목표로합니다 su.

예, 루트로 로그인하는 대신 "su root"에 대한 일반적인 sysadmin의 지혜였습니다. 요청을 받았을 때 실제로 이러한 선호에 대한 정당한 이유를 제시 할 수있는 소수의 사람들은이 접근법으로 달성 된 더 나은 책임 성을 언급 할 것입니다. 그렇습니다. 이것이 바로이 접근 방식을 선호하는 좋은 이유입니다. 그러나 그것은 또한 유일한 것입니다. ... (더 읽기)

그들의 배포판에서, 그들은 "기본 설치에서 SUID 루트 프로그램을 완전히 제거했습니다" (즉, su;를 포함하여 이것에 대한 기능을 사용하지 않습니다) :

서버의 경우 사람들은 재고를 재고하고 대부분의 경우 사용자의 su 및 sudo 호출을 허용하지 않아야한다고 생각합니다. 비 루트로 로그인하고 직접 루트 (두 개의 별도 세션)로 로그인하는 것과 비교하여 이전 "루트 비 로그인으로 로그인 한 다음 su 또는 sudo to root"sysadmin "wisdom"의 보안이 추가되지 않았습니다. 반대로 후자의 접근 방식은 보안 관점에서 유일하게 올바른 접근 방식입니다.

http://www.openwall.com/lists/owl-users/2004/10/20/6

여러 시스템 관리자의 책임을 위해서는 Owl처럼 루트 권한이있는 여러 계정을 지원해야합니다.

X가있는 데스크톱의 경우 까다로워집니다.

당신은 또한 절대적으로 처리해야합니다 ...

BTW, 그들은 여러 루트 계정으로 설정을 허용 하기 위해 대체 sulogin되었습니다 msulogin: msulogin단일 사용자 모드로 전환 할 때도 사용자 이름을 입력 할 수 있습니다 (그리고 "책임"을 유지하십시오) (이 정보는 러시아어 로이 토론에서 나옵니다 ) .


1
기본적으로 방화벽을 의미하는 시스템의 경우 훨씬 더 좋은 것은 아니지만 임의의 예로 mysql / postgresql / bind / powerdns / apache 및 프로덕션 시스템에서 실행하지 않으려는 경우 시작하십시오. X로 설명하는 것처럼 문제가 발생합니다. 본질적으로 그들은 어느 정도의 보안 성을 위해 많은 유용성을 거래했습니다. 공정한 거래인지 여부를 결정하는 것은 시스템 관리자의 책임입니다. 개인적으로 데비안을 고수하겠습니다.
Shadur

4

사용하면 sudo항상 환경 변수가 유지 된다고 가정 하지만 항상 그런 것은 아닙니다. 다음은 sudo 맨 페이지에서 발췌 한 내용입니다.

환경 변수를 처리하는 두 가지 방법이 있습니다. env_reset sudoers 옵션은 기본적으로 사용됩니다. 이로 인해 env_check 및 env_keep sudoers 옵션이 허용하는 호출 프로세스의 변수 외에 TERM, PATH, HOME, SHELL, LOGNAME, USER 및 USERNAME을 포함하는 최소 환경에서 명령이 실행됩니다. 환경 변수에 대한 화이트리스트가 효과적으로 있습니다.

그러나 sudoers에서 env_reset 옵션을 사용하지 않으면 env_check 및 env_delete 옵션에 의해 명시 적으로 거부되지 않은 모든 변수는 호출 프로세스에서 상속됩니다. 이 경우 env_check 및 env_delete는 블랙리스트처럼 동작합니다. 잠재적으로 위험한 환경 변수를 모두 블랙리스트에 올릴 수 없으므로 기본 env_reset 동작을 사용하는 것이 좋습니다.

모든 경우에 ()로 시작하는 값을 가진 환경 변수는 bash 함수로 해석 될 수 있으므로 제거됩니다. sudo가 허용하거나 거부하는 환경 변수 목록은 root로 실행될 때 sudo -V의 출력에 포함됩니다.

따라서 env_reset활성화되어 있으면 (기본값) 공격자가 사용자 PATH또는 다른 환경 변수를 무시할 수 없습니다 (특히 유지해야하는 변수의 화이트리스트에 추가하지 않는 한).


1
공격자가 내 경로를 제어 할 수 있으면 실제 / usr / bin / sudo 대신 무엇이든 실행할 수 있습니다. 예를 들어 / tmp / sudo Password: 는 입력 할 때 아무 것도 표시하지 않고 입력 한 내용을 전송하고 암호가 틀렸다고 말한 다음 실제 sudo를 실행합니다.
stribika

흠, 나는이 경우 쉘에 의존하지 않고 직접 / usr / bin / sudo를 실행할 수 있다고 생각한다. 그러나 당신 말이 맞아요, 그것은 내가 생각하지 못한 문제입니다.
Cedric

1
@ CedricStaub : 내가 말할 수있는 한 아무도 이것을 생각하지 않는 것 같습니다. 나는 전체 경로를 줄 수는 있지만 이것을 시도해보십시오 : 그 alias /usr/bin/sudo="echo pwned"외에도 암호를 훔칠 수있는 많은 프로그램 (X, xterm, shell)이 있습니다. 그렇기 때문에 안전하게 전환하는 데 너무 많은 문제가 있다고 말했습니다.
stribika

1
해봤 어? 내가 그랬어 :bash: alias: `/usr/bin/sudo': invalid alias name
maaartinus

@maaartinus : 흥미 롭습니다. ZSH에서 작동합니다.
stribika

4

가장 안전한 방법은 물리적 장치를 사용하여 키를 저장하는 (적어도) 2048 개의 긴 키 (비밀번호 로그인이 비활성화 된 상태)를 사용하는 ssh 로그인입니다.


1
물론 루트에서 루트로 또는 권한이없는에서 권한이없는 것을 루트로 전환 하시겠습니까? (실제로 안전을 위해 4096 비트 키를 사용하고 있습니다. 더 큰 키는 모든 곳에서 지원되지 않습니다.)
stribika

@stribika 글쎄, 둘 다. 기계가 손상된 경우에도 여전히 열쇠를 풀지 마십시오. 이는 확산을 방지합니다 (비밀번호 관련 가장 큰 문제).
Let_Me_Be

3

나는 조금 벗어난 주제를 추가하고 싶습니다. (주제 하나에 대해서는 '/ bin / su-'다음에 확인하십시오.)

위의 "보안"도 우리가 보호하고자하는 실제 데이터와 연결되어야한다고 생각합니다.

보안을 유지하려면 my_data, my_company_data, my_company_network와 같이 달라야합니다.

일반적으로 보안에 대해 말하면 "데이터 보안"및 백업에 대해서도 말합니다. 내결함성 시스템 등을 추가 할 수도 있습니다.

이를 감안할 때, 보안 전체는 유용성, "데이터 보안"및 보안 시스템 구현에 필요한 노력 사이의 균형이라고 생각합니다.

우분투의 목표는 여전히 최종 사용자였습니다. Sudo가 기본값입니다.

Fedora는 RedHat의 무료 버전으로 서버 지향적입니다. Sudo는 비활성화되었습니다.

다른 배포판에는 직접적인 정보가 없습니다.

나는 현재 페도라를 사용하고 있습니다. 그리고 구식 사용자로서 'su'를 입력하지 않았습니다. 그러나 타이피스트가 아니더라도 아주 짧은 시간에 "/ bin / su-"를 입력 할 수 있습니다. PATH 변수는 문제가되어서는 안됩니다 (경로를 입력하십시오). 또한 "-"(빼기) 원칙적으로 사용자 환경 변수를 제거하고 루트 변수 만로드해야합니다. 즉, 추가적인 문제를 피할 수 있습니다. 아마도 LS_PRELOAD 일 것입니다.

나머지 부분에서는 @mattdm이 꽤 정확했다고 생각합니다.

그러나 올바른 상자에 넣으십시오. 스크립팅 스마트 키트가 내 데이터에 액세스한다고 가정합니다. 도대체 그와 무슨 관계가 있다고 생각합니까? -내 사진을 게시 하시겠습니까? 나의? -내 여자 친구 이름을 찾아서 포르노 사이트를 방문한다고 말하려고합니까?

단일 사용자 사진에서 두 가지 최악의 상황은 다음과 같습니다.-아이가 모든 데이터를 삭제합니다. 또는 비슷한 목표.

첫 번째 경우에는 위에서 언급 한 것처럼 네트워크 보안보다 백업에 더 많은 노력을 기울입니다. 그렇습니다, 당신은 구원입니다. 하드웨어 충돌이 그렇게 다르지 않다는 것을 의미합니다.

두 번째 경우는 더 미묘합니다. 그러나 이러한 활동에 대한 신호가 있습니다. 어쨌든, 당신은 가능한 일을 할 수 있지만 테러 공격으로부터 가정의 PC를 보호하도록 구성하지는 않을 것입니다!

다른 시나리오는 건너 뛰겠습니다.

건배 F


2

손상된 사용자 계정을 사용하여 sudo또는에 사용 된 비밀번호를 스니핑 할 수 있다는 우려가있는 경우 및에 su일회성 비밀번호를 사용하십시오 . sudosu

원격 사용자를 위해 키를 강제로 사용할 수 있지만 규정 준수 목적으로 소집을 통과하지 못할 수 있습니다. 2 단계 인증이 필요한 SSH 게이트웨이 박스를 설정 한 다음 키 사용을 허용하는 것이 더 효과적 일 수 있습니다. 이러한 설정에 대한 문서는 다음과 같습니다 . WiKID 2 단계 인증으로 SSH 배포를 보호하십시오 .


0

또한 프라이버시 IDEA를 살펴볼 수 있습니다. OIDE 를 사용하여 컴퓨터에 로그인하거나 su / sudo를 수행 할 때 OTP를 사용할 수있을뿐만 아니라 오프라인으로 OTP를 수행 할 수도 있습니다.

또한 SSH 키를 관리 할 수 ​​있습니다. 즉, 많은 시스템과 여러 루트 사용자가있는 경우 모든 SSH 키가 중앙에 저장됩니다. 따라서 더 이상 키를 신뢰할 수없는 경우 SSH 키를 "취소"/ 삭제하기 쉽습니다.

물론 시스템을 보호하기위한 조직 작업 및 워크 플로가 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.