[시스템][메일][웹서버] 시스템 장애 시 대처 방안

리눅스 시스템 장애시 대처 방법

시스템 관리자는 시스템에 대해 보수적이어야 한다는 말이 있다. 이 “보수적” 이라는 말은

특정한 정치적 성향을 뜻하는 것이 아니라 시스템에 대해 단 1%라도 문제가 될 수 있는

여지를 제거하고, 각 유저

에게는 불편함을 주지 않는 한도내에서 가급적 사용 권한을 제한하여 혹시나 있을지 모를

시스템의 침해나 크래쉬등에 대비하는 것을 뜻한다. 아울러 새로운 룰을 적용 또는 변경

하거나 프로그램을 새로이 도입할 때에도 이 프로그램으로 인하여 다른 문제가 발생할

수 있는 여지는 없는지 여부를 신중히 검토 후 도입하여야 한다.

따라서 이번 호에서는  리눅스 서버를 운영해 오면서 서버 관리자라면 누구나 접할 수

있는 여러 가지 장애와 이에 따르는 원인과 해결 방법을 찾아가도록 하겠다.

오늘과내일 넷센터 홍석범 (antihong at tt.co.kr)

1.        일반적인 시스템 장애와 대처 방법

2.        메일서버(sendmail, pop3) 의 장애와 대처방법

3.        아파치 웹서버 에서의 장애와 대처방법

1. 일반적 시스템 장애 및 대처법

문) 서버가 정전이 되어 스스로 재부팅을 한 이후 아래와 같이 에러가 뜨면서

부팅이 되지 않습니다. 어떻게 해야 할까요?

   /dev/hda1: Unattached inode 31875

   /dev/hda1:UNEXPECTED INCONSISTENCY: Run fsck MANUALLY.

   (i.e., without -a or -p option)  [FAILED]

   *** An error occurred during the file system check.

   *** Dropping you to a shell; the system will reboot

   *** when you leave the shell

   Give root password for maintenance

   (or type Control-D for normal startup):

답)  시스템의 셧다운 과정에서 정상적인 파일 시스템의 언마운트 과정을 거치지 않은

채로 부팅시 파일 시스템 체크를 할 때 위와 같은 에러가 발생합니다.

이러한 경우에는 먼저 root 로 로그인한 이후 fsck –f  /dev/hda1 과 같이 에러가 난

장치에 대해 파일 시스템 체크를 수동으로 돌려준 후 재부팅을 하시면 됩니다.

이에 대한 자세한 설명은 본지 8월호의 서버 관리자를 위한 실전팁을 참고하세요.

문) 위와 같은 상태에서 파일 시스템 체크를 하려고 암호를 입력하였는데, root 암호가

변경되었는지 로긴이 되지 않습니다.  single 모드로 부팅해도 위와 같이 파일 시스템

체크 에러만 납니다. 리눅스를 다시 설치해야 하나요?

답) 이러한 경우에는 부팅시 LILO 에서 init 옵션을 주어야 합니다.

부팅시 lilo: linux init=/bin/sh  와 같이 입력하여 부팅하면 kernel이 뜨고 나서

바로 shell prompt ‘#’ 가 나타납니다.  이 때에는 file system도 read only로 mount

되어있고 동작하는 deamon process도 전혀 없는 상태입니다. 이 상태에서 수동으로

모든파일 시스템을 체크한 후 Ctrl-Alt-Del로 재부팅을 하시면 아주 심하게 깨지거나

disk에 이상이 있지 않는 한 복구가 될 것입니다.  

만약 쓰기 옵션이 필요한 경우에는 lilo 에서 lilo: linux init=/bin/sh –o rw 와 같이

-o rw 옵션을 추가하면 쓰기 모드로 부팅합니다.

문) 실수로 /dev/null 을 삭제하였습니다.

  /dev/null 을 다시 설정 하려면 어떻게 해야 하나요?

답)  mknod /dev/null1 c 1 3 –mode=666 로 생성하면 됩니다.  

ls –la /dev/null 로 확인시 ….

   crw-rw-rw-    1 root     root       1,   3  5월  6  1998 /dev/null

와 같이 보여야 합니다.

문) 부팅시 LILO 가 깨져서 부팅이 되지 않습니다. 대처법을 알려주세요?

답)  먼저 CD-ROM 으로 부팅후 설치 선택 화면에서 . [Alt+F2] 키로 쉘 프롬프트

(bash#)로 전환합니다. 그리고  mount -t ext2  sda1 mnt_tmp 로 기존에 설치된

리눅스의 루트 파티션(/) 을 마운트합니다. 이때 mnt_tmp는 루트 파티션을 임시로

마운트 할 디렉토리입니다. 그리고 /mnt_tmp/bin/vi  /mnt_tmp/etc/lilo.conf  로

lilo.conf 파일을 수정할 부분이 있는지 확인합니다. 마지막으로 아래와 같이 –r과 –C  

옵션을 이용하여 lilo를 재실행하면됩니다.  

/mnt_tmp/bin/lilo -r /mnt1 -C /etc/lilo.conf  와 같이 실행하는데,  여기서 –r 은

루트 디렉토리를 뜻하며 –C 는 설정파일의 위치를 정의하는 옵션입니다. 이후

umount /mnt_tmp 로 언마운트하고 재부팅을 하면 됩니다.

문) 이더넷 카드 설정등에 아무런 이상이 없는데, 갑자기 네트워크가 안됩니다.

부팅한지 오래 되어서 그런가요? 참고로 eepro100 을 사용 중입니다.

답)  ifconfig 로 인터페이스의 상태를 조회시

RX,TX가 아래와 같을 경우 시스템을 재부팅 하여야  한다고 알려져 있습니다.

(network restart 는 적용되지 않습니다.)

RX packets:2147483647

TX packets:2147483647

참고로 위와 같이 RX, TX 값인 2147483647 라는 값은 2의 31승 -1 의 값으로 변수를

long 으로 정의할 때의 최대값입니다…

문)  telnet 으로 로그인한 유저가 메모리를 많이 소모하는 프로그램을 실행하여

부하가 높아지고 있습니다. 유저가 사용하는 메모리를 제한하는 방법을 알려주세요.

답)  현재의 리눅스 시스템은 고의적이든 그렇지 않든 DoS성 공격에 무방비 상태입니다.

따라서 간단한 무한루프 스크립트가 돌기만 하면 서버는 바로 다운이 되어 버리는데,

이를 위해 아래의 내용을 /etc/profile 에 추가하면 로그인하는 모든 유저에게

적용이 됩니다.

if [ $LOGNAME != “root” ];       # root 는 제한하지 않음.

then

ulimit -Sv 10000          # 각 유저가 사용 가능한 가상메모리를 10메가로 제한.

ulimit -Su 15             # 생성 가능한 프로세스를 15개로 제한.

fi

위와 같이 설정 후 아래와 같이 메모리를 많이 소모하는 프로그램을 실행하면 제한 설정한

20메가를 초과하지 못하고 실행이 중단되게 됩니다. 물론 위 제한이 없을 경우에는 실행

과 동시에 가능한 많은 메모리를 소모하므로 제어가 불가능한 다운 상태가 되겠지요.

기타 ulimit 에 대한 자세한 내용은 help ulimit 를 참고하시기 바라며 아울러 사용 제한을

너무 타이트하게 설정시에는 컴파일등 정상적인 프로그램 조차 작동하지 않을 수 있으므로

각자의 시스템 상황에 맞게 적절히 설정하여 사용하시기 바랍니다.

2. 메일서버의 장애와 대처 방법

(문)  sendmail 을 이용해 메일 서비스를 제공하고 있는데, 특정한 유저가 너무

큰 사이즈의 메일을 보내거나 받고 있어 서버에 과부하가 걸리고 있습니다.

유저가 주고 받을 수 있는 메일의 사이즈를 제한할 수 있는 방법이 없을까요?

답) sendmail 은 외부로 메일을 발송하는 SMTP(보내는 메일서버) 기능도 있지만

외부에서 서버내 계정으로 전송되는 메일을 받는 기능도 있습니다. 이때 기본적

으로는 보내거나 받는 메일의 양에 대한 제한이 전혀 없어 10메가 이상이 넘는

큰 사이즈의 메일이 송수신 될 경우 서버에 과부하가 걸릴 수 있으므로 아래와

같이 각각의 설정(보내는 메일과 받는 메일의 양) 을 적절히 제한하여 설정하는

것이 좋습니다.

>> SMTP 서버에서 보내는 양 제한하는 법.

/etc/mail/sendmail.cf (또는 /etc/sendmail.cf) 파일에서 다음과 같이

MaxMessageSize  부분의 주석을 제거하고 제한하고자 하는 적절한 값을

입력합니다

# maximum message size

O MaxMessageSize=5024000

위와 같이 설정하였을 경우 현재의 서버를 보내는 메일 서버로 이용시 첨부파일이

5M 이상 초과하거나 /usr/sbin/sendmail 을 실행하여 외부로 메일을 발송하는 메일링

리스트등의 프로그램에서도 메일 발송시 5 메가 이상의 메일은 보낼 수 없게 됩니다.

5024000 은 byte 단위이며 설정 변경 후 변경된 내용을 적용하려면

killall –HUP sendmail 로 sendmail 데몬을 Refresh 하여야 합니다.

>> 받는 메일 서버에서 받는 양 제한하는 법.

외부에서 서버로 들어오는 메일에 대해서 용량을 제한하고 싶다면 같은 파일

(sendmail.cf) 에 대해서 “Local and Program Mailer specification” 부분을 설정해

주면 됩니다.

Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30,

R=20/40, M=5024000, T=DNS/RFC822/X-Unix, A=procmail -Y -a $h -d $u

위와 같이 T=DNS/RFC822/X-Unix  앞부분에M=5024000 부분을 추가해 주면 됩니다.

마찬가지로 5024000는 byte 단위이며 원하는 용량만큼 적절히 설정해 주면 됩니다

역시 설정 변경 후 sendmail 을 refresh 하면 적용이 됩니다.

위의 경우 서버에서는 5메가 이상의 메일은 수신하지 않으며 5메가 이상의 메일을

보낸 이는

552 5.2.3 <antihong at tt.co.kr>… Message is too large; 5024000 bytes max

554 5.0.0 <antihong at tt.co.kr>… Service unavailable

와 같은 에러 메시지를 받게 됩니다.  

아울러

# maximum number of recipients per SMTP envelope

O MaxRecipientsPerMessage=20

와 같은 부분이 있는데, 이 부분은 한번에 메일 발송 시 동시 발송(참조 발송)이 가능한

메일 계정의 수를 뜻합니다. 기본적으로 이 값에는 제한이 없는데, 주석을 삭제한 후

적절한 값을 설정해 주면 한번에 동시 발송 가능한 메일의 수도 제한할 수 있습니다.

(위의 경우에는 한번에 참조 발송이 가능한 메일 유저를 20명으로 제한)

설정이 끝난 후에는 killall –HUP sendmail 로 sendmail 을 재가동해주면 바로

적용됩니다.

문) 현재 sendmail 이 정상적으로 작동하는지 여부를 알려면 어떻게 확인 가능

하나요?

답) 다음과 같은 두 가지 방법으로 가능합니다.

(1) # ps auxw|grep sendmail 로 확인시

root   0.0  0.0  2684 1460    S  Aug24 sendmail: accepting connections on port 25

와 같이 sendmail: accepting connections 로 보이면 정상적으로 작동하는 것입니다.

만약 어떠한 이유로 작동하지 않을 때는

sendmail: rejecting connections 라는 메시지가 보이게 됩니다.

(2) sendmail 이 반응하는 25번 포트로 접속을 시도합니다.

# telnet pserang.co.kr 25

Trying 211.40.58.226…

Connected to pserang.co.kr.

Escape character is ‘^]’.

220 www.pserang.co.kr ESMTP Sendmail 8.11.2/8.11.2; Sun, 2 Sep 2001……

와 같이 25번 포트로 telnet 을 접속하면 sendmail 이 반응을 하게 되는데, 위와 같이 접

속을 하여 응답이 있을 경우에는 접속을 받아들일 준비가 되어 있는 상태이며

반응하지 않을 때는

Trying  pserang.co.kr…

telnet: Unable to connect to remote host: Connection refused

와 같이 접근이 거부되었다는 것을 알 수 있게 됩니다.

문)  갑자기 sendmail 이 작동하지 않습니다. 원인과 해결책을 알려주세요?

답) sendmail 이 작동하지 않는 경우는 2가지입니다.

첫번째는 시스템의 Load Average 가 높아져 sendmail 이 작동하지 않는 경우이고

두번째는 sendmail 에서 받는 메일이 저장되는 /var 파티션이 100%가 되었을 경우

입니다.

Sendmail 은 기본적으로 시스템의 Load Average 수치가 12를 초과하였을 경우에는

자동으로 작동하지 않게 됩니다.  이는 sendmail이 서비스 거부 공격등으로 시스템의

부하가 높아졌을 때 sendmail 로 인하여 시스템이 다운되는 것을 막기 위한

조처로 이 값은 sendmail.cf의

# load average at which we refuse connections

O RefuseLA=12

에서 수정해 주신 후 killall –HUP sendmail 로 재실행해 주면 되고 이 값은 각각의

시스템에 따라 적절히 조정하시면 됩니다.  만약 현 시스템의 특성상 늘 부하가 높아

로드가 자주 12를 초과한다면 이 값을 각자의 시스템 환경에 맞게 적절히 조절하여야

외부에서 오는 메일을 받을 수 있게 됩니다. 그리고 메일이 저장되는 /var/spool/mail

파티션이 가득 찼을 경우(100%) 에도 sendmail 이 작동하지 않으므로 파티션이

가득 찼을 경우에는 /var/log/ 등에서 불필요한 데이터를 삭제하여 /var/spool/mail

이 포함된 파티션이 100% 를 넘지 않도록 합니다. 파티션이 100%가 넘지 않으면

sendmail 이 자동으로 살아납니다.

또한 시스템의 Load Average 가 8이 넘으면 서버를 통해 메일을 발송해도 바로

전송되지 않고 일단 메일 큐에 저장이 된 후에 발송이 되게 됩니다. 이 역시 같은

이유 때문인데 이 수치는 sendmail.cf 의

# load average at which we just queue messages

O QueueLA=8

에서 적절히 설정하면 됩니다.

참고로 현재 시스템의 Load Average는 w 명령어를 이용하여 확인 가능합니다.

w 를 이용시 시스템의 Load Average 는 0.25, 0.40, 0.43  와 같이 보이는데

이는 각각 현재를 기준으로 지난 1분, 5분, 15분간의 평균 시스템 부하율을

나타냅니다.

문) 각 유저에게 디스크 용량 쿼터를 설정하고 있는데, 메일 용량에 대해서도

쿼터를 걸 수 있나요?

답)  Sendmail 을 이용할 경우에는 다소 복잡하기는 하지만 쿼터 설정이 가능은

합니다. 먼저 각 유저의 메일은 /var/spool/mail/ 디렉토리에 자신의 계정 소유로

저장이 되게 됩니다. 바로 이 특성을 이용하면 되는데, 쿼터는 각 파일 시스템별로

각각 설정이 가능하므로 각 유저의 홈디렉토리외에 /var 파티션에도 추가적으로

쿼터를 설정하면 됩니다. 쿼터를 설정하는 방법은 똑같습니다.

먼저 /etc/fstab 파일을  열어 /var 파티션이 별도로 설정되어 있다면 /var 파티션에,  

없으면 / 파티션에 유저쿼터 설정을 합니다.

/dev/sda8        /       ext2    defaults,usrquota=/home/.mailquota

이후 touch /home/.mailquota 로 파일을 생성한 후,  quotacheck –a 를 실행하여

파일 시스템을 스캔하여  디스크 사용량을 체크합니다.

edquota user 로 한 유저에 대해 일정 양의 쿼터를 설정한 후

(30메가로 쿼터를 설정할 경우 soft = 29980, hard = 29980와 같이 설정)

edquota -p user `awk -F: ‘$3 > 499 {print $1}’ /etc/passwd`

를 실행하면  edquota 프로그램은 /etc/passwd 에 정의된 유저중 UID 가 499

이후의모든 유저에 대해 “user” 의 쿼터 설정을 그대로 복사하게 됩니다.

만약 쿼터가 초과된 계정에 메일을 발송하게 되면 아래와 같은 에러 메시지가 나며

더 이상 메일을 수신하지 못하게 됩니다.

—————————————————————

The original message was received at Thu, 21 Jun 2001 01:23:20 +0900

from [211.47.158.17]

   —– The following addresses had permanent fatal errors —–

<antihong at tt.co.kr>

    (reason: can’t create (user) output file)

   —– Transcript of session follows —–

procmail: Quota exceeded while writing “/var/spool/mail/antihong”

550 5.0.0 <antihong at tt.co.kr>… Can’t create output

문)  sendmail 을 받는 메일 서버로만 작동하도록 하고 보내는 메일 기능은

사용하지 못하도록 하고 싶습니다. 어떻게 하면 될까요?

답) sendmail 에서 Relay 기능을 막아 두었다 하더라도 최근 버전에는 사용자

인증(SMTP AUTH) 기능이 있어 서버에 계정이 있으면 모든 유저가 메일 서버를

이용해 SMTP 기능을 이용하여 메일을 발송할 수 있습니다. 자신의 서버가 이

기능을 제공하는지를 알아보려면

[root@www /root]# netstat -na | grep :587

tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN

로 확인해 보아 587번 포트가 LISTEN하면 지원되는 것이고, 그렇지 않으면

지원되지 않는 것입니다. 따라서 이를 막으려면 최신의 8.11.4 나 8.11.5 와

같이 최신 버전으로 업그레이드 후 /etc/mail/smtpauth 파일에 보내는 메일  

기능을 허용할 유저를 입력해 주시면 됩니다.

(최근에 8.11.X 버전에 심각한 보안 문제가 확인되었으므로 반드시 8.11.6버전으로

업그레이드하셔야 합니다.)  파일을 생성 후 아무런 유저도 입력하지 않으면 서버에

계정이 있다 하더라도 어느 누구도 메일을 발송할 수 없게 됩니다. 따라서 최신의

8.11.6 버전으로 업그레이드 하실 것을 권장합니다. 이외 여러 변형된 방법이 존재

하는데,ipchains 나 iptables 를 이용해 패킷 필터링을 하는 방법도 있습니다.

커널 2.2.X 일 경우

ipchains -A output -p tcp -y -d 0/0 25 -j DENY

커널 2.4.X 일 경우

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

위와 같이 설정시 목적지(Target) 포트가 25번 포트로 향하는 초기화(SYN) 패킷만을

차단하여 메일을 발송할 수 없도록 합니다. 물론 초기화(SYN) 패킷에 대해서만 필터링

을 하였으므로 외부에서 오는 메일을 받는 것은 관계 없습니다.

문) Sircam 바이러스 메일 때문에 고생하고 있습니다.

sendmail 에서 각종 바이러스 메일을 차단할 수 있는 방법을 알려주세요.

답) sendmail 에서 룰셋(ruleset)을 이용하여 차단하는 기능이 있습니다.

Sendmail 에서는 제목이나 메일러 또는 첨부파일의 화일명등 각종 메일헤더 정보를

이용하여 필터링을 할 수 있는데, 예를 들어 발송되는 메일 제목(subject)으로 필터링

을 해 보도록 하겠습니다. 아래는 메일 제목에 ILOVEYOU 로 발송하는 멜리사 바이

러스를 차단하는 룰셋을 적용해 본 예입니다.

먼저 sendmail.cf 파일을 열어 제일 하단에 아래의 내용을 추가합니다.

HSubject: $>Check_Subject

D{WORMmsg}Access Denied – This message may contain a virus.

SCheck_Subject

RILOVEYOU               $#error $: 501 ${WORMmsg}

RRe: ILOVEYOU           $#error $: 501 ${WORMmsg}

RFW: ILOVEYOU           $#error $: 501 ${WORMmsg}

# 주의 :  $#error 앞의 blank는 스페이스가 아니라 탭으로 띄워주어야 합니다.

Sendmail.cf 의 내용이 다소 어렵고 복잡하기는 한데, 위 설정의 의미를 간단히

살펴보도록 하겠습니다.

H — 위 경우에는 헤더에서 Subject:라는 문자열을 찾아 이 헤더를 Check_Subject

로 정의합니다.

D — WORMmsg 라는 매크로를 정의하여 해당 룰셋에 적용되는 제목을 확인시 발송한

    유저에게 보낼 메시지를 정의합니다.

S — 헤더에서 check_subject로 정의한 부분을 룰셋으로 지정하는 부분입니다.

R — 해당 문자열이 포함된 메일을 발견시 앞에서 정의한 에러 메세지를 첨부하여

     반송을 시킵니다.

위의 경우 “I LOVE YOU” 와 같이 공란이 있을 경우 적용되지 않으며

“ILOVEYOU from me” 와 같이 특정 단어가 추가시에도 적용되지 않으며 반드시

정확히 일치하여야 합니다. 추가적으로 회신시 추가되는 Re: 와 전달(포워딩)시

추가되는 FW: 가 추가된 메일도 거부합니다.

다음으로 최근 유행하는 Sircam 바이러스 메일을 필터링해 보도록 하겠습니다.

Sircam 바이러스의 헤더를 보면 정상적인 메일과는 달리 메일 헤더에

Content-Disposition: Multipart message 와 같은 부분이 추가되어 있으며 이 특징

을 이용하여 필터링이 가능합니다.

Sendmail,cf 파일에 아래의 룰셋을 추가하면 됩니다.

HContent-Disposition: $>check_sircam

D{SIRCAM}”Warning: Your message contains the Sircam.worm Virus”

Scheck_sircam

RMultipart message      $#error $: 550 ${SIRCAM}

# 주의 :  $#error 앞의 blank는 스페이스가 아니라 탭으로 띄워주어야 합니다.

Sendmail.cf의 수정을 끝낸 후 바로 sendmail을 재 시작하지 말고

룰셋이 정상적으로 작동하고 있는지 아래와 같이 테스트를 하는 것이 좋습니다.

# /usr/lib/sendmail –bt                 # 테스트 모드로 접속

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)

Enter  

> check_sircam Multipart message        # Sircam 룰셋 테스트

check_sircam   input: Multipart message

check_sircam   returns: $# error $: 550 553 Warning: Your message contains

the Sircam.worm Virus (한줄에 다 써준다.)

> ctrl-D                                # 테스트 종료

위와 같이 확인된 후 sendmail을 재시작(killall –HUP sendmail) 하면 바로 적용됩

니다.아래와 같이 tail –f  /var/log/maillog 로 로그 파일을 지켜보면 아래와 같이 실제

로 Sircam 바이러스가  필터링되고 있음을 확인할 수 있습니다.

Sep  27 15:09:51 www sendmail[21386]: f8369of21386: to=<antihong at tt.co.kr>,

delay=00:00:01, pri=241584, stat=553  Warning: Your message contains the

Sircam worm Virus. (한줄에 다쓴다..)

이외 메일 필터링에 대한 구체적인 방법에 대해서는  

http://certcc.or.kr/paper/tr2001/tr2001-03/email security by procmail.html 나

http://quanta.khu.ac.kr/~dacapo/sendmail/rulesets/ 를 참고하시기 바랍니다.

문) sendmail 과 관련된 몇 가지 유용한 명령어를 알려주세요.

답)

>> mail1q

mailq 프로그램의 목적은 큐잉된(/var/spool/mqueue 에 저장된) mail 메시지의

요약된 정보를 보여줍니다.  네트워크 다운등 어떤 특정한 이유로 바로 발송되지

못한 메일은 일차적으로 /var/spool/mqueue 에 큐잉된 상태로 저장된 후 일정

시간마다 발송을 위해 재시도가 되는데,  현재 큐잉된 메일 메시지의 요약 정보를

보려면 아래와  같이 확인할 수 있습니다.

# mailq

/var/spool/mqueue/q1 (2 requests)

—-Q-ID—- –Size– —–Q-Time—– —Sender/Recipient——–

f7A84oV15068     1446 Fri Aug 10 17:04 nobody

                 (Deferred: Connection timed out with kebi.net.)

                                       darling at kebi.net

f775ieF24893   521898 Tue Aug  7 14:44 <shlee at tt.co.kr>

                 (Deferred: Connection timed out with mail.unitel.net.)

                                       <cf1318 at unitel.net>

/var/spool/mqueue/q2 is empty

                /var/spool/mqueue/q3 (1 request)

—-Q-ID—- –Size– —–Q-Time—– —Sender/Recipient——-

f775nJF25249   230815 Tue Aug  7 14:49 <shlee at tt.co.kr>

                 (Deferred: Connection timed out with hanmail.com)

cuwww23 at hanmail.com

위 메시지를 보면 어떠한 이유로 메일이 발송되지 못하고 있는지를 추측할 수 있습니다.

3 메시지 모두 수신자의 e-mail 주소를 잘못 기입했기 때문인데, 각각 kebi.com 인데,

kebi.net 으로 unitel.co.kr 인데, unitel.net 으로 , hanmail.net 인데, hanmail.com 으로

도메인 주소를 잘못 기입하여 발송하여 메일을 발송하지 못하고 큐에 저장되어 있는 것

을 확인할 수 있습니다.

여기에서 주의할 점은 mailq 명령어는 일반 유저로 실행하여 확인이 가능하므로

퍼미션을 700 으로 조절하여 일반 유저들은 실행할 수 없도록 하는 것이 좋습니다.

>> mailstats

mailstats 프로그램은 현재의 메일 송수신과 관련하여 통계를 보여줍니다.

  * 현재의 메일 통게를 보려면 아래와 같이 확인할 수 있습니다.

# mailstats

Statistics from Sat Aug 11 04:02:02 2001

M   msgsfr  bytes_from   msgsto    bytes_to  msgsrej msgsdis  Mailer

1        0          0K        3        317K        0       0  *file*

4      690     596691K      824     137070K    68426       0  esmtp

9       63      12212K        0          0K       27       0  local

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

T      753     608903K      827     137387K    68453       0

C      753                  827                68453

이를 적절히 이용하면 mrtg 를 이용해 일정 시간마다 발송되고 수신되는 메일의 개수를

통계로 내어 그래프로 보실 수 있습니다.

문) 아웃룩 익스프레스에서 배달을 누르면 메일이 받아지지 않습니다.

원인과 해결 방법 좀 알려주세요.

답) 여러가지 이유가 있을 수 있으니 아래의 사항에 대해 하나씩 찾아보시기 바랍니다.

(1)        IMAP 패키지가 설치되지 않았을 경우

서버에 저장되어 있는 자신의 계정으로 온 메일을 클라이언트 PC에서 받으려면

pop3 데몬이 반응하게 됩니다.  pop3d 는 IMAP 패키지안에 포함되어 있으므로

IMAP 패키지를 설치하셔야 pop3 를 사용하실 수 있습니다. rpm –q imap 으로

확인합니다.

(2)        Inetd 에 설정되어 있지 않을 경우

pop3d 는 inetd 또는 Xinetd 에서 작동하게 됩니다.

/etc/inetd.conf 또는 /etc/xinetd.conf 파일을 살펴보아 ipop3 가 주석처리 되어

있지는 않은지 확인합니다.

(3)        TCP Wrapper 에 설정되었는지 여부 확인

/etc./hosts.deny 에 pop3d 접근이 차단되지는 않았는지 확인합니다.

(4)        계정에 Lock 이 걸리지 않았는지 확인

메일을 받는 과정에서 갑자기 회선이 끊기거나 PC가 다운되는 등 비정상적으로

종료시 서버의 pop3d 프로세스가 죽지 않고 계속 남아 있는 경우가 있습니다.

이러한 경우 계정에 “Lock 이 걸렸다” 고 하며 이러한 경우에는 해당 프로세스를

찾아 kill 을 하면 됩니다.

(5)        Pop3 접속이 많은 경우

Pop3d 가 서비스되는 inetd는 기본적으로 60초동안 40회의 접속을 받아들이도록

(즉 maximum 40회 fork되도록) 되어 있습니다. 따라서 짧은 시간에 pop3d 요구가

많을 경우에는 pop3d 데몬 자체가 다운되어 버리므로 동시에 처리 가능한 프로세스

의 한계를 적절히 높여주시면 됩니다.  이를 위해서는 /etc/inetd.conf 를 열어

아래와 같이 수정합니다.

기본설정

pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d

변경 설정

pop-3 stream tcp nowait.200 root /usr/sbin/tcpd ipop3d

(위의 경우 처리 가능한 프로세스를 200회로 늘려줍니다.)

이후 killall -HUP inetd 를 하시면 됩니다.

(6)        110 번 포트로 확인

아래와 같이 pop3d 포트인 110번 포트로 직접 접속하여 수작업으로 확인 가능합니다.

# telnet  pop3.mail.sevrer 110           # 110번으로 직접 확인

Trying 210.17.6.5…

Connected to pop3.mail.server.

Escape character is ‘^]’.

+OK POP3 pop3.mail.sevrer v2001.76 server ready

user abc                              # abc 라는 계정으로 접속

+OK User name accepted, password please

pass xyz                              # abc 의 암호 xyz 입력

+OK Mailbox open, 10 messages

quit                                  # 접속을 끊음.

+OK Sayonara

Connection closed by foreign host.

위의 경우는 정상적인 경우이며 에러가 있을 경우 각각의 경우에 따라 에러 메시지를

확인할 수 있습니다.

(7)        mail –v 로 확인

타 서버에서 mail –v abc at pserang.co.kr 로 메일을 발송하여 정상적으로 메일이

도착하는지를 확인해 봅니다. –v 옵션을 이용하여 메일 발송시에는 메일 전송의

경로 및 메일 서버간에 주고받는 메시지를 확인할 수 있으므로 문제의 원인을

찾는데 도움이 됩니다.

문) 메일이 발송되지 않습니다.  원인이 뭘까요?

답) 메일이 보내지지 않는다면 보내는 메일서버(SMTP) 의 문제입니다.

먼저 클라이언트 프로그램에서 지정한 SMTP 서버를 확인 후

telnet smtp .mail.server 25 로  접속이 되는지를 확인 후 /etc/mail/access

에서 Relay 가 허용되어 있는지 확인합니다.

또한 최근 버전에서는 IP 별로 Relay 하는 기능외에 서버에 계정이 있을

경우/etc/mail/smtpauth 파일에서 계정별로 접근을 허가하거나 차단할 수 있는

기능이 추가되었으므로 이의 설정여부를 확인해 보면 됩니다.

문) 기타 메일과 관련된 장애가 확인 시 처리할 수 있는 방법을 알려주세요.

답) 문제나 장애가 발생시에는 반드시 로그 메시지를 살펴보아 문제의 원인을

찾아보시는 습관을 들이시는 것이 좋습니다. 메일 관련 로그는

/var/log/messages 나 /var/log/maillog 파일을 살펴보시면 됩니다.

3. 아파치 웹서버에서의 장애처리 방법

문) http://tt.co.kr/~antihong/ 과 같이 하면 접속이 되는데, http://tt.co.kr/~antihong

과 같이 끝에 / 을 하지 않으면 접속이 잘 되지 않습니다. 왜 그런가요?

답) 클라이언트가 서버의 디렉토리에 접속시 끝에 / (trailing) 을 하지 않은 경우 서버는

클라이언트에게 / 을 붙여 다시 접속을 하라고 요청합니다. 그렇지 않으면 상대 URL

경로를 인식하지 못하는 문제가 있기 떄문이지요. 만약 DNS 가 정상적으로 세팅되어

작동하고 있을  경우에는 문제가 없지만 그렇지 않은 경우에는 접속이 되지 않는 경우가

생깁니다. 또는 ServerName 에 지정된 호스트네임이 실제로 DNS 상에 리졸빙이 되지

않는 경우도 이러한 현상이 나타나므로 이러한 경우에는 httpd.conf 의 ServerName

옵션에 실제 서비스중인 도메인명으로 입력해 주면 됩니다.

문) 갑자기 웹접속이 안 되거나 되어도 접속이 너무 느려져 아파치 데몬을

확인해 보니 httpd 가 256개나 떠 있었습니다. 어떻게 해야 하나요?

답) 기본적으로 아파치 웹서버의 경우 MaxClients 가 256으로 설정되어 있어

동시에 256개의 데몬이 뜨게 되면 더 이상의 접속을 받아들이지 않고, 기존의

프로세스가 죽을 때까지 대기한 후 접속이 끊기게 되면 그제서야 접속을 받아

들이게 됩니다.

따라서 동시 접속이 많은 경우에는 이전의 웹접속이 끊길 때까지 대기를 하여야

하므로 접속 속도가 느린 것처럼 느끼시게 되는 것입니다.

일반적으로 정상적인 접속의 경우에 256개의 프로세스가 모두 뜨는 경우는 그리

많지 않기에 현재의 상태가 비정상적인 접속인지 여부를 판단하여야 합니다.

이를 판단할 수 있는 방법은 netstat –na | grep ES 로 ESTABLISHED 된 연결

상태를 확인하여 클라이언트의 IP 가 정상적인 연결인지 여부를 확인하면 됩니다.

또는 netstat -na|grep ES|awk ‘{print $5}’|sort 로 클라이언트의 IP만 따로 Sort

하여 확인하여 보도록 합니다. 통상적으로 HTTP 1.1 규약에서부터 적용되기 시

작한 KeepAlive 기능을 지정시 한 클라이언트 IP 에서 동시에 3-5개정도의 http

프로세스를 생성하므로 한 IP 에서 3-5개정도의 프로세스를 생성하는 것은 정상

적인 현상입니다. 비정상적인 접속의 경우에는 아래와 같은 이유가 있을 수 있습니다.

(1)        서비스 거부 공격(DoS) 의 경우

동시에 서비스할 수 있는 프로세스의 한계가 있다는 점을 악용한 서비스 거부

공격일 가능성이 있습니다. 이미 한번의 실행으로 100개나 200개등 원하는 만

큼의 동시 접속을 맺은후 이 접속을 끊지 않고 유지할 수 있는 공격 코드가

공개되어 있습니다. 그러나  이러한 공격의 경우 공격지의 IP 를 속이기가

매우 어려우므로 netstat 으로 확인 후 비정상적인 접속으로 확인시 해당 IP

를 차단하면 됩니다.

특정 IP의 라우팅을 차단하는 방법은 아래와 같이 route 를 이용한 방법과

iptables (커널 2.4 이상) 를 이용한 방법 이렇게 두 가지가 있습니다.

# 211.40.4.6 으로부터의 라우팅을 차단하는 설정  

# route add –host 211.40.4.6 reject

# iptables –A INPUT –s 211.40.4.6 –j DROP

참고로 TCP SYN Flooding 공격의 경우 SYN 패킷만 대량으로 발송할 뿐

ESTABLISHED 상태가 되지 않으므로TCP SYN Flooding 공격과는 무관합니다.

(2)        include 를 잘못하여 무한 루프가 돌 경우

    요즘에는 php 와 mysql 을 연동하여 많이 사용하고 있는데, 프로그래밍 과정에서의

실수로 php 파일에서 같은 php 파일을 include 하는 경우가 있습니다.

이러한 경우에는 무한 루프가 돌게 되어 결국은 아파치 데몬이 금새 Maxclients 에

차버리게 되는데, 어떤 파일에서 무한 루프가 돌고 있는지 찾기가 힘듭니다.

    임시로 아래와 같이 include 를 하지 못하도록 차단을 하는 방법이 있습니다.

# iptables -A INPUT -p tcp -i lo -s 211.100.2.3 –sport 1024:65535 -j DROP

또는 ps aux | grep http 로 보이는 프로세스에서 ls –la /proc/pid 로 각각의 http

프로세스가 어떤 파일을 참조하고 있는지 일일이 추적하는 방법도 있습니다.

(예:cwd -> /home/user1/public_html/infinite_loop/)

정상적인 접속의 경우에는 아래와 같이 대처합니다.

(1)        KeepAlive 옵션 변경

기본으로 설정되어 있는 KeepAlive On 을 KeepAlive Off 로 변경후 아파치를

재시작합니다. KeepAlive 를 Off 로 설정시 다소 접속 속도는 떨어지지만 좀

더 많은 동시접속을 수용할 수 있습니다. KeepAlive 를 On으로 그대로 사용

할 경우에는 15초로 설정된 Timeout 을 5초 정도로 낮게 설정하는 방법도 있

습니다.

(2) 아파치의 MaxClients 조절

MaxClients 를 512나 1024 와 같이 적절히 변경합니다. 그러나 이 값을 변경하기

위해서는 아파치의 소스를 수정후 재컴파일하여야 하므로 아파치의 소스 디렉토리에

있는src/include/httpd.h 파일에서 HARD_SERVER_LIMIT 256 로 설정된 값을 1024로

변경후 재컴파일하면 됩니다.

만약 커널 2.2.X 일 경우에는 /usr/src/linux/include/linux/tasks.h 에서 NR_TASKS

와 MAX_TASKS_PER_USER 변수 역시 수정하여야 하며, 2.4.X 의 경우에는 커널제한이

없으므로 아파치만 재컴파일 하시면 됩니다.

(3) 추가 아파치 데몬 설정

만약 특정 사이트나 어떠한 사이트내 특정 컨텐츠의 접속이 많아 그러하다면 이 부분을

별도로 데몬을 띄워 서비스하는 방법도 있습니다. 이를테면 한 사이트에서 게시판의

접속이 매우 많다면 기존의 80번 포트외에 8080과 같은 임의의 포트로 작동하는 웹

데몬을 추가로 띄워 이 포트를 통해 접속이 많은 서비스를 담당하게 하는 것이지요.

이를 위해서는 기존의 httpd.conf 파일을 httpd8080.conf 와 같이 설정 파일을 복사 후

아래와 같이 변경합니다.

port 80 à port 8080

User nobody  à User  www

Group nobody  à Group  www

그리고 httpd  –f  /usr/local/apache/conf/httpd8080.conf 로 8080포트로 작동하는

웹서버 데몬을 시작하면 됩니다. 물론 이때 www 라는 계정은 서버에 생성되어

있어야 하며 Nobody 가 아닌 www 라는별도의 계정으로 데몬을 작동하는 이유는

한 유저(nobody) 가 생성할 수 있는 프로세스의 한계가 있기 때문이며 커널 2.4.X

에서는 이 제한이 없으므로 Nobody 로 작동해도 관계 없습니다.

또는 기존의 웹데몬인 httpd 와 파일이름을 서로 다르게

하여 관리를 하기 위해 httpd 대신 httpd8080 등 다른 이름으로 변경하여

실행하셔도 좋습니다.

웹접속은 http://domain.com:8080/ 으로 하면 되며 이러한 방식으로

8081, 8082, 8083….등의 여러 포트를 띄울 수 있습니다.

문) 아파치 데몬은 떠 있는데, 접속이 되지 않습니다. 원인이 뭘까요?

답) 최근 유행하는 TCP SYN Flooding 공격일 가능성이 있습니다.

netstat –na | grep SYN 으로 확인시 많은 프로세스가 보인다면 이 공격 때문이며

이러한 경우에는

# sysctl –w net.ipv4.tcp_syncookies=1

으로 syncookies 기능을 enable 하시면 됩니다.

  이 공격에 대한 보다 자세한 내용은 본지 7월호에 실린 “TCP SYN Flooding 공격의

원인과 해결책” 을 참고하세요.

문) 웹호스팅을 서비스 하고 있는데, 유저들이 채팅CGI를 돌리고 있어 부하가 많이

걸리고 있습니다. 채팅 CGI 프로그램을 원천적으로 사용할 수 없도록 하는 방법이

없을까요?

답)  채팅의 경우 클라이언트와 계속 통신해야 하는 프로그램의 특성상 시스템의

로드를 많이 차지하게 됩니다.  

httpd.conf 를 열어 아래와 같이 설정하면 파일명에 chat 이라는 단어가 포함된

CGI 파일은 작동하지 않게 됩니다.

이런 방식으로 특정한 파일에 대해 웹접근을 차단할 수 있습니다.

따라서 CGI 파일에 아무리 실행권한을 주었다 하더라도  웹에서 접근하면 Forbidden

에러가 나게 됩니다.

   Order allow,deny

   Deny from all

문) 가끔 메모리를 많이 소모하는 CGI가 작동할 때는 시스템이 매우 불안해 집니다.

아파치에서 각 프로세스가 사용할 수 있는 메모리를 제한할 수 있는 방법이

없을까요?

답) 아파치의 인자(Directive)중에서 RLimitMEM 을 사용하면 됩니다.

이 인자는 아파치 웹서버에서 생성된 특정 프로세스가 작동시 소요 가능한 최대 메모

리의 양을 제한하는 것으로 메모리를 많이 소모하는 CGI 가 작동시 지정된 메모리까

지만 실행이 되고 그 이상 소요시에는 500 Internal Server Error 가 나면서 더 이상 작동

하지 않게 됩니다.

예를 들어 httpd.conf 에

RLimitMEM 20000000 21000000

RLimitMEM 50000000 51000000

와 같이 설정시 모든 디렉토리에는 메모리를 20메가나 최대 21메가까지만 사용이

가능하고 /home/special/public_html/* 디렉토리 이하에 접근시에는 특별히 50M

까지 메모리 이용이 가능하게 됩니다.

이와 비슷한 인자로 CPU 점유율을 제한하는 RLimitCPU 와 프로세스의 개수를 제한

하는  RLimitNPROC 이 있으며 이에 대해서는

http://httpd.apache.org/docs-2.0/mod/core.html 를 참고하시기 바랍니다.

문) 자료실을 운영하고 있는데, 사이즈가 너무 큰 파일을 업로드/다운로드 하는 경우가

있어 부하가 많이 걸립니다. 특정 사이즈 이상의 파일에 대해서는 업로드/다운로드를

하지 못하도록 제한할 수 있는 방법이 없을까요?

답)

가장 좋은 방법은 PHP 등의 자료실 프로그램 자체에서 업로드되는 사이즈를 제한하면

되지만 이 기능이 지원되지 않을 경우에는 아파치 웹서버에서 업로드/다운로드 하는

파일의 사이즈를 제한하는 LimitRequestBody 기능을 이용하시면 됩니다.

httpd.conf 를 열어 아래의 라인을 추가합니다.

LimitRequestBody 7168000

위와 같이 LimitRequestBody  인자를 사용하면 아파치 웹서버를 이용하여

업/다운로드 하는 파일의 사이즈를 7M로 제한하게 됩니다.

따라서 지정된 사이즈를 초과하는 파일을 업로드 시에는 아래와 같은 메시지가 뜨며

업로드되지 않습니다.

Request Entity Too Large

The requested resource

/wwwboard/bbs.cgi

does not allow request data with POST requests, or the amount of data provided in

the request exceeds the capacity limit.

—————————————————————

Apache/1.3.xx Server at tt.co.kr Port 80

문) 다른 사이트에서 제가 운영하는 서버의 데이터를 무단으로 링크하지 못하도록

하고 싶습니다. 차단할 수 있는 방법이 있나요?

답) 여러가지 방법이 있지만 httpd.conf 에 아래와 같이 설정하는 방법이

가장 효과적입니다.

    ServerAdmin webmaster at tt.co.kr

    DocumentRoot /home/tt/public_html

    ServerName tt.co.kr

    ServerAlias www.tt.co.kr

    SetEnvIf Referer tt\\.co\\.kr link_allow

    SetEnvIf Referer www\\.tt\\.co\\.kr link_allow

    SetEnvIf Referer ^$ link_allow

    

위와 같이 설정시 외부에서 mpg, asf, wmv 확장자를 갖는 파일에 대해서는 일체 무단

자료 링크가 불가능하게 되며 error_log 를 보면 아래와 같이 무단으로 링크한 자료의

다운로드가 작동하지 않는 것을 확인할 수 있습니다.

[Tue Sep  4 15:55:44 2001] [error] [client 211.230.82.78]

client denied by server configuration: /home/tt/public_html/data/3-2.wmv

문) 아래와 같이 Windows NT/2000 의 IIS 서버를 공격하는 코드레드웜 때문에

로그 사이즈가 매우 커지고 있습니다.  쓸데 없는 정보가 로그에 남지 않도록 하는

방법이 없을까요?

2001/08/01 23:39:50.765446 152.158.99.4:58781 -> 211.233.38.193:80 [AP]

GET/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

httpd.conf 파일을 열어

CustomLog 윗 줄에

SetEnvIf Request_URI “/default.ida$” cord-red 와 같이 정의한 후  

CustomLog /usr/local/apache/logs/access.log  combined 라고 설정되어 있는 부분을

CustomLog /usr/local/apache/logs//access.log  combined env=!cord-red 라고

수정합니다.! 는 not 의 의미이므로 위 설정은 cord-red로 정의된 요청을 거부하라는

뜻입니다.위와 같이 설정 후 아파치를 재시작하면 코드레드와 관련된 로그가 남지

않게 됩니다. 특히 코드레드의 경우  

iptables –A  INPUT -i eth0 -p tcp –tcp-flags ACK ACK –dport 80 \\

-m string –string ‘/default.ida?’ -j REJECT –reject-with tcp-reset 와 같이

iptables 를 이용하여 차단하는 방법도 있기는 하지만 이 방법은 커널과 iptables

를 다시 컴파일하여야 하는 문제가 있기는 합니다.

문) 기타 아파치 서버와 관련된 장애가 확인 시 처리할 수 있는 방법을

알려주세요.

답) 리눅스가 윈도우계열과 가장 큰 특징중 하나는 로그(log)를 철저히

남긴다는 것입니다. 남겨진 로그 정보를 이용하여 각종 시스템의 장애나

상태를 점검할 수가 있는데,. 아파치 웹서버 역시 마찬가지입니다.

문제나 장애가 발생시에는 반드시 error_log 를 남기게 하여

/usr/local/apache/logs/error_log 의 메시지를 살펴보시면 문제의 원인을

어렵지 않게 찾을 수 있게 될 것입니다.