파일은 변합니다.
이것은 시간만큼이나 오래된, 혹은 최소한 시스템 관리만큼이나 오래된 이야기입니다. Debian이나 Ubuntu 시스템에 패키지를 설치하고 나면 한동안은 모든 것이 완벽해 보입니다. 그러다 보면, 공격적인 스크립트가 무언가를 잘못 건드리거나, 누구인가가 함부로 설정 파일을 만지거나, 아니면 갑작스러운 종료 후 디스크가 말썽을 부릴 수도 있죠. 갑자기 머리를 긁적이며 생각하게 됩니다. ‘이게 내가 기대했던 상태 그대로일까? 뭔가, 어쨌든, 건드려진 걸까?’
<a href="/tag/debsums/">debsums</a>가 그 질문에 대한 답을 줍니다.
알잖아요, 우리 모두 그런 경험이 있다는 것을. 뭔가… 이상하게 작동하는 시스템 앞에서 말이죠. 로그를 검색하고, 디렉터리를 diff하고, 어둠 속에서 허우적거리며 몇 시간을 보낼 수도 있습니다. 아니면, 바로 이런 종류의 디지털 탐정 업무를 위해 만들어진 도구를 사용할 수도 있습니다. Debian 기반 시스템에서 그 도구는 바로 debsums입니다.
화려하진 않습니다. 헤드라인을 장식할 만한 물건도 아니죠. 하지만 패키지가 설치한 파일들이 실제로 디스크에서 변경되었는지 알고 싶을 때, 이것이 당신의 해결책입니다. 솔직히 말해, 이 엄청난 기술적 과대광고의 세계에서 이렇게 근본적으로 실용적인 것을 찾는 것은 분명한 승리입니다.
취약점 스캔을 넘어서
자, 이것을 모든 것을 해결하는 만능 보안 도구라고 착각하기 전에, 잠시 숨을 고릅시다. debsecan 도구를 만드는 사람들은 알려진 취약점, 보안팀을 긴장시키는 CVE를 찾는 데 집중합니다. debsums는 완전히 다른 게임을 하고 있는 겁니다. 패키지가 취약한지 묻는 것이 아닙니다. 그 패키지가 설치했던 파일들이 원래의 파일들인지 묻는 것이죠.
이렇게 생각해보세요. debsecan은 당신의 신분증을 확인하여 감시 목록에 있는지 보는 경찰관과 같습니다. debsums는 당신의 짐을 짐 목록과 비교하는 경비원이고요. 두 가지 다른 임무지만 둘 다 중요합니다. 하지만 당신은 용의자를 심문하기 위해 짐 스캐너를 보내지 않잖아요.
debsums는 시스템의 파일들을 MD5 체크섬과 비교하여 마법을 부립니다. 이 체크섬들은 각 패키지에 대해 /var/lib/dpkg/info/*.md5sums에 깔끔하게 보관되어 있습니다. 디스크 상의 파일에 대해 계산된 체크섬이 해당 .md5sums 파일에 기록된 것과 일치하지 않으면, debsums는 깃발을 올립니다.
무엇을 감지할 수 있을까요?
- 로컬에서 수정된 패키지 파일 (가장 흔한 원인).
- 완전히 사라진 파일.
- 발생할 수 있는 특정 종류의 데이터 손상 또는 비트 부패.
하지만 매뉴얼 페이지에서 빠르게 지적하듯 – 그리고 이 점은 주의해야 합니다 – 이것은 완전한 보안 감사가 아닙니다. 주로 로컬에서 조작되었거나 하드웨어 문제로 손상된 파일을 찾는 데 사용됩니다. 이 구분이 기대치를 설정하는 데 매우 중요합니다.
시작하기: 쉬워요 (대부분)
Debian이나 Ubuntu를 사용 중이라면, debsums를 설치하는 것은 몇 가지 표준 명령어로 간단하게 해결됩니다:
sudo apt-get update
sudo apt-get install debsums
확실히 설치되었는지 확인하려면, 간단히:
debsums --version
을 실행하면 됩니다.
처음 둘러볼 때는 작게 시작하세요. 특정 패키지, 예를 들어 bash가 문제를 일으킨다면, 이렇게 실행하세요:
debsums bash
모든 것이 정상이라면, 아마 아무런 출력도 없을 겁니다. 시스템 관리 세계에서는 이것이 좋은 침묵입니다.
빠른 분석을 위해, 특히 문제만 확인하고 싶을 때, --silent 플래그가 유용합니다:
debsums --silent bash
이것은 변경되지 않은 파일에 대한 모든 출력을 억제하여 오류만 남깁니다. 아주 편리하죠.
이제, 당신의 전체 호스트를 빠르게 훑어보는 작업 – 제가 시스템 상태 점검 시 사용할 만한 명령입니다 – 이것이 당신의 티켓입니다:
sudo debsums -c
-c 플래그는 --changed를 의미하며, --silent를 내포합니다. 즉, 실제로 수정된 파일만 보고합니다. 이 명령이 아무것도 반환하지 않으면, 보통 안도의 한숨을 쉴 수 있습니다.
설정 파일: 조심스럽게 다루세요
여기서 debsums가 좀 더 미묘해지는 지점이 있습니다. 솔직히 말해, 이것은 영리한 부분입니다:
기본적으로 debsums는 /etc에 있는 설정 파일들을 적극적으로 무시합니다. 왜일까요? 이 파일들은 변경될 것으로 예상되기 때문입니다. 애플리케이션을 설치할 때, 종종 설정 파일을 조정해야 합니다. 이러한 사용자 정의 변경 사항을 패키지의 기본값으로 덮어쓰는 것은 재앙이 될 것입니다.
만약 설정 파일도 검사에 포함시키고 싶다면 – 아마도 의도하지 않은 변경을 걱정하는 경우 – -a 플래그( --all의 약자)를 사용할 수 있습니다:
sudo debsums -ca
그리고 설정 파일만 확인하고 싶다면, 그것도 가능합니다:
sudo debsums -ce
이 옵션들은 신중하게 사용하세요. 변경된 설정 파일이 항상 나쁜 것은 아닙니다. 때로는 정상적이고 책임감 있는 시스템 관리의 결과일 뿐입니다.
체크섬이 누락된 경우
모든 패키지가 편리한 .md5sums 파일을 제공하는 것은 아닙니다. debsums는 -l 플래그를 사용하여 이 정보가 누락된 패키지를 알려줄 수 있습니다:
debsums -l
이것이 해당 패키지가 본질적으로 손상되었거나 깨졌다는 것을 의미하지는 않습니다. 단지 debsums가 애초에 체크섬이 없기 때문에 로컬 체크섬과 비교하여 해당 패키지의 파일을 검증할 수 없다는 의미입니다. 이러한 경우는 개별적으로 처리해야 하며, 패키지 저장소를 신뢰하거나 더 깊은 수동 검사를 수행해야 할 수도 있습니다.
체크섬 캐시 재구축
debsums가 더 많은 데이터를 활용하도록 만들고 싶다면, 특히 체크섬이 누락된 패키지에 대해 어떻게 해야 할까요? Debian 매뉴얼 페이지에는 멋진 트릭이 있습니다. APT 캐시에 패키지 아카이브를 다운로드하는 것입니다.
먼저, 체크섬이 누락된 패키지 목록을 가져옵니다:
debsums -l
그런 다음, 해당 목록을 사용하여 관련 .deb 파일을 다운로드합니다:
sudo apt-get --reinstall -d install $(debsums -l)
이것은 /var/cache/apt/archives 디렉터리를 채웁니다. 이제 debsums는 이 캐시된 아카이브를 사용하여 이전에 사용 불가능했던 곳에서 체크섬을 생성할 수 있습니다. 그런 다음 -g (generate) 및 -p (path) 플래그를 사용하여 더 포괄적인 검사를 수행할 수 있습니다:
sudo debsums -cagp /var/cache/apt/archives
각 플래그의 의미는 다음과 같습니다:
-c: 변경된 파일을 표시합니다.-a: 설정 파일을 포함합니다.-g: 체크섬이 누락된 패키지의 체크섬을 생성합니다 (캐시된.deb파일을 사용).-p /var/cache/apt/archives: 캐시된.deb파일이 있는 디렉터리를 지정합니다.
이 명령어 시퀀스는 Debian 호스트에서 실행할 수 있는 가장 강력한 무결성 검사 중 하나라고 할 수 있습니다. 이것은 단순히 빠른 수정을 찾는 것을 넘어선 전체 시스템 스윕입니다.
시스템 검사를 위한 실용적인 워크플로우
만약 문제가 있는 Debian 서버를 점검하는 임무를 맡게 된다면, 제가 아마 진행할 순서는 다음과 같을 것입니다:
-
변경 사항에 대한 빠른 스캔:
bash sudo debsums -c설치 이후 수정된 파일에 대한 즉각적인 확인을 제공합니다. 이것이 당신의 첫 번째 방어선입니다. -
설정 파일 포함:
bash sudo debsums -ca초기 스캔에서 아무것도 나오지 않았지만 여전히 의심스럽다면, 설정 파일을 포함하도록 범위를 넓히세요. 기억하세요, 이것들은 종종 의도적으로 변경되지만, 무엇이 변경되었는지 아는 것은 좋습니다. -
체크섬이 없는 패키지 식별:
bash debsums -ldebsums가 확인할 수 없는 패키지를 표시합니다. 이들은 별도로 조사해야 합니다. -
누락된 패키지 아카이브 다운로드:
bash sudo apt-get --reinstall -d install $(debsums -l)필요한 파일을 가져와서 더 심층적인 검사를 준비합니다. -
포괄적인 무결성 스윕:
bash sudo debsums -cagp /var/cache/apt/archives이것이 대망의 피날레입니다. 사용 가능한 모든 정보를 활용하여 시스템 무결성에 대한 가장 명확한 그림을 제공하는 철저한 검사입니다.
이러한 체계적인 접근 방식은 /usr 아래의 파일을 무작위로 diff하면서 올바른 문제를 우연히 발견하기를 바라는 것보다 훨씬 더 명확한 신호를 제공합니다. 이것은 체계적입니다.
변경 사항으로부터 복구하기
그렇다면, debsums -c가 /usr/bin/example-tool과 같은 수정된 파일을 출력했습니다. 이제 어떻게 해야 할까요? 어떤 패키지가 그것을 소유하고 있는지 알아야 합니다. dpkg -S 명령이 당신의 친구입니다:
dpkg -S /usr/bin/example-tool
이것은 example-package: /usr/bin/example-tool과 같은 결과를 보여주며, 책임 있는 패키지를 명확하게 식별합니다.
패키지 이름을 얻으면, 재설치를 진행할 수 있습니다. debsums 매뉴얼 페이지에서는 이를 위한 파이프라인을 설명하지만, 단계별로 나누면 더 많은 제어를 할 수 있습니다:
-
변경된 파일 찾기:
bash sudo debsums -c -
모든 변경된 파일의 소유 패키지를 가져와 고유하게 만들기:
bash dpkg -S $(sudo debsums -c) | cut -d: -f1 | sort -u -
해당 패키지 재설치:
bash sudo apt-get install --reinstall $(dpkg -S $(sudo debsums -c) | cut -d: -f1 | sort -u)
마지막 명령어는 신중하게 사용하세요. 이것은 패키지 관리 파일을 원래 상태로 복원하는 데 매우 유용합니다. 하지만, 변경된 모든 파일을 맹목적으로 덮어써야 한다는 마법 지팡이는 아닙니다. 만약 해당 파일이 의도적으로 변경되었고 그 변경 사항이 여전히 필요하다면, 전체 재설치는 시스템을 망가뜨릴 수 있습니다. 맹목적으로 복원하기 전에 파일이 변경된 이유를 항상 이해하세요.
이것은 절대적이고 달성 불가능한 보안에 관한 것이 아닙니다. 이것은 실용적이고 검증 가능한 무결성에 관한 것입니다. 그리고 이를 위해, debsums는 Debian 관리자의 툴킷에서 빼놓을 수 없는 도구입니다. 억측을 걷어냅니다.
🧬 관련 통찰
- 더 읽어보기: GitHub의 AI 보안, 저장소의 모든 스크립트와 설정을 꿰뚫다
- 더 읽어보기: 출시까지 일주일: 장애 사과문을 작성하는 AI
