Alice's Story

•  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, 기타 다른 암호화 검사 유틸리티들
•  인가받지 않은 프로그램 및 네트워크 모니터링 프로그램의 사용을 조사한다.
  - 침입자는 사용자의 계정과 패스워드 정보를 얻거나, 자신의 존재를 숨기거나, 또 다른 시스템을 공격하기 위해 다양한 프로그램 피해시스템에 설치하여 사용한다.

•  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값을 믿어서는 안된다.

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을 참고 바람

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