[root@op root]# ls
ls: unrecognized option `--show-control-chars'
Try `ls --help' for more information.

ls명령을 쳤을때 위와 같은 메세지가 뜨면서 명령어가 먹지 않을때에는
해킹을 의심하셔야 합니다.
위와 같은 경우에는 rootkit에 의한 해킹일 가능성이 가장 큽니다.
rootkit에 의한 해킹을 경우 어디에 백도어 파일이 있는지 찾기 힘들기
때문에 서버의 주요 파일만 백업 받으신 후 새로 설치 하시는게 가장
좋은 방법입니다.

Solaris 에서 기본적 package 인 xntpd 에 포함되어있는 NTP 를 사용하여 date & 시간을 sync 해주는 command 이다.
Solaris 에서는 기본적으로 xntpd 를 사용하므로 /etc/inet/ntp.conf 에있는 conf 파일 수정으로 time sync 를 할수있다.

Linux 에서 ntp 를 사용하려면 ntp 를 down 설치하여 사용할수있다.
Download 싸이트 : http://www.ntp.org/downloads.html

다운받은후 ntpd 를 설정하여도 되며 간단히 ntpdate 를 사용하려한다면 compile 후 ntpdate 를 복사 사용한다.
사용예제 :
ntp 서버의 시간 확인
#ntpdate -q clock.via.net

time 적용 받기
#ntpdate clock.via.net

LSOF는 'List Open File'의 약자이며, 해당 System의 프로세스들에 의해서 열려진 파일들을 확인 하는 tool 이다.
시스템의 프로세스에 대한 확인시 사용된다.

사용예 :

특정 파일의 엑세스하는 프로세스 혹인
# lsof /etc/passwd
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
more 13838 j*** 3r VREG 32,0 1410 18062 /etc/passwd

특정 호스트에 대한 접속 확인
# lsof -i@210.116.*.*
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd2 13715 root 6u inet 0x3000142c3f0 0t596000 TCP inet:22->210.116.*.*:3071 (ESTABLISHED)
sshd2 13826 root 6u inet 0x3000142c2b0 0t14264 TCP inet:22->210.116.*.*:3079 (ESTABLISHED)

특정 유저가 사용하는 프로세스 확인
#lsof -u $userid

특정 프로세스가 오픈하는 파일 확인
#lsof -p $pid

html, cgi, text 들을 unix 서버로 upload 했을때 ^M character 가 line 의 끝에 붙어서 script 등의 실행에 문제가 될때가 있다.
이것을 삭제 하려면 tr command 나 vi 를 사용하여 지워주면 된다.

tr command 사용하기
#more index.htm |tr -d '^M' > index2.htm

vi 에서 command 사용려면 아래와 같이 type 한다.
:0,$s/^M//g

주의 : ^M 은 Ctrl v + Ctrl m 임.

코드레드와 Nimda 등 Windows NT/2000 기반의 IIS 를 공격하는 무차별적인 웜공격으로 인하여 부하가 유발되고 로그 파일이 불필요한 데이터로 채워지는 경우가 있다.
로그 파일의 크기가 커지는 것은 둘째치고서라도 당장 계속적으로 커지는 로그 파일 때문에 서버에 부하를 유발하는 것이 더욱 큰 문제이다. 서버에서 로그를 남기는 방식은 매번 클라이언트의 요청이 있을 때마다 웹 서버에서 패킷 헤더에 있는 클라이언트의 정보를 받아낸 후 로그 파일을 open 한 후 로그 파일을 읽어 파일의 제일 끝으로 이동하여 로그 정보를 추가한 후 파일을 close 하는 것인데, 불 필요한 요청이 있을 때마다 이 작업을 계속하여야 하므로 서버에 부하를 유발함은 당연한 현상이다. 따라서 아예 로그를 남기지 않도록 하거나 로그를 남긴다 하더라도 불필요한 정보를 남기지 않도록 하는 것이 미소하게나마 서버의 성능을 높이는 것이 될 것이다. 그럼 실제로 불필요한 정보는 아예 로그를 남기지 않는 방법에 대해 알아보도록 하자.
이를테면 코드레드의 경우 아래와 같이 무차별적인 로그가 남게 되는데
2001/08/01 23:39:50.765446 152.158.99.4:58781 -> 211.233.38.193:80 [AP]
GET/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

이러한 로그를 막기 위해서는 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로 정의된 요청을 거부하라는 뜻이다.
위와 같이 설정 후 아파치를 재시작하면 코드 레드와 관련된 로그가 남지 않게 된다. 코드레드에 이은 Nimda 웜의 경우도 같은 방식으로 설정하여 로그에 남지 않도록 설정할 수 있다.
또한 같은 원리를 이용하여 iptables 를 이용하여 아예 패킷 자체를 차단할 수도 있는데, 코드 레드의 경우 default.ida 문자열을 요청한다는 특징을 이용하여
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 의 –strings 를 이용하여 특정 문자열이 포함된 패킷을 차단하는 방법도 있기는 하지만 이 방법은 커널과 iptables 를 다시 컴파일 하여야 하는 문제가 있다. Nimda Worm 역시 이외 cmd.exe 와 root.exe 를 포함하므로 같은 방식으로
iptables -A INPUT -p tcp --tcp-flags ACK ACK --dport 80 -m string --string "cmd.exe" -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp --tcp-flags ACK ACK --dport 80 -m string --string "root.exe?" -j REJECT --reject-with tcp-reset 와 같이 차단할 수 있다

아파치 서버를 시작시 자주 만나는 에러와 관련된 설정 중 하나가 바로 아래와 같은ServerName 이다.

# /usr/local/apache/bin/apachectl start
httpd: cannot determine local host name.
Use the ServerName directive to set it manually.
./apachectl startl: httpd could not be started

대부분 ServerName 은 리눅스 설치시 입력한 호스트 이름을 자동으로 가지고 와 설정되나 DNS상에 존재하지 않은 도메인명이나 설사 존재하더라도 로컬 서버가 아닌 잘못된 도메인을 정의시 이러한 현상이 나타난다. 이러한 경우에는 ServerName 을 실제 로컬 서버의 호스트 이름이나 IP 주소로 설정해 주어야 한다.
또한 ServerName 을 잘못 설정시 나타날 수 있는 현상중 하나가 http://domain.com/~user 와 같이 접속할 때의 문제이다. 즉, 서버내 계정 사용자의 홈페이지를 접속시 http://domain.com/~user/ 와 같이 접속하면 접속이 되나 http://domain.com/~user 와 같이 / 를 붙이지 않으면 접속이 되지 않는 경우이다.
클라이언트가 서버의 디렉토리에 접속시 끝에 / (trailing) 을 하지 않은 경우 서버는 클라이언트에게 / 을 붙여 다시 접속을 하라고 요청한다. 그렇지 않으면 상대 URL 경로를 인식하지 못하는 문제가 있기 떄문이다. 만약 DNS 가 정상적으로 세팅되어 작동하고 있을 경우에는 문제가 없지만 그렇지 않은 경우에는 접속이 되지 않는 경우가 생긴다. 또는 위에서처럼 ServerName 에 지정된 호스트네임이 실제로 DNS 상에 리졸빙이 되지 않는 경우도 이러한 현상이 나타나므로 이러한 경우에는 httpd.conf 의 ServerName 옵션에 실제 서비스중인 도메인명으로 입력해 주면 된다

가끔 서버를 운영하다보면 특정한 디렉토리 이하에 대해서는 인증된 유저만 접속이 가능하게 한다거나 특정 IP 대역의 유저만 접근하도록 하고자 할 필요가 있을 때가 있다. 특정 디렉토리 이하에 대해서 접근을 제어하고자 할 때에는 .htaccess 를 사용하거나 httpd.conf 에서 를 이용하여 제어를 할 수 있지만, 만약 특정한 파일에 대해서 외부에서의 접근을 제한하고자 한다면 어떻게 하여야 할까?
이때에는 Location 을 사용하면 된다. httpd.conf 파일에 아래와 같이 설정시 모든 디렉토리 이하의 secret.html 파일에 대해서는 192.168.1.1 에서만 접근이 가능하게 된다.


order deny,allow
deny from all
allow from 192.168.1.1


만약 여러 도메인이 설치되어 있는 호스팅 서버의 경우 secret.tt.co.kr 도메인내 secret.html 에 대해서만 접근을 제어하고자 할 경우에는 아래와 같이 VirtualHost 설정에서 하면 된다.


ServerAdmin anti@domain.co.kr
DocumentRoot /usr/local/apache/htdocs/secret/
ServerName secret.tt.co.kr

order deny,allow
deny from all
allow from 192.168.1.1



또는 위와 같이 IP 가 아니라 특정한 ID/PW를 입력한 유저에 대해서만 특정 파일에 대하여 접근을 허용하고자 할 때가 있다. 이러한 경우에는 httpd.conf 에 아래와 같이 설정하면 된다.


ServerAdmin anti@domain.co.kr
DocumentRoot /usr/local/apache/htdocs/secret/
ServerName secret.tt.co.kr

AuthName "ID/PW 를 입력하세요."
AuthType Basic
AuthUserFile /usr/local/apache/htdocs/.htpasswd
Require valid-user



그리고 htpasswd –c .htpasswd id 로 .htpasswd 파일에 ID/PW를 생성하여 secret.html 에 접근시 ID/PW 를 정확히 입력한 유저에 대해서만 접근이 가능하게 된다.

리눅스 서버를 운영하다 보면 ftp 접속 정보 를 알고 싶을때가 있습니다.
root 계정 으로 접속한후 ftpcount 명령어는 단순한 접속자수 를

# ftpcount
Master proftpd process 1423:
Service class - 3 users

ftpwho 명령어는 접속자 ID ,IP 등을 알수 있습니다.

# ftpwho
Master proftpd process 1423:
7977 0m17s proftpd: nabomi - 203.231.223.22: IDLE
8016 0m15s proftpd: www - 203.231.223.23: IDLE
8018 0m4s proftpd: www - 203.231.223.24: IDLE
Service class - 3 users

사용형식 : last [-R] [-num] [ -n num ] [-adiox] [ -f file ] [ -t YYYYMMDDHHMMSS ] [name...] [tty...]

# last <모든 계정들의 접속정보>
# last root <해당 계정의 접속정보>
# last -d <외부에서 접속한 정보, reboot에 관한 정보>
# lastlog -u root <해당 계정의 최근접속정보>

커널 패닉은 매우 많은 경우에 발생할 수 있습니다.
시스템의 과부하로 인한 문제일 수도 있고 CPU 나 메모리등 하드웨어의 불량으로 발생
할 수도 있습니다. 따라서 커널 패닉이 발생할 경우에는 콘솔이나 로그 파일에 패닉
에 대한 메시지가 남으므로 로그메시지를 근거로 아래의 사이트를 참고하여 커널 패
닉의 이유를 찾아 보시기 바랍니다.(이를 위해서는 일정정도의 C 언어의 해석 능력이
있어야 합니다.)
http://linux.fh-heilbronn.de/doku/Linux/linux-2.4.7/R/panic.htmlz
예를 들어 설명하면 필자가 운영하는 한 시스템의(커널 2.4.7) 경우
[root@www log]# cat messages|grep panic
Jul 22 14:57:45 www kernel: Kernel panic: CPU context corrupt
Jul 25 19:25:30 www kernel: Kernel panic: CPU context corrupt
와 같이 2-3 일에 한번씩 "CPU context corrupt" 라는 메시지를 내면서 커널 패닉이 발
생한 적이 있었는데, 이는 하드웨어와 관련하여 주로 다음과 같은 경우에 발생한다고
알려져 있습니다.
(1) CPU 를 overclocking 하였다.
(2) CPU 가 불량이다.
(3) 전압이 문제가 있거나 전원상태가 좋지 않다.
(4) 주위 온도가 높다.
커널 패닉의 구체적인 원인과 대처법에 대해서는 아래에서 설명할 커널 메일링 리스트
(http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html ) 에서 검색하면
도움을 받으실 수 있습니다.

아파치를 설치 후 시작하려고 하면 다음 메세지가 발생 됩니다
Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
/usr/local/apache/bin/apachectl start: httpd started

인증된 도메인명을 찾을 수 없기 때문에 위와 같은 메세지가 나옵니다.
아파치 설정 파일에 보면 ServerName 부분이 있습니다. 이 부분에 알맞은 주소를 적어주시면 됩니다.
그외엔 도메인명을 받아 설정을 하셔서 해결하실 수 있습니다..

하지만 그와 같은 에러 메세지가 떠도 아무 문제는 없습니다.

[root@op cron.d]# ps -ef| grep cron
root 571 1 0 Oct18 ? 00:00:00 crond
root 9674 9624 1 10:29 pts/0 00:00:00 grep cron

위에서 보시면 cron을 실행시키는 유저는 root입니다..
하지만 일반 사용자로도 가능합니다.

단지 제한을 할려면 /etc/cron.d/cron.deny라는 file에 사용자계정을 추가해서 사용제한 할 수 있습니다.
이건 default로 존재합니다.

그리고 /etc/cron.d/cron.allow라는 file은 허용 가능한 계정을 추가해주는건데요.
default로는 안만들어져있고 따로 만들어주게 됩니다.

아래의 내용은 보안상의 중요한 위험요소이며 특별한 경우가 아닐시 서버구축시 아래와 같은
체크사항을 적용하는것을 권장합니다.

1) /boot 퍼미션 조정 (700)
2) /usr/bin 의 불필요한 퍼미션 제거
3) /etc/services 의 불필요한 서비스 제거
4) 서버관리자용 sshd 데몬 로딩, SecureCRT 사용
5) /etc/skel 의 불필요한 hidden 화일들 제거
6) /usr/bin/X11 이하의 사용하지 않는 X-windows 실행화일들 및 기타 화일들 제거
7) 사용하지 않는 데몬들 제거
8) /var/named 이하 db 화일들의 내용중 NS 탭의 설정이 서로 다른 서버로 설정된것 들 다수
9) /etc/group 그룹설정에 사용하지 않는 그룹(대부분) 제거
10) /etc/passwd 화일에서 있어서는 안되는 유저(lp,news 등등)들 다수 존재
11) ipchains 를 이용한 81번 이상의 포트 접근 막음
12) /home/ftp 계정 제거 (Anonymous 계정용임)
13) /root /.rhosts 화일을 touch 명령으로 생성 후 퍼미션 000 부여
14) /etc/hosts.equiv 를 touch 명령으로 생성후 퍼미션 000 부여
15) 화일중 원격접속에 사용되는 r 또는 .r 로 시작되는 화일의 퍼미션 700 부여 (특히 rlogin, rsh, rsync등)
16) portsentry 를 설치하여 Stealth Scan에 대비
17) sz, rz 명령화일 제거
18) man 명령어의 SUID 제거
19) /usr/home 폴더 및 하위 화일 확인 후 제거
20) /usr/games 폴더 제거
21) /usr/local 하위폴더의 소스화일 (Apache, PHP) 제거

sendmail 에서 Relay 기능을 막아 두었다 하더라도 최근 버전에는 사용자 인증(SMTP AUTH) 기능이 있어 서버에 계정이 있으면 모든 유저가 메일 서버를 이용해 SMTP 기능을 이용하여 메일을 발송할 수 있다. 이를 막으려면 최신의 8.11.4 나 8.11.5 와 같이 최신 버전으로 업그레이드 후 /etc/mail/smtpauth 파일에 보내는 메일 기능을 허용할 유저를 입력해 주면 된다. (최근에 8.11.6 이전 버전에 심각한 보안 문제가 확인되었으므로 반드시 8.11.6 버전이나 8.12 버전으로 업그레이드하여야 한다.) 파일을 생성 후 아무런 유저도 입력하지 않으면 서버에 계정이 있다 하더라도 어느 누구도 메일을 발송할 수 없게 된다. 따라서 최신의 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) 패킷에 대해서만 필터링을 하였으므로 외부에서 오는 메일을 받는 것은 관계 없다.

아웃룩 익스프레스에서 “배달” 을 눌러 메일을 수신하려고 할 때 메일이 받아지지 않는 경우가 있다. 이러한 경우에는 아래와 같이 여러가지 이유가 있을 수 있으니 아래의 사항에 대해 하나씩 원인을 찾아보기 바란다.
(1) IMAP 패키지가 설치되지 않았을 경우
서버에 배달되어 있는 자신의 계정으로 온 메일을 클라이언트 PC에서 받으려면 pop3 데몬이 반응하게 된다. pop3d 는 IMAP 패키지안에 포함되어 있으므로, IMAP 패키지를 설치하여야 pop3 를 사용할 수 있다. Rpm 으로 설치했다면 rpm –q imap 으로 현재 시스템에 imap 패키지가 설치되어 있는지 확인한다. 또는 /usr/sbin/ipop3d 파일이 있는지 확인해 본다.
(2) Inetd 에 설정되어 있지 않을 경우
pop3d 는 inetd 또는 Xinetd 에서 작동하게 된다.
/etc/inetd.conf 또는 /etc/xinetd.conf 파일을 살펴보아 ipop3 가 주석처리 되어 있거나 pop3 가 disable = yes 로 되어 있지는 않은지 확인한다.
(3) TCP Wrapper 에 설정되었는지 여부 확인
/etc./hosts.deny 에 pop3d 접근이 차단되지는 않았는지 확인한다.
(4) 계정에 Lock 이 걸리지 않았는지 확인
메일을 받는 과정에서 갑자기 회선이 끊기거나 PC가 다운되는 등 비정상적으로 종료시 서버의 pop3d 프로세스가 죽지 않고 계속 남아 있는 경우가 있다.
이러한 경우 계정에 “Lock 이 걸렸다” 라고 하며 이러한 경우에는 해당 프로세스를 찾아 kill 을 하면 된다. 만약 계정에 Lock 이 걸린 상태에서 아웃룩 익스프레스에서 메일을 수신하려고 하면 아래와 같은 에러가 나게 된다.
“메일 서버에 로그온하는 데 문제가 있습니다. 지정한 암호가 거부되었습니다.
계정: 'dolmuri', 서버: 'dolmuri.pe.kr', 프로토콜: POP3, 서버 응답:
'-ERR Can't get lock. Mailbox in use', 포트: 110, 보안(SSL): 아니오,
서버 오류: 0x800CCC90, 오류 번호: 0x800CCC92”

(5) Pop3 접속이 많은 경우
Pop3d 가 서비스되는 inetd는 기본적으로 60초동안 40회의 접속을 받아들이
도록 (즉, maximum 40회 fork되도록) 설정되어 있다. 따라서 짧은 시간에 pop3d
요구가 많을 경우에는 메일로그에 pop3/tcp server failing (looping) 라는 메시지가
나면서 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 mail.nuri.net 110 # 110번으로 직접 확인
Trying 210.116.105.100...
Connected to mail.nuri.net.
Escape character is '^]'.
+OK The Inet Hosting POP at idial-pop2.nuri.net starting.
user aaaaa # aaaaa 라는 계정으로 접속
+OK Password required for dolmuri.
pass krw # aaaaa 의 암호 krw 입력
+OK aaaaa has 31 visible messages (0 hidden) in 257562 octets.
quit
+OK Pop server at idial-pop2.nuri.net signing off.
Connection closed by foreign host..

위의 경우는 정상적인 경우이며 에러가 있을 경우(만약 암호가 다르게 설정되었을 경우 -ERR Bad login 와 같은 메시지가 나게 된다.) 각각의 경우에 따라 에러 메시지를
각각 확인할 수 있다.

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@kebi.net
f775ieF24893 521898 Tue Aug 7 14:44
(Deferred: Connection timed out with mail.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
(Deferred: Connection timed out with hanmail.com)
cuwww23@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 를 이용해 일정 시간마다 발송되고 수신되는 메일의 개수를 통계로 내어 그래프로 볼 수 있다.

시스템의 제한 설정과 서비스의 안정성은 매우 깊은 연관성을 가지고 있다. 기본적으로 대부분의 서비스는 유저가 사용 가능한 시스템의 자원 제한이 거의 설정되어 있지 않은데, 메일 서비스도 마찬가지이다.
최근에는 메일의 이용율이 높아지고, 메일의 컨텐츠도 전통적인 텍스트 방식에서 음성,이
미지등 각종 동영상이 주종을 이루면서 용량도 점점 커지고 있다. 물론 그만큼 하드웨어나
메일 서버의 소프트웨어적인 성능도 향상되고 있지만 용량이 큰 메일을 주고 받는다면
당연히 시스템의 부하가 올라가기 마련이고 이로 인하여 같은 서버내 다른 서비스에까지
영향을 미치게 된다. 따라서 시스탬에서 보내는 메일 서비스(SMTP)나 받는 메일 서비
스(POP3)를 제공하고 있다면 용량이 큰 파일을 주고 받는 것을 적절히 제한할 필요가 있다.

sendmail 은 로컬의 메일을 외부로 발송하는 SMTP(보내는 메일서버) 기능도 있지만 외부에서 서버내 계정으로 전송되는 메일을 받아서 서버에 저장하는 기능도 있다. 이때 기본적으로는 보내거나 받는 메일의 양에 대한 제한이 전혀 없어 10메가 이상이 넘는 큰 사이즈의 메일이 송 수신 될 경우 서버에 과부하가 걸릴 수 있으므로 아래와 같이 각각의 설정(보내는 메일과 받는 메일의 양) 을 적절히 제한하여 설정하는 것이 좋다.

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

/etc/mail/sendmail.cf (또는 /etc/sendmail.cf. 이는 sendmail 의 패키징 방법에 따라 다르다.) 파일에서 다음과 같이 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 ... Message is too large; 5024000 bytes max
554 5.0.0 ... Service unavailable
와 같은 에러 메시지를 회신받게 된다.

아울러
# maximum number of recipients per SMTP envelope
O MaxRecipientsPerMessage=20

와 같은 부분이 있는데, 이 부분은 한번에 메일 발송 시 동시 발송(참조 발송)이 가능한 메일 계정의 수를 뜻하는 것으로 SMTP 서비스를 제공한다면 이 설정을 적용하는 것이 좋다. 기본적으로 이 값에도 제한이 없으므로 먼저 주석을 삭제한 후 적절한 값을 설정해 주면 한번에 동시 발송 가능한 메일의 수도 제한할 수 있다.
(위의 경우에는 한번에 참조 발송이 가능한 메일 유저를 20명으로 제한)
설정이 끝난 후에는 killall –HUP sendmail 로 sendmail 을 재가동해주면 적용된다.

가끔 접속자가 많은 서버를 운영하다 보면 갑자기 웹 접속이 되지 않거나 접속이 너무 느려 아파치 데몬 개수를 확인해 보면 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 이상) 를 이용한 방법 이렇게 두 가지가 있다.

예) 공격지 IP 인 211.40.4.6 으로부터의 라우팅을 차단하는 설정
# route add –host 211.40.4.6 reject
# iptables –A INPUT –s 211.40.4.6 –j DROP
실제 적용되었는지 확인하는 방법은 각각 route –n 과 iptables –L –n 이다.
참고로 TCP SYN Flooding 공격의 경우 SYN 패킷만 대량으로 발송할 뿐 ESTABLISHED 상태가 되지 않으므로TCP SYN Flooding 공격과는 무관하다.

(2) include 를 잘못하여 무한 루프가 돌 경우
요즘에는 php 와 mysql 을 연동하여 많이 사용하고 있는데, 프로그래밍 과정에서의 실수로 php 파일에서 같은 php 파일을 include 하는 경우가 있다. 또는 a.php 파일에서 b.php 파일을 include 하고 b.php 파일에서 다시 a.php 파일을 include 하는 경우도 그러한 경우일 것이다. 이러한 경우에는 무한 루프가 돌게 되어 결국은 아파치 데몬이 금새 Maxclients 에서 지정한 개수로 차 버리게 되는데, 어떤 파일에서 무한 루프가 돌고 있는지 찾기가 힘들다.
따라서 임시로 아래와 같이 include 를 하지 못하도록 차단을 하는 방법이 있다.

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

이는 같이 서버내에서 include 시에는 lo (Lookback Interface) 를 통해 sport 가 1024 이후의 high port 를 이용하여 통신한다는 특성을 이용한 것이다. 그러나 이 설정을 하였을 경우 로컬 서버에서 클라이언트 포트를 전혀 사용할 수 없게 되므로 다른 서비스에도 장애가 되기 때문에 임시로만 사용하기 바란다.
또는 ps aux | grep http 로 보이는 프로세스에서 ls –la /proc/pid/ 로 각각의 http 프로세스가 어떤 파일을 참조하고 있는지 일일이 추적하는 방법도 있다.
(예:cwd -> /home/user1/public_html/infinite_loop/)

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

(1) KeepAlive 옵션 변경
기본값으로 설정되어 있는 KeepAlive On 을 KeepAlive Off 로 변경 후 아파치를 재시작한다. KeepAlive 는 HTTP 1.1 규약에서부터 적용된 것으로 접속 속도에 큰 영향을 준다. KeepAlive 를 Off 로 설정시 다소 접속 속도는 떨어지지만 좀 더 많은 동시 접속을 수용할 수 있다. 따라서 MaxClients 에 도달할 정도로 동시 접속자가 많은 경우에는 KeepAlive 를 Off 로 설정하는 것이 다소 임시 방편이기는 하지만 해결 방법이 될 것이다.
KeepAlive 설정에 대해서는 Hit의 개념과 관련 지어 이해하면 된다. 예를 들어 10개의 이미지 파일을 링크한 HTML 페이지를 로딩시 웹브라우저는 이 HTML 파일을 다운로드하여 클라이언트에서 파싱(parsing) 을 하면서 이미지 파일등이 링크되어 있을 경우 서버에 접속하여 이미지 파일을 요청하는데, KeepAlive 가 On 일 경우에는 한 번 맺은 TCP 연결에 대해 같은 Client IP 에서 접속이 있을 것이라 가정하고 기존의 프로세스가 대기하고 있다가 이후의 접속을 처리하기 때문에 다시 접속을 맺는 절차가 필요 없이 빨리 서비스가 가능하지만, KeepAlive 가 Off 인 경우에는 이미지 파일을 불러올 때마다 매번 세션을 새로 맺고 끊는 과정을 반복하여야 하기 때문에 속도가 느려질 수 밖에 없다. 아파치 홈페이지의 문서에 의하면 많은 이미지 파일이 있는 HTML 문서를 로딩시 KeepAlive 설정에 따라 최고 50%까지 속도 차이가 날 수 있다고 한다. 그렇다고 해서 모든 사이트에서 KeepAlive 를 On 으로 하는 것이 좋은 것이 아니다. 순간적인 동시 접속자는 많지만 한 두 번 검색 후 검색 결과의 링크를 따라 다른 사이트로 빠져 나가는 검색 엔진의 경우에는 KeepAlive 를 Off 로 하는 것이 유리할 것이다. KeepAlive 를 On으로 설정하여 그대로 사용할 경우에는 15초로 설정된 KeepAlive Timeout 을 15초에서 5초 정도로 낮게 설정하는 방법도 있으며 이 값은 자신의 시스템 환경에 맞게 적절히 설정하기 바란다.

(2) 아파치의 MaxClients 조절
기본적으로는 256으로 설정되어 있는 MaxClients 의 한계를 512나 1024 와 같이 적절히 변경한다. 그러나 이 값을 변경하기 위해서는 아파치의 소스를 수정 후 다시 컴파일 하여야 하므로 아파치의 소스 디렉토리에 있는src/include/httpd.h 파일에서 HARD_SERVER_LIMIT 256 로 설정된 값을 512 나 1024로 변경 후 아파치를 재컴파일 하면 된다. 만약 커널 2.2.X 일 경우에는 /usr/src/linux/include/linux/tasks.h 에서 NR_TASKS 와 MAX_TASKS_PER_USER 변수 역시 수정한 후 커널을 재컴파일 해 주어야 하며, 2.4.X 의 경우에는 관련된 커널 제한이 없어졌으므로 아파치만 재컴파일 하면 된다.
그러나 대부분의 사이트에서는 256정도로 설정되어도 충분히 서비스가 가능하므로 무작정 이 값을 크게 늘려 메모리를 낭비할 필요가 없으니 특별한 경우가 아니라면 이 값을 늘리지 않는 것이 좋다.

(3) 추가 아파치 데몬 설정
만약 여러 도메인중 특정 도메인이나 어떠한 사이트내 특정 컨텐츠의 접속이 특별히 많아 같은 서버에 있는 다른 사이트에까지 피해를 주고 있다면 이 부분을 별도로 데몬을 띄워 서비스하는 방법도 있다. 이를테면 한 사이트에서 게시판의 접속이 매우 많다면 기존의 80번 포트외에 8080과 같은 임의의 포트로 작동하는 웹 데몬을 추가로 띄워 이 포트를 통해 접속이 많은 서비스를 담당하게 하는 것이다. 이를 위해서는 기존의 httpd.conf 파일을 httpd8080.conf 와 같이 설정 파일을 복사 후 httpd8080.conf 파일을 아래와 같이 변경하면 된다.

port 80 à port 8080
User nobody à User www
Group nobody à Group www

그리고 /usr/local/apache/bin/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….등의 여러 포트를 띄울 수 있다. 실제로 얼마 전 필자가 운영하는 호스팅 서버에서 특정 사이트의 게시판의 접속이 폭주하여 모든 웹 접속이 느려진 적이 있었는데, 위와 같이 게시판 부분만 따로 떼어 8080 포트로 분리하여 서비스를 하여 문제를 해결한 적도 있다.

누구나 업로드나 다운로드가 가능한 자료실을 운영하고 있을 경우 사이즈가 너무 큰 파일을 업로드 또는 다운로드 할 경우 부하가 많이 걸리게 되어 결국 시스템의 성능 저하를 유발하게 된다. 최근 배포되는 게시판/자료실 프로그램에서는 대부분 업로드 할 수 있는 용량등을 제한할 수 있는 기능이 있지만 그렇지 않은 프로그램도 상당수 있어 웹 서버 차원에서 이 제한을 적절히 설정할 필요가 있다. 아파치에서는 이와 관련하여 웹 서버에서 업로드/다운로드 할 수 있는 파일의 사이즈를 제한하는 LimitRequestBody 기능을 이용할 수 있다.
LimitRequestBody 는 클라이언트가 요청시 http 프로토콜을 통해 서버가 제공할 수 있는 메시지의 크기를 byte 단위로 정의하는 것으로 무한대를 의미하는 0부터 2,147,483,647(2Giga) 까지 설정 가능하며 이 설정으로 대용량의 파일을 업/다운로드 하는 형태의 서비스 거부 공격을 차단할 수 있다. 이를 설정하는 방법은
httpd.conf 를 열어 아래의 라인을 추가하면 된다.


LimitRequestBody 7168000


LimitRequestBody 10240000


위와 같이 LimitRequestBody 인자를 설정하면 아파치 웹서버를 이용하여 업/다운로드 하는 모든 파일의 사이즈를 7M로 제한하고 /home/special/ 이하에 대해서는 10M로 제한하게 된다.

최근에는 대부분의 사이트들이 대화방(채팅)을 위해 자바로 프로그래밍된 자바 대화방을 사용하는 추세이지만 얼마전 까지만 하더라도 C 나 Perl 로 된 CGI 대화방을 설치하여 사용하는 것이 유행이었다. 그런데, 이 대화방의 경우 대화방에 참여하는 유저 중 한 명이 글을 입력할 경우 모든 유저에게 이 내용이 실시간으로 뿌려 주어야 하는 특성상 시스템의 메모리를 매우 많이 소모하는 대표적인 프로그램중 하나였다. 따라서 채팅 CGI 프로그램을 원천적으로 사용할 수 없도록 하는 방법을 고민하게 되었는데, 해결 방법은 대부분의 채팅 프로그램이 xxxchat.cgi 또는 chatxxx.cgi 라는 파일을 실행 파일 이름으로 한다는 특징을 이용하면 된다.
즉, httpd.conf 를 열어 아래와 같이 설정하면 파일명에 chat 이라는 단어가 포함된 CGI 파일은 작동하지 않게 되는 것이다.

Order allow,deny
Deny from all


이러한 방식으로 특정한 파일에 대해 웹에서의 접근을 차단할 수 있다. 따라서 CGI 파일에 아무리 소유권과 실행 권한을 주었다 하더라도 웹서버 자체에서 접근을 거부하였으므로 웹에서 접근하면 Forbidden 에러가 나게 된다. 이러한 식으로 특정 파일 이름을 가진 파일의 실행이나 접근을 차단할 수 있다