서버에서 소프트웨어를 실행하려면 언제 새 사용자 계정을 만들어야합니까?


14

일반적으로 서버에서 인터넷 연결 소프트웨어를 실행하기 위해 언제 새 사용자 계정을 만들어야합니까?

예를 들어, 공유 데비안 서버를 사용하고 있는데 (예 : Dreamhost를 통해) WordPress, Redmine, Ruby on Rails, Django를 사용하는 웹 사이트를 운영하고 싶다고 가정하고 Mercurial을 제공하고 싶다고 가정 해 봅시다. 리포지토리도.

Dreamhost 서버 및 이와 유사한 다른 많은 설정 서버에서 단일 사용자 계정 으로이 작업을 수행 할 수 있지만이 방법에 대한 몇 가지 단점이 있습니다.

  • 더 긴 .bashrc
  • 하나의 계정이 손상된 경우 해당 계정으로 실행중인 모든 사이트도 손상됩니다.

반면에 많은 사용자 계정이 있으면 특히 소프트웨어 설치 측면에서 동일한 요구 사항이있는 경우 추적하기가 다소 어려울 수 있습니다. 예를 들어, WordPress를 실행하는 각 웹 사이트에 대해 하나의 계정을 갖는 것은 과도 할 수 있습니다.

모범 사례는 무엇입니까? 사용자 계정 당 호스팅 된 사이트 (또는 호스팅 된 리포지토리 등)의 수를 편집증 수준에 비례하여 줄이는 문제일까요?

이에 대한 의견을 적어 의견을 보내주십시오.

또한 개인 서버 또는 VPS에 대한 접근 방식이 공유 서버에 대한 접근 방식과 달라야한다고 생각할만한 이유가있는 경우 해당 서버가 무엇인지, 그리고 그 이유를 설명하십시오.

답변:


11

저는 일반적으로 "네트워크에서 청취 소켓을 여는 모든 것에 대해 한 명의 사용자"-Apache, Mail, DNS 등의 팬입니다.

이것은 여전히 ​​최상의 현재 관행이며, 그 뒤에 이유는 명백하고 단순한 편집증입니다.이 서비스는 누군가가 취약점을 발견하고 악용하여 패치 할 기회를 갖기 전에 악의적 인 인터넷에 노출됩니다 최소한 하나의 사용자 계정으로 제한하고 있으며 단일 서비스를 실행하는 데 필요한 권한 만 가지고 있습니다.
각 응용 프로그램은 예를 들어 취약점 (의 섬이 비록 사람이 플러그인 취약한 워드 프레스 설치하는 경우 일반적으로 내가 분리의 수준을 고려 말하는 것은, 시스템을 보호하기에 충분합니다 모든 아파치 (즉, 모든 웹 사이트에 액세스 할 수있는 것들)을 효과적으로 취약를 타협의 경우.

따라서 자체 아파치 구성 및 사용자로 공유 호스팅 클라이언트의 웹 사이트를 샌드 박싱하기 위해 해당 인수의 확장 버전을 만들 수 있습니다 (각 사이트마다 전체 웹 스택을 설치할 필요는 없으며 다른 사용자를 지정하는 별도의 아파치 구성 만 필요) ), 각 사이트에서 많은 Apache 프로세스가 실행되고 있으므로 RAM 사용량이 크게 증가했으며 단일 Apache 인스턴스 / 사용자가 손상되면 세계적으로 읽을 수있는 항목이 여전히 취약합니다.

더 많은 보안을 위해 각 아파치를 chroot (또는 BSD 시스템의 경우 감옥)에 넣는 것에 대한 논쟁을 더 확장 할 수 있지만, 이제 각 chroot / jail에 필요한 모든 소프트웨어가 필요하기 때문에 추가 디스크 공간에 대해 이야기하고 있습니다. 포함 된 사이트를 실행하고 (패치가 나올 때 서버에서 하나의 마스터 사본이 아닌 모든 사이트에 대해이 소프트웨어를 업데이트해야 함) 별도의 사용자 / 아파치 인스턴스가있을 때와 같은 RAM 요구 사항을 실행합니다.
이것은 사용자가 chroot에서 벗어날 수있게하는 OS / Kernel 버그를 제외한 모든 것을 완화시킵니다 (이것은 별도의 물리적 서버에서 모든 사이트를 실행하기위한 인수가되고 사이트를 다른 VLAN / 서브넷 등으로 분리하는 인수가됩니다).


모든 위험과 마찬가지로이를 제거 할 수는 없습니다. 잠재적 피해 / 손상 비용, 타협 가능성 및 각 완화 수준의 비용을 기준으로 위험을 허용 가능한 수준으로 완화 할 수 있습니다.
돈을 위해, 중요하지 않은 전자 상거래가 아닌 공유 호스팅 환경의 기본 "아파치 사용자 한 명, DNS 사용자 한 명, 메일 한 명 등" 안전망으로 충분합니다. 해당 수준 이상의 보안이 필요한 경우 사용자는 자신의 하드웨어를 진지하게 고려해야합니다.


1
Apache가 들어오는 요청에 따라 동적으로 실행중인 사용자를 변경할 수있게 해주는 Apache (mod_su라고 생각합니까?) 모듈도 있습니다. 공유 호스팅 환경에서는 액세스중인 사이트를 소유 한 사용자로 변경하도록 설정했습니다. 이는 가장 일반적인 유형의 위반 (코드 삽입 등)을 구획화하여 나쁜 WordPress 플러그인을 설치 한 사용자 만 영향을받습니다. 또한 Apache 프로세스 자체의 완전한 위반과 권한 에스컬레이션 공격에 대한 보호 기능을 제공하지만 실제 목적은 아닙니다.
Kromey

@ Kromey, mod_su에 대한 많은 정보를 찾을 수 없습니다. mod_suexec 을 의미 합니까 ?
sampablokuper

1
@sampablokuper 네, 그 정보가 잘못되었습니다.
Kromey

1
@Kromey의 큰 문제 mod_suexec는 "비 CGI 요청은 여전히 ​​User 지시자에 지정된 사용자와 함께 처리된다"는 것입니다. 따라서 PHP가 모듈 인 경우 여전히 "주"아파치 사용자로 실행됩니다. 실행중인 모든 것이 CGI 인 경우 훌륭한 솔루션입니다.
voretaq7

@voretaq 아, 나는 그 한계를 몰랐습니다. 여전히 일부 환경에서는 유용 할 수 있지만 실제로는 생각했던 것보다 적용 성이 떨어집니다.
Kromey

6

일반적으로 로그인 할 수없는 외부 연결 서비스 사용자 (예 : "아무도 없음")와 로그인 및 su 또는 sudo가 허용되는 계정이 있습니다. 당연히 사용자 이름이 다르고 쉽게 추측 할 수 없는지 확인하십시오.

각 고객이 로그인 한 공유 호스팅 환경을 실행하지 않으면 서비스 당 한 명의 사용자가 필요하지 않습니다. 현실적으로 자신을 해킹의 매우 매력적인 대상으로 생각한다면 가능한 한 격리해야 할 것입니다. 그러나 매우 논란의 여지가 있거나 재무 데이터를 호스팅하지 않는 한 실제로 목표의 매력은 아닙니다.


+1 분리 수준은 당면한 상황에 적합해야하며 일반적으로 "매우 논란이 많은"또는 "재무 데이터"에 도달하면 나만의 기계 분리 수준 을 원할 것입니다. :-)
voretaq7
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.