RSS구독하기:SUBSCRIBE TO RSS FEED
즐겨찾기추가:ADD FAVORITE
글쓰기:POST
관리자:ADMINISTRATOR
출처 카페 > 운영체제 공부 / 쩡희
원본 http://cafe.naver.com/jeonghee1004/21
제 목 : 아파치에서 phpBB웜 차단 및 별도 로그 저장
글쓴이 : 좋은진호(truefeel, http://coffeenix.net/ )
글쓴일 : 2005.2.16(수)

phpBB 2.0.11 이전 버전의 보안문제를 이용한 phpBB Worm(Santy 웜 등)의 공격이 여전히
많이 시도되고 있다. phpBB를 최신 버전으로 업하는 것은 당연한 것이지만 지속적인 공격
으로 시스템 로드를 잡아먹고 짜증나는 로그를 해결할 방법이 필요했다.

1. phpBB 웜 공격 로그

access log에는 다음과 같은 형태의 로그가 남는다. (한줄로)

--------------------------------------------------------------------
65.77.xxx.xx - - [30/Dec/2004:19:58:01 +0900] "GET /...경로.../viewtopic.php?
p=1303&highlight=%2527%252Esystem(chr(112)%252Echr(101)%252Echr(114)%252Echr(108)
%252Echr(32)%252Echr(45)%252Echr(101)%252Echr(32)%252Echr(34)%252Echr(112)%252
Echr(114)%252Echr(105)%252Echr(110)%252Echr(116)%252Echr(32)%252Echr(113)%252
Echr(40)%252Echr(106)%252Echr(83)%252Echr(86)%252Echr(111)%252Echr(119)%252
Echr(77)%252Echr(115)%252Echr(100)%252Echr(41)%252Echr(34))%252E%2527
HTTP/1.0" 302 712 "-" "Mozilla/4.0"
--------------------------------------------------------------------

highlight= 변수로 넘어온 값을 phpBB의 viewtopic.php에서 urldecode()함수를 통해 보안상의
문제를 열어두고 있는데 이를 악용한 것이다.
웜의 다른 특징은 Agent가 "Mozilla/4.0"이라는 것이다. 단지 이 user agent인 경우를 차단
면 정상적인 사용자의 접속을 차단하는 경우도 생길 수 있으므로 여기서는 URL을 통한 방법을
사용할 것이다.

2. 웜 차단과 로그는 별도 저장

웜도 차단하면서 동시에 웹로그는 별도로 저장하는 httpd.conf 아파치 설정을 알아보자.

--------------------------------------------------------------------
RewriteEngine On

RewriteCond %{QUERY_STRING} ^[a-z]{1}=(.*)highlight=\%2527\%252E
RewriteRule ^.*$ http://127.0.0.1/ [R,L,E=phpbb:1]

CustomLog logs/phpbb_worm_log common env=phpbb
--------------------------------------------------------------------

아파치에서는 URL Rewriting 설정을 통해 특정 URL로 요청된 것을 내부의 다른 페이지로
넘길 수도 있고 전혀 다른 사이트의 페이지로 보낼 수도 있다. 또한 조건에 맞는 URL이면
이를 아파치 내의 변수값으로 지정도 가능하다.
아파치의 Rewriting rule에 대한 자세한 글은 Apache 홈페이지의 "URL Rewriting Guide"
를 읽어보기 바라고, 설정에 대해 한줄씩 알아보기로 하자.

첫번째줄은 URL rewriting의 시작을 알린다.

두번째줄은 조건문이다. URI(쿼리)중에 위와 같은 URL이 형태인 경우인지를 비교하게된다.
즉, 로그의 첫부분인 다음과 같은 부분에 해당된다.
--------------------------------------------------------------------
p=1303&highlight=%2527%252Esystem(...
t=1303&highlight=%2527%252Esystem(...
--------------------------------------------------------------------

세번째줄은 조건이 맞는 경우에 어떻게 처리할 것인지를 정의한 것인데,
웜으로 판단되면 요청을 http://127.0.0.1/ 으로 넘겨버린다. 즉 웜 자신에게 요청을
넘기게 되는 것이다. 여기서 또 하나 중요한 부분이 'E=phpbb:1' 이다.
환경변수 phpbb에 1이라는 값을 넣으라는 것이다. 이 것은 로그를 별도로 저장하기 위한
안내자 역할을 하게 된다.

네번째줄은 환경변수 phpbb로 정의된 요청은 logs/phpbb_worm_log 에 로그를 남기라는 것이다.

자~ 이제 짜증나는 저 웜을 한방에 날려버리세요.

3. 참고 자료

* Apache 1.3 URL Rewriting Guide
http://httpd.apache.org/docs/misc/rewriteguide.html

* phpBB Worm 차단에 대해 (글 Raymond Dijkxhoorn)
http://www.securityfocus.com/archive/1/385103

* phpBB의 highlight 변수의 보안문제에 대해
http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=240513

* phpBB Remote Command Execution (Viewtopic.php Highlight)
http://www.securiteam.com/unixfocus/6J00O15BPS.html

* Using the [E=VAR:VAL] flag to pass a variable to CGI
http://www.webmasterworld.com/forum92/2631.htm

--
시스템관리자들의 쉼터, http://coffeenix.net/
2006/09/11 12:58 2006/09/11 12:58
이 글에는 트랙백을 보낼 수 없습니다
출처 카페 > 운영체제 공부 / 쩡희
원본 http://cafe.naver.com/jeonghee1004/21
제 목 : 아파치에서 phpBB웜 차단 및 별도 로그 저장
글쓴이 : 좋은진호(truefeel, http://coffeenix.net/ )
글쓴일 : 2005.2.16(수)

phpBB 2.0.11 이전 버전의 보안문제를 이용한 phpBB Worm(Santy 웜 등)의 공격이 여전히
많이 시도되고 있다. phpBB를 최신 버전으로 업하는 것은 당연한 것이지만 지속적인 공격
으로 시스템 로드를 잡아먹고 짜증나는 로그를 해결할 방법이 필요했다.

1. phpBB 웜 공격 로그

access log에는 다음과 같은 형태의 로그가 남는다. (한줄로)

--------------------------------------------------------------------
65.77.xxx.xx - - [30/Dec/2004:19:58:01 +0900] "GET /...경로.../viewtopic.php?
p=1303&highlight=%2527%252Esystem(chr(112)%252Echr(101)%252Echr(114)%252Echr(108)
%252Echr(32)%252Echr(45)%252Echr(101)%252Echr(32)%252Echr(34)%252Echr(112)%252
Echr(114)%252Echr(105)%252Echr(110)%252Echr(116)%252Echr(32)%252Echr(113)%252
Echr(40)%252Echr(106)%252Echr(83)%252Echr(86)%252Echr(111)%252Echr(119)%252
Echr(77)%252Echr(115)%252Echr(100)%252Echr(41)%252Echr(34))%252E%2527
HTTP/1.0" 302 712 "-" "Mozilla/4.0"
--------------------------------------------------------------------

highlight= 변수로 넘어온 값을 phpBB의 viewtopic.php에서 urldecode()함수를 통해 보안상의
문제를 열어두고 있는데 이를 악용한 것이다.
웜의 다른 특징은 Agent가 "Mozilla/4.0"이라는 것이다. 단지 이 user agent인 경우를 차단
면 정상적인 사용자의 접속을 차단하는 경우도 생길 수 있으므로 여기서는 URL을 통한 방법을
사용할 것이다.

2. 웜 차단과 로그는 별도 저장

웜도 차단하면서 동시에 웹로그는 별도로 저장하는 httpd.conf 아파치 설정을 알아보자.

--------------------------------------------------------------------
RewriteEngine On

RewriteCond %{QUERY_STRING} ^[a-z]{1}=(.*)highlight=\%2527\%252E
RewriteRule ^.*$ http://127.0.0.1/ [R,L,E=phpbb:1]

CustomLog logs/phpbb_worm_log common env=phpbb
--------------------------------------------------------------------

아파치에서는 URL Rewriting 설정을 통해 특정 URL로 요청된 것을 내부의 다른 페이지로
넘길 수도 있고 전혀 다른 사이트의 페이지로 보낼 수도 있다. 또한 조건에 맞는 URL이면
이를 아파치 내의 변수값으로 지정도 가능하다.
아파치의 Rewriting rule에 대한 자세한 글은 Apache 홈페이지의 "URL Rewriting Guide"
를 읽어보기 바라고, 설정에 대해 한줄씩 알아보기로 하자.

첫번째줄은 URL rewriting의 시작을 알린다.

두번째줄은 조건문이다. URI(쿼리)중에 위와 같은 URL이 형태인 경우인지를 비교하게된다.
즉, 로그의 첫부분인 다음과 같은 부분에 해당된다.
--------------------------------------------------------------------
p=1303&highlight=%2527%252Esystem(...
t=1303&highlight=%2527%252Esystem(...
--------------------------------------------------------------------

세번째줄은 조건이 맞는 경우에 어떻게 처리할 것인지를 정의한 것인데,
웜으로 판단되면 요청을 http://127.0.0.1/ 으로 넘겨버린다. 즉 웜 자신에게 요청을
넘기게 되는 것이다. 여기서 또 하나 중요한 부분이 'E=phpbb:1' 이다.
환경변수 phpbb에 1이라는 값을 넣으라는 것이다. 이 것은 로그를 별도로 저장하기 위한
안내자 역할을 하게 된다.

네번째줄은 환경변수 phpbb로 정의된 요청은 logs/phpbb_worm_log 에 로그를 남기라는 것이다.

자~ 이제 짜증나는 저 웜을 한방에 날려버리세요.

3. 참고 자료

* Apache 1.3 URL Rewriting Guide
http://httpd.apache.org/docs/misc/rewriteguide.html

* phpBB Worm 차단에 대해 (글 Raymond Dijkxhoorn)
http://www.securityfocus.com/archive/1/385103

* phpBB의 highlight 변수의 보안문제에 대해
http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=240513

* phpBB Remote Command Execution (Viewtopic.php Highlight)
http://www.securiteam.com/unixfocus/6J00O15BPS.html

* Using the [E=VAR:VAL] flag to pass a variable to CGI
http://www.webmasterworld.com/forum92/2631.htm

--
시스템관리자들의 쉼터, http://coffeenix.net/
2006/09/11 12:58 2006/09/11 12:58
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > 생을 그리는 작업실
원본 http://blog.naver.com/doolyking/60006404516
인터넷을 탐험하다가 보면, 웹상의 하이퍼링크나 즐겨찾기의 바로가기를 클릭하거나 직접 주소를 입력해 넣었을 때, 가고자 하는 사이트가 열리는 대신에 굵은 글씨에 가끔 숫자도 들어 있는 경고성 문구의 페이지가 뜨는 경우가 있습니다. 그 중에서 가장 대표적인 에러 메시지들을 소개할까 합니다.

403 Forbidden/Access Denied (403 금지/액세스 거부)
    이 웹 사이트는 패스워드와 같은 특별한 액세스 승인을 필요로 하는
    경우입니다.
404 Not Found (404 찾을 수 없음)
    브라우저가 호스트 컴퓨터는 찾았으나 요청된 특정 도큐먼트를 찾지 못한 경우입니다.
    정확한 주소를 입력했는지 확인해 봅니다. 그 페이지는 해당 웹 사이트에서 제거되었을 수도 있고 위치가 바뀌었을 수도 있습니다.
    파일명을 떼어내고 주소를 다시 한 번 입력해 봅니다. 즉, 한 단계 위의 웹 사이트를 찾아 봅니다.
503 Service Unavailable (503 서비스 불가)
    해당 웹 사이트의 서버에 과부하가 걸린 경우입니다.
    몇 초 후에 다시 시도해 봅니다.
Bad file request (잘못된 파일 요청)
    온라인 폼 또는 HTML 코드가 잘못된 경우입니다.
Connection refused by host (호스트의 접속 거부)
    위에 있는 ‘403 Forbidden/Access Denied’ 에러와 유사한 상황입니다.
Failed DNS lookup (DNS 찾기 실패)
    해당 웹 사이트의 URL이 적절한 IP 주소로 전환될 수 없는 경우입니다.
    이런 에러는 상용 사이트에서 빈번하게 발생하는데 IP 주소 전환을 담당하는 컴퓨터들이 과부하 상태에 놓이기 때문이라고 합니다.
    물론, 주소를 잘못 입력한 경우에도 발생할 수 있습니다.
    주소를 다시 한 번 입력해 보거나, 혼잡하지 않을 것 같은 시간에 다시 시도해 봅니다.
Helper application not found
    보조 응용프로그램(helper application)을 필요로 하는 파일을 다운받으려 하는데, 인터넷 익스플로러가 찾지 못하는 경우입니다.
    이런 경우에는 아무 Windows 창이나 열어서 ‘보기(V)’의 ‘폴더 옵션(O)’에 있는 ‘파일 형식’ 탭을 선택하여 보조 응용프로그램을 위한 디렉토리 및 파일명이 정확하게 입력되도록 합니다.
Not found (찾을 수 없음)
    하이퍼링크가 가리키는 웹 페이지가 더 이상 존재하지 않음을 나타냅니다.
Site unavailable (사이트 사용 불가)
    너무 많은 사람들이 동시에 액세스하려 하면 온라인상에 노이즈가 생겨 해당 사이트가 다운될 수도 있고, 아니면 더 이상 그 사이트가 존재하지 않는 경우일 수도 있습니다. 주소를 잘못 입력해도 나올 수 있습니다.
각 Error 코드별 의미
    100 : Continue
    101 : Switching protocols
    200 : OK, 에러없이 전송 성공
    201 : Created, POST 명령 실행 및 성공
    202 : Accepted, 서버가 클라이언트 명령을 받음
    203 : Non-authoritative information, 서버가 클라이언트 요구 중 일부 만 전송
    204 : No content, 클라언트 요구을 처리했으나 전송할 데이터가 없음
    205 : Reset content
    206 : Partial content
    300 : Multiple choices, 최근에 옮겨진 데이터를 요청
    301 : Moved permanently, 요구한 데이터를 변경된 임시 URL에서 찾았음
    302 : Moved temporarily, 요구한 데이터가 변경된 URL에 있음을 명시
    303 : See other, 요구한 데이터를 변경하지 않았기 때문에 문제가 있음
    304 : Not modified
    305 : Use proxy
    400 : Bad request, 클라이언트의 잘못된 요청으로 처리할 수 없음
    401 : Unauthorized, 클라이언트의 인증 실패
    402 : Payment required, 예약됨
    403 : Forbidden, 접근이 거부된 문서를 요청함
    404 : Not found, 문서를 찾을 수 없음
    405 : Method not allowed, 리소스를 허용안함
    406 : Not acceptable, 허용할 수 없음
    407 : Proxy authentication required, 프록시 인증 필요
    408 : Request timeout, 요청시간이 지남
    409 : Conflict
    410 : Gone, 영구적으로 사용할 수 없음
    411 : Length required
    412 : Precondition failed, 전체조건 실패
    413 : Request entity too large,
    414 : Request-URI too long, URL이 너무 김
    415 : Unsupported media type
    500 : Internal server error, 내부서버 오류(잘못된 스크립트 실행시)
    501 : Not implemented, 클라이언트에서 서버가 수행할 수 없는 행동을 요구함
    502 : Bad gateway, 서버의 과부하 상태
    503 : Service unavailable, 외부 서비스가 죽었거나 현재 멈춤 상태
    504 : Gateway timeout
    505 : HTTP version not supported
2006/09/11 12:58 2006/09/11 12:58
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > 피할수 없는 길이라면 즐겨라.
원본 http://blog.naver.com/nadanux/80008955701

1. 컴파일옵션

---------------------------------------------------------------------------------------

./configure --prefix=/usr/local/apache2 --enable-rule=SHARED_CORE --enable-module=so --enable-shared=max --enable-so --enable-ssl --enable-cgid --enable-cgi

------------------- 기본으로 주어야하는 옵션 -----------------------

--enable-suexec  // suecex 사용

--with-suexec-uidmin=500  // 기본 uid가 500 미만인 유저가 접근할경우 에러

--with-suexec-gidmin=500  // 기본 gid가 500 미만인 유저가 접근할경우 에러

--with-suexec-docroot=/   // hosting 폴더 설정  /home 또는 /hosting 등 만약에

/home1 /home2 등 여러곳일 경우 루트 "/" 로 적는다.

--with-suexec-caller=nobody  // 아파치 실행권한 대부분  nobody이다 적어주지 않을경우 www 사용자로 된다.

이정도만 해주면 무리업이 진행 될것입니다.



---------------------------------------------------------------------------------------

참고자료

---------------------------------------------------------------------------------------

Apache 에서 CGI 를 위한 suexec 사용하기.출처(phpschool.com)


Apache 를 컴파일 할때
--enable-suexec
옵션을 줘서 컴파일 한다.

위 옵션을 줄때는 반드시 부수적인 옵션 하나 이상이 있어야 한다.
 --with-suexec-bin       Path to suexec binary
 --with-suexec-caller    User allowed to call SuExec
 --with-suexec-userdir   User subdirectory
 --with-suexec-docroot   SuExec root directory
 --with-suexec-uidmin    Minimal allowed UID
 --with-suexec-gidmin    Minimal allowed GID
 --with-suexec-logfile   Set the logfile
 --with-suexec-safepath  Set the safepath
 --with-suexec-umask     umask for suexec'd process
이것중에 적어도 하나는 포함해야 합니다.

저는 httpd-2.0.49 에서
--server-uid=web \
--server-gid=web \
--enable-suexec \
--suexec-uidmin=1000 \
--suexec-gidmin=1000
이렇게 포함했습니다. UID 와 GID 가 1000 미만인 파일은 실행이 안되게끔...
단, web User 의 UID 와 GID 가 1000 이상이여야합니다. 이상이 아닐경우 오류를 출력합니다.

컴파일 설치한 후에는 httpd.conf 파일을 수정합니다.
먼저 CGI 가 실행되게끔 해줍니다.

AddHandler cgi-script .cgi

앞에 # 주석 제거.

<Directory ... > 의 Options 에 IncludesNoExec 를 ExecCGI 로 수정

Section 3 의 Virtual Hosts 를 사용하는 경우

<VirtualHost *:80>
       .
       .
   SuexecUserGroup master master
       .
</VirtualHost>
<VirtualHost *:80>
       .
       .
   SuexecUserGroup useraaa groupaaa
       .
</VirtualHost>
<VirtualHost *:80>
       .
       .
   SuexecUserGroup userbbb groupbbb
       .
</VirtualHost>

이런식으로 SuexecUserGroup 를 써줍니다. 보시면 아시겠지만 SuexecUserGroup 다음에 처음 작성하는게 해당 도메인 User 이고 두번째 작성하는게 해당 도메인 Group 입니다.

이제 간단하게 test.cgi 파일을 작성합니다. 단 조심하실점은 작성된 CGI 파일은 Group 이나 Order 에 Write 권한이 있다면 Internal Server Error 를 출력합니다. (User 에 Write 권한은 오류출력 안함.)

간단하게 CGI 파일의 권한설정을 chmod 500 test.cgi 정도로 주시면 되겠습니다. 이렇게 주시면 Group 이건 Order 건 접근 불가능 입니다.

그리고 위에 저와 같이 UID 와 GID 를 1000 으로 주신경우에 만약 1000 이하의 User 나 Group 의 CGI 를 실행할 경우 역시 Internal Server Error 에러를 출력합니다.

그리고 SuexecUserGroup 에서 지정된 User 와 Group 이 아니여도  Internal Server Error 오류를 출력합니다.

언제든지 suexec 설정을 보실려면

./suexec -V

하시면 되며 수정은 불가입니다. 수정하실려면 Apache 재설치 하셔야합니다.


오류의 원흉 정리)
1. --enable-suexec 옵션을 사용할경우 꼭 부수적인 옵션을 하나이상 포함할것.
2. 웹서버 데몬 User 와 Group 은 --suexec-uidmin=xxx --suexec-gidmin=xxx 에서 지정된 UID 와 GID 보다 클것.
3. 파일소유주와 그룹이  --suexec-uidmin=xxx --suexec-gidmin=xxx 에서 지정된 UID 와 GID 보다 클것.
4. 파일소유주와 그룹이 SuexecUserGroup 에서 지정한 User 와 Group 일것.
5. 파일권한에 Group 과 Order 에 write 권한이 없을것.(Suexec 를 사용하는경우는 그냥 퍼미션을 Group 과 Order 에 주지마세요 User 권한만 있으면 됩니다.)

추신. 저녁에 그냥 심심해서 작성한 글입니다. Suexec 를 사용할려고 하는분이나 설정이 미비하신분들은 사용하시면 좋습니다. Suexec 를 사용하지 않는 경우는 웹CGI 땜시 서버가 흔들리는 경우가 다반사라서...--; Suexec 를 사용한다 하더라도 SuexecUserGroup 를 주지 않는다면 역시 하나마나한거라서...--;

----------------------------------------------------------------------------------------

참고자료 끝 참고자료에서 옵션 바뀐 부분있음. --suexec-uidmin=xxx --suexec-gidmin=xxx

----------------------------------------------------------------------------------------


2. # make

3. # make install

4. # vi httpd.conf

---------------------------------------------------------------------------------------

<Directory /home>  // home아래서 cgi 사용
AllowOverride None
Options ExecCGI Includes
</Directory>


AddHandler cgi-script .cgi .pl  // 주석이 있다면 해제. pl확장자 일부 있음

// 가상 호스트 부분

<VirtualHost 61.xx.xx.xx>
ServerName abc.co.kr
DocumentRoot /host/abc/public_html
ServerAlias *.abc.co.kr
#ErrorLog /host/samil25/wwwLog/errorLog
#CustomLog  /host/samil25/wwwLog/accessLog common
SuexecUserGroup abc hosting  <-- 이부분 추가
</VirtualHost>


아파치 재시작

잘되는군요. 상쾌합니다.

기타 자세한 문의 : nadanux@nate.com


2006/09/11 12:57 2006/09/11 12:57
이 글에는 트랙백을 보낼 수 없습니다
Web_developing/Apache  2006/09/11 12:55
출처 블로그 > Greate Teacher Onizuka
원본 http://blog.naver.com/semi7623/100005575241

새 모듈을 Perl로 작성하고 기존의 모듈을 유명한 언어를 사용해서 구성할 수 있게 해주는 Apache 모듈 mod_perl도 DSO로서 컴파일할 수 있다. 이를 위해서는 mod_speling의 경우처럼 apxs를 사용해야 한다. 그러나 mod_perl은 단일 모듈에 비해 훨씬 복잡하고 컴파일 시 외부 정보에 크게 의존하기 때문에 독립 Perl 모듈과 비슷하게 perl Makefile.PL 다음에 make, make test, make install을 입력하여 구성 및 컴파일 해야 한다.
기존의 Apache 버전에 새 버전의 mod_perl을 컴파일하려면 다음과 같은 명령을 사용한다.

perl Makefile.PL \
USE_APXS=1 WITH_APXS=/usr/local/apache/bin/apxs

동적 내용 생성용의 기본 PerlHandler 외에 다양한 Apache 핸들러 전체에 대해 mod_perl을 가동하고 싶다면 EVERYTHING 스위치를 적용한다.

perl Makefile.PL \
USE_APXS=1 WITH_APXS=/usr/local/apache/bin/apxs \
EVERYTHING=1

이와 같이 Makefile을 생성했으면 아래의 명령으로 기존의 Apache 서버에 mod_perl을 컴파일하고 설치할 수 있다.

make
make test
make install

이 방법은 mod_perl의 새로운 복사본을 Apache에 설치하는 경우 뿐 아니라 기존 복사본을 업그레이드할 때도 효과적이다. 그런다음 서버의 주소와 포트 번호로 telnet 연결하고 아래와 같이 명령을 내려 mod_perl이 서버에 컴파일되었는지 확인할 수 있다.

HEAD / HTTP/1.0

그러면 서버에서 / 문서와 연결된 HTTP 헤더가 반환된다. 이 때 무엇보다도 운영되는 서버의 종류를 가리키는 'Server' 헤더가 중요하다. mod_perl은 이 출력 문자열에 태그를 추가하므로 아래와 같은 출력을 보게 될 것이다.

Server: Apache/1.3.22 (UNIX) mod_perl/1.24


mod_perl의 업데이트가 Apache와 다른 간격으로 이뤄지지 때문에 이렇게 mod_perl을 설치하고 업그레이드하는 방법은 상당한 효과를 갖는다.

2006/09/11 12:55 2006/09/11 12:55
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > 아름다운 세상, 아름다운 미래
원본 http://blog.naver.com/neocycle/80015132669

출처 : http://blog.n-nuri.com/index.php


# pgcc 가져 오기 ( 원사이트에서 가져와 pgcc와 pg++를 묶어놨습니다. )

wget http://www.sapphireserver.com/pgcc-linux.tar.gz
tar zxf pgcc-linux.tar.gz -C /usr/local/
echo '/usr/local/pgcc/lib' >> /etc/ld.so.conf
ldconfig



# mysql 설치
CC="/usr/local/pgcc/bin/pgcc" CFLAGS="-O6 -mpentiumpro -mstack-align-double -fomit-frame-pointer -march=pentiumpro" CXX="/usr/local/pgcc/bin/pgcc" CXXFLAGS="-O6 -mpentiumpro -march=pentiumpro -mstack-align-double -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" LDFLAGS="-static" ./configure --prefix=/usr/local/mysql --with-client-ldflags=-all-statoc --with-mysqld-ldflags=-all-static --with-charset=euc_kr --without-debug --enable-assembler --with-mysqld-user=mysql --with-innodb
make && make install

wget http://www.sapphireserver.com/euc_kr.conf -O /usr/local/mysql/share/mysql/charsets/euc_kr.conf
echo '/usr/local/mysql/lib' >> /etc/ld.so.conf
ldconfig



# 웹서버와 PHP 설치

CC="/usr/local/pgcc/bin/pgcc" OPTIM="-O2" CFLAGS="-DDYNAMIC_MODULE_LIMIT=0" ./configure --prefix=/usr/local/apache --enable-module=headers --disable-module=userdir --disable-module=imap --disable-module=status --disable-module=include --disable-module=auth --enable-module=mmap_static



./configure --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.29 --with-imap=/usr/local/imap-2001
make && make install



CC="/usr/local/pgcc/bin/pgcc" OPTIM="-O2" CFLAGS="-DDYNAMIC_MODULE_LIMIT=0" ./configure --prefix=/usr/local/apache --enable-module=headers --activate-module=src/modules/php4/libphp4.a --disable-module=userdir --disable-module=imap --disable-module=status --disable-module=include --disable-module=auth --enable-module=mmap_static
make && make install




  header append P3P: 'CP="CAO DSP COR CURa ADMa DEVa OUR IND PHY ONL UNI COM NAV INT DEM PRE"'






아래는 웹서버에 있는 동적파일을 벤치마킹한 결과입니다.
--------------------------------------------------------------------------------
ab -c1000 -n30000 http://www.test.com/index.php
This is ApacheBench, Version 1.3d <$Revision: 1.70 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.test.com (be patient)
Completed 3000 requests
Completed 6000 requests
Completed 9000 requests
Completed 12000 requests
Completed 15000 requests
Completed 18000 requests
Completed 21000 requests
Completed 24000 requests
Completed 27000 requests
Finished 30000 requests
Server Software: entertainment/:)
Server Hostname: www.test.com
Server Port: 80

Document Path: /index.php
Document Length: 4473 bytes

Concurrency Level: 1000
Time taken for tests: 233.487 seconds
Complete requests: 30000
Failed requests: 6
(Connect: 3, Length: 3, Exceptions: 0)
Broken pipe errors: 0
Total transferred: 141568201 bytes
HTML transferred: 134188201 bytes
Requests per second: 128.49 [#/sec] (mean)
Time per request: 7782.90 [ms] (mean)
Time per request: 7.78 [ms] (mean, across all concurrent requests)
Transfer rate: 606.32 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 10 835 2771.9 12 188998
Processing: 72 3122 3152.3 1012 193807
Waiting: 52 3121 3152.3 1011 193807
Total: 72 3957 4208.8 1037 193826

Percentage of the requests served within a certain time (ms)
50% 1037
66% 1452
75% 3985
80% 4073
90% 8243
95% 10303
98% 22569
99% 49780
100% 193826 (last request)



-------------------------------------------------------------------------

테스트는 서울(KIDC-터미널상태)에서 부산(온세 IDC)센터에 있는 서버로 했습니다.
서버는 커널 피라미터쪽도 손본상태이며, 디비서버가 분리된 웹서버 전용입니다.
인덱스파일은 템플릿을 사용하는 크기가 좀 큰 파일입니다.



php 또한 pgcc 로 컴파일 하실수 있습니다.
configure 후에 생성되는 Makefile 에서 gcc 를 pgcc 로 수정하시면 됩니다.

2006/09/11 12:52 2006/09/11 12:52
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > seafig님의 블로그
원본 http://blog.naver.com/seafig/60005184191
아파치에서 전송 속도 제한하기 (모든 설명은 레드햇 6.0을 기준으로 합니다.)  

1. 아파치 1.3.x용 bandwidth 모듈이 필요합니다.  

ftp://ftp.cohprog.com/pub/apache/module/1.3.0/mod_bandwidth.c를  
받아  
오시면 됩니다. 레드햇 6.0 이상을 기반으로 한 배포판에는 이 모듈이  
포함되어 있습니다. /usr/lib/apache/mod_bandwidth.so가 이미 존제하는 분은  
컴파일 과정을 생략하시면 됩니다.  

참고: 레드햇에 포함된 버젼은 1.2 버젼입니다. 최신 버젼은 2.0 버젼이며  
다음의 설명들에 1.2 버젼에는 없는 기능의 경우에는 *로 마크를  
하겠습니다.  

2. 아파치 모듈로의 컴파일이 필요합니다.  

o 아파치 소스와 같이 컴파일 하려면 아파치 소스의 src/modules/extra/  
디렉토리로 mod_bandwidth.c를 복사한 후에 ./configure시에  
--add-module=mod_bandwidth.c 옵션을 주시면 됩니다.  

o 직접 컴파일 하려면 다음의 명령을 따라하시면 됩니다. 물론 그러기  
위해서는 아파치의 개발용 헤더들이 시스템에 설치되어 있어야 합니다.  
레드햇의 경우 apache-devel이라는 패키지로 존재합니다. 그 위치는  
/usr/include/apache/에 있습니다. (배포판에 따라 틀릴 수 있습니다.)  

$ gcc -c -I/usr/include/apache -O2 -m486 -fno-strength-reduce   
mod_bandwidth.c -fpic -DSHARED_MODULE mod_bandwidth.c  
$ gcc -shared -o mod_bandwidth.so mod_bandwidth.o  

$는 쉘 프롬프트를 나타내며 는 줄이 이어진다는 뜻입니다. 그러니까 한  
줄로 붙여 쓰시기 바랍니다.  

3. 컴파일된 모듈을 아파치 모듈이 위치하는 디렉토리로 옮기시기 바랍니다.  
레드햇의 경우 /usr/lib/apache/에 위치합니다. 직접 컴파일하셨다면 지정한  
것에 따라 틀릴 수 있습니다. 알아서 하시기 바랍니다. :)  

4. 아파치의 설정 파일을 고쳐야 할 것입니다. 그럼 하나씩 고치는 방법에  
대해서 알아 보겠습니다.  

1. 모듈로 컴파일 했기 때문에 모듈을 읽도록 해야 합니다. httpd.conf에서  
LoadModule foobar_modules modules/mod_foobar.so 같은 내용이 있는  
부분이 있습니다. 그 하단부에 다음 줄을 추가 하십시오.  

LoadModule bandwidth_module modules/mod_bandwidth.so  

마지막은 모듈의 위치입니다. 설치한 것에 따라 설정하십시오.  

httpd.conf 설정에 ClearModuleList가 있다면 다음 줄이 추가되어야  
합니다.  

AddModule mod_bandwidth.c  

비슷한 내용이 있는 부분의 아래에 적으시면 될 것입니다. :)  

2. 이제 전송 속도 제한 기능을 하는 모듈을 사용하겠다는 것을 지정해  
주어야 합니다. 디렉토리별 설정 위에 다음 줄을 추가하시면 됩니다.  

BandWidthModule On  

3. 이 모듈이 사용하기 위해서는 데이타를 기록할 장소가 필요합니다.  
기본값으로 /tmp/apachebw 디렉토리를 사용합니다.  

/tmp/apachebw/link  
/tmp/apachebw/master  

이렇게 디렉토리를 생성해 주시십시오. 퍼미션은 nobody 사용자가 쓸 수  
있는 권한이 있어야 합니다. (여기서 nobody는 아파치가 사용하는  
사용자입니다. 다른 사용자를 사용한다면 그 사용자의 권한으로 줘야  
겠지요.) 생각하기 싫으신 분은 다음 명령을 실행하십시오.  

chown root.nobody /tmp/apachebw  
chmod -R 770 /tmp/apachebw/  

4. 이제 실제적인 전송 속도 제한의 옵션을 알아 보겠습니다.  

BandWidth, LargeFileLimit, MinBandWidth 이렇게 세가지의 지시자?가  
있습니다. 각각에 대해서 알아 봅시다.  

o BandWidth  

문 법: BandWidth <도메인|IP주소|all> <속도>  
기본값: 없음  
사용처: 전체 설정, 디렉토리별 설정, .htaccess  

호스트에 따라 속도의 제한을 걸 수 있습니다. all은 모든 호스트에  
대해서 제한을 거는 것입니다. 도메인이나 IP주소로 접속 호스트를  
지정할 수 있습니다. 그리고 네트워크/마스크 포맷*으로 지정할 수도  
있습니다. (예: 192.168.0.0/24)  

속도는 Bytes/second로 나타냅니다. 0의 경우는 제한이 없는 것입니다.  

디렉토리별 설정에서 사용한 예를 들겠습니다.  


BandWidth 192.168.1 0  
BandWidth foobar.net 0  
BandWidth all 1024  


/home/httpd/html 디렉토리에서의 제한을 한 것입니다. 192.168.1.* IP  
주소를 가진 호스트와 *.foobar.net이라는 도메인명을 사용하는  
호스트에 대해서는 제한을 걸지 않으며 그 외 모든 접속에 대해서  
1024Bytes/sec으로 제한을 걸었습니다.  

o LargeFileLimit  

문 법: LargeFileLimit <파일크기> <속도>  
기본값: 없음  
사용처: 전체 설정, 디렉토리별 설정, .htaccess  

일정 이상의 크기를 가진 파일을 누군가가 받아 가려 할 때 그 속도의  
제한을 걸 수 있습니다. 파일크기는 KByte 기준이며 속도는 역시  
Bytes/secound입니다.  

LargeFileLimit 1024 4096  
LargeFileLimit 2048 2048  

위 예제는 1024 ~ 2047KB 크기의 파일을 받아가려 할 때 속도를  
4KB/sec으로 제한하고 2048KB 이상의 파일은 2KB/sec으로 제한을 하는  
것입니다.  

o MinBandWidth  

문 법: MinBandWidth <도메인|IP주소|all> <속도>  
기본값: all, 256  
사용처: 전체 설정, 디렉토리별 설정, .htaccess  

데이타 전송의 최저 속도를 지정하게 됩니다. 예를 들어서 설명하는  
것이 가장 좋을 것 같군요.  

BandWidth를 4096 (4KBytes/sec)으로 지정하고 MinBandWidth가 1024로  
지정이 되어 있을 때:  

- 지정된 호스트에서 하나만 접속할 경우, 4096bytes/sec이 최고의  
속도가 됩니다.  

- 지정된 호스트에서 두개가 동시에 접속할 경우, 각각의 세션에 대해  
2048Bytes/sec이 최고의 속도가 됩니다.  

- 더 많은 동시 접속이 일어나도 세션 당 최고 속도는 1024Bytes/sec  
이하로는 줄지 않습니다. (MinBandWidth 값이 1024기 때문에)  

MinBandWidth가 "-1"로 지정되면 모든 세션에 대해 최고 속도는  
BandWidth나 LageFileLimit에서 지정한 속도가 나올 수 있게 됩니다.  

BandWidth를 4096으로 지정하고 MinBandWidth가 -1이라면 동시에 지정된  
호스트에서 몇개의 접속을 하더라도 각 세션의 속도는 4096Bytes/sec  
까지 나오게 되는 것입니다.  
출처: 적수네

2006/09/11 12:23 2006/09/11 12:23
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > 살 맛나는 세상
원본 http://blog.naver.com/xacti/80002321360
1. httpd.conf
A. config 에서 성능에 대한 요소들

i. KeepAlive Off
한번 connection 하면 바로 connection을 끊지 않고 유지를 하는 기능인데 Off를 해야 더 많은 client 들의 request 처리를 할 수 있다. KeepAlive On 상태이면 MaxKeepAliveRequests, KeepAliveTimeOut 값을 적절히 조절해야 된다.

ii. Timeout 30
connection 시점부터 완료 될때까지의 최대 시간값 이다. network 이상이상 등으로 connection 환경이 비정적인 client connection 들이 많아지면 apache child process 새 connetcion 처리를 위해 계속 fork하게 될것이고 server의 과부하가 생긴다.

iii. HostnameLookups Off
apache 기본값은 Off 이며 On 으로 되어 있으면 connection하고 있는 cilent IP 주소가 역 추적되고 그 정보가 log file등에 쓰인다. 그렇기 때문에 성능에 좋지 않다.

iv. FollowSymLinks
Options FollowSymLinks 가 설정되어 있다면 symlinks에 대한 보안검사를 수행한다. symlinks에 대한 보안검사에 따라서 성능이 좋지 않게되며 불필요한 경우라면 설정하지 않는게 좋다.

v. Options SymLinksIfOwnerMatch
설정되어 있다면 각 directory를 모두 점검해서 각각의 lstat system call을 하게 되므로 성능이 저하된다.

vi. AllowOverride None
AllowOverride all 로 설정된경우 모든 filename component에 대해서 .htaccess file을 열게된다. 이 file을 한번더 열게 됨으로서 성능이 좋지 않게 되며 이것이 필요없는 경우라면 AllowOverride None 을 사용해야 된다.

vii. Negotiation
DirectoryIndex index 처럼 wildcard를 사용 하는 것 보다 DirectoryIndex index.cgi index.pl index.shtml index.html 와 같이 complete list로 사용하는 것이 좋다. complete list 에서는 가장 먼저 선택되는 순으로 나열하는 것이 좋다.

viii. MaxRequestsPerChild 0
apache child process가 memory leak 이 없고 사용자 module 로 작성한 부분이 견고하다고 판단되면 0 (unlimited)로 설정하는 것이 좋다.

ix. Apache 2.0 Multi-Processing Modules 에 따른 Process Creation  


1. prefork  

A. apache 1.3 의 계승(default) 된것이며 thread 를 지원하지 않는 Unix 계열을 위해 남겨둔 것이다.

B. MinSpareServers, MaxSpareServers, StartServers 지시자를 적절히 조절해야 된다.

C. MaxClients 수는 Client connection 이 너무 많다면 server의 spec에 따라 적절하게 제한 해야 한다.


2. worker

A. parent 로 부터 fork 된 child process는 고정된 숫자의 thread 를 가지고 있으며 StartServer에 지정된 숫자 만큼 child process 생성한다.

B. ThreadPerChild 에 고정된 숫자 만큼 child process 내 Thread 개수 생성

C. StartServer × ThreadPerChild 숫자만큼의 Thread가 Server Start시에 생성되고 request에 따라 MaxClient 값까지 증가 한다.

D. 각각의 thread 들은 connection들의 listen 과 serve 를 한다.

E. request 가 늘어나면 parent 는 child process 를 fork 하여 ThreadPerChild에 지정된 숫자 만큼의 thread 를 생성한다. request 가 늘어나면 parent 는 child process 를 kill 하여 child process 내에 있던 thread를 한꺼번에 kill 한다.  MaxSpareThreads, MinSpareThreads 지시자 사용하여 적절히 조절해야 한다

F. apache 2.0.35 test 결과로는 child process 를 늘이고 child process 내에 thread 숫자를 줄이는 것이 더 성능이 좋았는데 이유는 thread 간의 경합문제가 생기는 것으로 판단된다.  


2. modules
compile 시 포함되는 불 필요한 module을 없애서 fork 및 불필요한 system call 의 부하를 줄인다.

A. Core Features and Multi-Processing Modules

i. core
basic server operation을 위해서 꼭 필요하다.

ii. mpm_common
multi-processing module (MPM) 을 위한 common module

iii. MPM module 로서 각 OS에 따라서 1개만 포함 되게 된다.


1. mpm_netware
   Novell NetWare 를 위한 multi-processing module
2. mpm_winnt
   Windows NT 를 위한 multi-processing module
3. perchild
   각각의 process 들이 다양한 다른 userid 를 가지고 serving 을 할 수 있는 multi-processing module 이며 실험 단계 이다.
4. prefork
   apache 1.3 의 pre-forking web server 의 계승된 multi-processing module
5. worker
   hybrid multi-threaded multi-process web server 를 구현한 multi-processing module

B. Other Modules

i. mod_access
<Directory>, <Files>, <Location> sections 및 .htaccess files 에 clinet 의 hostname, ip 들을 가지고 access control을 위해서 필요하다.

ii. mod_actions
CGI scripts 실행이 필요하다면 필요하다.

iii. mod_alias
URL redirection 이나 Alias ScriptAlias 을 위해 필요하다.

iv. mod_asis
HTTP header 와 함께 file 내용을 그대로 보낼 때 쓰인다. 불 필요 하다.

v. Authentication 에 대한 modules
Authentication 에 대한 기능이 필요 없으면 모두 불 필요하다.


1. mod_auth, mod_auth_dbm
HTTP basic authentication 으로서 인증에 관한 정보를 text file 등에 저장 할수 있고 mod_auth_dbm 을 통해서 DBM 등에 저장될수도 있다. 인증에 관련 없으면 불 필요.

2. mod_auth_anon
FTP 스타일 처럼 "anonymous" user access 를  authenticated areas 에 접근하게 할수 있다.

3. mod_auth_digest
MD5 Digest Authentication 지원. 인증에 관련 없으면 불필요 하다.

vi. mod_autoindex
ls및 dir 명령처럼 directory내의 file들을 정렬해서 나오게 해줄 때 쓰인다. 불필요하다.

vii. mod_cgi
CGI scripts 실행을 위해서 필요하다.

viii. mod_deflate
content 압축 지원 (정책상 content 압축을 하기 때문에 필요 할 수 있다.)

ix. mod_dir
directory index files 을 지원 불필요.

x. mod_env
CGI scripts 와 SSI pages 에 system 환경 변수 제공 불 필요.

xi. mod_imap
server 처리 image map으로 처리하기 위해 쓰이며 불 필요.

xii. mod_include
Server Side Includes (SSI) 처리를 위해서 쓰이며 불 필요.

xiii. mod_log_config
Logging 위해서 필요하다.

xiv. mod_mime
content (mime-type, language, character set, encoding)  및 file의 특성에 따라 특정 type 으로 처리하기 위해서 꼭 필요하다.

xv. mod_negotiation
content negotiation 에 필요하다.

xvi. mod_proxy
HTTP/1.1 proxy 기능에 필요.

xvii. mod_setenvif
request의 browser 특성에 따른 서로 다른 script 를 접근하게 하거나 환경 변수를 지정하게 할수있다. BrowserMatch 등의 지지사를 사용하기 위해서 필요하다.

xviii. mod_so
shared object 형태의 동적인 apache modules 이 있다면 필요하다.

xix. mod_ssl
Secure Sockets Layer (SSL) 와 Transport Layer Security (TLS) protocols 을 사용한다면 필요하다.

xx. mod_status
server activity 및 performance 정보들을 moniter 하기 위해서 필요.

xxi. mod_userdir
사용자 계정을 이용하여 home page 를 제공 한다. 불 필요 하다.

3. MaxClient 수를 위한 source 수정
A. apahce 1.3
apache_1.3.x/src/include/httpd.h 의 에서
HARD_SERVER_LIMIT 256
B. apache 2.0

i. prefork
httpd-2.0.36/server/mpm/prefork/prefork.c
DEFAULT_SERVER_LIMIT 256

ii. worker
httpd-2.0.36/server/mpm/worker/worker.c
DEFAULT_SERVER_LIMIT 16
DEFAULT_THREAD_LIMIT 64
2006/09/11 12:20 2006/09/11 12:20
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > 함께 하는 세상
원본 http://blog.naver.com/agentsds/10703283

서버 전역 설정


이 문서는 core 서버가 서버의 기본 행동을 설정하기위해 제공하는 지시어중 일부를 설명한다.



서버 식별

ServerAdminServerTokens 지시어는 오류문 등 서버가 생성하는 문서에 나올 서버에 대한 정보를 설정한다. ServerTokens 지시어는 서버 HTTP 응답 헤더를 설정한다.

서버는 ServerNameUseCanonicalName 지시어를 사용하여 자기참조 URL을 만든다. 예를 들어, 클라이언트가 디렉토리를 요청했지만 디렉토리명 뒤에 슬래쉬를 붙이지않은 경우 아파치는 뒤에 슬래쉬를 붙인 전체 이름을 클라이언트에게 리다이렉트하여, 클라이언트가 문서의 상대참조를 올바로 찾게 한다.

top

파일 위치

이 지시어들은 아파치가 정상적으로 동작하기위해 필요한 여러 파일들의 위치를 설정한다. 경로명이 슬래쉬(/)로 시작하지 않으면, ServerRoot에 상대적인 파일을 찾는다. root가 아닌 사용자에게 쓰기권한이 있는 경로에 파일을 두지않도록 조심해라. 더 자세한 정보는 보안 팁 문서를 참고하라.

top

자원사용 제한

LimitRequest* 지시어는 아파치가 클라이언트의 요청을 읽을 때 사용할 자원량을 제한한다. 이런 값들을 제한하여 서비스거부(denial of service)류 공격을 줄일 수 있다.

RLimit* 지시어는 아파치 자식이 생성하는 프로세스가 사용할 자원량을 제한한다. 특히 CGI 스크립트나 SSI exec 명령어가 사용할 자원을 제한한다.

ThreadStackSize 지시어는 스택 크기를 조절하기위해 Netware에서만 사용한다.

2006/09/11 10:35 2006/09/11 10:35
이 글에는 트랙백을 보낼 수 없습니다
출처 블로그 > Human Packet
원본 http://blog.naver.com/jabusunin/30000023873

[Apache-ProFTPd] Order, Allow, Deny 비교

- 작성자 : 김칠봉 <san2(at)linuxchannel.net>
- 작성일 : 2003-11-22
- 내  용 : 아파치와 ProFTPd 의 Order, Allow, Deny 비교
- 수  준 : 초보용
- 키워드 : Apache, ProFTPd, Order Allow, Deny

*주)
이 문서에 대한 최신 내용은 아래 URL에서 확인할 수 있습니다.

http://www.linuxchannel.net/docs/order-apache-vs-proftpd.txt


------------------------------------------------------
1. Apache Order allow,deny
2. ProFTPd Order allow,deny
3. 비교
4. 정리
------------------------------------------------------

1. Apache Order allow,deny

Order directive

- Syntax  : Order ordering
- Default : Order Deny,Allow  <---- Deny 에 없는 것은 모두 Allow 됨
- Context : directory, .htaccess
- Override: Limit
- Status  : Base
- Module  : mod_access

Allow directive

- Syntax  : Allow from all|host|env=variablename [host|env=variablename] ...
- Context : directory, .htaccess
- Override: Limit
- Status  : Base
- Module  : mod_access
- List    : 구분 공백(' ')
  A (partial) domain-name
Example: Allow from apache.org
  A full IP address
Example: Allow from 10.1.2.3
  A partial IP address
Example: Allow from 10.1
  A network/netmask pair
Example: Allow from 10.1.0.0/255.255.0.0
  A network/nnn CIDR specification
Example: Allow from 10.1.0.0/16

  Allow from 10.1.2.3 env=foo   <-- 틀린 경우(X)
  Allow from env=foo 10.1.2.3   <-- 맞는 경우(O), env 가 앞에 옴

기본정책이 Deny 에 없는 것은 모두 Allow 되고, Deny,Allow 사이는 빈공백없이
콤마(,)로 분리.

- Order Deny,Allow

  Allow 를 평가하기 전에 먼저 Deny 를 평가하고, 그 다음 Allow 에
  override 함. 그리고 여기에 매치되지 않는 나머지 호스트 모두
  Allow 됨. 따라서 이 Order 의 기본정책은 첫번째 Deny 지시자에서 결정함

  즉 순서는,

  1. Deny 매치 우선 결정(기본 정책 결정)
  2. 그 다음 Allow 매치를 override 함
  3. 나머지 포함되지 않은 호스트는 모두 Allow 됨

- Order Allow,Deny

  Deny 를 평가하기 전에 먼저 Allow 를 평가하고, 그 다음 Deny 에
  override 함. 그리고 여기에 매치되지 않은 나머지 호스트는 모두
  Deny 됨. 이 Order 의 기본정책은 첫번째 Allow 지사자에서 결정함.

(*** 이점이 ProFTPd 와 서로 다름 ***)


ex1) 기본정책은 Allow 이고, 예외로 bad.com hacker.com 은 금지

  Order Allow,Deny              <-- Order Mutual-failure 와 같음
  Allow from all
  Deny from bad.com hacker.com  <-- 리스트 나열은 빈공백으로 구분

ex2) 기본정책은 Deny 이고, 예외로 myhost.com 만 접근을 허용함

  Order Deny,Allow
  Deny from all
  Allow from myhost.com

ex3) 중요

  Order Allow,Deny
  Allow from apache.org
  Deny from foo.apache.org

이것은 foo.apache.org 를 제외한 *.apache.org 만 허용하고
나머지 모든 호스트는 접근을 금지함(foo.apache.org 는 당연히 금지)

이유는 Order 순서에 의해서 Deny 를 평가하기 전에 Allow 를 평가하고,
그 다음에 Deny 매치에 override 하기 때문이며, 나머지 매치되지 않는 모든
호스트는 Deny 됨.

ex4) 주의

  Order Deny,Allow
  Deny from all           <--- 기본정책이 모두 Deny 임
  Allow from aaa.foo.com
  Allow from bbb.foo.com ccc.foo.com
  Allow from ddd.com.com
  Deny from ccc.foo.com   <--- *** 이 호스트는 Allow 됨 ****

Allow 를 평가하기 전에 Deny 를 먼저 평가하기 때문에 평가 순서는
다음과 같음.

  Order Deny,Allow
  Deny from all           <--- 기본정책이 모두 Deny 임
  Deny from ccc.foo.com
  Allow from aaa.foo.com
  Allow from bbb.foo.com ccc.foo.com  <--- Allow 됨
  Allow from ddd.com.com


2. ProFTPd Order allow,deny

Order directive

- Syntax: Order [ Order allow,deny|deny,allow]
- Default : Order allow,deny
- Context : <Limit>
- Module  : mod_core
- Compatibility : 0.99.0pl6 and later

Allow directive

- Syntax  : Allow [ ["from"] "all"|"none"|host|network[,host|network[,...]]]
- Default : Allow from all
- Context : <Limit>
- Module  : mod_core
- Compatibility : 0.99.0pl6 and later
- List    : 구분 컴마(,)
  A (partial) domain-name
Example: Allow from .proftpd.org   <--- 아파치와 다르게 앞에 점 추가
  A full IP address
Example: Allow from 10.1.2.3       <--- 아파치와 같음
  A partial IP address
Example: Allow from 10.1.          <--- 아파치와 다르게 뒤에 점 추가         
  A network/netmask pair                   <--- 없음
  A network/nnn CIDR specification
Example: Allow from 10.1.0.0/16    <--- 아파치와 같음


ProFTPd 의 Order, Allow, Deny 지시자는 Apache와 비슷한 구문을 갖지만
그 결과는 아주 상이함.

- Order deny,allow   <-- 우선권 deny 둠

  allow 를 평가하기 전에 deny 를 먼저 평가하고 결정해 버림(overrid 하지 않음)
  그리고 allow 를 평가하고(같은 것이 있으면 deny 가 우선), 나머지
  매치되지 않은 모든 호스트는 deny 됨(아파치와 서로 반대임)

- Order allow,deny   <-- 우선권을 allow 둠

  deny 를 평가하기 전에 allow 를 먼저 평가하고 결정해 버림(overrid 하지 않음)
  그리고 deny 를 평가하고(같은 것이 있으면 allow 가 우선), 나머지
  매치되지 않은 모든 호스트는 allow 됨(아파치와 서로 반대임)

즉 같은 호스트가 allow 와 deny 에 둘다 있을 경우 그 우선권은
Order 지시자에서 설정한 앞부분의 keyword 에 따름.

  Order deny,allow
  Deny from 192.168.0.1
  Allow from 192.168.0.

  deny 가 우선이므로 192.168.0.1 은 deny 됨.(Override 되지 않음)
  또한 다음과 같이 Order 순서를 그대로 두고, 위치만 바꾸어도 동일함.

  Order deny,allow
  Allow from 192.168.0.
  Deny from 192.168.0.1

*중요)
ProFTPd 는 Apache 와 같이 Order 의 순서대로 Override 되지 않고,
Order 순서에 의해서 먼저 접근을 결정해 버림.

ex1) 특정 호스트만 허용함

  <Limit LOGIN>
   Order allow,deny
   Allow from 192.168.0.100,192.168.1.
   Deny from all       <--- all 은 매치되지 않은 나머지를 의미함.
  </Limit>

  192.168.0.100 192.168.1.0/24 만 허용하고 나머지는 모두 접속을 금지함.
  즉 특정 호스트만 허용(Allow) 하기 때문에 Order allow,deny 순으로
  설정하여 우선권을 allow 가 갖도록함.

ex2) 특정 호스트만 금지함

  <Limit LOGIN>
   Order deny,allow
   Deny from 192.168.0.100,192.168.1.
   Allow from all       <--- all 은 매치되지 않은 너머지를 의미함.
  </Limit>

  ex1) 과 서로 반대임

ex3) 부분과 전체

  <Limit LOGIN>
   Order allow,deny
   Allow from 128.44.26.,128.44.26.
   Allow from myhost.mydomain.edu,.trusted-domain.org
   Deny from all
  </Limit>

  ProFTPd 는 Override 되지 않기 때문에 제일 마지막에 Deny from all 설정이
  온다고 하더라고 먼저 설정한 호스트(ex 128.44.26.1)는 Allow 되고,
  상위 설정에서 포함되지 않은 나머지 호스트는 제일 마지막에 모두 Deny 됨

ex3) 우선권

  <Limit LOGIN>
   Order deny,allow
   Allow from 192.168.0.
   Deny from 192.168.0.152
   Deny from all            <--- all 은 매치되지 않은 너머지를 의미함.
  </Limit>

  192.168.0.152 호스트는 앞부분 'Allow from 192.168.0.*'에 포함되지만
  Order 순서가 deny 가 우선이므로 결국 이 호스트는 deny 됨.
  즉 같은 호스트가 allow 와 deny 에 둘다 있을 경우 그 우선권은
  Order 지시자에서 설정한 앞부분의 keyword 에 따름.

  <Limit LOGIN>
   Order deny,allow
   Deny from 192.168.0.152
   Allow from 192.168.0.    <--- override 되지 않음
   Deny from all            <--- all 은 매치되지 않은 너머지를 의미함.
  </Limit>

  위의 설정도 같은 동일한 설정임.


3. 비교

1) 설정방향

- Apache  : Order 순서에 의해서 순차적으로 override 됨.
            매치되지 않은 나머지 호스트는 Order 의 뒤쪽 keyword 에 따름
- ProFTPd : Order 순서에 의해서 순차적으로 먼저 결정함.
            매치되지 않은 나머지 호스트는 Order 의 앞쪽 keyword 에 따름

2) override 비교

- Apache  : override 됨(뒤에 온 놈이 장땡)
- ProFTPd : override 되지 않음(먼저 온 놈(?)이 장땡)

3) 기본 접근정책 비교

- Apache  : 전체 --> 부분으로 override
- ProFTPd : 부분 먼저 설정 --> 나머지 결정

4) 리스트 나열 비교

- Apache  : 빈공백(' ')으로 구분, 여러줄 일 경우 `\'와 중복 지시자 모두 가능
Allow from 1.2.3.4 1.2.3.5 \
1.2.3.6 1.2.3.7
Allow from 10.10.10.1

- ProFTPd : 컴마(,)로 구분하고 여러줄일 경우는 중복 지시자만 가능
Allow from 1.2.3.4,1.2.3.5,1.2.3.6,1.2.3.7
Allow from 10.10.10.1

5) Partial IP 주소 비교

- Apache  : 192.168.0 192.168.1    <-- 뒤에 점이 없음
- ProFTPd : 192.168.0.,192.168.1.  <-- 뒤에 점이 있음

6) Partial domain-name 비교

- Apache  : foo.com bar.com        <-- 앞에 점이 없음
- ProFTPd : .foo.com,.bar.com      <-- 앞에 점이 있음


4. 정리

1) 설정 방향

  - Apache
   Order 순서에 의해서 전체를 먼저 설정하고 나머지 부분을 Override 함

  - ProFTPd
   Order 순서에 의해서 부분을 먼저 결정하고 나머지 전체를 설정한

  * 서로 반대임

2) 특정 호스트만 허용할 경우 : 기본 정책이 deny 임

  - Apache

  Order Deny,Allow
  Deny from all
  Allow from 192.168.0 192.168.1.111

  - ProFTPd

  Order allow,deny
  Allow from 192.168.0.,192.168.1.111
  Deny from all  <-- 나머지를 의미함

3) 특정 호스트만 막을 경우 : 기본 정책이 allow 임

  - Apache

  Order Allow,Deny
  Allow from all
  Deny from 192.168.0 192.168.1.111

  - ProFTPd

  Order deny,allow
  Deny from 192.168.0.,192.168.1.111
  Allow from all  <-- 나머지를 의미함


EOF


From :http://www.linuxchannel.net/docs/order-apache-vs-proftpd.txt

more..

2006/09/11 10:34 2006/09/11 10:34
이 글에는 트랙백을 보낼 수 없습니다
웅쓰:웅자의 상상플러스
웅자의 상상플러스
전체 (379)
게임 (5)
영화 (2)
기타 (23)
맛집 (5)
영어 (2)
대수학 (3)
형태소 (5)
Hacking (9)
Linux (112)
HTML (48)
Application_developing (48)
Web_developing (102)
Window (11)
«   2024/11   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
  1. 2016/01 (1)
  2. 2015/12 (3)
  3. 2015/10 (3)
  4. 2015/03 (2)
  5. 2015/01 (4)