1. Option Explicit를 명시한다. 쓰지도 않는 변수들이 생기면 그만큼 메모리 낭비가 생기므로...

2. 배열사용 시 배열 재할당은 최대한 피한다.

3. 배열 사용이 빈번할 시 Dictionary 객체를 이용하여 가독성을 높인다.

4. Stored Procedure를 사용한다. (일반 ASP자체 쿼리보다 최고 30% 성능 향상.)

5. 뷰테이블 사용 시 뷰테이블 자체에서 정렬을 해야 한다. 이미 만들어진 뷰테이블을 이용하여 Asp 코드
에서 정렬하면 속도가 크게 떨어진다. 최고 50%까지 느려지는 것을 목격했음.

6. Query를 사용할 때 꼭 필요한 컬럼만 명시하여 불러오거나 이용해야 한다. SQL은 아주 정직해서 불러
오는 컬럼의 갯수(레코드 수가 동일하다고 가정시)에 비례하여 시간이 걸린다.

7. Recordset 객체 보다는 Command 객체를 이용하는 것이 빠르다. 10%정도의 향상을 볼 수 있었다.

8. Recordset 객체 사용시 CursorLocation를 적절한 것을 사용해야 한다. (1, 서버, 3. 클라이언트) 속도의
차이가 클 수 있다. CursorType도 영향을 미친다. 반드시 테스트 필요. 보통은 CursorLocation은 클라이언
트에 두는 것이 추세다. 테스트때 클라이언트에 커서를 두었을때 서버에 두었을때보다 속도가 최고 3배이상
빨라지는 것을 경험했다.

9. 1000글자가 넘어가는 문장의 경우는 변수에 담아서 한번에 Response.Write 하는 것보다는 한줄한줄 직
접 뿌려주는 것이 빠르다. <%= %>를 이용해 직접 뿌리는 것이 가장 빠르다. 괜히 변수에 잔뜩담아서
Response.write 해보라 -_-;;; 아마 글자수의 제곱에 비례하여 느려질 것이다 -_-;;;

10. 사용한 객체는 반드시 Close, Nothing 해준다. 안해주면 메모리 누수가 일어난다. 웹서버들이 잘 죽는
경우는 반드시 이것을 체크해야 한다.

11. 다중레코드를 이용할 시에는 Do until, Rs.MoveNext 구문보다는 GetRows() 함수를 이용하는 것이 빠르
다.(Stored Procedure와 함께 사용시 최고 40% 성능 향상, 단독으로 사용시 최고 20% 성능 향상.)

12. 사용자 Function을 만들어 쓰는 것이 디버깅 등에 좋다.

13. ADODB 객체 사용보다 OBJECT 객체를 사용하여 컨넥션, 레코드셋을 연다.
2009/09/01 15:55 2009/09/01 15:55
 

Source from:[S.S.R.E.T]ServersTeam.Org [F.N.S.T]Fineacer.Org
url:http://www.Serversteam.org/docs/Microsoft_Win_ASP_Webshell_Security.htm

개요:본문에서는 Microsoft 윈도우 계열의SERVER (IIS5.0、IIS6.0)에서 간단하고 빠르게 ASP 위험성 있는 컨포넌트를 WEB서버 시스템으로부터 멀리하는 것을 설명한다. 본문을 읽는 후 자기가 관리하고 있는 서버를 asp 트로이잔, Webshell 권한상승 및 시스템 보안위협 등으로부터 벗어날 수 있다.

본문:
주의:본문에서 언급된 설정방법 및 설정환경은:Microsoft Windows 2000 Server/Win2003 SERVER | IIS5.0/IIS6.0에 적용함.

1、우선 일반적인ASP트로이잔을 살펴본다, Webshell에서 사용한 ASP 컨포넌트는 아래와 같다. 중국산 webshell인 HY2006를 예를 들어보면,

<object runat="server" id="ws" scope="page" classid="clsid:72C24DD5-D70A-438B-8A42-98424B88AFB8"></object>
<object runat="server" id="ws" scope="page" classid="clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B"></object>
<object runat="server" id="net" scope="page" classid="clsid:093FF999-1EA0-4079-9525-9614C3504B74"></object>
<object runat="server" id="net" scope="page" classid="clsid:F935DC26-1CF0-11D0-ADB9-00C04FD58A0B"></object>
<object runat="server" id="fso" scope="page" classid="clsid:0D43FE01-F093-11CF-8940-00A0C9054228"></object>
shellStr="Shell"
applicationStr="Application"
if cmdPath="wscriptShell"
set sa=server.createObject(shellStr&"."&applicationStr)
set streamT=server.createObject("adodb.stream")
set domainObject = GetObject("WinNT://.")

이상은 HaiYang webshell의 일부 소스다, webshell에서는 아래 여러 종류의 ASP컨포넌트를 사용하고 있는 것을 알 수 있다.
① WScript.Shell (classid:72C24DD5-D70A-438B-8A42-98424B88AFB8)
② WScript.Shell.1 (classid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B)
③ WScript.Network (classid:093FF999-1EA0-4079-9525-9614C3504B74)
④ WScript.Network.1 (classid:093FF999-1EA0-4079-9525-9614C3504B74)
⑤ FileSystem Object (classid:0D43FE01-F093-11CF-8940-00A0C9054228)
⑥ Adodb.stream (classid:{00000566-0000-0010-8000-00AA006D2EA4})
⑦ Shell.applicaiton....

2: 해결방법:

① 아래 위험성 있는 ASP 컨포넌트를 삭제 혹은 명칭을 변경한다.
WScript.Shell、WScript.Shell.1、Wscript.Network、Wscript.Network.1、adodb.stream、Shell.application
[시작->실행->Regedit]을 실행하여 레지스토리를 수정한다. “Ctrl+F”으로 찾기를 실행한다. 순서대로 위에 Wscript.Shell등 컨포넌트의 명칭 혹은 그와 매칭한 ClassID을 입력한다. 해당 명칭을 삭제하거나 변경한다. (여기서 명칭변경을 권장한다. 만약 일부 웹 페이지의ASP프로그램에서 위에 열거한 컨포넌트를 사용했다면, ASP코드작성시 수정된 컨포넌트의 명칭을 사용하면 모든 것이 정상적 사용을 가능하다. 만약 ASP프로그램에서 이상의 컨포넌트를 사용하지 않는다면 삭제하는 것이 좋다. 삭제 혹은 명칭 변경 후, iisreset으로 IIS재 동작 후 적용한다.)
[주의:Adodb.Stream 컨포넌트는 많은 사이트에서 사용하기 때문에  만약 서버가 Virtual machine 이면 상황에 따라 조치 바람.]

② File System Object (classid:0D43FE01-F093-11CF-8940-00A0C9054228) 보안 문제에 대해 만약 서버에서 FSO를 사용해야 한다면(일부 Virtual Machine에서는 FSO기능을 사용함), FSO보안 해결방법은 “Microsoft Windows 2000 Server FSO 安全隐患解决办法” 문서를 참고하시길 바란다. 사용할 필요 없는 경우 직접 사용중지 하면 된다.

③ 사용중지 혹은 위험성 있는 컨포넌트를 삭제하는 방법:(방법① 및 방법②를 번거롭다고 생각하는 분은 본 방법을 참고함.)

wscript.shell 오브젝트를 해제하는 방법은 아래와 같다. cmd 모드에서[:regsvr32 /u %windir%\system32\WSHom.Ocx]를 실행한다.
FSO 오브젝트를 cmd 에서 아래 내용을 실행하여 해제한다. [regsvr32.exe /u %windir%\system32\scrrun.dll]
stream 오브젝트의 해제는 cmd에서 [regsvr32 /s /u "C:\Program Files\Common Files\System\ado\msado15.dll" ]를 실행한다.
만약 실행취소를 원한다면 위에 명령에 [/U] 옵션만 제거하면 된다. 즉, 관련 ASP컨포넌트를 재실행 가능하다. 예를 들면, regsvr32.exe %windir%\system32\scrrun.dll

④ Webshell 중에 set domainObject = GetObject("WinNT://.")을 사용하여 서버 프로세스, 서비스 및 사용자 정보 등을 획득하는 것에 대한 예방 방법은 아래와 같다. 서비스 중의 Workstation[네트워크 연결 및 통신을 제공함] 즉, Lanmanworkstation서비스를 중지하면 문제해결 된다. 이렇게 처리하면 Webshell 프로세스를 디스플레이 하는 곳에 공백으로 표시된다.

3 위에 방법1、2에 따라 ASP관련 위험한 컨포넌트에 대해 처리 후, Ajiang asp probe으로 테스트하면,"서버CPU상세내역" 및 "서버운영체제"를 찾을 수 없으며 내용은 모두 공백으로 디스플레이 된다. HaiYang을 사용하여 Wscript.Shell를 테스트 하면, cmd commend line에서 Active를 만들 수 없다는 메시지가 디스플레이 된다. ASP 트로이잔이 서버 시스템에 대한 보안 위협을 완화할 수 있다.
본문에서 소개한 내용은 단지 본인이 ASP트로이잔、Webshell에 대한 소견뿐이다. 향후 여러분께 어떻게 간단하게 타인 컴퓨터에 net user 와 같은 명령의 실행을 방지하고, 버퍼 오버플로우를 통해 cmdshell 획득을 방지 및 사용자 추가의 방지, NTFS 설정권한에서 터미널 서비스 등록 등에 대한 간단하고도 효과적인 방어방법을 소개할 예정이다.


저자: 李泊林/LeeBolin
[S.S.R.E.T 服务器安全研究专家小组 CTO] Http://www.serversteam.org
[F.N.S.T 情长计算机网络安全在线 技术顾问] Http://www.fineacer.org
E-mail:leebolin#serversteam.org QQ:24460394 본문관련 질문 사항은 메일 혹은 QQ에 연락하시길 바람
 
 
2009/09/01 11:28 2009/09/01 11:28
DDos 공격 좀비 컴을 확ㅇ니하는 플그램.

2009/07/09 20:01 2009/07/09 20:01
IIS튜닝 - 캐시 조정


www.wssplex.net

ASP파일 캐시

캐싱할 미리 컴파일된 스크립트 파일 수를 메모리에 저장할 파일수를 지정은 기본값으로 500(IIS5-250)개 이다. 이 속성은 사용 가능한 메모리 양과 스크립트 파일 트래픽의 양에 따라 성능을 조정하는 데 사용된다.

메모리에 캐시된 내용은 컴파일 되지 않은 ASP 요청보다 훨씬 빠르게 응답하게 된다. 메타베이스 속성값은 AspScriptFileCacheSize 이다.

물론 이 값을 높게 설정할수록 캐시량은 많아지지만, 캐시된 만큼 메모리를 점유하게 되므로 적용전 메모리 상태를 먼저 확인하는 것이 좋으며, 변경후에 캐시 적중 성능카운터를 이용해 그 효과를 측정해야 한다.




캐시할 스크립트 엔진

파싱된 스크립트를 바이트 코드로 변환하는 작업을 수행한다. IIS5에서는 125개 이며, IIS6에서는 250개가 기본값으로 되어 있다. 만약 웹사이트에서 수천개의 ASP페이지가 존재한다면 이 값을 증가시키는 것 만으로도 성능향상을 꾀할수 있다.



IIS6에서 추가된 디스크에 캐시를 저장하는 옵션으로 디스크에 파일캐시를 저장할경우 지정된 디렉토리에 캐시된 ASP파일이 저장된다. 언제나 그렇듯 ASP 파일내용이 자주 변경되는 웹사이트의 경우 캐시의 효과는 변경되는 비율많큼 적어진다.



위 성능카운터 값은 필자가 운영하는 서버중 한대로 Http 동시접속수 1249개 인 웹서버로 초당 Asp요청수가 초당 50~60건 정도이며, File Cache Hits 93% 인 상태이다. 성능카운터의 File Cache Hits %가 80~90% 선을 지속적으로 유지할 때 만족스러운 상태로 판단할 수 있다.

Adsutil.vbs set 메타베이스경로 "값"
Adsutil.vbs set 메타베이스경로 "값"
Adsutil.vbs set AspScriptEngineCacheMax "값"


IIS 파일 캐시 설정 변경

IIS는 서버에서 사용 가능한 메모리의 50% 까지 사용한다. 그러나 웹전용 서버이면서 IIS에서 점유하는 메모리가 50%에 다다른경우 시스템운영에 적정여유량을 제외한 나머지 값까지 사용할수 있도록 이 값을 변경해 볼 필요가 있다.

MemCacheSize
레지스트리 경로:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters
데이터 형식: REG_DWORD
범위: 0-2,500MB 기본값은 60초마다 동적으로 조정.


캐시된 리소스에 대한 TTL값 조정

IIS는 마지막요청후 30초 이내에 재요청이 없을경우캐시를 파기한다. 서버에 메모리 여유가 있다면 캐시에 오래 남아 있을수 있도록 TTL값을 조정해 볼 필요가 있다.

ObjectCacheTTL
레지스트리 경로:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters
데이터 형식: REG_DWORD
기본값: 30초
범위: 0 - 4,294,967,295 (제한 없음)


2009/06/18 13:41 2009/06/18 13:41

IIS 업로드 용량 제한 컨트롤
제가 알기론 2003에서 200K 용량 제한이 있는것으로 알고 있습니다.
이는 MetaBase.xml에 지정되어 있을것인데요.

C:\WINDOWS\system32\inetsrv\MetaBase.xml
을 보시면 AspMaxRequestEntityAllowed="204800" 으로 되어있습니다.
이 값을 변경시켜주면. 200K 용량제한을 해결하실수 있을것입니다.
이거 하시기전에 IIS 중지를 먼저 해주세요


M$계열 서버 부하 통계 알아보기
성능모니터링을 활용하는 방법
http://mudmania.org/reiot/PerformanceMonitoring

Web Application Stress Tool의 이용
http://support.microsoft.com/default.aspx?scid=kb;KO;231282
http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&DisplayLang=en

mrtg
http://mrtg.co.kr/
http://snmpboy.msft.net/default.aspx

log 분석
http://awstats.sourceforge.net


성능 모니터 중요한 몇가지
Processor - % Process Time ||
프로세서 사용률
이 값이 장시간 동안 80% 이상의 값을 나타내면 프로세서의 사용률이 과다한 것입니다.

Memory - Available Bytes
사용가능한 메모리 양입니다
점차 낮아지거나 장시간 동안 시스템 전체 메모리의 20% 미만인 경우에는 메모리가 부족한것입니다.

Web Service - Current Anonymouse users
동시 사용자의 수

ASP - Reqeust Queued
처리를 위해 대기 중인 ASP 스크립트의 수입니다.
동시 사용자 수가 500 이상인 상황에서 이 값이 5 이상의 값을 나타내면 웹 서버의 처리 능력을 초과한 것입니다.

Web Service - Current ISAPI Extension Requests
웹 서버에서 사용하는 DLL형태의 익스텐션이나 컴포넌트에 대한 호출 횟수입니다
동시 사용자 수가 500 이하인 상황에서 이 값이 5 이상의 값을 나타내면 웹서버의 처린 능력을 초과한 것입니다.


[Win2000] 튜닝을 위한 성능 모니터링
1) 성능 모니터링
웹 서버를 튜닝하기 위해서 주요한 도구중에서 성능 모니터링은 웹 서버 뿐만이 아니라 윈도우 2000 서버의 중요한 성능에 대한 각종 사항을 보여주는 유효한 도구 입니다. 성능 모니터링 도구를 이용하여 웹 서버 및 윈도우 2000 서버의 각종 성능을 모니터링 할 수 있는데 이것들은 프로세서와 메모링등 다양한 종류에 대한 카운터 정보를 모니터링 함으로써 추가 하드웨어 구입에 대한 정보나 현재 문제가 되고 있는 병목현상등을 파악할 수 있는 중요한 지표를 제공합니다.
성능 도구는 해당 컨텐트를 개체, 카운터 및 인스턴스로 그룹화합니다. 개체는 가장 높은 추상화 계층으로, 모니터링할 수 있는 리소스나 서비스와 관련된 카운터의 논리적 컬렉션으로 정의됩니다. 카운터는 성능 개체와 관련된 데이터 항목입니다. 선택된 각 카운터에 대해 성능 도구는 성능 개체에 대해 정의한 성능의 특정 측면을 나타내는 값을 제공합니다. 인스턴스는 가장 낮은 추상화 계층으로, 한 대의 시스템에서 같은 유형의 여러 성능 개체 간을 구분하는 데 사용됩니다.

Windows 2000 핵심 카운터
웹 응용 프로그램에서 성능 병목 현상을 검사하기 전에 운영 체제 수준에서 성능 문제점을 찾아야 합니다. 대개 메모리 부족과 같은 리소스 문제로 인해 시스템에서 다른 성능 문제가 발생할 수 있습니다. 시스템 성능을 이해하고 향상시키기 위해서는 시스템의 모든 부분에 대해 병목 현상이 있는가를 검사해야 합니다.
다음 성능 카운터를 면밀히 검사하여 서버에 프로세서, 메모리, 디스크 또는 네트워크 병목 현상이 있는지 확인하십시오. 웹 서버에서 나타나는 성능 병목 현상을 해결하는 데 도움을 주기 위해 각 카운터에 대한 설명과 함께 측정된 임계값, 권장 사항이 제공됩니다. 모든 검사는 2개의 프로세서와 1GB의 물리적 RAM이 있는 웹 서버에서 수행되었습니다. 성능 카운터는 개체:카운터:인스턴스 형식으로 표시됩니다(해당되는 경우).

Memory: Available Bytes ? 이 카운터는 시스템에서 실행되는 프로세스에 사용할 수 있는 실제 메모리 양을 바이트 단위로 표시합니다. 이 값은 Zeroed, Free 및 Stand-by 메모리 목록에 공간을 추가하여 계산합니다. Free 메모리는 사용할 수 있는 메모리이며, Zeroed 메모리는 나중에 프로세스가 이전 프로세스에서 사용한 데이터를 보지 못하게 하기 위해 0으로 채워진 메모리 페이지를 나타내며, Stand-by 메모리는 디스크로 보내지는 프로세스 작업 집합에서 제거되었지만 회수할 수 있는 메모리입니다. 이 카운터는 마지막으로 검색된 값만 표시합니다.

Available Bytes 값이 낮으면(4MB 이하) 시스템의 전체적인 메모리가 부족하거나 프로그램이 메모리를 릴리스하지 않는 경우일 수 있습니다. 4MB의 임계값에 도달하면 시스템의 가상 메모리가 부족함을 나타내는 이벤트 26이 시스템 이벤트 로그에 기록됩니다. 메모리가 낮으면 이벤트가 기록될 뿐 아니라 영향받는 시스템의 성능도 저하됩니다.

메모리 관련 성능 문제를 피하려면 웹 사이트가 최대로 사용될 때를 대비하여 적어도 10%의 메모리를 보유해야 합니다.

Memory: Cache Bytes - 이 카운터는 파일 시스템 캐시의 크기를 보여 줍니다. 이 크기는 설치된 실제 메모리 크기에 따라 최대 900MB까지 사용 가능한 실제 메모리의 50%를 사용하도록 설정됩니다. IIS는 메모리가 부족할 때 자동으로 캐시의 데이터를 지우므로 이 카운터는 중요합니다. 이 카운터를 아래에서 설명하는 Private Bytes와 함께 사용하면 메모리 누수가 있는 응용 프로그램을 격리할 수 있습니다.

Memory: Page Faults/Sec - 이 카운터는 초당 폴트된 평균 페이지 수를 측정합니다. 이 카운터는 하드 폴트(디스크 액세스를 필요로 하는 폴트)와 소프트 폴트(실제 메모리에서 폴트된 페이지가 있는 위치)를 모두 포함합니다. 대부분의 프로세서가 큰 영향 없이 많은 수의 소프트 페이지 폴트를 처리할 수 있습니다. 그러나 디스크 액세스를 필요로 하는 하드 폴트는 심각한 성능 문제를 유발할 수 있습니다. 이 카운터의 값이 낮으면 서버는 빠르게 요청에 응답합니다. 이 값이 높으면 나머지 시스템을 위해 충분한 메모리를 남겨 두지 않고 파일 시스템 캐시에 너무 많은 메모리가 할당될 수 있습니다. 페이지 폴트/초 값이 너무 높으면 서버의 실제 메모리 양을 늘려야 합니다.

Process: Private Bytes: (Inetinfo, Dllhost) - 이 카운터는 Inetinfo가 할당했으며 다른 프로세스와 공유할 수 없는 현재의 메모리 양을 측정합니다. 이 카운터는 이러한 프로세스가 긴 기간 동안 메모리를 릴리스하지 않고 시스템에 더 많은 메모리를 할당하고 있다는 사실을 알았을 때 웹 응용 프로그램의 메모리 누수를 격리시키는 데 도움이 됩니다. 응용 프로그램의 격리 수준이 낮게 설정되면 Private Bytes 카운터에서 Inetinfo 프로세스를 모니터링하십시오. 격리 수준이 보통이거나 높게 설정되면 해당 DLLHost 프로세스를 모니터링하십시오.

System: Processor Queue Length - 이 카운터는 프로세스 대기열에서 실행을 기다리는 스레드의 수를 나타냅니다. 프로세스가 여러 개 있는 컴퓨터에서도 프로세스 시간을 기다리는 준비 대기열은 하나만 있습니다. 이 카운터는 실행 중인 스레드가 아니라 준비 스레드만 계산합니다. 프로세서당 스레드가 2개가 넘는 프로세서 대기열 길이는 서버가 느리게 작동하거나 응답하지 않는 프로세서 정체 상태를 나타낼 수 있습니다. 여러 프로그램 프로세스가 프로세서 시간을 위해 경쟁하는 경우 더 빠른 프로세서를 설치하여 처리량을 향상시킬 수 있습니다. 멀티스레드 프로세스를 실행하는 경우에는 프로세서를 추가하는 것이 도움이 될 수 있지만 이러한 경우에 얻을 수 있는 이점은 제한되어 있습니다.

참고 긴 스레드 대기 상황에서는 한 대의 유휴 시스템에 두 개 이상의 프로세스 대기열이 있을 수 있습니다.

Processor: % Processor Time - 이 카운터는 프로세서가 비유휴 스레드를 실행하는 데 사용하는 시간(%)을 표시합니다. 이 카운터는 프로세서 활동에 대한 기본 지표로, 서버 작동 중단이나 무응답 상태와 같은 문제를 해결하는 데 사용할 수 있습니다. 이 성능 카운터를 분석할 때는 컴퓨터의 역할을 이해해야 합니다. 예를 들어, CAD 응용 프로그램에 주로 사용되는 컴퓨터를 모니터링하는 경우 CAD 응용 프로그램은 실행 중에 100%의 프로세스 시간을 쉽게 사용할 수 있습니다. 많은 클라이언트 요청을 처리하는 서버에서 이 값이 100%에 가깝다면 사용 가능한 프로세서 시간을 기다리기 위해 프로세스가 대기 중이므로 병목 상태일 것입니다. 따라서 서버에서 100%에 가까운 프로세서 사용률을 유지하는 일은 불가능하며, 프로세서를 추가하거나 작업 로드를 수정해야 합니다. 웹 서버에서 허용되는 프로세서 사용률 임계값은 70%입니다.

Network Interface: Bytes Total/Sec - 이 카운터는 네트워크 인터페이스에서 바이트를 보내고 받는 속도를 측정합니다. 네트워크 연결에서 병목 현상이 발생하는지 확인하려면 Network Interface: Bytes Total/sec 카운터 값과 네트워크 어댑터 카드의 총 대역폭을 비교해 보십시오. 급격히 증가하는 트래픽에 대비하려면 용량의 50% 이하만 사용해야 합니다. 이 값이 연결 용량에 거의 근접하고 프로세서와 메모리 사용량에 문제가 없으면 연결에 문제가 있는 것입니다.

Physical Disk: % Disk Time - 이 카운터는 선택한 디스크 드라이브가 읽기 및 쓰기 요청을 처리하는 시간을 측정합니다. 이 카운터 값이 높으면(90% 초과) Physical Disk: Current Disk Queue Length 카운터를 검사하여 디스크 액세스를 기다리는 시스템 요청 수를 확인해야 합니다. 대기 I/O 요청 수는 실제 디스크를 구성하는 스핀들 수의 1.5-2배 수준으로 유지되어야 합니다. 스핀들 정보에 대해서는 서버 제조업체에 문의하십시오. 일반적으로 대부분의 디스크에는 스핀들이 하나만 있지만 RAID 장치에는 더 많은 스핀들이 있습니다. 하드웨어 RAID 장치는 시스템 모니터에 하나의 실제 디스크로 나타나지만 소프트웨어를 통해 만들어진 RAID 장치는 여러 드라이브로 나타납니다. 각 실제 드라이브(RAID가 아닌)의 Physical Disk 카운터를 모니터링하거나 _Total 인스턴스를 사용하여 모든 컴퓨터 장치의 데이터를 모니터링할 수 있습니다.

Physical Disk: Current Disk Queue Length 및 Physical Disk: % Disk Time 카운터 값을 사용하여 디스크 하위 시스템의 병목 현상을 찾아 내십시오.이들 값이 모두 높으면 디스크 드라이브를 업그레이드하거나 자주 액세스하는 파일을 다른 디스크나 서버로 옮기는 것을 고려할 수 있습니다.

참고 RAID 장치를 사용하는 경우 % Disk Time이 100%보다 더 큰 값을 나타낼 수 있습니다. 이 경우 Physical Disk: Average Disk Queue Length 카운터를 사용하여 평균적으로 디스크 액세스를 기다리는 시스템 요청의 수를 확인하는 방법을 고려해야 합니다.

웹 응용 프로그램 성능 카운터
Microsoft는 관리자들이 웹 응용 프로그램의 문제점을 규명하는 데 도움을 주기 위해 성능 도구에 몇 가지 개체를 제공하고 있습니다. 아래의 웹 응용 프로그램 성능 카운터를 사용하여 응용 프로그램에 성능 병목 현상이 있는지 확인하십시오. 응용 프로그램의 성능 문제점을 빠르게 확인하고 해결하는 데 도움을 주기 위해 각 성능 카운터에 대한 설명과 임계값 및 권장 사항이 제공됩니다. 모든 임계값과 권장 사항은 프로세서가 두 개 있고 RAM이 1GB인 웹 서버에서 측정한 결과에 따른 것입니다. 성능 카운터는 개체:카운터:인스턴스 형식으로 표시됩니다(해당되는 경우).

Active Server Pages:Requests Executing - 이 카운터는 현재 실행 중인 요청의 수를 계산합니다. 이 카운터는 응용 프로그램이 한 번에 하나의 요청을 효율적으로 실행하는지 여부를 나타냅니다. 요청이 하나씩 실행되면 알려지지 않은 원인으로 인해 요청이 serialization됩니다. 일반적으로 인터넷 서비스 관리자를 통해 ASP 디버깅을 설정하면 serialization이 발생합니다.

자세한 내용과 코드 serialization의 예를 보려면 다음을 참조하십시오.

InProc 구성 요소(DLL)를 사용할 경우의 차단

Active Server Pages:Requests Queued - 이 카운터는 대기열에서 서비스를 기다리는 요청의 수를 측정합니다. 이상적인 값은 0입니다. 이 값이 계속 증가하면 ASP는 스레드를 차단하며, 대기열의 다른 요청을 처리할 수 있도록 스레드가 릴리스되지 않습니다. 스트레스 상황에서 Requests Queued 값이 상당히 증가하면 프로세서 사용률은 비교적 낮은상태를 유지하고 이것은 스크립트가 처리할 수 있는 것보다 많은 호출을 수신하는 COM 개체를 호출하고 있다는 표시입니다. 이 경우 COM 개체는 병목 현상을 발생시킵니다. 이 경우 IIS가 만드는 프로세서당 최대 작업자 스레드 수를 지정하는 ASPProcessorThreadMax 메타베이스 항목을 늘려야 합니다.

ASPProcessorThreadMax 메타베이스 항목에 대한 자세한 내용은 다음을 참조하십시오.

ASPProcessorThreadMax를 조정하는 방법

Active Server Pages: Sessions Total - 이 카운터는 서비스가 시작된 후의 전체 세션 수를 측정합니다. 특정 테스트 스크립트에 대해 만들어진 전체 세션을 모니터링하는 경우 보다 정확한 측정을 위해 테스트 실행 전에 웹 서비스를 중지했다가 다시 시작하는 것이 좋습니다. 스크립트가 실행 중인 경우 Sessions Total 값은 원하는 수준에 도달할 때까지 서서히 증가합니다. Sessions Total이 원하는 수준에 도달하지 않으면 웹 서비스를 중지했다가 다시 시작한 다음 다른 테스트를 실행할 수 있습니다.

Web Service: CGI Requests/sec 및 ISAPI Extension Requests/Sec - 이 카운터는 서버가 CGI 및 ISAPI 응용 프로그램 요청을 처리하는 속도를 측정합니다. 로드가 증가하는 동안 이 값들이 감소하면 응용 프로그램 개발자들에게 코드를 확인하도록 지시할 수 있습니다.

Web Service: Get Requests/Sec 및 Post Requests/Sec - 이 카운터는 서버에 두 가지 유형의 HTTP 요청이 수행되는 속도를 나타냅니다. POST 요청은 일반적으로 폼에 사용되며 ISAPI(ASP 포함) 또는 CGI로 전송됩니다. GET 요청은 POST 요청을 제외한 거의 모든 브라우저의 요청을 나타내고 정적 파일, ASP 및 기타 ISAPI 요청, CGI 요청 등을 포함합니다. 이러한 카운터는 사이트의 일반 로드 특성을 이해하는 데 많은 도움이 됩니다.





[Win2000] IIS 튜닝 하는 방법 자료에 대해서
웹컨텐트에 대한 보안과 함께 액세스가 빈번한 대용량 사이트라면 기본설정으로는 무리가 따르게 되므로 적절한 튜닝이 더욱 필요하다. 이런 튜닝 기술은 단순한 직감으로 수행될 수 없으므로 원리와 효과를 예측할 수 있도록 지식을 쌓는 것이 중요하다. 하지만 사용하는 시스템 환경에 따라 경우가 천차만별이므로 절대적인 기준을 제시하기는 어렵다. 그러므로 웹서버 트래픽 분석 및 적절한 벤치마킹을 통해 전문가들이 가이드라인을 제시하는 것이 일반적이다. (이 튜닝 포인트 가이드는 IIS 4.0을 기준으로 함). 다시 강조하지만 이러한 가이드조차 절대적인 것이 없으므로 웹관리자 스스로 서버 벤치마크 도구와 트래픽 분석을 통해 본인의 사이트에 맞는 기준을 설립하는 것이 중요하다.

1. 전체적인 튜닝 포인트
NT 서버는 그 사용도에 따라 서버를 최적화할 수 있도록 '사용 메모리 최소화', '균형 유지', '파일 공유 처리량 최대화', '네트워크 응용 프로그램 처리량 최대화' 등 4개의 서버 옵션을 제공한다.
NT 도움말을 보면 네트워크에 연결에 할당된 메모리와 사용자 컴퓨터에서 실행중인 응용 프로그램에 할당된 메모리 사이의 관계를 바로 이 옵션을 통해 조정할 수 있다고 돼 있다. 그러나 독자들의 관심사는 웹서버인 IIS 4.0일 것이므로 서버 최적화 옵션을 '네트워크 응용 프로그램 처리량 최대화'로 설정해 IIS 서버가 보다 많은 메모리를 사용하도록 하면 성능을 높일 수 있다.

IIS 서버는 파일 서버에 비해 페이지 오류(page fault)가 더 많이 발생하므로 파일 캐시 기능을 강화하기 위해 서버 옵션을 위와 같이 설정해야 한다고 되어 있다. 페이지 오류란 가상 메모리와 관련된 기술용어로 응용 프로그램에서 사용하는 가상 메모리 중 물리적인 메모리에 적재돼 있지 않은 곳을 프로그램에서 읽으려고 할 때 발생하는 시스템 이벤트다. 일단 페이지 오류가 발생하면 운영체제는 응용 프로그램에서 하던 일을 전부 멈추고 이 문제를
해결하기 위해 디스크로 스왑핑돼 있던 가상 메모리 영역 중 프로그램에서 요구한 부분을 물리적인 메모리로 읽어 오는 작업을 하게 된다. 그런데 문제는 디스크 읽기/쓰기 작업이 메모리 읽기/쓰기 작업에 비해 엄청나게 시간이 오래 걸린다는 점이다. 따라서 페이지 오류가 많이 발생하는 응용 프로그램에서 사용하는 가상공간은 가능한 물리적인 메모리 안에 두는 것이 성능을 극대화시킬 수 있는 것이다. 이것 서버 최적화 옵션을 선택하는 원인과 예
상할 수 있는 효과이다.

초창기 웹서버인 NCSA부터 시작해 거의 모든 웹서버는 '로깅(logging)' 기능을 가지고 있다. 로그에는 웹컨텐트 사용자에 대한 각종 정보가 담겨져 있어 문제점을 파악하고 사용자의 취향에 대한 판단을 할 수 있는 중요한 근거가 된다. 그러나 수백명이 웹서버를 이용하고 있는 상황에서 웹서버는 사용자가 원하는 파일을 개별적으로 가져다주기도 힘겨운데, 요구한 각 파일마다 로그기록을 남기도록 한다면 웹서버가 스트라이크(?)를 일으키는 상황이 종종 발생하게 된다. 이에 대해 튜닝 가이드는 사용자 경향을 어느 정도 파악한 사이트라든지, 성능이 무척 중요한 사이트라면 IIS 로깅 기능을 끄도록 권하고 있다. 로그를 반드시 봐야 한다면 일부 파일에 대한 로깅만 수행하는 '부분로깅'을 동작시키던지, 아니면 로그를 기록하는 디스크에 대한 부담을 줄이기 위해 스트라이프 파티션에 로그 파일을 두면 서버 성능 저하를 피할 수 있다.

2. 네트워크 튜닝 포인트
웹서버의 기반 프로토콜인 HTTP, FTP는 TCP/IP 위에서 동작하기 때문에 TCP/IP 설정 방법에 따라 성능차가 크게 나게 된다. 일반적인 응용 프로그램 서버로 NT 서버를 사용할 때에는 굳이 TCP/IP 설정을 바꿀 필요가 없지만, 사이트 규모가 큰 경우에는 보다 효율적인 운영을 위해 손질할 필요가 있다.
여기서는 NIC 파라미터와 TCP 파라미터에 대한 튜닝에 대한 포인트를 설명하기로 하고, 참고로 HTTP도 1.1 스펙을 보면 성능 향상을 위해 몇 가지 추가된 기능이 들어 있다. 이 기능은 클라이언트와 서버 모두에서 HTTP 1.1 스펙을 지원해야 하기 때문에 한계가 있지만 TCP/IP 상위 프로토콜에서도 튜닝할 부분이 있다는 점만은 알아두는 것이 좋다(보다 자세한 내용은 옵션팩 온라인 도큐먼트 중 IIS 서버 관리, 성능 튜닝 부분을 참조).
TCP/IP 프로토콜에서는 슬라이드 윈도우 기법을 사용해 흐름 제어(flow control)를 수행한다. 흐름 제어란 물리적인 네트워크에 통신 패킷들이 어느 한 곳에서 막히지 않고 원활히 지나다닐 수 있도록 제어하는 기법을 말한다. 여러 가지 흐름제어 방법 중 TCP/IP는 특정 윈도우 크기만큼 데이터 패킷들을 보내고 ACK를 받는 방식으로 흐름을 제어한다. 따라서 빠른 네트워크를 사용할 때는 윈도우 버퍼 크기를 크게 잡으면 잡을수록 보다 많은 데이터를
한꺼번에 전송할 수 있으므로 성능이 높아진다. 하지만 느린 네트워크에서는 오히려 문제가 발생할 소지가 있으므로 이 방법이 항상 좋은 것은 아니다. 이 값은 레지스트리 편집기인 regedt32.exe를 사용해 HKEY_LOCAL_MACHINE\CurrentControlSet\TCPIP 파라미터를 찾아보면 알 수 있는데, TcpWindowSize이다. 튜닝 가이드에 의하면 약 0x4470 정도로 값을 설
정하면 된다.
또다른 TCP/IP 파라미터로 'MaxUserPort'라는 것이 있다. 이 파라미터는 웹클라이언트에서 웹서버에 접속할 때 사용하는 사용자 포트의 최대 개수를 지정하는 키값을 의미하기 때문에 많은 사용자들이 서비스를 받고자 할 때 사용자 포트의 부족으로 패킷이 드롭(drop)돼 재전송되는 현상을 줄이고자 크게 잡는다. 튜닝 가이드에 의하면 0xfffe 정도로 설정하라고 되어있다.

3. 멀티 CPU 튜닝 포인트
여러 개의 CPU가 있는 시스템은 보다 빠르게 처리하도록 작업을 여러 CPU에 배분시킨다. 이렇게 배분된 작업은 쓰레드란 단위로 각 프로세서에서 실행된다. 쓰레드란 프로세서보다 가벼운 실행 단위로 순차적으로 실행되는 쓰레드(thread)를 의미한다. 요즘 출시되는 대부분의 서버는 다중쓰레드 구조를 가지고 있어, 동시에 여러 작업을 서버 내에서 처리하도록 되어 있다. IIS 4.0도 다중쓰레드를 사용해 웹클라이언트에서 요청한 작업을 여러 CPU에 분산시켜 처리 성능을 높인다. 그런데 만약 웹클라이언트에서 특정 파일을 요구하
고 난 후 IIS 서버가 그 작업용으로 쓰레드를 할당하려고 하는데 사용할 수 있는 쓰레드가 없는 경우가 발생한다면? 요구 자체를 지연(block)시킬 수밖에 없고, 사용 가능한 쓰레드가 생길 때까지 멈추게 된다. 결국 사용할 수 있는 쓰레드수의 부족으로 웹서버 성능이 저하될 수 있다는 얘기다.
현재 얼마나 많은 쓰레드가 실행중인가를 확인하려면 윈도우 NT 성능 모니터를 실행시킨 후 'System' 개체에서 'Processor Queue Length' 카운터를 차트에 추가하면 현재 시스템의 프로세서 큐 길이를 지켜볼 수 있다. 이 값은 현재 실행중인 쓰레드를 표시하지 않기 때문에 보통 상황에서는 1의 값을 가진다. 이 값은 프로세서가 N개일 때, N에서 3×N 정도로 설정하면 좋다. 이 값이 의미하는 바나 적절한 값을 잘 모르겠으면 건드리지 말고 디폴트로 놓도록 하되, IIS에서 사용하는 쓰레드수를 늘려주고 컨텍스트 스위치 횟수를 줄
이는 방향으로 튜닝해야 한다. 예를 들면, IIS 로드가 일정한 정적 환경에서는 MaxPoolThreads는 1로, PoolThreadLimit를 N으로 설정하도록 권장하고 있다. 이렇게 구성하면 프로세서 당 1개씩 쓰레드를 배치시켜 컨텍스트 스위치 횟수를 줄이는 동시에 IIS에서 사용할 수 있는 쓰레드의 개수를 늘려주므로 좀더 나은 성능을 얻을 수 있다.

4. 정적 환경에서의 튜닝 포인트
IIS 4.0에서는 객체 캐시 기능을 제공해 객체에 대한 사용이 끝나도 일정한 시간 동안 메모리에 가지고 있다가 다시 사용할 때 디스크에서 읽어올 필요 없이 곧바로 캐시 안에 있는 객체를 사용한다. 객체가 캐시 내에서 유지되는 시간을 TTL(Time To Live)라고 하며, 디폴트 값은 30초로 되어 있다. 만약 웹사이트 내용이 메모리에 적재될 정도이고 자주 바뀌는 것이 아니라면, 아에 TTL을 0xffffffff로 설정해 객체가 항상 캐시 안에 있도록 할 수도 있지
만, 대다수의 경우에는 메모리 안에 웹컨텐트가 모두 적재되지 않기 때문에 TTL값을 적절히 조절해야 할 필요가 있다.
아주 자주 사용되는 파일이 있다면, 이 TTL값을 크게 설정해 성능 향상을 꾀할 수도 있다. 반면 자주 요청되는 파일들이 많은 경우에는 TTL값을 크게 해도 성능 증대를 기대할 수 없고, TLL 값을 낮춰 캐시 안에 있는 객체수를 줄임으로써 시스템 자원이 고갈되는 것을 막을 수 있다. 캐시 안에 유지되는 파일수는 다음에 설명될 OpenFileInCache값을 조절하면 조정이 가능하다.
TTL 값은 레지스트리키인
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters안에 있는 ObjectCacheTTL값으로 설정된다.

IIS는 또한 캐쉬 안에 유지되는 파일 핸들의 수를 지정할 수 있도록 OpenFileInCache라는 레지스트리값을 제공한다. 이 값은 한번 열려진 파일에 대한 핸들을 몇 개나 저장하겠느냐를 의미하는 것으로 IIS 캐시용으로 할당할 수 있는 메모리양과 캐시 내에 저장하길 원하는 파일 핸들의 수에 따라 달라진다. 일반적으로 큰 웹사이트에서는 보다 많은 파일핸들을 캐싱시켜 성능을 높일 수 있으며, 일정한 파일만을 가진 웹사이트의 경우에는 그 파일
수보다 큰 값으로 OpenFileInCache값을 설정해 모든 파일들을 디스크 입출력 없이 메모리에서 파일을 읽어옴으로써 성능을 극대화할 수도 있다. 이 값을 적절히 선택하기 위해서는 NT성능 모니터를 사용해 'Internet Information Server Gobal' 개체 중 'Cached File Handles' 카운트값을 모니터링함으로써, 메모리 낭비없이 어느 정도면 많이 사용하는 파일 핸들을 캐시 내에 저장할 수 있을지를 예상할 수 있을 것이다.

5. 액티브 서버 페이지 튜닝 포인트
IIS 4.0은 MTS 2.0과 통합돼 각종 ASP 스크립트나 COM 컴포넌트들에 대해 트랜잭션 성격을 부과할 수 있게 됐다. IIS는 MTS의 실행을 위해 CPU당 일정한 수의 쓰레드를 할당해 놓는다. 이 값은 레지스트리 키 중 HKEY_LOCAL_MACHINE\System\CurrentControlSet\ServicesW3SVC\ASP\Parameters안에 있는 ProcessorThreadMax값으로 설정할 수 있다. 잘 만들어진 ASP의 경우라면 이 값이 적을수록 경쟁 감소 효과가 일어나므로 이 값을 줄여보고 성능을 모니터링한 뒤, 만약 성능이 떨어지면 원상태로 복귀하는 방식으로 튜닝하면 된다.
ProcessorThreadMax와 연계된 튜닝 포인트로 AspScriptEngineCacheMax라는 값이 있다. 이 값은 대개 ProcessorThreadMax값에 시스템에서 제공하는 프로세서의 수를 곱한 값으로 설정한다. 이렇게 설정함으로써 각 ASP 쓰레드가 좀더 효과적으로 ASP 페이지들을 처리하도록 스크립트 엔진들을 하나씩 캐시하게 된다.
또한 ASP 응용 프로그램들에서 클라이언트로 출력되는 모든 내용을 버퍼링한 후 마지막에 한꺼번에 출력시킴으로써 성능을 높일 수도 있다. 이 기능은 MS 관리 콘솔에서 인터넷 인포메이션 서버 스냅인(snap-in)을 선택하고, 특성을 선택한 후 'Home/Virtual Directory' 특성 페이지를 열고, 'Configuration' 버튼을 누르고, 'App Options'에서 'Enable Buffering'을 클릭하면 된다.
ASP 안에서 세션을 유지하기 위해 '세션객체(session object)'를 사용하는데, 이 객체를 계속해서 유지하려면 시스템 자원을 점유하게 된다. 만약 1000명의 사용자가 동시에 연결된다면, 각 사용자당 세션 상태를 유지시키기 위해 굉장히 많은 양의 시스템 자원을 점유해야 한다. 세션을 유지하는 한 시스템 자원을 점유해야 하므로 세션 타임 아웃값을 적절히 설정한다면, 서버 자원 사용을 최적화할 수 있을 뿐만 아니라 성능 또한 증대시킬 수 있다.
웹 응용프로그램은 또한 In-process와 Out-of-process를 지원하는데 성능면에서는 In-process를 사용하는 것이 바람직하다. Out-of-process는 주로 개발 기간에 웹 응용프로그램에 Bug가 내제 되어 있는 시점에 전체 IIS 서버에 영향을 안 끼치기 위한 방법으로 사용된다.


성공적인 NT 웹서버 관리를 위해
NT 서버의 성능 및 보안체계 튜닝 작업은 가상 시뮬레인션인 벤치마킹과 실제 데이터인 로그 데이터, 성능 데이터를 기반으로 하고 있으므로 실제 튜닝 작업에 들어가기 전에 관련 도구 및 데이터 분석 능력도 함께 키워야 제한된 능력만을 가진 서버 관리자에서 벗어나 고급 관리자로 탈바꿈할 수 있을 것이다.
저작권 (주)마이크로소프트
http://www.microsoft.com/korea/support/kb/K000987.htm


추가적인 자료입니다
1.IIS 4.0 Tuning Parameters for High-Volume Sites (March 9, 1998)
http://msdn.microsoft.com/workshop/server/feature/tune.asp

2.Server Performance and Scalability Killers(February 22, 1999)
http://msdn.microsoft.com/workshop/server/iis/tencom.asp




[Win2000] Windows 2000 과 IIS 관리자들을 위한 점검사항 리스트

1.OS System 측면
International English 버전으로 설치
Windows OS 의 HotFix(Patch 또는 Update)가 1주일에 거의 1번 꼴로 발생한다.
그러나, 대부분이 영어버전용이고 다국어 버전에서는 어떻다는 말이 없다. 특수한 경우에는 다국어 버전의 파일을 별도로 제공하고는 있지만 나머지는 다국어 버전에서 그냥 사용해도되는지 알 수 없다. 사용하다 문제가 발생하면 누구의 책임이겠는가? 모든 것이 관리자의 책임이다.
따라서, 이런 고민을 하지 않으려면 영어버전(국내에서 판매되는 International English)버전을 사용하기 바란다.

버전관리
Boot Script 를 활용하여 서비스팩과 핫픽스을 업데이트

계정 관리
- 계정별 권한관리.
Perms.exe : 사용자별 파일/디렉토리 액세스권한을 확인할 수 있다.

계정암호 관리
- 최소길이 7자 추천(최대 127자)
- 특정 단어사용하지 말것(사전에 나오는 문자사용불가)
- 영문자(대소문자 혼용)+숫자+기호(!$%& 등의 특수 문자)
- 원격 암호변경 불가능하도록 설정 : 해커가 관리자의 암호를 마음대로 수정하는 것을 방지한다.
- 암호사용기간 및 암호기록 횟수 지정 : 일반적으로 사용자들은 한 번 정한 암호를 바꾸지 않는다. 이 것을 방지한다.

Storage 관리
- NTFS 파티션 : 적어도 Web 관련된 부분만큼은 NTFS 로 지정되어 있어야 한다.

로그관리 - 이벤트 표시기를 통한 보안/시스템/응용프로그램 로그를 항상 주시하여 언제 발생할지 모르는 사고와 사태에 대비하여야 한다. 노란색으로 표시되는 경고메시지는 잠재된 에러를 뜻하므로 경계를 게을리하면 안된다.

로그온감사 : 사용자 로그온 기록을 남기자
- ID 사용을 감시할 수 있으므로 불법 ID 확인이 가능하다.

보안관리 : Microsoft 보안 알림서비스 메일링리스트 가입
- 제목, 내용없이 메일을 보내면 가입을 확인하는 메일이 오는데, 이 메일에 회신하면 가입축하메일이 온다.



2.네트워크 측면
Ping 받지않기(ICMP 패킷 차단하기)
Windows 2000 의 경우, IPSec 을 사용하여 ICMP 패킷을 차단할 수 있다.

Web 서비스 전용기기로 설치하기
웹 서버를 파일서버등과 분리하는 것은 보안적 측면이나 속도를 고려해서 추천할 만한 방법일 것이다.

네트워크에서 분리하기
웹 서비스 기기는 다른 업무용 기기와 분리되는 것이 좋으나, 하나의 기기로 여러 개의 작업을 하는 경우라면 서버측에 랜카드를 두개 설정하고 IP 주소를 분리하는 방법도 고려해 볼만하다.

Qos 를 이용한 대역폭관리

방화벽이용
방화벽을 이용할 경우, Windows 의 서비스들은 각각의 port 를 사용한다.
\\…\system32\drivers\etc\service.txt 를 참조한다.


3.DNS 측면
외부에서 nslookup 으로 DNS 정보를 볼 수 없게 설정한다.
DNS서버의 웹사이트의 등록정보에 보면 “영역 전송” 탭에서 체크박스를 체크해주고 아래에 영역을 전송할 서버를 입력하여 주면 됩니다.
이 것을 "아무서버로" 라 설정하면 말 그대로 영영정보를 요청하는 모든 곳에 영역을 전송하게 됩니다. 즉, 이를 막는 방법을 사용하려면 특정서버(연결된 ISP 의 DNS 서버 권장)로의 연결만을 허락하는 것이 좋습니다.


4.IIS 측면
버전관리
- HFCheck : HotFix 적용확인 도구

보안관리
- IISCONFIG :
- IISLock : IIS 5.0 설정을 쉽게 해준다.
- What If : IIS 보안 확인도구(시나리오를 이용한 보안성 확인)
- 보안체크리스트(원문)

응용프로그램보안
- IIS 응용프로그램레벨의 보안방화벽 Secure IIS 추천

IIS 무응답상태 : ASP Queue 관리
- set objVar = nothing
- IIS 서비스가 무응답으로 빠지는 문제는 대부분 ASP에서 Object 변수를 Nothing 처리를 하지 않았기 때문입니다.
- 퍼포먼스관리자의 ASP Requested Queue 의 수가 0 이어야 한다. ASP 가 하나씩 실행될 때마다 1 씩 증가하며, 종료되면 1 씩 감소한다. 따라서 정상적인 ASP 코드의 경우에는 늘어난 만큼 감소하여 나중에는 0이 되어야한다.

webroot 보안 십계명

unicode 문제
- 디렉토리/파일의 이름에 유니코드등 2 바이트문자를 사용하지 않는다.(영문만 사용한다)
- 가급적 실행권한을 주지 않는다.
- 필요한 경우가 아니라면, IIS 설치시 기본적으로 설치되는 IISAdmin, IISSample 등의 디렉토리를 지운다.

웹용량 분석
- MS Web Capacity Analysis Tool

웹캐쉬제어

ASP 성능향상
- Tip 1
- Tip 2


5.사이트관리측면
- 관리자와 서버간 통신은 VPN / SSL 등으로 보호하자.
- Terminal Service 보안


6. 참고 list 및 문헌
윈도우 NT서버 및 IIS 보안 관리
- http://www.ntfaq.co.kr
- http://www.ntsecurity.com
- http://www.ntsecurity.net
- http://www.microsoft.com/security
- http://www.microsoft.com/technet/security
- 공짜로 경험하는 강력한 네트워크관리



[Win2000] IIS 5.0 실행에 필요한 최소 NTFS 권한
이 문서에서는 IIS 5.0 웹 사이트에 필요한 최소 NTFS 액세스 권한에 대해 설명합니다. IIS를 설치할 때 이미 기본 웹 사이트와 기본 FTP 사이트에 대해 적절한 NTFS 액세스 권한을 갖고 있어야 합니다. 올바른 NTFS 권한이 필요한 폴더가 많이 있습니다. 이러한 폴더 중 하나의 설정이 틀리면 다음 중 하나 이상의 오류가 발생할 수 있습니다.

웹 브라우저의 오류:

You are not authorized to view this page
You do not have permission to view this directory or page using the credentials you supplied.

HTTP 401.3 - Access denied by ACL on resource
Internet Information Services

-또는-

웹 브라우저의 오류:

Server Application Error
The server has encountered an error while loading an application during the processing of your request. Please refer to the event log for more detailed information. Please contact the server administrator for assistance.

시스템 로그의 오류 설명:

Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 36
Date: 3/5/2001
Time: 9:59:40 AM
User: N/A
Computer: MACHINE-NAME
Description:
The server failed to load application '/LM/W3SVC/5/Root'. The error was 'General access denied error'.
For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp.

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10001
Date: 3/5/2001
Time: 9:59:40 AM
User: NT AUTHORITY\SYSTEM
Computer: MACHINE-NAME
Description:
Unable to start a DCOM Server: {99169CB1-A707-11D0-989D-00C04FD919C1} as ./IWAM_MACHINE-NAME. The error: "Access is denied. " Happened while starting this command: C:\WINNT\System32\dllhost.exe /Processid:{3D14228D-FBE1-11D0-995D-00C04FD919C1}

-또는-

웹 브라우저의 오류:

Error: Access is Denied.

시스템 로그의 오류 설명:

Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 30
Date: 3/5/2001
Time: 10:01:13 AM
User: N/A
Computer: MACHINE-NAME
Description:
The server was unable to read the file C:\WINNT\help\iisHelp\common\401-3.htm. The file does not exist. For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp.

원인
NTFS 권한이 기본 설정에서 변경되어 IIS 5.0 실행 권한으로는 충분하지 않습니다.

해결 방법
참고: 본 문서에서 설명하는 단계를 수행하면 IIS 5.0 컴퓨터에서 관리자만 소프트웨어를 설치하거나 실행할 수 있도록 권한이 제한됩니다. 이 문서에서 지정한대로 권한을 재설정한 후에는 인터넷 서비스 관리자를 통해 각 웹 사이트에 대해 Server Extensions 확인 작업을 수행해야 합니다. FrontPage 클라이언트가 HTTP 프로토콜을 사용하여 연결될 수 있으려면 이 단계가 필요합니다.

Windows 탐색기를 사용하여 다음과 같이 하십시오.

전체 하드 드라이브를 다음과 같이 설정합니다.


SYSTEM - 모든 권한
ADMINISTRATORS - 모든 권한


이렇게 설정하려면 고급을 누르고 모든 자식 개체의 사용 권한 재설정 및 상속 가능한 사용 권한 전파 허용을 선택합니다.

참고: Pagefile.sys 파일에 사용 권한을 적용하려고 하면 오류 메시지가 나타납니다. 이 오류 메시지와 유사한 모든 오류 메시지에 대해 계속을 누르십시오.


Program Files\Common Files의 경우 Everyone을 추가하고 읽기 및 실행, 폴더 내용 보기 및 읽기를 선택합니다.

참고: 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음 확인란을 선택 취소하지 마십시오.


Inetpub\Wwwroot의 경우 IUSR_MACHINE을 추가하고 읽기 및 실행, 폴더 내용 보기 및 읽기를 선택합니다.

참고: 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음 확인란을 선택 취소하지 마십시오.


Winnt\System32 폴더에서 Inetsrv 폴더와 Certsrv 폴더를 제외하고 모든 폴더를 선택합니다.

이러한 폴더의 등록 정보 시트를 열고 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음을 선택 취소합니다. 나타나는 대화 상자에서 복사를 누릅니다. 확인을 눌러 등록 정보 시트를 종료합니다.


Winnt 폴더에서 Downloaded Program Files, Help, IIS Temporary Compressed Files, Offline Web Pages, System32, Tasks, Temp 및 Web 폴더를 제외하고 모든 폴더를 선택합니다.

이러한 폴더의 등록 정보 시트를 열고 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음을 선택 취소합니다. 나타나는 대화 상자에서 복사를 누릅니다. 확인을 눌러 등록 정보 시트를 종료합니다.


Winnt의 경우 Everyone을 추가하고 읽기 및 실행, 폴더 내용 보기 및 읽기를 선택합니다.

참고: 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음 확인란을 선택 취소하지 마십시오.


Winnt\Temp(ASP 페이지에서 Access 데이터베이스를 볼 수 있게 해줌)의 경우 Everyone 그룹(이 그룹은 Winnt 폴더에서 상속하여 이미 존재해야 함)을 선택하고 수정을 선택합니다.


추가 정보
각 시스템 관리자의 필요에 맞게 사용 권한을 특수화할 수도 있지만 IUSR_MACHINE 계정 대신 Everyone 그룹을 사용하는 것이 좋습니다.

Everyone 그룹은 사용자 그룹, IUSR_MACHINE 계정 및 IWAM_MACHINE 계정을 포함합니다.

IIS 5.0에서는 웹 페이지를 실행하는 데 별도의 두 가지 계정을 사용합니다. 익명 인증을 사용할 경우 IIS는 IUSR_MACHINE 계정을 사용하여 해당 페이지를 봅니다. 그러나, Dllhost.exe라는 별도의 프로세스를 시작할 때는 IWAM_MACHINE을 사용합니다. 모든 ASP(Active Server Page), 구성 요소 개체 모델(COM) 구성 요소 또는 기타 ISAPI 확장(ASP는 ISAPI 확장으로 간주됨)이 Dllhost.exe 프로세스 내부에서 실행됩니다. 이것은 주로 안정성을 위한 것입니다. ASP 페이지에서 호출된 사용자 지정 COM 구성 요소가 동작하지 않아도 즉, 액세스 위반으로 인해 프로세스가 중단되어도 Inetinfo.exe가 영향을 받지 않아 웹 서비스가 계속 실행됩니다.

IIS 4.0의 두 가지 보호 수준은 아래와 같습니다.

기본설정: IIS 4.0이 프로세스 내 즉, SYSTEM 계정에 의해 시작되는 Inetinfo.exe 프로세스 내부에서 모든 응용 프로그램을 시작합니다. 웹 페이지가 나타나면 해당 페이지를 서비스하는 특정 스레드가 IUSR_MACHINE 계정의 컨텍스트에서 실행됩니다. HTM, ASP 및 그 밖의 다른 ISAPI 확장이 Inetinfo.exe 내부에서 실행됩니다.


구분 메모리 공간에서 실행(격리된 프로세스): 이를 out-of-process라고도 합니다. IWAM_MACHINE 계정을 사용하여 ASP와 그 밖의 다른 ISAPI 확장을 실행하는 별도의 Mtx.exe 프로세스를 만듭니다.


IIS 5.0의 세 가지 보호 수준은 아래와 같습니다.

낮음(IIS 프로세스): 이 설정은 IIS 4.0의 기본 설정과 유사합니다. 모든 웹 페이지가 HTM인지 아니면 ASP인지에 관계 없이 Inetinfo.exe 프로세스 내부에서 실행됩니다.


보통(풀링됨): 이것이 기본값입니다. IIS 4.0에서처럼 이 설정은 모든 ASP 및 COM 구성 요소가 실행되는 Dllhost.exe라는 별도의 프로세스를 시작합니다. 이 프로세스는 IIS 4.0에서처럼 IWAM_MACHINE 계정에 의해 시작됩니다. 또한, 이 설정은 IIS에서 실행하는 모든 웹 사이트가 ASP 페이지를 실행하는 데 이 단일 Dllhost.exe를 공유하므로 풀링됨이라고도 합니다. Windows 2000에서는 Mtx.exe가 Dllhost.exe로 대체됩니다.


높음(격리됨): 이 설정은 각 웹 사이트나 응용 프로그램에 대해 전용 Dllhost.exe 프로세스를 시작합니다. 5개의 웹 사이트가 있고 각각 높은 수준의 보호로 설정되어 있으면 총 6개의 Dllhost.exe 프로세스 즉, 5개의 Dllhost.exe 프로세스 외에 시스템 응용 프로그램 아래에서 COM+가 시작하는 추가 Dllhost.exe 프로세스 하나가 더 시작됩니다.


참조
Windows 2000의 기본 NTFS 권한을 복원하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com/support/kb/articles/Q266/1/18.ASP

Q266118 How to Restore the Default NTFS Permissions for Windows 2000

추가 검색어: iis 5 NTFS permission


[Win2000] IIS 웹 인증을 구성하는 방법
http://support.microsoft.com/kb/308160/ko


IIS에서 ASP에러 보이게 하기
웹사이트 등록정보를 보시면 사용자 정의 오류 탭이 있습니다 ..
그중에서 500-100을 편집누르시고 url로 고치신다음 url로는 /iishelp/common/500-100.asp
를 써주시고 ...다음 그 웹사이트에서 가상 디렉토리명을 iishelp로 잡으시면 됩니다.
가상 디렉토리를 만드실때 존재하는 디렉토리는 os가 설치된 드라이브의 winnt\help\iishelp 가 됩니다.
그러시면 원하시는 asp 오류메세지를 보실수 있습니다.


IIS 사용자 정의 HTTP 헤더
사용자 정의 헤더 이름 P3P
값 CP='CAO PSA CONi OTR OUR DEM ONL'
쿠키 설정하는 부분을 자동적으로 처리


[IIS] SMTP Error 0x8009000f - Object already exists
* Support.Microsoft.com
http://support.microsoft.com/default.aspx?scid=3Dkb;EN-US;q294274

* iisFAQ
http://www.iisfaq.com/default.aspx?View=R288&P=154

* Google.co.kr
http://www.google.co.kr/search?hl=ko&ie=UTF-8&oe=UTF-8&newwindow=1&q=0x8009000F&lr=

* Solve this Problem
1. Read MSKB
2. ReInstall SMTP
3. Had the same problem trying to install IIS. MS's solution did not work

### so deleted files in MachineKeys folder & was successful. ###

Windows 와 .NET 관련 IIS 세팅

UNable to create web project
One suggestion is to add the .tmp extension to the MIMEMap entries in IIS (open
IIS MMC Snapin, right click on local computer node, select Properties, MIMEMap,
and add the .tmp extension. Restart IIS so that this global change is taken
[important]).

Add this MIME type to your vdir, found this elsewhere on the boards:

Extension: .tmp
MIME type: application/x-temporary

That should allow you to open Web Projects using the File Share option, yes,
it IS ridiculous.


동시 접속자수가 많을 때, IIS의 급격한 성능 저하 또는 서버 장애 현상
http://support.microsoft.com/default.aspx?scid=kb;ko;601401

2009/06/18 13:37 2009/06/18 13:37
[Advance Computing Conference 2009] 비용절감 시대의 NEW IT 패러다임 '오픈소스' - 2009.4.14(화)
[지디넷코리아]전세계 언론자유와 언론인 인권보호를 목적으로 하는 국경없는기자회(RSF)는 최근 인권단체 엠네스티와 공동으로 인터넷 검열 등 언론의 자유를 위협하는 '인터넷의 적' 국가 명단을 발표했다.

'인터넷의 적'의 거론된 국가는 미얀마, 중국, 쿠바, 이집트, 이란, 북한, 사우디아라비아, 시리아, 튀니지, 투르크메니스탄, 우즈베키스탄, 베트남 등 12개국이다.

RSF는 이들 국가가 "국민이 '바람직하지 않은' 온라인정보의 접속을 막기 위해, 인터넷을 인트라넷으로 바꾸고 있다"고 비판하며, "이들 국가는 온라인 뉴스나 정보를 검열하는 능력과, 문제가 있는 인터넷이용자를 사실상 조직적으로 박해하고 있다"고 언급했다.

또한 RSF는 이들 국가가 인터넷 여론에 직접 관여하고 있다고도 지적했다. 일례로 중국 정부가 북경올림픽 당시, 인터넷이용자에게 보수를 지불하고 온라인상에 정부를 지지하는 글을 의뢰한 것을 꼽았다.

특히 RSF는 권력남용으로 연결될 가능성이 있는 인터넷정책을 세우고 있는 국가를 '감시대상'으로 발표했다. 특히 한국과 호주는 최근 온라인 표현의 자유를 위협할 수도 있는 정책을 도입했다고 전했다. 호주는 인터넷서비스제공자(ISP)에게 필터링을 의무화하는 법안을 검토하고 있고, 한국은 리만브러더스 등 주가폭락을 예측한 블로그를 체포하는 등 사건이 있었다.

이외에도 감시대상으로 바레인, 벨로루시, 에리트레아, 말레이지아, 스리랑카, 태국, UAE, 예멘, 짐바브웨 등이 거론됐다.
이와함께 현재 중국에서는 70명이 온라인 기고로 가장 많이 구속돼 있고, 베트남과 이란이 그 뒤를 잇고 있다고 전했다.

▲ 국경없는기자회는 지난 12일 `인터넷의 적` 국가 명단을 발표했다.
2009/03/17 11:08 2009/03/17 11:08
Tags:
그동안 언론이나 전문블로그를 통해 알려졌던 차세대 휴대폰이 최근 바르셀로나에서 개최된 '2009 GSMA Mobile World Congress'에서 하나하나 베일을 벗고 있다.

삼성전자와 LG전자 등 국내 업체은 물론 글로벌 휴대폰 제조사인 노키아, 소니에릭슨, HTC 그리고 최근 스마트폰 진출을 선언한 전통적인 PC제조업체인 에이서, 도시바 등 다양한 업체들이 자사의 차세대 휴대폰 및 스마트폰을 선보였다.

2009년 휴대폰 시장이 정체를 거듭하고 있는 상황에도 불구하고 오히려 더 많은 제품들이 휴대폰 시장 불황을 넘기 위해 새롭게 등장하고 있다.


▲ 노키아가 새롭게 선보인 E75 모델


■2009 휴대폰 화두는 '터치+스마트폰'

지난해부터 본격적으로 불던 터치폰 바람이 2009년에는 대세로 굳어질 전망이다. 삼성전자와 LG전자는 이번 MWC2009에서도 터치폰을 중심으로 신제품을 쏟아내고 있다.


▲ 삼성전자 옴니아HD
삼성전자는 글로벌 시장에서 큰 인기를 얻었던 울트라시리즈의 최신버전인 '울트라터치'로 인기몰이를 지속하고 있다.

울트라터치는 터치폰임에도 불구하고 슬라이브방식의 키패드를 내장해 터치폰이 익숙하지 않은 사람들도 쉽게 이용할 수 있는 환경을 제공하고 있다. 하나 아쉬운 점은 3인치가 안되는 2.8인치의 액정을 탑재했다는 점이다.

삼성전자는 국내외에서 큰 인기를 얻고 있는 스마트폰 옴니아의 후속 모델인 '옴니아HD'도 공개했다. 옴니아HD는 3.7인치의 대형 AMOLED 디스플레이를 탑재했으며 720P 수준의 HD 동영상 촬영 및 HD급 재생이 가능한 첨단 기능을 내장했다.

신종균 삼성전자 DMC부문 무선사업부장은 "빠르게 변화하는 휴대폰 시장과 소비자의 요구를 반영해 삼성전자만의 차별화된 기능과 디자인의 휴대폰을 지속적으로 출시하는 것은 물론, 토털 솔루션을 제공해 나갈 것"이라고 말했다.

LG전자도 이번에 공개한 최신 휴대폰에 거는 기대가 못지 않다.

우선 LG전자는 차세대 유저인터페이스를 탑재한 '아레나'를 선보였다.
 



▲ LG전자의 아레나는 큐브 모양의 3D 유저인터페이스를 탑재했다.

아레나는 지금까지 LG전자의 유저인터페이스 기술을 총망라한 'S클래스 UI'를 탑재했다. 유저인터페이스가 3D 효과로 구성되어 있어 별도의 학습없이 직관적으로 이용할 수 있는 장점을 제공한다.

팬택계열도 듀얼 슬라이드 방식의 스마트폰 '매트릭스 프로'를 공개했다.

 팬택 매트릭스 프로
팬택 매트릭스 프로는 윈도모바일6.1 운영체제를 탑재했고 메시징 서비스를 이용하기 쉽게 쿼티키보드를 적용했다.

또 모든 듀얼 슬라이드폰과 같이 수직으로 올리면 숫자키패드가, 수평으로 올리면 쿼티키보드가 나온다. 매트릭스 프로는 전작에 비해 매끄러운 디자인에 거울 느낌의 외관이 돋보인다.
대부분의 스마트폰과 같이 마이크로소프트 액티브싱크를 통한 동기화를 지원하고 있고 메일, 연락처는 물론 오피스 문서도 자유롭게 이용할 수 있다. aGPS를 탑재해 AT&T의 내비게이터 기능은 물론 AT&T 모바일 뮤직, 스테레오 블루투스, 32GB microSD 카드를 지원한다.

이외에도 해외 업체인 노키아, 소니에릭슨, HTC 등도 다양한 신모델을 선보이며 2009년 휴대폰 시장 경쟁속으로 뛰어들고 있다.









▲ HTC가 선보이는 터치스마트폰 터치다이아몬드2와 터치프로2


▲ 소니에릭슨이 공개한 콘셉트폰 Idou와 워크맨폰 W995

■에이서,도시바···뉴 플레이어 등장으로 2009년은 뜨겁다

전통적인 휴대폰 제조업체가 아닌 PC제조업체들이 속속 휴대폰 시장으로 몰려들고 있다. 그동안 실제 제품이 공개되지 않아서 억측만 난무하던 PC업체들의 첫 작품들이 속속 공개됐다.

애플에 이어 세계적인 PC제조업체인 에이서가 2009년 총10종의 휴대폰을 출시할 것이라고 밝혔다. 이미 4종의 모델은 MWC2009에서 공개된 상태.

에이서는 M900, F900, X960, DX900 등 다양한 스마트폰을 선보였다.


▲ 에이서 M900



▲ 에이서 DX900

대부분 윈도모바일을 운영체제로 이용하고 있으며 PC제조의 노하우를 스마트폰으로 잘 이식했다는 평가다.

도시바도 스마트폰 'TG01'모델을 공개했다.


▲ 도시바가 선보인 TG01 실제 제품, 아이폰의 대항마가 될 수 있을지 주목된다.

TG01은 공개되기 전부터 이미 아이폰 대항마로 낙점된 제품으로 퀄컴의 '스냅드래곤' 1GHz CPU와 4.1인치 WVGA(800x480)의 대형 디스플레이를 탑재해 시원한 화면을 빠르게 보여준다. 3G HSPA 네트워크를 지원하며 와이파이는 물론 aGPS를 탑재했다.

글로벌 경기 침체에도 불구하고 2009년 휴대폰 시장은 전통적인 휴대폰 업체는 물론 새롭게 등장한 스마트폰 제조업체까지 뒤엉키며 다양한 제품을 쏟아낼 것으로 예상된다. 불활에도 불구하고 휴대폰 시장 경쟁은 더욱 뜨거워질 것으로 전망되며 새로운 휴대폰을 찾는 소비자들의 눈과 귀가 더욱 즐거워질 것으로 기대된다.
2009/02/24 20:51 2009/02/24 20:51
Tags:

사용자 삽입 이미지
조직 활성화를 위한 동기부여 리더십
저자 : 오자사 요시히자

동기 부여는 사람에 있어 가장 중요한 내용인 듯 하다.
가끔 이런 말을 한다.
먹기위해 사느냐, 살려고 먹느냐..
이 말을 보면동기 부여에 관해 조금 생각 할 수 있다고 하겠다.
사는데 목적, 즉 동기가 먹기위함이 동기이고, 먹는 다는 목적에 살기 위함이라는 동기가 부여 될 수 있다는 생각이 들었다.

조직도 마찬가지 아닌가 한다.
조직이 유지되고 조직이 커가는 모든 원인은 조직원 내의 모든 동기부여가 부합되었을때 최대의 효과를 볼 수 있는듯 하다.
얼마전 우리 여행박사에서도 구조조정이라는 명목에 많은 사람들이 회사를 나가게 되었다.
물론 힘든 일이었을 것이다. 여러 상황의로 사정이 안 좋아 졌으니 회사에서 할 수 있는 최선이 아니었나 생각이 든다.
여행박사의 초창기 멤버는 아니지만, 많은 선임들에게서 들었던 내용과 책의 내용을 조합해보면,
우리 여행박사는 지금 조직의 재생기에 있어 보인다. 물론 개인적인 생각이다.
많이 비대 해졌으며, 자기 재생으로 새롭게 태어나는, 그런 때 인듯 하다.
모두 성공한 조직은 생성이 되고 발전이 하며, 비대 해지고, 다시 자기 재생을 하면서 더욱 단단한 조직 문화를 만들며 성공 한다는 모습을 하지 않았을까 한다.
여행박사는 그렇지 않으리라는 생각은 오산이 아닐런지...
지금까지 여행박사를 믿고 따라 왔던 이들은 "잘 될꺼야~"라는 막연한 동기를 가지고 지금껏있다가 퇴사를 했겠지만,
앞으로 넘겨진 사람들도 여행박사가 존재 하는 한 많은 일을 해야 한다는 생각이 들었다.

이 책에서는 많은 법칙과 많은 이야기가 있지만, 리더들이 어찌 해야 한다는 동기로 시작한다.
회사의 흥망을 좌지우지 하는 리더는 힘들겠지만, 누군가 아니 내가 리더였다면 어땠을까? 하는 생각도 한편으로 드는 내용이었다.
이 책을 읽는 시점이 참으로 절묘하게 사쵸의 생각을 하게 되었던 계기가 아닌가 생각 된다.

한번의 흥망을 바라볼 수 있었고, 점점 단단해지는 조직으로의 발전을 기원하며, 어떻게 이해 해야 하며,
우리 회사는 어떤 메세지를 계속적으로 소비자에게 나타낼 건지 또한 생각 해볼 때가 아닌가 하는 생각도 해보았다

2008/12/11 08:48 2008/12/11 08:48
2006년 9월.
드디어 생애 첫 해외여행을 간 곳은 일본의 오사카 였다.
처음 여행박사에 입사하여 여행을 다녀오지 않고서 시스템을 확인 할 수 없다는 이유로 반 강제로 회사에서 여행을 보낸게 계기가 되었다. 오사카를 1박 3일을 다녀왔다.
본인~

처음 인천공항에 도착 하여 한 컷을 했다.
오사카 도착은 아침 7시쯤 도착을 했다.

간사이 공항에서 난바역으로

처음 난바역에서 아침 으로 우동을 한드릇 먹은 후 바로 나라로 이동.
사슴들이 방목(?)을 하고 있는 곳으로 갔다.
나라에서
나라에 있는 한 절에 갔을 때 사람들이 우리나라의 대웅전과 같은 곳에 달린 큰 종을 밑에서 친 후
소원을 비는 모습을 보며 형태는 다를지 모르지만 모두 소원을 비는 마음은 하나 일꺼라는 생각을 잠시 했었다.
나라에서

사용자 삽입 이미지

대단한 거북이
나라를 뒤로 하고 교토로 향했다.
처음 교코역을 도착 했을때 나를 반기는 친숙한 캐릭터 하나.
우리들에 아~~톰~~
어릴 때 아톰 한번 흉내 안내본 사람 없을듯....
하지만 우리나라의 캐릭터가 아니라 일본의 캐릭터 였다는 것을 이후에 알았을떄의...그 묘한 기분이 있었으리라 생각 된다.~
다음은 우리가 많이 알고 있는 교코타워~~~
교코타워

사실 올라 가보지는 못했다...그냥 엄두가 안났다 ...ㅋㅋ
다음에는 꼮 가봐야쥐..ㅋㅋ

교토역 근처에 있는 니시혼간지 라는 곳이다 약간의 공원 같이 꾸며 놓은 절이었다.
애석 하게도 갔을 당시에는 본관은 공사 중이었다~
사용자 삽입 이미지
근처에 조금 외진 곳을 돌면서 이곳 저곳을 돌아 보면서 방금이라도 정종을 한잔 마실 수 있을 것 같은 선술집 하나를 발견 했었다.약간의 주택가 안에 종종 이런 가계가 있었다.
선술집


잠시 돌아 본 후 첫 숙박지인 코니텔일라는 한국인 분이 운영하시는 코니텔로 향했다.
위치는 니혼바시(니뽄바시)에 위치 하고 있다.
그 근처에는 우리나라의 용산 전자 상가쯤 되는 거리가 약 1KM 정도 위치 하고 있다. 모든 전자 용품 및 캐릭터 용품점이 즐비 했다. 요즘 같은 고 환율시대에는 엄두가 나지 않는....ㅋㅋㅋㅋ
역에서 내려 바로 있는 시장 같은 곳에어 우리나라의 신라면을 보았다..ㅋㅋ어~~찌나 방갑든지~~ㅋㅋ
근데 백엔인데 지금 환율로 보면1개에 1500원쯤 하는거다..ㅋㅋ
친숙한 이모네라는 간판도 있는것으로 보아 한국사람들이 많이 오는 모양이다~.
한국의 정취?
오늘은 여기까지..ㅋㅋ
급 피곤 해서 민박집으로 간 이후 바로 잠을자서, 다음날 아침까지 정말 죽었다 살아 난듯 잠만 자고 일어나서 다음날 일정을 또 갔었다.
다음날은 오사카 성과 도톤보리를 둘러 본 후 한국으로 고고~~
다음날 일정은 다음 편에 올리도록 하겠다~
오늘 너무 많이 올린듯...ㅋㅋㅋㅋ이런거 익숙치 않아~~~~

휘리릭~~~~~




2008/12/07 22:23 2008/12/07 22:23
1권의 제목은 "열정이 있다면 무모한 도전은 없다. "였습니다.^^

물론 사장님의 책을 읽고서 독후감을 다시 쓴다는 것이 조금 어색한 일이기는 하지만, 지금까지 지나온 여행박사의 흔적들을 하나하나 읽어 가면서
참 많은 일이 있었구나 생각이 되었습니다.

책에서 소개된 일들 보다 더 많은 일이 현장에서 있었으리라는 생각을 하면서 순간 웃음이 나왔다.

사장님께서 알고 있는 위기등의 모든 역경을 이겨 내고 지금의 여행박사가 성장 했다는 생각에 나 또한 다시 한번 마음을 다잡는 기회가 되었다.

입사 2년을 넘어 3년을 향해 가고 있는 개인적으로는 좋은 책을 적시에 읽은 듯한 생각이 든다.

요즘 많이 힘들다. 여행박사 또한 많은 어려움에 닥쳐있다.
이러한 위기를 잘 극복해야 할텐데 하는 마음이 머리속을 채우고 있는 지금 시점에서 이러한 책을 읽으면서 다시 한번 마음을 잡는 것도 나쁘지 않을듯 하다.

여행박사라는 회사에 몸담고 있는 이 시점에서 독후감이라는 말 보다는 책을 읽고 여행박사라는 회사에 대한 느낌을 다시 잡는 것이 좋을 듯 하다.

여행박사는 항상 최선을 다하며 지내 왔다. 그 순간순간 최선의 방법을 찾기 위해 항상 최선을 다하며 지내고 있다.
그게 틀린 결정이라 해도 항상 최선을 다해야 한다는 것이 여행박사의 정신이 아닐지...(물론 틀린 결정은 내려 질 수 없지만^^)
그 결정에 최선의 노력을 해야 하는게 우리들의 할 일이 아닐까 생각 된다.


언제나 잘나가는 여행박사가 되기 위해 난 오늘도 키보드를 뚜드린다~^^
2008/11/21 15:38 2008/11/21 15:38