| 무료 Loading image 제작 사이트 (0) | 2008.01.30 |
|---|---|
| Microsoft Windows 7 (0) | 2008.01.28 |
| Java Edition 구분 (0) | 2008.01.25 |
Vista를 구입한지 얼마 되지 않은 사람들 에겐 좋은 소식으로 들리지 않을 듯.
두 번째 코드테스트 버전인 M2를 오는 4월이나 5월중에 발표할 것으로 보이며, M3 버전은 2008년 3/4분기에 나올 전망.
Windows7은 약 3년의 개발 기간을 거쳐 2010년경 공급될 것으로 예정 되어 있었으나, 당초 계획보다 좀 더 시기를 앞당겨 2009년 후반 정식 제품으로 출시될 가능성이 높아졌다고 한다.
새로운 기능은 물론 구체적인 정보 조차 밝혀지지 않은 윈도우 7에 대해 마이크로소프트는 공식적인 언급을 피하고 있는 상태라고...
| PDF Text Online (0) | 2008.01.29 |
|---|---|
| Java Edition 구분 (0) | 2008.01.25 |
| Macworld 2008 Steve Jobs Apple Keynote Highlights (0) | 2008.01.24 |
| Microsoft Windows 7 (0) | 2008.01.28 |
|---|---|
| Macworld 2008 Steve Jobs Apple Keynote Highlights (0) | 2008.01.24 |
| 테라리움 (0) | 2008.01.22 |
| Java Edition 구분 (0) | 2008.01.25 |
|---|---|
| 테라리움 (0) | 2008.01.22 |
| MacBook Air 광고 동영상 (0) | 2008.01.21 |
| Macworld 2008 Steve Jobs Apple Keynote Highlights (0) | 2008.01.24 |
|---|---|
| MacBook Air 광고 동영상 (0) | 2008.01.21 |
| Web Browser 세계시장 점유율 (2007년12월 기준) (0) | 2008.01.21 |
| 테라리움 (0) | 2008.01.22 |
|---|---|
| Web Browser 세계시장 점유율 (2007년12월 기준) (0) | 2008.01.21 |
| 도메인간 쿠키공유 (0) | 2008.01.17 |
| MacBook Air 광고 동영상 (0) | 2008.01.21 |
|---|---|
| 도메인간 쿠키공유 (0) | 2008.01.17 |
| SOA와 웹2.0 개념비교 (0) | 2008.01.17 |
| Web Browser 세계시장 점유율 (2007년12월 기준) (0) | 2008.01.21 |
|---|---|
| SOA와 웹2.0 개념비교 (0) | 2008.01.17 |
| 제어판/관리콘솔 실행명령어 (0) | 2008.01.17 |
웹기반 표준기술인 웹서비스 기술을 활용하여 새로운 비즈니스를 창출한다는 측면에서 SOA는 최근 화두가 되고 있는 웹 2.0과 매우 유사한 특징을 지니고 있다.
마이크로소프트 아키텍쳐 전략 담당관인 John de Vados는 웹 2.0과 SOA의 개념과 주요 특성을 비교하면서 현재 웹 2.0은 소비자
중심 비즈니스 모델을 지원하고, SOA는 기업 중심 모델을 지원하고 있다고 보고 있다. 그리고 미래 비즈니스 세계는 이 둘간의
구분이 모호해지고 연계가 활발해짐에 따라, 궁극적으로 웹 2.0이 글로벌 차원의 SOA를 실현할 수 있을 것으로 전망하고 있다.
|
* 웹 2.0과 SOA간 개념비교 (출처 : SOA Web Service Journal, 2006)
|
| 도메인간 쿠키공유 (0) | 2008.01.17 |
|---|---|
| 제어판/관리콘솔 실행명령어 (0) | 2008.01.17 |
| 로지텍 공중 마우스 MX Air (0) | 2007.12.27 |
제어판/관리콘솔 실행명령어 리스트
< 제어판 바로실행 명령어 >
control 제어판
Access.cpl 내게 필요한 옵션
appwiz.cpl 프로그램 추가/제거
bthprops.cpl 블루투스장치설정
desk.cpl 디스플레이 등록정보
firewall.cpl Windows방화벽
hdwwiz.cpl 새하드웨어추가마법사
inetcpl.cpl 인터넷등록정보
intl.cpl 국가및언어옵션
irprops.cpl 적외선포트 설정
joy.cpl 게임컨트롤러
main.cpl 마우스등록정보
mmsys.cpl 사운드및 오디오장치등록정보
ncpa.cpl 네트워크연결
netsetup.cpl 네트워크설정마법사
nusrmgr.cpl 사용자계정
nwc.cpl 네트워크 게이트웨이
odbccp32.cpl ODBC데이터원본 관리자
powercfg.cpl 전원옵션 등록정보
sysdm.cpl 시스템등록정보
telephon.cpl 전화및모뎀 옵션
timedate.cpl 날짜 및 시간 등록정보
wscui.cpl Windwos보안센터
wuaucpl.cpl 자동업데이트
Sapi.cpl 텍스트 음성 변환설정
control Admintools 관리도구
control Folders 폴더옵션
control Userpasswords 사용자 계정
시스템등록정보 -> (윈도우키 + Pause)
< 관리콘솔 명령어 >
certmgr.msc : 인증서
ciadv.msc : 인덱싱서비스
ntmsmgr.msc : 이동식저장소
ntmsoprq.msc : 이동식저장소 운영자 요청
secpol.msc : 로컬보안정책
wmimgmt.msc : WMI(Windows Management Infrastructure)
compmgmt.msc : 컴퓨터 관리
devmgmt.msc : 장치관리자
diskmgmt.msc : 디스크 관리
dfrg.msc : 디스크 조각모음
eventvwr.msc : 이벤트 뷰어
fsmgmt.msc : 공유폴더
gpedit.msc : 로컬 컴퓨터 정책
lusrmgr.msc : 로컬 사용자 및 그룹
perfmon.msc : 성능모니터뷰
rsop.msc : 정책의 결과와 집합
secpol.msc : 로컬 보안설정
services.msc : 서비스
C:\WINDOWS\system32\Com\comexp.msc : 구성요소서비스
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorcfg.msc : .NET Configuration 1.1
| SOA와 웹2.0 개념비교 (0) | 2008.01.17 |
|---|---|
| 로지텍 공중 마우스 MX Air (0) | 2007.12.27 |
| 차세대 뱅킹서비스 - 농협 X-Bank (0) | 2007.12.16 |
| 제어판/관리콘솔 실행명령어 (0) | 2008.01.17 |
|---|---|
| 차세대 뱅킹서비스 - 농협 X-Bank (0) | 2007.12.16 |
| Adobe Flex 국내 공식사이트 (0) | 2007.12.14 |
| 로지텍 공중 마우스 MX Air (0) | 2007.12.27 |
|---|---|
| Adobe Flex 국내 공식사이트 (0) | 2007.12.14 |
| 쿠빌라이 칸의 유언 (2) | 2007.12.12 |
| 차세대 뱅킹서비스 - 농협 X-Bank (0) | 2007.12.16 |
|---|---|
| 쿠빌라이 칸의 유언 (2) | 2007.12.12 |
| 무료신용정보 조회 (10) | 2007.12.03 |
세상은 넓고, 사람은 많고, 기술은 끝없이 바뀐다.
아무리 어려운 난관에 부딪혀도 반드시 방법이 있음을 믿고,
아무리 하찮은 적이라도 우리와 다른 기술을 가지고 있을지도 모른다는 점을 한시도 잊지 말라.
내가 최고라도 자만하지 말라.
옆을 보고, 앞을 보고, 뒤를 보아라.
산을 넘고, 강을 건너고, 바다를 건너라.
세상을 살되 한 뼘이라도 더 넓게 살고,
사람을 사귀되 한 명이라도 더 사귀며,
기술을 배우되 한 가지라도 더 배워라.
상대가 강하면 너희를 바꾸고,
너희가 강하면 상대를 바꾸어라.
| Adobe Flex 국내 공식사이트 (0) | 2007.12.14 |
|---|---|
| 무료신용정보 조회 (10) | 2007.12.03 |
| SiteCheck (0) | 2007.12.03 |
| 쿠빌라이 칸의 유언 (2) | 2007.12.12 |
|---|---|
| SiteCheck (0) | 2007.12.03 |
| Windows XP 팁 (0) | 2007.11.30 |
| 무료신용정보 조회 (10) | 2007.12.03 |
|---|---|
| Windows XP 팁 (0) | 2007.11.30 |
| Cookie의 보안 취약점에 대해 (0) | 2007.11.26 |
1. 사용자 등록정보
바꾸기
경로 :
HKey_Local_Machine\Software\Microsoft\Windows
NT\CurrentVersion
수정 : [RegisteredOwner] 값 수정, [RegisteredOrganization] 값 수정
2. 휴지통 이름 바꾸기
경로 :
HKey_Classess_Root\Clsid\{645FF040-5081-101B-9f08-00AA002F954E}
수정 : [기본값] 수정, [LocalizedString]의 데이터 뒤에 쉼표
입력
3. 작업 표시줄의 시간 표시
바꾸기
경로 :
HKey_Current_User\Control
Panel\International
수정 : [s1159] 값을
‘낮’으로 수정,
[s2359] 값을 ’밤’으로 수정
4. 인터넷 익스플로러의 제목
표시줄에 문구 넣기
경로 :
HKey_Current_User\Software\Microsoft\Internet
Explorer\Main
수정 : [Window
Title]키의 데이터를 원하는 문자로 수정
5. 인터넷 익스플로러의 툴바에
그림 넣기
경로 :
HKey_Current_User\Software\Microsoft\Internet
Explorer\Toolbar
수정 : [Backbitmap]
값의 데이터에 삽입할 비트맵(bmp) 파일 경로 및 이름 입력
| SiteCheck (0) | 2007.12.03 |
|---|---|
| Cookie의 보안 취약점에 대해 (0) | 2007.11.26 |
| Books MBA (2) | 2007.11.12 |
1. Cookie 개요
Cookie는 사용자가 방문한 웹 사이트에서 추후에 어떤 용도로든 사용하기 위해서 사용자의 하드디스크에 남기는 정보를 의미한다. 예를 들어 사용자가 특정 팝업창에 대해 "더 이상 띄우지 않음", "오늘은 띄우지 않음" 등과 같은 체크 박스를 선택할 경우 다음부터 해당 사이트에 방문할 때 더 이상 그런 팝업창이 나타나지 않게 되는데 이는 Cookie 정보가 사용자의 PC에 저장되어 있기 때문이다. 엄밀히 말하자면 이런 Cookie는 Persistent Cookie라고 불리우며 메모리 공간에 상주하여 브라우저 관련 프로세스가 실행되고 있을 때까지만 유효한 Cookie 정보도 있는데 이를 Non-Persistent Cookie 혹은 Session Cookie라고 부른다.
2. Cookie 종류
Cookie의 종류에는 Persistent Cookie와 Session Cookie(Non-Persistent Cookie)가 있다. 이 두 개를 비교하면 다음과 같다.
비교 항목 Persistent Cookie Session Cookie 저장 위치 디스크매체(text 파일) 브라우저가 사용하는 메모리 공간 초기 접속 시 전송 여부 초기 접속 시 전송 서버로부터의 Set-Cookie로 할당되어야 메모리 공간에 나타나므로 초기 접속 시 전송되지 않음 Cookie의 만료 시기 Cookie 항목에 대해 설정된 expiration date가 지난 경우, 사용자가 Cookie를 삭제한 경우 사용자가 브라우저를 종료한 경우, 서버가 Set-Cookie로 Cookie 항목의 내용을 클리어한 경우 주요 용도 사용자가 사이트 재방문 시 속성 (팝업창 제한, ID, Password 등)을 기억하기 위함 사용자가 사이트 접속 시 인증 정보를 유지하기 위함
3. Cookie 동작 원리
클라이언트가 웹서버에 접속할 때 Cookie가 어떤 식으로 교환되는지 살펴보기로 하자.
우
선 클라이언트가 해당 서버에 대한 Persistent Cookie를 저장하고 있다면 저장하고 있는 Cookie 정보가
만료되었는지 여부를 확인하여 만료되지 않았다면 해당 Cookie 정보를 보낸다. 이 정보는 Request Header에 포함되어
전달된다.
클라이언트는 해당 Cookie 정보를 받아들이거나 무시할 수 있지만 특별한 브라우저 설정을 하지 않았고 Set-Cookie가 규약을 만족한다면 받아들이는 것이 기본이다. 다음에 해당 웹서버로 클라이언트가 요청을 하게 될 경우 앞서 보냈던 쿠키 정보에 Set-Cookie에 의해 새로이 추가된 쿠키 정보를 포함하여 보낸다.
여기서 웹서버가 브라우저에 보내는 Set-Cookie를 좀 더 상세히 보자. Set-Cookie는 다음과 같은 정보가 포함될 수 있다.
|
필드 |
설명 |
|
NAME=VALUE |
(Required) 쿠키 변수 이름과 쿠키 변수 값을 지정한다. 앞서 예제의 경우에는 login_id가 NAME, hosik이 VALUE가 된다. |
|
Comment=Comment |
(Optional) Cookie에는 개인 정보가 포함되는 경우가 있다. 따라서 해당 Cookie가 어떤 용도로 사용되는 Cookie인지 사용자에게 알리기 위한 용도로 Comment를 추가한다. 사용자는 Comment 정보로 판단하여 해당 Cookie를 허용할지 않을지 여부를 결정할 수 있다. |
|
Domain=Domain |
(Optional) Cookie 정보가 유효한 도메인을 말한다. 어떤 사이트의 경우에는 하나의 인증 받은 정보를 다른 URL에서도 사용해야 하는 경우가 있다. 예를 들어 www.coconut.co.kr을 통해 인증 받았지만 file.coconut.co.kr이라는 URL에도 같은 정보가 유지되어야 하는 경우이다. 이런 경우 Domain=.coconut.co.kr이라는 정보를 추가로 쓰게 되며 Domain 값으로는 반드시 '.' 문자가 선행되어야 한다. (ex. Domain=file.coconut.co.kr (X), Domain=.coconut.co.kr (O)) |
|
Path=path |
(Optional) 어떤 경로에 해당 Cookie가 적용될지를 의미한다. Path=/ 라고 한다면 모든 경로에 적용되며 Path=/download/ 라고 한다면 /download/ 이하의 경로에 적용된다. |
|
Max-Age=delta-seconds |
(Optional) Cookie의 lifetime을 의미하며 delta-seconds가 경과하면 클라이언트는 Cookie를 버려야 한다. 해당 값은 0 이상으로 셋팅될 수 있으며 0으로 셋팅된 것은 해당 쿠키값이 바로 버려져야 한다는 것을 의미한다. |
|
Secure |
(Optional) 해당 Cookie는 secure channel로 전송되어야만 함을 의미한다. |
|
Version=Version |
(Required ) Version은 10진수의 정수로 표현될 수 있다. Cookie의 버전을 의미하며 Version=1로 표현된다. |
브라우저에 전송된 Set-Cookie가 악의적인 경우에 대처하기 위해 브라우저는 다음과 같은 경우 쿠키 정보를 거부할 수 있다.
- Domain 값이 '.'으로 시작되지 않는 경우
- 요청한 호스트 정보와 Domain의 값이 무관한 경우
- 요청한 호스트가 FQDN(IP 주소 형태가 아님)의 형태를 가질 때 요청한 호스트의 FQDN에서 Domain 값을 제외한 나머지, 즉 호스트명이 '.'을 하나 이상 포함하는 경우
(예를 들면 다음과 같음)
청한 호스트의 FQDN이 www.coconut.co.kr인데 Domain 값이 .co.kr 혹은 .kr인 경우
4. Cookie 파일 저장 위치 및 구조
Cookie(엄밀히 Persistent Cookie) 파일이 저장되는 위치, 그리고 저장 방식은 웹 브라우저 종류와 버전에 따라 상이하다. 예를 들어 Netscape Navigator 4.x 버전은 User Preference 폴더에 cookies.txt라는 파일 하나로 저장하였으며 Opera 4.x 버전은 cookies4.dat라는 파일로서 Opera 디렉토리에 저장한다. 국내에서 가장 많은 유저가 사용하는 인터넷익스플로러의 경우는 도메인마다 파일 하나로서 저장한다. 또한 저장되는 위치는 Windows 버전에 따라 다를 수 있다. 따라서 Cookie 파일을 찾기 위해서는 '파일 찾기'등의 검색 툴을 이용하여 검색어로서 'Cookie'를 입력하여 로컬하드디스크를 확인해보는 것이 쉽다.
이중 윈도우에 저장된 인터넷익스플로러의 Cookie 파일의 예를 보자. 다음은 로컬하드디스크에저장된 hosik@google[1].txt의 내용을 메모장으로 열어 본 경우이다.
|
PREF |
여기서 PREF는 Cookie의 Name이며 ,
ID=e86917dffe2b57c6.. (생략) .. S=R4sPpGRTj7axz2nH 는 Cookie의 Value,
google.com/는 Cookie가 사용되는 Domain과 Path를 의미하며 1536은 해당 Cookie가 Secure하지
않음을 의미한다. 이렇게 Cookie 파일 그 자체로서 내용을 분석하는 것은 까다로운 문제이다. IECookieView라는 툴을
이용하면 다음과 같이 저장된 Cookie 내용들을 쉽게 열람하고 분석할 수 있다.
Persistent Cookie의 경우에는
사용자의 하드디스크에 저장된다. 특히 PC방이나 전산실, 도서관 등과 같은 공용 PC 환경에 저장된 하드디스크에 저장된
Cookie 정보는 쉽게 얻어낼 수 있다. 앞서 언급한 IECookieView 등을 통하여 종종 사용자의 ID, 비밀번호를
얻어내는 그런 직접적인 시도가 아니더라도 사용자의 ID, 비밀번호가 암호화된 형태로 저장되어 있을 때 해당 Cookie 값을
그대로 복사해와서 ID, 비밀번호 인증 절차를 거치지 않고 로그인할 수 있다. 이 경우는 자동로그인을 활성화한 거의 모든
사이트의 경우 ID, 비밀번호와 같은 중요 인증 정보를 Persistent Cookie로서 저장하기에 발생하는 문제이다.
5.1.1 XSS, XST 등의 취약점을 이용
XSS는 Cross Site Scripting의 약자로 CSS로 표기되지 않는 이유는 Cascading Style Sheet와 그 약자가 동일하기 때문에 혼동이 될 수 있어서이다. XST는 HTTP 메소드 중 디버깅을 위한 용도의 TRACE라는 메소드를 이용하는 것으로 Cross Site Tracing으로 XSS에 비해 진보된 공격 기법이다. XSS를 통한 Cookie Theft는 Cookie 옵션을 이용하여 근본적인 차단 방법이 있기에 이런 방법을 구현한 사이트에 대해서는 XST 기법을 사용한다. XSS, XST를 이용하는 경우에는 브라우저 프로세스 실행 중에만 유지되는 Session Cookie와 같은 정보도 얻어낼 수 있다.
XSS 취약성은 클라이언트 레벨에서 의도치 않은 스크립트(자바스크립트)가 실행되도록 하는 것이다. XSS 취약성을 응용한 공격 형태를 몇 가지 제시하면 다음과 같다.
- 게시판에 HTML 태그(<script> 등)를 포함하는 방법
- Flash의 ActionScript를 이용하는 방법
- 웹 서버 취약성을 이용하여 URL에 HTML 태그 추가
`` http://www.victim.com/<script>alert(document.cookie)</script>
- 웹 어플리케이션의 취약성을 이용하여 파라미터에 HTML 태그 추가
```http://www.victim.com/hole.asp?q=<script>alert(document.cookie)</script>
○ XST 취약성을 이용
XSS 취약성을 이용한 Cookie Theft는 매우 위협적이다. 이 방법을 근본적으로 차단할 수 있도록 하기 위한 메커니즘이 있는데 이는 다음달 연재에서 자세히 다루겠다. 이런 메커니즘이 적용된 Cookie의 경우에는 XSS 취약성으로 얻어낼 수 없다. 이 경우 사용하는 것이 TRACE 메소드를 이용한 XST(Cross Site Tracing)이다. 이 공격 기법에 대한 상세한 내용은 언급하지 않겠다.
5.1.2 스니핑 기법을 이용
Cookie는 패킷 스니핑을 통하여 요청에 포함된 Cookie 헤더 필드를 통해서도 얻어낼 수 있다. 유선랜 환경과 무선랜 환경의 경우로 나누어 알아 본다.
○ Wired LAN
패킷 스니핑까지 할 수 있는 환경이라면 아예 Cookie 대신 로그인 시 전송되는 ID, Password 정보를 얻는 것이 더 현명할 수도 있겠다고 판단할 수 있다. 맞는 말이지만 로그인 과정이 SSL 등으로 암호화하여 전송되어 ID, Password를 얻을 수 없는 경우에 얻어낸 Cookie 정보는 매우 도움이 된다. 물론 접속 이후에도 모든 통신 과정이 SSL로 암호화되어 이루어진다면 스니핑으로도 Cookie 정보는 얻어낼 수 없지만 보안 수준이 매우 높지 않은 대부분의 사이트(즉 금융권 등을 제외한 사이트)는 로그인 과정에 전달되는 ID, Password 정도만 SSL 암호화를 적용하고 있음을 기억하자. 물론 심지어는 그런 최소한의 암호화도 안하고 있는 사이트도 많다.
두 번째로 의문을 가질 수 있는 점은 패킷 스니핑이 그렇게 쉬운가 하는 점이다. 유선랜 환경에서는 허브 환경이라 사용자의 모든 트래픽을 복사하여 아무 포트에서나 쉽게 다른 사용자의 트래픽을 볼 수 있는 방법, 혹은 스위치 환경이나 스위치를 제어할 수 있어서 특정 포트를 mirroring 포트로 지정하여 보는 방법이 있을 수 있다. 물론 이것도 저것도 아니면 ARP Redirect 등과 같은 기법을 쓸 수도 있으나 이러한 방법들은 최소한 중요한 정보를 얻고자하는 네트워크 내에 공격자가 포함되어 있어야 한다.
○ Wireless LAN
무선랜 환경에서는 스니핑을 통해 중요한 정보를 얻는 것이 매우 쉬워졌다. 무선랜 환경에서 패킷의 송수신은 안테나를 통해 전파를 수신하여 모든 사람이 라디오를 청취하는 것과 같아서 주파수만 맞추면 누구나 그 패킷을 수신할 수 있다. 그리고 그 주파수란 몇 개 되지 않는 값으로 그것을 맞추는 일은 아주 쉽다. 이러한 공격 기법에 대한 대응책으로서 보안 의식이 있는 네트워크 관리자는 자사가 보유한 AP(Access Point) 장비에 WEP, WPA 등과 같은 암호화를 적용하기도 하지만 아직도 단지 MAC 주소 인증만으로 어느 정도의 보안 조치를 끝냈다고 생각하는 관리자는 너무도 많다.
5.2 Cookie 정보 활용
여기까지 HTTP Session으로 이용되는 Cookie 값들을 수집하는 방법등을 알아 보았다. 그러면 이러한 방법들을 이용하여 Cookie를 수집하는 이유는 무엇일까?
5.2.1 개인정보 유출
가입된 웹 사이트에 로그인을 한 후 아래 그림과 같이 주소입력 창에
javascript:document.cookie 를 입력하면 개인의 Cookie 값을 확인 해 볼 수 있다.
누군가가 이 정보를 가지고 가면 저자의 정보들을 획득 할 수 있을 것이다. 만일, 이 쿠키값에 위 정보외에 주민 번호, 주소, 전화번호, 핸드폰번호등이 있다고 가정하면 자기 자신의 모든 개인정보들이 나도 모르게 외부에 알려지게 된다. 그 예로 2004년 1사분기 Cookie에 포함된 개인정보가 유출된 사례로서 많은 사이트가 주민등록번호, 실명 정보 등을 쿠키에 포함하여 노출한 사례가 발견된 바 있었다.
기사 제목 대검 등 주요 사이트 개인정보 무방비 노출 ( 기사 내용 (일부) 국가 최고 수사기관, 공중파 방송사, 유명 신문사, 1천만명이 넘는 회원을 가진 커뮤니티 등 주요 웹사이트 상당수가 암호화 미비로 개인정보를 고스란히 노출, 타인 명의를 도용한 불법선거운동, 허위 투서, 명예훼손, 사기 등에 악용될 우려가 매우 높은 것으로 나타났다. 24일 네트워크와 보안업계에 따르면 주요 웹사이트 상당수가 서버와 PC 사이의 로그인과 접속유지를 위해 반복 교환하는 쿠키(cookieㆍ용어설명 참조)에 주민등록 번호, 실명, 실제 주소, e-메일 주소, 전화번호, 연령, 성별 등의 정보를 암호화되지 않은 평문으로 담는 방식을 사용, 이같은 문제점이 빚어지고 있다.
……(이하 생략) ……
5.3 사용자 도용(Cookie Spoofing)
매번 사용자가 로그인할 때마다 랜덤한 값으로 생성되는 일회용 토큰 형태의 Cookie 값을 이용한 인증을 하지 않는 사이트의 경우, 얻어낸 타 사용자의 Cookie 정보를 이용하여 다른 사용자로 로그인할 수 있다. Cookie를 위조하는 공격 기법이라고 하여 이를 Cookie Spoofing이라고 한다. Cookie Spoofing에는 도용하고자 하는 대상 사용자(희생자)의 Cookie 정보가 필요하지 않은 경우와 Cookie 정보가 필요한 경우가 있는데 전자와 후자를 각각 ‘단순 사용자 도용’, ‘Cookie Theft와 연계한 사용자 도용’으로 나누어 설명하도록 한다. 그 전에 잠시 ParosProxy 툴에 대해 알아보자.
5.3.1 ParosProxy의 소개
Cookie를 조작하기 위해서는 클라이언트가 서버에 Cookie 헤더를 보내는 중간에, 혹은 서버가 클라이언트에게 Set-Cookie 헤더를 보내는 중간에 요청과 응답을 가로채어 수정해야 한다. 물론 브라우저 자체가 그런 기능을 제공하는 경우도 있지만(일례로 FireFox의 플러그인 TamperData가 있음) Proxy 계열의 점검 도구를 사용하는 것이 편리하다. 이런 툴의 경우 또 다른 Proxy Server를 다시 Proxy Server로 잡는 Proxy Chain 기능, Request, Response에 대한 저장 및 분석, Web Spidering(Crawling), 또한 SQL Injection, CRLF Injection 등의 보안 취약성 검사 기능 등의 유용한 기능을 제공하기 때문이다. 그러한 툴 중에 프리웨어로서 유명한 툴이 ParosProxy이다. 이 툴은 http://www.parosproxy.org/에서 다운로드할 수 있으며 설치 과정은 단순하므로 생략한다. 툴 설치 이전에 JRE(Java Runtime Environment)가 설치되어 있어야 하며 버전은 ParosProxy에서 요구하는 버전으로 설치하여야 한다.
5.3.2 Cookie Theft와 연계한 사용자 도용
Cookie Theft를 통해 Cookie 정보를 얻어내어야 하는 경우가 있다. 인증에 사용되는 Cookie 정보가 앞선 경우와는 달리 복잡하게 설정된 경우이다. 대표적인 경우는 아래와 같은 경우이다. 아래 정보를 보면 사용자ID, 해당 부서 등의 정보를 얻어내야 할텐데 앞서 논한 단순 사용자 도용과 같이 추측만으로 하기는 어려운 문제이다. 이 경우는 사용자의 Cookie를 얻어내는 방법 즉 Cookie Theft가 필요하다. 하나, 이 경우도 기억할 점이 있다면 Cookie 정보는 많지만 실제 로그인 정보를 유지하고 사용자 정보를 구분하는 핵심 Cookie 정보만 필요하다는 점이다. 그런 정보가 많지 않고 간단하게 구현되어 있다면 그것을 파악하면 좀 더 쉽게 작업을 할 수 있다.
|
ASPSESSIONIDCARTBSDR=CCNGEOOABFJGIHHCJIIEPFBP; LoginInfo=Key=79%1683%1667%1668%1660%1677%16 &EditorMode=1&HOST=coconut%2Eonnet21%2Ecom&SvcOrder=5%2CB05%2C0%2C0%2C10%2CB10%2C0%2C0 %2C12%2CC02%2C0%2C0%2C14%2CC04%2C0%2C0%2C17%2CC08%2C1%2C1%2C11%2CC01%2C1%2C1%2C7 %2CB07%2C1%2C1%2C8%2CB08%2C1%2C1%2C3%2CB03%2C1%2C1%2C2%2CB02%2C1%2C1%2C13%2CC03 %2C1%2C1%2C4%2CB04%2C1%2C1%2C9%2CB09%2C1%2C1%2C1%2CB01%2C1%2C0%2C6%2CB06%2C1%2C0 %2C&MailHost=mail&EmpID=54&UserID=hosik&PosName=+%B4%EB%B8%AE&ComName=%28%C1%D6%29%BE %C8%B7%A6%C4%DA%C4%DA%B3%D3&bbp=YldWc2IyNW5JUT09&DOMAIN=coconut%2Eonnet21%2Ecom &ComID=COCONUT&DeptName=%BA%B8%BE%C8%B1%E2%BC%FA%BF%AC%B1%B8%C6%C0&UType=N &UpperDepts=i%5FDeptId%3D26+OR+i%5FDeptId%3D22+OR+i%5FDeptId%3D0&fmode=1&Name=%C0%CC %BF%EB%C7%D0&DeptID=26&ID=hosik |
얻어낸 Cookie를 재사용하여 로그인할 수 있는 문제점, 공격 기법을 Cookie Replay라고 부른다.
From. marga
여기에 정리 된 내용은 출처에서 간추린 내용이며, 출처 사이트로 가면 이미지와 함께 좀더 자세히 이해 할 수 있을 것 이다.
매우 좋은 내용의 글 이므로 원문을 꼭 읽어볼 것을 추천한다.
원문 http://blog.naver.com/arternis74?Redirect=Log&logNo=150017024791
| Windows XP 팁 (0) | 2007.11.30 |
|---|---|
| Books MBA (2) | 2007.11.12 |
| 영문주소변환기 (2) | 2007.11.07 |
| Cookie의 보안 취약점에 대해 (0) | 2007.11.26 |
|---|---|
| 영문주소변환기 (2) | 2007.11.07 |
| 2007년 웹서버 사용 통계 발표 (0) | 2007.11.06 |
외국사이트에 가입할때면 주소 기입이 간혹 난감해진다.
로마표기법에 따른 한글 치환 프로그램을 하나 만들까 했더니 이미 해논곳이 있어서 링크를...ㅋ
언어닷컴 주소 변환기 : http://archive.eoneo.com/lang/en/freezone/addressConverter/
'서울시 개똥이네'를 변환하면...
'Gaettongine Seoul S.KOREA' 이렇게 변환해준다.
편하다. 변환 표기가 좀 아니다 싶을때도 있지만, 큰 문제는 없다.
| Books MBA (2) | 2007.11.12 |
|---|---|
| 2007년 웹서버 사용 통계 발표 (0) | 2007.11.06 |
| 웹 사용 시 10대 불만족 요인-PC World 조사 (0) | 2007.11.06 |
| Developer | March 2007 | Percent | April 2007 | Percent | Change |
|---|---|---|---|---|---|
| Apache | 64747516 | 58.62 | 66899485 | 58.86 | 0.24 |
| Microsoft | 34265321 | 31.02 | 35380121 | 31.13 | 0.11 |
| Sun | 1851269 | 1.68 | 1907610 | 1.68 | 0.00 |
| lighttpd | 1399786 | 1.27 | 1382843 | 1.22 | -0.05 |
| Zeus | 525405 | 0.48 | 488838 | 0.43 | -0.05 |
Rails를 사용하는 사람들은 아파치 웹 서버와 CGI. 성능에 문제가 많은데 그런 부분을 보완한 Lighttpd +
FCGI 조합을 많이 쓰인다. 그리고 무엇보다 Lighttpd에 열광하는 이유는 기본으로 제공되는 안정적인 fastcgi
모듈이다. 이 모듈이 아파치의 mod_fastcgi보다 빠르고 안정적이라는 사실은 모두가 인정하고 있다.
Lighttpd + Pound + Mongrel 이 조합도 좋아 보인다. 그래서인지 앞으로는 Lighttpd의 사용률이 많이 올라가지 않을까 생각해본다.
| 영문주소변환기 (2) | 2007.11.07 |
|---|---|
| 웹 사용 시 10대 불만족 요인-PC World 조사 (0) | 2007.11.06 |
| 스트리트파이터4 오프닝 동영상 (0) | 2007.10.29 |
| 2007년 웹서버 사용 통계 발표 (0) | 2007.11.06 |
|---|---|
| 스트리트파이터4 오프닝 동영상 (0) | 2007.10.29 |
| MS Office2007 호환팩 (0) | 2007.10.24 |
| 웹 사용 시 10대 불만족 요인-PC World 조사 (0) | 2007.11.06 |
|---|---|
| MS Office2007 호환팩 (0) | 2007.10.24 |
| Activity Diagram (2) | 2007.09.06 |
| 스트리트파이터4 오프닝 동영상 (0) | 2007.10.29 |
|---|---|
| Activity Diagram (2) | 2007.09.06 |
| Web Application Stress Test Tool (0) | 2007.09.03 |
1. Activity Diagram 개요
① 정의 : 처리 로직이나 조건에 따른 처리흐름을 순서에 따라 정의한 모델
② 작성목적
* 처리순서 표현 (대상에 관계없이..)
* 비즈니스 프로세스 정의(이 용도로 가장많이 사용됨) : 업무의 As-is분석, To-be 분석 가능
* 프로그램 로직 정의 : 처리흐름의 도식화로 프로그램 로직 정의 가능
* 유즈케이스 실현
③ 작성시기 : 그 시점이 한정되어 있지 않고 다양하게 사용 가능
* 업무 프로세스 정의 시점.
* 유즈케이스 정의서 작성 시, 처리절차 기술할 때
* 오퍼레이션 사양 정의시
④ 작성순서
* 작성대상 선정 : 업무프로세스 모델링, 오퍼레이션 사양 정의
↓
* Swim lane 정의 : 대상영역에 명확한 역할을 정의해야 할 때.
↓
* 처리절차 모델링 : 시작점, 끝점 반드시 표현.
2. Activity Diagram 구성요소
① Things
* Activity : 행위나 작업 ( 내부적으로 구조를 가지는 단위
ex) 상품조회, 구매결정, 결재내용입력, 결재자지정....
* Initial State : ● * Final State : ⊙
* Decision(Branch) : ◇
* Synchronization bar : 병렬처리절차가 시작되거나 모이는 지점
ex)
② Relationship
* Transition(전이) : 하나의 액티비티가 행위를 완료하고 다른 액티비티로 처리순서가 옮겨
지는 제어흐름 표현
③ Swim lane : 하나의 처리를 구분지음.
3. Activity Diagram 사례
① SCM 시스템의 일반 정보에 대한 Role 액티비티 다이어그램
* AS-IS
* TO-BE
→ 모든 사용자에게 일반정보를 제공했던 것을 등록여부와 거래품목 등록여부 확인 후
등록된 사용자에게만 일반정보 제공.
② 프리즘에서 유지보수 절차 프로세스를 정의한 액티비티 다이어그램
| MS Office2007 호환팩 (0) | 2007.10.24 |
|---|---|
| Web Application Stress Test Tool (0) | 2007.09.03 |
| 입지 않는 티셔츠를 가지고 오시면, 루츠 'Live Green' 티셔츠를 드립니다 (0) | 2007.08.23 |
목 차
1 Web Application Stress Test Overview
2 Web Application Stress Test Tool
A. ACT(Microsoft Application Center Test)
? 스크립트 작성법
? 테스트 속성 설정
B. OpenSTA(Open System Testing Architecture)
? 스크립트 작성법
? 테스트 속성 설정
C. ACT vs OpenSTA
D. Performance Monitor(성능 모니터)
? 성능 카운터 항목
? 성능 모니터 사용 권고 사항
3 Web Application Stress Testing
A. 스트레스 테스트 계획
? 테스트 목적 설정
? 테스트 환경 설정
? 테스트 시나리오 정의
B. 스트레스 테스트 실행
? System Performance(응답시간)
? System Capacity(용량)
C. 스트레스 테스트 분석
? 테스트 결과 분석 가이드
웹 어플리케이션 개발 후 실제 운용 상황을 가상하여 테스트를 실시함으로써 어플리케이션, 시스템, 네트워크 상황들을 점검해보는 목적이다. 안정적으로 동시 사용자 x 명까지 수용할 수 있는 시스템이다라는 가정을 검증하는 과정이다.
ACT(Microsoft Application Center Test)는 웹 어플리케이션에 대한 성능 테스트를 수행하고 관련 성능 정보를 수집하여 해당 웹 어플리케이션의 성능을 가늠해 볼 수 있게 해주는 툴이다. 웹 어플리케이션이 이용되는 상황을 스크립트로 작성하여 시뮬레이션 할 수 있다.
1. [시작] -> [프로그램] -> [Microsoft Visual Studio .NET] ->[ Visual Studio .NET Enterprise Features] -> [Microsoft Application Center Test]를 선택하여 ACT를 시작한다.
2. [파일]->[새 프로젝트]를 선택하여 프로젝트 이름과 저장될 위치를 지정한다. 이름 : WooriBanca Stress Test , 위치 : \ WooriBanca\Stress Test\
3. 새로 생성된 프로젝트 폴더의 [테스트]에서 마우스 오른쪽을 눌러 [새 테스트(N)…]를 선택한다. 5단계의 테스트 마법사가 실행된다.
4. 마법사 2번째 단계 ‘테스트 원본 선택’에서 “새 테스트 기록하기”를 선택한다. 이는 매크로 기능처럼 사용자가 취한 행위를 vbs 스크립트로 자동 생성해준다. 4번째 단계 ‘브라우저 기록’에서 “기록시작”을 누르면 신규 브라우저가 화면에 나타난다. 이 페이지에서 시작하여 우리은행 Bancassurance 의 특정 업무를 수행하는 과정을 실제 시뮬레이션 한다. 끝나면, 기록중지를 누른다. 테스트 명을 지정(Woori Banca test)하고 마친다.
테스트 속성에는 일반 / 사용자 / 카운터 3개의
탭 페이지가 있다.
l 일반 : 테스트 회수, 시간 등을 설정
Ø
테스트
로드 수준 브라우저 동시 연결 수 : ACT는 지정된 수만큼 동시에 브라우저 연결을 설정한다. 실제 프로세스가 뜨는 것은 아니다.
Ø
테스트
지속 시간 : 지정한 시간 동안 반복적으로 테스트를 수행한다.
Ø
지정한
횟수만큼 테스트 실행 : 실행시간에 상관없이 스크립트 수행을 지정된 회수만큼 수행한다.
l
사용자 : 사용자 인증과 쿠키 처리 방식을 설정
l 카운터 : 테스트시 모니터링할 서버, 클라이언트의 성능 카운터 설정
Ø
테스트
수행과정에서 서버 및 클라이언트에서 모니터링 할 카운터를 설정한다.
Ø
원격 컴퓨터의 성능카운터를 확인하려면 관리자 권한이 있어야 한다.
OpenSTA(Open
System Testing Architecture)는 WAE(Web
Application Environment)하에서 동작하는 웹 서버, 어플리케이션 서버
및 데이터베이스 서버 등에 부하테스트를 수행할 수 있는 성능 테스팅 툴(Performance Testing
Tool)이다. 가상 유저(Virtual User)를
이용한 실 사용자와 동일한 부하를 생성할 수 있고 생성된 스크립트의 결과 등 분석 자료를 추출할 수 있다. http://opensta.org/download.html 에서
프로그램을 다운로드 할 수 있고 http://portal.opensta.org/
에서 필요한 기술 정보를 얻을 수 있다.
1.
[시작]
-> [프로그램] -> [OpenSTA] -> [OpenSTA Commander]를 선택하여 OpenSTA를 시작한다.
2. 아래의 그림의 메뉴를 이용해 새로운 테스트 스크립트를 생성하고 디폴트 이름을
적절하게 변경한다.
3. 생성된 스크립트를 더블 클릭하여 나온 아래와 같은 화면에서 
버튼을
클릭하여 브라우저를 통해서 테스트 시나리오를 레코딩한다.
4. 아래의 그림의 메뉴를 이용해 새로운 테스트를 생성하고 디폴트 이름을 적절하게
변경한다.
5. 테스트를 더블 클릭하여 나타난 화면에 테스트하고자 하는 Script를 끌어다 놓는다. 하나의 테스트에는 여러 개의 테스트 그룹이
포함될 수 있고 하나의 테스트 그룹에서는 순차적으로 실행되는 200개의 Script가 포함될 수 있다. 각각의 테스트 그룹별로 속성을 다르게
지정할 수 있다.
테스트 속성에는 VUs(가상 유저수) / Start(시작설정) 속성 등이 있다.
l
VUs(가상 유저수) : 스크립트를 실행하는 가상 유저수를 Task Group 별로 지정한다.
l
Start(시작설정) : 시작을 즉시할 것인지/스케줄을 사용할 것이지 등의 시작 설정과
반복 회수/실행 시간등을 지정한다.
|
|
ACT |
OpenSTA |
|
시나리오 |
단일 스크립트 방식 : 여러 개의 ACT를 동시에 실행할 경우 멀티 스크립트 가능 |
멀티 스크립트 방식 : 시나리오별 Virtual User 지정 가능 => 실제 사용 모습을 재현하는데 ACT에 비해서 용이 |
|
부하 단위 |
동시 브라우저 수 |
Active
Virtual User : 이해가 쉬움 |
|
분석 리포트 |
요약 / 페이지별 강력한 분석 보고서 |
ACT에 비해서 취약 : HTTP Data를
분석할 수 있음 |
|
용도 |
Capacity
측정을 위한 부하시 사용 적합 |
Capacity
측정을 위한 부하 및 낱개 페이지별 Response Time 측정에 적합 |
|
개별 특성 |
.vbs
파일 수정 가능 |
성능 테스트를 실행하는
클라이언트 리소스를 적게 사용(CPU 등 확인시) |
|
Exchange
사서함 주소가 한글 사이트에 대해서 Auto recorded script를 일부 수정해 주어야 함 |
www.openSTA.org 공개 소스 |
l
클라이언트
사이드 : 성능 테스트를 수행하는 클라이언트에서 확인해야 할 내용.
|
개체 |
성능 카운터 |
표시 내용 |
|
Processor |
% Processor Time/_Total |
테스트 클라이언트의 프로세서 사용 량이다. |
|
Memory |
Available Bytes |
테스트 클라이언트에서 사용할 수 있는 메모리의 양. |
|
Network Interface |
Bytes Total/sec |
테스트 클라이언트에서 또는 테스트 클라이언트로 이동하는 네트워크 소통 량. |
l
서버 사이드 : 성능 테스트를 수행하는 서버에서 확인해야
할 내용
|
개체 |
카운터 |
설명 |
해석 |
|
.NET CLR
Exceptions |
# of
Exceps Thrown |
응용 프로그램이 시작된 이후에 throw된 총 예외 수 이다. 이 값은 .NET 예외 및
.NET 예외로 변환되는 unmanaged 예외가 포함된 값. 예: unmanaged code의 null 포인터 참조 예외는 managed code에서 .NET System.NullReferenceException으로 다시
throw된다. |
예외는 아주 드문 경우에만
나타나야 하며 프로그램의 정상적인 제어 흐름에는 존재하지 않는 것이 바람직. |
|
ASP.NET |
Requests Queued |
처리 대기중인 요청수.. 이 숫자가 IIS 대기열
길이를 초과하면 "서버 사용량이 많습니다." 오류가
발생한다. |
이 숫자는 0에 가까워야 한다.1보다 큰 경우, Request Wait Time을 동시에 해석하여 큐 대기시간을 동시에 파악해야 한다. |
|
ASP.NET |
Request
Execution Time |
가장 최근 요청을 실행하는데 소요된 시간(ms) |
적은 값일수록 요청을 빨리
처리했다는 증거. |
|
ASP.NET |
Worker Process Restarts |
워커 프로세스(aspnet_wp.exe)의 재시작 회수. |
웨커 프로세스의 recycling 시 이벤트 로그에도 그 기록이 남는다. |
|
ASP.NET Appliacations |
Requests/Sec |
초 당 실행되는 요청 수이다. |
시스템의 처리 능력을 가늠. |
|
Internet Information Services Global |
File Cache Flushes and File Cache Hits |
이 카운터를 비교하면 캐시 정리에 대한 적중률을 알 수 있다. 플러시는 파일이 캐시에서
제거될 때 발생한다. 이들 카운터는 개체가 캐시에서 플러시되고 있는 속도를 표시하고 있으며, 플러시가 너무 느리게 발생하면 메모리가 불필요하게 사용되는 것이다.
ObjectCacheTTL, MemCacheSize 및 MaxCacheFileSize 레지스트리
설정을 조정하면 이 값을 조정할 수 있다. |
|
|
Internet Information Services Global |
File Cache Hits % |
이 카운터는 총 캐시 요청에 대한 캐시 적중률을 표시. |
정적 페이지가 있는 사이트의
캐시 적중률은 약 80%이어야 한다. |
|
Memory |
Available Bytes |
이 숫자는 남아 있는 사용 가능한 실제 메모리의 양 표시함. |
|
|
Memory |
Cache Bytes |
정적 파일에 사용된 캐시 크기를 표시. 기본적으로 캐시 바이트는 사용 가능한 메모리의 약 50%로 설정되지만 사용 가능한 메모리가 감소하여 시스템 성능이 저하되면 더 낮게 설정된다. |
|
|
Memory |
Pages/sec |
서버의 메모리가 부족하여 서버의 작업 부하를 처리할 수 없으면 이 숫자는 지속적으로 올라갑니다. |
|
|
Memory |
Pool Paged Bytes and Pool Nonpaged Bytes |
풀에는 응용 프로그램과 운영 체제에서 만들고 사용한 개체가 저장됩니다. 풀이 채워지면 메모리
누실이 있을 수 있습니다. |
|
|
Network Interface |
Bytes Total/sec |
사용 가능한 대역폭과 이 값을 비교하면 발생할 수 있는 네트워크 병목 상태를 명확하게 표시할 수 있습니다. 일반적으로 바이트 수/초는 사용 가능한 총 대역폭의 50% 이하로 유지해야 합니다. |
|
|
Object |
Threads |
Threads는 프로세서에서 명령을 실행할 수 있는 기본 실행 엔터티입니다. 이 숫자가 시간에 따라 계속 커지면 Process:Thread Count
카운터를 열어 모든 스레드를 만들고 있는 인스턴스를 확인합니다. |
|
|
PhysicalDisk |
% Disk time |
읽기/쓰기 작업을 하는 디스크의 경과된 시간을 비율로 표시합니다. 이 카운터 숫자가 높고 프로세서 및 네트워크 대역폭이 포화되어 있지 않으면 디스크 병목 현상이 발생할 수
있습니다. 이 카운터를 로깅하기 전에 Windows 2000 명령줄에서 "diskperf -yD"를 실행하십시오. 지속적으로
숫자가 80% 이상이면 메모리 누실을 나타내는 것일 수 있습니다.
다중 디스크 시스템에 대해 이 카운터의 0 인스턴스에서 x 인스턴스까지 추가하도록 합다. |
|
|
PhysicalDisk |
Disk Queue Length |
아직 해결되지 않은 요청 수를 디스크에 표시합니다. 한 디스크에 표시되는 대기열 길이가
지속적으로 3 이상이면 디스크, 메모리 또는 SQL Server 구성 문제를 나타냅니다. |
|
|
Process |
Private Bytes - _Total |
다른 프로세스와 공유할 수 없는 모든 인스턴스가 할당한 현재 바이트 수를 표시합니다. 목록에서 _Total 인스턴스를 선택합니다. 메모리를 모두 소모하고 있는
것으로 간주되는 다른 모든 인스턴스를 선택. |
|
|
Process |
Private
Bytes(inetinfo 인스턴스) |
Private Bytes(inetinfo)는 다른 프로세스와
공유할 수 없는 HTTP/ASP 서비스가 할당한 현재 바이트 수 입니다. 이 숫자가 지속적으로 커지면 서버쪽 개체에 누실이 있을 수 있습니다.
Process: Private Bytes(_Total)와 비교해야 한다. |
COM+내 Server
Type(dllhost.exe)의 카운터 값도 모니터링해야 한다. |
|
Process |
Thread Count(inetinfo 인스턴스) |
웹 서버 프로세스에서 만든 스레드 수입니다. |
|
|
Processor |
% Processor Time(_Total 인스턴스) |
이 카운터를 통해 프로세서 포화 상태를 가장 잘 볼 수 있습니다. 모든 CPU에서 스레드를 처리하는 데 소비된 시간을 표시합니다. 하나
이상의 프로세서에서 숫자가 지속적으로 90% 이상이면 하드웨어에 대한 테스트가 지나치게 집중되어
있다는 것을 나타냅니다. 다중 프로세서 서버에 대해 이 카운터의
0 인스턴스에서 x 인스턴스까지 추가하십시오. |
|
|
Processor |
Interrupts/sec |
프로세서 사용률이 90% 이상이고 인터럽트 시간 백분율이
15%보다 크면 프로세서는 지나치게 인터럽트됩니다. |
|
|
Server |
Bytes Total/sec |
네트워크 동작을 표시합니다. |
|
|
System |
Processor Queue
Length |
이 카운터는 웹 서버의 모든 프로세서가 공유하는 대기열에서 실행 대기하고 있는 스레드 수를 표시합니다. |
프로세서 병목 상태가 되면 지속적으로 값이 2보다
커질 수 있습니다. |
|
System and Thread |
Context Switches/sec, Context Switches/sec:
dllhost(thread # instance) 및 Thread:
Context Switches/sec: inetinfo(thread # instance) |
이들 카운터는 시스템 전체에서 발생하는 컨텍스트 전환 수와 IIS 5.0 내에서만 발생하는
컨텍스트 전환 수를 표시합니다. |
|
|
Thread: |
% Processor Time: InetInfo => Thread # |
InetInfo 프로세스의 각 스레드가 사용하는
프로세서 시간을 나타냅니다. |
|
|
Thread: |
Context Switches/sec: InetInfo => Thread # |
IIS 서비스의 스레드가 프로세서의 설정 또는 해제를 전환하는
횟수를 나타냅니다. |
|
|
Web Service |
Bytes Total/sec |
웹 서버에서 보내고 받은 바이트의 합계를 표시합니다. |
|
|
Web Service |
Current Anonymous Users |
인증되지 않은 스트레스 테스트 동안 서비스에 연결되어 있는 현재 연결 수를 표시합니다. |
|
|
Web Service |
Current Connections |
HTTP 서버에 현재 연결되어 있는 인증된 사용자 수입니다. |
Current Non-Anonymous Users 수와 동일. |
|
Web Service |
Not Found Errors |
반환된 404 응답 코드 수를 표시합니다. |
|
l
최대 4시간까지 모니터링하는 경우 모니터링 빈도는 15sec(Default)을
유지한다. 8시간이상 모니터링하는 경우 시스템의 Overhead를
줄이기 위해 300sec(5분)이상으로 설정한다.
l
모니터링
주기는 15분을 기본으로 한다.
l
사용자 임계치 정의
예) 급여오픈시 3,000 User가 30분간 집중적으로 로그인함
예) 출근 직후 혹은 퇴근 직전 1시간동안 1,000 User가 집중적으로 로그인 후 보험 실적 입력
예) 동시 사용자 200 User가 3초안에 로그인 할 수 있도록
l
L4 Switch의 Balancing Algorithm을 고려하여 각 서버 그룹을 1대를
대상으로 할 것인지 서버 그룹 내 2대의 서버를 모두 대상으로 할 것인지 등을 결정
예) 사용자 요구 사항이 동시
사용자 200 User 일 때 전체 Web/App 서버가 4대로 구성될 경우 한 서버에 동시 사용자 50 User를 테스트, Web/App 서버 이후의 Back-End 서버는 모두 정상 가동
l
스트레스
테스트에 사용되는 데이터베이스를 테스트 환경에 맞추어 설정한 후 반복적인 테스트에 쉽게 대응할 수 있도록 백업하거나 원상 복구용 스크립트를 작성해
주는 것이 좋다.
l
테스트
시나리오 범위
Ø
전체
시스템 중 다른 서버와의 연계 및 시스템의 핵심 기능, 성능에 영향을 미칠 것으로 보이는 모든 접점을
범위로 하여 시나리오 구성 : 로그인, 게정계와의 연동, 타보험사와의 연동 등
l
테스트
시나리오 정의 예
Ø
로그인 (동시 사용자 200명) : 동시
사용자 200명 로그인 테스트
Ø
로그인 -> 계정계와의 연동(동시 사용자 100명) : 동시 사용자 100명으로
로그인 단계에 부하를 가하고 있는 상태에서 추가적으로 100명의 동시 사용자를 [로그인 -> 계정계와의 연동]
테스트
Ø
로그인 -> 타보험사와의 연동(동시사용자 50명) : 동시 사용자 100명으로
로그인 단계에 부하를 가하고 있는 상태에서 추가적으로 50명을 [로그인 -> 계정계와의 연동] 시나리오로 부하를 준다. 이 상태에서 다시 50명의 부하를 [로그인 -> 타보험사와의 연동]에
가한다.
l
현상계
사용 시나리오에 준해서 OpenSTA로 부하를 가하고 ACT를
이용해서 Performance에 대한 보고서를 얻어낸다.
예) 로그인 -> 타보험사와의 연동(동시사용자 50명)
[OpenSTA]
Ø
로그인 : 동시 사용자 100명 부하
Ø
로그인 -> 계정계와의 연동 : 동시 사용자 50명 부하
Ø
로그인 -> 타보험사와의 연동 : 동시 사용자 50명 부하
[ACT]
Ø
로그인 -> 타보험사와의 연동 : 동시 브라우저수 1개로 부하를 가하면서 Performance 보고서를 취득
l 성능 모니터를 이용한 성능 카운터(메모리, CPU, 디스크, 프로세스 등)를 이용해서 보고서를 얻어낸다.
l
테스트
결과에서 많은 양의 에러(응답 코드 200번 보다 큰 응답
코드)를 발견할 경우, 에러 발생 지점은 성능이나 병목 이슈의
후보가 될 수도 있다.
l
스트레스
테스트 도구들은 Ramping Up 스트레스를 준다. 즉, 처음에는 부하의 수준을 조금 주다가 시간이 흐를수록 부하의 수준을 늘려가게 된다. 시스템에 어느 정도의 부하에서 테스트가 실패하는지도 살펴볼만한 요소가 되나.
l
시스템의
성능의 관점에서 RPS(Request Per Second)의 값은 서버의 Capacity와 테스트 시나리오에 모두 관련이 있다. RPS값은
테스트 시나리오의 복잡성, 서버의 Capacity와 관련이
있으므로 절대적인 응답시간이나 Capacity의 기준으로 간주해서는 안되며 하나의 참조자료가 될 수
있다.
l
시나리오의
응답시간은 ACT의 결과인 “반복 당 평균 TTLB(밀리초)”가 좋은 척도가 된다.
l
부하분석
결과 예)
|
부하 시나리오 |
서버용량 |
응답속도 |
||||||
|
시나리오 |
|
CPU% |
RPS |
Queue |
CC |
평균(Sec) |
최소 |
최대 |
|
로그인 |
10 |
10 |
6 |
0 |
24 |
5.67 |
4.00 |
9.00 |
|
20 |
19 |
12 |
0 |
49 |
5.57 |
4.00 |
7.00 |
|
|
50 |
34 |
28 |
0 |
113 |
5.71 |
4.00 |
11.00 |
|
|
75 |
58 |
43 |
0 |
188 |
5.61 |
4.00 |
10.00 |
|
|
100 |
84 |
50 |
1 |
235 |
7.08 |
4.00 |
12.00 |
|
|
125 |
86 |
54 |
1 |
350 |
8.33 |
4.00 |
14.00 |
|
|
150 |
86 |
54 |
1 |
349 |
12.00 |
4.00 |
20.00 |
|
|
200 |
92 |
51 |
3 |
450 |
16.24 |
5.00 |
28.00 |
|
|
300 |
91 |
48 |
20 |
672 |
31.24 |
6.00 |
46.00 |
|
Ø
위의
로그인 프로세스의 경우 동시 사용자 100명일 경우가 현재 시스템이 커버할 수 있는 최대수로 보여진다. 100명일 경우와 150명일 경우 CPU 평균 사용량(84~86)과
RPS(50~54)등이 모두 비슷하지만 응답시간의 경우 많은 차이(7.08~12.00)를
보인다. 따라서 시스템이 커버할 수 있는 적정 동시 사용자수는 100명으로
볼 수 있다.
l
부하
테스트의 결과 현재의 시나리오에서 시스템이 커버할 수 있는 동시 사용자수와 응답 속도가 사용자의 요구에 만족스럽지 않을 경우
Ø
ACT의 페이지별 TTLB를 확인하여 오래 걸리는 페이지에 대한 추가적인 조사 작업을 수행
Ø
OpenSTA의 결과인 HTTP Data List의 데이터를 이용하여 특정 시나리오내의 구간을 정의하여 구간별 응답시간을 상세히 분석해
볼 수 있다(수작업 필요).
| Activity Diagram (2) | 2007.09.06 |
|---|---|
| 입지 않는 티셔츠를 가지고 오시면, 루츠 'Live Green' 티셔츠를 드립니다 (0) | 2007.08.23 |
| 서비스별 네트워크 포트번호 (0) | 2007.08.02 |
| Web Application Stress Test Tool (0) | 2007.09.03 |
|---|---|
| 서비스별 네트워크 포트번호 (0) | 2007.08.02 |
| Ship it (2) | 2007.07.31 |
| 입지 않는 티셔츠를 가지고 오시면, 루츠 'Live Green' 티셔츠를 드립니다 (0) | 2007.08.23 |
|---|---|
| Ship it (2) | 2007.07.31 |
| Google Product Connections Map (0) | 2007.07.06 |
| 서비스별 네트워크 포트번호 (0) | 2007.08.02 |
|---|---|
| Google Product Connections Map (0) | 2007.07.06 |
| Google Docs & Spreadsheets Keyboard Shortcuts (0) | 2007.07.03 |
Google Product Connections Map
Google Product Connections Map Origial
| Ship it (2) | 2007.07.31 |
|---|---|
| Google Docs & Spreadsheets Keyboard Shortcuts (0) | 2007.07.03 |
| Youtube 동영상 다운로드 하기 (1) | 2007.06.26 |
