프로덕션 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
내 시스템에서는 프로세스로 표시됩니다 .
확인을 찾을 수 없지만 이러한 계정을 삭제하는 것이 현명하지 않다고 생각하며 해당 계정 이름을 사용하는 프로세스에 대한 합리적인 대체 방법이 있는지도 모르겠습니다.