Search

'시스템관리'에 해당되는 글 1건

  1. 2002.09.09 [퍼온팁] 시스템 관리자를 위한 50가지 비밀

[퍼온팁] 시스템 관리자를 위한 50가지 비밀

秋 - Tip 2002.09.09 20:54 Posted by 민수아빠™
=======================================================
시스템 관리자를 위한 50가지 비법
=======================================================

좀 오래된것 같지만 쓸만한 것이 많아서 올립니다. 출처 모르겠음.

리눅스 시스템 관리자가 되기 위해서는 많은 것을 알아두어야 한다. 시스템 관리자의 관리 여하에 따라 많은 사람들의 시스템 장애를 초래할 수 있기 때문이다. 물론 시스템 관리자가 모든 것을 미리 예방할 수는 없다. 하지만 불가피한 상황을 제외하고는 시스템이 정상적으로 작동되도록 해야한다.
이번 호에서는 시스템, 네트워크, APM, 메일, 보안, 장애 발생시 복구 등에서 일어날 수 있는 시스템 관리자의 행동요령에 대해 알아볼 것이다. 시스템 관리자는 항상 모니터와 키보드와 함께 한다는 사실을 기억해야 한다.

막강한 시스템 길들이기

시스템이 네트워크에 연결되어 있다면, 다음과 같이 한국 표준시간 서버에서 표준시간을 받아서 설정할 수 있다.

# rdate -s time.kriss.re.kr

시스템이 온라인 상태가 아니라면 아래와 같이 수동으로 설정할 수도 있다.

# date -s ?1999-12-30 22:22:40?

위와 같이 실행하면 실행할 때만 적용되므로 이후 시간이 늦어지는 것을막기 위해서는 주기적으로 변경 가능하게 크론(/etc/crontab)에 설정하는 것이 좋다. .profile은 로그인시 적용되는 내용들이고, rc.local은 시스템 부팅시 실행해야 할 것들을 적어 놓은 것이다. 사용자 홈디렉토리의 .profile이 /etc에 있는 설정 파일보다 우선하기 때문에 홈 디렉토리에 .profile에 패스를 설정해주거나 쉘 환경 파일 등을 설정해 주면 계정 내에서 적용이 된다. rc.local에는 부팅시 가장 마지막에 실행되므로 일반적으로 부팅시 실행되어야 할 데몬 등을 적어준다.

리눅스 시스템의 자원 정보는 proc 파일시스템 구조를 통해서 알 수 있다. 이는 실제로 디스크 용량을 차지하는 파일들이 아닌 가상의 디렉토리 구조이며 리눅스 커널에 의해 사용되는 시스템의 정보를 담는 곳으로 사용된다. 다음의 위치에서 하드웨어에 대한 정보 및 시스템 관련 정보들을 확인할 수 있다.
위와 같이 관련된 정보에 해당하는 파일 이름이 존재한다. 이 파일들은 텍스트 포맷이므로 cat 명령을 통해서 확인할 수 있다


^M 문자를 공백으로 치환하면 된다.

:1,$s/^M//g

# rpm -qa | grep 패키지 명으로 확인할 수 있다.

rpm2cpio filename.rpm | cpio -I -make-deretories -E filename

Tcp Syn Flooding은 웹으로의 공격이 대부분이므로 syn_recv 프로세스가 일정 개수가 넘게 되면 아파치를 재시작한다. 지속적인 공격일 경우 대처 방안으로 두 가지 방법이 있다.

첫째, sysctl -a |grep syn_backlog으로 확인 후 backlog를 늘려주거나
둘째, sysctl -a |grep syncookies로 확인 후 syncookies의 값을 1로 바꾸어준다. syn_backlog의 값을 조정해주는 방법은 다음과 같다.

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
# echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog

syncookies의 값은 다음과 같이 변경이 가능하다.

# sysctl -w net.ipv4.tcp_syncookies=1

Umount시 위와 같은 메시지가 나는 것은 unmount하려는 디렉토리에서 실행되고 있는 프로세스가 있기 때문이다. 예로 /tmp 디렉토리를 umount시키려 할 때 위의 메시지가 뜨는 경우 mysql. socket파일 /tmp에 있는 경우를 들 수 있다. 이 경우에는 해당 파일시스템에서 실행중인 프로세스를 제거해야 하나 일일이 제거가 번거로우므로 Fuser에서 -k 옵션을 사용하면 간단히 해결할 수 있다.

Fuser -km 장치명

디렉토리나 파일 퍼미션 중 setuid는 소유자의 권한을 잠시 빌려 실행 후 권한을 돌려주고 실행을 마치게 되는데 실행도중 인터럽트가 발생한다면 정상적으로 권한을 반환하지 못하게 되어 소유자의 권한을 그대로 가지고 있게 된다. 이때 파일의 소유자가 루트였다면 이것은 보안에 문제가 될 수 있으며 이런 점을 이용해 해킹에 많이 사용된다. Setuid가 걸려 있는 파일 중에 실행권한이 있으며 루트권한일 경우에는 위험하다. 특정 디렉토리에서 setuid가 걸려있는 파일을 찾으려면 find /usr -perm 4755와 같이 perm 옵션으로 찾을 수 있다.

다음과 같이 ~/.bash_profile를 실행해서 변경이 적용되도록 한다.

# source ~/.bash_profile

리눅스 시스템을 재부팅하고 lilo가 뜨면 ‘linux single’로 부팅한다.
Tab 키를 누르면 등록되어 있는 라벨이 모두 보이므로, 여기에서 선택하도록 한다. 부팅 후 쉘 명령어 화면에서 /etc/passwd 파일에서 암호 부분을 삭제하거나 passwd를 실행하여 루트의 패스워드를 새로 설정해 준다.

# passwd root

위의 명령을 입력한 후 변경할 패스워드를 입력하면 된다.

보통 파티션을 나누는 것에 대해서 별다른 고려 없이 /로 모든 것을 잡아서 설치하는 경우가 종종 있다. 이럴 경우 설치시 편리하지만, 나중에 파일시스템에 문제가 생기거나 효율적으로 파티션을 관리하기에는 많은 어려움이 있다. 파티션을 나눌때는 어떤 용도로 쓸 것인지에 대해서 충분히 생각한 후 파티션을 해야 한다. 다음은 9.1GB 스카시 하드디스크를 기준으로 웹 서버에 이용될 서버에 대해 파티션한 경우의 예다.
/var 디렉토리와 같이 항상 새로운 자료가 쌓이는 곳은 안전성이 우선시 되므로, ext3 파일시스템이 유리하며, /usr와 같이 내용 변화 없이 빠르게 액세스하여 쓸 수 있어야 하는 부분은 ext2 시스템을 이용하여 성능에 초점을 두면 좋을 것이다.

1024KB인 경우에는 블럭이 작은 만큼 4096KB보다 하드의 낭비가 적다. 1023KB의 데이터를 저장하는 경우, 기본 블럭사이즈가 1024KB일 때는 1K 공간이 사용되지만, 4096KB가 기본 블럭이라면 4K를 차지하게 된다. 하지만 아주 작은 파일들이 많은 경우 해당 데이터를 액세스하는 데는 1024KB가 4096KB보다 더 걸리게 되므로 퍼포먼스가 급격히 떨어지게 된다. 따라서 자신이 이용하는 시스템의 특성과 용도에 맞게 블럭 사이즈를 지정해서 사용하면 된다.

RAID는 ‘Redundant Array of Inexpensive (or Independant) Disks’의 약어다. RAID 시스템은 여러 드라이브의 집합을 하나의 저장장치처럼 다룰 수 있게 하고, 장애가 발생했을 때 데이터를 잃어버리지 않게 하며 각각에 대해 독립적으로 동작할 수 있도록 한다.

시스템의 다운, 데이터 손실에 대비하여 보통 여러 가지 RAID 레벨 중에서 1과 5번 방법을 많이 사용한다.
RAID 1(mirroring)의 특징은 빠른 기록 속도와 함께 장애 복구 능력이 있다는 것이다. 2대의 드라이브만으로 구성할 수 있기 때문에 작은 시스템에 적합하다. 읽을 똑같은 하드가 복제되고 있으므로, 시스템에 문제 발생시 서비스 지연 시간이 매우 짧아서 웹 서비스를 하는 곳에서 유용하게 쓸 수 있다. 하지만 한 하드의 내용이 또 다른 하드에 똑같이 복사되므로 하드용량의 낭비가 심하다.
RAID 5(distributed parity)는 작고 랜덤한 입출력이 많은 경우 더 나은 성능을 제공한다. 빠른 기록 속도가 필수적이지 않다면, 일반적인 다중사용자 환경을 위해 가장 좋은 선택이다. 그러나 최소한 3대, 일반적으로는 5대 이상의 드라이브가 필요하다. 변경된 내용이 있을 경우 그것만 기록한다. 일반적으로 RAID 1은 ECC 계산을 하지 않으므로 RAID 5보다 빠르고, raid5는 하드 공간을 좀 더 여유있게 쓸 수 있다는 장점을 지닌다.

먼저 시스템의 전체 용량이 어떻게 되고, 그 중에서 백업할 가치가 있는 것은 어떤 부분인지를 결정한다. 사용할 백업 장비와 종류를 알아보고, 총 백업 시간과 어느 정도 부하가 걸리는지 예상해보고 테스트 해 본 후 마지막으로 백업 스케줄을 정한다. Full 백업은 백업할 자료를 처음부터 끝까지 다 기록하는 것이고, Incremental 백업은 이전의 데이터와 비교해서 새로 추가된 내용만 백업하는 방법이다. 따라서 Full 백업시 완전히 데이터를 백업할 수 있지만 시간이 많이 걸리고, 시스템에 부하를 초래할 수 있는 반면에 Incremental 백업은 빠른 시간내에 백업을 할 수 있지만, 백업하는 시간에 따라 데이터가 완전히 백업되지 못할 경우도 있을 수 있다.

SNMP는 ‘Simple Network Management Protocol’의 약자다. 네트워크에 연결되어 있는 장치에서 네트워크에 관련된 정보를 모으고 문제점 등을 보고할 수 있는 기능을 제공하는 프로토콜이다. 구성 요소는 에이전트와 매니저가 있다. 이것은 서버/클라이언트 구조로서 에이전트가 서버에 해당되고, 매니저가 클라이언트에 해당한다. 에러가 발생하는 경우는 선택한 장비에 SNMP가 Enable이 안 되었거나, 네트워크에 문제가 있어서 모니터링 하려는 장비까지 프로토콜이 전송되지 않는 경우, community 값이 잘못 사
용된 경우 등이 있다.

/etc/rc.d/init.d이 디렉토리에 있는 서비스를 ‘서비스명’ stop 또는 start 시키거나 재시작시킨다.

quota를 이용하면 된다. df 명령으로 사용자의 홈디렉토리가 있는 디바이스를 확인한다.

ilesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda5              3028080    878480   1995780  31% /
/dev/sda1                62217      7713     51291  13% /boot
/dev/sda6              2759260   2088820    530276  80% /home2
/dev/sdb1              8744304   6496724   1803388  78% /home3
/dev/sdc1             35296928  25597968   7905940  76% /home4
/dev/sda10              202220         6    191774   0% /tmp
/dev/sda7              1517920   1280648    160164  89% /usr
/dev/sda8               608724    426992    150812  74% /var
# edquota username
Quotas for user jhk1:
/dev/sda6: blocks in use: 47584, limits (soft = 0, hard = 0) /* 이 부분에 설정 */
       inodes in use: 4590, limits (soft = 0, hard = 0)
/dev/sda8: blocks in use: 4, limits (soft = 0, hard = 0)
       inodes in use: 1, limits (soft = 0, hard = 0)
Soft는 용량에 설정되어 있는 용량은 넘어도 어느 정도 여유가 있지만, hard 용량에 설정된 크기는 절대적이다. 따라서 hard 용량을 사용자는 넘을 수 없다. 일반적으로 soft 용량을 hard 용량보다 조금 더 적게 설정해 놓는다. 쿼터 조정후 quotacheck /dev/sda6를 해줘서 체크를 해 주도록 한다.

파일명이 하이픈(-)으로 시작하는 파일

rm ./-filename 상대경로를 이용하여 파일명을 지정해줌
rm -- -filename --를 이용 그 이후에 오는 '-filename'이라는 파일이 옵션이 아닌    파일이라는 것을 밝힘

/etc/inittab에서 사용하지 않은 가상콘솔 레벨을 주석처리 해주면 된다.

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6


먼저 psacct라는 패키지가 필요하다. 설치되지 않은 경우 rpm이나 소스 등을 직접 설치 한다(대부분 배포본에 기본적으로 포함되어 있으므로 그대로 사용하면 된다). 다음과 같이 명령하면 사용한 명령어를 확인할 수 있다.

더미 로그 파일 생성(데이타를 기록할 파일 생성)
# touch /var/log/pacct
# /sbin/accton /var/log/pacct 체크를 시작하게 하는 명령어 실행
# lastcomm 사용자계정   사용자가 수행한 명령어 체크 */
tar xvfpz 압축파일 또는 .tgz -C 특정경로 특정 파일의 절대경로(또는 파일명)로 입력하면 된다. test.tgz 파일에서 /home/test /test.txt파일을 /tmp 디렉토리에 압축해제를 한다면, tar xvfpz test.tgz -C /tmp /home/test/test.txt와 같이 하면 된다.

TTL이란 Time To Live의 약자다. 이것은 라우팅 에러로 인하여 데이터그램이 네트워크를 영원히 떠돌아다니는 것을 방지한다. 라우터는 네트워크 간을 이동하는 데이터그램의 TTL 필드를 감소시키며 TTL 필드가 0이 되는 데이터그램은 버린다(drop). IPv4 멀티캐스트에서 TTL은 문턱값(threshold)의 의미를 지닌다.
다음 예를 보면 그 용도가 분명해진다. 회사에서 모든 호스트가 속하는 아주 길고 대역폭에 한 부서가 대역폭을 많이 차지하는 인터넷 방송을 한다면, 랜에는 엄청난 용량의 트래픽이 발생할 것이다. 인터넷 방송도 하길 원하지만, 멀티캐스트 트래픽 때문에 인터넷 전체가 마비되어서는 안된다. 멀티캐스트 트래픽이 라우터간을 얼마나 멀리까지 이동할 수 있도록 할 것인지 제한할 필요가 있다. 이것이 TTL의 용도다.

TCP Wrapper를 사용하는 방법과 ipchains를 사용할 수 있는데 커널 2.4 버전부터는iptables을 사용한다. hosts.allow와 hosts. deny를 사용한다면, hosts.deny 파일에서 다음과 같이 모두 제한을 한다.

all : ALL

hosts.allow 파일에서 허용할 IP를 여러 개 설정할 경우 다음과 같이 스페이스로 구분하여 준다.

all : xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx ....

ipchains나 iptables의 경우에는 다음과 같이 설정하여 주면 된다.

# ipchains ?A input ?s xxx.xxx.xxx.xxx ?j DENY
# iptables ?A INPUT ?s xxx.xxx.xxx.xxx ?j DROP

안전한 네트워크 다지기

시스템에 기본적으로 설치된 아래의 명령들을 사용하여 네트워크가 정상적으로 작동하지 않는 경우 여러 가지 테스트를 해볼 수 있다.
/etc/sysconfig 디렉토리 밑에 하드웨어에 대한 정보가 나오는데 이더넷 카드가 여러 개 꽂혀 있다면 ifcfg-eth1, ifcfg-eth2 식으로 확인할 수 있다.

/etc/sysconfig/network-scripts/ifcfg-eth0

#cat ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static   /* 정적 아이피 */
BROADCAST=211.47.64.255
IPADDR=211.47.64.80
NETMASK=255.255.255.0
NETWORK=211.47.64.0
ONBOOT=yes   /* 부팅시 자동인식 */

사용하는 IP를 변경하거나, 새로운 네트워크 카드 추가시에는 ifcfg-eth0 파일을 수정한 후에 반드시 ifdown ifcfg-eth0, ifup ifcfg-eth0 명령을 실행해 주어야 변경된 IP가 적용된다. 또 /etc/rc.d /init.d/network restart를 실행해 주어도 된다.

Apache + PHP + MySQL

아파치에만 적용되는 내용은 아니지만 standalone으로 설정할 경우에는 /etc/rc.d/rc.local나 /etc/rc.d/rc3.d/밑에 설정되어 데몬으로 실행되며, inetd로 설정할 경우 /etc/inetd.conf에 추가되어 실행되어 텔넷이나 FTP와 같이 시스템 프로세스로 실행되므로 접속이 많은 httpd 인 경우 standalone으로 설정하여야 한다. 그리고 inetd로 설정시에는 한정된 프로세스만 수용 가능하며 반응속도가 standalone 방식에 비해 느리다.

httpd  -t 옵션으로 우선 syntax error부터 확인한 후 syntax error가 있으면 먼저 수정을 해주고 Logs 디렉토리에서 에러 로그 파일을 확인하여 수정 후 재실행한다.

php3 버전의 경우 index.php3을 php4의 경우 index.php라는 파일을 다음과 같은 내용으로 작성하여 웹에서 열어보면 버전 및 연동 현황을 확인할 수 있다.

<?phpinfo();?>

아파치에서 bandwidth 모듈이 삽입되어 있는 상태라면 모든 호스트에 대해 1024byte로 속도를 제한하기 위해 아파치에서 설정해 주는 부분은 다음과 같다. Httpd.conf에서 BandWidthModule On라고 설정 후 BandWidth all 1024라고 설정한다.

아파치에서 index.html 파일이 없을 때 디렉토리 목록 출력을 원하지 않을 경우에는 DocumentRoot 디렉토리쪽에 설정되어져 있는 옵션에서 Indexes를 삭제한다. 또한 특정 디렉토리에서만 인덱스를 허용치 않을 경우에는 특정 디렉토리의 .htaccess 파일안에 ‘Options -Indexes’ 이 부분을 삽입하면 된다.

안전한 메일 관리법

센드메일에서 한번에 보낼 수 있는 메일 용량은 /etc/mail /sendmail .cf 파일에서 MaxMessageSize 부분에서 다음과 같이 주석을 제거하고 바이트 단위로 설정을 해줄 수 있다. 받는 메일 계정의 용량은 Mlocal 부분에서 M=1000000 부분에서 바이트 단위로 제한량을 적는다.

MaxMessageSize=1000000

relay를 막는 방법도 있지만 그건 외부에서 로컬 서버를 SMTP로 사용하지 못하도록만 할 수 있으며 iptables를 이용하면 로컬 서버에서 보내는 메일에 대해 제한이 가능하다.

# iptables -A OUTPUT -p tcp --syn --dport 25 -j DROP

-A 기존의 iptable에 추가
-p 프로토콜
-dport 포트 넘버
로컬에서 외부로 보내는 메일이라면 remote의 25번 포트로 접속이 되므로 OUTPUT 패킷 중 목적지 포트가 25번인 패킷만 drop 한다. 메일 송수신은 tcp이므로 --syn을 추가하지 않을 경우에는 3 way-handshaking에 의해 메일을 받을 수도 없게 되므로 반드시 --syn을 추가해야 한다. 보내는 메일은 일단 메일큐 디렉토리에 저장된 후 발송되므로 메일큐 디렉토리를 삭제하거나 다른 이름으로 변경하면 메일을 발송할 수 없게 된다.

/etc/mail/access 파일에서 Relay 여부를 설정한다.

localhost  RELAY

변경한 후 적용하려면 다음과 같이 실행해 준다. 또는 인증 기능(SMTP AUTH)이 지원되는 최신 버전의 센드메일을 사용한다.

# makemap hash /etc/mail/access < /etc/mail/access

간단한 방법으로 다음과 같이 텔넷으로 센드메일 포트인 25번으로 접속해 보면 알 수 있다

# telnet jimmy.tt.co.kr 25

가상 계정을 이용해서 해결할 수 있다. 아웃룩에서 jhk라는 계정을 설정하면 jhk at jungheekim.co.kr, webmaster@jungheekim.co.kr로 오는 메일을 모두 받아 볼 수 있다.

# vi /etc/mail/virtusertable
webmaster at jungheekim.co.kr jhk(jhk계정에webmaster라는 계정이 가상계정으로 설정)

해외에 출장이 잦은 사용자가 메일을 자신이 사용하는 웹메일로 포워딩해 달라고 하고, 회사에 돌아와서도 포워딩된 메일을 아웃룩에서 다시 받아보길 원한다면 다음과 같이 한다. 해당 사용자의 홈디렉토리 밑에 .forward 파일을 만들어서 이메일 주소를 입력하고 자신의 계정에는 \를 추가해 주어야 루프를 막을 수 있다.

vi ~junghee/.forward
sitsme75 at hanmail.net, junghee.kim at tt.co.kr

메일을 확인할 수 없는 상황일 때, 메일 수신 후 자동으로 미리 작성되어 있는 메시지를 보낼 수 있는 방법(즉 자동응답 메일 작성 방법)은 자신의 홈디렉토리에 “.procmailrc” 파일을 만들고 다음의 내용을 입력한다.

-------------------------------------------
:0 h c
* !^FROM_DAEMON
* !^X-Loop: YOUR@EMAIL
| (formail -r -A"Precedence: junk"
-I"From: YOUR_NAME "
-A"X-Loop: YOUR@EMAIL
cat $HOME/autoreply.txt) | $SENDMAIL -t
--------------------------------------------
그리고 ‘autoreply.txt’ 파일에 답변 글을 작성하면 그 내용이 자동 답
변된다.

아웃룩에서 메일을 받아보려고 하는데, POP3가 다운되어 반응하지 않을 때 다음과 같이 조정한다. inetd는 기본적으로 1분에 fork 할 수 있는 인스턴스가 40으로 제한되어 있으므로 이 값을 늘려줘야 한다. POP3 부분에서 nowait.200이나 적절한 수만큼 늘려주면 된다. nowait 뒤에 반드시 .(점)을 찍고 허용할 만큼의 POP 데몬의 수를 입력한다. 이후 inetd를 재시작하면 적용된다.


  A # vi /etc/inetd.conf
  # Pop and imap mail services et al
  #pop-2   stream  tcp     nowait  root    /usr/sbin/tcpd ipop2d
  pop-3   stream  tcp     nowait  root    /usr/sbin/tcpd  ipop3d
  #imap    stream  tcp     nowait  root    /usr/sbin/tcpd imapd


철통 보안 관리

① 현재 서버에서 사용하지 않고, 보안상 취약점이 있는 데몬에 대해 서비스를 중지한다.
② TCP Wrapper와 ipchains를 이용한다. 커널 2.4에서는 iptables를 이용해 각 서비스에 대해서 접속을 허락하거나, 제한한다.
③ 섀도우 패스워드를 반드시 이용한다.
④ su 권한의 사용을 특정 사용자만 가능하도록 정의한다.
⑤ 원격에서 루트 권한으로 접속할 수 없도록 한다.
⑥ 지속적으로 패치한다.


echo 1> /proc/sys/net/ipv4/icmp_echo_ignore_all

다시 응답하게 하려면 다음과 같이 실행하면 된다.

echo 0> /proc/sys/net/ipv4/icmp_echo_ignore_all

보통 백도어 파일은 rm 명령으로도 삭제되지 않는다. 속성이 있을 경우 다
음과 같이 삭제 한다.

# lsattr /usr/sbin/in.fingerd
lsattr 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09
-----a-- /usr/sbin/in.fingerd
==> a 속성이 있음을 확인

chattr -a /usr/sbin/in.fingerd
chattr 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09
==> -a로 속성을 해제

# lsattr /usr/sbin/in.fingerd
lsattr 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09
-------- /usr/sbin/in.fingerd
==>해제


lpd는 내부와 원격 프린트 작업을 수행하는 BSD 라인 프린터 데몬이다. lpd 데몬의 접근 권한을 가지고 있는 내부 시스템이나 원격 시스템의 사용자가 특별히 변형된 불완전한 프린트작업을 요청하고 이어서 프린터 큐의 디스플레이를 요청하게 되면 해당 시스템에 버퍼 오버플로우를 일으킬 수 있다. 결국 관리자 권한으로 내부 시스템에 공격 코드를 실행시킬 수 있게 된다. 따라서 패치를 해주거나 서비스를 하지 않는다면 데몬을 중지하는 것이 좋다.

BIND 4.x, 8.x에서 문제가 검출되었다. BIND 8 버전에서는 트랜잭션 시그너쳐(TSIG) 핸들링 코드에 버퍼오버플로우 취약점을 포함하고 있다.
유효한 키를 포함하지 않는 TSIG를 발견하는 경우 BIND 8 버전에서는 에러응답을 보내기 위한 코드를 실행하게 되며, 이때 발생하는 변수 초기화 방식의 차이에 의해 해당 취약점이 발생하게 된다. DNS 시스템에 대한 요청 접근만으로 해당 취약점을 발생시킬 수 있으므로 이로 인한 위험성은 크게 된다.
BIND 4 버전에서는 nslookupComplain( ) 내부에 있는 문자 배열(syslog 를 위한 에러 메시지 작성 버퍼)에 대해 버퍼 오버플로우 취약점을 포함하고 있다. 특수한 포맷 형태를 가진 쿼리를 전송함으로써 해당 취약점을 발생시킨다.
또한 nslookupComplain( ) 내부에 있는 문자 배열(syslog를 위한 에러 메시지 작성 버퍼)에 대해 입력 검증(input validation) 취약점을 포함하고 있다. 이것은 특수한 포맷 형태를 가진 쿼리를 전송함으로써 입력 검증 취약점을 발생시킨다.
BIND 4,8 버전에서는 해당 서버가 쿼리를 처리하는 동안 정보가 누출(information leak)될 수 있는 취약점을 포함하고 있다. 특수한 포맷 형태를 가진 쿼리 전송을 통해 공격자가 프로그램 스택에 접근할 수 있게 함으로써 해당 취약점을 발생시킨다.
해결책은 BIND 버전은 8.2.3 이상이나 9.1버전으로 업그레이드하는 것이다. 이것은 해결책이 아니라 시스템 관리자가 반드시 해야 할 일이다.

장애 발생시 복구

대부분 정전이 발생한 후에도 시스템은 정상적으로 부팅되며 파일시스템도 자동으로 check하지만 간혹 관리자가 수동으로 해주어야 하는 경우가 발생한다. 리눅스가 다운 되었을때 보통 Power OFF를 하는데, 이때 문제가 발생할 수 있으므로 Magic SysRq라는 것을 이용하여 안전하게 재부팅하는 방법을 이용한다.
Magic SysRq key란 시스템의 제어가 불가능한 상태(일반적으로 ‘다운’되었다고 한다)에서도 제어를 가능하게 해주므로 커널 컴파일시 Kernel hacking ---> [*] Magic SysRq key를 체크해야 한다. Magic SysRq key를 사용하려면 다음과 같이 /proc/sys/kernel /sysrq 값을 1로 만들어야 한다.

# echo 1 > /proc/sys/kernel/sysrq
lilo: linux init=/bin/sh

그러면 커널이 뜨고 나서 바로 shell prompt ‘#’가 나타난다. 이때에는 filesystem도 read only로 마운트 되고, 동작하는 deamon process도 전혀 없는 상태가 된다. 그 상태에서 수동으로 모든 파일 시스템을 체크한다.

# fsck [-t ext2] 장치명
# e2fsck 장치명

위의 명령 사용시 문제가 생긴 블록의 수정 여부를 묻게 되는데 ‘y’를 선택하고 만약 수정여부를 묻는 질문이 많다면 -y 옵션을 사용하여 자동으로 ‘y’를 선택하게 할 수 있다.

# e2fsck -y 장치명

Ctrl-Alt-Del로 리부팅하면 아주 심하게 깨지거나, 디스크에 이상이 있지 않는 한 복구가 된다.