U-51) 계정이 존재하지 않는 GID 금지

 

 

오늘은 "계정이 존재하지 않는 GID 금지"라는 다소 설명드리기 애매한 점검 항목에 대해 말씀드리도록 하겠습니다. 해당 항목이 애매하다고 표현한 이유는 사실 이와 같은 상황에서 발생하는 취약점을 명확하게 설명드리지 못하기 때문인데요. 이후 확실하게 말씀드릴 수 있는 상황을 찾는다면 추가적인 설명을 드리도록 하겠습니다. 그래서 이번 글에서는 해당 항목을 기술적 측면이 아닌 관리적인 측면에서 설명드리도록 할텐데요. 그럼 이전 글과 마찬가지로 점검 가이드에 나와있는 취약점 개요에 대해 먼저 정리하고 가도록 하죠.

 

 

이번 점검 항목의 내용 자체는 굉장히 간단합니다. 불필요한 그룹이 존재하면 해당 그룹을 삭제하는 것인데, 점검하는 방법과 조치 방법까지는 어느 정도 예상하실 수 있겠죠. 하지만 문제는 불필요한 그룹의 소유권으로 설정된 파일이 노출되었을 때 발생할 수 있는 위험에 대해서는 설명하기 어렵다는 겁니다.

 

예를 들어 adduser 명령어를 통해 test라는 계정을 생성하고 userdel 명령어를 통해 test를 삭제하면, /etc/passwd 파일에서는 해당 계정이 제거된 것을 볼 있는데요. 그런데 /etc/group 파일에서는 test라는 그룹이 그대로 남아있게 됩니다. 계정을 삭제하면 그룹까지 삭제해야 한다는 건 명확하겠지만, 그렇다고 해도 test 그룹의 소유권으로 남아있는 파일이 비인가자에게 노출되어 발생할 수 있는 위험이 존재하는지는 확실히 설명할 수 없죠.

이처럼 이번 점검 항목에서 발견되는 위험을 기술적으로는 명확하게 설명드리기 어려운데요. 그래서 관리적인 측면으로 말씀드릴텐데, 여기서는 회사에서 퇴사자의 계정을 처리해야 하는 시나리오를 생각해보겠습니다. 개발자의 경우 리눅스 개발 서버에 접속할 수 있는 계정을 관리자로 부터 할당 받아서 사용하고 있겠죠.

 

그런데 이 개발자가 갑자기 퇴사를 한겁니다. 퇴사한 개발자에게 부여된 계정은 더이상 사용되면 안되기 때문에, 서버 관리자는 리눅스에서 userdel 명령어를 이용해서 해당 계정을 삭제하겠죠. 그런데 일반적으로 /etc/passwd에 있는 계정만 삭제되고 /etc/group에 있는 그룹은 삭제되지 않기 때문에, 계속해서 퇴사 후 해당 계정의 그룹이 남게된다면 그룹이 제대로 관리되지 않는다고 볼 수 있습니다.

그러면 점검 방법에 대해서 알아볼텐데요. 주통기 점검 가이드에서는 그룹을 생성해놓고 추후에 계정을 할당할 수 있기 때문에, 무분별하게 삭제하지 말고 GID 500 이상의 신규 생성된 그룹을 중점적으로 점검하라고 권고하고 있습니다. 보통 GID가 500 이하인 그룹들은 시스템에서 사용하는 그룹이기 때문에 건드리지 않는 것이 좋겠죠.

 

그리고 여기서 짚고 넘어가야 할 것은 계정을 만들면서 동시에 /etc/group에 생성되는 그룹에는 만들어진 계정이 포함되지 않는다는 점입니다. 이게 무슨 말인지 잘 이해가 가시지 않겠지만 해당 파일의 내용을 보시면 바로 아실 수 있을텐데요. 아래의 명령어 결과에 보이는 것처럼, 관리자나 사용자가 직접 그룹에 계정을 추가해주지 않는 이상 계정은 모두 비어있습니다. 그렇기 때문에 계정이 존재하지 않는 그룹을 점검을 하더라도 어불성설인 경우가 많죠.

 

root@kali:~# cat /etc/group
root:x:0:
daemon:x:1:
...
test1:x:1000:
test2:x:1001:
...
root@kali:~# cat /etc/group | awk -F: '$3>=500 && $4==NULL {print $1}'
test1
test2
...

 

/etc/group의 구조에 대해서는 "U-50) 관리자 그룹에 최소한의 계정 포함"에서 자세히 설명드렸으니 참고하시구요. 이를 점검하는 방법은 의외로 간단합니다. /etc/group의 내용을 읽어와서 awk 명령어로 GID가 있는 세 번째 필드가 500이상이면서, 그룹에 할당된 계정이 표시되는 네 번째 필드가 공백(NULL)인 라인들을 필터링 합니다.

 

다른 언어들과 마찬가지로 awk 명령어에서 조건 여러 개를 사용하기 위해서는 '&&'를 붙여주면 됩니다. 그래서 이렇게 필터링 된 첫 번째 필드를 출력해서 계정을 할당하지 않는 그룹명을 알아낼 수 있습니다. 하지만 결과에서 보이는 것처럼 대부분 새로 생성된 계정의 그룹이 출력되기 때문에 이것이 가지는 의미가 있는지는 애매모호 하죠.

그리고 점검 가이드에서는 굉장히 아무 문제 없는 것처럼 나와있지만, 이 점검 항목은 조치 방법에서 굉장히 조심해야 하는데요. 임직원에게 부여되는 계정을 제외한다고 하더라도, 리눅스에 설치된 프로그램이 생성한 그룹에 계정이 할당되어 있지 않다고 바로 삭제하면 시스템 운영에 영향을 끼치는 경우가 있습니다.

 

특히 SSH 연결에서 키를 관리하는 ssh_keys를 지워버리면, 이와 동시에 서버에 다시 접속할 수 없게 되는 끔찍한 일이 발생할 수 있죠. 실제 고객사 인프라 진단 때도 인터뷰를 통해 그룹 관리에 문제가 없다고 하면, 웬만해서 양호하다고 판단하기 때문에 해당 항목은 신중하게 접근하셨으면 합니다. 그럼 이번 글은 이만 줄이도록 하죠. 읽어주셔서 감사합니다.