IIS로그(W3C)를 중앙집중 로깅하도록 설정(IIS6)

일반적으로 IIS로깅을 설정하면, 각 개별 웹사이트마다 해당 웹사이트 ID별 디렉토리에 로깅파일을 생성하여 기록하게 되어있다.

문제는,. 많은 웹사이트의 로그를 일괄적으로 한곳에 로깅하여 관리가 필요한 경우가 있다.
IIS6에는 그런 방법을 지원하고 있다.

예외사항은,, FTP, NNTP, SMTP는 W3C 중앙집중 로깅을 지원하지 않으며, 로깅형식을 W3C가 아닌 바이너리로 할경우 HostHeader, Cookie, UserAgent,Referrer 로깅을 지원하지 않는다.

W3C로그파일 포맷형식은 W3C Extended Log File Format. 문서를 참고하기 바란다.

중앙집중 로깅의 장점은, IIS에서 각 웹사이트별 개별적인 로그파일에 기록하기 위해서 리소스소모를 절약할수 있다.  또한 웹서버 문제 발생시 어떤 웹사이트로 인해서 발생한것인지 로그파일을 통한 문제 추적이 쉬어진다.

로그파일 분석은, IIS 6.0 Resource Kit Tools 의 Log Parser 툴이 효과적이다.

방법은 간단하다. 직접 메타베이스를 수정하거나, Adsutil 을 이용하는 방법이 있다.

Adsutil.vbs set w3svc/CentralW3CLoggingEnabled true

위 설정을 적용한다음에는 서비스 관리자등에서 w3svc 를 재시작 해야 한다.

19-TechNetB_masthead_ltr.gif

Wfetch.exe를 이용한 HTTP 연결 Troubleshooting

IIS와 웹 클라이언트 사이의 연결에 대한 문제를 해결할 때 요청 및 응답 패킷에 포함되어 있는 HTTP 헤더 같이 웹 브라우저에 표시되지 않는 데이터를 보아야 할 수도 있다.

WebFetch(Wfetch.exe) 1.2는 무료 유틸이며, 다음과 같은 옵션을 통해서 웹서버와의 연결상태 및 웹서버 응답값등을 확인할 수 있다. 여러가지 메쏘드 방식을 테스트해 볼수 있으므로 특정 메쏘드를 서비스하는 웹서버에서는 결과값 확인 테스트에 좋은 도구일수 있다.

물론, 이 도구 말고도 찾아보면,. 여러 유틸이 있다.

다운로드 : http://support.microsoft.com/?id=284285

GUI  인터페이스를 제공하므로, 이용하는데는 크게 어려움이 없다.



다음은, Microsoft.com 웹사이트에 대해서 HEAD 메쏘드에 대한 연결로그 값이다.



결과 로그를 보면, 일단, 200 OK라는 정상응답 코드와,
Microsoft.com 웹사이트는 IIS6 및 ASP.NET 2.0 이라는 것,
그리고 P3P 헤더에 다양한 값이 적용되어 있다는 것,
마지막으로 index 페이지의 크기가 23,190 이라는 것을 확인할 수 있다.

자세한 내용은, 다운로드 링크에 있는 해당 kb번호 KR284285 문서를 참고하길.....

16-wfetch_a.gif
16-wfetch_b.gif

IIS FTP에 패시브모드 포트 범위 설정

IIS기반 FTP 서비스는 패시브모드(Passive-mode)와 액티브모드(Active-mode) 2가지를 지원한다.

Active-mode 는 클라이언트 기반 접속이다. 그래서 웹서버쪽에 20,21 번이 열린 FTP를 접속시 클라이언트에서는 포트가 랜덤포트를 이용하나 서버 포트는 변함이 없다. 클라이언트는 서버쪽에 port 명령어를 보낸다.

Passive-mode 는 서버쪽 21번 포트로 접속시, 클라이언트의 랜덤포트가 아니라 서버쪽 랜덤포트를 이용하게 된다. 서버는 클라언트에게 pasv 명령어를 보내며, 클라이언트는 승인하게 된다.

문제는, 패시브모드의 경우 서버쪽에 1024 에서 65535 포트 사이를 랜덤하게 할당하며, 네트워크 세션이 있을때마다 신규포트를 이용하게 된다. 이때, 서버쪽에 방화벽을 운영하거나 대량접속서비스가 운영중일때는 네트워크 자원이 부족하게 되어 접속장애가 있을수 있다.

패시브모드에서의 서버쪽 랜덤 포트범위를 조정하므로써, 이를 해결할 수 있다.

Windows 2000 Server 및 Windows Server 2003 모두  PassivePortRange 값을 이용하여 조정이 가능하다.

Windows Server 2003 의 경우

1. 메타베이스를 수정하는 방법이다.
  (메타베이스를 수정할려면, IIS MMC에서 메타베이스 직접수정 허용 설정이 되어 있어야 한다.)

2. ADSUTIL을 이용하는 방법이다.
   Adsutil.vbs set /MSFTPSVC/PassivePortRange "5500-5700"


Windows 2000 Server 의 경우는 레지스트리 값을 추가해야 한다.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msftpsvc\Parameters\
에서 REG_SZ 타입의 PassivePortRange 값이름을 추가한다.

값으로는, 5500-5700 을 설정한다.

위 2경우 모두 설정후 FTP 서비스를 재시작 해야 적용되며, 위와 같이 범위 또는 특정포트값을 설정해도 된다.

서버에 방화벽을 운영하는 서버인데, 클라이언트가 액티브모드를 지원하지 않는경우에 적용하는 것이 좋은 해결책이 될 수 있다.



15-TechNetB_masthead_ltr.gif

Troubleshooting SMTP - SMTPDiag 도구

IIS SMTP나 Exchage Server에서 메일 발송시, 일부 문제로 인해서 메일이 발송되지 않고, Queue 또는 PickUp 폴더에 그대로 있는 경우가 있다.

메일이라는 것은, 메일을 보내는 아웃룩같은 클라이언트에서 메일서버 그리고 메일을 수신하게 되는 원격서버간, 그 사이에 DNS등. 연동작업이므로 문제가 발생하는 경우 그 원인을 알기가 쉽지 않다.

SMTPDiag 도구 메일발송시 문제가 되는 부분을 일부 확인할 수 있는 훌륭한 툴이다. 이 툴은 Exchange Server 도구의 일부로 제공된다.. 이툴은 Microsoft EULA 가 있는 툴이므로 공개서비스용으로 이용하면 안된다.

다운로드 : http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=BC1881C7-925D-4A29-BD42-71E8563C80A9

사용법:
SMTPDIAG    "보낸 사람 주소"    "받는 사람 주소"    [-d external DNS]   [/v]

보낸 사람 주소 : 필수. 로컬 사서함 주소. SMTP 전송 및 인바운드 DNS를 확인하는 데 사용.

받는 사람 주소 :  필수. 메일을 보내려고 하는 원격 사서함의 전자 메일 주소. DNS 및 원격 사서함의 사용 가능성을 확인하는 데 사용.

-d target DNS : 옵션. 테스트할 원격 MX 레코드 조회에 사용할 대상 DNS 서버의 IP 주소.

/v :  옵션. 각 테스트에 대한 추가 정보를 표시.

실제 테스트를 예는 다음과 같다.

SmtpDiag.exe "insideapple@gmail.com" "sysadmin@hanbiro.com" /v

Exchange 외부 DNS 설정을 검색하고 있습니다.
컴퓨터 이름이 SERVERINFO입니다.
도메인 컨트롤러에 연결하지 못했습니다. 오류: 8007054b

hanbiro.com의 SOA를 확인하고 있습니다.
외부 DNS 서버를 확인하고 있습니다.
내부 DNS 서버를 확인하고 있습니다.

DNS 서버 [211.234.98.50]을(를) 사용하여 TCP/UDP SOA 일련 번호를 확인하고 있습니다.
TCP 테스트에 성공했습니다.
UDP 테스트에 성공했습니다.
일련 번호: 951247

DNS 서버 [168.126.63.1]을(를) 사용하여 TCP/UDP SOA 일련 번호를 확인하고 있습니다.
TCP 테스트에 실패했습니다.
UDP 테스트에 성공했습니다.
일련 번호: 951247
SOA 일련 번호가 일치합니다. 통과되었습니다.

로컬 도메인 레코드를 확인하고 있습니다.
로컬 도메인의 TCP 및 UDP DNS 쿼리를 시작합니다. 이 테스트는 인바운드 메일의 DNS가 제대로 설정되어 있는지를 확인합니다.
이 테스트는 다음과 같은 세 가지 원인으로 인해 실패할 수 있습니다.
    1) 로컬 도메인이 DNS에 설정되어 있지 않습니다. 인바운드 메일을 로컬 사서함으로 라우팅할 수 없습니다.
    2) 방화벽이 TCP/UDP DNS 쿼리를 차단합니다. 인바운드 메일에는 영향을 주지 않지만 아웃바운드 메일에는 영향을 줍니다.
    3) 내부 DNS가 외부 DNS 설정을 인식하지 못합니다. 특정 토폴로지에 유효한 구성입니다.
TCP를 사용하여 MX 레코드를 확인하고 있습니다. gmail.com.
  MX:    gsmtp185-2.google.com (10)
  MX:    gsmtp163.google.com (10)
  MX:    gsmtp83.google.com (10)
  MX:    gsmtp83-2.google.com (10)
  MX:    gmail-smtp-in.l.google.com (5)
  MX:    gsmtp185.google.com (10)
  A:     gsmtp185-2.google.com [64.233.185.114]
  A:     gsmtp83.google.com [66.249.83.27]
  A:     gsmtp83-2.google.com [66.249.83.114]
  A:     gmail-smtp-in.l.google.com [66.249.83.114]
  A:     gmail-smtp-in.l.google.com [66.249.83.27]
  A:     ns1.google.com [216.239.32.10]
  A:     ns2.google.com [216.239.34.10]
  A:     ns3.google.com [216.239.36.10]
  A:     ns4.google.com [216.239.38.10]
UDP를 사용하여 MX 레코드를 확인하고 있습니다. gmail.com.
  MX:    gsmtp185.google.com (10)
  MX:    gsmtp185-2.google.com (10)
  MX:    gsmtp163.google.com (10)
  MX:    gsmtp83.google.com (10)
  MX:    gsmtp83-2.google.com (10)
  MX:    gmail-smtp-in.l.google.com (5)
  A:     gsmtp185.google.com [64.233.185.27]
  A:     gsmtp185-2.google.com [64.233.185.114]
  A:     gsmtp163.google.com [64.233.163.27]
  A:     gsmtp83.google.com [66.249.83.27]
  A:     gsmtp83-2.google.com [66.249.83.114]
  A:     gmail-smtp-in.l.google.com [66.249.83.114]
  A:     gmail-smtp-in.l.google.com [66.249.83.27]
  A:     ns1.google.com [216.239.32.10]
  A:     ns2.google.com [216.239.34.10]
  A:     ns3.google.com [216.239.36.10]
  A:     ns4.google.com [216.239.38.10]
TCP 및 UDP 쿼리가 모두 성공했습니다. 로컬 DNS 테스트를 통과했습니다.

원격 도메인 레코드를 확인하고 있습니다.
원격 도메인의 TCP 및 UDP DNS 쿼리를 시작합니다. 이 테스트는 아웃바운드 메일의 DNS가 제대로 설정되어 있는지를 확인합니다.
 이 테스트는 다음과 같은 세 가지 원인으로 인해 실패할 수 있습니다.
    1) 아웃바운드 메일을 차단할 TCP/UDP 쿼리를 방화벽이 차단합니다. Windows 2000/NT Server의 경우 TCP DNS 쿼리가 필요합
니다. Windows Server 2003은 먼저 UDP 쿼리를 사용한 다음 다시 TCP 쿼리로 변경합니다.
    2) 내부 DNS가 외부 도메인 쿼리 방법을 모릅니다. 외부 DNS 서버를 사용하거나 DNS 서버를 구성하여 외부 도메인을 쿼리해
야 합니다.
    3) 원격 도메인이 없습니다. 오류가 발생할 수 있습니다.
TCP를 사용하여 MX 레코드를 확인하고 있습니다. hanbiro.com.
  MX:    nmail.hanbiro.com (10)
  A:     nmail.hanbiro.com [211.234.111.10]
UDP를 사용하여 MX 레코드를 확인하고 있습니다. hanbiro.com.
  MX:    nmail.hanbiro.com (10)
TCP 및 UDP 쿼리가 모두 성공했습니다. 원격 DNS 테스트를 통과했습니다.

sysadmin@hanbiro.com의 나열된 MX 서버를 확인하고 있습니다.
포트 25의 nmail.hanbiro.com[211.234.111.10]에 연결하고 있습니다.
받음:
220 ns12.hanbiro.com ESMTP

보냄:
ehlo gmail.com

받음:
250-ns12.hanbiro.com
250-STARTTLS
250-AUTH LOGIN CRAM-MD5 PLAIN
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-PIPELINING
250 8BITMIME

보냄:
mail from: <insideapple@gmail.com>

받음:
250 ok

보냄:
rcpt to: <sysadmin@hanbiro.com>

받음:
250 ok

보냄:
quit

받음:
221 ns12.hanbiro.com

nmail.hanbiro.com에 연결했습니다.

 

웹서버 핑거프린팅 (Web Server Fingerprinting)

웹서버는, 해당서버에 접속할경우 해당 서버 정보를 접속 클라이언트에게 간단하게 출력한다.

이것을, 배너정보라고 하는데,.. 웹서버, FTP, SMTP서버등 공개 다중 서비스의 경우 거의 대부분 출력한다. 접속한 서버에 대한 정보를 알수 있다는 좋은 점이 있기는 하나, 이게 오히려 해커들의 정보수집에 일부 역할을 한다는 것이다.

www.microsoft.com 80   Microsoft-IIS/6.0   Microsoft-IIS/6.0
www.intel.com 80   IA Web Server/1.0   Microsoft-IIS/5.1, Microsoft-IIS/5.0 ASP.NET
www.linux.org 80   Apache/2.2.0 (Fedora)   Apache/2.0.x
www.ibm.com 80   IBM_HTTP_Server   Lotus-Domino/6.x
www.google.com.my 80   GWS/2.1   GWS/2.1 Google Web Server

배너정보 출력은, 툴을 통해서 변경이 가능하다.
IIS의 경우 Urlscan이나, 기타 공개된툴(WebKnight)이나 상용보안툴을 통해서도 변경이 가능하며,Apache의 경우 자체적으로 변경 또는 Mod_Security 를 통해서도 변경이 가능하다.

( 관련팁 : http://www.serverinfo.pe.kr/TipnTech.aspx?Content=Windows&Search=&vMode=View&page=2&Seq=124 )

일반적인 배너그래빙 툴로는 변경된  서버 정보는 알수가 없다..,

소개하는 툴은,. net-square(http://net-square.com/httprint/) 의 httprint 툴 이다.



이툴의 경우 배너를 수정하였다 하더라고,.. 거의 정확하게 알아 낼수 있다. 이툴이 웹서버 정보를 알아내는 방법은 다음문서에 잘 설명되어 있다.

http://net-square.com/httprint/httprint_paper.html

내용을 보면,, 통계와 퍼지원리등을 이용해서 해당 웹서버의 정보를 추출한다고 한다. 내용을 보면 설명내용처럼 꽤, 통계적이고 과학적이듯 하다.

설명서의 6장을 보면, 각 웹서버가 같은 방식의 전송방식에 서로 다른 결과값을 보인다는 것이다. 이런 결과값을 이용하여 7장 처럼 통계를 이용하고 8장 처럼 고유값을 확보하게 된다.

Signature 파일은 지속적으로 업데이트를 해주는듯 하다. 이와 같은 방식인지는 모르겠으나, 웹서버 통계 웹사이트는 NetCraft (http://netcraft.com) 도 비교적 웹서버 정보를 자세하게 알려준다.

툴은 플랫폼 별로 제공하고 있다.

Win32 GUI and cmd line [download] a66408308c3f540030bbb0d59716b032
Linux [download] af53704de9c1851bd439cbe3fab3e0ad
Mac OS X [download] 6b188cd60df6eca5409694fa40859f0d
FreeBSD [download] d5efd9463f671ce92f50ce3222f1774e

15-httprint301_scaled.gif

IIS의 성능을 높이기 위한 10가지 방법 - TechNet Magazine

Top Ten Ways To Pump Up IIS Performance

본 테크넷매거진 컬럼에는, IIS의 성능을 높이기 위한 10가지 방법을 소개하고 있다.

10가지 방법은 다음과 같으며, 운영자가 이전에 등록한 몇개 팁과도 같은 내용이 있다. 각 10가지 항목에 대해서 간단하게 덧붙이자면...

1. Enable HTTP Keep-Alives

일반적으로, IIS의 기본값으로 설정되어 있는 상태이다. 이전에 등록된 팁에서도 언급한 내용이지만, 너무긴 유지시간은 오히려 성능저하를 가져오므로 조정을 통한 최적의 적절한 값이 필요하다.

관련팁: http://www.serverinfo.pe.kr/TipnTech.aspx?Content=Windows&Search=&vMode=View&page=&Seq=199

2. Adjust Connection Timeouts

HTTP연결유지시간과 같은 맥락이다. 이부분도 조정을 통해서 해당 서버에 최적의 값을 찿아내야 한다.

3. Enable HTTP Compression

높은 대역폭을 요구하는 웹사이트의 경우 아주 효과적이긴 하다. 그러나 그 댓가를 치를 만큼의 웹서버 하드웨어 스펙은 되어야 한다.

관련팁: http://www.serverinfo.pe.kr/TipnTech.aspx?Content=Windows&Search=&vMode=View&page=&Seq=198

4. Grow a Web Garden

이부분은 IIS6에서 지원되는 내용으로, 다중 CPU를 운영하는 서버에서 각 CPU별로 응용프로그램풀에 웹가든 형식으로 로드밸런싱의 효과를 가져올 수 있다.

5. Adjust the IIS Object Cache TTL

캐시값 조정을 통한 성능조정.

관련팁: http://www.serverinfo.pe.kr/TipnTech.aspx?Content=Windows&Search=&vMode=View&page=&Seq=204

6. Recycle

이부분도 내용상으로는 IIS6의 재생에 대한 설명이나, IIS5의 경우에는 IIS5Recycle 툴을 이용하는 것도 좋은 방법이다.

7. Limit Queue Length

웹서버에서 최대의 성능을 낼만큼만의 큐 제한을 해놓아야 한다는 것이다.

관련팁: http://www.serverinfo.pe.kr/TipnTech.aspx?Content=Windows&Search=&vMode=View&page=&Seq=203

8. Shift Priority to the Working Set

페이징에 관련된것인데, 적절한 페이징은 웹서버뿐만 아니라 서버 전체 성능에 영향을 미친다.

9. Add Memory

메모리 소비 지향의 웹사이트라면, 메모리확장을 하면 디스크에 페이징이 줄어들게 되므로 서버 전체적으로 성능향상을 가져온다는 것이다.

10. Use Disk Striping

마지막으로, 디스크에 관련된 내용인데,  시스템파티션, 웹파티션, 로그파티션등 각 기능별로 물리적인 디스크로 분리하면 I/O성능을 향상시킬수 있다는 것이다.

관련팁: http://www.serverinfo.pe.kr/TipnTech.aspx?Content=Windows&Search=&vMode=View&page=&Seq=200


기사원본(영문) :
http://www.microsoft.com/technet/technetmag/issues/
2005/11/PumpUpPerformance/default.aspx

13-TechNetB_masthead_ltr.gif