Sun Microsystems사의 NFS/NIS

목차

1.Sun Microsystems사의 NFS/NIS

2.관련 시스템 파일들

3.관련 명령어들과 데몬 프로세스

4.NFS 서버 설치

5.NFS 서버 설치와 관련된 파일과 명령어들

6.Manual export

7.NFS 클라이언트 설치

8.NFS 클라이언트 설치와 관련된 파일과 명령어들

9.에러 메시지와 이에 대한 대응 방법

10.NFS 보안

11./etc/exports 파일

12.rpc.mountd 데몬

본문내용

iris라는 호스트에만 주고 있음을 알 수 있다. 이것은 만약 이 2개의 호스트가 아닌 다른 호스트에서 침입자가 루트 권한을 얻더라도 isis가 export한 파일 시스템에서는 루트 권한을 행사할 수 없음을 나타낸다. 즉 침입자가 2개 호스트가 아닌 다른 호스트의 루트로써 isis가 export한 파일 시스템에서 write 또는 read 작업을 행하게 되면 이는 isis에서는 nobody(정의되지 않은 사용자)로 인식하게 된다.
· 가능하면 export할 파일시스템을 제약하라.
불필요한 파일 시스템을 export하는 것을 제한하고 클라이언트가 서버의 파일 시스템에서 read 작업만을 요구하는 경우라면 반드시 read only로 export해주는 것이 올바르다. Read only로 export해주는 예는 다음과 같다.
plus% cat /etc/exports
/usr -access=isis:osiris
/home -access=isis:osiris,root=isis:osiris
/usr2 -ro,access=isis
이 예에서는 NFS 서버가 자신의 /usr2라는 파일 시스템을 read only로 export하고 있으며 오직 isis만이 이 파일 시스템을 access할 수 있도록 허가해 주고 있다. 여기서 만일 `/usr2 -ro\' 라고 만 되어 있으면 이 경우에는 /usr2를 read only로 모든 호스트에게 export시켜준다는 것을 의미하게 되는데, 비록 클라이언트가 마운트 하여서 쓰지는(write) 못하더라도 내용을 읽을(read) 수는 있기 때문에 보안상의 문제를 야기할 수 있다. 그러므로 반드시 -access 옵션을 첨가해주는 것을 잊지 말아야 한다.
· NFS의 버그 중에서 /etc/exports에서 주어지는 옵션이 256자를 넘는 경우에는 옵션이 주어지지 않은 것과 마찬가지가 되어 어느 호스트에서나 접근이 가능하게 되는 것이 있다. 옵션이 256자를 넘어서는 경우로는 처음에 export해주기 시작할 당시에는 소수의 몇몇 호스트들에만 접근허가를 해주다가 나중에 클라이언트들이 늘어나게 됨에 따라서 이러한 한계를 넘어서 버리는 경우를 들 수 있다. 접근허가를 주어야 할 호스트가 많아지면, netgroup을 사용함으로써 옵션의 길이를 줄여야 한다.
Figure: rpc.mountd에 의한 hacking mechanism
rpc.mountd 데몬
NFS 서버의 서비스는 rpc.mountd와 nfsd라는 2개의 데몬에 의하여 이루어지게 된다. 여기서 nfsd 데몬은 클라이언트 파일 시스템의 요청(requests)을 처리하게 되며 rpc.mountd 데몬은 클라이언트의 파일 시스템 마운트 요청(file system mount requests)과 경로 번역(pathname translation)처리를 주목적으로 하고 있다. 이 데몬들의 자세한 메커니즘은 복잡하기 때문에 이 정도에서 접어두기로 하자.
여기서 문제가 되는 것은 바로 rpc.mountd이다. 일반적으로 SunOS를 설치하여 NFS를 이용하는 대부분의 호스트들은 이 데몬에 -n 옵션을 붙이고서 동작하고 있다. HP-UX를 제외한 대부분의 운영체제에서 이 옵션의 의미는 허가되지 않은 마운트 요청을 허락하겠다는 의미가 된다. 즉, 쉽게 이야기하면 클라이언트의 요청이 루트 사용자의 것이 아니더라도 서비스를 해주겠다는 의미이다. 이는 하나의 보안의 구멍을 제공할 수가 있다.
모든 NFS의 동작은 파일이나 디렉토리를 지정하는 파일 handle들을 이용하여 이루어지게 되는데, 이 파일 handle들은 허가 받은 클라이언트가 서버와의 동작을 위하여 알고 있는 것이다. 그런데 허가 받지 않은 클라이언트가 이 파일 handle들의 값을 알고 있다면 어떻게 될까? 당연히 허가 받지 않은 클라이언트도 서버에게 NFS 서비스를 받을 수 있게 된다. 쉽게 비유하면 허락 받은 사람(exported hosts)에게만 주는 열쇠가 있는데 이 열쇠를 허가 받지 않은 사람이 하나 복사해서 가지고 있으면 이 사람도 당연히 집에 들어갈 수가 있는 것과 같은 이치이다. rpc.mountd에서 -n 옵션은 허가 받지 않은 사람에게도 열쇠를 하나 줄 수 있도록 하는 것이다.
이 버그를 이용한 해킹 시나리오의 조건은 다음과 같다.
· rpc.mountd에 -n 옵션이 붙어 있다.
· 침입자는 NFS의 클라이언트에 일반 사용자의 계정을 가지고 있다.
· 침입자는 자신이 루트가 될 수 있는 다른 호스트를 가지고 있다.
· NFS 서버로부터 파일 handle들을 얻을 수 있는 간단한 프로그램을 가지고 있다(이는 물론 해커라면 쉽게 만들 수 있다).
· 파일 handle들에 의하여 NFS 서버에 마운트 시킬 수 있는 프로그램을 가지고 있다(이 또한 쉽게 만들어질 수 있다).
이제 이 시나리오대로 해킹을 진행시켜보자.
· NFS 클라이언트의 일반 사용자의 계정으로 login을 한다.
· 해킹 프로그램을 이용하여 파일 handle들을 얻어낸다.
· 자신이 루트가 될 수 있는 호스트로 login한다.
· NFS 서버로 마운트를 할 수 있는 간단한 프로그램에 의하여 마운트를 수행한다.
이 버그를 이용한 해킹의 메커니즘은 위의 그림과 같다.
이 해킹은 결국 클라이언트의 루트가 아닌 사용자가 NFS 서버로부터 파일 handle들을 넘겨받을 수 있게 해주는 rpc.mountd -n에 의하여 이루어지게 되는데 이 버그의 문제점은 서버에서 침입자가 몰래 수행한 마운트를 추적하기가 곤란하다는 것이다. 일반적으로 showmount -a 명령에 의하여 서버에서는 자기 자신에게 마운트를 수행한 클라이언트들을 알아낼 수가 있는데 이런 방법에 의한 마운트는 이 명령의 결과에도 나타나지 않는다는 사실이다.
그러면 SUN에서 왜 대부분의 rpc.mountd에 이 옵션이 붙어 있는 것일까? 이유는 SunOS의 옛 버전(pre-3.0)을 사용하고 있는 호스트에게도 NFS 클라이언트가 될 수 있도록 하기 위해서이다. 그러므로 NFS를 이용하는 클라이언트들 중에 옛 버전의 SunOS를 사용하고 있는 호스트가 없다면 반드시 이 옵션을 제거해주어야 한다.

키워드

Sun Microsystems,   NFS,   INS,   파일,   명령어