U-06) 파일 및 디렉터리 소유자 설정

 

 

이번 글에서는 "파일 및 디렉토리 소유자 설정" 점검 항목에 대해 알아보도록 하겠습니다. 해당 항목은 퇴사 등의 이유로 사용되지 않는 계정이 삭제된 이후, 소유자가 존재하지 않는 파일과 디렉토리가 존재하는지 확인하는데요. 사용자 계정을 삭제하고 나면 파일에 어떤 현상이 벌어지는지, 그리고 소유자가 존재하지 않는 파일을 그대로 두면 어떤 위험이 있는지를 중점적으로 말씀드리도록 하죠. 그럼 마찬가지로 취약점 개요에 대해 먼저 정리해보도록 하겠습니다.

 

 

우선 자신이 서버의 관리자라고 생각하고 기존 직원이 퇴사했을 때 해야할 일을 생각해봅시다. 기밀 정보 유출 방지를 위해서 퇴사자가 해당 서버에 더이상 접근할 수 없도록 계정을 삭제해야할텐데요. 일반적으로 userdel 명령어를 통해 기존 계정을 삭제하게 됩니다.

 

그리고 보통 계정을 생성할 때 홈 디렉토리도 같이 생성을 해주기 때문에, 홈 디렉토리를 같이 삭제하기 위해 -r 옵션을 붙여서 사용하죠. 그런데 생각해보면 해당 직원이 자신의 홈 디렉토리에서만 파일을 생성하지는 않았을 겁니다. 다른 직원과의 협업을 위해 공용 디렉토리나 tmp와 같은 임시 디렉토리에도 파일을 생성했을 수도 있을겁니다.

 

root@kali:/tmp# ls -l test1.txt
-rw-r-----  1  1000 test1     510   Jul   6  09:34 test1.txt

 

만약 퇴사한 직원이 UID 1000번을 가진 test1라는 계정을 사용하고 있었고, tmp 디렉토리에 test1.txt 파일을 생성하고 삭제하지 않았다고 가정하겠습니다. 관리자가 test1 계정을 삭제하고, tmp 디렉토리에서 test1.txt의 자세한 정보를 확인해보면, 소유자가 표시되는 부분에 계정명이 아닌 UID가 표시되는 것을 볼 수 있죠.

 

좀 더 명확하게 말씀드리면 계정을 생성했을 당시 passwd 파일에 표시된 UID가 보여지는데요. 다만 passwd 파일에서 계정은 삭제되어 UID로 보여지지만, "U-51) 계정이 존재하지 않는 GID 금지"에서 말씀드린 것처럼 계정을 삭제해도 그룹은 삭제되지 않아 그룹은 그대로 표시가 되는 것을 볼 수 있습니다.
​
그러면 이것이 왜 문제가 되는지에 대해 말씀드려보겠습니다. 만약 A라는 계정이 기밀 정보를 취급하는 임직원의 계정이었다고 하면, 비인가자에 의해 의도적으로 passwd 파일에서 특정 계정의 UID를 1000번으로 변경하여 해당 파일의 소유권을 가지게 할 수 있습니다.

 

또한 의도적이지 않더라도 계정을 생성할 때 시스템이 UID를 순차적으로 부여하다가 중간에 빈 UID를 부여하는 경우가 있는데, 이럴 경우에도 새로운 계정이 이전 A의 계정이 생성한 파일이나 디렉토리의 소유자가 되겠죠. 이러한 문제로 인해 소유자가 존재하지 않는 파일을 관리해야 한다고 생각하시면 될 것 같습니다.

 

root@kali:~# find / -nouser
/tmp/test1.txt

 

마지막으로 해당 항목을 점검하는 방법과 조치 방법에 대해 설명드릴텐데요. 여기서는 find라는 명령어를 이용하게 되는데, 특정 조건을 가진 파일이나 디렉토리를 찾을 때 사용하는 명령어라고 생각하시면 됩니다. -nouser 옵션을 이용하여 소유자가 없는 파일을 검색할 수 있죠.

 

그리고 조치 방법은 소유자가 존재하지 않는 파일의 소유자를 변경하는 것인데, 이전에 말씀드린 적이 있는 chown 명령어를 통해 소유자를 변경할 수 있습니다. 서버 관리를 하다보면 쉽게 간과할 수 있는 부분이지만, 그래도 관리적인 부분도 점검을 반드시 해야 하기 때문에 잘 짚고 넘어가셨으면 합니다. 그럼 이번 글은 여기서 마무리하도록 하죠. 읽어주셔서 감사합니다.