☰

비밀번호가 없는 사용자가 왜 나쁜 생각입니까(이 경우)?

tag-icon • tag-icon security users password non-root-user privileges
비밀번호가 없는 사용자가 왜 나쁜 생각입니까(이 경우)?

나는 이것을 여기에 게시할 것인지 아니면 보안 SE에 게시할 것인지 고민했지만... 이것은 실제로 암호화에 관한 질문이 아니고 Linux 사용자/권한에 관한 더 많은 질문이 아니기 때문에 Unix SE를 사용하기로 결정했습니다. 오늘 내 Google이 약할 수도 있지만 지금까지 내가 접한 유일한 것은

  1. 구체적인 예 없이 이것이 "나쁜 관행" 또는 "인기 없는" 것에 대해 매우 일반적인 답변을 제공합니다.
  2. 비밀번호가 없는 사용자가 루트 액세스 권한을 갖고 있다고 가정하거나 가능한 모든 보호를 포기한다는 답변이 있습니다.

명확히 하자면, 저는 이것을 옹호하는 것이 아니라 실제로 타당한 이유를 찾고 있습니다.아니요이렇게 하는데 단순히 '이건 나쁘다'가 아니라 구체적인 이유를 찾고 싶다. :-)

그럼 제가 실제로 이 질문에 대해 생각하게 된 예를 하나 들어보겠습니다.

홈 시스템 설정을 고려 중이고 내 계정에 강력한 비밀번호가 있다고 가정해 보겠습니다 root. 또한, 나는fred라는 루트가 아닌 계정그건아니요관리자 그룹 wheel(또는 sudoersDebian/Ubuntu). 이 시스템에는 /home부팅 중에 잠금이 해제되는 별도의 LUKS 암호화 파티션 도 있습니다 . 즉, 비밀번호는하다여전히 GRUB와 로그인 관리자 사이에 입력되어 있지만 로그인 관리자는 자동으로 로그인하도록 설정되어 있습니다. 이 외에도 (루트에서) 다음을 설정한다고 가정해 보겠습니다 password -f -u fred.강제 잠금 해제비밀번호 fred( fred비밀번호는 비워두는 것이 효과적입니다).

이 상황에서는 어떤 유형의 보안 문제가 발생할 수 있나요? 당신이 이 일을 하고 싶지 않다고 느끼는 데에는 그럴듯한 이유가 있어야 합니다.하지만오직지금까지 내가 생각한 것은 다음과 같습니다.

  • 화면 보호기 잠금이 실행될 때 LUKS 파티션이 닫히지 않습니다(적어도 Cinnamon에서는예트리거로 설정). 따라서 누군가 내 집에 침입하여 fred이미 로그인한 경우 fred먼저 컴퓨터를 분리/재시작/제거하지 않는 한 앉아서 모니터를 켜고 액세스할 수 있는 모든 항목을 볼 수 있습니다( 따라서 LUKS를 다시 잠급니다). 충분히 노력한다면 화면 보호기가 실행될 때 스크립트를 호출한 다음 해당 스크립트에서 LUKS를 잠그면(또는 kde/xfce/gnome/etc가 이미 어떤 방법을 가지고 있을 수도 있음) 이 취약점을 닫는 방법을 찾을 수 있을 것 같습니다. ) 이것을 처리하기 위해? ).

강력하고 강력한 비밀번호를 사용 하더라도 fred관리자가 아니면 소프트웨어를 설치할 수 없으며 시스템 설정이 엉망이 됩니다. 또한 확실하지 않지만 파일에 대한 브라우저/와인 액세스가 어떤 식으로든 변경되지 않는다고 생각합니다. 만일의 경우보다 더 위험한 것이 있습니까?fred 했다비밀번호가 있나요?

편집: 중요하지 않다고 생각하지만 배포판은 Fedora(SELinux 활성화)이지만 다른 배포판(또는 SELinux 활성화하지 않음)으로 응답하는 것이 더 편하다고 느끼면 그것도 괜찮습니다.

편집 #2: 관련 ssh/ samba. 저는 보통 삼바 공유 등을 /media/sdb1/shared사용하기보다는 폴더 같은 것을 설정합니다 . $HOME나는 이것이 집과 같은 소규모 사용자 환경에서 설정하는 것이 매우 쉽다는 것을 알았습니다. (분명히 작업 환경이나 모든 사용자가 서로를 신뢰하지 않는 환경에서는 이 작업을 수행하지 않을 것입니다.) 하지만 저는 항상 별도의 비밀번호로 보호된 Samba 사용자 계정(로그인한 사용자 계정과 다름)을 사용하고 smb.conf설정을 강화하기 위한 몇 가지 지침을 따릅니다. 이 설정에서 결함을 발견하면 로그인 계정에 빈 비밀번호를 사용하여 가상 시나리오/설정을 공격하는 데 유효하다고 가정합니다 fred(삼바 계정 비밀번호는아니요비어 있지만).

의 경우 ssh기본적으로 빈 비밀번호가 거부되는지 확인하고 싶습니다.모두계정(뿐만 아니라 root). 그렇지 않다면 FelixJN의 답변이 유효하다고 생각합니다. 그렇지 않으면 아마도 samba일반적으로 사용하는 것과 동일한 설정, 즉 기본 구성의 강화된 버전을 사용할 것입니다. 이에 대한 많은 설정을 변경한 기억이 없으므로 일반적으로 수정한 내용을 정확히 찾아 여기에 포함시킬 수 있는지 알아보겠습니다. 모르겠어요. 포트 번호를 변경해도 상관없다는 걸 압니다.

거부를 확인했을 때 LM19가 (force) 플래그를 지원하지 않는 것 같아서 이상하게도 Fedora에서는 루트가 아닌 빈 비밀번호만 생성할 수 있다는 ssh사실에 놀랐습니다 . LM19 상자에서 페도라로 전환 하려고 하면 거부됩니다.passwd-fssh

    $ ssh -p 2468 fred@fedora-testbox
    fred@fedora-testbox's password: 
    Permission denied, please try again.
    fred@fedora-testbox's password: 
    Permission denied, please try again.

포트 외에도 허용되는 최소 비밀번호/MAC/KexAlgorithms를 늘리고 // 줄인 후 LoginGraceTime//를 설정한 것 같습니다. 을 위한:MaxAuthTriesMaxSessionsPermitRootLogin noUsePAM yesChallengeResponseAuthentication noPermitEmptyPasswords아니요가 기본값인 것 같습니다.하지만 저는 분명히 했습니다.

답변1

제가 생각하는 가장 큰 실제적인 이유는 일부 네트워크 소프트웨어를 사용하면 누군가가 비밀번호 없이 원격으로 컴퓨터에 로그인할 수 있다는 것입니다. 위험은 당신이 알고 있는 소프트웨어에 있는 것이 아니라, 당신이 고려하지 않는 소프트웨어에 있습니다. 어쩌면 배포판과 함께 제공된 소프트웨어일 수도 있습니다.

비밀번호가 없는 사용자의 경우 컴퓨터의 모든 네트워크 연결 서비스를 확인하여 비밀번호 없이 원격 로그인을 허용하는지 확인해야 합니다.

일반적인 보안 원칙은 모든 사람을 잠그고 누구도 들어오지 못하게 하여 "실패"하려는 것입니다. 비밀번호가 없는 사용자가 있는 경우 실수나 단순한 부주의로 인해 어딘가에 백도어가 잠금 해제되기가 더 쉽습니다.

예를 들어 이메일 서버를 들 수 있습니다. 공용 IPv4 주소가 있는 머신이 있는 경우 다음이 보장됩니다.~ 할 것이다매주 또는 매일 SMTP에 로그인해 보세요. 해커는 취약한 시스템을 찾기 위해 모든 IPv4 주소를 샅샅이 뒤집니다(주소는 40억 개에 불과합니다).

SSH에서도 마찬가지입니다. OpenSSH는 비밀번호 없이(인증 필요 없음) 로그인 시도를 거부하도록 구성되어 있으므로 아마도 안전할 것입니다. 하지만 매일 해커들이 비밀번호가 비어 있는 사용자 이름을 찾으려고 노력하는 것을 봅니다. 그들은 단지 수천 개의 공통 사용자 이름을 순환하면서 행운이 있기를 바랄 뿐입니다.

답변2

나는 보통 다음과 같은 측면을 고려합니다.

  1. 원격 액세스:

활성 액세스 와 같은 원격 액세스 옵션이 있는 경우 ssh이는 분명한 이유로 열린 문입니다. 이 경우 특히 2항과 3항이 적용됩니다.

  1. 데이터 개인정보 보호 및 보안:

귀하의 사용자는 권한이 없는 사용자가 접근해서는 안 되는 정보를 노출하고 있으며, 물론 귀하의 날짜는 누구든지 삭제할 수 있습니다. 어떤 사람들은 단지 파괴적입니다.

  1. 시스템 보안:

물론 공식 사용자에게는 관리자 권한이 없지만 해킹이 불가능한 시스템은 없습니다. 누군가가 사용자로서 액세스 권한을 얻으면 악성 코드 업로드, 보안 허점 악용, 로컬에서 프로그램 컴파일 및 시스템 손상을 막을 수 있는 방법은 없습니다.

그것은 다른 사람의 길에 얼마나 많은 돌을 던질 의향이 있는지에 달려 있습니다.

따라서 문제는 로그인을 자동화하고 이러한 위험 중 적어도 일부를 방지하여 물리적 액세스에 대한 필요성을 최대한 높게 유지할 수 있는데 왜 비밀번호가 없는 사용자를 사용하는가입니다.

관련 정보