"bin" 사용자에게 로그인 쉘이 필요한 이유는 무엇입니까?

"bin" 사용자에게 로그인 쉘이 필요한 이유는 무엇입니까?

/var/log/auth.log공개 웹 서버 중 하나를 감사하는 동안 다음을 발견했습니다.

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

언뜻 보면 이는 ssh임의의 해커가 보낸 일반적인 로그인 스팸 이메일처럼 보였지만, 자세히 살펴보니 다른 점이 있었습니다. 대부분의 실패한 /var/log/auth.log항목은 invalid user다음과 같습니다.

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

실패한 로그인 메시지에 대한 충격적인 점 bin은 다음과 같습니다.유효한 사용자/etc/passwd로그인 쉘도 있습니다 .

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

PermitRootLogin나는 비활성화되었을 때 원격으로 로그인하는 데 사용할 수 있는 모든 기본 사용자 이름을 다루었다고 생각했습니다. /etc/ssh/sshd_config이 항목을 발견하면 편집증적인 마음에 새로운 가능성이 열렸습니다. 어떻게든 서비스가 실행 중이 bin라면 누군가가 컴퓨터에서 실행 중인 서비스의 ssh 키를 사용자 디렉터리에 삽입했을 가능성이 높으므로 bin가능하다면 사용자 로그인을 완전히 비활성화하고 싶습니다 bin.

질문

  • 서버가 원격이고 수리 비용이 많이 듭니다(예: 원격 사용자가 KVM에 연결하는 비용과 KVM 임대 비용을 지불합니다). /etc/passwd항목을 다음과 같이 변경 하면 bin어떤 문제가 발생할 수 있는지 알아내려고 노력 중입니다.

    bin:x:2:2:bin:/bin:/bin/false

  • 필요한 것이 무엇 인지 알아보기 위해 다음 명령을 실행했습니다. bin그러나 이 명령과 함께 파일이 나타나지 않으며 해당 명령이 소유한 프로세스를 찾을 수 없습니다 bin. 사용자가 정확히 무엇을 했나요 bin?

    $ sudo find / -group bin

    $ sudo find / -user bin

  • 로그인 쉘을 이것으로 설정해야 하는 다른 사용자가 있습니까 /bin/false? 참고로 저는 이미 /bin/false갖고 있어요 www-data.

  • 제가 너무 편집증적인 걸까요?

그게 중요하다면 저는 데비안을 사용하고 있습니다.

답변1

유효한 쉘이 있고 비밀번호가 없는 사용자는 비밀번호 기반이 아닌 방법(가장 일반적으로 SSH 키)을 통해 로그인할 수 있습니다. 크론 작업을 실행하려면 유효한 셸이 필요합니다. 이것이 작동하려면 유효한 쉘도 su bin -c 'wibble'필요합니다(적어도 Linux에서는 su bin -s /bin/sh -c 'wibble').

bin대부분의 시스템은 명령을 일반 작업으로 실행하지 않으므로 쉘 bin을 로 설정하는 /bin/false것이 좋습니다.

bin/bin/.ssh/authorized_keysSSH를 통한 로그인을 허용하면 사용자 또는 루트로 bin로그인 해야 하므로 직접적인 공격 위험이 발생하지 않습니다 . 즉, 들어갈 수 있는 유일한 방법은 들어가는 것입니다. 그러나 유효한 셸이 있으면 구성이 잘못될 위험이 높아집니다. 또한 SSH 이외의 서비스를 사용하는 일부 원격 공격도 허용합니다.보고서공격자는 Samba를 통해 원격으로 비밀번호를 설정한 daemon다음 해당 비밀번호를 사용하여 SSH를 통해 로그인할 수 있습니다.

DenyUsers지시문에 시스템 사용자의 이름을 나열하여 SSH 취약점을 해결할 수 있습니다 /etc/ssh/sshd_config(안타깝게도 숫자 범위는 사용할 수 없습니다). 또는 반대로 AllowGroups지시어를 입력하고 물리적 사용자가 포함된 그룹만 허용할 수 있습니다(예: users모든 물리적 사용자에게 해당 그룹의 멤버십을 부여하는 경우).

Debian에는 이 문제에 대한 버그가 있습니다(#274229,#330882,#581899), 현재 공개되어 있으며 "위시리스트"로 분류되어 있습니다. 나는 이것이 버그이며 시스템 사용자가 /bin/false필요해 보이지 않는 한 이것을 쉘로 사용해야 한다는 데 동의하는 경향이 있습니다.

답변2

사용자로서 이에 대해 걱정할 필요가 없습니다. 그들은 "로그인하고 사용하는" 사람들의 의미에서 사용자가 아니라 보안 그룹의 의미에서 "사용자"입니다. "/etc/shadow"를 보면 이러한 "사용자" 모두가 비밀번호(긴 솔트 해시 대신 "x" 또는 "!")를 갖고 있지 않음을 알 수 있습니다. 이는 해당 사용자가 어쨌든 로그인할 수 없음을 의미합니다.

즉, 이러한 모든 사용자에 대해 "/bin/sh"를 "/bin/false"로 변경하는 것이 좋은 생각인지는 모르겠습니다. 프로그램은 이러한 그룹에서 실행되기 때문에 필요한 명령을 실행하지 못할 수도 있습니다. 저는 "/bin/sh"로 남겨둡니다.

이러한 사용자에 대해 걱정할 필요가 없습니다. 생성한 사용자(및 "/etc/shadow"에 해시가 있는 사용자)만 걱정하세요.

답변3

bin홈 디렉터리( )에 SSH 공개 키를 설정하려면 /bin공격자가 파일 시스템에 대한 루트 액세스 권한을 가지고 있어야 하기 때문에 이것이 문제가 되지 않는다고 생각합니다. 이는 어쨌든 여러분이 망했다는 뜻입니다.

원하는 경우 bin이 블록을 사용하여 sshd 구성에서 사용자에 대한 모든 인증 방법을 비활성화 할 수 있습니다 MatchUser.

즉, bin 사용자는 순전히 전통에 대한 고개를 끄덕이거나 특정 표준을 준수하기 위해 현대 데비안 파생물에서 이를 사용하지 않는 것으로 보입니다.

관련 정보