Ext 2, Ext 3 개념과 분석 - 응용프로그램 범주

14.6 응용프로그램 범주

- Ext3는 오직 한가지 응용프로그램 수준의 기능 즉, 파일스시템 저널만을 갖는다. Ext2에는 저널기능이 없고, 할당같은 다른 응용프로그램 범주기능이 일반 사용자 파일에 구현되어있다.

▶ 파일시스템 저널링

-  8장에서 설명했던 파일시스템 저널을 Ext3는 포함한다. 파일시스템 저널은 파일시스템이 손상되었을때 재빨리 복구할 수 있도록 파일시스템에 업데이트를 기록한다.

 

▷ 개요

- 파일시스템 저널은 보통 inode8을 사용한다. Ext3 저널은 슈퍼블록에서 위치가 지정되기 때문에 어디든 위치할 수 있긴하다. 저널은 호환시스템 기능으로 저널 사용시 슈퍼블록에 해당 값을 설정한다. 슈퍼블록은 또한 저널 장치를 위해 비호환 기능도 존재한다. 비호환 기능이 설정될 때 파일시스템은 외부 저널을 사용하고, 로컬파일에 데이터를 저장하지 않는다. 이 외부 저널 장치 위치는 슈퍼블록에서 주어진다.

- 저널은 어떤 블록에서 업데이트가 일어났는지 기록하고, 업데이트 이후에 그 업데이트가 끝났는지 확인한다. 저널이 동작하는데 두가지 모드가 있다. 하나는 메타데이터 업데이트만 저널에 기록하는 것이고, 다른 하나는 데이터 블록을 포함한 모든 업데이트를 저널에 기록하는 것이다. 저널의 첫 버전은 뒤의 방법을 사용했다. 하지만 현재 버전에서는 데이터 블록을 기록하는 것을 옵션으로 제공하고, 기본적으로 메타데이터 변경만을 기록한다.

- Ext3 저널링은 블록수준에서 실행되고, 이것은 만약 특정 inode에서 1비트가 업데이트 되면 inode가 위치한 전체 파일시스템 블록이 저널에 저장된다는 것을 의미한다. 저널의 첫 블록은 슈퍼블록을 위한 것이고, 전체적인 정보를 담고있다. 다른 블록은 저널 엔트리를 위해 사용되고, 저널은 그 끝에 도달시 다시 시작으로 돌아온다. 저널의 블록크기는 파일시스템의 블록크기와 동일한다.

- 업데이트는 트랜잭션으로 처리되고, 각 트랜잭션은 순서번호를 갖는다. 저널의 블록은 트랜잭션 관리데이터나 파일 시스템 업데이트 데이터중 하나를 포함한다. 각 트랜잭션은 기술자 블록에서 시작하고, 그 블록은 트랜잭션 순서번호와 어떤 파일 시스템 블록이 업데이트 되었는지를 나타내는 목록을 포함한다. 디스크에서 업데이트가 발생할 때 적용블록은 동일한 순서번호로 존재한다. 새로운 트랜잭션에 기술자는 적용블록 다음에 온다. 아래 그림에서 이 같은 예를 볼 수 있다.

<두 트랜잭션이 있는 Ext3저널>

- 슈퍼블록은 첫 기술자 블록이 어디있는지 확인해서 그 순서번호를 구분한다. 식별자 블록이 전부 채워지면 새로운 블록이 남은 엔트리를 위해 동일한 순서번호로 할당된다. 저널에 추가되었던 파일시스템 블록은 취소될 수 있으므로 그 변경은 복구하는 동안 적용되지 않는다. 취소 블록에는 순서번호와 취소될 블록의 목록이 저장되어있고, 취소블록을 이용해서 이것을 수행할 수 있다. 복구하는 동안 취소블록에 정리되어 있는 블록과 취소 블록이 순서번호보다 더 작은 순서번호는 복구되지 않는다.

- 저널의 데이터 구조체와 예제는 15장에서 설명하도록 한다. TSK jls 도구는 저널 내용을 분석한다. 

 

※ 이 명령어로 예제 파일시스템 이미지를 분석한 결과는 다음과 같다.

-> 이 결과에서 슈퍼블록, 기술자, 그리고 적용블록을 확인할 수 있다. 트랜잭션 295는 저널블록1에서 시작하고, 블록8에서 끝난다. 또한 각 저널 블록에 해당하는 파일시스템 블록을 볼 수 있다. TSK jcat 도구를 이용해 저널에서 저널 블록을 추출할 수 있다.

 

▷ 분석기술

- 파일시스템 저널을 분석해서 최근에 어떤 이벤트들이 일어났었는지 추가 정보를 얻을 수 있다. 이 분석을 위해서 파일시스템 슈퍼블록에 있는 주소로 로그위치를 확인하고, 저널 슈퍼블록을 분석해야 한다. 이것은 먼저 유효한 트랜잭션이 어디에 존재하는지 파악하도록 한다. 그 후 어떤 파일시스템 블록이 이 트랜잭션에서 업데이트 되었는지 확인하기 위해 블록기술자 블록을 확인한다. 

- 만약 특정한 블록을 찾으려면 의심스러운 블록 하나를 위해 기술자 블록 전부를 조사해야한다. 만약 inode가 삭제되기 전에 블록포인터가 있는 inode테이블에서 블록을 찾는다면 파일들을 복구할 수 있다. 

 

▷ 분석 고려사항

- 시간이 진행됨에 따라 로그는 다시 처음으로 돌아가고, 사고에서 데이터는 덮어써진다. 따라서 저널은 최근에 발생한 이벤트를 조사하는데 유용하다. 리눅스는 파일시스템이 마운트 될 때마다 그 시작에서 저널을 시작한다. 

- 주어진 저널블록이 파일시스템 어디에 속하는지 판단하기 위해서 기술자 블록의 위치를 반드시 확인하자. 때로는 기술자가 나중에 발생한 트랜잭션으로 덮어 써졌을 수도 있다. 

- 기본으로 메타데이터 데이터만 기록을 남기므로 삭제된 파일시스템 내용은 복구할 수 없다. 슈퍼블록과 디렉토리 내용은 기록이 되기 때문에 파일들이 추가되고, 슈퍼블록 값을 사용해서 삭제될 때 이 변경 내용들을 관찰할 수 있고, 관련된 디렉토리에 있는 파일 이름들을 살펴볼 수 있다. 저널을 이용해 얻을 수 있는 데이터량은 사고가 발생한 시점과 분석을 시작하는 시점 사이에 얼마나 많은 시스템 활동이 있었느냐에 달려있다.

 

 

▶ 분석 시나리오

- 해킹 피해를 입은 리눅스 시스템을 조사하는 시나리오를 생각해보자. 피해를 입은 당일 이미지를 수집했고, 공격한 정보가 저널에 기록되어 있다. 조사하다보니 다양한 공격도구가 있는 디렉토리를 발견할 수 있었다. 또한 Passwords.txt라는 삭제된 파일 이름도 발견했다. 이를 저널에서 찾으려고 한다. 

- 삭제된 파일은 블록그룹 30에 있는 inode 488,650에 할당된 것을 알고 있다. 그 블록그룹의 첫번째 inode는 488641이다. inode 테이블은 블록 983044에서 시작하고 각 블록은 4096바이트이다. 그래서 찾으려는 inode는 그룹의 inode 테이블 엔트리 10이고 테이블의 첫 번째 블록에 있다. 

 

※ 저널에서 jls를 시작하고, 파일시스템 블록 983044에서 엔트리를 찾는다.

트랜잭션 136723을 볼 수 있다.

 

※ 블록 983044에는 여러 내용이 있고, 그것들의 차이점을 비교해서 각각을 분석해야 한다. 저널 블록 2297에서 inode테이블을 추출할 수 있고, 테이블에서 10번째 inode로 건너뛰도록 아래 dd를 이용하자.

10번째로 건너뛰면서 찾으려는 inode를 볼 수 있다.

-> 이는 inode 488650데이터고, 크기는 4~7바이트를 통해 알 수 있다. 7940바이트(0x1f04). 2개의 직접블록포인터는 바이트 40~43과 44~47에서 확인할 수 있다. 블록 983569와 983570이 그 파일에 할당되어 있는 것을 알 수 있다. 이 블록의 내용을 확인하면 공격자가 해킹했던 다양한 시스템들의 패스워드 목록을 발견할 수 있다.

 

- 이 시나리오에서 저널은 inode의 이전 복사본을 찾도록 했다.

 

---

14.7 큰 그림

- 지금까지 파일과 디렉토리 각각의 요소들을 살펴보았다. 이제는 이 모든 정보를 종합해서 전체적인 구조를 파악해 볼 시간이며, 이를 위해 /dir1/file1.dat 파일을 할당하고 삭제하는 경우를 예로 들어 설명하도록 하겠다. 파일크기는 6000바이트이고, Ext3 파일시스템 블록 크기는 1024바이트이다. 

 

▶ 파일 할당의 예

- /dir1/file1.dat 파일 생성과정을 예로 들면 먼저 dir1 디렉토리 위치를 확인하고, 이 후 디렉토리 엔트리를 생성하고, inode를 할당해서 파일 내용을 블록에 저장하는 것이다. 데이터 구조체를 할당하는 순서는 운영체제마다 다를 수 있어 언급한 것들이 실제 시스템과 다를 수 있다는 사실에 주의하자.

 

1. 파일시스템 1024바이트에있는, 1023바이트 크기의 슈퍼블록 데이터 구조체를 읽는다. 이 구조체를 분석하면 블록과 조각 크기가 1024바이트라는 것을 알 수 있다. 각 블록 그룹에는 8192개의 블록과 2016개의 inode가 있다. 첫 번째 블록 그룹 시작 전에 예약된 블록은 없다. 

2. 블록 2와 3에 있는 그룹 기술자 테이블을 읽는다. 이 테이블은 각 블록 그룹의 레이아웃을 설명한다. 

3. dir1 디렉토리를 확인하려면 루트 디렉토리인 inode2를 분석해야 한다. 그룹의 inode개수를 이용해 inode 2는 블록 그룹 0에 있다는 것을 확인할 수 있다. 그리고 그룹 0의 그룹 기술자 테이블 엔트리를 이용해서 inode테이블이 블록 6에서 시작한다는 것을 알 수 있다. 

4. 블록 6에서 inode 테이블을 읽고, 두 번째 엔트리를 해석한다. inode2의 inode는 루트 디렉토리의 디렉토리 엔트리 구조체가 블록 258에 있다는 것을 알려준다. 

5. 블록 258에서 루트 디렉토리 내용을 읽고, 디렉토리 엔트리의 목록으로 내용을 해석한다. 첫 두 엔트리는 '.'와 '..'를 위한 것이다. 각 엔트리의 레코드 길이를 사용해서 다음 엔트리로 넘어가고, dir1 이름을 갖는 엔트리를 찾는다. 분석한 결과 해당 디렉토리는 inode 5033이다. 루트 디렉토리의 A-time은 디렉토리가 읽혔다는 것을 반영하기 위해 업데이트 된다. 

6. 그룹별 inode 수로 그 디렉토리의 inode 5033을 나눠 그 inode가 블록 그룹2에 있다는 것을 알 수 있다. 그룹2의 그룹기술자 엔트리를 사용해서 inode 테이블이 블록 16390에서 시작한다고 결정할 수 있다. 

7. 블록 16390에서 inode테이블을 읽고, inode 5033의 상대적인 위치인 엔트리 1001을 분석한다. 그 inode 내용은 dir1의 내용이 블록 18431에 있다는 것을 알려준다. 

8. 블록 18431에서 dir1내용을 읽고, 디렉토리 엔트리의 목록으로 그 내용을 분석한다. 디렉토리에서 사용하지 않은 공간을 찾는다. file1.dat 이름은 8문자 길이이므로, 디렉토리 엔트리는 16바이트를 필요로 한다. 이름은 2개의 할당된 이름들 사이에 더해지고, 디렉토리의 M-과 C-time이 업데이트된다. 디렉토리 내용의 변경사항이 저널에 기록된다.

9. 이후 파일에 inode를 할당하는 것이 필요하고, 부모와 동일한 그룹 블록 그룹 2에 할당해야 한다. inode 할당을 위해서는 inode 비트맵에서 할당되지 않는 inode를 확인해야 하는 데, 그룹 기술자를 사용해서 블록 16386에 그룹2의 inode비트맵이 있다는 것을 알 수 있다. '첫 번째 적용' 검색을 통해 inode 5110이 할당되지 않았다는 것을 확인할 수 있다.

비트맵 해당 비트를 1로 설정하고, 그룹 기술자 테이블에서 비할당 inode 카운트는 1 감소시키고, 슈퍼블록도 마찬가지로 1을 감소시킨다. inode 주소는 file1.dat 디렉토리 엔트리에 추가된다. 비트맵, 그룹기술자, 그리고 슈퍼블록의 변경 사항들이 저널에 기록된다. 

10. 그룹 2 inode 테이블에 inode 5110을 배치하고, 그 값을 초기화한다. 시간 값들은 현재 시간으로 설정되고, 링크값은 디렉토리 엔트리 링크에 해당하는 1로 설정된다. inode테이블 변경사항이 저널에 기록된다.

11. 파일 내용을 저장하기 위해서는 6개의 블록이 필요하기 때문에 블록 16385에 있는 블록 비트맵을 분석해야 한다. 블록 그룹2에서 이용 가능한 블록을 검색하기 위해 '첫 번째 적용' 알고리즘을 사용하고, 검색된 결과는 블록 20002~20003과 20114~20117이 이용가능한 것으로 확인되었다. 비트맵에서 이 블록들의 각 비트는 설정되고, 그 주소들은 inode 5110에 있는 직접 포인터에 더해진다. 그룹기술자와 슈퍼 블록의 비할당 블록 카운트는 업데이트된다. inode, 그룹 기술자, 슈퍼블록과 비트맵 변경 사항이 저널에 기록된다.

12. file1.dat의 파일 내용은 할당된 블록에 써진다.

 

 

※ 이 과정의 마지막 상태는 아래 그림과 같다.

<'dir1/file1.dat' 파일이 더해진 후 파일시스템의 마지막 상태>

 

 

▶ 파일 삭제의 예

- 지금부터는 /dir1/file1/dat 파일이 삭제되는 과정을 보도록 하자. 이전 절에서 언급한 것처럼 데이터 구조체가 비할당되는 과정은 운영체제마다 다르기 때문에 이 순서가 실제 운영체제와 다를 수 있다는 것을 유념하자.

 

1. 파일시스템 1024바이트에있는, 1023바이트 크기의 슈퍼블록 데이터 구조체를 읽는다. 이 구조체를 분석하면 블록과 조각 크기가 1024바이트라는 것을 알 수 있다. 각 블록 그룹에는 8192개의 블록과 2016개의 inode가 있다. 첫 번째 블록 그룹 시작 전에 예약된 블록은 없다. 

2. 블록 2와 3에 있는 그룹 기술자 테이블을 읽는다. 이 테이블은 각 블록 그룹의 레이아웃을 설명한다. 

3. dir1 디렉토리를 확인하려면 루트 디렉토리인 inode2를 분석해야 한다. 그룹의 inode개수를 이용해 inode 2는 블록 그룹 0에 있다는 것을 확인할 수 있다. 그리고 그룹 0의 그룹 기술자 테이블 엔트리를 이용해서 inode테이블이 블록 6에서 시작한다는 것을 알 수 있다. 

4. 블록 6에서 inode 테이블을 읽고, 두 번째 엔트리를 해석한다. inode2의 inode는 루트 디렉토리의 디렉토리 엔트리 구조체가 블록 258에 있다는 것을 알려준다. 

5. 블록 258에서 루트 디렉토리 내용을 읽고, 디렉토리 엔트리의 목록으로 내용을 해석한다. 첫 두 엔트리는 '.'와 '..'를 위한 것이다. 각 엔트리의 레코드 길이를 사용해서 다음 엔트리로 넘어가고, dir1 이름을 갖는 엔트리를 찾는다. 분석한 결과 해당 디렉토리는 inode 5033이다. 루트 디렉토리의 A-time은 디렉토리가 읽혔다는 것을 반영하기 위해 업데이트 된다. 

6. 그룹별 inode 수로 그 디렉토리의 inode 5033을 나눠 그 inode가 블록 그룹2에 있다는 것을 알 수 있다. 그룹2의 그룹기술자 엔트리를 사용해서 inode 테이블이 블록 16390에서 시작한다고 결정할 수 있다. 

7. 블록 16390에서 inode테이블을 읽고, inode 5033의 상대적인 위치인 엔트리 1001을 분석한다. 그 inode 내용은 dir1의 내용이 블록 18431에 있다는 것을 알려준다. 

8. 블록 18431에서 dir1 내용을 읽고, 디렉토리 엔트리의 목록으로 그 내용을 분석한다. file1.dat 파일의 엔트리를 찾아야 하고, 확인 결과 파일은 inode 5110에 할당되어 있다. 디렉토리 엔트리 12.jpg 파일에 속한 이전 디렉토리 엔트리의 레코드 길이 필드의 길이에 삭제할 파일의 레코드 길이를 더해서 비할당된다. 이 과정의 결과로 디렉토리의 M-와 A-, C-time이 업데이트된다. 디렉토리의 내용 변경 사항이 저널에 기록된다.

9. 그룹 2 inode 테이블에서 inode 5110의 내용을 분석해 해당 파일의 이름이 삭제되었다는 것을 표시하기 위해 링크카운트 1을 감소시킨다. 링크 카운트는 0이되고, 그것은 inode를 해제했다는 것을 의미한다. 

inode를 해제하기 위해 inode 비트맵에서 해당 비트를 0으로 설정하고 그룹 기술자와 슈퍼블록에 있는 비할당 inode카운트를 업데이트 한다. 이 변경 사항들 또한 저널에 기록된다.

10. 또한 파일에 할당된 6개의 블록도 할당을 해제해야 한다. 각 블록에 해당하는 블록 비트맵의 비트를 0으로 설정하고 inode에 블록 포인터를 제거한다. 파일 크기는 블록이 해제될 때 매번 감소해서 결국 0이 된다.

M-, C-, D-time는 inode가 변경되었다는 것을 반영하기 위해 업데이트된다. 비할당 블록 카운트는 그룹 기술자와 슈퍼블록에서 업데이트된다. 그 변경 사항들이 저널에 기록된다. 

 

 

※ 파일이 삭제된 후 파일시스템 마지막 상태는 아래와 같다. 굵은 색 줄과 값들은 파일 삭제로 인해 파일시스템에서 변경된 내용을 표시한 것이다. (점선 말하는 듯)

<'dir1/file1.dat' 파일이 삭제된 후 마지막 상태>  

 

 

---

14.8 다른 주제

- 이 절은 ExtX 삭제된 파일 복구와 피일시스템과 일관성 검사를 설명한다. 이 두 주제는 5가지 데이터 범주를 벗어난다. 

 

▶ 파일 복구

- 표준 리눅스 시스템에서 Ext2와 달리 Ext3에서 파일복구가 쉽지 않다. Ext2에서 파일이 삭제될 때 inode값이 영구삭제되지 않기 때문에 블록포인터들은 계속 남아있다. 또한 시간 값들은 파일이 삭제될 때 업데이트되므로 삭제시간도 확인할 수 있다. 디렉토리 엔트리와 inode사이의 연결은 영구 삭제되기 때문에 비할당된 inode엔트리를 검사해서 파일들을 복구해야 한다. 하지만 비할당 된 inode가 재할당 될 수 있기 때문에 그 블록이 더이상 블록 주소와 관련이 없을 수도 있다는 것을 명심하자.

- Ext3에서는 파일이름과 inode 연결이 남아있지만 블록포인터는 영구 삭제된다. 데이터를 복구하기 위해서 데이터 카빙 기술을 이용해야 한다. 특정 파일에 대한 데이터를 수집시 그룹 정보를 이용한다. 대부분의 운영체제들은 블록그룹에 블록들을 할당한다. 그래서 더 작은 영역에 집중할 수 있지만 어떤 운영체제는 다른 곳에도 블록을 할당할 수 있다. 따라서 전체 수집을 할 필요가 있다. (블록 그룹 뿐아니라 다른 곳도 확인을 해야한다는 말)

- 데이터 수집시 간접블록 포인터들이 데이터 중간에 존재할 수 있다는 사실에 주의하자. 연속적인 블록들이 삭제된 블록에 할당되었어도 마지막 블록은 간접블록 포인터로서 첫 번째 블록의 기능을 할 수 있다. 삭제된 파일에서는 포인터들이 모두 0이고, 수집된 파일에서 이것들을 제거해야 한다. 

- 마지막으로 Ext3 파일시스템에서 파일이 최근에 삭제되었다면 inode의 이전 복사본을 찾기 위해 저널을 분석할 수 있다. inode가 모든 블록 포인터와 간접블록 포인터의 복사본을 가지고 있다면, 저널은 inode의 블록 복사본을 저장하고 있다.

 

 

▶ 일관성 검사

- 파일시스템 데이터 구조체에서 유효하지 않는 값들은 데이터를 숨기는데 사용할 수 있는데, 이를 찾기 위해 일관성 검사가 필요하다. 먼저 파일시스템 범주의 슈퍼블록을 조사해보자. 슈퍼블록의 1024바이트 대부분은 사용하지 않기 때문에 데이터를 숨기는데 사용될 수 있다. 그룹기술자는 저장을 더욱 효율적으로하는데 그룹기술자와 슈퍼블록의 복사본을 사용하고, 이는 변경들을 탐지하는데 사용이 가능하다. 

- inode 수가 그룹의 블록의 수보다 적다. 그러다보니 inode 비트맵 마지막 바이트는 전체가 사용되지는 않는다. 그래서 inode에 할당된 블록은 전부 사용되지 않기 때문에 블록그룹은 블록 비트맵에서 사용하지 않는 비트들을 가질 수 있다.

- 그룹기술자 테이블, inode 테이블, 블록비트맵, inode 비트맵 또는 슈퍼블록을 저장하는 관리 블록 중 한개가 아니면, 할당된 모든 블록에는 그것을 가리키는 할당된 inode엔트리가 있어야 한다. 

- 각 inode에 대부분의 데이터를 사용하므로 많은 양의 데이터를 숨길 수는 없다. 하지만 각 inode테이블 끝에 사용하지 않는 많은 바이트들이 있다. 첫 10개 inode들은 예약되어 있지만, 사용해서는 안된다. 이것들은 데이터를 숨기는 데 사용될 수 있다. 

- 예약되거나 고아인 inode 빼고는 할당된 모든 indoe엔트리들은 파일이름을 가지고 있어야 한다. 고아 파일들은 슈퍼블록에서 관리한다. 그리고 이름개수와 연결 카운트 수는 같아야한다. 할당된 모든 파일이름은 반드시 할당된 inode엔트리에서 지정해야 한다. 디렉토리의 끝 공간은 데이터를 숨기는데 사용될 수 있다.

 

▶ 요약

- Ext2와 Ext3는 리눅스 운영체제에서 주로 사용한다. 둘의 파일복구 방법은 서로 다른데 파일 삭제시 Ext3는 모든 블록 포인터를 제거하기 때문이다. 

 

---

p.s 개강+요양 = 힘듬 ㅜ