프로덕션 서버가 설치해도 안전합니까?


42

가상 서버 인스턴스를 설정하는 동안 일부 응용 프로그램을 사용하여 빌드해야합니다 make. make설치 와 관련된 보안 위험이 있습니까? 아니면 인스턴스를 배포하기 전에 정리해야합니까?

또한 gcc배포하기 전에 응용 프로그램을 작성하는 데 사용하는 서버에 컴파일러가 있습니다.


4
당신이 더 나은 느낌 경우, 어떤 소프트웨어의 조각이 설치된 어디서나 취약점을 만듭니다.
MDMoore313

1
서버에 루트가 아닌 쉘 액세스 권한을 가진 사용자는 "distro 독립형"컴파일러 패키지 (.tar.gz)를 다운로드 할 필요가 없습니다.

1
나인가요, 아니면 "안전한가요?" "루트 액세스"가 다소 불편한 가요?
DNA

2
gcc가 이미 설치되어 있다면 잠재적으로 보안 문제를 악화시킬 수있는 방법이 없습니다.
Shadur

1
@Shadur GCC와의 차이점은 무엇입니까? 사용자가 이미 머신에 액세스 할 수 있으면 gcc 사본을 간단하게 업로드 할 수 있습니다. 어쨌든 gcc는 권한이없는 사용자에게 권한이있는 사용자가없는 한 권한이없는 사용자에게 유용 할 수 있으며 보안 위험이 없습니다.
Vality

답변:


50

일부 사람들은 프로덕션 시스템에 개발 도구가 있으면 공격자가 더 쉽게 생활 할 수 있다고 주장합니다. 그러나 이것은 공격자에게 아주 작은로드 범프입니다. 개발 도구 설치에 대해 찾거나 반대 할 수있는 다른 주장은 더 무겁습니다.

공격자가 지금까지 시스템에 침투하여 서버에있는 도구를 호출 할 수 있다면 이미 심각한 보안 위반이 발생한 것입니다. 개발 도구가 없으면 이진 데이터를 파일에 쓴 다음 해당 파일에서 chmod를 실행하는 다른 많은 방법이 있습니다. 이 시점에서 시스템에서 사용자 지정 빌드 실행 파일을 사용하려는 공격자는 자신의 컴퓨터에서이를 빌드하여 서버로 전송할 수 있습니다.

찾아야 할 훨씬 더 관련된 것들이 있습니다. 설치된 소프트웨어에 보안 버그가 포함 된 경우 공격자에게 노출 될 수있는 몇 가지 방법이 있습니다.

  • 패키지는 suid 또는 sgid 실행 파일을 포함 할 수 있습니다.
  • 패키지가 시스템에서 서비스를 시작 중일 수 있습니다.
  • 패키지는 특정 상황에서 자동으로 호출되는 스크립트를 설치할 수 있습니다 (크론 작업이 포함되지만 네트워크 인터페이스의 상태가 변경되거나 사용자가 로그인 할 때와 같은 다른 이벤트에 의해 스크립트가 호출 될 수 있음).
  • 패키지는 장치 inode를 설치할 수 있습니다.

개발 도구가 위 중 하나와 일치하지 않을 것으로 예상되므로 위험이 높은 패키지는 아닙니다.

개발 도구를 사용할 워크 플로가있는 경우 먼저 해당 워크 플로가 합리적인 워크 플로인지 결정해야하며 해당 워크 플로 인 경우 개발 도구를 설치해야합니다.

서버에 이러한 도구가 실제로 필요하지 않은 경우 여러 가지 이유로 설치하지 마십시오.

  • 서버와 백업 모두에서 디스크 공간을 절약합니다.
  • 덜 설치된 소프트웨어를 사용하면 종속성을 쉽게 추적 할 수 있습니다.
  • 패키지가 필요하지 않은 경우 보안 위험이 적더라도 추가 보안 위험이 패키지를 설치하지 않아도됩니다.

보안상의 이유로 권한이없는 사용자가 자신의 실행 파일을 서버에 넣도록 허용하지 않는 경우 개발 도구가 아니라 실행 권한으로 마운트 된 파일 시스템의 해당 사용자에게 쓰기 가능한 디렉토리를 피해야합니다. 이러한 상황에서도 개발 도구를 계속 사용할 수는 있지만 그럴 가능성은 낮습니다.


6
여기에는 여러 프로덕션 시스템이 해석 된 코드 (예 : PHP, Perl, Python 등)에 의존한다는 점을 덧붙입니다. 이러한 맥락에서 개발 도구를 금지하는 것은 의미가 없습니다. 컴파일러 gcc는 이것보다 더 높은 위험을 나타내지 않는 것을 고려하고 있습니다. 당신이 말했듯이, 시스템에 설치된 컴파일러를 사용하는 공격자는 일반적으로 자신의 (정적으로 링크 된) 실행 파일을 업로드하는 것과 같이 더 나쁜 일을 할 수 있습니다.
Bruno

3
관련 : 작은 버전의 wget (51 바이트?) . 후속 echo문장을 파일로 사용하여 바이너리를 서버로 옮기는 공격자의 실제 사례 . 전체 프로세스는 동일한 링크에있는 스크립트로 자동화됩니다.
Adi

2
@Adnan, 흥미로운. 내가 알 수있는 한,이 DVR 예제의 주요 보안 결함은 공격자가 처음에 암호 123456을 사용하여 루트로 텔넷에 연결할 수 있다는 사실입니다. 그런 다음 wget이나 다른 도구 (공격 전)가 있는지 여부는 실제로 거의 관련이 없습니다.
Bruno

15

make와 구문이 다른 쉘입니다 bash.

컴파일러 gccawk표준 awk이 지원하지 않는 대체 세트로 구성된 강력한 기능입니다. POSIX를 준수하지 sort않거나 cat출력에 쓰레기를 주입합니다. vi시작시 일부 편집을 수행 한 다음 사용자 인터페이스를 표시하기 전에 종료하도록 구성된 대화식 텍스트 편집기 (think )입니다.

본질적으로 안전하지 않은 것은 없으며 bash + cat+ 쉘 리디렉션 이있는 시스템보다 안전하지 않습니다 .


2
대답은 너무 평가하는 방법을 모르겠습니다.
kasperd

4
@kasperd이 답변은 진지한 것입니다. 프로그래머의 관점을 가져 오는 것이 도움이 될 수 있다고 생각했습니다. 입력을 출력으로 변환하는 기능은 그 출력이 CPU가 이해할 수있는 형식이기 때문에 취약점을 유발하지 않습니다.
ignis

1
나는 당신이 만드는 요점에 동의합니다. 귀하의 답변은 이미 이에 동의 한 모든 사람에게 큰 도움이 될 것입니다. 나는 당신의 대답이 동의하지 않는 누군가에게 농담으로 나타날 수 있다고 걱정합니다.
kasperd

나는이 답변이 허용 된 것보다 훨씬 더 좋아 :)
Ruslan

15

make자체는 괜찮습니다. make의존성 추적 및 자동화 프레임 워크 일뿐입니다. 그러나 일반적으로 컴파일러와 함께 사용되며 프로덕션 시스템에서는 완전히 필요하지 않으므로 바람직하지 않습니다. 공유 라이브러리, 인터프리터 등 모든 불필요한 패키지에 대해서도 마찬가지입니다. 프로덕션 시스템에 설치된 소프트웨어는 엄격하게 제어해야하며 응용 프로그램에 필요한 패키지 만 있어야합니다.

빌드 서버에서 애플리케이션을 빌드하고 패키징 한 다음 바이너리 시스템을 프로덕션 시스템에 배치해야합니다.

참고 : 기본 패키지 도구를 빨아 . 그들을 망치려고 노력조차하지 마십시오. 대신 Jordan Sissel 's를 확인하십시오 fpm. 그것은 포장을 절대적인 기쁨으로 만듭니다.


8
여기서 호기심과 무지에 대해 묻습니다. 왜 컴파일러의 존재가 "중요한 보안 문제"라고 말합니까? 컴파일러 설치와 관련된 보안 문제는 무엇입니까? 처음에는 프로덕션 서버에서 코드를 작성해서는 안되므로 문제가됩니까? 따라서 컴파일러가 불필요하거나 실제로 컴파일러 자체에 심각한 보안 문제가 있습니까?
reirab

11
별도의 서버에서 애플리케이션을 구축하는 것이 좋지만 프로덕션 시스템에 컴파일러가 존재한다는 것은 보안 상 중요한 문제가 아니라고 말합니다. 스크립팅 언어 및 JIT 컴파일 시스템 (Perl, Python, Java 등)은 어떻습니까?
Bruno

3
프로덕션 환경에 컴파일러가있는 것은 "중요한 보안 위험" 이 아닙니다 . 나 자신 echo과 and를 사용하여 바이너리를 손상된 상자로 옮겼습니다 base64. 실제로, 당신은 일련의 echo진술로 그것을 할 수 있으며 다른 도구는 없습니다 .
Adi

1
좋은 지적입니다. 명확히하기 위해 답변을 편집했습니다.
EEAA

9

반대로 make프로덕션 서버에있을 수있는 잠재적 인 문제는 테스트 된 사전 빌드 된 이미지를 배포하는 대신 프로덕션 서버에 응용 프로그램을 빌드하는 것입니다. 이 방법론에 대한 타당한 이유가있을 수 있지만, 내가 그것을 채택하도록 요청 받았다는 것이 강력하게 반대하는 이유입니다.


4

make프로덕션 서버에 설치해야하는지 묻는 것이지만 실제 질문은 다음과 같습니다. 누가 프로덕션 서버에 액세스 할 수 있으며 침입을 처리하기 위해 어떤 보호 장치를 갖추고 있습니까? 경우 make설치되어 있지만 누군가 이득되지 않은 root액세스, 무슨 생각? 그들은 수동으로 설치 make하고 원하는 것을 할 수 있습니다 .

컴퓨터 보안에 대한 혹독한 현실은 원치 않는 액세스를 막고 자하는 것입니다. 액세스 차단에 집착하는 것은 다음과 같이 중요하지 않습니다.

  1. 서버에 누가 액세스 할 수 있습니까?
  2. 침입 후의 결과에서 롤백하기 위해 무엇을 할 수 있습니까?

이것은 당신이하는 일에 달려 있습니다. 나는 주로 웹 서버 세계에서 일하며 내 태도는 기본적으로 나로부터 프로덕션 서버 액세스 권한을 얻는 사람은 기술, 지식 및 성숙도를 입증해야합니다. 그게 다야. 때로는 며칠이 걸립니다. 때로는 몇 달이 걸립니다. 그러나 기본적으로 프로덕션 서버의 최상의 보안 라인은 서버를 강화하기 위해 우리가하는 다른 일들에 대한 액세스를 제어하는 ​​것입니다.


1

make그 자체는 무해합니다. 지정한 종속성과 시스템에 이미 존재하는 파일에 따라 정해진 순서로 응용 프로그램을 실행하기 만하면됩니다. 설치 프로세스의 일부로 유용 할 수도 있습니다. 미리 빌드 한 파일을 이동하거나 유닛 테스트 또는 기타 작업을 실행하는 데 사용할 수 있습니다.

그러나 정확히 사용하려는 대상을 고려해야 합니다. 그것은 종종 응용 프로그램을 구축하기위한 컴파일러 및 기타 도구와 함께 사용되며, 그는 방어의 회선 중 일부를 부정하는 데 사용할 수 있습니다. 그러나 make도구를 사용할 수 없으면 이러한 작업을 수행 할 수 없습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.