RAID Forensics (Hardware RAID vs. Software RAID, Acquistion)
RAID(Redundant Array of Independent Disks)는 앞서 간단히 살펴보았다.
2010/07/06 – [Storage Forensics] – RAID 소개 및 레벨 (RAID Levels)
여기서는 RAID의 두 가지 큰 흐름인 하드웨어 RAID와 소프트웨어 RAID를 비교해 보고 각 경우에 디지털 증거 수집 방안에 대해서 살펴본다.
RAID는 여러 개의 디스크를 묶어 하나의 큰 볼륨으로 사용하고자 하는 것이다. 단순히 큰 용량으로 늘리는 것은 디스크 스패닝(Disk Spanning)을 의미하는 것이고, RAID는 이와 더불어 데이터의 신뢰성(Reliability)과 성능(Performance) 향상이 주 목적이다. RAID는 크게 크게 하드웨어 방식과 소프트웨어 방식으로 나눌 수 있다.
1. 하드웨어 RAID
하드웨어 RAID는 RAID 기능(볼륨 생성, 패리티 계산, write-back 등)을 하드웨어로 구현한 것이다. 따라서 RAID 기능을 수행하는 응용프로그램이 하드웨어적으로 구현되어 독자적인 프로세서와 메모리를 가지고 있다. 하드웨어 RAID도 구현 방식에 따라 별도의 카드(add-in card)를 사용하는 경우와 모든 기능을 하나의 칩에 넣은 ROC(RAID-on-Chip) 방식이 있다.
하드웨어 RAID는 독립적으로 구성되기 때문에 컨트롤러와 통신하기 위해서는 OS에 적절한 드라이버가 필요하다. 다음 그림은 하드웨어 RAID의 구성에 대해 간략히 보여준다.

위 그림과 같이 여러 개의 디스크는 RAID 컨트롤러에 의해 하나 이상의 RAID 볼륨으로 재구성된다. OS 입장에서는 개별 디스크가 아닌 RAID 볼륨을 하나의 디스크처럼 사용한다. 이와 같은 구성의 장점은 OS 입장에서는 단지 RAID 볼륨에서 데이터를 읽고 쓰기만 하면 된다. 각 RAID 타입에 따라 중복된 쓰기와 읽기 처리, 패리티 비트 계산 등의 RAID 기능에 대한 처리는 컨트롤러에서 알아서 해준다.
하드웨어 RAID 구현 방식은 여러가지가 있지만 크게 독립된 RAID 컨트롤러 카드를 이용한 구현 방식과 ROC(RAID-On-Chip)를 이용한 구현 방식이 있다.
1) 독립된 RAID 컨트롤러 카드를 이용한 구현
이 방식은 확장 카드(expansion card)를 이용하여 구현하는 방식으로 독립된 RAID 프로세서 (I/O 프로세서), 컨트롤러 (I/O 컨트롤러), 메모리를 가지고 있다. 보통 메인보드(M/B)에 PCI-X나 PCIe 확장 슬록에 장착된다. 별도의 확장 슬록에 프로세서가 들어가기 때문에 이 방식의 카드는 비교적 비싸다. 하지만 CPU 없이 독립적인 입출력 처리가 가능하므로 시스템에 아무런 영향을 주지 않고 최적의 성능을 낼 수 있다.
그리고 각각의 디스크는 컨트롤러 카드에만 영향을 받고 호스트의 영향을 받지 않는다. 따라서 새로운 시스템으로 이전하거나 저장용량 확장의 경우에도 호스트와 무관하게 이전 및 확장이 가능하다.
다음은 독립된 RAID 컨트롤러 카드를 이용할 경우에 특징이다.
- 볼륨이 독립적으로 동작하므로 부트 드라이브의 에러나 부팅 시 일어나는 악의적인 행위로부터 보호될 수 있다.
- 독립적인 I/O 프로세서와 메모리를 가지고 있어 호스트 시스템에 영향을 주지 않으므로 최적의 성능을 낼 수 있다.
- RAID 응용프로그램이 호스트에 영향을 받지 않으므로 시스템이 고장난 경우에도 영향이 없다.
- 비휘발성 하드웨어와 전원 유지로 갑작스런 시스템 전원이 손실된 경우에도 데이터의 쓰기 작업이 보장된다.
- 호스트와 독립적이므로 바이러스에 비교적 취약하지 않다.
- 카드 방식이기 때문에 다른 시스템으로의 이전이나 업그레이드가 비교적 쉽다.
- 컨트롤러 캐싱(caching)을 통해 후 기록(write-back)이 가능하다.
2) RAID-On-Chip에 기반한 통합 하드웨어 솔루션
ROC는 RAID 프로세서, 메모리 컨트롤러, 호스트 인터페이스, I/O 인터페이스, 메모리 등이 하나의 칩(Chip)에 모두 구현된 형태이다. 단일 칩 형태이기 때문에 메인보드나 다른 하드웨어 장치와 통합될 수 있다. ROC 칩은 기존의 I/O 인터페이스 칩(SCSI 컨트롤러 칩 등)과 교체될 수 있다. 단일 칩에 모든 기능을 구현했기 때문에 비용면에서 별도의 컨트롤러 카드를 사용한 것보다 저렴할 수 있다.
ROC 기반의 하드웨어 RAID는 다음과 같은 특징이 있다.
- 호스트와 독립적으로 동작하므로 부트 드라이브의 에러나 부팅 시 일어나는 악의적인 행위로부터 보호될 수 있다.
- RAID 응용프로그램이 호스트에 영향을 받지 않으므로 시스템이 고장난 경우에도 영향이 없다.
- 비휘발성 하드웨어와 전원 유지로 갑작스런 시스템 전원이 손실된 경우에도 데이터의 쓰기 작업이 보장된다.
- 호스트와 독립적이므로 바이러스에 비교적 취약하지 않다.
- 컨트롤러 캐싱(caching)을 통해 후 기록(write-back)이 가능하다.
- 기존 하드웨어 장비에 장착되어있기 때문에 다른 시스템으로의 이전이 쉽지 않다.
2. 소프트웨어 RAID
소프트웨어 RAID는 RAID 기능이 소프트웨어로 구현된 것이다.

위 그림과 같이 RAID 소프트웨어는 OS에 포함되어 있다. 따라서 사용자는 볼륨만 확인할 수 있다. 각 디스크에 접근하기 위해서는 유닉스의 저수준 장치를 통해 접근하거나 윈도우의 저수준 API를 통해 접근 가능하다. RAID 기능을 제공하는 운영체제는 윈도우 NT, 2000, XP, Vista, 7, 애플 OS X, 리눅스, 솔라리스, HP-UX, IBM AIX 등이 있다. 소프트웨어 RAID가 동작하기 위해서는 CPU의 자원을 사용하기 때문에 하드웨어 RAID에 비해 성능에 제약이 있다.
윈도우 NT, 2000, XP, Vista, 7의 경우에는 LDM(Logical Disk Manager)에 의해 RAID 기능이 지원된다. LDM으로 관리되기 위해서는 저장매체를 동적디스크(dynamic disk)로 포맷해야 한다. 리눅스의 경우에는 MD(Multiple Device) 커널 드라이버로 RAID 기능이 지원된다. 설정은 /etc/raidtab에서 가능하다.
소프트웨어 RAID의 경우 RAID 기능 처리는 모두 CPU가 담당한다. 따라서 패리티 계산과 같은 많은 처리를 요하는 RAID 구성은 적절치 않다. RAID 구성의 신뢰성과 성능 향상이 호스트에게는 성능 하락으로 나타나면 안되기 때문이다. 그래서 대부분의 소프트웨어 RAID는 RAID 기능 처리에 부담이 되지 않는 RAID 0, RAID1 방식만 지원한다. 최근에는 RAID 5도 지원하기는 하지만 호스트 성능이 매우 좋지 않다면 추천하고 싶지는 않다.
소프트웨어 RAID의 경우에도 순수 소프트웨어로 구현한 방식과 하이브리드(Hybrid) 구현 방식이 있다.
1) 순수 소프트웨어 구현 방식
하드웨어 없이 오로지 소프트웨어로만 구현된 방식이다. 각 드라이브의 I/O 인터페이스나 HBA(Host Bust Adapter)을 사용하여 동작하게 된다. 그리고 RAID 소프트웨어는 부팅 후 운영체제에 로드된다. 별도의 하드웨어 없이 소프트웨어로만 구현되었기 때문에 하드웨어 구현 방식에 비해 비용이 저렴하다.
순수 소프트웨어 구현 방식은 다음과 같은 특징을 가진다.
- 소프트웨어로 동작하므로 비용이 저렴하다.
- RAID 소프트웨어가 로드되기 전인 부팅 시 일어나는 데이터의 손실이나 에러에 대해 취약하다.
- 동작을 위해 CPU 자원을 사용하므로 호스트의 성능을 제한한다.
- 소프트웨어로 동작하므로 상대적으로 바이러스에 취약하다.
- 호스트 시스템의 고장으로 인해 데이터의 무결성이 훼손될 수 있다.
- 후 기록(write-back)을 위한 캐시가 없고 추가적인 배터리도 추가하기 어렵다.
2) 하이브리드 모델 (Hybrid Model; Hardware-Assisted Software RAID)
순수한 소프트웨어 방식이 데이터 무결성에 취약하기 때문에 이를 보완하기 위해 하드웨어의 도움을 받는 방식이다. 엄밀히 말하면 하이브리드이지만 RAID의 기능은 실제 소프트웨어로 동작하기 때문에 소프트웨어 방식으로 보는 것이 적절할 것이다. 하드웨어의 도움을 받는 다는 것은 메인보드 등의 별도로 구현된 RAID BIOS의 도움을 받는 것이다.
BIOS에 구현되어 있기 때문에 부팅 되기 전 BIOS Setup 유틸리티에 의해 동작이 가능하다. 따라서 부팅 전에 발생하는 시스템의 에러에도 기존 모델보다 효과적인 대처가 가능하다. 그리고 다양한 드라이버를 포함할 수 있기 때문에 기존 모델보다 운영체제와 독립적이다.
하이브리드 모델은 다음과 같은 특징을 가진다.
- 부팅 시 일어나는 부트 드라이브의 에러나 부팅 시 일어나는 악의적인 행위로부터 보호될 수 있다.
- 결국 하이브리드 모델도 소프트웨어로 동작하기 때문에 호스트 CPU 자원을 소모해야 한다.
- 시스템 이전이 쉽지 않다.
- 소프트웨어로 동작하므로 상대적으로 바이러스에 취약하다.
- 호스트 시스템의 고장으로 인해 데이터의 무결성이 훼손될 수 있다.
- 후 기록(write-back)을 위한 캐시가 없고 추가적인 배터리도 추가하기 어렵다.
다음은 앞서 살펴본 RAID 방식의 특징을 요약한 것이다.
| Features | Pure Software RAID | Hardware-assisted SW RAID |
Hardware RAID |
| Data protection at boot | No | Yes | Yes |
| Write-back caching possible | No | No | Yes |
| Enhanced protection in case of power loss |
No | No | Yes |
| RAID independent of host OS | No | No | Yes |
| RAID performance | Depends on server load | Depends on server load | High : Independent of server load |
| RAID functionality vulnerable to viruses |
Yes | Yes | No |
| Setup during boot | No | Yes | Yes |
| Ability to migrate to other OS versions | No | Limited | Yes |
| Typical RAID applications | RAID 0, 1 | RAID 0, 1 | Advanced RAID : RAID 5, 6 |
예전에는 RAID라고 하면 대규모 서버에서만 사용하는 것으로 인식되었다. 그래서 개인 사용자의 관심도 적었다. 하지만 최근에는 소프트웨어 방식의 RAID 지원이 활발해 지면서 개인용 컴퓨터에서도 RAID 구성을 많이 이용하고 있다. 7년 전에 컴퓨터 구입 시 RAID 구성을 위해 일부러 160기가 하드를 구입해도 되는 것을 80기가 2개를 구입해 RAID 0으로 쓴 적이 있다.
그 당시 아수스 메인보드에서 지원하는 RAID 기능을 활용했다. 최근에 컴퓨터를 새로 구입하고 나서 초기 운영체제를 설치하고자 하면 기본적인 ROM BIOS 외에 RAID와 관련된 BIOS가 하나 더 로드되는 것을 쉽게 확인할 수 있다. 이 방식은 결국 하이브리드 모델인 RAID BIOS를 이용하는 소프트웨어 RAID 일 것이다.
3. 시스템이 RAID 구성을 사용할 경우 이미징 방안
시스템 조사 시 저장매체의 이미징을 수행한다고 할 때, 하드웨어 RAID 방식과 소프트웨어 RAID 방식의 경우 어떤 식으로 이미징이 되어야 할 것인가? 그냥 직관적으로 살펴 볼 수 있는 내용에 대해서 논의해 보자.
# 하드웨어 방식의 RAID에서 이미징
기본적으로 RAID 방식에서 RAID 볼륨을 이미징 할 것인가? 아니면 각 디스크를 이미징 할 것인가? 로 고민하게 된다. 하드웨어 방식은 개별적인 디스크가 별도의 컨트롤러에 의해 볼륨으로 구성되는 방식이다. 해당 컨트롤러는 작게는 수십에서 많게는 수천만원에 이르는 제품까지 존재한다.
이와 같은 상황에서 개별적인 디스크를 이미징 한다는 것은 잘못된 방법일 것이다. 물론 시중의 모든 RAID 컨트롤러가 자기 부서의 포렌식 LAB에 마련되어 있다면 개별적인 디스크 이미징도 쓸모가 있겠지만 모든 RAID 컨트롤러를 가지고 있기 힘들다. 이미징에 의한 분석은 현장에서 이루어지기 어렵기 때문에 컨트롤러가 없는 입장에서 개별적인 디스크를 이미징 하는 것은 파일시스템 단에서의 분석을 포기하는 것이 된다.
물론 RAID 0이나 1과 같이 단순히 구성된 경우에는 개별적인 디스크 이미지 만으로 분석이 가능할 수 있지만 하드웨어 RAID의 경우에는 개별 디스크가 컨트롤러에 의존적인 경우가 많기 때문에 정확한 실험이 이루어지지 않았다면 볼륨을 이미징 하는 것이 적절할 것이다.
볼륨은 상대적으로 매우 크지만 최근의 디스크 이미징 도구는 분할 이미징이 되므로 저장 용량만 갖추어 진다면 이미징 하는 것이 어렵지는 않을 것이다. 추가적으로 볼륨은 개별적인 디스크의 모든 영역을 포함하지 않을 수도 있다. 개별적인 디스크에서 논리적으로 나누어진 영역을 다시 논리적으로 통합했기 때문에 슬랙과 같은 영역은 볼륨에 포함되지 않는다.
따라서, 완벽한 분석을 위해서라면 볼륨 뿐만아니라 개별적인 디스크 또한 수집을 해야 할 것이다. 개별적인 디스크는 컨트롤러의 드라이버 없이는 분석이 용이하지 못할 수 있으므로 문자열 검색과 같은 제한적인 방법이 사용될 수 있을 것이다.
그렇다면 볼륨은 어떤 식으로 수집을 할 것인가? 대규모의 서버의 경우 시스템이 활성화 된 상태일 것이다. 이 경우 시스템 종료 방안은 기업의 손실을 초래할 수 있다. 따라서 영장의 범위 내에서 시스템을 종료할 수 없는 경우는 활성화된 상태에서 손쉽게 볼륨을 이미징 할 수 있다. 하지만 시스템이 종료되어 있는 경우에는 해당 RAID 컨트롤러 드라이버가 포함된 Live CD나 Bootble USB를 통해 부팅 후 이미징 하는 것이 적절할 것이다.
그리고 하드웨어 RAID의 경우 볼륨이라는 논리적인 단위를 증거로 수집하는 것인 만큼 추가적인 무결성 입증 방안이 필요하다.
# 소프트웨어 방식의 RAID에서 이미징
소프트웨어 방식의 RAID의 경우, 소프트웨어만으로 RAID 구성이 가능하므로 개별적인 디스크 이미징을 수행한 후 해당 소프트웨어의 도움을 받아 비교적 쉽게 다른 시스템에 마운트 시킬 수 있으므로 개별 디스크 이미징을 수행해도 큰 문제가 없을 것이다.
대부분 소프트웨어 방식은 운영체제에서 지원하는 RAID 기능을 사용하기 때문에 이 경우에는 디스크 구성이 단순하다. 따라서 윈도우에서 구성한 RAID도 리눅스에서 마운트 할 수 있다. 그리고 널리 알려진 포렌식 분석도구들도 이러한 소프트웨어 방식의 RAID를 분석할 수 있는 기능을 지원한다. 각 RAID 구성 방식에 맞는 적절한 구성을 마치면 별도로 볼륨을 가상 마운트 시켜준다.
볼륨을 이미징 해도 되지만 이 경우에도 앞서 이야기한 볼륨으로 구성되지 못한 개별 디스크의 영역이 존재할 수 있기 때문에 주의해야 한다.
최근에 하드디스크의 경우 1 TB의 용량이 보편화 되고 있다. 그에 따라 증거 수집에서 분석까지 너무도 많은 시간이 걸린다. 그래서 최근에는 대용량 데이터에 대한 효과적인 분석을 주제로 한 디지털 포렌식 방안이 연구되고 있다. 하지만 시간을 줄인다는 것은 분석하는 데이터가 줄어든다는 것인데, 정확한 분류가 가능하다면 모르지만 이것은 현실적으로 불가능 하기 때문에 중요한 증거를 놓칠 가능성이 존재한다.
이런 상황에서 RAID로 구성한 4 TB, 서버의 경우 수십 TB의 데이터를 이미징하고 분석하는 것은 말로는 쉬울지 모르나 정말 고된일이 아닐 수 없다. 하지만 시간이 오래 걸린다고 포기할 수는 없는 일이기 때문에 솔직히 RAID와 같은 환경에서 분석하는 일이 적길 바랄 뿐이다.
참고 자료
http://www.adaptec.com/NR/rdonlyres/14B2FD84-F7A0-4AC5-A07A-214123EA3DD6/0/4423_SW_HWRAID_10.pdf
Brian Carrier, File System Forensics Analysis, Addison Wesley.
-
http://feedbeef.blogspot.com n0fate
-
http://forensic-proof.com Proneer
Categories
- 0×01 News (16)
- 0×02 Fundamentals (11)
- 0×03 Data Forensics (12)
- 0×04 Storage Forensics (14)
- 0×05 File System Forensics (31)
- 0×06 Windows Forensics (19)
- 0×07 *nix Forensics (2)
- 0×09 Web Forensics (5)
- 0x0A Virtual Forensics (5)
- 0x0B Forensic Challenges (15)
- 0x0C Forensic Education (8)
- 0x0D EnCase (12)
- 0x0E Forensic Tools (8)
- 0x0F Slides (24)
- 0×10 Articles (2)
addressing artifacts BIOS boot code boot process challenge Cluster Codegate cookie Data Carving Data recovery DC3 DCO defcon ENCASE EnCE encoding EnScript exFAT FAT File System firmware Forensic Challenge hardware imaging Live Forensics live response mbr network ntfs padocon process RAID Recycle Bin SCSI signature Slack slide SSD steganography timeline timestamp virtual forensics WDFS writeup
WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.
What I'm Doing...
- Old Servers never die – unfortunately, http://t.co/9x9WoU5L 3 days ago
- Windows Live Messenger, MessengerCache folder - http://t.co/ynsdu7fe 3 days ago
- DFIR Slides and Video scripts - http://t.co/XmMYTpg1 3 days ago
- More updates...
Recent Comments
- Jinkook Kim on 리눅스 메모리 포렌식 개요 (An Introduction to Linux Memory Forensics)
- blesslaw on 리눅스 메모리 포렌식 개요 (An Introduction to Linux Memory Forensics)
- MaJ3stY on 리눅스 메모리 포렌식 개요 (An Introduction to Linux Memory Forensics)
- Jinkook Kim on 리눅스 메모리 포렌식 개요 (An Introduction to Linux Memory Forensics)
- MaJ3stY on 리눅스 메모리 포렌식 개요 (An Introduction to Linux Memory Forensics)
Last searched terms
- - 포렌식 툴
- - 스테가(...)포렌식
Last referers
Visitors Online
- 02 visitor(s) online
- powered by WassUp


