이 섹션은 이 애플리케이션을 사용할 때 발생할 수 있는 일반적인 문제 및 이를 해결하기 위한 지침에 대해 설명합니다. 기술 지원에 문의해야 할 경우 이 섹션을 참고하면 기술 지원에 필요한 정보를 수집하는 데 유용합니다.
보안 콘솔 또는 스캔 엔진과 관련된 문제가 발생하는 경우 문제 해결을 위해 로그 파일을 참조할 수 있습니다. 로그 파일은 또한 정기적인 유지 보수 및 디버깅에도 유용합니다.
이 섹션은 스캔 이벤트와 관련된 스캔 로그에 대해서는 다루지 않습니다. 스캔 로그 확인을 참조하십시오.
로그 파일은 보안 콘솔의 [installation_directory]/nsc/logs 디렉토리와 스캔 엔진의 [installation_directory]/nse/logs에 있습니다. 다음의 로그 파일을 이용할 수 있습니다.
이전 제품 버전에서는 API 정보가 nsc.log에 저장되어 있습니다.
[yyyy-mm-ddThh:mm:ss GMT] [LEVEL] [Thread: NAME] [MESSAGE]
예:
2011-12-20T16:54:48 [INFO] [Thread: Security Console] 보안 콘솔이 12분 54초 내에 시작됩니다.
날짜와 시간은 해당 메시지를 생성하는 이벤트 발생 시점과 일치합니다.
주요 문제를 해결하기 위해 로그 파일을 확인할 때 먼저 ERROR 및 WARN 수준의 메시지를 확인하는 것이 유용할 수 있습니다.
스레드는 해당 메시지를 생성한 프로세스를 식별합니다.
모든 로그 파일은 기본적으로 심각도 수준이 INFO 이상인 메시지를 표시합니다. 따라서 INFO, WARN 및 ERROR 메시지만 표시되며 DEBUG 메시지는 표시되지 않습니다. 로그 파일에 표시될 심각도 수준을 변경할 수 있습니다. 예를 들어 사용자가 심각도 수준이 WARN 및 ERROR가 아닌 모든 메시지를 필터링하기를 원할 수 있습니다. 또는 유지 보수 및 디버깅 용도를 위해 DEBUG 메시지를 포함하기를 원할 수 있습니다.
보안 콘솔과 분산형 스캔 엔진의 구성 단계는 동일합니다. 표시할 로그 심각도 수준을 구성하는 단계:
注意: user-log-settings.xml 파일에서 기본값은 구성 요소가 보안 콘솔에 설치되었는지, 분산형 스캔 엔진에 설치되었는지에 따라 각각 nsc.log 파일 또는 nse.log 파일을 가리킵니다.
<!-- 및 -->:<!-- <property name="default-level" value="INFO"/> -->
<!-- <property name="default-level" value="INFO"/> --><property name="default-level" value="DEBUG"/>
<property name="auth-level" value="DEBUG"/>
<property name="access-level" value="DEBUG"/>
<property name="mem-level" value="DEBUG"/>
변경 사항은 약 30초 후에 적용됩니다.
문제 해결 페이지에서 로그 전송을 클릭하면 스캔 엔진에 의해 생성된 로그를 기술 지원에 전송할 수 있습니다.
注意: 직접 링크를 이용할 수 없는 경우 옵션 SMTP(이메일) 전송 메커니즘도 지원됩니다. 자세한 내용은 기술 지원에 문의하십시오.
로그 전송 방법:
보안 콘솔이 로그 업로드 상자를 표시합니다.
이러한 메시지는 스캔 오류, 지원 사례 또는 비정상적인 시스템 동작에 대한 보고서를 가리킬 수 있습니다.
보안 콘솔에 직접적인 인터넷 액세스가 없는 경우 프록시 서버를 사용해 로그를 기술 지원에 전송할 수 있습니다.
업데이트를 위해 프록시 설정 구성:
관리 페이지가 나타납니다.
보안 콘솔 구성 패널이 나타납니다.
보안 콘솔 구성 패널 - 로그를 기술 지원에 전송하기 위한 프록시 설정
오탐, 부정 오류 또는 잘못된 핑거 프린팅 등 스캔에서 부정확한 결과가 제공된 경우 스캔 로깅 기능을 활용하여 기술 지원팀이 문제를 해결할 수 있도록 돕는 데이터를 수집할 수 있습니다. 자산 구성 내보내기(ACES)는 Windows 레지스트리 키, SSH 명령 실행 및 파일 버전 등 스캔 도중 문제 해결에 유용한 정보를 수집하는 로깅 기능입니다.
다음은 샘플 ACES 로그 파일입니다.
<ace:collected_object>
<ace:source-id>0</ace:source-id>
<ace:thread-activity>do-unix-create-system-fingerprint@example.com:22</ace:thread-activity>
<ace:remote_execution_item id="42">
<ace:command>freebsd-version</ace:command>
<ace:rc datatype="int">0</ace:rc>
<ace:stdin status="does not exist"/>
<ace:stdout>10.0-RELEASE
</ace:stdout>
<ace:stderr status="does not exist"/>
<ace:start_time datatype="int">1443208125966</ace:start_time>
<ace:end_time datatype="int">1443208125982</ace:end_time>
</ace:remote_execution_item>
</ace:collected_object>
이 기능을 활용에는 두 가지 단계가 있습니다.
注意: ACES 로깅이 활성화된 상태에서 개별 자산 또는 소규모 사이트를 스캔하는 것이 좋습니다.
ACES는 자산 구성 내보내기 스캔 템플릿에서 기본으로 활성화됩니다. 그러나 특정 환경에서 보다 나은 성능을 발휘하도록 미세 조정된 사용자 지정 템플릿으로 스캔하는 것도 가능합니다. 사용자 지정 스캔 템플릿에서 ACES를 활성화하는 방법:
注意: 현재 기본 설정에서는 ACES 로깅이 제공되지 않습니다. 그러나 향후 업데이트에서 일부 ACES 로깅 기능이 제공될 예정입니다.
템플릿으로 전체 사이트를 스캔하려면 사이트 구성에 추가한 다음 사이트를 스캔합니다. 스캔 템플릿 선택을 참조하십시오.
注意: ACES 로깅은 상당한 양의 데이터를 수집하며 그로 인해 스캔하려는 자산의 수에 따라 디스크 공간에 영향을 줄 수 있습니다.
템플릿을 사용해 특정 자산을 수동으로 스캔하는 경우 스캔 대화 상자에 템플릿을 추가합니다. 수동 스캔 실행을 참조하십시오.
ACES 로깅을 사용하여 수행된 각 스캔은 스캔 디렉토리에 ACES 데이터 Zip 아카이브로 저장됩니다. 저장 위치:
[installation_directory]/nse/scans/[silo_ID]/[scan_ID]/ACES.zip.
예:
/opt/rapid7/nexpose/nexpose/nse/scans/00000000/0000000000000001$/ACES.zip
특정 스캔 ID를 결정하려면 다음 단계를 따릅니다.
스캔 ID 결정
시스템 성능에 영향을 미칠 수 있는 문제를 파악하기 위해 여러 진단 기능을 실행할 수 있습니다.
애플리케이션 내부 문제에 대한 진단을 실행하는 방법:
보안 콘솔이 문제 해결 페이지를 표시합니다.
요청된 진단이 수행된 후 보안 콘솔이 결과 테이블을 표시합니다. 각 항목은 해당 시스템 구성 요소에 대한 문제가 존재하는지 여부를 나타내는 빨간색 또는 녹색 아이콘을 포함합니다.
시작 시 심각한 하위 시스템 오류가 발생하는 경우, 이 애플리케이션은 이러한 장애를 해결하기 위해 적절한 유지 보수 작업을 대기시키려고 시도합니다. 그다음 애플리케이션은 유지 보수 모드에서 재시작됩니다.
관리자는 애플리케이션에 로그온하여 장애 원인을 검사할 수 있습니다. 필요한 경우, 해당 문제를 해결하기 위해 특정한 조치를 취할 수 있습니다.
실행할 수 있는 두 가지 유형의 복구 작업:
이 애플리케이션은 매우 심각한 장애가 발생했을 때 유지 보수 웹 서버에 기본 포트 3780이 없는 경우 유지 보수 모드에서 재시작하지 못할 수 있습니다. 이는 이러한 포트를 실행하는 인스턴스가 이미 있거나 하나 이상의 키 구성 파일이 없거나 유효하지 않을 때 발생할 수 있습니다. 이러한 파일은 .nsc, .xml 및 .userdb와 같은 확장자를 가질 수 있습니다.
웹 인터페이스 세션이 유휴 세션에서 시간 초과한 경우, 보안 콘솔은 사용자가 세션을 새로 고칠 수 있도록 로그온 창을 표시합니다. 웹 브라우저와 보안 콘솔 웹 브라우저 간의 통신 문제로 인해 세션을 새로 고칠 수 없는 경우 오류 메시지가 나타납니다. 사용자가 작업을 저장하지 않은 경우 통신 문제가 해결된 후 작업이 손실되지 않도록 페이지를 종료하거나 브라우저를 닫아서는 안 됩니다.
통신 장애는 다음과 같은 원인 중 하나로 인해 발생할 수 있습니다. 이러한 원인으로 장애가 발생한 경우 다음과 같이 적절한 조치를 수행하십시오.
보안 콘솔이 사용자의 세션 새로 고침 요청에 응답하는 데 너무 많은 시간이 소요되는 경우에도 오류 메시지가 나타날 수 있습니다.
잘못된 암호를 통한 로그온 시도가 너무 많이 발생한 경우, 이 애플리케이션은 해당 사용자에 대한 잠금이 재설정될 때까지 이 사용자를 잠급니다.
기본 잠금 임계값은 4번의 로그온 시도입니다. 글로벌 관리자는 이 매개 변수를 보안 콘솔 구성 — 웹 서버 페이지에서 변경할 수 있습니다. 보안 콘솔 웹 서버 기본 설정 변경을 참조하십시오.
잠금을 재설정할 수 있는 세 가지 방법:
계정 잠금 해제를 실행합니다. 명령 콘솔 사용을 참조하십시오.스캔에 너무 많은 시간이 걸리거나 스캔이 완전히 중단된 것처럼 보이는 경우가 발생할 수 있습니다.
스캔에 얼마만큼의 시간이 걸릴지 정확히 예측할 수는 없습니다. 스캔 시간은 대상 자산의 수, 스캔 템플릿이 얼마나 세부적인지 또는 복잡한지와 같은 요인에 따라 달라집니다. 하지만 스캔 시간을 이전 스캔에 소요된 시간과 비교하여 스캔 완료에 비정상적으로 오랜 시간이 걸리는지를 확인할 수 있습니다.
일반적으로 단일 호스트에서 스캔 실행에 8시간이 넘게 소요되거나 해당 사이트에서 48시간이 넘게 소요되는 경우, 특정한 문제가 있는지 확인할 필요가 있습니다.
스캔을 시작, 일시 중지, 재시작 또는 중지하려고 할 때 해당 작업이 진행 중이라는 메시지가 오랫동안 나타나는 경우, 이는 보안 콘솔이 스캔 엔진과 통신할 때의 네트워크 관련 지연으로 인한 현상일 수 있습니다. 대역폭이 낮거나 대기 시간이 긴 네트워크의 경우, 보안 콘솔/스캔 엔진 통신에서 시간 초과가 빈번하게 발생해 보안 콘솔의 스캔 상태 정보 수신이 지연됨으로써 스캔 작업이 지연될 수 있습니다. 시간 초과를 줄이기 위해 스캔 엔진 응답 시간 제한 설정을 높일 수 있습니다. 보안 콘솔과 분산형 스캔 엔진의 연결 구성을 참조하십시오.
메모리 관련 문제로 인해 스캔이 지연되거나 실패할 수 있습니다. 메모리 부족 문제를 참조하십시오.
이 애플리케이션은 취약점 검사를 실행하기 전에 검색되는 모든 대상 호스트의 포트를 스캔합니다. 대상 포트의 범위는 구성이 가능한 스캔 템플릿 설정입니다. 스캔 시간은 스캔 포트의 수에 비례해 증가합니다.
특히 대부분의 네트워크 디바이스의 TCP/IP 스택에 내장된 ICMP 속도 제한 메커니즘을 트리거하지 않기 위해 이 애플리케이션이 초당 전송하는 UDP 패킷은 기본적으로 최대 2개로 제한되므로 UDP 포트 스캔에 많은 시간이 걸릴 수 있습니다.
스캔 속도를 높이려면 잘 알려진 포트 또는 관련 서비스를 호스팅하는 것으로 알려진 특정한 포트만 검사하도록 스캔을 구성하는 방식을 고려하십시오. 스캔 템플릿 이용 및 스캔 성능 조정을 참조하십시오.
스캔 시 스캔 엔진이 오프라인 상태가 되면 스캔이 중단된 것처럼 보일 수 있습니다. 스캔 시 스캔 엔진이 오프라인 상태가 될 때 데이터베이스는 완료되지 않은 스캔에서 데이터를 삭제해야 합니다. 이러한 프로세스는 다음의 스캔 로그와 비슷한 메시지를 남깁니다.
DBConsistenc3/10/09 12:05 PM: 전송된 스캔 ID 410에 대한 불일치 발견, 부분적으로 가져온 스캔 결과 삭제...
스캔 엔진이 오프라인 상태가 되면 엔진을 재시작합니다. 그다음 스캔 엔진 구성 패널로 이동해 스캔 엔진이 활성 상태인지 확인합니다. 분산형 스캔 엔진 구성을 참조하십시오.
진행 중이거나 완료된 스캔에 대한 작업 로그를 확인할 수 있습니다.
스캔 로그 확인 방법:
콘솔이 스캔 로그를 표시합니다.
다른 사용자가 스캔을 중지한 경우 스캔이 중단된 것처럼 보일 수 있습니다. 이를 확인하려면 다음과 비슷한 메시지에 대한 로그를 확인합니다.
Nexpose3/16/09 7:22 PM: 스캔 [] 중지: "maylor" <>
스캔 로그 확인을 참조하십시오.
보고서 생성에 너무 많은 시간이 걸리거나 이러한 작업이 완전히 중단된 것처럼 보이는 경우가 발생할 수 있습니다. 보안 콘솔 로그에서 보고 오류를 검색할 수 있습니다.
메모리 관련 문제로 인해 보고서 생성이 지연되거나 실패할 수 있습니다. 메모리 부족 문제를 참조하십시오.
데이터베이스 속도는 보고 속도에 영향을 미칩니다. 시간이 지나면서 이전 스캔의 데이터가 데이터베이스에 누적됩니다. 이로 인해 데이터베이스 속도가 저하됩니다.
보고 작업 속도가 저하된 경우, 다음의 예와 같이 보안 콘솔 로그에서 다른 보고 작업의 기간과 일치하지 않는 보고 작업을 확인합니다.
nsc.log.0:Reportmanage1/5/09 3:00 AM: 보고 작업 serviceVulnStatistics가 2시간 1분 23초 내에 완료
많은 경우, 데이터베이스를 정리하면 보고서 생성 속도를 높일 수 있습니다. 정기적인 데이터베이스 유지 보수 작업을 통해 남아 있는 스캔 데이터 및 호스트 정보를 삭제할 수 있습니다. 스캔 로그 확인, 데이터베이스 백업/복구 및 데이터 보존을 참조하십시오.
스캔 및 보고는 메모리 사용이 많은 작업이므로 이러한 작업과 관련된 오류는 메모리 문제인 경우가 많습니다. 설정을 변경하며 메모리 사용을 조절할 수 있습니다. 몇몇 메모리 문제는 시스템 리소스 조절 방식과 관련됩니다.
애플리케이션 장애가 발생한 경우, 다음의 메시지에 대한 로그 파일을 확인해 메모리 부족이 장애의 원인인지 확인할 수 있습니다.
java.lang.OutOfMemoryError: Java 힙 공간
이 메시지가 나타나면 기술 지원에 문의하십시오. 지시가 없는 한 애플리케이션을 재시작하지 마십시오.
스캔은 메모리 사용이 많으며 빈번하게 수행되는 작업이므로 메모리 문제가 스캔 성능에 영향을 미치지 않도록 스캔이 사용하는 메모리의 양을 조절해야 합니다. 메모리 제한이 스캔에 영향을 미치지 않도록 하기 위한 전략은 여러 가지가 있습니다.
대상 호스트가 수의 증가하면 스캔 정보를 저장하는 데 필요한 메모리의 양도 증가합니다. 스캔하는 호스트에 있는 취약점의 수가 너무 많은 경우, 메모리 부족으로 인해 스캔이 중단될 수 있습니다.
해당 스캔의 복잡성을 줄이기 위한 방법:
한 번의 스캔에 포함되지 않은 모든 취약점에 패치를 적용한 후 제외된 IP 주소 또는 취약점을 사이트 구성에 추가하고 스캔을 다시 실행합니다.
자세한 내용은 분산형 스캔 엔진 구성, 스캔 템플릿 이용 및 스캔 성능 조정을 참조하십시오.
여러 스캔을 동시에 실행하면 보안 콘솔 메모리가 부족해질 수 있습니다. 메모리를 보존하기 위해 동시 스캔의 수를 줄이십시오.
스캔 메모리 부족 문제가 계속 발생하는 경우 서버에 메모리를 추가할 수 있습니다. 메모리를 추가하려면 서버 운영 체제에도 업그레이드가 필요할 수 있습니다. 64비트 운영 체제에서는 32비트 운영 체제에서 실행될 때보다 애플리케이션이 더 많은 메모리를 처리할 수 있습니다. 하지만 64비트 운영 체제에서 애플리케이션을 실행하려면 8Gb의 메모리가 필요합니다.
메모리 효율적인 스캔 실행 방법에 대한 자세한 내용을 참고할 수 있는 챕터:
시스템 업데이트가 실패하는 경우가 발생할 수 있습니다. 시스템 로그를 확인해 그 원인을 파악할 수 있습니다.
이 애플리케이션은 이전에 적용된 업데이트를 업데이트 테이블에서 추적합니다. 이러한 업데이트 테이블이 손상되면 이 애플리케이션은 다운로드 및 적용할 업데이트를 파악할 수 없습니다.
손상된 업데이트 테이블로 인해 업데이트를 설치할 수 없는 경우 스캔 콘솔 로그에 다음과 비슷한 메시지가 저장됩니다.
AutoUpdateJo3/12/09 5:17 AM: NSC 업데이트 실패: com.rapid7.updater.UpdateException: java.io.EOFException
지점 com.rapid7.updater.UpdatePackageProcessor.getUpdateTable(알 수 없는 소스)
지점 com.rapid7.updater.UpdatePackageProcessor.getUpdates(알 수 없는 소스)
지점 com.rapid7.updater.UpdatePackageProcessor.getUpdates(알 수 없는 소스)
지점 com.rapid7.nexpose.nsc.U.execute(알 수 없는 소스)
지점 com.rapid7.scheduler.Scheduler$_A.run(알 수 없는 소스)
이러한 문제가 발생하는 경우 기술 지원에 문의하십시오. 스캔 로그 확인을 참조하십시오.
이 애플리케이션은 기본적으로 업데이트를 자동으로 다운로드하고 설치합니다. 애플리케이션이 업데이트를 다운로드했지만 설치가 실패하는 경우가 발생할 수 있습니다.
스캔 로그를 확인해 이 문제가 발생했는지 확인할 수 있습니다.
오랫동안 비활성 상태로 나타난 업데이트 시간 스탬프를 확인합니다.
AU-BE37EE72A11/3/08 5:56 PM: 파일 업데이트: nsc/htroot/help/html/757.htm
NSC 11/3/08 9:57 PM: 로깅 초기화(시스템 시간대 SystemV/PST8PDT)
지금 업데이트 명령 프롬프트를 사용해 업데이트를 수동으로 재시도하는 방법:
명령 콘솔 페이지가 나타납니다.
지금 업데이트 명령을 입력하고 실행을 클릭합니다. 보안 콘솔이 업데이트가 성공했는지 여부를 알려주는 메시지를 표시합니다. 스캔 로그 확인을 참조하십시오.
손상된 파일로 인해 애플리케이션이 업데이트를 수행할 수 없는 경우 스캔 콘솔 로그에 다음과 비슷한 메시지가 저장됩니다.
AU-892F7C6793/7/09 1:19 AM: 업데이트 id 919518342 적용
AU-892F7C6793/7/09 1:19 AM: zip 파일 열기 오류
AutoUpdateJo3/7/09 1:19 AM: NSC 업데이트 실패: com.rapid7.updater.UpdateException:
java.util.zip.ZipException: zip 파일 열기 오류
지점 com.rapid7.updater.UpdatePackageProcessor.B(알 수 없는 소스)
지점 com.rapid7.updater.UpdatePackageProcessor.getUpdates(알 수 없는 소스)
지점 com.rapid7.updater.UpdatePackageProcessor.getUpdates(알 수 없는 소스)
지점 com.rapid7.nexpose.nsc.U.execute(알 수 없는 소스)
지점 com.rapid7.scheduler.Scheduler$_A.run(알 수 없는 소스)
손상된 파일로 인해 업데이트가 실패한 경우, 업데이트 파일이 다운로드되었지만 해당 파일이 유효하지 않은 것입니다. 이러한 문제가 발생하는 경우 기술 지원에 문의하십시오. 스캔 로그 확인을 참조하십시오.
보안 콘솔과 업데이트 서버 간의 연결을 설정할 수 없는 경우 다음과 비슷한 메시지가 로그에 나타납니다.
AU-A7F0FF3623/10/09 4:53 PM: 업데이트 다운로드: 919518342
AutoUpdateJo3/10/09 4:54 PM: NSC 업데이트 실패: java.net.SocketTimeoutException
java.net.SocketTimeoutException은 업데이트 서버로 연결을 설정할 수 없다는 것을 나타냅니다. 연결이 중단된 경우, 실패한 업데이트 이전의 다른 업데이트는 성공한 것입니다.
지금 업데이트 명령 프롬프트를 사용해 업데이트를 수동으로 재시도하는 방법. 중단된 업데이트, 스캔 로그 확인을 참조하십시오.