nologin 쉘을 사용하여 사용자 삭제

nologin 쉘을 사용하여 사용자 삭제

프로덕션 Linux 서버에서 수행된 보안 감사 중에 아무도 사용하지 않는 애플리케이션이 있는 경우 none 사용자를 제거하라는 요청을 받았습니다.

확인해 보니 "nobody" 사용자가 소유한 파일이 없습니다.

find / -path /proc -prune -o -user nobody -ls

"nobody" 사용자는 셸에 로그인하지 않습니다. 마찬가지로 로그인하지 않은 사용자도 보안 위협을 가합니까? 로그인 셸 없이 이러한 사용자를 삭제하는 것이 권장됩니까?

# grep nobody /etc/passwd
nobody:x:99:99:Nobody:/:/sbin/nologin

당신의 생각을 알려주십시오.

답변1

시스템 계정(예: 루트, sys, 없음, bin, 데몬 등)의 존재 여부는 제가 수년에 걸쳐 겪은 많은 보안 감사의 대상이었으며 이는 실제로 몇 가지 사항으로 요약됩니다.

예, 이러한 유형의 계정은 특히 셸이 활성화된 경우 보안 허점이 될 수 있습니다.

  • 나쁜

    bin:x:1:1:bin:/bin:/bin/sh
    
  • 좋아요

    bin:x:1:1:bin:/bin:/sbin/nologin
    

구성되었거나 /sbin/nologin때때로 /bin/false이러한 계정은 로그인할 수 없지만 여전히 프로세스를 소유할 수 있습니다. 문서를 소유할 수도 있습니다.

파일 소유권

둘 중 더 쉽기 때문에 먼저 파일의 소유권을 가져오겠습니다.

이러한 항목을 파일 소유권에 포함 /etc/passwd하고 연관시키는 데 따른 위험은 없습니다. /etc/group이 용량에서 이러한 기능이 있으면 도구의 출력이 ls다음과 같이 표시됩니다.

  • /etc/passwd에 항목이 있습니다.

    $ ls -l woof
    -rwxrwxr-x 1 saml saml 20284 May 31  2012 woof
    
  • /etc/passwd에 액세스할 수 없습니다.

    $ ls -n woof
    -rwxrwxr-x 1 500 501 20284 May 31  2012 woof
    

따라서 이러한 관점에서는 관리자가 디스크에 기록된 UID/GID로 소유자 이름을 볼 수 있는 것이 더 좋을 것입니다. 그러나 이러한 항목은 시스템에서 UID/GID를 생성할 수 있는 추가 적용을 제공하지 않습니다. 예를 들면 다음과 같습니다.

$ touch afile && chown 10000:10000 afile
$ ls -l | grep afile
-rw-r--r--  1 10000 10000      0 Jun 11 05:11 afile

이러한 항목이 있을 때 발생하는 유일한 실제 위험은 잠재적인 공격자가 파일 시스템에서 파일을 숨기고 파일에 진정한 소유권을 부여하여 해당 파일이 해당 파일에 속한 것처럼 보이게 할 수 있다는 /etc/passwd것 입니다./etc/group

프로세스 소유권

이는 실제로 대부분의 감사인이 감사를 수행할 때 어려움을 겪는 문제입니다.시스템 계정의 항목입니다 /etc/passwd. 그들은 파일의 항목이 범위를 제한한다는 인상을 받았습니다. 하지만 여기에 문제가 있습니다. 마찬가지로, /etc/passwd조각화된 UID/GID가 있는 파일을 생성하는 기능을 제한하지 않으며 프로세스가 원하는 UID/GID를 사용하여 실행하도록 강제하지도 않습니다.

다음 Q&A를 참조하세요.setuid는 매우 큰 숫자를 설정합니다..

UNIX에는 프로세스 소유자를 제어하는 ​​4가지 C 함수가 있습니다.

  • setuid()- 사용자 ID 설정
  • seteuid()-유효한 사용자 ID 설정
  • setgid()- 그룹 ID 설정
  • setegid()- 유효 그룹 ID 설정

더 높은 권한을 가진 계정으로 실행하는 경우 원하는 대로 이러한 기능을 호출할 수 있습니다. 예를 들어:

  • setuid(500); setuid(0);답변: 500/500(첫 번째 호출은 500/500을 생성하고 두 번째 호출은 실패함)
  • seteuid(500); setuid(0);답변: 0/500(첫 번째 호출은 500/500을 생성하고 두 번째 호출은 0/500을 생성합니다).
  • seteuid(600); setuid(500);답변: 500/500(첫 번째 호출은 600/500을 생성하고 두 번째 호출은 500/500을 생성합니다).
  • seteuid(600); setuid(500);setuid(0); 답변: 0/500(첫 번째 호출은 600/500을 생성하고, 두 번째 호출은 500/500을 생성하고, 세 번째 호출은 0/500을 생성합니다).

위의 코드는 여기에서 빌려왔습니다:Set-UID 권한 있는 프로그램 - 유인물.

그러므로 사용자 입장을 고려하여아무도상승된 권한(예: sudo)이 없으면 서버/서비스를 다음과 같이 실행할 수 있는 옵션이 없습니다.아무도다음을 제외한 모든 하위 프로세스를 생성할 수 있습니다.아무도. 이 서버/서비스가 아무도 실행하지 않는 경우 소유한 파일만 손상됩니다.아무도위험이 있을 것입니다.

제공하다

시스템 보호에 접근할 때 집중해야 할 가장 중요한 영역은 실제로 특정 시스템에서 실행되는 서비스와 해당 시스템에 설치된 소프트웨어입니다.

프로덕션 시스템의 경우 설치에는 gcc/g++와 같은 개발 도구가 포함되어서는 안 되며 기본 서비스만 실행해야 합니다. 시스템에 설치된 소프트웨어를 정기적으로 업데이트하기 위한 업데이트 전략을 개발해야 합니다.

종합해 보면, 이는 파일에 있는 시스템 관련 활동에 대한 다른 계정의 존재와 관련이 없습니다 /etc/passwd.

윈도우

여기서 이것을 언급하는 이유는 궁극적으로 감사자 10명 중 9명이 Windows 보안에 익숙하고 UNIX 보안에는 덜 익숙할 수 있기 때문입니다.

Windows 시스템을 살펴보면 특정 사용자와 직접 연결되지 않은 12개의 사용자 계정을 볼 수 있습니다. 이는 시스템 계정이며 그 목적은 다음과 같은 계정과 동일합니다.아무도공급. 이 기능이 없거나 비활성화된 경우 Windows 시스템은 효율적으로 실행되지 않습니다. UNIX 시스템에서도 마찬가지입니다.

일반적으로 이러한 방식으로 설명하면 대부분의 감사자는 이러한 계정이 필요한 특정 시스템에 유지될 수 있거나 유지되어야 하는 이유를 이해할 수 있습니다.

인용하다

답변2

IIRC에서는 데몬이 아무도 실행하지 않는 것이 매우 일반적입니다. 따라서 출시 후에는 필요한 것 이상의 권리가 없다는 것이 분명합니다(아무것도 없음).

예를 들어, 이렇게 하면:

ps -u nobody

dnsmasq내 시스템에서는 프로세스로 표시됩니다 .

확인을 찾을 수 없지만 이러한 계정을 삭제하는 것이 현명하지 않다고 생각하며 해당 계정 이름을 사용하는 프로세스에 대한 합리적인 대체 방법이 있는지도 모르겠습니다.

관련 정보