NIS의 잠재적 인 보안 문제입니까, 아니면 오해입니까?


0

조직의 NIS 서버와 통신 할 수있는 가상 컴퓨터에서 작업하고 있습니다. 나는 그것에 대한 많은 경험이 없지만, 나는 나의 호스트로부터 다른 사용자가 될 수 있다는 것을 알아 차렸다. NIS 서버의 루트 암호없이 . 사실, 아래 프롬프트는 암호를 묻지 않습니다. 그 행동은 조금 이상합니다. 누군가는 왜 그것이 작동하지 않는지 설명 할 수 있습니다. sudo 비록 내가 뿌리인데.

[root@unsecurehost ~]# su - myusername
su: user myusername does not exist

[root@unsecurehost ~]# sudo su - myusername
Last login: Mon Feb 12 19:24:17 UTC 2018 on pts/0
Last failed login: Mon Feb 12 19:28:13 UTC 2018 on pts/0
There were 2 failed login attempts since the last successful login.
su: warning: cannot change directory to /network/path/home/myusername: No such file or directory
-bash-4.2$ id
uid=012345(myusername) gid=0123(companyname) groups=0123(companyname),9999(othergroupname) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

나의 uid, gid, 및 groups 맞다.

일반적으로 나는 이것을 non-issue로 생각할 것이다. 그러나 접근하려고 시도한다. /network/path/home/myusername, 내 (네트워크) 홈 디렉토리입니다. 이 스토리지를 마운트하지 않았지만이 호스트에서 그렇게 할 수 있습니다.

나는 yp.conf 파일은 컴퓨터의 모든 사용자가 읽을 수 있으며 ypbind.

이것을 악용 할 수 있습니까? 일부 사용자는 여기에 민감한 정보가 있습니다. 다른 사용자가되어 파일에 액세스 할 수있는 경우 이는 보안상의 결함입니다. 나는 이것이 불가능하다고 믿고 싶기 때문에 실제 상황에서 이것을 시도하지 않았다. (아마도 네트워크 스토리지가이를 허용하지 않거나 "컨텍스트"필드가 중요하다.). 이것은 지금 큰 문제는 아니지만 우리는 잠재적으로 사용자를 루트로 허용 할 수있는 사용자 관리자를 허용하는 가상 시스템에 대해 작업하고 있습니다.

저에게 무슨 일이 일어나는지 알려주세요.


"하지만 NIS 서버에 루트 암호가 없으면 내 호스트에서 다른 사용자가 될 수 있음을 알았습니다." -이 구성에 대해서는 이상한 것이 없습니다. 단지 사용자를 의미하며 sudo 그룹에 속해 있으며 해당 권한이 부여되었습니다. 루트로 명령을 실행했기 때문에 어떤 의미가 있습니다. 당신이 ssh 연결을 통해 루트로 연결되어 있지 않다면, 사용자를위한 암호를 물어 보지 않았다는 사실에 관해서는, 나는 당신이 ssh 세션에 연결할 때 이미 그 사용자에 대한 인증을했다고 의심합니다.
Ramhound

답변:


0

당신이 시연 한 것은 문제가 아닙니다.

NIS에서 "액세스 토큰"을 얻지 못했습니다. 얻은 유일한 정보는 같은 들판 에 존재하는 /etc/passwd - UID, GID, 로그인 쉘, 홈 디렉토리 - 당신이 한 유일한 일은 OS에 UID를 012345로 설정하라는 것입니다.

동일한 UID로 로컬 계정을 만듦으로써 NIS가 없어도 쉽게 동일한 작업을 수행 할 수 있습니다.

그러나 이것이 반드시 네트워크의 다른 컴퓨터에 대한 액세스를 허용하지는 않습니다. 귀하의 UID가 다른 시스템을 인증하기에 충분하지 않다는 것을 아는 것만으로는 알 수 없습니다. 어디에 홈 디렉토리가 당신이 그것을 액세스 할 수 있다는 것을 의미하지는 않습니다.

즉, 하나의 큰 예외가 있습니다 : NFS.

너 뭐야? 하지 않았다 실증이 실제 문제 일 수 있습니다.

아마도 네트워크로 연결된 저장소는 이것을 허용하지 않을 것입니다.

여기서 가장 중요한 질문입니다. 네트워크로 연결된 스토리지에 액세스하는 데 사용되는 프로토콜과 스토리지 서버 구성 방법에 따라 다릅니다.

대부분 (최신) 네트워크 프로토콜은 항상 클라이언트의 인증을 요구합니다. 예를 들어 스토리지 서버에 암호, 인증서 또는 Kerberos 티켓이 필요할 수 있습니다. 이러한 정보는 NIS를 통해 얻을 수 없습니다.

하나, NFS (auth = sys)는 예외입니다. 실제로 클라이언트가 보낸 UID를 맹목적으로 신뢰합니다. 클라이언트가 UID 12345를 대신하여 요청을 보내고 있다고 말하면 UID 12345가 소유 한 파일에 아무런 문제없이 액세스 할 수 있습니다.

따라서 네트워크 스토리지를 마운트하는 데 사용하는 방법을 자세히 살펴보십시오. auth = specification없이 NFS라면 파일 서버가 활짝 열려 있습니다. NIS의 잘못이 아닙니다.


또 다른 예외는 rsh & amp; rcp는 클라이언트가 보낸 사용자 이름도 신뢰하지만 희망을 갖고 아무도 그 프로토콜을 더 이상 사용하지 않습니다. 그 사이에, auth = sys를 가진 NFS는 아직도 아주 대중적이다.


설명해 주셔서 감사합니다! 필자는 조직의 시스템 관리자에게 물었고 NFS (신뢰할 수있는 호스트, Kerberos 및 기타 IP 범위로 제한된)의 안전하지 않은 특성을 완화하기위한 몇 가지 조치를 취했습니다.
skyrocket

Kerberos가 좋습니다.
grawity

0

NIS는 모든 참가 시스템이 신뢰할 수 있다는 전제하에 존재합니다. 즉, 시스템 관리자는 sudo su 그가 무엇을하고 있는지 알았습니다.

악의적 인 관리 사용자에 대해 (모든 시스템에서와 마찬가지로) 보호 기능이 없습니다.


흠, 재미 있네. 나는 그것이 사실일지도 모른다라고 생각했다. 그러나 그것은 매우 어리 석다. 연결에 사용한 정보 (NIS 서버 IP 주소 만)는 공개적으로 사용할 수 있습니다. 즉, 네트워크 연결이있는 건물의 모든 사용자가 이론적으로 다른 사용자가 될 수 있습니다.
skyrocket
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.