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

나는 이것을 여기에 게시할 것인지 아니면 보안 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아니요가 기본값인 것 같습니다.하지만 저는 분명히 했습니다.