질문이 명확하지 않고 너무 광범위할 수 있지만, 짧거나 광범위하더라도 어떤 답변이라도 매우 감사하게 생각합니다.
얼마 전 저는 프로덕션 서버에 zsh를 설치해 달라고 요청했습니다. 내 관리자 회사는 개발 서버가 아닌 프로덕션이므로 수행할 수 없다고 대답했습니다.
저는 지난 5년 동안 zsh와 oh-my-zsh를 사용해왔고 zsh에 매우 애착을 갖고 있습니다. zsh를 사용하면 작업이 더 쉽고 빨라집니다. 그러나 그것만으로는 충분한 주장이 아니었습니다.
저는 여기에 관련된 보안이나 기타 문제에 대해 강한 지식을 갖고 있지 않습니다. 그래서 제 질문은 다음과 같습니다.
- 프로덕션 서버에 zsh를 설치하면 시스템에 무해합니까?
- 이 경우 zsh 설치를 허용하시겠습니까? 그 이유는 무엇입니까?
- 프로덕션 서버에서 bash를 사용하여 사용자를 제한하는 것이 합리적입니까?
답변1
zsh단지 쉘일 뿐이며 어떤 서비스도 시작하지 않으며 setuid 명령도 함께 제공되지 않습니다. 따라서 단순히 패키지를 설치하는 것만으로는 누군가 또는 무언가가 실제로 패키지를 사용할 때까지 아무 것도 할 수 없습니다. 어떤 권한도 필요하지 않기 때문에 모든 사용자는 자신의 홈 디렉터리나 액세스할 수 있는 모든 곳에 직접 설치할 수 있습니다.
그렇지 않았다면생산 품질, admin 사용자의 로그인 셸로 만들면 약간의 위험이 발생할 수 있다고 주장할 수 있지만 bashor 와 같은 다른 셸보다 훨씬 더 건전한 구문을 사용하면 tcsh문제가 상당히 개선될 것이라고 주장합니다.
주요 사용법은 대화형 셸이지만, 스크립트를 작성하는 것이 스크립트 zsh보다 더 안전하고 신뢰할 수 있는 스크립트를 만들 수 있다고 주장하고 싶습니다. 변수를 인용하는 것을 잊어버렸을 때 자신도 모르게 구문 으로 스크립트를 작성하는 사람이 얼마나 많은지, Shebang을 변경하는 방법을 확인하세요. from to는 스크립트의 많은 버그를 수정합니다).bashbashzsh#! /bin/bash#! /bin/zsh -
어쨌든 설치는 zsh제가 일했던 모든 장소의 모든 서버 배포에 대해 제가 가장 먼저 수행한 작업 중 하나입니다.
그러나 일부 소프트웨어에서는 bash 중심 환경을 기대하는 것이 드문 일이 아니기 때문에 일반적으로 기본적으로 모든 사용자의 로그인 셸로 만들지 않습니다.
답변2
다른 사람들과 마찬가지로 내 의견은 다음과 같습니다.
- 프로덕션 서버에 zsh를 설치하면 시스템에 무해합니까?
'무해하다'라고 정의하세요. 엄밀히 말하면 직접적인 피해는 없습니다. 그러나 프로덕션 시스템에 있는 모든 코드는 잠재적인 공격 벡터입니다. 그런 의미에서 그것은 실제로 '무해한' 것은 아닙니다.~할 수 있었다시스템 공격에 사용됩니다. 간접적으로 문제를 일으킬 수 있는 다른 방법도 있습니다. 예를 들어 ZSH는 bash보다 리소스를 더 많이 소모하므로 용량에 가깝게 실행되는 시스템에서 문제가 될 수 있습니다.
- 이 경우 zsh 설치를 허용하시겠습니까? 그 이유는 무엇입니까?
정확한 상황에 따라 이미 설치되어 있을 수도 있습니다.
내 모든 개인 시스템에는 ZSH가 설치되어 있으며 루트를 포함한 모든 사람의 기본 셸로 설정되어 있습니다. 이는 제가 이러한 시스템의 로컬 셸에서 정기적으로 작업하고 있고 많은 경우 ZSH를 적극적으로 사용하기 때문입니다.
하지만 제가 직장에서 관리하는 모든 시스템에는 이 프로그램이 설치되어 있지 않습니다. 제가 수행하는 관리 작업 중 약 95%는 실제로 이러한 시스템의 쉘을 건드리지 않습니다.많은직장에서 Ansible을 통해) 친숙한 환경으로 만들 필요가 없습니다. 또한 실제 개발 시스템이 아닌 다른 시스템에는 설치할 가능성이 거의 없으며, 오프사이트에서 직접 액세스할 수 있는 시스템에는 설치할 가능성도 없습니다.
- 프로덕션 서버에서 bash를 사용하여 사용자를 제한하는 것이 합리적입니까?
실제 쉘 액세스를 포함하지 않는 매우 제한적인 특정 사례를 넘어 일반 사용자가 프로덕션 시스템을 전혀 만지지 못하게 하는 실용성에 의문이 듭니다.
예를 들어, 제가 일하는 곳에서는 IT 부서와 웹사이트 유지 관리를 직접 담당하는 사람들만이 웹 서버에 대한 일반적인 HTTPS 액세스 권한을 갖고 있지 않습니다. IT 담당자(저 포함)는 웹 서버 관리에만 사용되는 특수 계정으로 로그인해야 하며, 심지어 서버실의 물리적 콘솔에 앉아 있지 않는 한 시스템에 대한 액세스가 제한됩니다. 웹 디자이너는 웹사이트 루트에만 SFTP 액세스 권한을 갖고 있습니다.아무것도 아님또 다른. 이를 감안할 때 bash(관리용 내부 표준)를 제외한 쉘은 필요하지 않습니다.
마찬가지로 내부 파일 서버의 경우 IT 부서만 실제 셸 액세스 권한을 갖습니다. 다른 사용자는 특정 디렉터리에 대해 특별히 제한된 액세스 권한을 가지며 일반적으로 일반 파일 서버 프로토콜(SMB, NFS 등)과 SFTP 및 경우에 따라 rsync를 허용하지만 실제로는 필요하지 않기 때문에 이들 중 누구도 실제 셸 액세스 권한을 갖지 않습니다. 그것.
답변3
내 경험에 따르면 프로덕션 서버에 zsh를 설치하는 것은 일반적이지 않습니다. 즉, 저는 '보수적인' 고객(은행, 행정부 등)과 가장 많이 협력하므로 귀하의 마일리지가 다를 수 있습니다.
Zsh 자체는해가없는. bash, ksh 등과 같은 '그저 또 하나의 셸'입니다. 그러나 많은 기업의 보안 정책은 다음과 같습니다.공격 표면을 최대한 제한즉, 필요한 경우가 아니면 아무것도 설치하지 마세요. zsh가 무해하더라도코드 베이스에 버그가 있을 수 있습니다.. 에 대해 읽다쉘쇼크당신이 그것에 대해 아직 모른다면. :)
즉, vi 대신 vim을 갖는 것과 같은 '상품'에 대해서는 특정 관대함이 있습니다. Zsh가 이 범주에 속할 수 있습니다.생산되지 않음, 일어나지 않습니다. 공격 표면을 줄이는 것 외에도 스크립트를 두 번 테스트해야 한다는 사실도 있습니다. 한 번은 zsh로, 한 번은 bash로 테스트해야 합니다. 시간과 돈이 필요합니다.
나는 그것을 bash로 제한한다고 부르지 않을 것입니다.bash로는 할 수 없지만 zsh로 할 수 있는 일이 있나요?
최종 참고사항:bash는 거의 업계 표준입니다. 이는 대부분의 엔터프라이즈급 배포판(RHEL, SUSE 등)뿐만 아니라 Debia, Ubuntun과 같은 널리 사용되는 배포판의 기본 셸입니다.
저는 수년에 걸쳐 "새로운" 셸을 사용해 보았습니다. zsh와 fish는 내가 정말 좋아했던 두 가지. 그러나 가정용으로는 직장에서는 bash를 사용합니다(AIX 등으로 작업할 때는 ksh). 결국 집에서도 bash를 사용하게 되었고, 오래된 습관은 쉽게 사라지지 않습니다.
답변4
다른 의견도 있지만 여기 내 의견이 있습니다.
- 프로덕션 서버에 zsh를 설치하면 시스템에 무해합니까?
새로운 소프트웨어를 도입하는 것이 무해한 경우는 거의 없습니다. 예를 들어, 이와 관련된 모든 취약점을 식별하고 패치해야 합니다.
- 이 경우 zsh 설치를 허용하시겠습니까? 그 이유는 무엇입니까?
아니요. 실질적인 이점이 확인되기를 원합니다.
- 프로덕션 서버에서 bash를 사용하여 사용자를 제한하는 것이 합리적입니까?
예, bash훌륭합니다 :-) 그리고 회사의 일부 틈새 사용자 그룹이 zsh광범위한 지원 팀에 대한 지식 없이 스크립트를 작성하기 시작하면 그들은 당황하게 됩니다.