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


27

/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원격으로 누군가가 bin상자에서 실행중인 서비스에서 사용자의 디렉토리에 ssh 키를 삽입 할 수 있으므로 가능한 경우 사용자의 로그인을 완전히 비활성화하고 싶습니다 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/falsewww-data.

  • 내가 너무 편집증입니까?

중요한 경우 데비안을 실행하고 있습니다.


관련 질문은 unix.stackexchange.com/questions/485505 입니다.
JdeBP

답변:


22

유효한 쉘을 가지고 있고 암호가없는 사용자는 여전히 암호 기반이 아닌 방법으로 로그인 할 수 있습니다. 가장 일반적인 방법은 ssh 키입니다. cron 작업을 실행하려면 유효한 쉘이 필요합니다. 유효한 쉘도 su bin -c 'wibble'작동해야합니다 (최소한 Linux에서는 su bin -s /bin/sh -c 'wibble'작동합니다).

의 경우 bin대부분의 시스템 bin은 정상 작동에서 와 같이 명령을 실행하지 않으므로 셸을 /bin/false올바르게 설정하면 됩니다.

binSSH를 통해 로그인 할 수있는 직접 공격의 위험은 없습니다 . 왜냐하면 /bin/.ssh/authorized_keys사용자 bin또는 루트 로 작성해야하기 때문입니다 . 다시 말해, 들어갈 수있는 유일한 방법은 들어가는 것입니다. 그러나 유효한 쉘을 사용하면 구성 오류의 위험이 높아집니다. 또한 SSH 이외의 서비스로 일부 원격 공격을 허용 할 수도 있습니다. 예를 들어, 사용자 는 공격자가 Samba를 통해 원격으로 암호를 설정 한 다음 해당 암호를 사용하여 SSH를 통해 로그인 할 수 있다고 보고 합니다 daemon.

DenyUsers지시문에 시스템 사용자 이름을 나열하여 SSH 구멍을 막을 수 있습니다 /etc/ssh/sshd_config(불행히도 숫자 범위는 사용할 수 없습니다). 반대로, AllowGroups지시문을 작성하고 실제 사용자를 포함하는 그룹 만 허용 할 수 있습니다 (예 : users모든 실제 사용자에게 그룹 멤버십을 부여하는 경우).

데비안 ( # 274229 , # 330882 , # 581899 )에는 현재이 문제에 대해 버그가 제기되어 있으며 현재 열려 있고“wishlist”로 분류되어 있습니다. 나는 이것이 버그이며 시스템 사용자 /bin/false가 달리 할 필요가없는 한 쉘로 가지고 있어야한다는 데 동의하는 경향이 있습니다 .


6

사용자라는 것에 대해 걱정할 필요가 없습니다. 이들은 "로그인 및 사용"이라는 의미의 사용자가 아니라 보안 그룹의 의미에서 "사용자"입니다. "/ etc / shadow"를 살펴보면이 "사용자"모두에 암호가없는 것을 알 수 있습니다 (긴 솔트 해시 대신 "x"또는 "!"). 즉, 이러한 사용자는 무엇이든 로그인 할 수 없습니다.

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

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


1
에 해시 없음에 대한 장점은 /etc/shadow있지만 서비스가 사용자로 실행되는 경우 이론적으로 누군가가 ssh로그인 키 를 삽입 할 수 있습니까?
Mike Pennington

그들이 이미 루트 권한으로 귀하의 계정에 로그인 한 경우에만 ...이 경우,이 사용자들은 귀하의 걱정을 가장 적게합니다 : -P
Chris

방금 나열된 모든 제약 조건에 동의하지 않습니다. 이것이 사실이라면, 열린 rpcd포트는 문제가되지 않습니다. 그러나 필자는 구식 Solaris 시스템에서 공격자가 rpc박스에 있는 익스플로잇을 통해 액세스 한 원격 익스플로잇의 결과를 개인적으로 목격했습니다 . rhosts해당 rpc사용자 가 활성화하고 쓸 수 ~/.ssh/authorized_keys있음 암호에서 /etc/shadow)
마이크 페닝 턴

예, 그러나 그러한 악용은 SSH를 통한 것이 아닙니다. 프로그램은 일반적으로 사용자가 말한대로 자신의 사용자로 실행됩니다. 프로그램의 악용 (예 : 버퍼 오버플로 악용)은 악의적 인 사용자가 해당 프로그램이 액세스하는 셸에 액세스하도록 할 수 있습니다. 그러나 해당 프로그램은 해당 프로그램의 용도에 관계없이 액세스 할 수 있어야합니다 (그렇지 않으면 필요한 작업에 액세스 할 수 없음). 따라서 권한이 올바르게 설정되어 있어야합니다. rpc 데몬의 악용은 소프트웨어를 업데이트하거나 제한하여 해결할 수있는 큰 문제입니다.
Chris

1
죄송합니다. 공간이 부족합니다. 프로그램이 액세스 할 수있는 셸을 변경하면 해당 문제가 해결되지만 프로그램이 실제로 수행해야하는 작업에 더 많은 문제가 발생합니다. 나는 당신이 원래 악의적 인 사용자가 그 사용자를 통해 SSH에 접속할 수 있다는 것을 의미한다고 생각했습니다. sshd_config에서 "AllowUsers <username> <username> ..."을 지정하여 특정 사용자 SSH 액세스 만 허용함으로써 작은 문제를 해결할 수 있습니다.
Chris

1

bin홈 디렉토리 ( /bin) 에 SSH 공개 키를 설정 하려면 침입자가 파일 시스템에 대한 루트 액세스 권한을 가져야하므로 문제가 될 수 있습니다.

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

빈 사용자가 최신 데비안 파생 시스템에서 사용되지 않고 순전히 전통을 고수하거나 일부 표준을 준수하는 것처럼 보입니다.

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