U-47) 패스워드 최대 사용기간 설정

 

 

지난 글인 "U-46) 패스워드 최소 길이 설정"에 이어서 이번에는 "패스워드 최대 사용기간 설정" 점검 항목에 대해 설명하도록 하겠습니다. 이번 항목도 점검 방법이나 조치 방법이 저번 항목과 굉장히 비슷하기 때문에 언급하는 내용들이 크게 다르진 않겠지만, 패스워드 최대 사용기간을 왜 설정해야 하는지와 ISMS 심사에서 해당 항목의 판단 기준이 맞지 않는다면 정말로 결함을 주는지 등 실제 컨설팅 사례에 대해서도 말씀드려보겠습니다. 그럼 우선 취약점 개요에 대해 간단히 정리하고 넘어가보도록 하죠.

 

 

이번 점검 항목의 핵심은 패스워드 최대 사용기간이 설정되어 있는지의 여부입니다. 앞에서 패스워드 복잡성 설정이나 계정 잠금 임계값 설정을 통해서 어느 정도 무작위 대입을 방지할 수 있다고 말씀드렸었죠. 그런데 패스워드 복잡성이 설정되고 계정 잠금 임계값 설정이 된 경우라고 하더라도, 해커가 오랜 시간을 들여서 원래의 패스워드를 알아낼 경우도 존재할 겁니다. 예를 들면, PAM 모듈에서 5회 입력 실패 시 계정에 락(lock)이 걸리고 120초 후에 잠금이 해제가 되도록 설정했다면, 무작위 대입 공격을 5회 시도 후 2분 뒤 다시 5회 시도.. 이런식으로 인터벌로 공격을 할 수 있겠죠. 물론 계정 관리자가 로그인 실패 로그를 자주 확인하거나 보안 솔루션이 미리 탐지해준다면 그 전에 막히겠지만 생각보다 많은 기업들에서 보안이 그렇게 잘 되어 있는 경우는 드물다고 말씀드렸죠.

​

위와 같은 이유로 패스워드 최대 사용기간을 설정하여 일정 주기마다 패스워드를 변경하도록 하면, 무작위 대입 공격에 더 안전하다라고 판단해서 해당 점검 항목을 추가한 것으로 생각됩니다. 그런데 사실 이 항목은 리눅스 서버 뿐만 아니라 네이버나 다음 같은 일반적인 웹 사이트에서 적용되는 항목이죠. 물론 대부분의 사용자들이 패스워드를 바꾸는 것을 귀찮아서 다음에 변경하기를 누르고 있기도 하고, "U-02) 패스워드 복잡성 설정"에서 설명드렸던 것처럼 미국의 NIST에서 연구한 내용에서는 패스워드를 자주 바꾸는 것이 더 문제가 된다고 이야기하는 것으로 보아 아마 추후에는 이와 같은 정책이 또 바뀌지 않을까라는 생각도 듭니다.

 

root@kali~# cat /etc/login.defs | grep "PASS_MAX_DAYS" | awk '$2<=90' | wc -l
1

 

지난 글을 보신 분들은 해당 항목의 점검 방법이 grep 명령어로 필터링하는 "PASS_MAX_DAYS"라는 문자열과 awk 명령어로 값이 90 이하인지 확인하는 것만 달라졌을 뿐이라고 느끼셨을텐데요. 대부분의 항목들이 점검 방법과 조치하는 방법 또한 같기에 자세한 설명은 생략하도록 하겠습니다. 다만 패스워드 최대 사용기간을 설정하는 방법이 login.defs 파일을 수정하는 것 외에도 chage 명령어를 통해 사용자 계정 별로 최대 사용기간을 설정할 수 있다는 것도 알아두셨으면 합니다.

 

패스워드 최대 사용기간을 login.defs 파일에서 직접 수정하면 이후에 생성되는 계정에만 적용되는데, 그 이전의 계정에 대해서는 "chage -M 90 test"로 명령어를 통해 사용기간을 변경할 수 있습니다. 또한 이는 /etc/shadow 파일의 5번째 필드에 적용되므로, 궁금하신 분들은 구글링을 통해 해당 파일의 구조를 알아보시는 것도 도움이 되시리라 생각합니다.

그리고 한 가지 더 말씀드리면 주통기 점검 가이드에서는 해당 항목의 양호, 취약 판단 기준을 90일 이하로 설정하라고 되어 있긴 하지만, 어디까지나 가이드에 나온 권고 사항일 뿐이기도 하고 ISMS 심사를 하는 분들마다 조금씩패스워드 최대 사용기간이 아예 설정되지 않은 경우만 아니라면 ISMS 심사에서 웬만해서는 결함으로 보진 않습니다. ISMS 인증 심사 기준을 보면 패스워드 변경주기가 반기별 1회 이상이기도 하고, 기업의 정보보안 규정에 따라 패스워드 최대 사용기간이 90일 보다 길 수도 있고 반대로 90일 보다 짧을 수도 있는거죠.

그렇기 때문에 추후 컨설팅에서 인프라 진단을 하시다가 이와 같은 항목을 점검하실 때 꼭 90일이 이하가 아니여서 취약하다고 점검결과를 작성하시기 보다는, 가이드에 90일 이하로 설정하는 것을 권장하고 있기 때문에 전사 보안 규정을 따르는 것이 아니라면 이렇게 바꾸는 것을 권고한다고 담당자에게 이야기하는 것도 나쁘지 않다고 생각합니다. 실제 컨설팅에서 인프라 진단 후 리뷰를 진행하면서 담당자와 이런 문제로 언쟁을 하기도 해서, 왜 이렇게 조치해야 하는지 담당자를 이해시키는 것도 컨설팅의 중요한 일이기 때문에 조심스레 말씀드렸습니다. 그럼 오늘은 여기서 마무리하고 다음 글에서 뵙도록 하겠습니다. 감사합니다.