랜섬웨어로부터 Firebird 데이터베이스를 보호하는 방법은 무엇인가요?

2016년 12월 6일, Alexey Kovyazin 작성

랜섬웨어 공격은 많은 기업에게 심각한 문제가 되었습니다. 지난 주에만 서로 다른 고객 3곳에서 Firebird 데이터베이스가 랜섬웨어 바이러스에 의해 암호화되는 사고가 발생했습니다. 다행히 우리는 모두를 도울 수 있었지만, 문제의 규모는 분명히 증가하고 있습니다.

이 글에서는 이러한 문제들이 어떻게 해결되었는지 살펴보겠습니다.

일반적으로 랜섬웨어는 특별히 Firebird 데이터베이스를 암호화하도록 설계된 것이 아니라 컴퓨터의 모든 파일을 암호화한 다음 복호화 비밀번호를 제공하는 대가로 몸값을 요구합니다. 그리고 몸값을 지불하더라도 복호화 비밀번호나 응답을 전혀 받지 못할 수도 있습니다(또한, 백신 웹사이트를 확인하는 것이 필요합니다. 그들은 종종 해당 랜섬웨어에 대한 핀 코드나 복호화 도구를 공개하기 때문입니다. 예를 들어, 그 중 하나: noransom.kaspersky.com).

물론, 안정적인(그리고 서버에 적합한) 백신을 갖추는 것이 필요하지만, Firebird 데이터베이스를 보호하기 위해 특별히 할 수 있는 일이 있을까요?

랜섬웨어에는 다양한 유형이 있으며, Firebird 데이터베이스에 미치는 영향을 살펴보겠습니다.

2개 회사는 Firebird 데이터베이스를 부분적으로 암호화한 랜섬웨어에 감염되었습니다.

아시다시피, Firebird 데이터베이스 파일은 동일한 크기의 페이지 집합입니다. Firebird 데이터베이스의 데이터베이스 페이지에는 메타데이터, 사용자 데이터, 인덱스, 생성기 등 다양한 유형의 정보가 포함되어 있습니다.

일반적으로 이러한 랜섬웨어는 데이터베이스 파일 전체가 아니라 파일의 작은 부분, 즉 헤더 페이지와 데이터베이스 내부의 일부 데이터베이스 페이지(%)를 암호화합니다.

모든 페이지는 강한 연관성을 가지고 있기 때문에, 암호화된 페이지가 몇 개뿐이어도 전체 데이터베이스를 Firebird 엔진으로 읽을 수 없게 만듭니다. 예를 들어, 10GB 데이터베이스에서 1% 미만의 데이터가 암호화되었고 나머지 99%는 정상이었습니다.

이 경우, 이러한 암호화된 데이터베이스는 심각하게 손상된 데이터베이스 파일로 간주할 수 있으며, IBSurgeon FirstAID는 암호화된 Firebird 데이터베이스 파일에서 데이터를 내보낼 수 있는 도구입니다. 손상된 HDD에서 데이터베이스를 복구할 때도 동일한 접근 방식이 사용됩니다.

암호화된 Firebird 데이터베이스에서 데이터 내보내기

IBSurgeon FirstAID는 직접 복구 또는 데이터 추출을 통해 데이터베이스를 복구할 수 있습니다. 직접 복구는 빠르며 데이터베이스 파일의 손상을 직접 신속하게 수정할 수 있습니다. 그러나 랜섬웨어의 경우 헤더 페이지와 주요 메타데이터가 손실되었기 때문에 도움이 되지 않으므로 추출이 유일한 선택입니다.

FirstAID는 데이터베이스 파일을 직접 읽습니다. Firebird를 사용하여 데이터베이스 파일에 접근하지 않고 바이트 단위로 직접 읽습니다. 손상된 데이터 추출에만 집중하고 성능을 희생하기 때문에 FirstAID는 심각하게 손상된 Firebird 데이터베이스에서도 데이터를 내보낼 수 있습니다. 물론 FirstAID는 암호화된 데이터를 손상된 것으로 건너뛰고 정상 데이터만 내보냅니다.

랜섬웨어가 중요한 메타데이터를 암호화하지 않은 경우 FirstAID로 암호화된 데이터베이스 파일을 열고 레코드를 미리 볼 수 있습니다. 왼쪽 목록에서 테이블을 선택하고 미리 보기 탭을 연 다음 데이터 페이지를 탐색하세요.

볼 수 있는 레코드는 동일한 구조의 새 데이터베이스로 내보낼 수 있습니다:

대략적인 손실량은 데이터베이스의 페이지 요약 탭에 있는 불량 페이지 비율로 추정할 수 있습니다:

불량 페이지 비율은 암호화되어 데이터가 손실된 데이터베이스 페이지 수를 보여줍니다.

따라서 2건의 경우 암호화된 데이터베이스에서 데이터를 내보낸 FirstAID 추출기를 사용하여 데이터베이스를 구했습니다.

100% 암호화 랜섬웨어

안타깝게도 랜섬웨어는 종종 파일의 100%를 예외 없이 완전히 암호화합니다.

일반적으로 이러한 랜섬웨어는 운영 체제의 부트로더에 악성 코드를 주입한 다음 컴퓨터를 재부팅하고 CHKDSK 실행을 시뮬레이션하지만, 디스크 검사 대신 모든 것을 암호화합니다.

이러한 바이러스로부터 보호하는 유일한 방법은 중요한 데이터베이스의 백업을 클라우드나 다른 사무실 등 제3의 장소에 보관하는 것입니다.

Firebird 데이터베이스에는 4가지 가능한 백업 방법이 있습니다:

gbak을 사용한 전체 검증 백업
nbackup을 사용한 증분 미검증 백업
VM 수준 백업(가상 환경용)
복제 기반 웜 대기(데이터베이스 미러)

랜섬웨어로부터 보호하기 위한 최상의 백업 방법은 무엇일까요? 50GB 크기의 Firebird 데이터베이스 실제 사례를 통해 장단점을 살펴보겠습니다.

기능	전체 검증 백업(gbak)	증분 백업(nbackup)	VM 수준 백업	웜 대기(복제)
업로드 크기	매일 ~30GB	처음 50GB, 이후 변경된 부분
최대 백업 빈도	매일	매시간	VM 백업 도구 설정에 따라 다름	매분
데이터베이스 성능 저하	높음	중간	낮음	매우 낮음
백업 방법의 신뢰성	높음	낮음	낮음	높음
백업 수행 시간	2-3시간(IO 속도에 따라 다름)	초기 레벨 0 생성 15-20분, 이후 3-4분	디스크 전체 스냅샷 필요(IO 및 디스크 크기에 따라 다름)	초기 15-20분, 항상 온라인

gbak을 사용한 전체 검증 백업

백업 도구(gbak)는 전체 데이터베이스를 읽고 특수 형식(fbk)으로 저장합니다. 이 백업 방법은 데이터베이스의 모든 레코드를 읽고 데이터베이스가 정상인지 확인하기 때문에 검증 백업이라고 합니다. 매우 신뢰할 수 있는 백업 방법입니다.

그러나 전체 검증 백업은 매번 전체 백업을 업로드해야 하고 수행하는 데 많은 시간이 필요하기 때문에(가장 느린 Firebird 백업 유형) 충분히 큰 데이터베이스(예제의 50GB와 같은)의 클라우드 백업에는 적합하지 않습니다. gbak 실행 중에는 집중적인 임의 디스크 읽기 및 쓰기로 인해 데이터베이스 성능이 낮습니다.

nbackup을 사용한 증분 백업

증분 백업은 Firebird의 또 다른 백업 도구인 nbackup으로 수행됩니다. Nbackup은 변경 사항의 증분으로 백업을 생성합니다. 먼저 데이터베이스의 정확한 복사본인 레벨 0 백업을 만든 다음, 다음 반복에서 데이터베이스를 스캔하고 변경된 페이지만 레벨 1, 레벨 2 등으로 저장합니다. 전체 백업(레벨 0)은 분기별 1회, 레벨 1 증분은 매월, 레벨 2는 매주, 레벨 3은 매일, 레벨 4는 매시간 설정할 수 있습니다.

속도가 상당히 빠르며 거의 선형 파일 복사 속도로 백업을 생성합니다.

nbackup의 주요 단점은 검증이 없다는 것입니다. 데이터베이스 페이지가 손상된 경우 nbackup은 손상된 페이지를 백업 파일에 복사하며, 이 백업 파일도 손상됩니다(gbak은 이 경우 오류를 발생시킵니다). 또한 각 레벨을 생성할 때 Firebird가 전체 데이터베이스를 스캔해야 하므로(Firebird 2.5, v3에는 개선 사항이 있음) 큰 데이터베이스에서 nbackup을 너무 자주 실행할 수 없습니다.

이해할 수 있듯이 nbackup은 상당히 정교한 일정이 필요하지만 적절한 도구를 사용하면 쉬운 작업입니다.

올바른 방법은 nbackup을 gbak과 함께 사용하는 것입니다. gbak은 매일 또는 매주 데이터베이스를 검증하고, nbackup은 데이터베이스를 자주 백업할 수 있는 빠른 방법을 제공합니다.

따라서 nbackup은 데이터베이스를 클라우드에 저장하기에 좋은 선택으로 보입니다.

VM 백업

가상 머신 백업은 어떨까요? VM 및 백업 도구 공급업체는 데이터베이스 백업을 지원한다고 주장하지만, 어떤 데이터베이스가 지원되는지 명시하지 않는 경우가 많습니다. VM 백업은 온라인 백업을 올바르게 수행하려면 특정 데이터베이스용 Volume Shadow Service(VSS) 공급자가 설치되어 있어야 합니다. Firebird용 VSS 공급자는 HQbird 고급 배포판의 일부로 제공됩니다.

물론 VSS 공급자가 있는 VM 백업에는 마법이 없습니다. 내부적으로는 nbackup을 사용하여 데이터베이스를 복사에 적합한 모드로 전환합니다. VSS 공급자가 없으면 VM 수준 백업 결과는 하드 리셋과 유사한 상태의 데이터베이스 복사본과 같습니다. Firebird는 RAM의 데이터 캐싱을 집중적으로 사용하므로 플러시되지 않은 변경 사항으로 인해 백업이 손상될 수 있습니다.

웜 스탠바이

일부 기업은 데이터베이스에서 어떤 데이터도 잃고 싶지 않아 합니다. 크래시 직전의 최근 청구서는 중요할 수 있으며, 마지막 배송으로 수십 대의 트럭이 도로에 나설 수도 있습니다. 이런 경우 시간별 백업조차 충분하지 않으며, 유일한 해결책은 비동기 네이티브 복제를 기반으로 한 데이터베이스의 웜 스탠바이(읽기 전용 미러)입니다.

네이티브란 복제에 트리거나 메타데이터 변경이 필요하지 않으며(유일한 요구 사항은 모든 복제 테이블에 기본 키 또는 고유 키가 있어야 한다는 것), 매우 빠르게 작동한다는 의미입니다.

웜 스탠바이를 구현하려면 데이터베이스의 초기 복사본을 만들고, 이를 복제본으로 초기화한 후 스탠바이 서버에 업로드해야 합니다. 그 후 데이터 변경 사항이 최소 지연(1분부터)으로 마스터에서 전송됩니다. 변경 사항만 전송되므로 데이터베이스의 읽기 성능을 저하시키지 않습니다.

이 백업 옵션은 매우 안정적입니다. 다른 서버에 데이터베이스의 실시간 복사본이 존재함을 보장합니다.

IBSurgeon이 무엇을 도와드릴까요?

저희는 Firebird를 위한 구독 기반 지원 서비스를 제공하며, 여기에는 클라우드 백업 및 웜 스탠바이 옵션이 포함됩니다. 이는 간편하고 합리적인 가격($99/월)이며, 다음 옵션을 포함합니다:

Firebird 데이터베이스 모니터링 및 백업 자동화
원격 데스크톱 및 인스턴트 메신저 지원
장애 조치 Firebird 솔루션(웜 스탠바이) 및 클라우드 백업

Firebird 지원 서비스에 대한 자세한 내용은 여기에서 확인하세요.

또 다른 옵션은 Firebird의 고급 배포판인 HQbird를 사용하여 클라우드 백업이나 웜 스탠바이를 직접 구현하는 것입니다. HQbird에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

그리고 물론, 마지막 수단으로 FirstAID Extractor가 있습니다.

궁금한 점이 있으시면 언제든지 문의해 주세요!