[보안] 파일 무결성 검사 ( Tripwire )

Tripwire

April 30, 1999

파일 무결성 검사도구인 Tripwire에 대한 사용자 입문서이다.  Tripwire

소스와 함께 http://tripwiresecurity.com 에서 제공한다.

_______________________________________________________________

목차

1. 저작권

2. 빠른 시작

   2.1 Tripwire의 설정과 설치

   2.2 Tripwire 고객을 위한 공개 편지

   2.3 공개 편지

3. Tripwire 설치

   3.1 이 문서에 관하여

   3.2 Tripwire에 관하여

4. Tripwire 설정하는 법

   4.1 Tripwire 설정하는 법

   4.2 서명 절차

5. Tripwire 실행

   5.1 Tripwire 사용법

6. Tripwire FAQ

   6.1 빈번한 질문들(FAQ)

_____________________________________________________________

1.  저작권

Tripwire(TM) 소프트웨어에 관련된 모든 파일은 ‘Tripwire 보안 시스템즈

(Inc)’의 소유이며 독점적인 라이센스를 가집니다. 즉 모든 권한을 가지고

있습니다. 이 배포판에 있는 몇개의 파일들은 내부의 주석에 의해 명시된

것처럼 다른 저작권하에 있을 수 있습니다.

이 배포판은 단일 CPU, 단일 장소, 최종 사용자를 위한 문서입니다.

복제는 백업할 목적에 의해서만 허용됩니다. 이 소프트웨어를 다른 용도로

사용하기 위해서는 우선 ‘Tripwire 보안 시스템즈(Inc)’의 동의를 얻어야

합니다.  만일 이 소프트웨어가 웹 사이트에 사용된다면 ‘Tripwire

Protected’라는 로고가, 당신의 홈페이지에 적절한 저작권과 트레이드

마크와 함께 사용되 어야 합니다. 권한에 의해 쓰기전에 , 이 제품을

추천하는데 있어서 Puedue 대학 이름이나 저자의 이름이 사용되어서는

안됩니다.

이 소프트웨어는 이렇게 제공되며 보증, 허용, 무제한, 상업적 목적의

묵시적인 보증과 어떤 특별한 목적에 적합하다는 표현 또는 묵시적인

동의를 하지 않습니다.

Copyright 1998-99 Tripwire(TM) Security Systems, Inc.  Tripwire is a

trademark of the Purdue Research Foundatio and is licensed exclusively

to Tripwire Security Systems, Inc.  All references to other brands or

trademarks are the property of their respective owners.

2.  빠른 시작

2.1.  Tripwire의 설정과 설치

Tripwire의 적절한 설정, 설치, 그리고 사용을 위해서 다음의 과정을

따르시오.

1.

2.

3. FAQ 부분을 읽는다.

4. 본인 사이트에 적절한 값으로 include/config.h 파일을 수정한다.

5. 남은 과정을 위하여 단일 사용자 모드로 들어간다.

6. 더이상 수정한 것이 없도록 본인의 운영체제에서 실행 파일들을

   재설치한다.

7. 데이터베이스 초기화 모드로 Tripwire를 동작시킨다.

8. 목적지 디렉토리의 디스크를 읽기전용으로 만든다. 그리고(또는) siggen

   유틸리티를 사용하여 모든 파일에 유일한 서명(signature)을 남긴다.

9. 일반적인 작업들을 다시 시작한다.

강력히 추천하는 과정으로 , 이 과정을 실행했다면 보안 사고가 발생한

경우에도 가능한 최소한의 시간에 어떤 손상된 데이터도 복구할 수 있을

것이다.

2.2.  Tripwire 고객을 위한 공개 편지

2.3.  공개 편지

3.  Tripwire 설치

3.1.  이 문서에 관하여

이 문서는 Tripwire입문서이다. 여기서는 Tripwire의 설정, 테스트, 그리고

수행에 필요한 정보를 제공한다. 설계와 기술적인 이론을 자세히 알고

싶다면, ./doc 디렉토리에 Tripwire 설계 문서가 있으며 또한 기술

리포트(TR-CSD-93/71)가 제공중이라는 것을 염두해 둬라.

3.2.  Tripwire에 관하여

Tripwire는 파일 무결성 보관 도구로, 이전에 생성된 데이터베이스에

저장된 정보와 지정된 파일과 디렉토리를 비교하는일을 한다.  Tripwire는

모든 변화를 감지하며 목록의 추가와 삭제도 포함한다. 일반적인

기반하에서 시스템 파일에 대하여 동작중일 경우 중요한 파일들의 어떤

변화도 감지할 수 있으며, 그 즉시 적절한 손해 정도를 측정할 수 있다.

시스템 관리자는 Tripwire가 이상무라는 보고를 하면, 주어진 파일 목록

중에는 마음대로 , 권한없이 수정된 파일이 없다는 것을 명백히 확신할 수

있다.

Tripwire는 다양한 유닉스 변종들에서 설정되고 테스트되었다.  이글을 쓴

시점에서, Tripwire는 BSD, OSF/1, Mach, Xenix, 그리고 유닉스의 최근

System V 변종에서도 성공적으로 동작한다.

Tripwire 설정하는 법

1. 어떤 파일을 수정하거나 프로그램을 설정하기 전에 README 파일을 다시

   한번 보기 바란다. 이 문서는 설정과 실행에 대한 다양한 설명과

   방법들을 설명한다. 시스템의 옵션을 선택하고 방법을 설정했다면 다시

   한번 보기 바란다. 이 문서는 설정과 실행에 대한 다양한 설명과

   방법들을 설명한다. 시스템의 옵션을 선택하고 방법을 설정했다면 다시

   이 부분으로 돌아와서 명령을 따르길 바란다.  목록을 가지고 있다. 이

   목록에서 당신의 시스템을 발견하게 된다면, Tripwire 설정에 사용된

   시스템 세팅을 참고해두어라.

2. Makefile을 살펴보고 C 컴파일러와 모든 플래그 세팅이 당신의 설정에

   적합한지 확인하라. 대부분의 시스템 세팅은 ‘Ported’ 파일의 목록에

   있다.

3. 파일에 이 파일 이름을 삽입해야 할 것이다) 만일 그런 파일이 존재하지

   않을 경우 당신의 시스템 파일과 비슷한 것을 하나고르고, 그것을

   적절하게 수정해야 한다. 수정된 유형은

   support at tripwiresecurity.com으로

메일보내주기 바란다.

   절대로 이 파일을 config.h파일에 덮어쓰면 안된다.

4. 정의된 헤더 파일에서 가장 유사한 것을 찾아서 적절한 라인을

   넣어준다.

   Tripwire 설정 파일의 경로와 이름은 또한 config.h 파일에 정의되어

   있다.  Tripwire가 설정과 데이터 베이스 파일을 참고하는 경로를

   반드시 기억하고 있어야 한다.  이것은 당신의 시스템에 따라 적절하게

   바뀌어질 수 있다.

   중요 : 디스크에서 Tripwire 설정 파일이 위치한 곳은 하드웨어 설정에

   의해서 읽기 전용이어야 한다. 이로서 침입자에 의한 파일의 수정을

   예방할 수 있다. 현재 사용중인 버전의 Tripwire는 같은 곳에 위치해야

   한다.  만약 디스크를 읽기 전용으로 만들수 없다면, 더 안전한 기계의

   원격 파티션에 옮겨놓을 수 있다. 읽기 전용이라는 점은 중요하다.

5. 다시 ‘./config’ 디렉토리를 참고하여 당신의 운영체제와 일치하는

   tw.config 파일을 찾는다. 이 파일들은 다양한 업체에서 지원하는

   운영체제의 구조에 맞도록 수정되어 있다. 이 하부 디렉토리에서 당신의

   시스템과 일치하는 파일을 찾지 못할 경우, 가장 비슷한 것을 선택한다.

6. 지역의 실행 파일과 중요한 데이터베이스, 그리고 감시하고 싶은 파일을

   추가하기 위해서 이 파일을 편집한다. 만일 파일이 옮겨졌거나 원격에서

   마운팅된 경우( 오직 서버에 있는 경우만 체크한다) , 검사에서 제외할

   파일들이 있는 경우 , 올바른 경로 명세가 필요하다. 당신은 Tripwire

   실행 파일 자체도 설정 파일에 추가할 수 있는데, 이것은 나중에

   Tripwire가 검색하는 것들에 대해 확신을 가지게 한다.

   tw.config 파일을 최적화한 뒤에 , config.h 파일에 그 경로를 복사해야

   한다.

7. 설정 환경을 만든 뒤에는 최상위 디렉토리에서 단순히 ‘make’라고

   입력하면 된다. 모든 하부 디렉토리의 Makefile이 최상위 디렉토리의

   Makefile에 의해 제어된다는 사실은 알아두라 (./src 디렉토리에서

   ‘make’라고 입력하면 아마 동작하지 않을 것이다)

일반적인 Tripwire 컴파일 문제

Tripwire는 원래 ANSI C로 작성되었다. 하지만 , 이제는 K&R 로도 컴파일

할 수 있다. 모든 프로토타입은  ‘#ifdef_STDC_’ 지시자 사이에 남겨진다.

ANSI에서의 컴파일은 때때로 K&R 보다 더 어려울 때가 있다.  만일 당신의

시스템이 ANSI를 요구하지 않는다면 K&R로 컴파일 하는 것을

추천한다.(코드의 무결성은 malloc() 과 exit()의 반환값을 제외하고는

완벽하게 깨끗한 것이다)

일반적인 컴파일 문제는 dirent(S5)/direct(BSD) 문제와 POSIX에 따른

#define의 변화이다. 만일 Tripwire 테스트 목록이 실패한다면 다음 과정을

일반적인 컴파일 문제는 dirent(S5)/direct(BSD) 문제와 POSIX에 따른

#define의 변화이다. 만일 Tripwire 테스트 목록이 실패한다면 다음 과정을

따른다.

o  당신의 ./include/config.h 파일이 적절한 conf-*.h 파일인지 체크하라.

o  Makefile 에서 CFLAGS 선언을 바꾸어서 어떤 최적화도 완료되지 않도록

   한다.  (‘-O’ 옵션을 삭제한다)

o

o  컴파일을 재시도한다.

만일 당신이 flex와 bison을 사용한다면, 컴파일 시의 에러를 피하기 위해

gcc 컴파일러를 사용해야 한다. 이것이 실패하면 다른 종류의 C 컴파일러를

시도한다(예를 들어 GCC).

GNU에서 lex와 yacc를 대체한 새 버전의 flex와 bison은 기본적인 Tripwire

소스를 사용하는 테스트 목록에서 코드를 생성하지 않고 통과해버린다.

Calvin 페이지에서는 config.pre.1과 config.pre.y 파일을 대체하여 이

문제를 해결할 수 있도록 했다. lex를 사용하면 Tripwire 테스트 목록에

실패하는 문제를 해결할 수 있다.

./sig/sha의 SHA 코드가, 많은 최적화된 C 컴파일러에서 어렵게

다루어진다는 사실도 명심하라. 예를 들어 Sun OS 4.x 에 제공되는 stock C

컴파일러는 이 파일을 -O 옵션으로 컴파일 하는데 스팍스테이션10에서 2분

정도 걸린다.  다른 컴파일러(GCC 같은)도 이 문제를 해결하지 못한다.

Tripwire 테스팅

Tripwire는 배포판 패키지에 최상위 설정 디렉토리를 체크할 수 있는,

스크립트 기반의 테스트 목록이 제공된다.  ./test 디렉토리에는 완전한

Tripwire소스가 있는 데이터베이스와 tw.config 파일이 있다. 이 테스트

스크립트는 당신의 시스템에 맞는 Tripwire 파일 이름으로 자동 변환

시켜준다. 파일이 변환된 뒤에는 Tripwire가 무결성 검사 모드로 동작한다.

테스트를 동작시키기 위해서, 최상위 디렉토리에서 ‘make test’라고

입력하면 된다.  이것은 스크립트를 동작시키고, 만일 모든 것이 제대로

수행되면, 스크립트가 제공하는 값은 Tripwire의 결과와 일치하는 값일

것이다.

Tripwire 배포판의 모든 파일을 체크하고 덧붙여서, 컴파일된 프로그램이

올바로 동작하는지 몇개의 서명과 기능적인 테스트를 수행한다.

4.  Tripwire 설정하는 법

4.1.  Tripwire 설정하는 법

큰 사이트에서 Tripwire를 사용하기 위한 약간의 팁

tw.config.5 매뉴얼 페이지에서 tw.config 파일에 지원되는 문법을

상세하게 설명해 놓았다. Tripwire는 C 선행처리기에 유사한 기능을

제공하며, 로컬 디스크에 수백개의 워크스테이션을 관리할 수 있도록

Tripwire를 사용하는 다른 지시자를 제공한다.

tw.config 문법

이 명령어들은 아래에 간단히 설명된다.

______________________________________________________________

@@deifne VAR VALUE

@@undef VAR

@@ifhost HOSTNAME

@@ifnhost HOSTNAME

@@ifdef VAR

@@ifndef VAR

@@else

@@endif

@@include FILENAME

____________________________________________________________

게다가 tw.config 문법은 논리적 연산도 지원한다. 예를 들어, 당신의

tw.config 파일에 다음 구절을 넣을 수 있다.

______________________________________________________________

@@ifhost spam.cc.purdue.edu || weiner.cc.purdue.edu

…entries…

@@endif

______________________________________________________________

cpp와 같은 기능을 제외하고 @@를 사용할 수 있는데 실시간으로 해석되는

문자열을 생성하는 역할을 한다. 다음과 같이 사용된다.

______________________________________________________________

@@ifhost mentor.cc.purdue.edu

@@ define TEMPLATE_S +pinug-cas0123456789

@@else

@@ define TEMPLATE_S +pinug012-cas3456789

@@endif

/etc/tw.loginfo        @@TEMPLATE_S

_____________________________________________________________

이들 지시자를 사용하는 법

Tripwire는 tw.config 파일의 실시간 해석(interpretation)을 허용하기

때문에 많은 다른 호스트가 같은 tw.config 파일을 공유하는 것도

가능하다.  이 때문에 Tripwire 설정 파일은 크고 이질적인 환경에서도

유지될 수 있다.  비록 각각의 호스트가 반드시 서로다른 데이터베이스

파일을 가져야 하지만, 디스크 위치의 문제일 뿐이므로 별로 중요한 것은

아니다.

4.2.  서명 절차

RSA 데이터 시큐리티(Inc). MD5, MD4, 그리고 MD2 메시지 암호화 알고리즘,

Snefru(제록스 보안 해쉬 함수), SHA(보안 해쉬 알고리즘), 그리고 Haval

코드는 실시간으로 특정한 절차에 의한 크고 작은 변화를 제거할 수 있도록

변화되었다. 이 문제가 본인에게 돌아왔지만 우리는 아직도 제품이

반환되리라고 걱정하지 않는다. 그때까지 이 패키지의 코드와 그들의 원본

배포판간에는 약간의 차이가 남아있다.

성능(Performance) Vs. 보안(Security)

보안과 속도의 균형을 맞춘다는 것은 관리자의 결정이 가장 중요하다.

보안과 속도의 균형을 맞춘다는 것은 관리자의 결정이 가장 중요하다.

보통은 파일당 하나의 체크섬만 있으면 변화를 감지하기에 충분하다.

속도가 목적이라면 손쉽게 계산할 수 있는 체크섬이 유리하다. 하지만 쉽게

계산되는 서명키의 대부분은 침입자가 깨고 싶은 마음만 있다면 쉽게

깨버릴 수 있다 (설계 문서의 도표를 보면 무차별 대입이 얼마나 쉬운지

알수 있을 것이다).

Tripwire는 16,32 비트 CRC 알고리즘을 사용하는 MD2,MD4,SHA,그리고 Haval

서명키 알고리즘을 포함한다. 기본적으로 두개의 서명(MD5 와 Snefru)으로

각각의 데이터베이스 목록에 서명하는데 , 파일의 접근 흔적을 감시한다는

매우, 매우 강력한 확신을 줄 수 있다.  파일을 성공적으로 서명했다면

침입자는 파일을 수정하고, 파일의 크기를 변화시키지 않은 채로 적절한

단어를 삽입해서 두개의 체크섬을 재생성해야 한다. MD5와 Snefru 체크섬이

사용된다면 , 임의로 이런 행동을 하는 것은 불가능하다. 이들 두

알고리즘은 철저하게 분석하는 것은 아니지만, 강한 메시지 인증 코드로

알려져 있다.

하지만 이 보증을 더하는 것은 많은 부담이 든다. 두 알고리즘과 특별히

Snefru를 사용하면 계산이 힘들어진다. 모든 파일에 MD5와 Snefru

알고리즘을 사용한다면 거의 모든 시스템은 다운될 것이다.  체크섬 두개를

사용하는 것은 가장 중요한 파일일 경우뿐이다. Tripwire 데이터베이스와

프로그램, 그리고 당신의 시스템에 존재하는 setuid와 setgid 파일 모두가

해당된다.  MD5(또는 Haval) 단독으로 모든 파일을 체크하는 것이 더 빠른

연산과 신뢰 수준을 높여줄 것이다. 파일을 변형하거나 원래의 MD5

체크섬을 재생성하는 작업은 매우 어렵다. 어렵게 보여지만 대부분이

결정되어 있기 때문에, 숙련된 침입자는 유한한 시간 동안에 할 수 있지만

말이다.

Tripwire의 실시간 수행 크기를 줄이기 위해서는 당신의 Tripwire.config

목록에서 Snefru(서명2) 상태를 무시하여라. Snefru는 엄격한 감시를

수행하는 파일이다.  이 작업은 Snefru 서명이 완전히 수집하는데 걸리는

작업을 그냥 통과한다.  하지만 미리 경고하는데, MD2는 Snefru와 비교해서

절대적으로 느리며 무결성 검사도 더 낫다고 보장할 수 없다. 하지만 우린

모든 방식을 보유하고 있기 때문에 자기 사이트에 가장 적합하다고 느끼는

것을 선택하면 된다.

당신이 다른 방식을 추가하기 위해서 체크섬/서명키 생성기(generator)를

추가할 수 있다. 예를 들어 당신이 빠른 DES 구현 도구를 가지고 있다면

(칩 기반 생성을 포함하여) , CBC 모드를 사용해서 파일을 암호화한 뒤에

몇개의 고정키를 사용하여 128비트의 최종 서명키를 저장할 수도 있다.

설정파일 규칙중에 몇개의 플래그는 현재 공백이기 때문에 당신이 원하는

만큼 확장할 수 있다.

확실한 것은 자기 마음대로 다른 서명 알고리즘을 사용하더라도 Tripwire는

데이터 보안을 보증하는 유연성을 제공한다는 것이다. Tripwire는 관리자가

사용하기 쉽도록 사소한 CRC 데이터베이스도 유지하고 전체(비효율적일수도

있지만) 8개의 서명키로 데이터베이스를 체크할 수도 있다.

다음 절에서는 8개의 서명 알고리즘을 설명한다.

서명 절차

이 절은 간단히 각각의 서명 절차를 설명한다. 이것은 권위있는 목록은

아니지만, 각각의 서명 절차가 제공하는 배경 지식을 알려줄 것이다.

MD5,MD2,SHA, 그리고 Haval은 모두 메시지 암호화 알고리즘이다(단방향

해쉬 함수, 표식(fingerprint) 절차, 메시지 인증 코드, 또는 조작 검출

코드로 알려져 있다).  이것들은 암호화 기법을 사용하여 입력에서의 작은

변화가 그 즉시 크게 다른 결과로 나타나게 한다. 게다가 이들 알고리즘은

128비트 또는 그 이상의 서명 을 사용하기 때문에 무차별 대입 공격으로

변화가 그 즉시 크게 다른 결과로 나타나게 한다. 게다가 이들 알고리즘은

128비트 또는 그 이상의 서명 을 사용하기 때문에 무차별 대입 공격으로

같은 서명을 유지하면서 파일을 수정하려는 시도는 컴퓨터로도

실행불가능한 작업이 되었다.

반대로 CRC 알고리즘은 간단히 여러개로 나누어서 체크섬을 생성한다. 이

기법은 상당히 빠르고 수학적으로도 이해하기 쉽다. 게다가 서명키를 위한

공간이 아주 작은 경우(보통 16또는 32비트) 무차별 대입 공격으로 CRC

충돌을 시도할 경우 대개의 워크스테이션 능력으로도 충분하다.  현제 공개

도메인에 몇개의 프로그램이 있으며, 주어진 입력 파일이 없어도 30초

이내에 같은 CRC 서명으로된 다른 출력 파일을 만든다.

서명 절차에서 제공되는 시간 측정은 모두 16MHz 80386 프로세서 10개를

병렬 처리한 기계로 측정한 것이다. 제공된 프로세서는 어떤 정해진 규격이

아니라 비정형적인 처리량을 보인다.

MD5

MD5는 RSA 데이터 시큐리티(Inc)의 메시지 압축 알고리즘으로 데이터 인증

기준을 제공한다. 인터넷 설계 제안(draft submisson)은 인터넷 작업 설계

(working draft) RFC 1321에서 발견되며 이 문서는 NIC.DDN.MIL의 익명

FTP나 RSA.COM의  /pub/md5.doc에서 발견할 수 있다. MD5는 빠른 속도로

잠재적인 위협 위치를 검출해낸다. 하지만 MD4보다는 보안이 약하다. MD5는

약간 보수적인 알고리즘으로 설계되어서, 암호 해독 공격이 성공할

경우같은 위협이 될 때는 ‘모서리에서 회피하기(away from the edge)로

돌아갈 수 있다.

MD5는 128비트 서명키를 생성하고, 임의의 가상 출력을 만들기 위해 네번의

과정을 통과한다. 결과물은 약 초당 70Kbyte 정도의 속도로 나온다.

현재 MD5는 많은 이로부터 예술적인(state-of-the-art) 서명 알고리즘으로

평가된다.

Snefru

Snefru, 제록스(Xerox) 보안 해쉬 함수는 Xerox PARC의 Palph Merckl에

의해 개발되었다. Snefru를 크랙하는데 장려금이 있었는데 같은 서명을

만드는데 입력해야 할 2가지 세트를 발견하는 사람에게 현금 1000달러를

준다는 것이었다.

이 상은 1990년 3월까지 깨지지 않고 남아있었는데, Snefru 의 2-패스

버전이 Adi Shamir 의 Ph.D인 Eli Biham에 의해 깨졌다. 현재 Ralph

Merkle은 8-패스 버전이 아닌 4-패스 버전의 Snefru를 추천하고 있다.

Snefru README에서는 고 말한다.

Tripwire에서는 Snefru가 4-패스로 설정되어 있다. 최근 버전은 2.5로

Tripwire에 포함되어 있다. Snefru는 MD5보다 느리다. 하지만 첫번째

서명으로의 MD5를 백업하는 작업에 유리하다.

설정대로라면 Snefru는 초당 31Kbyte의 속도를 가진다.

Snefru는 srisia.xerox.com의 익명 ftp인 /pub/hash 디렉토리에서 구할 수

있다.

CRC-32

순환적인 여분 체크(Cyclic Redundancy Check)는 오랜 기간동안 에러 검출

알고리즘으로 사용되었다. 이 알고리즘은 빠르고 강력하며 데이터 전달과

관련된 에러를 검출하는데 안정적이다. CRC-32는 최소 크기로 5블록을

차지하 는데 이것은 4K 보다도 작은 것이다. 그러나 이러한 감소가 블록의

크기를 증가시켰다. 그러므로 긴 파일에 CRC-32를 사용하는 것은 분명히 이

서명키 알고리즘을 잘못 사용하는 것이다. 하지만 CRC-32는 빠르고, 느린

크기를 증가시켰다. 그러므로 긴 파일에 CRC-32를 사용하는 것은 분명히 이

서명키 알고리즘을 잘못 사용하는 것이다. 하지만 CRC-32는 빠르고, 느린

메시지 암축 알고리즘을 상호 제어시켜 빠르게 만든다.  Tripwire에

CRC-32버전은 Gary S.Brown에 의해 쓰여졌다.  CRC-32의 동작 속도는 초당

111Kbyte정도이다.

CRC-16

CRC-16은 CRC-32 이전에 개발된 것으로 , 데이터의 여분과 다중의 생성자를

저장하는 공간으로 단지 16비트만 사용하였다. CRC-16은 일반적으로 링크

단계에서 수행되며, 하드웨어가 전송에러를 감지한다. 이 CRC-16의 동작

속도 는 초당 131Kbyte이다.

MD4

MD4는 RSA 데이터 시큐리티(Inc) 의 메시지 압축 알고리즘으로 위에서

설명한 MD5의 전신(predecessor)이다. 이것은 기본적인 데이터 인증

알고리즘으로 알려져 있으며, 인터넷 작업 설계 1320 문서에서 설명되었다.

MD4 알고리즘은 32비트 RISC 아키텍처에서 최대 산출물을 끌어내기 위해

설계되었다. 선 스팍 스테이션에서 초당 1.4Mbyte의 속도까지 가능하다.

MD4는 RSA.COM의 익명 FTP  /pub에서 구할수 있다.

평균적으로 , MD4의 산출물은 초당 332Kbyte의 속도를 가진다.

MD2

RSA 데이터 시큐리티(Inc)의 MD2 메시지 압축 알고리즘은 개인용 메일

패키지 의 부분이었다. 이 패키지는 전자 메일의 보안을 강화하고 인증을

한다.  RSA 데이터 시큐리티(Inc)의 알고리즘이 그렇듯 , MD2는 128비트의

서명을 생성한다. MD2 알고리즘은 상당히 느리다. 16MHz의 80386에서

기껏해야 초당 3Kbyte 정도의 속도를 보인다. MD5 대신 이 느린 알고리즘을

사용한다고 해서 어떤 이점이 있는것도 아니다.  MD2의 라이센스는 개인용

메일 패키지가 독점권을 가진다. RSA 데이터 시큐리 티(Inc)에서 준비한

것들은 현재 Tripwire에 포함되어 사용되는 것이다.  MD2는 공공의 소유가

아니라는 것을 명심하라.

SHA/SHS

SHS는 NIST 디지털 서명 스탠다드에서 개발한 것으로 보안 해쉬의 기준으로

알려져있다. NIST FIPS 180에서 자세히 설명되어 있다. 우리는 이것보다

보안 해쉬 알고리즘인 SHA를 선호하는데 왜냐면 우린 인증받지 않은 도구를

사용하 고 기준에 맞춘 도구들만 사용하지는 않기 때문이다.

SHA는 MD5보다 50%정도 더 빠르다. SHS는 여러개의 키를 사용하는 MD4에

많은 기반을 두었지만 MD5의 전체 구현을 받아들이지 않았기 때문이다.

1994년 중반에 NSA의 요청에 따라서 , 여러 암호학자들이 제시한 SHA와

MD4의 전체 기능에 관련된 몇가지 문제를 정정하였다(Tripwire에서 기본

버전으로 반영되었다. sigs/sha/sha.h 를 참고하여라).

Haval

Haval은 Wollongong 대학의 Yuliang Zheng에 이해 쓰여졌고, Y.Zheng ,

J.pieprzyk 그리고 J.Seberry에 의해 설명되었다.  고급 암호(Advance in

Cryptology)에서 설명한다.  Tripwire에 내장된 Haval은 다른 서명키

알고리즘과 유사하게 4-패스를 사용 한 128비트 서명을 한다. 이 방식으로

설정한다면, Haval의 결과물은 대략 초당 100K 정도의 속도를

가진다(MD5보다 30%빠르다).

빈(Null) 서명

sig_null_get()이라는 서명키는 실제로 서명키 알고리즘이 아니다.  대신

서명 배열에서 사용하지 않은 슬롯을 고정시키는 역할을 한다. 항상 단일

의견(Feedback)과 버그 리포트

버그 리포트, 질문, 의견 또는 어떠한 논평은 아래 주소로 보내라.

Support at tripwiresecurity.com

사용자 공헌(contributions)과 경험(experiences)

./contrib 디렉토리에서는 베타 테스트 기간에 사용자에게 제공했던 몇개의

프로그램이 있다. 프로그램 각각에 대하여 프로그램 제작자가 쓴 README

파일이 있다.

5.  Tripwire 실행

5.1.  Tripwire 사용법

Tripwire는 네가지 모드 중에서 하나로 동작한다. 데이터베이스 생성,

무결성 검사, 데이터베이스 갱신, 그리고 대화식(interactive) 갱신 모드가

있다. 무결성 검사를 수행하기 위해서는 비교할 데이터베이스를 가지고

있어야 한다. 그러므로, 먼저 당신은 Tripwire가 감시할 파일들의 목록을

정해놓아야 한다. 파일들의 목록은 tw.config에 저장된다.

자신의 tw.config 파일을 생성하기

tw.config 파일 또는 자신이 정의한 Tripwire 설정 파일을 열고, 감시할

파일들이 있는 디렉토리들을 추가한다. 설정 파일의 형식은 헤더에

설명되어 있고 맨 페이지에 도 있다. 플래그를 설정하고 목록에서 필요없는

것을 신중하게 제거하라. 이 작업은 Tripwire에서 쓸모없는 결과가 나오는

경우를 상당히 줄일 수 있다. 예를 들어, 당신은 운영체제에서 항상 변하는

마운팅 테이블 같은 파일을 제거할 수 있다.

다음 , ‘tripwire -initialize’ 로 Tripwire를 구동한다. 이 작업은 당신의

데이터베이스를 저장하는 디렉토리에 ‘tw.db_[호스트이름]’이라는 파일을

생성한다.

Tripwire의 변화 검출

Tripwire는 데이터베이스와 비교하여 파일들이 변화되었는지 검사한다.

당신이 생성한 초기 데이터베이스가 무결한가 확신해야 된다. Tripwire는

이미 변경된 파일들은 감시할 수 없다. 제일 좋은 방법은 단일 사용자

모드로 들어간 뒤에 시스템 파일들을 다시 설치하고 Tripwire의 초기화

모드를 실행하는 것이다. 그 다음에 다중 사용자 모드로 돌어간다.

데이터베이스는 반드시 수정할 수 없는 곳으로 이동해야 한다. 왜냐면

Tripwire가 신뢰하는 것은 그 데이터베이스 밖에 없기 때문이다. 우리는

모든 시스템 데이터베이스를 읽기 전용 디스크에 위치시키는 것을

추천한다(초기화와 갱신 모드인 경우에는 쓰기로 디스크를 변화시킬수

있어야 한다) 또는, ‘안전한 서버’에 읽기 전용 NFS로 익스포트 시키는

것도 좋은 방법이다(파일 경로는 Tripwire 코드에 저장되어 있다.

데이터베이스 저장 경로를 바꿀때면 반드시 Tripwire를 재컴파일해야 한다.

이로서 악의있는 침입자가 잘못된 ‘okay’ 메시지로 Tripwire를 스푸핑하는

것을 막을 수 있다)

또한 , 즉시 데이터베이스 내용을 프린트하는 것을 추천한다.

데이터베이스의 무결성에서 이상한 점을 발견했을 때 이 프린트를 사용하여

직접 비교할 수 있다.  크래커가 시스템에 침입해서 프린트된 종이를

변경시킨다는 것은 불가능하니까 말이다 .

직접 비교할 수 있다.  크래커가 시스템에 침입해서 프린트된 종이를

변경시킨다는 것은 불가능하니까 말이다 .

데이터베이스, 설정 파일, 그리고 Tripwire 실행파일의 서명키를 생성해야

한다.  이것은 ‘siggen’이라는 유틸리티를 사용하면 된다(siggen 의

서명키도 생성하여라).  하지만 읽기 전용 저장 장치에 있는 버전의

siggen이나  암호화된 siggen 과는 비교하지 말 것을 충고한다.

Tripwire을 무결성 검사 모드로 동작시키기

데이터베이스가 완성되었다면, ‘tripwire’ 명령을 입력하여 무결성 검사

모드로 Tripwire를 동작시킬 수 있다.

데이터베이스를 최신 상태로 유지하기

일반적인 설치로 Tripwire를 동작시킨다면, 결과물이 생성될 때마다 시스템

관리자에 게 메일로 보낼것이다. 그러나 몇개가 일반적인 연산도중에

변화한다면, Tripwire 데이터베이스를 갱신할 필요가 생긴 것이다.

Tripwire 데이터베이스를 갱신하기 위해서는 두가지 방법이 있다. 첫번째

방법은 상호대화 모드로 Tripwire가 사용자에게 , 현재 파일 상태를

반영하여 갱신할 목록을 알려주는 것이다. 두번째 방법은 명령어 지향

모드로 실시간에 특정한 파일 목록이 지정된다.

상호대화(interactive) 모드로 tripwire 동작하기

상호대화 모드로 Tripwire를 동작시키는 것은 무결성 검사 모드와

유사하다. 그러나 파일 또는 디렉토리가 데이터베이스에 저장된 것과 달리

추가, 삭제, 변경된 경우 Tripwire는 데이터베이스를 갱신할 것을

사용자에게 묻는다.

예를 들어 Tripwire가 상호대화 모드로 동작하고 파일의 갱신 시간이

변경된 경우, Tripwire는 파일에서 기대한 상태를 출력하고 , 사용자에게

파일을 갱신할지 묻는다.

/home/research/tw/src/preen.c

        st_mtime: Wed May 5 15:30:37 1993       Wed May 5 15:24:09 1993

        st_ctime: Wed May 5 15:30:37 1993       Wed May 5 15:24:09 1993

—> File: ‘/home/sresearch/tw/src/preen.c

—> Update entry?      [YN(y)nh?] y

yes 또는 no, 또는 대문자 ‘Y’,’N’ 라고 대답하면 Tripwire은 나머지

파일에 대해서도 이 답변을 사용한다. (‘h’ 와 ‘?’는 사용법과 다양한

inode필드를 보여준다)

이 모드가 데이터베이스를 최신으로 유지하는데 가장 편리한 방법으로

사용자의 절에서 설명한다.

데이터베이스 갱신 모드로 Tripwire 동작시키기

Tripwire는 파일, 디렉토리의 데이터베이스 또는 tw.config 목록에

기반하여 데이터베이스를 누증적으로 갱신할 수 있다. Tripwire는

데이터베이스에 정보를 저장하기 때문에 , 데이터베이스가 생성되었다면

tw.config 목록과 데이터베이스에 있는 파일을 연결시킬 수 있다.

그러므로, 만일 하나의 파일이 변했다면 다음을 입력한다.

tripwire -update /etc/newly.installed.file

또는 tw.config 파일의 목록에 있는 자체 파일이 변경된 경우 다음을

입력한다.

tripwire -update /usr/local/bin/Local_Package_Dir

이외의 경우, Tripwire을 매번 특정한 이름으로 데이터베이스 목록을

재생성한다.  오래된 데이터베이스의 백업은 ./databases 디렉토리에

생성된다.

Tripwire는 이제 데이터베이스 갱신 모드에서 임의의 인수들을 제어할 수

있게 되었다.  이 기능은 버전 1.0.1에서 추가되었다.

일관성을 검증하는 임시 기법이다. 즉, 새로운 목록이 tw.config 파일에

추가되었다면 , 데이터베이스 목록은 더이상 적절한 목록 숫자를 연결하지

못하는 것이 된다.  twdb_ckeck.pl 스크립트는 데이터베이스를 분석하고

각각의 데이터베이스 목록을 tw.config 목록에 맞추어 재정렬(remap) 한다.

twdb_check 의 기능은 나중 버전의 Tripwire프로그램에 내장될 것이다.

빠른(Quick) 무결성 검사 모드

Tripwire는 명령줄 옵션인 경우 실행중에 어떤 서명키를 선택적으로 통과할

수 있게 해준다. 예를 들어, Tripwire를 매 시간마다 수행하고 싶다면,

MD5만 수행한다 하더라도 계산이 불가능해진다. 이경우 CRC32 서명키로만

검사하는 것이 바람직하다.  이러기 위해서는 데이터베이스를 초기화할 때

MD5,Snefru, 그리고 CRC32만 사용하도록 하면 된다.

tripwire -i 1 -i 2

이로서 Tripwire는 서명키 1과 서명키 2를 무시한다. 매일마다 Tripwire를

동작시킬 경우, MD5와 CRC32를 사용하는 것이 좋다. 마지막으로, 매주마다

동작시킬 경우, 세  개의 서명키 모두를 사용하는 것이 좋다.  서명키

검사없이 추가, 삭제된 파일을 찾을 경우 다음을 입력한다.

tripwire -i all

Siggen 유틸리티

siggen 유틸리티는 Tripwire를 동작시키지 않고도 파일의 서명키를

사용자에게 알려준다.

siggen [-0123456789aqv] [ 파일 .. ]

기본적으로 , siggen은 모두 10개의 서명키를 출력한다. 그러나 명령줄에서

서명키의 숫자를 선택해서 출력할 수 있다. 자세한 것은 매뉴얼 페이지를

참고하라.

6.  Tripwire FAQ

6.1.  빈번한 질문들(FAQ)

아래 목록들은 Tripwire에 관한 빈번한 질문들이다. 첫번째 것은

Tripwire의 개념과 설계를 다루고, 두번째 것은 트러블 슈팅을 한다.

개념들:

Q: Tripwire는 2000년 문제(y2k)가 없는가?

A: Tripwire는 y2k 문제를 최소한도로 테스트했다. 이번 버전은 다른

유닉스 유틸리티 에서 사용되는 POSIX ctime() 함수를 사용했다. 날자는

전체 26개의 문자로 표현되어 2000년 이후도 분명히 표현할 수 있다. (예를

들어 Fri Sep 13 00:00:00 2003) y2k 테스트는 하지 않았고 Tripwire는 y2k

인증을 받지 않았지만 아무 문제가 없다.

Q: tw.config 파일에서 목록을 제거하는 것과(“!”), 모든 것을 무시하는

것(“E” 형 (Template))은 무슨 차이가 있는가?

A: 디렉토리의 모든 것을 무시하는 것은 아직도 추가, 삭제된 파일을

감시하고 있다는 것이다. 디렉토리를 제거하는 것은 trip이 특정

디렉토리를 검사하지 못하게 하는 것이다.

Q: Tripwire가 매우 느리게 동작한다. 더 빠르게 만들수 없는가?

A: tw.config 파일을 수정해 Snefru 서명키를 통과하도록 수정하라.

무시(ignore) 플래그에 ‘-2’를 덧붙이면 된다. 또는 실행할때 Tripwire에게

Snefru를 통과하도록 할 수 있다.

tripwire -i 2

이 많은 시간이 걸리는 연산은 대개 필요가 없는 것들이다.  (더 많은

설명을 원한다면 README 절의 ‘보안 vs 성능조절’ 을 읽어보아라)

트러블슈팅:

Q: Tripwire를 설치했는데 테스트 슈트(suite)가 실패한다. 무엇을

해야하나?

A: README 절의 ‘일반적인 컴파일 문제’를 읽어보라.

Q: Tripwire이 내 데이터베이스 버전이 오래되었다고 보고했다. 무엇을

해야하나?

A: Tripwire v1.2에서는 데이터베이스 형식이 변화되었다. Tripwire v1.2의

데이터베이스를 재작성해야 한다. 자세한 것은 README 파일을 참고하라.

만일 파일 이름과 함께 위치도 감시하고 있다면, Tripwire v1.3.1의

데이터베이스로 재작성해야 한다.

Q: Tripwire를 무결성 검사 모드로 동작시키면, 수십/수백/수천개의 ‘/’를

가진 파일 이름을 찾으려고 시도하며 실패한다. 무엇이 잘못되었는가?

A: conf-<os>.h 파일의 #define DIRENT 값의 설정이 아마 틀린 것이다.

설정을 맞추고 문제가 해결되었는지 살펴보라(가령 #define을 #undef로

하는 등)

Q: tw.config 파일에 /tmp 를 추가했다. 그런데 디렉토리 안의 어떤 파일도

Tripwire 에서 읽을 수 없다. 어떻게 된 일인가?

A: /tmp 가 다른 파일 시스템의 심볼릭 링크가 아닌지 체크하라.

디렉토리를 순환적 으로 들어갈 경우, Tripwire는 심볼릭 링크나 다른 파일

시스템은 탐색하지 않는다.

Q: Tripwire가 검색한 파일의 이름을 출력할 수 있는 방법이 없는가?

Tripwire이 어느 파일을 검사하고 있는지 직접 알고 싶다.

A: ‘tripwire -v’를 입력하라.

Q: 데이터베이스를 초기화하려고 ‘tripwire -initialize’를 입력했다.

그런데 실행 파일을 찾을 수 없었다. Tripwire 실행 파일은 어디에 있는가?

A: ./src/tripwire에 만들어져있다. ‘make install’하면 최상위 Makefile에

정의된 $(DESTDIR) 디렉토리에 설치된다.

Q: 특정한 호스트에서 동작하기 위해서 tw.config 파일에 다음 줄을

추가했다. 왜 제대로 동작하지 않는가?

_____________________________________________________________

@@ifhost chapel || chekov || chewie || data || guinan

        …

@@endif

_____________________________________________________________

A: 반드시 호스트 이름에 ‘hostname’ 또는 ‘uname’에서 반환되는 값을

넣어야 한다.  (BSD 나 SYSV 같은 OS에 의존한다). 그러므로 제대로 된

형식은 다음과 같다.

____________________________________________________________

@@ifhost chapel.enterprise.fed || chekov.enterprise.fed ..

____________________________________________________________

Tripwire 선행처리기는 당신이 잘못된 형식의 호스트 이름을 사용할 경우

제대로 이해하기 위해 시도한다.

Q: 내 익스포트된 NFS 파티션의 보안 계획에서 ‘fsirand’를 항상

동작시키고 싶다.  불행하게도, 내가 이렇게하면, Tripwire는 모든 파일이

변경되었다고 보고한다.  (왜냐면 i-node 숫자가 변경하기 때문이다). 매번

전체 시스템 데이터베이스를 재설치하기는 싫다. 어떻게 하면 좋을까?

A: 배포판에 펄 스크립트 하나가 있는데 이것은 Tripwire db 파일로

이동하여 i-node 파일을 갱신한다. 동시에 모든 것이 변경된 경우

사용한다.  사용하려면 펄 해석기의 위치를 지정하는 첫 줄만 수정하면

된다. (펄을 사용하지 않으면, ftp 사이트에서 펄을 가져오거나 , C로 직접

프로그램을 작성해야할 것이다) 펄 스크립트의 이름은

./contri/twdb_newinode.pl이다.  다음에, 단일 사용자 모드로 들어가서

fsirand를 실행한다. 이 스크립트를 실행시키는 데 db를 입력에 넣는다.

다음과 같이 말이다.

cd /usr/local/adm/tcheck/databases

./twdb_newinode.pl tw.db_myhost

이 스크립트는 만약을 위해서 자동적으로 파일 백업 버전을 생성한다.

   그 다음에, 데이터가 저장된 디스크를 읽기 전용 모드로 돌려놓아라.

   또한, 펄 스크립트를 Tripwire 프로그램이 저장된 안전한 곳에

   저장시킨다.

최근 수정일: 1999년 3월 30일. 메일은 support at

tripwiresecurity.com으로

보내시오

새로운 Tripwire 데이터베이스 형식

Tripwire 데이터베이스 형식은 버전 1.0 이후로 변했다. 다른 64개의

알파벳과 암호화 기법을 사용했다. twconvert 프로그램을 사용하면

1.0버전의 데이터베이스를 1.1버전 의 데이터베이스로 바꿀수 있다. (./src

디렉토리에 있다) 만일 구버전의 Tripwire를 사용중이라면, twconvert를

사용하여 당신의 데이터베이스 를 새로운 형식으로 바꿀수 있다.

Tripwire 데이터베이스 갱신

주로 덮어쓰기/제고하기(rethink)에 사용되는 ‘tripwire – update’ 라는

명령과 유사하게 ‘tripwire -interactive’ 란 명령은 데이터베이스가

갱신된 경우 사용자에게 상호대화식으로 선택하도록 허용한다. ‘-add’ 나

‘-delete’ 같은 명령은 거의 쓰이지 않고 ‘-update’명령이 자동적으로

파일을 추가,삭제한다.

그러나 파일 시스템과 조율하여 Tripwire 데이터베이스를 유지하는 방법중

더나은 것은 ‘-interactive’ 명령을 사용하는 것이다. 상호대화모드로

Tripwire를 사용하는 과정은 다음과 같이 표시된다.

6:25am  (flounder)      tw/src  1006 %% tripwire        – interactive

        ### Phase 1:    Reading configuration file

        ### Phase 2:    Generation file list

        ### Phase 3:    Creating file information database

        ### Phase 4:    Searching for inconsistencies

        ###

        ###             Total   files scanned:         49

        ###    Files added:           0

        ###    Files deleted:         0

        ###    Files changed:         49

        ###

        ###             After   applying rules:

        ###    Changes discarded:     47

        ###    Changes remaining:     2

        ###

        changed: drwx—— genek 1024 May 30 6:25:37 1993

/homes/research/tw/src

        changed: -rw——- genek 7978 May 30 6:24:19 1993 /homes/

/research/tw/src/databases/tw.db_flounder.Eng.Sun.COM.old

        ### Phase 5:    Generating observed/expected pairs for changed files

        ###

        ### Attr        Observed(what it is)    Expected(what it should be)

        ### =========== ===========================

             ==============================

        /homes/research/tw/src

             st_mtime: Mon May 3 06:25:37 1993  Mon May 3 06:11:39 1993

             st_ctime: Mon May 3 06:25:37 1993  Mon May 3 06:11:39 1993

—> File: ‘/homes/research/tw/src’

—> Update entry? [YN(y)nh?] y

        ### Updating database…

        ###

        ### Phase 1:    Reading configuration file

        ### Phase 2:    Generating file list

        ### Phase 3:    Updating file information database

        ###

        ### Warning:    Old database file will be moved to

             ‘tw.db_flounder.Eng.Sun.COM.old’

        ###             in ./databases.

        ###

        6:25am (flounder)       tw/src 10007 %%

Tripwire는 현재 파일의 데이터베이스 목록에서, 현재 파일 정보에 맞추어

갱신해야 할 파일들을 사용자에게 알려준다. y는 현재 파일을 갱신하고 ,

n을 누르면 다음 파일 로 넘어간다. Y나 N을 누르면 당신의 답변이 모든

목록에 적용된다는 것을 의미한다.  (예를 들어, /etc 가 변화된 경우, Y를

누르면 /etc 만 갱신되는 것이 아니라 /etc에 있는 모든 파일들이

갱신된다)

Tripwire 종료 코드

Tripwire 종료 상태는 다음 마스크(mask)로 해석된다.

1: 실행중 에러. 중단됨

1: 실행중 에러. 중단됨

2: 파일 추가

4: 파일 삭제

8: 파일 변경

예를 들어, Tripwire가 종료 코드 10을 반환했다면, 파일은 추가되고

변경된 것이다 (8+2 = 10)

Tripwire의 조용한(quiet) 옵션

변경된 경우 한줄만 출력한다. 결과물은  awk나 perl로 파싱하기에 더

적합하다.

조용히(monotonically) 커지는 파일

이제 ‘>’ 형(template)이 tw.config파일에 지원된다. 이 형은 어떤

보고없이 파일을 증가시킨다. 그러나 만약 파일이 데이터베이스에 저장된

크기보다 작거나, 삭제된 경우, 변화를 보고한다.

느슨한(loose) 디렉토리 검사

이 옵션은 Tripwire를 무결성 검사와 상호 대화 모드에서, 이 디렉토리가

nlink,ctime, mtime, 그리고 크기가 변경된 경우에 보고하지 않도록

지시한다.

Tripwire이 ‘-losedir’ 옵션으로 동작한다면, 디렉토리를 검사할때

자동으로 이 상태들을 무시하는 마스크를 사용한다. 그래서 여기에 관련된

보고는 무시한다.

이 옵션은 기본적으로 지원되지 않는다. 보통 Tripwire의 동작은 이전

버전과 다른 점이 없다. 하지만 이 옵션으로 동작하면 Tripwire 보고에

‘잡음(noise)’이 줄어든 것을 알게 될 것이다.

(이상적으로, ‘느슨한 디렉토리 검사’는 tw.config 파일에서 한 파일

기반으로 제공되어야 한다. 하지만 tw.config 파일에 다른 필드를 더하는

것은, 변화가 너무 어려워서 이번 배포판에서 제어하기 어렵다. 아마 다음

배포판에는 수정될 것이다.

외부 서비스 이용(hook)

Tripwire는 특별한 열린 파일 기술자를 사용하여 저마다의 설정 파일과

데이터베이스 파일로 사용할 수 있도록 ‘-cfd’ , ‘-dfd’ 라는 옵션을

지원한다. 이 옵션을 사용하면 외부 프로그램이 열린 파일 기술자를 통하여

Tripwire에 입력할 수 있다. 이 외부 프로그램은 Tripwire를 통하지

않고서도 암호화, 데이터 압축, 또는 집중화된 네트웍 서버 같은 서비스를

지원할 수 있다.

이 프로그램은 다음과 같은 과정으로 동작한다. 데이터베이스의 설정

파일을 열고 진행하고 디코딩한다(파일의 압축을 푸는등..). 그리고 정해진

형식으로 임시 파일에 쓴다. 열린 파일 기술자는 그때서야 execl()을 통한

명령줄 인수로 Tripwire에 전달된다.

쉘스크립트를 사용해서 파일을 압축하고 암호화시킬수 있는데

./contrib/zcatcrypt에 있다. 4줄의 본쉘 스크립트는 데이터베이스와

설정파일을 압축하고 암호화한다.

tw.config 선행처리기 수정하기

tw.config 선행처리기는 파일 이름에 ‘@@변수’로 적절히 확장될 수 있다.

아래에 사용한 @@define은 기대했던 것처럼 동작한다.

_________________________________________________________

@@define        DOMAIN_NAME             my_main_nis_domain

/var/yp/@@DOMAIN_NAME           L

@@DOMAIN_NAME/FOO L

_________________________________________________________

(세번만에 정확히 동작하게 된 것이다. 우리는 어휘 분석기에서 매크로

확장 규칙을 이동시켜서 이 문제를 해결했다)

테스트 슈트(suite)의 확장

Tripwire의 테스트 슈트는 표준 서명키 테스트 슈트보다 더 잘 작동한다.

이것은 MD2, MD4, 그리고 MD5 서명키 규칙의 구현 오류를 발견하고

수정법을 알려준다. Tripwire 정식판이 나오기 전에 만들어졌다(Eugene

Zaustinsky 에게 감사한다) 두개의 테스트 슈트가 더해졌다. 하나는

Tripwire의 보고 기능을 모두 수행하고 데이터베이스가 갱신되는 경우를

모두 수행해본다. 다른 테스트케이스는 Tripwire 선행처리기가 매크로

확장을 제대로 하는지 검사한다.

CRC32의 변화

더욱이 , CRC32 서명키 규칙은 이제 POSIX1003.2를 만족한다(Dan

Bernstein에게 감사한다).

한 테스터가 ‘sigfetch’는 사실 아무것도 패치하지 못하기 때문에 잘못된

이름이라고 말했다. 결국 ‘sigfetch’가 데이터베이스로부터 서명키를

복구하기 때문에 (옳지않은) 결론을 내리기 쉽다. ‘siggen’ 이란 명령은

‘sigfetch’와 거의 유사하다. 매뉴얼 페이지에서 이들의 차이를 설명했다.