웹에서  .php 가 아니라 .abc 로 바꾸는 방법이 있는줄 알았는데,

 

일부 인코딩된 핵심 라이브러리에서 .php , jsp, asp 확장자를 사용하므로 임의로 변경하실 수 없습니다.

 

따라서 소스 자체를 수정하는 것이 좋다.

 

a.php이면,  소스를 a.abc로 수정하고.

 

    AddType application/x-httpd-php .abc

 

 

이런식으로 수정할 것.

 

 

 

Posted by '김용환'
,

apache 문제.

web 2007. 11. 29. 00:18

 

 

 [Wed Nov 28 15:00:37 2007] [error] (28)No space left on device: mod_security: Could not create modsec_auditlog_lock
[Wed Nov 28 15:02:21 2007] [error] (28)No space left on device: mod_security: Could not create modsec_auditlog_lock
[Wed Nov 28 15:02:21 2007] [error] (28)No space left on device: mod_security: Could not create modsec_auditlog_lock

 

=>

 

 

 

ipcs | perl -ane '`ipcrm -s $F[1]` if $F[2] == "apache" and $F[1] =~ /\d+/ and $F[1] != 0'

 

 

 

Posted by '김용환'
,

아파치 튜닝
출처 : 불분명(통지바람)

1. 웹 페이지 로딩시간 확인
#time -pa lynx -source http://www.gwise.com > /dev/null
real 0.74
user 0.16
sys 0.09
-------------
실제 접속시간 : 0.74-(0.16+0.09)=0.49초

2. 아파치 벤치 마킹
#man ab 사용법 보기
-n requests 요청을 수행할 개수
-c concurrency 요청을 만들 개수로 동시 사용자 개념으로 이해하면 되겠다.
-v verbosity 얼마나 자세한 정보를 화면에 출력해 줄 것인지 결정
-w HTML 문서형식으로 테이블로 만들어 결과를 화면에 출력
-k HTTP 프로토콜의 지속연결 (KeepAlive) 기능을 사용

#./ab -n 100 -c 10 http://www.gwise.com:80/
10 명의 유저가 동시에 http://www.gwise.com/index.html 을 요청하는 것을 모의 실험.
각각의 시뮬레이트 유저는 요청을 10 번씩 하게 됩니다

# ab -n 1500 -c 50 http://www.apache.kr.net:80/
요청을 30 x 50 (50 명의 사용자가, 각각 30 번의 요청)

Requests per second: 80.48
초당 80.48개를 요청 했음.

'MaxRequestsPerChild’ 는 메모리 누수현상(?) 등이 발생하지 않는다면 가능한 이 값을 높게 설정하시고요(파라미터의 값을 0 으로 설정해 무한대로 하실수도 있습니다) StartServers’ 는 프로세스가 active 되어 있는 경우가 적을 경우 값을 낮게 설정하시고, 접속량이 아주 많을 경우는 MaxClients 에 가깝게 조절하시기 바라며, MaxSpareServers 를 MaxClients 와 같게 설정합니다. MaxClients 는 너무 낮게 설정하지 않도록 주의하시기 바라며, 그렇다고 또 너무 크게 잡으셔도 안됩니다


3. 웹 서버 삽질 막기
BrowserMatch "WebZip" go_out
BrowserMatch "Teleport" go_out
BrowserMatch "GetRight" go_out

 

....
Deny from env=go_out


4. 아파치 튜닝
일반 서버에서는 다른것은 그냥 Default 값으로 둔다.
(대형 서버의 경우 말고는 특히 쓸 일어 없을 것이다.)

증가 시킬 경우 배수로 한다. 꼭 이렇게 해야 한다가 아니라
이렇게 하면 좋다.

Timeout 300
클라이언트의 요청에 의해서 Server와 연결 되었을때
클라이언트와 서버간의 아무런 메시지가 발생하지 않았을때
오류로 처리하는 시간
네트워크 속도가 나쁠수록 수치값을 높게 한다.

KeepAlive on
지속적인 접속, 즉 서버 연결에 대하여 한번 이상의 요청을 허용 여부.

MaxKeepAliveRequests 100
클라이언트가 접속된 시간동안 아파치 서버에 요청할 수 있는 처리 process 개수

StartServers 5 X ? =20 -> 초반에 뜰 process 그 이상 그이하의 의미도 없다.
MinSpareServers 5 X ? =20 -> Spare 프로세스가 이것 이하 일때 끌어 올려 준다.
MaxSpareServers 10 X ? =40 -> Spare 프로세스가 이것 이상 일때 진정(?)시켜 준다.
말 그대로 Spare.... 언제 있을지 모를 요청에 대해서 컴퓨터 스스로가
조절해 준다.

MaxClients 150
클라이언트들이 동시에 최대로 접속했을때 가능한 최대 서버이 수를 지정.
Ulimit -a ~~~ max process...이 수치 이상 증가 못함.
httpd.h
HARD_SERVER_LIMIT=250 조정해서 다시 컴파일 가능

MaxClient 150 -> 동시에 떠 있을수 있는 최대 process
더 많은 수를 원할시 httpd.h 소스 파일의
HARD_SERVER_LIMIT 값을 수정 한 다음 다시 컴파일 해야 한다.

#ulimit -a
core file size (blocks) 0
data seg size (kbytes) unlimited
file size (blocks) unlimited
max memory size (kbytes) unlimited
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 2048
pipe size (512 bytes) 8
open files 1024
virtual memory (kbytes) 2105343
-----------------------
위의 max user processes 의 수를 초과 할 수 없다.

MaxRequestPerChild 100
한 프로세스가 몇 번의 서비스를 하고 소멸될 것인지 정한다.
M$계열에서는 별 의미가 없으므로 0을 한다.
하지만 Unix 계열은 0을 사용하지 않는 것이 좋다.

가장 중요한 것은Timeout 설정입니다. 위에서 keep-alive 를 설정해 놓은
경우, 하나의 connection에서 계속해서 다음 request를 처리할 수 있기 때문에 효율적
이라고 하지만, 실제로는 그렇지 않습니다. keep-alive 를 허용하고 그 timeout을
5초로만 설정해도, 하나의 request를 처리한 후 적어도 5초동안은 그 httpd가 다른
작업을 하지 못하고 다음 request를 기다리게 됩니다.

보통 웹브라우저들은 서버로 동시에 4개의 connection을 만들게 됩니다. 한 페이지를
보는데 이미지 등등 해서 보통 4개의 connection을 만드는 것은 기본이죠. 이렇게 되면
httpd가 100개 떠 있다고 해도, 실제로는 동시에 25명의 방문자밖에 처리하지 못합니다.

그리고 keep-alive timeout이 5초인 경우, 한 명의 방문자를 처리한 후 적어도 5초동안은
계속해서 기다리면서 httpd가 놀게 됩니다.(그렇다고 해서 httpd의 수를 늘여주면 앞의
문제 때문에 load가 몰릴 때 순간적으로 부하가 지나치게 많이 걸리게 됩니다. 어떤
request는 수초가 지난 후 답을 받는 등 quality of service가 많이 떨어지죠.)

결국 한 명의 방문자를 처리하는데 4개의 httpd가 5초동안 작업한다는 뜻이고, 100개의
httpd를 띄워봐야 1초에 5명의 방문자밖에 처리하지 못하는 셈입니다. ( 1 명 / 5 sec /
4 httpd = 5 / 1 sec / 100 httpd )

그래서 검색엔진 서비스 등 traffic이 많은 사이트에서는 keep-alive 옵션을 반드시 꺼
놓게 됩니다. 그리고 connection timeout도 상당히 짧게 설정해 놓죠. 4~5초 이내로 말입니다

http://www.apache.org/docs/misc/perf-tuning.html
web performance tunning - 오렐리

그렇지만 명심할 점이 있습니다. 웹사이트의 성능 개선을 위해서는 커널에서만
손대주는 것이 아니라 OS, 네트웍, 프로그래밍 등 다양한 조건을 같이 고려해야
한다는 것입니다. 또한 하드웨어 성능을 고려하지 않은채 무작정 바꾸면 문제가
생긴다는 것입니다. 또한 일반적으로 정적인 html서비스는 문제가 안되지만 성능의
병목지점이 생기는 곳은 네트웍이 아니라면 cgi일 경우가 많습니다. 아파치에
들어있는 ab, 유닉스의 time, ping, netstat 등 다양한 명령어들을 이용해서 항상
시스템의 상태를 모니터링해보고 속도를 재어 보아야 합니다. 또한 아무리 튜닝을
잘해도 웹페이지에 이미지를 엄청나게 넣어둔다면 헛일하는것이지요. 저도 잘
모르면서 어설크게 오라클 튜닝을 한다고 했더니 cpu 4개, 메모리 2G인 시스템에서
오히려 일반PC보다 오라클이 더 느려지더군요. 잘 모르는 경우에는 기본값을 사용하는
것이 더 나을때도 있지요. 아래 예에서 keepalive 옵션은 대형 사이트같은 경우에는
off로 해 놓는 것이 더 나은 경우도 많이 있습니다. 빨리 처리하고 연결을 빨리빨리
끊어주는 것이 아무일도 하지 않은채 그냥 프로세스를 띄워놓고 놀리는 것보다는
낫지요.

 


아파치 웹 서버 튜닝
문태준(taejun at tunelinux.pe.kr http://tunelinux.pe.kr)

아파치 웹 서버의 튜닝은 간략하게 두 부분으로 나눌 수 있다. 첫 번째는 소스코드에
하드코딩 되어 있는 제한 값을 조정하는 것이고, 두 번째는 환경설정 파일의 각 제한
값들을 수정하는 것이다.

1) 소스레벨
httpd.h 파일에 리눅스의 경우 HARD_SERVER_LIMIT 값이 256으로 기본 설정되어
있으며, 이 값은 서버가 수용할 수 있는 최대 접속을 의미한다. 이 값을 1280으로
설정한다.

2) 환경설정 파일
가. KeepAliveTimeout
클라이언트가 서버로 접속을 했을 경우 하나의 웹 서버 프로세스가 해당 웹 페이지의
여러 개체들의 전송을 새로운 프로세스를 생성하지 않고 지속적으로 접속을 유지하며
담당하며, 이 클라이언트의 요청에 대한 타임아웃에 대한 값이다. 기본 15초에서
30초로 증가.
나. MaxKeepAliveRequests
웹 서버 프로세스가 지속적으로 접속을 유지하면서 처리할 수 있는 요청 개수이다.
100으로 설정되어 있으며, 10000으로 증가.
다. StartServer, Min/MaxSpareServer
기본 설정은 5, 5, 10정도이며, 웹 서버가 Standalone 방식일 경우 새로운 접속
요청을 받으면 기존의 Spare Child Process를 포크하여 새로운 Child Process를
만들어내므로 기본적으로 Spare Process가 많을수록 폭주에 빨리 대처할 수 있다.
StartServer 20, MinSpareServer 20, MaxSpareServer 40으로 증가.
라. MaxRequestsPerChild
웹 서버 프로세스가 일정 횟수의 클라이언트 요청을 처리하고 종료되는 수치이며,
1000으로 증가.
마. MaxClients
동시에 실행될 수 있는 최대 프로세스 수를 제한하는 것이며, 기본 256으로 설정되어
있다. 이를 512까지 증가.
바. 로그파일 생성
이용자가 접속할 때마다 기록되는 access_log 파일의 경우 한번 접속당 약 85바이트가
증가하며, 접속량이 많을 경우 이 파일의 크기는 실제로 엄청나다. 이럴 경우
접속때마다 로그파일을 액세스하는데 상당한 시간과 부하가 걸리므로 로그 파일을
일정시간마다 초기화하여 항상 경량화 시켜 줄 필요가 있다. 아파치에서 제공하는
rotatelog를 이용.


ㅇ커널 소프트 레벨 튜닝

커널이 제공하는 파라메터값을 /proc 파일 시스템을 이용해서 부팅이 완료된 시점후에
변경한다. 여기서는 주로 파일시스템과 네트웍 자원에 관련된 내용에 대해서
튜닝한다.

1) 파일 시스템 관련
- 리눅스 커널이 할당할 수 있는 파일 개수의 최대값 : 4096 -> 32768
- 리눅스 커널이 할당할 수 있는 inode 개수의 최대값 : 16384 -> 65536
- root 사용자에 대해 할당할 수 있는 파일 개수의 최대값 : 1024 -> 32768
- 하나의 프로세스가 오픈할 수 있는 파일의 개수 : 256 -> 512

2) 네트웍 자원 관련
- TCP 가 Keep Alive 메시지를 보내는 시간 간격 : 7200 -> 1200
- 소켓이 항상 CLOSE되기 전에 마지막 FIN 을 기다리는 시간 : 180 -> 30
- 하나의 TCP 접속 요청에 대해 응답을 재전송하는 횟수 : 7 -> 2

이렇게 설정되는 값들은 시스템이 부팅되면서 스크립트를 통해 설정되어야 되기
때문에 /etc/rc.d/rc.local 파일의 마지막 부분에 정의된다.

ㅇ 커널 하드 레벨 튜닝

커널 소스를 직접 수정하여 제한값을 조정한다. 이를 위해서는 커널 컴파일이
필수적이며, 조심스런 접근이 필요하다.

- 파일 오픈 개수
- 처리할 수 있는 프로세스 개수

**참고

1. 아파치 웹 서버 튜닝
- apache/src/include/httpd.h:
HARD_SERVER_LIMIT 256 -> 1280
- apache/conf/httpd.conf:
MaxKeepAliveRequests 100 -> 10000
KeepAliveTimeout 15 -> 30
MinSpareServers 5 -> 20
MaxSpareServers 10 -> 40
StartServers 5 -> 20
MaxClients 256 -> 1024

2. 커널 소프트 레벨 튜닝
- ulimit -n 32768
- /proc/sys/fs/file-max: 4096 -> 32768
- /proc/sys/fs/inode-max: 16384 -> 65536
- /proc/sys/net/ipv4/tcp_keepalive_time: 7200 -> 1200
- /proc/sys/net/ipv4/tcp_fin_timeout: 180 -> 30
- /proc/sys/net/ipv4/tcp_sack: 1 -> 0
- /proc/sys/net/ipv4/tcp_timestamps: 1 -> 0
- /proc/sys/net/ipv4/tcp_syncookies: 0 -> 1
- /proc/sys/net/ipv4/tcp_retries1: 7 -> 2
- /proc/sys/net/ipv4/tcp_max_syn_backlog: 128 -> 8192
- /proc/sys/net/ipv4/tcp_window_scaling: 1-> 0

3. 커널 하드 레벨 튜닝
- /usr/src/linux/include/linux/fs.h:
NR_FILE 4096 -> 32768
INR_OPEN 1024 -> 32767
- /usr/src/linux/include/linux/tasks.h:
NR_TASKS 2560 -> 3192
MAX_TASKS_PER_USER 2048 -> 3192
- /usr/src/linux/include/linux/limits.h:
NR_OPEN 1024 -> 32767
- /usr/src/linux/include/net/tcp.h:
TCP_TIMEWAIT_LEN (60*HZ) -> (15*HZ) 

Posted by '김용환'
,

Lucy alpha cms에서 나던 Exception 있죠?

 

IOException while loading persisted sessions: java.io.EOFException

  

톰캣은 persist session을 저장할 수 있답니다.. , 종료나 restart 될 때에 session정보를 serialize 하게 저장합니다.

Shutdown할 때, session create되고, start할 때는 제거된다고 하네요.

serialize한게 저장한 것을 못읽어 Exception이 나왔습니다.

 

해결 방법은 session.ser을 지운면 된다고 합니다. 어제 밤에 확인을 했었는데. Ser 확장자를 지웠더니 해당 Exception은 안나더군요. 참고하세요.^^

 


ERROR [main] (StandardManager.java:372) - IOException while loading persisted sessions: java.io.EOFException
java.io.EOFException
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2232)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2698)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:750)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:268)
at org.apache.catalina.util.CustomObjectInputStream.<init>(CustomObjectInputStream.java:57)
at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:361)
at org.apache.catalina.session.StandardManager.load(StandardManager.java:320)
at org.apache.catalina.session.StandardManager.start(StandardManager.java:636)
at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:431)
at org.apache.catalina.startup.ContextConfig.managerConfig(ContextConfig.java:391)
at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1042)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:255)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4076)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:910)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:873)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at org.apache.catalina.core.StandardService.start(StandardService.java:450)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:680)
at org.apache.catalina.startup.Catalina.start(Catalina.java:536)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)


ERROR [main] (StandardManager.java:638) - Exception loading sessions from persistent storage
java.io.EOFException
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2232)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2698)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:750)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:268)
at org.apache.catalina.util.CustomObjectInputStream.<init>(CustomObjectInputStream.java:57)
at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:361)
at org.apache.catalina.session.StandardManager.load(StandardManager.java:320)
at org.apache.catalina.session.StandardManager.start(StandardManager.java:636)
at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:431)
at org.apache.catalina.startup.ContextConfig.managerConfig(ContextConfig.java:391)
at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1042)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:255)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4076)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:910)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:873)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at org.apache.catalina.core.StandardService.start(StandardService.java:450)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:680)
at org.apache.catalina.startup.Catalina.start(Catalina.java:536)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

 

 

참고자료

http://72.14.235.104/search?q=cache:Ew7B0Xe8VA0J:thiamteck.blogspot.com/2006/07/session-persistent-in-tomcat.html+session.ser&hl=ko&ct=clnk&cd=11&gl=kr

http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-12724.html

 

Posted by '김용환'
,

httpclient 3.0 테스트 코드

web 2007. 10. 24. 13:15

import org.apache.commons.httpclient.*;

import org.apache.commons.httpclient.methods.GetMethod;
import org.apache.commons.httpclient.cookie.*;

public class Test {

    public Test() {
    }

   public void test(){
       
       String HOST = "i61959";

        HttpState initialState = new HttpState();
        String domain = "monitor.google.com";
         String path = "/";
        Cookie mycookie = new Cookie(domain, "JSESSIONID", "E52715F1C816B6CF556486A6", path, null, false);
        initialState.addCookie(mycookie);

 

        mycookie = new Cookie(domain, "kac", "1", path, null, false);
        initialState.addCookie(mycookie);


        mycookie = new Cookie(domain, "cnet_7", "1", path, null, false);
        initialState.addCookie(mycookie);

 

        HttpClient client = new HttpClient();
        //HttpMethod method = new GetMethod("http://i61974.google.com:80/common/monitor.gle?farm=vcomp");
        HttpMethod method = new GetMethod("http://m.google.com/anitor/requestbridge.gle?http://"+ HOST +".google.com:8080/common/monitor.gle?m=serverStatus");
        int statusCode = 0;
 client.setState(initialState);
 client.getParams().setCookiePolicy(CookiePolicy.RFC_2109);
        try {
            statusCode = client.executeMethod(method);
           
            byte[] responseBody = method.getResponseBody();
            System.out.println(new String(responseBody));

     // Get all the cookies
     Cookie[] cookies = client.getState().getCookies();
     // Display the cookies
     System.out.println("Present cookies: ");
     for (int i = 0; i < cookies.length; i++) {
  System.out.println(" - " + cookies[i].toExternalForm());
     }

        } catch (Exception e) {
            System.out.println("IOException");
            e.printStackTrace();
        }finally{
            method.releaseConnection();
        }      
    }

    public static void main(String[] args) {
              new Test().test();
    }
}

 

컴파일

 javac -classpath http.jar:.:logging.jar:codec.jar Test.java

//아파치 로깅과 codec 패키지에 대한 dependency가 있다.

 

 

실행

java -classpath http.jar:.:logging.jar:codec.jar Test

Posted by '김용환'
,

보통 DDos 공격은 특정 시간대에 몰려서 하나 혹은 여러 ip에서 엄청나게 많은 Request를 보낸다는 것이다.

 

그런데, 서버 한대가 장애가 있어 확인해 보니..

 

특정 IP가 한시간에 한번씩 분당 500~600 Request를 전달하는 것이 아닌가.

 

즉 초당 5회에서 6회씩 연속으로 전달하고 있었다.

그리고, 1초에 5,6회씩이 아니라 10초내, 또는 20초내에 30~50회에 나눠 보내는 특성을 타고 있었다.

 

 

그래서 10초당 block수를 높여서 하도록 처리했다..

Posted by '김용환'
,

 

아파치 로그를 통해서 분당 IP를 뽑아내어 10개이상 중복될 경우는 출력을 한다.

abusing PC의 ip를 얻어올 수있다.

 

 

 
#!/usr/bin/perl
#cat access_https.071016 | grep 17:31 | awk '{print $1}' | sort 
#awk '{pre; cur=$1; if(pre==0) { count=1;pre=$1;} else if (cur==pre) {count++;} else { print pre,"-",count ; pre = $1; count=
1 }  } END { print pre,"-",count} 

# count to expect abusing
my $abuseCount= 10;
# every minute
my $minute = 1;

my $filename;
my $time;
my $until;

if($#ARGV < 0) {
    printUsage();
} else {
    while($#ARGV >= 0) {
        $filename = shift(@ARGV);
        $time = shift(@ARGV);
        $minute = shift(@ARGV);
    }
}

sub printUsage() {
    print "Usage : getReqCount.pl filename time(hh:mm) until(until minute)\n";
    print "ex) getReqCount.pl access_https.log 1700 1\n";
    print "\n";
}

#print "filename : $filename\n";
#print "time : $time\n";
#print "until : $until\n";

$digits = $time;
@timeinfo = $digits =~ /(\d\d)/g;

    for ($i = 0; $i < $minute ; $i++) {
        $i = @timeinfo[1] + $i;
        if ($i < 10) {
            $i = "0".$i;
        }
        print "@timeinfo[0]:$i\n";
        print `grep "$m:$i" $filename | grep -v 127.0.0.1 | awk '{print \$1}' | sort | awk '{pre; cur=\$1; if(pre==0) { count
=1;pre=\$1;} else if (cur==pre) {count++;} else { if (count > $abuseCount) { print pre,"-",count } ; pre = \$1; count=1 }  } 
END { if (count > $abuseCount) { print pre,"-",count} }'`
        #print `grep "$m:$i" $filename | grep -v 127.0.0.1 | awk '{print \$1}' | sort | awk '{pre; cur=\$1; if(pre==0) { coun
t=1;pre=\$1;} else if (cur==pre) {count++;} else { print pre,"-",count ; pre = \$1; count=1 }  } END { print pre,"-",count}'`
        #print `grep "$m:$i" $filename | awk '{print \$1}' | sort `
    }

'web' 카테고리의 다른 글

httpclient 3.0 테스트 코드  (0) 2007.10.24
DDos 공격의 또 다른 패턴을 잡기.  (0) 2007.10.21
Apache request 갯수 파악하기  (0) 2007.10.19
L4 이야기  (0) 2007.09.29
L4 사용여부.  (0) 2007.09.29
Posted by '김용환'
,

 

 

 

 

 

로그파일(file)을 읽어서 분단위로 특정시간(time)부터 몇시간(until)까지 읽어 화면에 찍는다. 이를 엑셀로 확인하여 아파치 리쿼스트 갯수를 확인할 수 있다.

#!/usr/bin/perl

my $filename;
my $time;
my $until;

if($#ARGV < 0) {
    printUsage();
} else {
    while($#ARGV >= 0) {
        $filename = shift(@ARGV);
        $time = shift(@ARGV);
        $until = shift(@ARGV);
    }
}

sub printUsage() {
    print "Usage : getReqCount.pl filename time(hh:mm) until(until hour)\n";
    print "ex) getReqCount.pl access_https.log 1700 2\n";
    print "\n";
}

#print "filename : $filename\n";
#print "time : $time\n";
#print "until : $until\n";

$digits = $time;
@timeinfo = $digits =~ /(\d\d)/g;

for ($j = 0 ; $j < $until ; $j++) {
    $m = @timeinfo[0] + $j;
    for ($i = 0; $i < 60 ; $i++) {
        $i = @timeinfo[1] + $i;
        if ($i < 10) {
            $i = "0".$i;
        }
        print "$m:$i\t";
        print `grep "$m:$i" $filename | wc -l`
    }
}

'web' 카테고리의 다른 글

DDos 공격의 또 다른 패턴을 잡기.  (0) 2007.10.21
Apache request중 abusing IP 확인하기  (0) 2007.10.19
L4 이야기  (0) 2007.09.29
L4 사용여부.  (0) 2007.09.29
L7 스위치 개념 및 동작원리  (0) 2007.09.29
Posted by '김용환'
,

L4 이야기

web 2007. 9. 29. 06:46

회사에서, 인터넷에서 배운 정도를 바탕으로 정리해서 써 보기로 한다.

틀리면 갈켜도~~~ (정말 나는 웹을 모른다..ㅜㅜ)

 

 

L4, 이것은 OSI 7계층의 4번째 Layer를 의미한다. 즉 TCP, UDP 프로토콜이 있는 전송계층을 의미한다. 그렇게 때문에 IP, port 정보를 확인하고, 스위칭을 한다.

마찬가지로 L1은 물리적레벌, L2는 layer2 이더넷 부분만 보고 패킷흐름을 결정해 주고, L3는 IP 레이어, 라우팅을 결정한다. 그러면 L7은 패킷 내용을 파싱하는 것이렸다. L5, L6 스위치도 있단다. 근데, 몰라서 패쓰~

 

실제로는 L4와 L7 스위치가 가장 많이 활용되고 쓰이고 있다.

 

 

잘 보면 알겠지만, 방화벽 클러스터링이 L4 스위치와 같이 사용되고 있다.

 

외부망 - L4스위치 - 방화벽 - L4 스위치 - IDS

 

in과 out이 하나인 방화벽이 하는 일은 데이터가 들어올 수 있는 정보인지 아닌지를 걸러낸다. 스위치는 룰에 따라 어디로 가야할 지 판단해 준다. 그래서 L4 스위치의 경우는 로드 밸런싱이나 TCP 세션관리에 치중하고 있다.

보통 나와 관련있는 서버는 L4의 맥스 커넥션을 150정도 잡는다고 한다. 그리고, 세션를 관리하고 있으므로, 특정 서버에서 이 요청을 하고 있구나 판단하고 패킷을 잘 줄 수 있다.

 

방화벽은 다양한 기능이 많고, 비싸다고 한다..

 

참고로 방화벽의 중점사항은 단위시간당 필터링할 수 있는 패킷의 갯수, L4는 초당 스위칭 가능한 세션수, 라우터는 라이팅 가능한 패킷수라 한다.

 

 

 

'web' 카테고리의 다른 글

Apache request중 abusing IP 확인하기  (0) 2007.10.19
Apache request 갯수 파악하기  (0) 2007.10.19
L4 사용여부.  (0) 2007.09.29
L7 스위치 개념 및 동작원리  (0) 2007.09.29
L4스위치와 L7스위치의 차이점  (0) 2007.09.29
Posted by '김용환'
,

L4 사용여부.

web 2007. 9. 29. 06:27

 

 

L4가 바인딩되어 있는지 아닌지 확인하는 것중의 하나...

머가 있는지 잘 모르지만. lo:0 (루프백에 먼가 추가된 녀석이 있고, inet address가 있다면, L4일 수도 있다. 시스템 관리자에게 물어본다.)

우리 회사는 이걸로 L4 바인딩 여부를 알수 있다.

 

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:80270471 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80270471 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2779187157 (2.5 GiB)  TX bytes:2779187157 (2.5 GiB)

lo:0      Link encap:Local Loopback 
          inet addr:2.1.1.6  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:16436  Metric:1 

'web' 카테고리의 다른 글

Apache request 갯수 파악하기  (0) 2007.10.19
L4 이야기  (0) 2007.09.29
L7 스위치 개념 및 동작원리  (0) 2007.09.29
L4스위치와 L7스위치의 차이점  (0) 2007.09.29
자바 - include 관련  (1) 2007.09.28
Posted by '김용환'
,