☰

Apache 보안 구성 - Ubuntu 12

tag-icon • tag-icon apache-2.2 web-server ubuntu-12.04 httpd.conf security
Apache 보안 구성 - Ubuntu 12

저는 PHP 기반 API를 제공하는 기본 기능을 사용하여 Ubuntu 12에서 LAMP 스택을 실행하고 있습니다.

대중에게 공개하고 싶은 파일은 다음과 같습니다:api.php

/cfg/api-config.phpAPI가 데이터베이스 등에 쓸 수 있도록 db 비밀번호가 포함 된 구성 파일을 참조해야 합니다 .

그래서 나는 api.php아파치가 '제공'하고 공개하기를 원합니다.

/cfg에 넣은 구성 파일은 api.php에서 읽을 수 있어야 하지만 사이트를 방문하는 사람은 읽을 수 없습니다.

나는 없으며 아래에 따라 구성되었습니다 .htaccess.httpd.conf

<VirtualHost *:44448>
    DocumentRoot "/api"
    ServerName localhost:44448
    ServerAlias Server.local
    DirectoryIndex index.html
    CustomLog "/var/log/apache_access.log" combined
    ErrorLog "/var/log/apache_error.log"

    SetEnv APPLICATION_ENV development
    php_flag magic_quotes_gpc off

    <Directory "/api">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

내 폴더에 대한 권한은 /cfg다음 과 /api같습니다. drwxr-xr-xDB 비밀번호가 있는 민감한 구성 파일에 대한 권한은 /cfg/api-config.php다음과 같습니다.-rw-r--r--

이것이 올바르고 안전한지 누군가가 나에게 말해 줄 수 있는지 궁금합니다.

방법:

A) 이외의 모든 파일은 /api/api.php공개되지 않으며 내 서버 파일에 액세스할 수 없습니다.

B) db(api용) 비밀번호가 포함된 구성 파일도 사이트를 방문하는 사람이 읽을 수 없습니까?

/cfgwith 에 새 폴더를 생성하여 이를 테스트해 보았는데 chmod 777, 액세스할 수 없는 것 같습니다. 좋은 일입니다!

답변1

두 개의 파일이 있습니다(/var/www에 있다고 가정).

  • /var/www/api/api.php
  • /var/www/cfg/api-config.php

우선, Apache를 사용하여 /cfg에 대한 액세스를 제한하고(이렇게 하면 누구도 http에서 액세스할 수 없도록 보장) /api에 대한 액세스를 허용합니다.

<Directory /var/www/api>
    Options None
    AllowOverride None
    Order allow,deny
    Allow from all
<Directory>

<Directory /var/www/cfg>
    Options None
    AllowOverride None
    Order allow,deny
    Deny from all
<Directory>

다음으로, open_basedir로 PHP를 제한하세요:

open_basedir = /var/www/api:/var/www/cfg

(필요한 경우 여기에 /tmp, 세션 및 기타 디렉터리를 추가하세요)

다음으로 /var/www/cfg 디렉토리 및 /var/www/cfg/api-config.php 파일의 액세스 모드를 변경합니다(Apache 사용자가 www-data라고 가정).

  chown -Rv root:root /var/www/{cfg,api}
  chmod -v 711 /var/www/cfg
  chmod -v 755 /var/www/api
  chmod -v 644 /var/www/api/api.php /var/www/cfg/api-config.php

사용하여711/cfg에서는 누구도 디렉토리의 내용을 읽(나열)할 수 없지만 api-config.php는 읽을 수 있도록 보장합니다(PHP로 파일을 읽으려면 이것이 필요합니다).

답변2

먼저 cfg와 그 안에 있는 파일의 파일 권한을 변경하겠습니다. DB - 설정을 저장하면 읽기 권한이고 쓰기 권한을 제거해야 합니다. Apache HTTP 데몬 환경을 안전하게 설정하는 것은 좋지만 이는 또 다른 보안 계층입니다. 귀하의 PHP 설치는 HTTP 데몬의 사용자 컨텍스트 내에서 실행되므로 개인적으로 그룹에 대한 읽기 액세스 권한도 제거하겠습니다. 어떤 테스트를 했는지 궁금합니다. cfg - 폴더는 DocumentRoot 아래에 없는 것 같아서 언뜻 보면 HTTP - 서버에서 액세스할 수 없는 것 같습니다. 그러나 귀하의 설비에 침입하려는 사람들은 이러한 접근 방식에 의존하지 않을 것입니다. 구성에 AllowOverride All Order 허용, 거부 허용이 있는데 이는 단순히 액세스 제어가 전혀 없음을 의미합니다. 또한 다른 보안 영향을 초래하는 FollowSymLinks도 명시합니다. 따라서 이 설치는 보안에 훨씬 뒤떨어져 있습니다. 설치의 DocumentRoot에 .htaccess 파일을 넣어 cfg 폴더를 보호할 수 있습니다. 여기에 포함된 항목은 파일 및 디렉토리 액세스를 모두 강력하게 보호할 수 있습니다. 예:

<Files RELEASE_NOTES.txt>
order 허용, 거부
모든 항목에서 거부
</Files> (magento 설치에서 가져옴)

FollowSymLinks의 보안 영향에 대해 궁금하신 경우: PHP는 Apache HTTP 데몬 설치 컨텍스트에서 실행되고 있다는 점을 기억하세요. PHP는 파일 시스템에서 쓰기 작업을 수행할 수 있습니다. PHP - 코드가 애플리케이션에 삽입되어 심볼릭 링크를 생성하면 누군가가 관심 있는 시스템 부분에 대한 심볼릭 링크를 생성하여 파일 시스템을 감시할 수 있습니다. 간단한 .htaccess - 파일을 cfg에 배치합니다. - Order Allow,deny Deny from all 형식의 디렉토리는 HTTP 데몬을 통해 이 디렉토리를 탐색하는 기능을 제거합니다. api.php가 PHP 설치/웹앱의 전면 컨트롤러인 경우 Apache의 mod_rewrite를 사용하여 api.php를 가리키도록 요청된 모든 URL을 다시 작성하는 것을 고려해야 합니다. 예:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ api.php [L]

.htaccess - 파일에서 /api - 디렉토리에 배치하면 모든 요청이 api.php로 라우팅됩니다. 예를 들어 localhost:44448/someURL?id=988은 내부적으로 localhost:44448/api.php?id=988 요청이 됩니다.
명확하게 하기:
재작성 - 규칙은 액세스 제어에 사용되어서는 안 됩니다. 규칙의 목적은 주로 요청 처리 방법을 변경하는 것입니다.
많은 PHP - 프레임워크 또는 CMS는 RewriteRules를 사용하여 응용 프로그램 구성 요소가 로드되고 라우팅 구성 요소가 호출될 수 있으며 URL 매개 변수에서 내부 구조로의 변환이 수행되는 웹 응용 프로그램에 대한 중앙 진입점을 갖습니다.
예를 들어 Symfony2는 Query/및 Post 매개변수를 보다 객체 지향적인 구조로 변환하여 이를 객체로 캡슐화합니다.
Symfony2는 또한 HTTP 응답을 생성하기 전에 라우팅(정보 및 구성)을 읽어 보안 개념을 활용합니다. 예를 들어 인증이 수행되었는지 확인하거나 사용자가 URL 경로에 액세스하기 위한 올바른 사용자 역할을 가지고 있어야 하는지 확인합니다.

답변3

/cfg/api-config.phpDocumentRoot 외부에 두는 중요한 작업을 수행한 것 같습니다 . /cfgURL 공간 내에 없으면 웹 사이트 사용자는 이를 읽을 수 없습니다 . 이것이 취할 수 있는 가장 기본적인 예방 조치입니다.

사용자가 여전히 해당 파일을 읽을 수 있습니까? 물론, 다른 곳에서 구성을 중단하거나(예를 들어 파일에 Alias또는 파일을 설정하여 RewriteRule) 응용 프로그램이 파일 내용을 출력하는 등 어리석은 작업을 수행하는 경우에는 그렇습니다. 애플리케이션 취약성은 실제 우려 사항입니다. 애플리케이션은 파일을 읽을 수 있어야 하며, 애플리케이션이 복잡할수록 숨겨진 취약성이 있을 가능성이 더 높습니다. 하지만 Apache 구성에 관한 한 모든 작업이 완료된 것 같습니다.

답변4

위의 제안 외에도 Apache 사용자가 소유한 DocumentRoot의 모든 파일/폴더에 대한 쓰기 액세스를 제거하는 것이 좋습니다. (예: api.php 파일) 이는 api.php(또는 이것이 호출하는 모든 것)가 로컬 웹 서버에 아무것도 쓸 필요가 없다고 가정합니다. 이는 원치 않는 파일이 웹 서버에 기록되는 것을 방지하는 데 도움이 됩니다.

관련 정보