select   /*+ index( idx_col_1 ) */

           name, age, hobby

from     member

--------------------------------------------------

*오라클 힌트 사용표

INDEX ACCESS OPERATION 관련 HINT
HINT 내용 사용법
INDEX  INDEX를 순차적으로 스캔 INDEX(TABLE명, INDEX명)
INDEX_DESC INDEX를 역순으로 스캔 INDEX_DESC(TABLE명, INDEX명)
INDEX_FFS INDEX FAST FULL SCAN INDEX_FFS(TABLE명, INDEX명)
PARALLEL_INDEX INDEX PARALLEL SCAN PARALLEL_INDEX(TABLE명,INDEX명)
NOPARALLEL_INDEX INDEX PARALLEL SCAN 제한 NOPARALLEL_INDEX(TABLE명,INDEX명)
AND_EQUALS INDEX MERGE 수행 AND_EQUALS(INDEX_NAME, INDEX_NAME)
FULL FULL SCAN FULL(TALBE명)

  
JOIN ACCESS OPERATION 관련 HINT
HINT 내용 사용법
USE_NL NESTED LOOP JOIN USE_NL(TABLE1, TABLE2)
USE_MERGE SORT MERGE JOIN USE_MERGE(TABBLE1, TABLE2)
USE_HASH HASH JOIN USE_HASH(TABLE1, TABLE2)
HASH_AJ HASH ANTIJOIN HASH_AJ(TABLE1, TABLE2)
HASH_SJ HASH SEMIJOIN HASH_SJ(TABLE1, TABLE2)
NL_AJ NESTED LOOP ANTI JOIN NL_AJ(TABLE1, TABLE2)
NL_SJ NESTED LOOP SEMIJOIN NL_SJ(TABLE1, TABLE2)
MERGE_AJ SORT MERGE ANTIJOIN MERGE_AJ(TABLE1, TABLE2)
MERGE_SJ SORT MERGE SEMIJOIN MERGE_SJ(TABLE1, TABLE2)


JOIN시 DRIVING 순서 결정 HINT
HINT 내용
ORDERED FROM 절의 앞에서부터 DRIVING
DRIVING 해당 테이블을 먼저 DRIVING- driving(table)


기타 힌트
HINT 내용
append insert 시 direct loading
parallel select, insert 시 여러 개의 프로세스로 수행- parallel(table, 개수)
cache 데이터를 메모리에 caching
nocache 데이터를 메모리에 caching하지 않음
push_subq subquery를 먼저 수행
rewrite query rewrite 수행
norewrite query rewrite 를  수행 못함
use_concat in절을 concatenation access operation으로 수행
use_expand in절을 concatenation access operation으로 수행 못하게 함
merge view merging 수행
no_merge view merging 수행 못하게 함
Tag:: oracle

'Database > Oracle' 카테고리의 다른 글

10g RAC의 Load Balancing과 Failover  (1) 2009.12.30
Backup and Recover  (0) 2009.12.30
Admin Workshop 1 - 구조  (0) 2009.12.15
Query 실행 과정  (1) 2009.12.15
외래키 검색  (0) 2009.12.09
select a.table_name, a.constraint_name, c.column_name 
from user_constraints a, user_constraints b, user_cons_columns c
where a.r_constraint_name = b.constraint_name
and b.table_name = '<원하는 table명>'
and c.constraint_name = b.constraint_name

'Database > Oracle' 카테고리의 다른 글

10g RAC의 Load Balancing과 Failover  (1) 2009.12.30
Backup and Recover  (0) 2009.12.30
Admin Workshop 1 - 구조  (0) 2009.12.15
Query 실행 과정  (1) 2009.12.15
힌트 종류  (0) 2009.12.15

업무 요건에 의해 많은 곳에서 SQL에 정렬을 수행하게 된다. 대부분의 SQL이 ORDER BY 절에 의한 정렬이다. 이와 같은 정렬이 SQL의 성능을 저하시킨다는 것은 누구나 아는 사실일 것이다. 하지만, 개발에 시간이 없어서인지 아니면 정확한 지식이 없어서인지 실제 업무에서 정렬을 제거하고자 하는 사람은 거의 없는 것 같다. 더욱 아쉬운 것은 성능을 향상시키고자 하는 튜너들 중 많은 튜너들이 정렬을 제거하는 방법을 모른다는 것이다.

정렬의 제거는 해당 시스템의 성능을 몇 단계 향상시킬 수 있는 방법이다. 그럼에도 불구하고 아직 많은 사이트에서는 이러한 것이 이뤄지지 않고 있다. 왜 그런 것일까? 개발에 식간이 없어서인가? 그것은 아닌 것 같다. 필자의 의견으로는 바빠서라기보다는 몰라서가 더 맞는 답인 것 같다. 이제 우리는 이와 같이 정렬을 제거할 수 있는 아키텍처를 이해해 최적의 성능을 보장 받아야 할 것이다. 이것이야말로 대용량 데이터베이스로 변하는 지금 우리에게 반드시 필요한 기술이다. 이번 호에서 SQL의 정렬을 제거하는 방법을 하나하나 알아보도록 하자.

정렬을 제거하기 위해 필요한 요소는 무엇인가?

정렬을 제거하기 위해 필요한 것은 무엇일까? 필자는 정렬을 제거하기 위해 필요한 요소는 세 가지라고 생각한다.

- 인덱스
- 기술력
- 논리적인 사고

정렬을 제거하기 위해서는 위와 같은 요소들이 융합되어야만 한다. 첫 번째로 인덱스에 대해 확인해 보자. ORDER BY 절을 가지고 있는 SQL에 대해 정렬을 제거하려면 어떻게 해야 하는가? ORDER BY 절을 제거하고 정렬을 제거하기 위해서는 이미 정렬된 데이터가 존재해야 할 것이다. 정렬된 데이터가 존재하지 않는데 자동으로 정렬된 데이터를 추출할 수는 없다. 그렇다면 어디에 정렬된 데이터가 존재하는가? 테이블을 먼저 확인해 보자. 테이블에는 데이터가 저장되는 순서대로 저장되므로 실제 정렬된 데이터가 존재할 수 없게 된다. 만약 테이블에 원하는 형태의 정렬된 데이터가 존재한다면 이는 운이 좋은 경우이다. 이와 같기 때문에 테이블에서 정렬된 데이터를 원할 수는 없게 된다. 그렇다면 또 무엇을 확인해야 하는가? 바로 인덱스이다. 인덱스는 어떠한가? 인덱스는 인덱스를 구성하는 컬럼으로 정렬되어 있게 된다. 그렇기 때문에 인덱스를 COL1 컬럼으로 생성한다면 해당 인덱스는 COL1 컬럼의 값으로 정렬되어 디스크에 저장된다. 이처럼 인덱스를 정확히 이해하고 효과적으로 사용해야만 우리는 정렬을 제거할 수 있다.

두 번째로 기술력에 대해 확인해 보자. 여기서 말하는 기술력은 데이터베이스 및 SQL에 대한 기술력이다. SQL을 작성하다 보면 조인을 많이 이용하게 된다. 이와 같은 조인은 2개 이상의 테이블에서 원하는 데이터를 추출하는 경우에 해당한다. 오히려 하나의 테이블에서 원하는 데이터를 추출하는 경우보다는 2개 이상의 테이블에서 원하는 데이터를 추출하는 경우가 더 많을 것이다. 이와 같은 경우에는 조인에 대한 성격을 정확히 이해해야만 정렬을 제거하고 정렬된 데이터를 추출할 수 있게 된다. 예를 들어 중첩 루프 조인(Nested Loops Join)의 경우에는 먼저 액세스되는 테이블이 이용하는 인덱스에 의해 정렬된 데이터가 추출될 것이다. 이처럼 인덱스만으로 정렬을 제거할 수 없으며 이에 따르는 전반적인 지식이 있어야만 우리는 정렬을 제거할 수 있다.

세 번째로 논리적인 사고이다. 여기서 말하는 논리적인 사고는 ORDER BY 절을 제거하기 위해 반드시 필요하다. ORDER BY 절을 제거하지 못하더라도 최적의 성능을 보장하기 위해 반드시 필요한 사항이다. 예를 들어 UNION ALL이 사용되었다면 어떻게 될까? 두 집합을 연결하는 연산자가 UNION ALL 집합 연산자이다. 이와 같은 경우 정렬을 수행해 해당 집합에서 20건의 데이터만을 추출한다면 쉽게 ORDER BY 절을 제거할 수 없을 것이다. 이런 경우에는 각각의 집합에서 정렬된 20건의 데이터를 추출한 후 40건에 대해 실제 ORDER BY 절을 수행해 정렬을 최적화할 수 있다. 이처럼 논리적인 사고는 ORDER BY 절을 제거하거나 최적화하기 위해 반드시 필요하다.

정렬을 제거한다는 것은 결코 쉬운 것이 아니다. 또한, 모든 정렬은 위에서 언급한 세 가지 요소를 정확히 구사한다면 모두 제거할 수 있다. 하지만 모든 정렬을 제거하는 것 또한 의미는 없으며 힘든 작업이 될 것이다. 그렇기 때문에 해당 시스템에서 중요한 SQL에 대해서만 정렬을 제거하는 것이 필요하다.

기본적인 정렬을 제거해 보자.

우선적으로 기본적인 정렬을 제거해 봄으로써 정렬을 제거하는 기본 개념을 이해하길 바란다.


위의 SQL에서 사용된 ORDER BY 절을 제거하기 위해서는 어떻게 해야 할까? 앞서 언급했듯이 ORDER BY 절을 제거하기 위해서는 인덱스를 이용해야 할 것이다. 그렇다면 어떻게 인덱스를 생성해서 이용해야 정렬을 제거하고 효과적인 SQL을 작성할 수 있겠는가?

REG_DATE로 인덱스를 생성했다고 가정하자. 그렇다면 인덱스에 BOARD_ID 컬럼이 존재하지 않으므로 모든 인덱스 값을 액세스해야 할 것이다. 모든 인덱스 값을 액세스한 후 BOARD_ID 값이 ‘111’인 데이터를 확인해 결과로 추출하게 된다. 이와 같이 수행한다면 인덱스 FULL SCAN 실행 계획이 생성될 것은 너무나도 자명한 일이다. 인덱스 FULL SCAN이 발생한다면 인덱스의 모든 값을 액세스한 후 BOARD_ID 컬럼의 값을 확인해 조건을 만족하지 않는 경우 버리게 되므로 비효율이 발생하게 되며 그 양이 많다면 성능 저하도 당연할 것이다.

인덱스를 BOARD_ID+REG_DATE로 생성하는 경우는 어떠한가? 이와 같이 인덱스를 생성한다면 BOARD_ID 컬럼을 만족하는 데이터에 대해 차례대로 값을 액세스하게 된다. 인덱스가 BOARD_ID+REG_DATE로 구성되어 있으므로 동일한 BOARD_ID 값에 대해서는 REG_DATE 컬럼의 값으로 정렬되어 있다. 그러므로 이와 같이 인덱스를 생성한다면 처리 범위도 감소시키면서 인덱스를 이용해 정렬을 제거할 수 있게 된다. 아래의 예제를 확인해 보자.

위와 같이 SQL을 수행한다면 BOARD_ID+REG_DATE 인덱스로 정렬을 제거할 수 있겠는가?
해당 SQL은 BOARD_ID +REG_DATE 인덱스를 이용해서는 정렬된 데이터를 추출할 수 없다. 이는 BOARD_ID 컬럼의 값이 하나가 아니며 여러 개의 값이기 때문이다. BOARD_ID+REG_DATE 인덱스는 동일한 BOARD_ID 컬럼의 값에 대해서는 REG_DATE 컬럼의 값으로 정렬된다. 하지만 해당 SQL은 BOARD_ID 컬럼의 값이 여러 개이므로 조건을 만족하는 BOARD_ID 컬럼의 값에 대해 REG_DATE 컬럼의 값으로 정렬되어 있다고 할 수 없다.

그렇기 때문에 위의 예제는 BOARD_ID+REG_DATE 인덱스를 이용해 정렬된 데이터를 추출할 수 없게 되며 인덱스를 이용해 정렬을 수행하고자 한다면 REG_DATE 인덱스 또는 REG_DATE +BOARD_ID 인덱스를 이용해야 할 것이다. 이와 같다면 BOARD_ID 컬럼에 의해 처리 범위가 감소하지 않게 된다. 이 경우에는 정렬을 제거하고 전체를 액세스하는 것이 유리한지 아니면 정렬은 수행하되 BOARD_ID 컬럼에 의한 처리 범위를 감소시키는 것이 유리한지를 고려해 선택해야 할 것이다.
정렬을 제거하는 가장 기본적인 예제들을 확인해 보았다.

해당 예제들은 인덱스만을 이용해 정렬을 제거하는 것이며 인덱스 구성만 최적화한다면 손쉽게 정렬을 제거할 수 있다. 이처럼 정렬을 제거하고자 한다면 정렬을 제거할 수는 있다. 하지만, 정렬을 제거할 경우의 상황을 정확히 파악해 최적의 경우를 선택해야 한다는 것이 더 중요하다. 다음 호에서는 정렬을 제거하는 SQL에 대해 복잡한 경우를 확인해 보도록 하자.

필자소개

권순용 kwontra@hanmail.net|Data Consulting 업무를 수행하는 ㈜엑시엄의 대표이사이며 DBA로 시작해 SQL 튜닝, 데이터베이스 아키텍처 및 모델링 업무를 주로 수행했다. 데이터베이스 교육에도 많은 관심을 가지고 있으며 저서로는 『Perfect! 오라클 실전 튜닝, 『초보자를 위한 오라클 10g』 및 『INSIDE SQL』이 있다. 또한, 데이터 액세스 최적화에 대한 특허를 출원했다.

출처 : 한국 마이크로 소프트웨어 [2009년 11월호]
제공 : DB포탈사이트 DBguide.net

'Database' 카테고리의 다른 글

DBMS별 날짜 포멧  (0) 2010.01.27
오픈소스 DBMS 라이센스의 이해  (0) 2009.12.30
DBMS별 날짜 포멧  (0) 2009.12.30
해킹 피해시스템 분석 및 복구 절차  

2000. 2. 18

이현우/CERTCC-KR, lotus@{kisa, certcc}.or.kr

이 문서는 시스템이 침입을 당했을 경우 유닉스 시스템의 보안을 위해 무엇을 할 것인가를 알려준다. 또한 아직 침입을 당하지 않은 상태라도 시스템 보안점검에 도움이 된다. 그리고 유닉스 시스템이 침입을 당했을 경우 본 문서에서 권고하는 절차에 따라 시스템 복구하도록 권고한다.

1. 해킹 피해시스템 분석 절차

가. 시스템 침입흔적 조사 방법
 

  •  특별한 장소 또는 행위로부터의 접속에 대한 로그파일을 조사한다.
  • - last, syslog, 프로세스 로그와 그밖에 다른 로그파일을 조사한다.
    - access-log, xferlog 등 주요서버의 로그파일을 조사한다.
    - 방화벽 또는 라우터에 의한 로그 기록이 있을 경우 조사한다.
    < 유닉스 기본 로그 파일 >
    로그 파일 
    보유정보
    /var/adm/messages 콘솔 상에 있는 정보
    /var/adm/utmp(x) 현재 로그인한 사용자 정보
    /var/adm/wtmp(x) 사용자의 로그인, 로그아웃

    시스템의 shutdown, start up

    /var/adm/lastlog 사용자의 최근 로그인 관련정보
    /var/adm/acct 사용자의 command 정보
     
    예) 시스템 공격에 따른 각종 로그 예
  •  imap/ipop 공격 로그 : messages 로그파일
     

    Dec 5 11:57:50 www ipop3d[933]: connect from xxx.xxx.124.104
    Dec 5 11:57:54 www ipop3d[934]: connect from xxx.xxx.124.104
    ===========================================================
    Jun 22 10:03:07 ns imapd[447]: command stream end of file, while reading 
    line user=??? host=dialup187-2-45.xxx.xxx.xxx
    Jun 15 15:10:40 ns imapd[14943]: Login failure 
    user=^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^
    P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
    ^P^P^P^P^P^P^P^P host=irv-ca48-32.xxx.xxx.xxx
  •  mscan 공격 로그 : secure 로그파일
    Jun 27 20:49:29 ns in.telnetd[12918]: connect from xxx.xxx.50.76
    Jun 15 03:39:28 ns imapd[14020]: connect from xxx.xxx.94.85
    Jun 15 10:15:07 ns in.ftpd[14169]: connect from xxx.xxx.250.76
    ...
  •  statd 공격 로그 : messages 로그파일
    May 9 07:08:14 hosim statd[191]: attempt to create "/var/statmon/sm//../../../../
    ../../../../../..//../../../../../../../../../../../../../../../../../../../../..
    /../../../../../tmp/.nfs09 D H $ $ $ $ `
    O * * * # # P *` c 6 ) 
    # # ; # XbinXsh tirdwr "
  •  WWW 관련 공격 로그 : access-log 로그파일
    xxx.xxx.ter.net - - [27/Mar/1998:06:12:08 +0900] "GET /cgi-bin/phf?Qalias=x%0a
    /bin/cat%20/etc/passwd HTTP/1.0" 200 7360
    xxx.xxx.xxx- - [04/May/1998:04:17:38 +0900] "GET /cgi-bin/phf?Qalias=x%0a/bi
    n/cat%20/etc/shadow HTTP/1.0" 200 92
    xxx.xxx.xxx- - [08/Jun/1998:09:17:14 +0900] "POST /cgi-bin/phf?Qname=x%0a/bi
    n/sh+-s%0a HTTP/1.0" 200 82

     
    •  setuid, setgid 파일을 조사한다.
      - 침입자는 종종 추후에 루트권한으로 접속하기 위해 /bin/sh 또는 /bin/time과 같은 백도어 파일을 남겨둔다.
      - 다음의 방법으로 setuid, setgid 파일을 찾는다.
      # find / -user root -perm -4000 -print
      # find / -group kmem -perm -2000 -print
      NFS/AFS 마운트 시스템에서는 다음과 같은 명령어를 이용한다.
      #find / -user root -perm -4000 -print -xdev
      - setuid 파일을 찾는 다른 방법으로 각각의 파티션에 대해 적용하는 ncheck 가 있다.
      # ncheck -s /dev/rsd0g
    •  시스템의 바이너리 파일의 변경 여부를 조사한다.
      - 침입자는 /etc/inetd.conf 가 참조하는 다음과 같은 파일들을 변경한다.
        login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync 등
      - 백업된 초기 파일과 현재의 파일을 비교하기 위한 유닉스의 sum 명령어는 트로이목마프로그램에 의해 믿지못하는 결과를 나타낼 수 있으므로 다음 프로그램을 사용한다.
        cmp, MD5, Tripwire, 기타 다른 암호화 검사 유틸리티들
    •  인가받지 않은 프로그램 및 네트워크 모니터링 프로그램의 사용을 조사한다.
      - 침입자는 사용자의 계정과 패스워드 정보를 얻거나, 자신의 존재를 숨기거나, 또 다른 시스템을 공격하기 위해 다양한 프로그램 피해시스템에 설치하여 사용한다.
    < 자주 발견되는 해킹 프로그램 >
    프로그램명
    설명
    killinetd 원격지 호스트의 inetd 데몬을 다운시켜서 네트워크서비스 방해
    imap, imap2 imap 데몬 오버플로우 원격지공격 프로그램
    imapver  imap 데몬버전의 원격점검 프로그램
    netcat 범용 네트워크 해킹도구
    brute.sh imap 취약점공격시 사용되는 보조 프로그램
    z0ne 특정 도메인의 수많은 IP를 찾아내는 프로그램
    sniffer  스니퍼 프로그램
    linux rootkit 백도어 모음(chfn, chsh, inetd, login, ls, du, ifconfig, netstat, passwd, ps, top, rshd, syslogd, tcpd 등)
    phfscan phf.cgi 취약점 스캐너
    phpscan php.cgi 취약점 스캐너
    nmap  각종 기능을 추가한 포트스캐너 
    chkexploit linux의 각종 시스템 취약점을 찾아내는 스캐너
    eipscan network 레벨의 IP 스캐너
    ADMfindall network 레벨의 IP 스캐너
    lsp network 레벨의 포트스캐너
    imapvun  imap 취약점 스캐너
    imapd_scan.sh imap 취약점 스캐너
    mscan imapd, ipopd, statd등 여러 취약점을 찾아내는 취약점스캐너
    기타  sirc, ipw, ircbnc, login, icat, ts2, tt, mendax, phf, s, sirc4, bcast3, bips, boink, bonk, bonk2, ck, fear, frag, jolt, killwin, land, nestea, newteardrop, ns, smurf, ssping, tear2, teardrop 등
    •  cron과 at.으로 수행되는 모든 파일을 검사한다.
      - 침입자는 보통 cron과 at 명령으로 수행되는 파일들에 백도어 프로그램을 남겨둔다. 그러므로 이러한 프로그램으로 수행되는 파일들을 쓰기금지로 설정한다.
       
    • 인가받지 않은 서비스를 조사한다.
      - /etc/inetd.conf를 조사하여 인가받지 않은 추가되거나 변경된 서비스를 조사한다. 특히 쉘을 수행할 수 있는 /bin/sh나 /bin/csh를 조사한다.
       
    •  /etc/passwd 파일을 조사하여 변경된 부분이 있는지 확인한다.
      - 추가된 계정, 패스워드의 생략, uid(0로의)의 변경여부를 확인한다.
       
    • 시스템과 네트워크 설정 파일의 인가받지 않은 항목을 조사한다.
      - /etc/hosts.equiv, /etc/hosts.lpd과 모든 .rhosts 파일에 '+' 항목이 있는지 조사해서 제거한다.
    •  시스템에 숨겨지거나 '.' 으로 시작하는 특이한 파일이 있는지 조사한다.
      - ls 명령어로 보이지 않는 파일을 조사한다.
        # find / -name ".. " -print -xdev
        # find / -name ".*" -print -xdev | cat -v
      일반적으로 '.xx' 파일이나 '.mail' 파일이 침입자에 의해 이용된다.
    •  지역 네트워크의 모든 시스템을 조사한다.


    나. 침입자의 출발지 분석
     

    •  who, w : 사용자 및 사용자의 컴퓨터 확인
    •  last : 사용자들의 로그인/로그아웃 일시 기록 확인
    •  lastcomm : 사용자들의 시스템 명령 및 프로세스 기록 확인
    •  netstat : 네트워크 접속 현황 확인
    •  snmpnetstat : 네트워크관리 시스템에서의 현황
    •  라우터 정보 : 라우터의 라우팅 및 접속 등의 현황 확인
    •  /var/adm/messages : 전자우편 송수신 현황 기록 확인(많은 침입자들이 자신의 시스템으로 전자우편 송신)
    •  syslog : 시스템 로그 확인(다른 시스템으로도 로그를 보낸다)
    •  wrapper 로그 : 외부 시스템 접속 차단 프로그램의 연결
    •  시스템의 모든 사용자에게 finger를 하여 어디서 왔는지 점검
      * 참고 : who, w, last, lastcomm은 /var/pacct, /usr/adm/wtmp의 기록을 보여주는데 침입자들은 뒷문(Backdoor Program)을 이용하여 이 로그들을 수정하여 자신의 흔적을 지울 수 있다. 그리고 침입자가 아직 이런 뒷문이 없다하더라도 아주 쉽게 이 로그들을 수정하거나 지울 수 있다. 하지만 가끔 침입자들은 로그를 삭제하지 않을 수도 있으며, 특히 추가적인 유닉스 로깅 프로그램을 설치한 경우에 더욱 그렇다.


    다. xinetd나 tcp_wrapper는 외부에서의 모든 접속에 대해 로그를 남길 수 있으며, 침입자가 로그를 수정하거나 지울 수 없도록 이 로그들을 다른 시스템에 옮겨두는 것이 좋다. 적절한 대책을 세우기 전에 침입자가 ethernet sniffer로 다른 시스템에 어떻게 침입하는지를 모니터링하는 것이 좋다.

    라. 외부로부터 접속하는 시스템들을 막고 특히, 침입자의 접근을 막기 위해 네트워크를 중지시킨다. 하지만 만약 침입자가 눈치챈다면 당신의 시스템에서 "rm -rf /"를 실행하여 모든 정보를 지울 수도 있다.

    마. 시스템 실행 파일의 변경 유무를 점검하는데, 특히 뒷문프로그램으로 잘 이용되는 다음 프로그램들을 중점 점검한다.
     

    •  /bin/login
    •  모든 /usr/etc/in.* files (예: in.telnetd)
    •  /lib/libc.so.* (on Suns).
    •  inetd에서 호출되는 모든 것
    • 기타 잘 교체되는 것으로서는 다음과 같은 것이 있다.
      •  netstat : 정보를 감추게 한다
      •  ps : 프로세스를 감추게 한다 (예: Crack)
      •  ls : 디렉토리를 감춘다
      •  ifconfig : 이더넷에 대한 promiscuity mode 를 감춘다
      •  sum : sum을 수정하지 않고도 실행파일의 체크썸을 올바르게 위장 할 수 있으므로 더 이상 교체하지는 않는다. 따라서 sum값을 믿어서는 안된다.
    파일의 실제 수정 시간을 알기 위해서는 "ls -lac"를 사용한다. /etc/wtmp를 점검하여 시스템 시간을 알아내고 CD나 테이프의 원본과 비교하거나 MD5 체크썸이 이전의 체크썸과 다른지 비교하며, 흔히 off-line으로 저장된 미리 만들어진 체크썸과 cmp 명령으로 비교한다. 또 흔히 사용되는 뒷문으로서 /bin/time과 같은 setuid 프로그램인데, 이들은 일반 사용자가 root로 실행할 수 있게 해준다. 이런 프로그램을 찾기 위해서는 다음 명령을 이용하면 된다.
     
    find / -type f -perm -4000 -ls


    하다보면 OS 전체를 다시 설치해야될지도 모른다. Tripwire 보안도구는 관리자 몰래 실행파일을 수정하거나 inetd.conf와 같은 시스템파일의 수정을 발견할 수 있도록 도와준다.

    바. 모든 사용자의 .rhosts, .forward 등을 점검한다. 만약 .rhosts가 "+"를 가지고 있으면 어떤한 시스템에서도 패스워드 체크 없이접근할 수 있다. COPS는 다음 과 같은 체킹 스크립트를 가지고 있다.
     

    find / -name .rhosts -ls -o -name .forward -ls


    의심스러운 모든 파일의 생성 및 수정 시간을 점검하는데 다음을 이용한다.
     

    find / -ctime -2 -ctime +1 -ls


    이것은 이틀전 에서 하루 이후 에 수정된 파일을 찾아준다.

    모든 .login, .logout, .profile, .cshrc 들도 적어도 수정일 및 시간 등을 점검 하며, .rhosts 파일이 잠궈진 것은 없는지, news, sundiag, sync 등의 계정에 대한 쉘이 보다 안전을 위해 "/bin/false"로 되어 있어야 하며 "/bin/sh" 등으로 되어 있어서는 안된다. 또한 ". ", ".. " 등의 디렉토리가 없는지 점검하는데 대부분 /tmp,/var/tmp, /usr/spool/* 나 공개적으로 쓰기 할 수 있는 디렉토리에서 많이 발견된다.

    사. NFS가 외부에 널리 공개된것은 아닌지 점검한다.

    NFSwatch는 NFS트랜잭션에 대해 로그를 만들어주며, "showmount -e" 를 하여 올바른 NFS 구성을 점검할 수 있도록 한다. 256 바이트를 넘긴 경우에 nfsd는 버그를 가지고 있으며, 또한 당신이 마운트하고 있는 시스템에 대한 점검도 중요하다. 가능한 "nosuid"플래그를 사용한다.

    아. 시스템이 취약점이 있는지 점검하는 리스트
     

    •  원하지 않은 프로세스가 없는지, "rpcinfo -p"를 이용하여 점검한다.
    •  hosts.equiv 에 "+" 가 없는지 점검한다.
    •  tftp를 사용하지 않든가, 사용하기를 원한다면 "-s" 플래그를 사용한다.
      이 경우는 대부분 디스크없는 워크스테이션을 위한 경우인데, 적절하게 NFS를 이용할 수도 있다. 이것을 root 로 실행하지 않도록 하며, /etc/inetd.conf에서 다음과 같이 바꾼다.
       
        tftp dgram udp wait nobody /usr/etc/in.tftpd in.tftpd -s /tftpboot
      혹은 원치 않는 곳에서의 접근을 막기 위해 tcp_wrapper에서 tftpd에한 부분을 고치고 모든 접속 상황을 로그로 남긴다.
       
        tftp dgram udp wait nobody /usr/etc/tcpd in.tftpd -s /tftpboot
      혹은 /etc/hosts.allow에서 정의된 곳에서만 접근할 수 있도록 조정한다.
    •  crontab과 at-vobs 를 점검한다. 침입자가 남긴 모든 것을 정리했다고 생각한 후 이것이 어떤 작업을 할 수 있다.
    •  rc.boot, rc.local(SYSV : /etc/rc?.d/*)나 기타 시스템 시작시 실행 파일들을 점검한다. 가장 좋은 방법은 off-line으로 저장했다가 주기적으로 점검하는 것이며, sendmail.cf, hosts.allow, at.allow, at.deny, cron.allow, hosts, hosts.lpd 등의 시스템 구성파일들을 점검한다. "aliases"는 메일 확장을 위한 것인데, "uudecode" 등과 같은 것을 가지고 있을 수 있다.
    •  inetd.conf 와 /etc/services 파일에서 침입자가 추가한 불법 프로그램 서비스가 있는 지 점검한다.
    •  현재 가지고 있는 모든 로그 파일(pacct, wtmp, lastlog, sulog, syslog, authlog 등)들을 다른 안전한 곳으로 옮긴다. /tmp/* 파일들을 먼저 살펴 본 후 재시동(Reboot) 한다.
    •  /etc/passwd 파일의 여벌파일을 가능한 디스켓 등으로 저장한 후 su 및 passwd 프로그램이 뒷문(Backdoor) 가 아님을 확인한 후 root 패스워드를 바꾼다. 만약 침입자가 su 나 passwd 뒷문을 설치하였다면 /etc/passwd 파일의 패스워드 부분을 모두 "*"로 바꾼다. 또한 침입자가 패스워드 파일을 가지고 있다면 모든 사용자들의 패스워드를 알아낼 가능성이 있으며, 장기간 사용하지 않는 사용자의 패스우드를 바꿀 수 도 있다. NIS서버에서는 단순히 /etc/passwd 뿐 아니라 NIS 맵에 해 당하는 것들도 점검해야 한다.
    •  익명FTP나 다른 네트워크 서비스 시스템들이 적절하게 구성되어 있는지 점검한다.
    •  inetd를 다시 설치한다.
    •  콘솔 만이 "secure" 단말로 정의하여 다른 단말에서 root 로 로그인할 수 없도록 한다.
    •  hosts.equiv, .rhosts, hosts.lpd 에 "#" 이 있는지 점검한다. 만약 침입자가 "#" 을 기계이름으로 정의하였다면 누구나 신뢰하는 호스트로 정의된다.
    •  침입자에 대한 경각심을 늦추지 않는다.


    자. 침입자가 경유한 모든 기관의 시스템에 전자우편을 보내고 cert@certcc.or.kr 로도 메일을 보내 협조를 요청한다.
     

    2. 해킹 피해시스템 복구절차
     

    가. 침입으로부터의 복구

    (1) 시스템 제어 회복

    시스템에 대한 제어를 다시 회복하려면 침입자가 다시 접근할 수 없도록 네트워크 접속을 끊거나 단일사용자(Single-User) 모드에서 작업해야 한다. 그런 이후 로그파일과 구성파일을 분석하여 침입자가 남긴 흔적들을 찾아야 한다. 특히 이를 위해 시스템의 중요한 파일들에 대해 복사본을 가능한 오프라인 디스켓 등으로 보관하고 있는 것이 좋다

    추후 법적인 조사과정에서의 물증으로 확보하려면 파일시스템을 아주 자세한 수준으로 덤프(Dump)를 받고 결과의 레이블을 만들고 서명, 일시 등을 기록해두어야 한다. 물론 이 덤프파일은 안전한 곳에 보관해야 한다.

    (2) 침입자가 변조한 파일을 복구하고 시스템 다시 설치

    시스템을 훼손되지 않은 시스템으로 다시 설치해야 하는데 만약 백업 에서 다시 설치하는 것이라면 훼손되지 않았음을 확인해야 한다. 필요하다면 원래의 OS 미디어(tape, CD)로부터 다시 시스템을 설치한다,

    시스템의 취악요소들을 다시 확인하고 제거하도록 한다. 다시 설치한 시스템이 이러한 취약점들이 제거된 것을 확인하고 필요하다면 점검해 줄 수 있는 도구들을 활용한다.

    외부에 공개할 네트워크 응용프로그램과 그렇지 않은 응용프로그램에 대해 정의하고 제대로 구성화일이 되었는지 점검한다.

    Tripwire 와 같은 도구를 이용하여 새로 설치된 시스템에 대한 MD5 체크섬 파일을 받아둔다.
     

    (3) 로그시 분석된 다른 기관이나 시스템 관리자에게 연락 및 체크
     

    •  다른 기관에 무엇을 말하나?
      침해당하는 기간동안 관련된 외부기관에 대한 증거나 흔적이 있다면 자신 이 발견한 내용과 그 기관의 시스템이 당할지 모르는 침해에 대해 설명하고 도움을 주거나 요구해야 한다. 이러한 내용을 CERTCC-KR 에도 Email로 보내면 해당하는 기관이 CERTCC-KR 과의 협조를 받아 침해사고처리가 진행된다면 그쪽에서 신뢰감을 얻을 수 있으며 그 기관의 문제점에 대해 CERTCC-KR 이 도움을 줄수 있다.
       
    •  어떻게 연락처를 알 수 있나?
      whois, traceroute 등의 도구를 이용하여 알아낸다.
        # whois -h whois.krnic.net example.co.kr
        # traceroute example.co.kr
      만약 해외 기관이라면,
        # whois -h rs.internic.net
      을 이용하면 된다. 이 경우 어려움이 있다면 CERTCC-KR에 도움을 청하기 바란다. 특히 국내 전산망침해사고대응팀협의회(CONCERT)에 대해 알고 싶거나 해외 FIRST(Forum of Incident Response Security Team)에 대해 알고 싶다면 CERTCC-KR 에 접촉하거나 FIRST 홈페이지(http://www.first.org)를 접속하기 바란다.
    •  패스워드 파일을 메일로 보낼때는 어떻게 하는가?
      인터넷을 경유하여 패스워드 파일을 보내는 것은 매우 위험하므로 암호화된 패스워드 부분만 제거하고 보낸다.
       
        #awk -F: '{ print $1":(deleted):"$3":"$4":"$5":"$6":"$7 }' $file > $file.stripped
    •  패킷스니퍼 경우에는 어떻게 하나 ?
      시스템에 패킷스니퍼가 설치된 경우라면 패스워드가 알려진 시스템이 위험에 처해있음을 알 수 있다. 스니퍼 결과파일의 목적지 시스템이 문제인 것이다. 다음 명령으로 그 시스템을 알 수 있다.
       
        #grep PATH: $sniffer_log_file | awk '{print $4}' | awk -F\( '{print $1}'| sort -u
    이 명령은 대부분의 스니퍼가 만든 경우이며 다음과 같은 예제 파일을 가정으로 한 것이다.
    -- TCP/IP LOG -- TM: Tue Nov 15 15:12:29 --
    PATH: not_at_risk.co.kr(1567) => at_risk.ac.kr(telnet)
    또한 하나의 스니퍼 결과 뿐 아니라 이전에 만들었을지도 모르는 스니퍼 결과 파일이 있는지 조사해야 한다.


    나. 시스템 보안 작업

    (1) 패치를 가져와서 설치

    시스템에 관한 모든 패치들을 가져와서 설치한다. 이것은 외부의 침입시도를 막는 기본적인 과정의 첫걸음이며 시스템 공급업체로부터 요구할 수 있다.

    (2) CERT 기술권고문 등 관련 자료를 참고

    미국의 CERT 기술권고문(Advisory)나 CERTCC-KR의 권고문(KA:Korea Advisory) 혹은 CERT의 요약문 등을 참고하기 바란다. 이 권고문에는 시스템 취약점에 대한 패치 방법과 절차들이 기술되어 있다.
     

    •  이 권고문들은 다음에서 찾을 수 있다.
    - CERTCC-KR : http://www.certcc.or.kr/advisory.html
    - US CERT/CC : ftp://info.cert.org/pub/cert_advisories/


    (3) 해킹방지 등 보안 도구들을 설치함

    CERTCC-KR-TR-97-006, "침입 방지를 위한 보안 도구"를 참고하여 TCPWrapper, COPS, Tripwire 등의 보안도구들을 설치한다. 이 도구들은 미국 CERT에서 가져올 수 있다.
     

    ftp://info.cert.org/pub/tools/
    ftp://info.cert.org/pub/tech_tips/security_tools


    (4) 로그시스템을 다시 운영 시작

    로그/감사/회계 등의 패키지들을 올바르게 지정하여 다시 실행시키는데, sendmail은 레벨 8-9 등으로 적당한 수준을 정해야 하며 백업을 전용의 시스템으로 받을 것을 권고한다.

    (5) 네트워크 방화벽 시스템 설치 및 운영

    외부에서 들어오는 패킷에 대한 필터링은 매우 중요하므로 CERTCC-KR의 홈페이지에서 방화벽 FAQ 대해 이해하고 미국 CERT 의 패킷 필터링에 대한 권고사항을 이해하여 실시한다.
     

    ftp://info.cert.org/pub/tech_tips/packet_filtering


    (6) 유닉스 보안 구성지침에 따라 보안상태 검토

    시스템의 보안구성에 대해서는 CERTCC-KR-TR-97-004, "유닉스 보안구성 지침"을 참고로 한다.

    (7) 사용자 패스워드 교체

    시스템에 대한 안전한 작업이 끝났다면 이 침해를 당한 시스템의 모든 계정의 패스워드를 교체할 것을 권고한다. 그리고 패스워드 정책을 구현할 수 있는 도구들을 활용할 것을 건의한다.

    (8) 네트워크 재 접속 및 운영 시작

    만약 작업을 시작하기 전에 네트워크를 끊었다면 다시 연결을 시도한다.

    (9) CERTCC-KR 사고보고 양식 작성 및 연락

    CERTCC-KR 에 침해사고를 보고하려면, 홈페이지에서 보고양식을 작성하여 Email이나 팩스등을 이용하여 보낸다. 이때 이 양식에 해당하는 것만 그리고 할 수 있는 것만 우선 작성하여 보낸다.

    http://www.certcc.or.kr/Service/Incrpt.html
     

    -- 한국정보보호센터 CERTCC-KR 침해사고 지원 안내 --

    전 화 : 02-3488-4119 삐 삐 : 015-993-4571

    핸드폰 : 011-732-7821 팩 스 : 3488-4129

    Email : cert@certcc.or.kr

    침해사고 접수 방법은 http://www.certcc.or.kr/service.html을 참고 바람

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

  • + Recent posts