☰

VPS 자체에서 VPS 파일 시스템을 안전하게 삭제(스크럽)

tag-icon • tag-icon linux filesystems security deleted-files
VPS 자체에서 VPS 파일 시스템을 안전하게 삭제(스크럽)

VPS가 있는데 삭제할 계획입니다. 이 특정 클라우드 제공업체는 디스크를 다음 사람에게 전달하기 전에 드라이브의 데이터가 지워진다는 것을 보장하지 않습니다. 무엇인가요최대 노력민감한 데이터(파일로 존재하는지 여부)를 안전하게 삭제하려고 할 수 있나요?또는 삭제된 데이터로) 운전 중이신가요?

  • 공급자가 유지 관리를 수행하기 위해 별도의 부팅 가능한 운영 체제를 제공하지 않는다고 가정합니다.
  • 민감한 데이터의 마지막 비트가 삭제된다는 보장이 없더라도 상관없습니다.
    • (데이터가 그렇게 민감하다면 데이터를 암호화하겠습니다!)

답변1

사용스크럽 명령VPS 파일 시스템의 사용자 데이터 섹션 2는 그림 1에 나와 있습니다.

경계하다:다음 명령고의적인 데이터 파괴.

다음은 합리적인 순서로 대상을 정리하기 위한 아이디어 목록이지만 특정 VPS 구성에 따라 변경해야 할 수도 있습니다.

  • 데이터 베이스, 일반적으로 에 저장됩니다 /var. 예를 들어 MySQL을 사용하는 경우 다음과 같이 말할 수 있습니다.

    # service stop mysql       # command varies by OS, substitute as necessary
# find /var/lib/mysql -type f -exec scrub {} \;

  • /usr/local여기에는 일반 운영 체제 패키지 시스템 외부에서 시스템에 추가하는 소프트웨어만 포함되어야 합니다. 핵무기로 모든 것을 파괴하세요:

    # find /usr/local -type f -exec scrub {} \;

  • 네트워크 루트.이는 Apache를 실행하는 베어 VPS의 대부분의 Linux 웹 서버에 대한 좋은 추측입니다.

    # service stop apache      # ditto caveat above
# find /var/www -type f -exec scrub {} \;

    가상 호스트를 설정할 수 있는 우수한 제어판 프런트엔드가 있는 관리형 VPS를 사용하거나 공유 호스팅을 사용하는 경우 웹 루트가 다른 곳에 있을 가능성이 있습니다. 대신 찾아서 사용해야 합니다 /var/www.

  • 이메일.이 두 가지를 꼭 잡아보세요MTA스풀 디렉터리와 개별 사용자의 메일함 파일 및 디렉터리.

  • 모든 구성 파일잠재적으로 민감한 데이터가 포함되어 있습니다. 구성 데이터는 일반적으로 매우 지루하기 때문에 이 범주의 어떤 것도 제대로 생각할 수 없습니다. 공격하는 한 가지 방법은 다음과 같습니다.

    # ls -ltr /etc | tail -30

    이렇게 하면 마지막으로 터치한 30개의 파일이 제공되며 /etc, 인벤토리 구성 정보가 포함된 것이 아니라 가장 많이 터치했을 가능성이 높은 파일 목록이 제공됩니다.

    주의 깊은! 일부 파일로 /etc인해 다시 로그인하지 못할 수도 있습니다. 나중에 이러한 파일 지우기를 연기할 수도 있습니다.

  • 비밀번호 파일, 키 등이 목록은 시스템마다 크게 다르지만 다음과 같이 시작할 수 있습니다.

    /etc/shadow
/etc/pki/*
/etc/ssh/*key*
/etc/ssl/{certs,private}/*
~/.ssh                        # for each user

    이 시점에서는 다시 로그인이 불가능할 수 있으므로 VPS에 대한 SSH 연결을 끊지 않도록 주의하세요.

  • 여유 공간 지우기사용자 데이터를 포함할 수 있는 각 마운트된 파일 시스템에서:

    각 사용자 데이터 파일 시스템에 대한 2개의 마운트 지점 MOUNTPT:

    # mkdir MOUNTPT/scrub
# scrub -X MOUNTPT/scrub

    예를 들어, /home자체 파일 시스템에 있는 경우 /home/scrub디렉토리를 생성합니다 scrub -X. 각 파일 시스템에 대해 개별적으로 이 작업을 수행해야 합니다. 그러면 파일 시스템이 채워집니다.의사 난수소음.

    루트 파일 시스템에 사용자 데이터가 있는 경우에는 이 작업을 수행하지 마십시오. 루트 파일 시스템을 채우면 시스템이 충돌할 수 있습니다.

  • 불타는 세계. 이 시점에서 OS가 충돌하지 않았고 쉘이 해당 세션을 삭제하지 않은 경우 등을 사용하여 세상을 불태울 수 있습니다.

    # find /var /home /etc -type f -exec scrub {} \;

    Unix의 파일 잠금 방식을 사용하면 이 명령을 실행할 때 로그인에 필요한 파일을 덮어쓰더라도 VPS에 대한 연결이 끊어지지 않을 수 있습니다. 이 문제가 발생하면 더 이상 마지막에 어떤 명령도 실행할 수 없게 될 수 있습니다. 그것은 분명히 "당신이 앉아 있는 가지를 자르는 것"과 같은 명령입니다.

    이 작업이 완료된 후에도 여전히 로그인되어 있으면 이제 루트 파일 시스템의 여유 공간을 지울 수 있습니다.

    # mkdir /scrub
# scrub -X /scrub

  • VPS를 확인하세요.마지막으로 VPS 제어판에 로그인하여 다른 운영 체제를 사용하여 VPS를 다시 설치하도록 지시하십시오. VPS 제공업체가 제공하는 가장 크고 기능이 풍부한 제품을 선택하세요. 이렇게 하면 VPS 디스크의 일부를 신선하고 흥미롭지 않은 데이터로 덮어쓰게 됩니다. 이전 단계에서 놓친 민감한 콘텐츠를 덮어쓸 가능성이 있습니다.

위의 모든 명령에서는 scrub(1)기본값이 합리적이므로 특별한 옵션을 제공하지 않았습니다. 특히 편집증적인 느낌이 든다면 scrub더 많은 패스, 다양한 데이터 적용 범위 모드 등을 사용하는 방법이 있습니다 .

Scrub은 데이터 덮어쓰기 기술을 사용하며 이를 극복하려면 영웅적인 조치가 필요합니다. 동기 부여가 되는 질문은 다음과 같습니다. 누군가가 귀하의 데이터를 복구하기 위해 얼마나 많은 작업을 하려고 합니까? 이는 위의 단계를 수행하고 다른 단계를 추가하는 것에 대해 얼마나 편집증적이어야 하는지 알려줍니다.

가상 머신의 특성상 VPS 마이그레이션 등의 이유로 사용자 데이터가 호스트 시스템에 "반향"될 수 있지만 이러한 반향은 외부인이 액세스할 수 없습니다. 이러한 사항에 관심이 있다면 애초에 VPS 제공업체를 선택해서는 안 됩니다.

사용자 데이터 트리의 표준 목록 2 에 다른 디렉터리를 추가하는 경우 정리 순서는 대부분의 사용자 중심에서 가장 적은 사용자 중심 순이므로 해당 디렉터리를 초기에 정리해야 합니다.

사용자 중심이 가장 적은 부분은 시스템 자체의 기능에 영향을 미치는 파일 시스템의 일부인 경향이 있으므로 마지막에 수행하십시오. 정리가 완료될 때까지 VPS에서 자신을 잠그고 싶지 않습니다.

  1. 스크럽은 이식성이 뛰어나며 이미 운영 체제의 패키지 저장소에 있을 수 있지만 소스에서 빌드해야 하는 경우어렵지 않아요.

  2. 일반적으로 사용자 데이터를 포함하는 트리는 /home, /usr/local및 /var이며 /etc, 사용자 데이터는 시스템 기본 데이터보다 "밀도"가 감소합니다. 시스템 관리 스타일이나 VPS 관리 소프트웨어 기본 설정으로 인해 이 목록에 추가 디렉터리를 추가해야 할 수도 있습니다.

    우리는 널리 사용 가능한 파일 복사본만 포함해야 하고 따라서 지루한 /usr/bin장소와 같은 장소를 정리하는 데 신경 쓰지 않을 것 입니다. /lib(운영 체제, 공개 소스에서 설치한 소프트웨어 등)

답변2

먼저 개인 데이터가 포함된 모든 파일을 삭제하세요. 이는 /home, in /srv, /etc사용자 정의한 모든 항목, 로그인 /var/log, 이메일 입력 /var/mail및 일반적으로 이와 유사한 기타 많은 항목 의 파일을 의미합니다 /var. 일부 최소한의 네트워크 구성, 특히 필요한 경우 SSH 키만 유지하십시오(삭제 중에 일회용 SSH 키를 생성하고 나머지는 삭제할 수 있음).

루트를 제외한 모든 파티션을 덮어쓰고 마운트 해제합니다.

# you shouldn't have any open file on non-root partitions at this point
umount /srv
</dev/zero cat >/dev/sda2

이제 빈칸을 채우세요:

</dev/zero cat >/zero
rm /zero

그 시점에서 대부분의 데이터는 사라졌습니다. 일부 파일 시스템에서는 각 파일의 마지막 블록에 일부 데이터가 남아 있을 수 있습니다. 예를 들어 1kB 블록이 있는 파일 시스템에서 파일 길이가 2000바이트인 경우 끝에 48개의 사용되지 않은 바이트가 있습니다. , 제 생각엔 이 사용되지 않는 공간은 항상 0으로 처리되어 있는 것 같아요.

마지막 "작별 인사"의 경우 가능한 한 많은 서비스를 종료한 다음 루트 파티션을 덮어씁니다.

</dev/zero cat >/dev/sda1

시스템을 다시 시작할 수 없습니다.

0 대신 여러 임의 채널로 덮어쓰지 마십시오. 이 조언은 1990년대의 디스크 기술을 기반으로 하며 더 이상 관련이 없습니다. 운. 바라보다디스크 덮어쓰기자세한 내용을 보려면 링크를 클릭하세요.

관련 정보