답변:
우선, Apache의 모든 스크립팅 기능 (php, cgi, ruby, ...)은 스크립트를 실행하는 사용자의 권한을 가진 쉘 계정과 동등한 가능성에 유의하십시오.
서버가 여러 사용자와 공유되는 경우 suexec (-또는 ITK MPM - David Schmitt 제안 )를 사용하여 모든 스크립트가 동일한 아파치 사용자로 실행되는 것은 아닙니다.
가상화 또는 chroot 아파치를 통해 추가 보안 계층에 타협이 포함되도록합니다. 아파치를 chroot 할 때 라이브러리를 감옥 등으로 옮기면 유지 관리가 어려워 질 수 있습니다. FreeBSD를 사용하는 경우 대신 아파치를 설치할 수 있기 때문에 유지 관리가 훨씬 쉬운 감옥을 대신 사용할 수 있습니다 라이브러리 의존성에 대해 걱정할 필요없이 파일을 수동으로 이동시킬 필요없이 포트에서 포트 감사를 실행할 수 있습니다. BSD jails를 사용하면 패키지 관리 시스템 (포트)을 계속 사용할 수 있습니다. (GNU / Linux 에서는 가상화를 위해 VServer 를 사용할 수도 있습니다 .- David Schmitt 제안 )
(분명히) Apache뿐만 아니라 PHP, ruby, perl 등의 업데이트 및 패치를 유지하십시오. OS가 모든 업데이트를 제공한다고 신뢰하지는 않습니다. 일부 배포판은 패치가 너무 느립니다. 노출 시간을 0 일 취약점으로 최대한 제한하십시오. 스틱 milw0rm의 , RSS 리더에 피드를 구독 insecure.org의 등 ...뿐만 아니라 그것은 당신의 OS 패치를 발표 주위에 도착하기 전에, 당신은 또한 특정 PHP 취약점에 대해 배우게됩니다 취약점에 대해 배울 도움이 될 것입니다, 메일 링리스트 예를 들어 cms 응용 프로그램은 OS에서 전혀 관리하거나 패치하지 않을 수도 있습니다.
파일 시스템의 변경 사항을 추적 하려면 tripwire / aide, audit 또는 BSD의 mtree (BSD)와 같은 것을 사용하십시오 . 이것은 정말 중요합니다. 변경 사항을 정기적으로 우편으로 보내 매일 매일 수동으로 검토하십시오. 변경되지 않아야하는 파일이 변경되면 그 이유를 조사하십시오. 어떤 방법 으로든 어떤 악성 자바 스크립트가 페이지에 삽입되면 이런 식으로 잡을 것입니다. 이렇게하면 자신의 웹 페이지가 남용되어 방문자를 감염시킬 수 있으므로 서버뿐만 아니라 사용자도 절약됩니다. (이것은 매우 일반적인 전술이며, 공격자는 종종 서버에 신경 쓰지 않으며, 발견 될 때까지 가능한 한 많은 방문자를 감염시키기를 원합니다. 이러한 공격자는 일반적으로 트랙을 숨기지 않아도됩니다. 이와 같은 타협을 최대한 빨리 잡는 것이 매우 중요합니다.)
PHP를 보호하기 위해 suhosin 과 같은 것을 사용하면 도움이됩니다. 또한 이해하는 법을 배우고 응용 프로그램의 예상 매개 변수 구성을 조정하십시오.
PaX 와 같은 커널 패치를 사용하면 많은 버퍼 오버플로 취약점으로부터 보호 할 수 있습니다. 소프트웨어가 취약한 경우에도 마찬가지입니다. (이것은 당신을 무적 상태로 만들지 않으며 단지 또 다른 작은 레이어입니다.)
일부 보안 도구를 사용할 때 과신하지 마십시오. 사용하는 도구를 이해하고 상식을 사용하십시오. 당신이 할 수있는만큼 읽고 배우십시오.
필수 액세스 제어 (예 : SELinux ) 사용을 고려하십시오 . 각 응용 프로그램에 대해 수행 할 수있는 작업을 자세하게 지정할 수 있습니다. 어떤 파일에 액세스 할 수 있습니까? 커널 호출은 무엇을 할 수 있는지 등입니다. 이것은 매우 복잡한 과정이며 많은 이해가 필요합니다. 일부 배포판은 패키지에 대해 사전 제작 된 SELinux 정책을 제공합니다 (예 : Gentoo ). 이 제안은 아래의 내용과 모순되지만 여전히 유효합니다.
일을 단순하게 유지하십시오. 복잡한 보안 전략이 효과적 일 수 있습니다.
Apache에서는 매우 제한적인 기본 규칙 (옵션 없음, 모두 거부 등)을 설정하고 특정 VirtualHost에 필요한대로 재정의합니다.
모든 도트 파일에 대한 액세스 거부 (.htaccess 파일도 즉시 포함)
모든 종류의 비밀번호 인증이있는 경우 항상 https를 사용하십시오.
방화벽은 기본적으로 거부 정책이어야합니다. 방화벽에서 특정 규칙을 작성하여 특정 트래픽을 기록하십시오.
로그 구문 분석 스크립트를 설정하여 로그에 이상이 있는지 스캔하십시오. ( prelude IDS 제품군이이를 수행 할 수 있지만 솔직히 말하면 자신의 도구와 규칙을 더 잘 이해하는 데 도움이되므로 시간이 지남에 따라 고유 한 스크립트를 작성하는 것이 좋습니다.)
서버가 매일 로그인 한 사용자, 활성 연결, 사용 된 대역폭 등에 대해 매일보고하는 메일을 받도록하십시오.
크론에서 suid 바이너리, 월드 쓰기 가능 파일 등을 스캔하여 우편으로 보내십시오.
설정 한 것들에 대해 우편으로 발송되는 경우 시간이 지남에 따라 예외 목록을 작성해야합니다. (파일 시스템 변경을 무시할 폴더, 허용 할 777 파일, 허용되는 바이너리 바이너리 허용). 발생해서는 안되는 일에 대해서만 알림을받는 것이 중요합니다. 매일 사소한 것들로 메일을 받으면 무시하기 시작하고 무의미해질 것입니다.
견고한 중복 백업 전략을 세우십시오. 그리고 이미지 나 모든 사본을 만드는 것이 효과가 있다고 가정하지 마십시오. 예를 들어, 백업 중 MySQL이 테이블에 쓰는 중이면 백업을 복원 할 때 MySQL 이진 파일이 손상 될 수 있습니다. 따라서 mysqldump가 일반 이미지 또는 야간 타르볼 또는 버전 제어 또는 설정 한 다른 것 위에 데이터베이스를 설치하는 cron이 필요합니다. 백업 전략에 대해 생각해보십시오. 진심으로 생각 해봐
보안을 위해 이와 같은 목록에 의존하지 마십시오 :) 심각하게! 인터넷을 통해 이러한 것들을 많이 찾고, 모든 것을 읽고, 모든 제안을 연구하고, 상식과 경험을 사용하여 자신의 마음을 구성하십시오. 결국, 경험과 상식 만이 당신을 구할 것입니다. 목록이나 도구가 아닙니다. 읽지 만 이해하지 않고 복사하지 마십시오.
SAN 의 Linux Security Checklist를 권장합니다 . 나는 그 외에도 다른 사내 절차를 사용합니다. 체크리스트는 약간 오래되었지만 주요 요점은 사실입니다.
점검 할 수있는 수많은 권한, 무수한 체크리스트, 항상 새로운 버그 / 취약점 발견을 끝내지 않을 것입니다. 내가 생각하지 않는 보안은 여러분이 켜거나 끄는 것이 아니라 끊임없이하는 것입니다.
소프트웨어의 "피할 수없는 실패"를 감안할 때 SELinux는 몇 가지 걱정을 덜어줍니다. 사용자 공간 응용 프로그램이 손상되었다고 가정하면 올바른 SELinux 정책으로 인해 일반적인 (SELinux가 비활성화되었거나 허용 된 경우) 권한으로 작동하지 못하게됩니다. 물론 감사 로그를 모니터링하고 설치된 정책을 분석하고 필요한 경우 응용 프로그램이 작동 할 수 있도록 수정해야합니다.
기본 정책을 말하는 것은 도움이되지 않지만 개인적으로 허용되는 것을 알고 싶습니다.