자산 검색 구성의 3가지 옵션:
맞춤 지정한 스캔 템플릿에서 자산 검색을 구성하지 않기로 선택하는 경우, 스캔은 서비스 검색을 통해 시작됩니다.
대상 자산이 활성 자산인지 확인하면 많은 수의 자산이 있어 추적이 쉽지 않은 환경에 유용합니다. 스캔 작업을 통해 비활성 자산을 필터링하면 스캔 시간을 단축하고 리소스를 절약할 수 있습니다.
자산에 액세스하는 3가지 방법:
이 경우 방화벽 또는 기타 보안 디바이스가 검색 연결 요청을 차단해, 활성화된 자산이 비활성화된 것처럼 보이는 문제가 발생할 수 있습니다. 방화벽은 특정한 기준에 해당하는 모든 패킷에 대한 네트워크 액세스를 차단하거나 모든 스캔을 잠재적인 해킹으로 간주하도록 구성되기 때문에 네트워크에 방화벽이 설정되면 연결 요청이 차단될 수 있습니다. 어떠한 경우든 애플리케이션은 스캔 로그에 자산을 비활성으로 보고합니다. 따라서 전반적인 스캔 정확성이 감소할 수 있습니다. 따라서 스캔 엔진 구축 위치 그리고 스캔 엔진과 방화벽과의 관계를 고려해야 합니다. “스캔에 적합한” 환경 구축을 참조하십시오.
여러 검색 방법을 사용하면 결과의 정확성이 향상됩니다. 애플리케이션이 특정한 방법으로 자산이 활성 자산인지 확인할 수 없는 경우, 다른 방법을 사용할 수 있습니다.
注意: 웹 감사 및 인터넷 DMZ 감사 템플릿에는 이러한 검색 방법 중 어떤 것도 포함되지 않습니다.
주변 네트워크에는 일반적으로 매우 강력한 방화벽이 구축되어 있어, 자산 검색의 효과가 감소합니다. 따라서 이러한 유형의 스캔을 위해 애플리케이션이 대상 자산을 활성으로 "간주"하고 스캔 다음 단계인 서비스 검색을 수행하는 것이 더욱 효율적입니다. 이 경우 애플리케이션이 자산의 활성 유무와 상관없이 모든 대상 자산에서 포트를 검사하므로 이 방법에는 많은 시간이 걸립니다. 반면 모든 가능한 대상을 검사하므로 정확성은 향상됩니다.
스캔 엔진은 디바이스 검색 시 자산을 검색하기 위해 기본적으로 에코 요청 또는 ping으로 알려진 메시지 유형을 포함하는 ICMP 프로토콜을 사용합니다. 방화벽은 특정한 기준에 해당하는 모든 패킷에 대한 네트워크 액세스를 차단하거나 모든 스캔을 잠재적인 해킹으로 간주하도록 구성되기 때문에 ping을 삭제할 수 있습니다. 어떠한 경우든 애플리케이션은 디바이스가 존재하지 않는 것으로 간주하고 스캔 로그에 자산을 비활성으로 보고합니다.
注意: 디바이스 검색에 TCP와 UDP를 모두 선택하면 1개의 프로토콜을 선택할 때보다 애플리케이션이 더 많은 패킷을 전송하므로 네트워크 대역폭 사용이 증가합니다.
TCP 및/또는 UDP를 활성 호스트를 검색하기 위한 추가 또는 대체 옵션으로 선택할 수 있습니다. 이러한 프로토콜을 통해 애플리케이션은 연결을 개시하여 온라인에서 자산의 존재를 확인하려고 시도합니다. 방화벽은 주로 웹 서비스를 지원하는 기본 HTTP 포트인 포트 80에서 트래픽을 허용하도록 구성됩니다. 포트 80에 아무것도 등록되어 있지 않으면, 대상 자산이 스캔 엔진에 “포트 닫힘” 응답을 보내거나 응답을 보내지 않습니다. 이는 자산이 온라인 상태이며 포트 스캔이 발생할 수 있음을 나타냅니다. 이 경우 애플리케이션은 스캔 로그에 자산을 활성으로 보고합니다.
디바이스 검색에 TCP 또는 UDP를 선택하는 경우 대상 자산에서 실행되는 서비스 및 운영 체제에 따라 포트 80 이외에 추가 포트를 지정하십시오. 일반적으로 사용되는 포트 번호를 파악하기 위해 검색 스캔(Discovery scan) 및 검색 스캔(Discovery scan, Aggressive)과 같은 기본 스캔 템플릿에서 TCP 및 UDP 포트 설정을 확인할 수 있습니다.
대상 자산에서 응답을 수신하는 기능은 TCP가 UDP보다 신뢰성이 높습니다. 또한 UDP보다 TCP를 사용하는 서비스가 더 많습니다. 한편 대상 디바이스가 보다 일반적인 TCP 및 ICMP 패킷을 차단할 가능성이 높기 때문에 UDP를 보완적인 프로토콜로 사용할 수 있습니다.
스캔 대상이 사이트 구성의 호스트 이름 목록에 있는 경우, 애플리케이션이 DNS 해결을 시도합니다. 해결할 수 없는 호스트 이름은 해결되지 않음으로, 즉 스캔의 목적에서 볼 때 비활성으로 간주됩니다.
UDP는 TCP와는 달리 데이터 무결성 및 순서를 확인할 수 있는 TCP의 핸드세이킹을 사용하지 않으므로 자산 검색 프로토콜로서 TCP보다 신뢰성이 낮습니다. TCP와 달리, UDP 포트는 통신 시도에 응답하지 않으면, 일반적으로 개방되어 있는 것으로 간주됩니다.
자산 검색은 정확성을 개선할 수 있는 효율적인 방법입니다. 또한 자산 검색을 사용하지 않으면 스캔 시간이 증가할 수 있습니다. 이 애플리케이션은 활성 상태로 확인된 자산만 스캔합니다. 그 외의 자산에 대한 스캔은 생략합니다. 예를 들어 스파스(sparse) 클래스 C 네트워크에 50개의 활성 호스트가 있는 것으로 확인한 다음에는 불필요한 포트 스캔을 생략할 수 있습니다.
애플리케이션과 대상 네트워크 간에 ICMP 에코 요청과 응답 패킷의 통신을 허용하도록 ICMP를 설정하고 방화벽을 구성하는 것이 좋습니다.
내부 네트워크에 엄격한 방화벽 규칙이 있는 경우 자산 검색을 위해 TCP도 설정해야 합니다. UDP 사용 시 UDP 포트의 신뢰성 문제로 인해 많은 비용이 들 수 있습니다. 정확성 및 시간상의 이점을 비교하여 UDP 포트 사용 여부를 결정하십시오.
어떠한 검색 방법도 선택하지 않은 경우, 스캔은 모든 대상 자산을 활성으로 간주하고 즉시 서비스 검색을 시작합니다.
애플리케이션이 자산 검색을 위해 TCP 또는 UDP 방식을 사용하는 경우 특정한 포트에 요청 패킷을 전송합니다. 애플리케이션이 포트에 접속하고 포트가 개방되었다는 응답을 수신하면 애플리케이션은 호스트가 “활성”이라고 보고하고 호스트를 스캔합니다.
PCI 감사 템플릿은 검색을 위한 추가적인 TCP 포트를 포함합니다. PCI 스캔 시, 모든 활성 자산을 스캔해야 합니다.
취약점 검사를 수행하기 전에 검색된 자산 및 검색된 네트워크에 대한 특정한 정보를 수집할 수 있습니다. 이러한 모든 검색 설정은 옵션 사항입니다.
이 애플리케이션은 DNS 및 WINS 서버를 쿼리해 스캔이 가능한 기타 네트워크 자산을 검색할 수 있습니다.
Microsoft는 NT 3.5의 LAN 관리자 환경에서 이름 해결을 위한 WINS(Windows Internet Name Service)를 개발했습니다. 이 애플리케이션은 이 브로드캐스트 프로토콜을 조사해 Windows 워크스테이션 및 서버 이름을 검색할 수 있습니다. 일반적으로 WINS가 필요하지는 않습니다. WINS는 원래 NETBIOS 이름의 IP 주소로의 변환을 지원하기 위한 시스템 데이터베이스 애플리케이션으로서 개발되었습니다.
기타 네트워크 자산을 검색하는 옵션을 설정하면, 이 애플리케이션은 모든 지원되는 자산의 IP 주소에 대한 DNS 및 WINS 서버를 검색하고 조사합니다. 여기에는 스캔 시스템 목록에 있는 자산이 포함됩니다.
注意: Whois는 내부 RFC1918 주소에 사용할 수 없습니다.
Whois는 개체 이름과 같은 IP 주소 관련 정보를 수집하는 인터넷 서비스입니다. Whois 서버를 네트워크에서 이용할 수 없는 경우 스캔 엔진 성능 향상을 위해 모든 발견된 자산에 대해 Whois 서버의 조사를 요청하지 않을 수 있습니다.
이 애플리케이션은 IP 핑거 프린팅이라고 불리는 방법을 통해 검색된 자산에 대한 최대한의 세부 정보를 파악합니다. 자산의 IP 스택을 스캔하여 자산의 하드웨어, 운영 체제 및 시스템에서 실행되는 애플리케이션에 대한 정보를 파악할 수 있습니다. IP 핑거 프린팅 관련 설정은 성능의 정확도에 영향을 미칩니다.
재시도 설정은 애플리케이션이 IP 스택 핑거 프린팅 시도를 반복하는 횟수를 지정합니다. 기본 재시도 값은 0입니다. IP 핑거 프린팅에는 자산당 최대 1분이 소요됩니다. IP 스택을 처음에 핑거 프린팅할 수 없는 경우, 두 번째 시도는 하지 않는 것이 좋을 수 있습니다. 하지만 IP 핑거 프린팅 재시도 횟수를 원하는 대로 설정할 수는 있습니다.
IP 핑거 프린팅 설정 여부와 상관없이, 애플리케이션은 포트 스캔의 서비스 데이터 분석과 같은 기타 핑거 프린팅 방법을 사용합니다. 예를 들어 대상 자산에서 IIS(Internet Information Service)를 검색함으로써 이 자산이 Windows Web 서버임을 확인할 수 있습니다.
0.0~1.0 범위인 확신도 값은 자산 핑거 프린팅의 확실성을 반영합니다. 특정 핑거 프린팅이 최소 확신도 값보다 작으면, 애플리케이션은 해당 자산의 IP 핑거 프린팅 정보를 삭제합니다. 이러한 설정은 자산 검색과 관련된 성능 설정과 함께 모범 사례를 바탕으로 신중하게 정의되므로 이와 같은 설정들은 모두 동일합니다.
검색된 자산 관련 정보 수집 구성 단계:
권한 없는 MAC 주소를 취약점으로 보고하도록 스캔을 설정할 수 있습니다. MAC(Media Access Control) 주소는 네트워크의 각 노드를 고유하게 식별하는 하드웨어 주소입니다.
IEEE 802 네트워크에서 OSI 참조 모델의 DLC(Data Link Control) 계층은 두 가지 하위 계층인 LLC(Logical Link Control) 계층과 MAC(Media Access Control) 계층으로 나눌 수 있습니다. MAC 계층은 네트워크 미디어와 직접 접속됩니다. 각 네트워크 미디어 유형에 필요한 MAC 계층은 서로 다릅니다. IEEE 802 표준을 충족하지는 않지만 OSI 참조 모델을 충족하는 네트워크의 노드 주소는 DLC(Data Link Control) 주소라고 부릅니다.
안전한 환경에서 특정 기기만 네트워크에 접속하도록 설정할 필요가 있을 수 있습니다. 권한 없는 MAC 주소를 감지하기 위해 필요한 특정한 조건:
MAC 주소를 수집하기 위해 애플리케이션이 인증된 스캔을 수행하도록, 설정하는 단계:
콘솔이 해당 사이트에 대한 사이트 구성 패널을 표시합니다.
콘솔이 새 로그인 박스를 표시합니다.
자격 증명 구성에 대한 자세한 내용은 스캔 자격 증명 구성을 참조하십시오.
자격 증명 페이지에 새 로그온 정보가 나타납니다.
신뢰할 수 있는 MAC 주소 목록 생성 단계:
Windows에서의 설치 시 기본 경로:
C:Program Files\[installation_directory]\plugins\java\1\NetworkScanners\1\[file_name]
Linux 사용 시 기본 경로:
/opt/[installation_directory]/java/1/NetworkScanners/1/[filename]
스캔 템플릿에 권한 없는 MAC 주소 보고를 설정하는 단계:
신뢰할 수 있는 MAC 파일이 생성되고 스캔 값이 설정되면 애플리케이션이 신뢰할 수 있는 MAC 취약점 테스트를 수행합니다. 이를 위해 애플리케이션은 대상 자산에 ARP 요청을 보내 MAC 주소를 수집합니다. 또한, 세그먼트를 관리하는 라우터 또는 스위치에서 ARP 테이블을 검색합니다. 그다음 SNMP를 사용해 자산의 MAC 주소를 검색하고 NetBIOS 이름을 통해 자산을 조사하여 MAC 주소를 검색합니다.