이 글을 여기에 올릴지 아니면 보안 SE에 올릴지 고민했지만... 이것은 실제로 암호화에 관한 질문이 아니라 Linux 사용자/권한에 관한 질문이기 때문에 Unix SE를 사용하기로 결정했습니다. 오늘 내 google-fu가 약할 수도 있지만 지금까지 내가 본 유일한 것은
- 구체적인 예 없이 "나쁜 습관" 또는 "눈살을 찌푸리는 행위"라는 매우 일반적인 손으로 대답하는 경우, 또는
- 비밀번호가 없는 사용자가 루트 액세스 권한을 갖고 있거나 가능한 모든 보호 기능을 폐기하고 있다고 가정하는 응답이 있습니다.
명확히 하자면, 저는 이것을 옹호하는 것이 아니며 실제로 타당한 이유를 찾고 있는 것입니다.~ 아니다그렇게 하고 싶지만 단순히 "나쁘다"는 것보다 그 이유가 무엇인지 구체적인 이유를 찾고 싶습니다. :-)
그럼 그건 제쳐두고, 제가 처음에 이것에 대해 실제로 생각하게 만든 예를 설정하겠습니다.
계정에 강력한 비밀번호가 있는 홈 시스템 설정을 고려 중이라고 가정해 보겠습니다 root. 게다가, 나는fred라는 루트가 아닌 계정그건아니다관리자 그룹 wheel(또는 sudoersDebian/Ubuntu)에 있습니다. 이 시스템에는 /home부팅 프로세스 중에 잠금이 해제되는 별도의 LUKS 암호화 파티션 도 있습니다 . 즉, 비밀번호하다여전히 GRUB와 로그인 관리자 사이에 입력되지만 로그인 관리자는 자동 로그인으로 설정됩니다. 이 외에도 (루트에서) 다음을 설정 password -f -u fred한다고 가정해 보겠습니다.강제 잠금 해제비밀번호 fred(효과적으로 fred빈 비밀번호를 갖게 함).
이 상황에서는 어떤 종류의 보안 문제가 발생할 수 있습니까? 이 일을 하고 싶지 않은 데에는 타당한 이유가 있어야 할 것 같습니다.하지만오직지금까지 생각나는 것은 다음과 같습니다.
- 화면 보호기 잠금이 실행될 때 LUKS 파티션이 닫히지 않습니다(적어도 Cinnamon에서는 그렇지 않고~이다트리거되도록 설정) 따라서 누군가 내 집에 침입하여 이미 로그인한 경우에는 먼저 PC를 분리/재부팅/휴대하지 않는 한
fred앉아서 모니터를 켠 다음 액세스할 수 있는 모든 항목을 살펴볼 수 있습니다 (fred따라서 LUKS를 다시 잠급니다). 그리고 충분히 열심히 노력하면 화면 보호기가 실행될 때 스크립트를 호출한 다음 해당 스크립트에서 LUKS를 잠가서 이 구멍을 닫을 수 있는 방법을 찾을 수 있을 것입니다(또는 kde/xfce/gnome/etc가 이미 어떤 방법을 가지고 있을 수도 있습니다). 이걸 처리하려고?).
강력한 비밀번호가 있더라도 fred관리자가 아니면 소프트웨어를 설치하거나 시스템 설정을 망칠 수 없었습니다. 그리고 확실하지는 않지만 파일에 대한 브라우저/와인 액세스는 어느 쪽이든 변경되지 않을 것이라고 생각합니다. 여기보다 더 위험한 것이 있습니까?fred 했다비밀번호 있어요?
편집: 중요하지 않다고 생각하지만 배포판은 Fedora(SELinux 포함)이지만 다른 배포판(또는 SELinux 제외)에 관해 더 편안하게 대답할 수 있다면 괜찮습니다.
편집 #2: 관련 ssh/ samba. 나는 일반적으로 삼바의 공유나 소위 말하는 것을 /media/sdb1/shared사용하기보다는 폴더 같은 것을 설정합니다. $HOME집과 같은 소규모 사용자 환경에서는 이 작업을 매우 쉽게 설정할 수 있습니다(분명히 작업 환경이나 모든 사용자가 서로를 신뢰하지 않는 환경에서는 이 작업을 수행하지 않을 것입니다). 하지만 저는 항상 별도의 비밀번호로 보호된 삼바 사용자 계정(로그인한 사용자와 동일하지 않음)을 사용하고 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/ MaxAuthTries/ MaxSessions, 설정 PermitRootLogin no/ UsePAM yes/ 을 줄인 것 같습니다 ChallengeResponseAuthentication no. 을 위한 PermitEmptyPasswords:아니오가 기본값인 것 같았습니다.그러나 나는 명시적으로 말했다.
답변1
제가 생각하는 가장 큰 실제적인 이유는 일부 네트워크 소프트웨어를 통해 누군가가 비밀번호 없이 원격으로 귀하의 컴퓨터에 로그인할 수 있다는 것입니다. 위험은 당신이 알고 있는 소프트웨어가 아니라 당신이 생각하지 못한 소프트웨어에 있습니다. 아마도 배포판과 함께 제공되는 소프트웨어일 것입니다.
비밀번호가 없는 사용자의 경우 컴퓨터의 모든 네트워크 연결 서비스를 확인하여 비밀번호 없이 원격 로그인을 허용하는지 확인하는 것이 귀하의 임무입니다.
일반적인 보안 원칙은 누군가를 허용하는 대신 모든 사람을 차단하여 "실패"하기를 원하는 것입니다. 비밀번호가 없는 사용자가 있는 경우 실수와 단순한 실수로 인해 어딘가에 백도어가 잠금 해제될 가능성이 더 높습니다.
그러한 예 중 하나가 이메일 서버일 수 있습니다. 공용 IPv4 주소를 가진 머신이 있다면 보장됩니다.~ 할 것이다매주 또는 매일 SMTP에 로그인을 시도합니다. 해커는 취약한 시스템을 찾기 위해 모든 단일 IPv4 주소를 순환합니다(주소는 40억 개에 불과합니다).
마찬가지로 SSH. OpenSSH는 비밀번호 없이(인증 없이) 로그인 시도를 거부하도록 구성되어 있으므로 안전할 가능성이 높습니다. 그러나 나는 빈 비밀번호로 사용자 이름을 찾으려는 해커들의 시도를 매일 몇 번씩 목격합니다. 그들은 행운을 빌기 위해 수천 개의 일반적인 사용자 이름을 순환합니다.
답변2
나는 일반적으로 다음과 같은 측면을 고려합니다.
- 원격 액세스:
활성 과 같은 원격 액세스 옵션이 있는 경우 ssh이는 분명한 이유로 열린 문입니다. 이 경우 특히 2번과 3번 항목이 적용됩니다.
- 데이터 개인정보 보호 및 보안:
귀하의 사용자는 권한이 없는 사용자가 사용할 수 없는 정보를 노출하며 물론 귀하의 날짜가 누구에 의해 삭제될 수도 있습니다. 어떤 사람들은 단지 파괴적입니다.
- 시스템 보안:
물론 공식적으로 사용자에게는 관리자 권한이 없지만 해킹할 수 없는 시스템은 없습니다. 누군가가 사용자로 액세스하면 누구도 악성 코드 업로드, 보안 허점 악용, 로컬에서 프로그램 컴파일 및 시스템 침해를 막을 수 없습니다.
누군가의 길을 가로막는 돌을 얼마나 많이 놓느냐의 문제입니다.
따라서 문제는 자동 로그인을 통해 이러한 위험 중 적어도 일부를 피할 수 있고 물리적 액세스에 대한 필요성을 최대한 높일 수 있는데 왜 비밀번호가 없는 사용자가 있는 걸까요?