7장 서버 액세스 제어

인증, 권한 및 액세스 제어 등 다양한 보안 서비스 및 기법을 통해 웹 서버에 있는 자원을 보호할 수 있습니다. 이 장에서는 Web Server 에 대한 액세스를 제어하는 몇 가지 지원 메커니즘에 대해 설명합니다.

• 액세스 제어란?

• 액세스 제어의 작동 방식

• 사용자 그룹용 액세스 제어 설정

• 호스트-IP용 액세스 제어 설정

• ACL 사용자 캐시 구성

• 액세스 제어 구성

• .htaccess 파일 사용

액세스 제어란?

인증은 신분을 확인하는 과정입니다. 권한은 특정 사용자가 제한된 자원에 액세스할 수 있도록 허용하는 것을 의미하며 액세스 제어 기법을 통해 이러한 제한을 실행합니다. 인증 및 권한은 여러 보안 모델(웹 응용 프로그램 보안, htaccess, 인증 영역 등)과 서비스를 통해 실행될수 있습니다.

액세스 제어를 사용하면 다음을 결정할 수 있습니다.

• Administration Server에 액세스할 수 있는 사용자

• 액세스할 수 있는 응용 프로그램

• 웹 사이트의 파일 또는 디렉토리에 액세스할 수 있는 사용자

서버의 전체 또는 일부, 또는 웹 사이트의 파일 또는 디렉토리에 대한 액세스를 제어할 수 있습니다. ACE(Access Control Entries)라는 규칙 계층을 만들어 액세스를 허용 또는 거부합니다. 만드는 ACE의 모음을 액세스 제어 목록(ACL)이라고 합니다.

기본으로 서버에는 하나의 ACL 파일이 있으며 여기에는 여러 개의 ACL이 있습니다. 들어오는 요청에 사용할 가상 서버를 지정하면 서버는 해당 가상 서버에 대해 ACL이 구성되어 있는지 확인합니다. 현재 요청에 적용되는 ACL이 있는 경우 서버는 ACE를 평가하여 액세스를 허용할 것인지 또는 거부할 것인지 결정합니다.

다음을 기준으로 액세스를 허용 또는 거부합니다.

• 요청하는 사용자(사용자 그룹)

• 요청의 출처(호스트-IP)

• 요청이 발생한 시간(예: 하루 중 시간)

• 사용되는 연결의 종류(SSL)

액세스 제어의 작동 방식

서버에 페이지에 대한 요청이 수신되면 서버는 ACL 파일에 있는 규칙을 사용하여 액세스 허용 여부를 결정합니다. 규칙은 요청을 보내는 컴퓨터의 호스트 이름 또는 IP 주소를 참조할 수 있습니다. 또한 LDAP 디렉토리에 저장된 사용자 및 그룹을 참조할 수 있습니다.

일치하는 ACL이 두 개 이상인 경우 서버는 일치되는 마지막 ACL 문을 사용합니다. 일치하는 마지막 문이 uri ACL이기 때문에 default ACL은 무시됩니다.

위의 그림은 Web Server 에서 액세스 제어의 작동 방식을 보여줍니다. 사용자 에이전트(클라이언트)가 Web Server에 액세스합니다. Web Server는 obj.conf 파일에 있는 PathCheck 지시문을 실행합니다. Web Server는 클라이언트에 HTTP 401(인증되지 않음)을 반환합니다. 클라이언트는 사용자의 인증 확인을 요구하는 프롬프트를 표시합니다. 클라이언트가 브라우저인 경우에는 로그인 대화 상자가 열립니다. 사용자가 로그인 정보를 입력합니다. Web Server는 내부 check-acl 함수를 실행합니다. Web Server는 사용자 자격 증명을 검증하고 요청을 처리합니다.

사용자 그룹용 액세스 제어 설정

웹 서버에 대한 액세스를 특정 사용자 또는 그룹으로 제한할 수 있습니다. 사용자 그룹 액세스 제어를 사용하려면 사용자가 해당 서버에 액세스하기 전에 사용자 이름과 비밀번호를 입력해야 합니다. 서버는 클라이언트 인증서에 있는 정보를 디렉토리 서버 항목과 비교합니다.

Administration Server는 오직 기본 인증만 사용합니다. Administration Server에 클라이언트 인증을 요청하도록 하려면 ACL 파일을 직접 편집하여 메소드를 SSL로 변경해야 합니다.

사용자 그룹 인증은 Web Server에서 사용자 그룹 데이터베이스에 있는 항목을 읽어서 수행합니다. 디렉토리 서비스가 액세스 제어를 구현하는 데 사용하는 정보는 다음 중 한 가지 소스에서 구합니다.

• 내부 보통 파일 유형 데이터베이스

• 외부 LDAP 데이터베이스

서버가 외부 LDAP 기반 디렉토리 서비스를 사용하는 경우 서버 인스턴스용으로 다음 유형의 사용자 그룹 인증 메소드를 지원합니다.

• Default

• Basic

• SSL

• Digest

• 기타

서버가 내부 파일 기반 디렉토리 서비스를 사용하는 경우 서버 인스턴스용으로 다음 유형의 사용자 그룹 인증 메소드를 지원합니다.

• Default

• Basic

• Digest

사용자 그룹 인증을 수행하려면 사용자가 서버 또는 웹 사이트의 파일 및 디렉토리에 액세스하기 전에 자신을 인증해야 합니다. 인증 시 사용자는 클라이언트 인증서를 사용하여 사용자 이름과 비밀번호를 입력하는 방식으로 신분을 확인합니다. 클라이언트 인증서는 SSL 통신인 경우에만 필요합니다.

Default 인증

Default 인증은 가장 많이 사용되는 메소드입니다. Default 설정으로 하면 server.xml 파일의 기본 메소드를 사용하고 server.xml에 설정이 없을 경우 "Basic"을 사용합니다. Default를 선택하면 ACL 규칙에서 ACL 파일에 메소드를 지정하지 않습니다. Default를 선택한 경우 obj.conf 파일에서 한 줄만 편집하면 모든 ACL의 메소드를 간단하게 변경할 수 있습니다.

Basic 인증

Basic 인증을 사용하려면 사용자가 웹 서버나 웹 사이트에 액세스하기 위해 사용자 이름과 비밀번호를 입력해야 합니다. 이 설정이 기본값입니다. Sun Java System Directory Server와 같은 LDAP 데이터베이스나 파일에 사용자 및 그룹 목록을 만들어 저장해야 합니다. 웹 서버가 아닌 다른 루트 디렉토리에 설치된 디렉토리 서버 또는 원격 컴퓨터에 설치된 디렉토리 서버를 사용해야 합니다.

Administration Server 또는 웹 사이트에서 사용자 그룹 인증이 있는 자원에 액세스하려는 경우 웹 브라우저에 사용자 이름과 비밀번호를 입력하라는 대화 상자가 표시됩니다. 서버에서 암호화 기능이 사용되는지의 여부에 따라 이 정보는 암호화 또는 암호화되지 않은 형태로 서버에 입력됩니다.

SSL 암호화가 없는 Basic 인증을 사용하는 경우 사용자 이름과 비밀번호가 암호화되지 않은 텍스트로 네트워크에 전송됩니다. 네트워크 패킷은 가로챌 수 있으며 사용자 이름과 비밀번호가 도용될 수 있습니다. Basic 인증은 SSL 암호화, 호스트-IP 인증 또는 두 가지 인증을 모두 사용하는 경우에 가장 효과적입니다. Digest 인증을 사용하면 이러한 문제를 방지할 수 있습니다.

SSL 인증

서버는 다음 두 가지 방법을 사용하여 보안 인증서가 있는 사용자의 신분을 확인합니다.

• 클라이언트 인증서의 정보를 신분 증명으로 사용

• LDAP 디렉토리에 게시된 클라이언트 인증서 확인(추가)

서버가 클라이언트 인증용으로 인증서 정보를 사용하도록 설정하면 서버는 다음 작업을 수행합니다.

• 우선 인증서가 신뢰할 수 있는 인증 기관에서 발급된 것인지 확인합니다. 그렇지 않은 경우 인증이 실패하며 트랜잭션이 종료됩니다.

• 인증서가 신뢰할 수 있는 인증 기관(CA)에서 발급된 경우 certmap.conf 파일을 사용하여 인증서를 사용자 항목에 매핑합니다.

• 인증서가 올바로 매핑된 경우 해당 사용자에 대해 지정된 ACL 규칙을 확인합니다. 인증서가 올바로 매핑된 경우라도 ACL 규칙에 따라 사용자 액세스를 거부할 수 있습니다.

특정 자원에 대한 액세스 제어를 위해 클라이언트 인증을 요구하는 것은 서버에 대한 모든 연결에 대해 클라이언트 인증을 요구하는 것과 다릅니다. 모든 연결에 대해 서버가 클라이언트 인증을 요구하도록 설정한 경우 클라이언트는 신뢰할 수 있는 인증 기관에서 발급한 유효한 인증서만 제시하면 됩니다. 서버의 액세스 제어가 사용자 및 그룹 인증을 위해 SSL 메소드를 사용하도록 설정하는 경우 클라이언트는 다음 작업을 수행합니다.

• 신뢰할 수 있는 인증 기관에서 발급한 유효한 인증서를 제시합니다.

• 인증서는 LDAP에 있는 유효한 사용자에 매핑되어야 합니다.

• 액세스 제어 목록에서 적절히 평가해야 합니다.

액세스 제어와 함께 클라이언트 인증을 요구하는 경우 웹 서버용 SSL 암호를 사용하도록 설정해야 합니다.

SSL 인증이 요구되는 자원에 성공적으로 액세스하려면 웹 서버가 신뢰하는 인증 기관으로부터 클라이언트 인증서가 발급되어야 합니다. 웹 서버의 certmap.conf 파일이 브라우저에 있는 클라이언트 인증서와 디렉토리 서버에 있는 클라이언트 인증서를 비교하도록 구성된 경우에는 클라이언트 인증서가 디렉토리 서버에 게시되어야 합니다. 그러나 certmap.conf 파일은 인증서의 선택된 정보만 디렉토리 서버 항목과 비교하도록 구성할 수 있습니다. 예를 들어 브라우저 인증서의 사용자 아이디와 전자 메일 주소만 디렉토리 서버 항목과 비교하도록 certmap.conf 파일을 구성할 수 있습니다.

인증서는 LDAP 디렉토리와 비교해 확인되기 때문에 SSL 인증 방법을 사용하려면 certmap.conf 파일을 수정해야 합니다. 서버로의 모든 연결에 대해 클라이언트 인증이 요구되는 경우에는 이 파일을 변경할 필요가 없습니다. 클라이언트 인증서를 사용하도록 선택한 경우 magnus.conf의 AcceptTimeout 지시문 값을 올려야 합니다 .

Digest 인증

LDAP 기반 또는 파일 기반 디렉토리 서비스를 사용하여 Digest 인증을 수행하도록 서버를 구성할 수 있습니다.

Digest 인증을 사용하면 사용자가 사용자 이름과 비밀번호를 일반 텍스트로 전송하지 않고 사용자 이름과 비밀번호를 기준으로 인증할 수 있습니다. 브라우저는 MD5 알고리즘을 사용하여 Web Server가 제공하는 사용자 비밀번호 및 일부 정보를 사용하는 다이제스트 값을 만듭니다.

서버에서 LDAP 기반 디렉토리 서비스를 사용하여 Digest 인증을 수행하는 경우 이 다이제스트 값은 서버측에서 Digest 인증 플러그인을 통해서도 계산되며 클라이언트에서 제공하는 다이제스트 값과 비교됩니다. 다이제스트 값이 일치하면 사용자가 인증됩니다. 이렇게 하려면 디렉토리 서버가 일반 텍스트로 사용자의 비밀번호에 액세스해야 합니다. Sun Java System Directory Server에는 역변환 가능한 비밀번호 플러그인이 있으며, 이는 데이터를 암호화된 형태로 저장하여 나중에 원래 형태로 해독할 수 있는 대칭 암호화 알고리즘을 사용합니다. 오직 Directory Server만이 데이터의 키를 보유합니다.

LDAP 기반 Digest 인증의 경우 서버에 포함된 역전환 가능 비밀번호 플러그인과 digestauth 특정 플러그인을 사용하도록 설정해야 합니다. 웹 서버가 Digest 인증을 처리하도록 구성하려면 dbswitch.conf에 있는 데이터베이스 정의에서 digestauth 등록 정보를 설정해야 합니다.

ACL 방법을 지정하지 않는 경우, 서버는 인증이 필요하면 Digest 또는 Basic 인증을 사용하고 인증이 필요하지 않으면 Basic 인증을 사용합니다. 이것이 가장 많이 사용되는 방법입니다.

method = digest로 설정된 ACL을 처리할 경우 서버는 다음을 수행하여 인증을 시도합니다.

• 인증 요청 헤더 확인. 없는 경우 Digest 시도를 포함하는 401 응답이 생성되며 프로세스는 중지됩니다.

• 인증 유형 확인. 인증 유형이 Digest인 경우:

  • nonce를 확인합니다. 유효하지 않은 경우 이 서버가 새 nonce를 생성하고 401 응답이 생성되며 프로세스가 중지됩니다. 오래된 경우 stale=true로 설정된 401 응답이 생성되며 프로세스가 중지됩니다.

    server_root/https-server_name /config/에 있는 magnus.conf 파일에서 DigestStaleTimeout 매개 변수 값을 변경하여 nonce가 새로운 상태를 유지하는 시간을 구성할 수 있습니다. 이 값을 설정하려면 magnus.conf에 다음 줄을 추가합니다.

    DigestStaleTimeout seconds

    여기서 seconds는 nonce가 새로운 상태를 유지하는 시간(초)을 나타냅니다. 지정된 시간(초)이 경과하면 nonce가 만료되며 사용자에게 새로운 인증이 요구됩니다.

  • 영역 확인. 일치하지 않는 경우 401 응답이 생성되며 프로세스가 중지됩니다.

  • 인증 디렉토리가 LDAP 기반인 경우 LDAP 디렉토리에 사용자가 있는지 확인하며 인증 디렉토리가 파일 기반인 경우 파일 데이터베이스에 사용자가 있는지 확인합니다. 찾을 수 없는 경우 401 응답이 생성되며 프로세스가 중지됩니다.

  • 디렉토리 서버 또는 파일 데이터베이스에서 요청 다이제스트 값을 가져오고 클라이언트의 요청 다이제스트와 일치하는지 확인합니다. 일치하지 않는 경우 401 응답이 생성되며 프로세스가 중지됩니다.

  • Authorization-Info 헤더를 만들고 이를 서버 헤더에 삽입합니다.

호스트-IP용 액세스 제어 설정

Administration Server 또는 웹 사이트의 파일 및 디렉토리를 특정 컴퓨터를 이용하는 사용자만 사용할 수 있도록 설정하여 액세스를 제한할 수 있습니다. 허용 또는 거부할 컴퓨터의 호스트 이름이나 IP 주소를 지정합니다. 여러 대의 컴퓨터 또는 전체 네트워크를 지정하려면 와일드카드 패턴을 사용합니다. 호스트-IP 인증을 사용하는 파일 또는 디렉토리 액세스는 사용자가 알 수 없게 진행됩니다. 사용자는 사용자 이름이나 비밀번호를 입력하지 않고 파일과 디렉토리에 액세스할 수 있습니다.

특정 컴퓨터를 여러 사람이 사용할 수 있기 때문에 호스트-IP 인증을 사용자 그룹 인증과 함께 사용하면 더욱 효과적일 수 있습니다. 두 가지 인증 방법이 모두 사용되는 경우 액세스할 때 사용자 이름과 비밀번호가 필요합니다.

호스트-IP 인증의 경우 서버에 DNS를 구성할 필요가 없습니다. 호스트-IP 인증을 사용하도록 선택한 경우 DNS가 네트워크에서 실행되어야 하며 서버가 DNS를 사용하도록 구성되어야 합니다.

DNS를 사용하도록 설정하면 서버가 DNS 조회를 수행해야 하므로 서버의 성능이 저하됩니다. DNS 조회가 서버 성능에 미치는 영향을 줄이려면 모든 요청의 IP 주소를 확인하는 대신 액세스 제어 및 CGI에 대해서만 IP 주소를 확인합니다. 이렇게 하려면 obj.conf 파일에서 iponly=1을 AddLog fn="flex-log" name="access"에 추가합니다.

AddLog fn="flex-log" name="access" iponly=1

ACL 사용자 캐시 구성

기본적으로 서버는 ACL 사용자 캐시에 사용자 및 그룹 인증 결과를 캐시합니다. magnus.conf 파일의 ACLCacheLifetime 지시문을 사용하여 ACL 사용자 캐시가 유효한 시간을 제어할 수 있습니다. 캐시에 있는 항목을 참조할 때마다 시간이 계산되고 ACLCacheLifetime과 비교하여 확인됩니다. 항목의 시간이 ACLCacheLifetime 이상이면 해당 항목은 사용되지 않습니다 . 기본값은 120초입니다. 값을 0으로 설정하면 캐시가 해제됩니다. 이 값에 큰 수를 사용하면 LDAP 항목을 변경할 때마다 서버를 다시 시작해야 합니다. 예를 들어, 이 값을 120초로 설정하면 서버가 최대 2분까지 LDAP 디렉토리와 동기화되지 않을 수 있습니다. LDAP 디렉토리가 자주 변경되지 않는 경우에만 큰 값을 사용하십시오.

ACLUserCacheSize의 magnus.conf 매개 변수를 사용하면 캐시에 보유할 수 있는 최대 항목 수를 구성할 수 있습니다. 이 매개 변수의 기본값은 200입니다. 새 항목은 목록의 앞에 추가되며 이 목록의 끝에 있는 항목은 캐시가 최대 크기에 도달할 경우 재활용되어 새로운 항목을 만듭니다.

또한 magnus.conf 매개 변수 ACLGroupCacheSize를 사용하여 각 사용자 항목마다 캐시될 수 있는 그룹 구성원의 최대 수를 설정할 수 있습니다. 이 매개 변수의 기본값은 4입니다. 그룹에 있는 사용자가 구성원이 아닌 경우 캐시되지 않으며 이로 인해 모든 요청에 대해 LDAP 디렉토리 액세스가 여러 번 발생하게 됩니다.

ACL 파일 지시문에 대한 자세한 내용은 NSAPI Developer’s Guide를 참조하십시오.

ACL 캐시 등록 정보 설정

CLI를 통해 ACL 캐시 등록 정보를 설정하려면 다음 명령을 실행합니다.

wadm> set-acl-cache-prop --user=admin --password-file=admin.pwd --host=serverhost 
--port=8989 --config=config1 property=value

CLI 참조 set-acl-cache-prop(1)를 참조하십시오.

설정할 수 있는 유효한 등록 정보는 다음과 같습니다.

• enabled — 서버에서 파일 내용과 메타 정보를 캐시하는지 여부를 나타냅니다. 기본값은 true입니다.

• max-age — 파일 내용과 메타 정보를 캐시하는 최대 시간(초)입니다. 값의 범위는 0.001 - 3600입니다.

• max-groups-per-user — 서버에서 구성원 정보를 캐시하는 사용자별 최대 그룹 수입니다. 값의 범위는 1 - 1024입니다.

• max-age — 인증 정보를 캐시하는 최대 시간(초)입니다. 값의 범위는 0.001 - 3600입니다.

액세스 제어 구성

서버는 로컬에 저장된 액세스 제어 목록(ACL)을 사용하여 인증 및 권한을 지원합니다. 이 ACL에는 자원에 대해 사용자가 가지는 액세스 권한이 설명되어 있습니다. 예를 들어, ACL에 있는 항목에서 John이라는 이름의 사용자에게 misc라는 특정 폴더에 대해 read 권한을 부여할 수 있습니다.

이 절에서는 웹 사이트의 파일 및 디렉토리에 대한 액세스를 제한하는 과정에 대해 설명합니다. 모든 서버에 대한 전역 액세스 제어 규칙을 설정할 수도 있고 특정 서버에 대한 개별 규칙을 설정할 수도 있습니다. 예를 들어, 인력 관리 부서에서는 모든 인증된 사용자가 자신의 연봉 데이터를 볼 수 있으나 오직 인력 관리 부서의 연봉을 담당하는 직원만 데이터를 업데이트할 수 있도록 제한하는 ACL을 만들 수 있습니다.

서버가 지원하는 핵심 ACL에는 기본, SSL 및 다이제스트와 같은 세 가지 유형의 인증이 있습니다.

액세스 제어 설정을 편집하려면 다음 작업을 수행하십시오.

1. 구성 탭을 누르고 구성을 선택합니다.

2. 보안 하위 탭 > 액세스 제어 하위 탭을 누릅니다.

3. ACL 추가 버튼을 눌러 새 ACL을 추가하거나 기존 ACL을 눌러 설정을 편집합니다.

액세스 제어 목록(ACL) 추가

다음 절에서는 구성에 새 ACL을 추가하는 과정에 대해 설명합니다.

1. 구성 탭을 누르고 구성을 선택합니다.

2. 액세스 제어 하위 탭 > 액세스 제어 목록 하위 탭을 누릅니다.

3. 새로 만들기 버튼을 눌러 새 ACL을 추가합니다.

다음 매개 변수를 구성합니다.

CLI 사용

CLI를 통해 ACL을 추가하려면 다음 명령을 실행합니다.

wadm> set-acl --user=admin --password-file=admin.pwd 
--host=serverhost --port=8989 --vs=config1_vs_1 --config=config1 
--aclfile=aclfile1

CLI 참조 set-acl(1)을 참조하십시오.

액세스 제어 항목(ACE) 추가

이 절에서는 선택한 구성에 대해 새 액세스 제어 항목(ACE)을 추가하는 과정에 대해 설명합니다.

1. 구성 탭을 누르고 구성을 선택합니다.

2. 액세스 제어 하위 탭 > 액세스 제어 목록 하위 탭을 누릅니다.

3. 새로 만들기 버튼을 누릅니다.

4. 액세스 제어 항목(ACE) 아래에 있는 새로 만들기 버튼을 누릅니다.

다음 ACE 매개 변수를 구성합니다.

.htaccess 파일 사용

서버는 .htaccess 동적 구성 파일을 지원합니다. 사용자 인터페이스를 통해 또는 구성 파일을 직접 변경하여 .htaccess 파일을 사용 가능으로 설정할 수 있습니다.

.htaccess 파일을 서버의 표준 액세스 제어와 함께 사용할 수 있습니다. PathCheck 지시문의 순서에 관계없이 표준 액세스 제어는 모든 .htaccess 액세스 제어에 우선하여 적용됩니다. 사용자 그룹 인증이 "Basic"인 경우에는 사용자 인증에 표준 및 .htaccess 액세스 제어를 모두 요청하면 안 됩니다. 표준 서버 액세스 제어를 통해 SSL 클라이언트 인증을 사용하고 .htaccess 파일을 통해 HTTP "Basic" 인증을 요청할 수도 있습니다.

.htaccess 파일을 사용하도록 설정하면 서버가 자원을 서비스하기 전에 .htaccess 파일을 확인합니다. 서버는 우선 자원과 동일한 디렉토리에서 시작하여 그 상위 디렉토리, 다시 문서 루트까지 .htaccess 파일을 찾습니다. 예를 들어, Primary Document Directory가 /sun/server/docs로 설정되어 있고 클라이언트가 /sun/server/docs/reports/index.html을 요청하는 경우 서버는 /sun/server/docs/reports/.htaccess와 /sun/server/docs/.htaccess에서 .htaccess 파일을 확인하게 됩니다.

참고로 관리자는 서버의 추가 문서 디렉토리와 CGI 디렉토리 기능을 사용하여 대체 문서 루트를 정의할 수 있습니다. 대체 문서 루트가 있으면 .htaccess 파일 처리가 달라집니다. 예를 들어, 서버의 기본 문서 디렉토리는 /sun/server/docs로 설정되고 CGI 프로그램은 /sun/server/docs/cgi-bin/program.cgi에 있는 경우를 가정합니다. CGI를 파일 유형으로 사용 설정하면 클라이언트가 CGI 프로그램을 요청할 때 서버는 /sun/server/docs/.htaccess와 /sun/server/docs/cgi-bin/.htaccess의 내용을 모두 확인합니다. 그러나 대신 CGI 디렉토리를 /sun/server/docs/cgi-bin으로 구성하면 서버가 /sun/server/docs/cgi-bin/.htaccess는 확인하지만 /sun/server/docs/.htaccess는 확인하지 않습니다. 이는 /sun/server/docs/cgi-bin을 CGI 디렉토리로 지정하면 이 디렉토리가 대체 문서 루트가 되기 때문입니다.

서비스 거부 공격 방지

서비스 거부(DoS) 공격은 악의적인 서버 사용자가 합법적인 사용자의 서비스 사용을 방해하려고 시도하는 것입니다. 이러한 공격은 다음과 같은 방법으로 시작될 수 있습니다.

• 특정 웹 자원에 대한 요청을 서버로 계속 보냅니다.

Web Server 는 자주 액세스되는 URI를 모니터하여 요청 빈도가 매우 높은 경우 요청을 거부하여 DoS 공격을 감지할 수 있습니다.

다음 절에서는 가상 서버 수준에서 DoS 공격을 방지할 수 있는 방법에 대해 설명합니다.

서버에 대한 요청 제한

요청 제한을 구성하고 가상 서버당 최대 연결 수를 모니터하여 서버에서 서비스 거부 공격을 방지하도록 조정할 수 있습니다. 이런 값을 몇 개 구성하면 서버 성능에 영향을 줄 수 있습니다.

서버에 대해 요청 제한을 구성하려면 구성 > 가상 서버 > 서버 설정 > 요청 제한을 누릅니다. 다음 표에 나열된 매개 변수를 구성합니다.

CLI 사용

CLI를 통해 서버 요청을 제한하려면 다음 명령을 실행합니다.

wadm> enable-request-limits --user=admin --password-file=admin.pwd 
--host=serverhost --port=8989 --config=config1 --vs=config1_vs_1

CLI 참조 enable-request-limits(1)를 참조하십시오.

최대 연결 수를 제한하는 방법

최대 동시 연결 수를 제한할 수 있습니다. 최소한의 지정된 요청 수를 처리하는 동안 일치하는 요청이 수신되면 요청이 거부됩니다. 요청 거부는 특정 시간에 한하여 이루어집니다. 동시 요청 수가 이 제한보다 작아지면 바로 새 요청을 처리할 수 있게 됩니다.

1. 구성 탭을 누릅니다.

2. 목록에서 구성을 선택합니다.

3. 가상 서버 탭 아래에서 가상 서버를 선택합니다.

4. 서버 설정 > 요청 제한을 누릅니다.

5. 최대 연결 섹션에 값을 입력합니다.