[보안] 허용된 호스트만 접근 허용, 접근제어솔루션 우회불가 확인 방법 (DBSafer, Hiware 등의 IT Supporting Tools 설정 확인)

많은 회사들이 OS, DB 등에 접근하기 위하여 별도로 접근제어솔루션을 도입하여 사용하고 있습니다.

그럴 경우에 생각할 수 있는 위험은,
회사의 중요 OS, DB에 접근할 때, 접근제어솔루션을 우회하여 직접 OS, DB에 접속할 위험입니다.

일반적으로 OS, DB에 접근할 때 접근 절차는 아래의 설명과 그림을 참고하시면 됩니다.
>> 사용자 PC 로그인(예 - AD 인증 등) -> 접근제어솔루션(예 - Hiware, DBSafer, ChakraMax, Petra 등) -> 접속할 OS/DB 선택 -> 접속할 계정 선택 후 패스워드 입력(회사별로 상이) -> 접근 성공

DBSafer 접근제어솔루션 예시

업무를 하다가 'OS, DB의 접근제어솔루션을 우회하여 접근할 수 없다.'라는 확신을 얻기 위해서 어떻게 이를 확인할 수 있을지에 대해 이것 저것 알아보면서 발견한 사항들을 적어볼까 합니다. (참고만 해주세요.. 정확하지 않을 수 있습니다. 더 자세히 아신다면 댓글 달아주세요!)

[확인 방법]
1. 직접 테스트(Direct Test) [OS, DB]
직접 OS, DB로 접근을 시도하여 접근이 되지 않음을 step by step으로 확인.

2. 대상 OS의 /etc/hosts.allow, /etc/hosts.deny 확인 [OS, DB]
리눅스에서 TCP Wrapper(네트워크 서비스에 관련한 트래픽을 제어하고 모니터링 할 수 있는 UNIX 기반의 방화벽 툴) 기능을 사용하면 간단하게 FTP, Telnet, SSH 및 xinetd 기반의 서비스에 대해 접근제어(Access Control List) 설정이 가능한데, 이는 최근 버전의 리눅스에서는 별도로 설치할 필요가 없습니다. 그렇기 때문에 바로 /etc/hosts.allow, /etc/hosts.deny 파일의 설정을 통하여 특정 IP 또는 IP대역에 대하여 접근제어를 허가, 거부 할 수 있습니다.
검토 대상의 OS에 접근하여 접근제어솔루션의 IP주소 및 포트만이 허용이 되었으며(/etc/hosts.allow), 이 외의 IP주소 및 포트는 차단하고있는지(/etc/hosts.deny - 대부분 ALL:ALL 로 모든 것을 차단.) 확인을 합니다. 이는 보안 취약점 진단시 확인하는 항목으로도 설정이 되어있습니다.
-> DB의 경우에도 직접 접속시에 DB가 구동되는 OS를 통하여 DB에 붙는 경우도 존재하기 때문에, 마찬가지로 DB가 설치된 OS에서 동일하게 확인할 수 있을 것으로 생각됩니다.

3. 방화벽 정책 혹은 접근제어솔루션의 접근정책 확인 [OS, DB]
"제한된 사용자 -> 접근제어솔루션" & "접근제어솔루션 -> OS/DB" - Allow, 나머지 Deny all 되어있는 정책을 확인한다면,
(1) "제한된 사용자"로 직접 "OS/DB"로 접근이 불가하게 설정되어있음. Allow
(2) "제한된 사용자"가 아닌 사용자로 "접근제어솔루션" 및 "OS/DB"로 접근이 불가하게 설정되어있음. Deny all
을 나름 확신할 수 있습니다.
즉, 모든 "OS/DB"로의 접근은 "제한된 사용자가" "접근제어솔루션"을 통하여야만 접근이 가능함을 증명하는 것이기 때문에 우회가 불가능하다는 증빙 중에 하나로 사용이 가능할 것이라고 생각됩니다.
또한, 일부 접근제어솔루션(DBSafer 등)에서는 접근제어정책이라는 기능을 지원하여, 자체적으로 IP 제한을 할 수 있으니 해당 정책을 검토하는 것도 하나의 방법이 될 수 있을 것이라고 생각됩니다. 이는 해당 솔루션이 Gateway, Server Agent 등으로 구성이 되어 운영되고 있기 때문에 자체적으로 해당 기능이 지원되는 것으로 보입니다만, 자세한건 잘 모르겠습니다.. ㅎㅎ

4. 서버간 원격접속 차단 [OS]
사용자가 직접 OS에 붙는 것도 우회의 방법이지만, 추가적으로 OS의 원격접속을 사용하는 것도 하나의 우회방법이 될 수 있을 것입니다. ( os to os ) 원격 접속 프로토콜으로는 대표적으로 Rlogin, Telnet(암호화X), ssh(암호화O) 등이 존재합니다. (접근제어 툴 상에서 ssh, telnet 등의 포트들이 관리가 되게 설정이 되어있다면 괜찮을 것 같습니다.)
또한, 원격으로 접근하여 root의 계정을 사용할 수 있게 설정이 되어있다면 책임 추적이 불가한 비인가자에 의하여 super user권한인 root계정이 탈취되어 시스템 장악 및 각종 공격을 받을 위혐이 있습니다.
<확인사항>
1) OS에 접속하여 rlogin(remote login) 설정이 'False'로 되어있어 원격으로 로그인이 불가함을 확인.
만약 'True'로 설정이 되어있다면 /etc/hosts.equiv 및 .rhosts 파일을 확인하여 어떠한 호스트, IP주소, 계정아이디로 접근이 가능한지 확인. (원격 접속은 허용되지 않도록 기본적으로 권고됨. 감사 관점일 경우 문제가 될 확률이 높음.)
2) PermitRootLogin이 No 로 설정되어있음을 확인. Linux의 경우, PAM 설정(/etc/pam.d/login)도 확인. (원격 접속 시 root로 직접 접속 허용여부)
3) /etc/securetty에서 pts(telnet, ssh, 터미널 등 이용하여 접속) 존재 유무 확인.
4) OS 접근제어솔루션 사용 시, 대부분은 명령어 차단 기능을 사용함. 접근제어솔루션 내 기능으로 ssh, telnet, 기타 포트 등의 차단 여부 확인.
등이 존재할 것 같습니다.
정확한 내용까지는 보안 전문인이 아니라서 자세히는 모르고, 회사에서 접근제어솔루션의 우회를 통제하고 있는지 확인하는 방법만 얕은 지식으로 알아보고 테스트를 하였기에... 더 자세히 아시거나 정정할 내용이 있다면 댓글로 남겨주세요.. ㅎㅎ



제가 감사를 수행할 때는 방법을 찾아보다가 위의 방법들을 찾아내어 테스트를 수행하였는데,
추가적으로 더 정확한 방법이 존재한다면 언제든 알려주시면 감사하겠습니다.
저도 추가적으로 확인되는 부분이 있다면 작성하도록 하겠습니다!


참고 : https://se.uzoogom.com/125, https://min-zero.tistory.com/entry/KITRI-Day14-Telnet-SSH-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0