A boring day ~ : IBM HTTPServer

#IBM HTTPServer#WebSphere

[IHS/WAS] 실제 클라이언트 IP(Real IP) 식별 가이드: mod_remoteip 설정 및 버전별 패치 현황 (9.0.5.13)

로드밸런서(L4/L7) 환경에서 실제 클라이언트 IP를 식별하기 위해 IBM HTTP Server(IHS) 9.0의 mod_remoteip를 설정하는 방법을 다룹니다. 특히 보안 감사 로그의 무결성을 위해 IHS 9.0.5.13 (APAR PH47286) 패치가 왜 중요한지, 그리고 버전별 로그 포맷 설정 차이점을 중점적으로 정리합니다.

0. 배경: 왜 IP가 바뀔까?

클라이언트가 로드밸런서(Proxy)를 거쳐 웹 서버에 접속하면, 웹 서버 입장에서는 연결을 요청한 주체가 로드밸런서이므로 Source IP가 로드밸런서 IP(예: 10.0.0.1)로 기록됩니다.

이는 다음과 같은 보안 문제를 야기합니다.

접근 제어 실패: IP 기반의 ACL(Access Control List) 적용 불가
감사 추적 불가: 사고 발생 시 실제 공격자의 IP를 로그에서 찾을 수 없음

1. 버전별 패치 및 로그 포맷 주의사항 (Version History)

IHS 설정에 앞서, 사용 중인 IHS 버전에 따라 로그 포맷 변수를 다르게 써야 하므로 버전 확인이 필수적입니다.

📢 핵심 패치 정보: APAR PH47286

적용 버전: IBM HTTP Server 9.0.5.13 이상

내용: 이전 버전에서는 mod_remoteip가 정상 작동해도, 기본 로그 변수인 %h가 여전히 프록시 IP를 출력하는 문제가 있었습니다. 9.0.5.13부터는 %h가 mod_remoteip에 의해 변경된 실제 IP를 반영하도록 수정되었습니다.

버전별 권장 로그 포맷

IHS 버전	Access Log 권장 변수	설명
9.0.5.12 이하	`%a` (Client IP)	`%h`는 프록시 IP를 찍으므로 사용 금지. 반드시 `%a` 사용.
9.0.5.13 이상	`%h` 또는 `%a`	패치 적용됨. `%h`를 써도 실제 IP가 기록됨 (기존 설정 유지 가능).

2. IHS 설정 가이드 (httpd.conf)

Step 1: 모듈 활성화

# mod_remoteip 모듈 주석 해제
LoadModule remoteip_module modules/mod_remoteip.so

Step 2: 신뢰할 프록시 등록

보안을 위해 "누가 보내준 헤더를 믿을 것인가"를 명시해야 합니다. 아무 헤더나 믿으면 IP 스푸핑 공격에 당할 수 있습니다.

<IfModule mod_remoteip.c>
    # 1. 실제 IP가 담긴 헤더명 지정 (표준: X-Forwarded-For)
    RemoteIPHeader X-Forwarded-For

    # 2. 신뢰할 로드밸런서(L4/L7) IP 등록
    # 사설 IP 대역의 프록시인 경우 (10.x, 192.168.x 등)
    RemoteIPInternalProxy 10.0.0.1 10.0.0.2

    # 공인 IP 대역의 프록시인 경우
    # RemoteIPTrustedProxy 203.0.113.5
</IfModule>

Step 3: 로그 포맷 변경 (Access Log)

버전에 관계없이 가장 안전한 방법은 %a 변수를 사용하는 것입니다.

# [기존] common 포맷 (9.0.5.12 이하에서 문제 발생 가능)
# LogFormat "%h %l %u %t \"%r\" %>s %b" common

# [변경] %h -> %a 로 변경 (권장)
LogFormat "%a %l %u %t \"%r\" %>s %b" common

3. 검증 및 디버깅 (Validation)

설정 적용 후 실제로 헤더가 잘 변환되는지 확인하기 위해 임시로 로그를 상세하게 찍어봅니다.

# 디버깅용 로그 포맷 정의 (작업 후 주석 처리 권장)
# %{c}a : Connection IP (L4 IP)
# %a    : Client IP (변환된 실제 IP)
GlobalLog logs/remoteip_debug.log "L4-IP=%{c}a Real-IP=%a XFF-Header=%{X-Forwarded-For}i"

정상 결과 예시:

L4-IP=10.0.0.1 Real-IP=203.0.113.2 XFF-Header=203.0.113.2

L4-IP에는 로드밸런서 IP가 나와야 함
Real-IP에는 실제 사용자 PC의 IP가 나와야 함 (성공)

4. WAS(WebSphere) 추가 설정 필요 여부

IHS에서 mod_remoteip가 정상 작동하면, WAS 플러그인(Plugin)으로 넘어갈 때 이미 Source IP가 복원된 상태로 넘어갑니다. 따라서 WAS 쪽에서는 별도의 추가 설정 없이 request.getRemoteAddr() 호출 시 실제 IP를 획득할 수 있습니다.

(단, Plugin 설정의 TrustedProxyEnable 속성은 상황에 따라 검토가 필요할 수 있습니다.)

Read Log →

#apache#IBM HTTPServer

[Apache/IHS] 서버 성능 튜닝의 핵심: MaxRequestWorkers 계산법 및 MPM 설정 완벽 가이드

"사용자가 몰리면 서버가 응답이 없어요." 이런 문제의 90%는 동시 접속자 처리 설정인 MPM(Multi-Processing Module) 튜닝으로 해결됩니다. 물리 메모리 한계 내에서 최대 성능을 끌어내는 MaxRequestWorkers 설정법과 ServerLimit의 관계를 단계별로 정리합니다.

0. 튜닝의 핵심 공식 (The Formula)

튜닝은 '감'으로 하는 것이 아닙니다. 메모리 부족으로 인한 스왑(Swap) 발생을 막는 것이 최우선 목표이며, 이는 정확한 계산에서 시작됩니다.

    MaxRequestWorkers = (총 RAM - OS/DB 사용 RAM) / (Apache 프로세스 1개의 평균 메모리)

1. 3단계 계산법: 내 서버의 한계값 찾기

Step 1: Apache 프로세스 평균 메모리 측정

먼저, 현재 구동 중인 httpd(또는 apache2) 프로세스 하나가 실제로 사용하는 메모리(RSS)의 평균을 구합니다.

# SSH 접속 후 실행 (결과 단위: MB)
ps -ylC httpd --sort:rss | awk '{sum+=$8; ++n} END {print "Average RSS: " sum/n/1024 " MB"}'

(예시 결과: 45.5 MB)

Step 2: Apache 가용 RAM 산정

서버의 전체 메모리에서 OS와 다른 애플리케이션(DB 등)이 사용하는 메모리를 제외합니다.

# 전체 메모리 확인
free -m

(예시: 16GB 서버에서 OS/DB가 6GB 사용 중 -> Apache용 가용 메모리 10GB (10,240 MB))

Step 3: 최종 설정값 도출

위에서 구한 값을 공식에 대입합니다.

계산: 10,240 MB / 45.5 MB = 225.05
결론: 소수점은 버리고 225를 MaxRequestWorkers 값으로 선정합니다.

2. 보이지 않는 벽: Limit 지시어의 이해

MaxRequestWorkers 값만 높인다고 끝이 아닙니다. 이 값은 상위 제한(Hard Limit) 설정인 ServerLimit과 ThreadLimit 안에서만 유효합니다.

규칙: MaxRequestWorkers ≤ (ServerLimit × ThreadsPerChild)

만약 계산된 값이 기본 한계(보통 ServerLimit 16)를 초과한다면, 반드시 설정 파일에 ServerLimit을 명시해야 합니다.

3. 튜닝 전략: 안정성 vs 효율성

Event/Worker MPM을 사용할 때, 성능을 높이는 방향은 두 가지입니다.

구분	ServerLimit 증가 (프로세스 ↑)	ThreadsPerChild 증가 (스레드 ↑)
안정성	높음 (하나가 죽어도 나머지는 생존)	낮음 (스레드 하나가 죽으면 프로세스 전체 다운)
메모리 효율	낮음 (독립 메모리 필요)	높음 (메모리 공유)
권장	✅ 적극 권장	⚠️ 신중한 접근 필요 (보통 25~64 고정)

4. 최종 설정 예시 (httpd.conf)

위의 계산 결과(MaxRequestWorkers 1000 가정)를 바탕으로 한 Event MPM 최종 설정 예시입니다.

<IfModule mpm_event_module>
    # 1. 스레드 수는 안정적인 값으로 고정 (25)
    ThreadsPerChild         25

    # 2. 필요한 프로세스 수 계산 (1000 / 25 = 40)
    # 기본값(16)보다 크므로 반드시 명시해야 함
    ServerLimit             40

    # 3. 목표 동시 처리 수 (40 * 25 = 1000)
    MaxRequestWorkers       1000

    # 4. 기타 프로세스 관리 옵션
    StartServers            4
    MinSpareThreads         75
    MaxSpareThreads         250
    MaxConnectionsPerChild  0
</IfModule>

Check Point: 설정을 마친 후에는 반드시 apachectl -t 또는 httpd -t 명령어로 문법 오류가 없는지 확인하고 재기동해야 합니다.

Read Log →

#IBM HTTPServer

[IBM HTTPServer] SSL 인증서 적용 가이드: PEM → P12 → KDB 변환 및 gskcapicmd 사용법

일반적인 인증서 파일(PEM/Key)을 IBM HTTP Server(IHS)에서 사용하는 CMS 키 데이터베이스(KDB) 형식으로 변환하는 과정을 정리합니다. OpenSSL을 이용해 P12로 1차 변환 후, IBM GSKit(gskcapicmd)을 이용해 KDB로 최종 변환 및 등록합니다.

0. 배경 및 프로세스 (Workflow)

IHS는 OpenSSL 기반이 아닌 IBM 고유의 암호화 라이브러리(GSKit)를 사용합니다. 따라서 다음과 같은 변환 과정이 필수적입니다.

Step 1: .key + .pem → .p12 (OpenSSL 사용)
Step 2: .p12 → .kdb (gskcapicmd 사용)

Test Environment

OS: Linux / Unix
Web Server: IBM HTTP Server v9.0 (v8.5 이상 동일)
Tool: OpenSSL, gskcapicmd (IHS bin 폴더 내장)

1. PEM을 P12로 변환 (OpenSSL)

개인키(Private Key)와 인증서(Certificate)를 하나의 패키지 포맷인 PKCS#12(.p12)로 병합합니다.

# 구문: openssl pkcs12 -export -inkey [개인키] -in [인증서] -out [출력파일명]
openssl pkcs12 -export -inkey Wildcard.test.co.kr.key -in Wildcard.test.co.kr.pem -out Wildcard.test.co.kr.p12

주의 (Password):
명령어 실행 시 Export Password를 설정하게 됩니다. 이 비밀번호는 다음 단계에서 KDB로 임포트할 때 필요하므로 반드시 기억해야 합니다.

2. P12를 KDB로 변환 (GSKit)

IHS의 bin 디렉토리에 있는 gskcapicmd(또는 gskcmd)를 사용합니다.

2-1. 환경 변수 설정 (필수)

GSKit 라이브러리를 로드하기 위해 라이브러리 경로를 잡아주어야 에러가 발생하지 않습니다.

# IHS 설치 경로 예시 (/sw/web/IHS9)
export LD_LIBRARY_PATH=/sw/web/IHS9/lib:$LD_LIBRARY_PATH
cd /sw/web/IHS9/bin

2-2. 신규 KDB 생성 (없는 경우)

기존 KDB가 없다면 새로 생성합니다. -stash 옵션은 비밀번호를 파일(.sth)로 저장하여 웹 서버 기동 시 비밀번호 입력을 자동화합니다.

./gskcapicmd -keydb -create -db key.kdb -pw [KDB패스워드] -type cms -stash

2-3. P12 파일 임포트 (Import)

생성된(또는 기존) KDB 파일에 위에서 만든 P12 인증서를 넣습니다.

./gskcapicmd -cert -import \
-db /sw/img/Wildcard.test.co.kr.p12 -pw [P12패스워드] \
-target key.kdb -target_pw [KDB패스워드] \
-label "*.test.co.kr"

참고 (Export vs Import):
질문하신 내용 중 -export를 사용하여 P12를 KDB로 바로 변환하는 방법도 가능하지만, 실무에서는 기존 KDB에 인증서를 추가(Import)하거나 갱신하는 경우가 많으므로 -import 방식을 권장합니다.

3. 기본 인증서 설정 및 검증

KDB 안에 여러 인증서가 있을 경우, 어떤 인증서를 메인으로 사용할지 지정해야 합니다.

기본 인증서 지정 (Set Default)

./gskcapicmd -cert -setdefault -db key.kdb -pw [KDB패스워드] -label "*.test.co.kr"

검증 (List & Details)

KDB 내의 인증서 목록과 유효기간을 확인하여 작업이 정상적으로 되었는지 점검합니다.

# 인증서 목록 확인 (Default는 * 또는 > 표시가 붙음)
./gskcapicmd -cert -list -db key.kdb -pw [KDB패스워드]

# 특정 인증서 상세 정보 확인
./gskcapicmd -cert -details -db key.kdb -pw [KDB패스워드] -label "*.test.co.kr"

Next Step:
key.kdb 파일과 key.sth(Stash) 파일을 httpd.conf의 KeyFile 경로에 위치시키고 IHS를 재기동하면 SSL 적용이 완료됩니다.

Read Log →

#IBM HTTPServer#WebSphere

[WebSphere] WAS v9.0 CLI 설치 완벽 가이드: IM, WAS, IHS, Plugin 및 JDK 8 동시 설치

CentOS 7 환경에서 GUI 없이 imcl 명령어를 사용하여 WebSphere v9.0.5.1을 설치합니다. v9.0부터 변경된 정책에 따라 JDK 8을 반드시 함께 설치해야 함을 강조하며, WAS, IHS, Plugin 설치 및 패치 적용 명령어를 정리합니다.

Test Environment

OS: CentOS 7 (3.10.0-957.el7.x86_64)
Installer: IBM Installation Manager (IM) 1.8.x 이상
Target Version: WebSphere Application Server 9.0.5.1

1. Installation Manager (IM) 설치

IBM 제품군을 설치하고 관리하는 도구인 IM을 먼저 설치합니다. -repositories에는 repository.config 파일이 있는 경로를 지정합니다.

설치 명령어

# 설치 경로로 이동
cd /sw/img/im

# IM 설치 실행
./imcl install com.ibm.cic.agent \
-repositories "/sw/img/im/repository.config" \
-installationDirectory "/sw/IBM/InstallationManager/eclipse" \
-sharedResourcesDirectory "/sw/IBM/IMShared" \
-acceptLicense \
-showProgress -sP

Tip (패키지 ID 확인):
설치하려는 제품의 정확한 ID(예: com.ibm.websphere...)를 모른다면 설치 미디어 내의 Offerings 폴더를 확인하거나, ./imcl listAvailablePackages -repositories [경로] 명령어로 조회할 수 있습니다.

2. WebSphere Application Server (WAS) 설치

중요: WAS v9.0은 기본 JDK가 포함되어 있지 않습니다. 따라서 com.ibm.websphere.BASE... 패키지와 com.ibm.java.jdk.v8... 패키지를 동시에 지정하여 설치해야 합니다.

설치 명령어 (Base + JDK 8)

설치 도구(tools) 경로로 이동하여 실행합니다.

cd /sw/IBM/InstallationManager/eclipse/tools

# WAS 및 JDK 동시 설치
./imcl install com.ibm.websphere.BASE.v90_9.0.5001.20190828_0616 \
com.ibm.java.jdk.v8_8.0.5041.20190924_1031 \
-repositories "/sw/img/base","/sw/img/sdk" \
-installationDirectory "/sw/was/AppServer9" \
-sharedResourcesDirectory "/sw/IBM/IMShared" \
-acceptLicense \
-properties cic.selector.nl=ko \
-showProgress -sP

Fix Pack 업데이트 (Optional)

설치 후 특정 픽스팩(예: 9.0.5.3)으로 업데이트가 필요한 경우 아래 명령어를 사용합니다.

./imcl install com.ibm.websphere.BASE.v90_9.0.5003.20200226_0941 \
-repositories "/sw/img/fixwas" \
-installationDirectory "/sw/was/AppServer9" \
-acceptLicense -sP

3. IBM HTTP Server (IHS) 설치

웹 서버인 IHS도 마찬가지로 JDK 설치가 필요합니다. user.ihs.httpPort 속성으로 기본 포트를 지정할 수 있습니다.

# IHS 및 JDK 동시 설치
./imcl install com.ibm.websphere.IHS.v90_9.0.5001.20190828_0616 \
com.ibm.java.jdk.v8_8.0.5041.20190924_1031 \
-repositories "/sw/img/ihs","/sw/img/sdk" \
-installationDirectory "/sw/web/IHS9" \
-sharedResourcesDirectory "/sw/IBM/IMShared" \
-acceptLicense \
-properties user.ihs.httpPort="80" \
-showProgress -sP

4. Web Server Plugin (PLG) 설치

WAS와 웹 서버를 연동해주는 플러그인 모듈입니다.

# Plugin 및 JDK 동시 설치
./imcl install com.ibm.websphere.PLG.v90_9.0.5001.20190828_0616 \
com.ibm.java.jdk.v8_8.0.5041.20190924_1031 \
-repositories "/sw/img/plg","/sw/img/sdk" \
-installationDirectory "/sw/web/Plugins9" \
-sharedResourcesDirectory "/sw/IBM/IMShared" \
-acceptLicense \
-showProgress -sP

5. 설치 검증 (Verification)

모든 설치가 완료되면 설치된 패키지 목록과 상세 버전을 확인합니다.

설치된 패키지 목록 확인

# IM 명령어로 확인
./imcl listInstalledPackages

상세 버전 리포트 확인

WAS가 제공하는 스크립트로 상세 리포트를 확인합니다.

# WAS 홈의 bin 디렉토리
/sw/was/AppServer9/bin/versionInfo.sh

Next Step:
엔진 설치가 완료되었습니다. 이제 manageprofiles.sh 명령어를 사용하여 실제 서비스를 구동할 프로파일(Profile)을 생성해야 합니다.

Read Log →

#IBM HTTPServer#security#WebSphere

[WebSphere/IHS] 보안 취약점 조치: Server 헤더 숨기기 및 버전 정보 노출 방지 전략

HTTP 응답 헤더의 Server 필드(예: Apache/2.4, WebSphere Application Server/8.5)를 통해 서버의 종류와 버전이 노출되는 것을 방지하는 방법을 정리합니다. 앞단의 IBM HTTP Server(IHS)와 뒷단의 WebSphere(WAS) 양쪽 모두의 설정이 필요합니다.

0. 배경 및 원인 (Context)

서버의 구체적인 버전 정보가 노출되면, 해커는 해당 버전에 알려진 취약점(CVE)을 찾아 맞춤형 공격을 시도할 수 있습니다. 따라서 보안 모범 사례(Best Practice)에서는 서버 정보를 숨기거나 최소화할 것을 권고합니다.

Test Environment

OS: CentOS 7.2
Web Server: IBM HTTP Server (Apache 기반)
WAS: WebSphere Application Server v8.5

1. IBM HTTP Server (Web Server) 설정

가장 앞단에서 요청을 받는 웹 서버의 설정을 변경합니다. httpd.conf 파일에 아래 지시어를 추가하거나 수정합니다.

설정 내용 (httpd.conf)

# 1. 서버 정보 최소화 (Apache/x.y.z -> Apache)
ServerTokens Prod

# 2. 에러 페이지 하단(Footer)에 서버 정보 숨김
ServerSignature Off

# 3. Server 헤더 자체를 응답에서 제거 (IHS 전용 기능, 가능할 경우 권장)
AddServerHeader Off

Tip: AddServerHeader Off는 표준 Apache에는 없고 IBM HTTP Server에만 존재하는 지시어일 수 있습니다. 적용 후 Syntax Error가 난다면 ServerTokens Prod까지만 적용하십시오.

2. WebSphere (WAS) 설정

WAS가 직접 클라이언트에게 응답을 줄 때 붙는 헤더를 제어합니다. WAS v8.5.0.2 이상부터는 기본 동작이 변경되었으나, 명시적으로 제어하기 위해 HTTP 전송 채널(Transport Channel) 설정을 수정합니다.

설정 경로

서버 > WebSphere Application Server > [서버명] > 웹 컨테이너 설정 > 웹 컨테이너 전송 체인 > WCInboundDefault > HTTP 인바운드 채널 (HTTP_2) > 사용자 정의 특성 (Custom properties)

주요 속성 (택 1)

상황에 맞춰 아래 두 가지 속성 중 하나를 선택하여 적용합니다.

속성 이름 (Name)	설명 및 권장 값
RemoveServerHeader	값: true Server 헤더 자체를 아예 삭제합니다. 가장 강력한 보안 설정입니다.
ServerHeaderValue	값: (임의의 문자열) 기본값인 "WebSphere Application Server..." 대신 사용자가 지정한 문자열(예: "AppServer")로 치환합니다.

참고 (WebContainer 속성):
전송 채널 설정 외에도, 웹 컨테이너 > 사용자 정의 특성에서 com.ibm.ws.webcontainer.disableServerHeader 값을 true로 설정하는 방법도 존재합니다. (최신 버전에서 권장)

3. 검증 (Verification)

IHS와 WAS를 모두 재기동한 후, curl 명령어로 응답 헤더를 확인합니다.

# 헤더 확인
curl -I http://localhost/

# [Before]
HTTP/1.1 200 OK
Server: IBM_HTTP_Server/8.5 ...
...

# [After] 
HTTP/1.1 200 OK
# Server 헤더가 아예 없거나 "Apache" 또는 지정한 값으로 표시됨
...

Next Step:
헤더 숨김 처리가 완료되었습니다. 다음으로는 HTTP 메소드(PUT, DELETE, TRACE) 차단 설정을 통해 불필요한 요청을 막는 웹 서버 강화 작업을 진행해 보십시오.

Read Log →

#IBM HTTPServer

[IHS] SSL/TLS 보안 강화: Protocol 비활성화 및 Cipher Suite 화이트리스트 설정

IBM HTTP Server(IHS)는 Apache 기반이지만, SSL 모듈은 별도의 mod_ibm_ssl을 사용합니다. 따라서 커뮤니티 Apache(mod_ssl)와 프로토콜 설정 문법이 상이합니다. 두 서버 간의 설정 차이를 비교하고, IHS v8.5 환경에서의 보안 강화 설정을 정리합니다.

[Image of SSL TLS handshake process]

1. Apache vs IHS 설정 차이점 (Comparison)

두 웹 서버는 SSL/TLS 핸드쉐이크를 처리하는 엔진과 모듈이 다르기 때문에, httpd.conf에 작성하는 지시어(Directive)가 다릅니다. 마이그레이션이나 운영 시 혼동하지 않도록 주의해야 합니다.

구분	Apache HTTP Server (Community)	IBM HTTP Server (IHS)
사용 모듈	`mod_ssl` (OpenSSL 기반)	`mod_ibm_ssl` (IBM GSKit 기반)
프로토콜 설정	`SSLProtocol` (한 줄로 제어)	`SSLProtocolDisable` `SSLProtocolEnable` (개별 제어)
Cipher 설정	`SSLCipherSuite`	`SSLCipherSpec`

설정 문법 비교 예시

Apache (mod_ssl)

# 모든 프로토콜에서 SSLv2, SSLv3 제외
SSLProtocol all -SSLv2 -SSLv3

# Cipher Suite 설정 (OpenSSL 명명규칙 사용)
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

IHS (mod_ibm_ssl)

# 개별적으로 활성/비활성 지정
SSLProtocolDisable SSLv2
SSLProtocolDisable SSLv3
SSLProtocolEnable TLSv12

# Cipher Spec 설정 (Long Name 사용, 초기화 후 추가 방식 권장)
SSLCipherSpec ALL NONE
SSLCipherSpec ALL +TLS_RSA_WITH_AES_128_CBC_SHA

2. IHS 보안 설정 가이드 (Configuration)

IHS v8.5 이상 환경에서 취약한 프로토콜을 차단하고 안전한 Cipher만 허용하는 설정입니다.

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 443

# IP 기반 가상 호스트 활성화 (IHS 8.5 이하 필수)
NameVirtualHost *:443

<VirtualHost *:443>
    ServerName www.example.com
    DocumentRoot /app/EAR/SSL
    
    # SSL 엔진 활성화
    SSLEnable
    
    # 1. 취약 프로토콜 명시적 비활성화
    # (TLS 1.0, 1.1도 보안 정책에 따라 차단 고려)
    SSLProtocolDisable SSLv2
    SSLProtocolDisable SSLv3
    SSLProtocolDisable TLSv10
    SSLProtocolDisable TLSv11
    
    # 2. 안전한 프로토콜 활성화
    SSLProtocolEnable TLSv12
    
    # 3. Cipher Suite 화이트리스트 설정
    # 중요: 'ALL NONE'으로 기존 설정 초기화
    SSLCipherSpec ALL NONE
    
    # Forward Secrecy(PFS)를 지원하는 ECDHE 계열 우선 배치
    SSLCipherSpec ALL +TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 +TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    SSLCipherSpec ALL +TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 +TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    
    # 호환성을 위한 RSA/AES 계열 추가
    SSLCipherSpec ALL +TLS_RSA_WITH_AES_256_CBC_SHA +TLS_RSA_WITH_AES_128_CBC_SHA
</VirtualHost>

KeyFile /SW/web/HTTPServer/key/key.kdb
SSLDisable

3. 설정 검증 (Verification)

설정 적용 후 IHS를 재기동하기 전, 명령어를 통해 적용된 Cipher 목록을 확인합니다.

적용된 Cipher 확인

cd [IHS_HOME]/bin
./apachectl -t -D DUMP_SSL_CONFIG

접속 테스트 (nmap)

외부에서 스캔하여 취약한 프로토콜(SSLv3 등)이 노출되지 않는지 교차 검증합니다.

nmap --script ssl-enum-ciphers -p 443 [Target_IP]

Next Step:
IHS 9.0 (Apache 2.4 기반)으로 업그레이드할 경우, SSLProtocol 지시어를 Apache 스타일로 사용할 수 있게 되지만, 기존 IHS 설정과의 호환성을 위해 IBM 문서를 반드시 참조하시기 바랍니다.

Read Log →

#apache#IBM HTTPServer

[Apache/IHS] IP 접속 및 미등록 도메인 요청 차단 설정 (Default VirtualHost)

Apache(IHS) 웹 서버에서 도메인명이 아닌 IP 주소로 접속하거나, ServerName에 정의되지 않은 요청이 들어올 경우 이를 차단하거나 에러 페이지를 보여주는 방법을 정리합니다. 가장 먼저 로딩되는 Dummy VirtualHost를 활용하는 것이 핵심입니다.

0. 배경 지식 (Context)

Apache는 클라이언트 요청의 Host 헤더와 일치하는 ServerName(또는 ServerAlias)을 찾지 못할 경우, 설정 파일에서 가장 먼저 정의된 VirtualHost를 기본값(Default)으로 사용하여 요청을 처리합니다.

이 원리를 이용하여, 최상단에 아무런 ServerName을 갖지 않는(혹은 더미 값을 가진) VirtualHost를 배치하고 403 Forbidden 등을 반환하게 하면, 지정된 도메인 외의 모든 접근을 차단할 수 있습니다.

Test Environment

OS: CentOS 7.2
Web Server: IBM HTTPServer v8.5 (Apache 2.2 Base)

1. httpd.conf 설정 (VirtualHost 구성)

핵심은 순서입니다. 차단용(Dummy) 설정을 정상 서비스 설정보다 반드시 위쪽에 작성해야 합니다.

1) 기본 설정 및 포트 리슨

Listen 80
Listen 4958

# Apache 2.2 / IHS 8.5 이하 필수 (IP 기반 가상호스트 활성화)
NameVirtualHost *:80
NameVirtualHost *:4958

2) 차단용 Dummy VirtualHost (최상단 배치)

이 블록에는 ServerName을 지정하지 않거나 의미 없는 값을 넣습니다. 이곳으로 들어오는 요청은 모두 에러 메시지를 반환합니다.

# [80 포트] 미등록 도메인/IP 접속 차단
<VirtualHost *:80>
    DocumentRoot /app/was/htdocs
    
    # 접근 거부 메시지 설정 (보안상 상세 정보 숨김 권장)
    ErrorDocument 403 "Forbidden: Access is denied."
    ErrorDocument 404 "Not Found."
    ErrorDocument 500 "Internal Server Error."
    
    # 모든 요청에 대해 403 Forbidden 강제 반환 (mod_rewrite 사용 시)
    # RewriteEngine On
    # RewriteRule .* - [R=403,L]
    
    # 또는 디렉토리 접근 권한 제어
    <Directory "/app/was/htdocs">
        Order allow,deny
        Deny from all
    </Directory>
</VirtualHost>

# [4958 포트] 미등록 도메인/IP 접속 차단
<VirtualHost *:4958>
    DocumentRoot /app/was/htdocs
    ErrorDocument 403 "Forbidden: Access is denied."
    # ... (상동)
</VirtualHost>

3) 실제 서비스 VirtualHost

정상적인 도메인(ServerName)을 가진 요청만 처리하는 블록입니다. Proxy 설정을 포함합니다.

# Reverse Proxy 사용 시 Open Relay 방지
ProxyRequests Off

# [80 포트] 정상 서비스
<VirtualHost *:80>
    ServerName test.apache.com
    
    # WAS 또는 백엔드 서버로 프록시
    ProxyPass / http://172.31.98.155/ Keepalive=on
    ProxyPassReverse / http://172.31.98.155/
    
    # Host 헤더 유지 (WAS가 도메인을 인식하도록 함)
    ProxyPreserveHost On
    
    ErrorLog /app/was/HTTPServer/logs/test_proxy_error.log
    CustomLog /app/was/HTTPServer/logs/test_proxy_access.log combined
</VirtualHost>

# [4958 포트] 정상 서비스
<VirtualHost *:4958>
    ServerName test.httpserver.com
    
    ProxyPass / http://172.31.98.209/ Keepalive=on
    ProxyPassReverse / http://172.31.98.209/
    ProxyPreserveHost On
    
    ErrorLog /app/was/HTTPServer/logs/http_proxy_error.log
    CustomLog /app/was/HTTPServer/logs/http_proxy_access.log combined
</VirtualHost>

Tip: ProxyPreserveHost On 옵션은 클라이언트가 요청한 도메인 정보(Host Header)를 백엔드 서버(WAS)까지 그대로 전달합니다. WAS에서 가상 호스트를 구분해야 한다면 필수 옵션입니다.

2. 검증 (Verification)

설정 적용 후 웹 서버를 재기동하고 curl을 이용하여 테스트합니다.

1) 정상 도메인 접속 테스트

# 정상 응답(200 OK)이 와야 함
curl -v -H "Host: test.apache.com" http://localhost:80/

2) IP 접속 및 미등록 도메인 테스트

# 1. IP로 직접 요청 -> 403 또는 설정한 에러 메시지 출력되어야 함
curl -v http://localhost:80/

# 2. 엉뚱한 도메인 요청 -> 403 출력되어야 함
curl -v -H "Host: unknown.com" http://localhost:80/

Next Step:
Apache 2.4 (IHS 9.0 이상)를 사용 중이라면, NameVirtualHost 지시어는 더 이상 필요하지 않으므로 삭제하고, 접근 제어 구문을 Require all denied 등으로 변경해야 합니다.

Read Log →

#IBM HTTPServer

[IBM HTTPServer] SSL/TLS 암호화 슈트(Cipher Suite) 확인 및 점검 방법 (DUMP_SSL_CIPHERS)

IBM HTTP Server(IHS)에서 현재 적용된 SSL/TLS 프로토콜 버전과 지원하는 암호화 슈트(Cipher Suite) 목록을 확인하는 방법을 정리합니다. apachectl의 진단 옵션을 통해 서버에 설정된 보안 수준을 점검할 수 있습니다.

0. 배경 지식 (Context)

보안 취약점 점검 시 "SSLv3나 RC4 같은 약한 암호화 알고리즘을 비활성화하라"는 권고를 자주 받습니다. 조치를 취하기 전에, 현재 웹 서버가 어떤 알고리즘을 허용하고 있는지 정확히 파악하는 것이 우선입니다.

Test Environment

OS: CentOS 7.2
Web Server: IBM HTTPServer v8.5.0.0

1. Cipher Suite 확인 명령어

IHS는 apachectl 실행 스크립트에 -t(문법 검사) 옵션과 함께 -D DUMP_SSL_CIPHERS 정의를 추가하여, 현재 설정된 SSL 구성을 출력하는 기능을 제공합니다.

명령어 실행

cd [IHS_HOME]/bin

# SSL Cipher 설정 덤프
./apachectl -t -D DUMP_SSL_CIPHERS

결과 출력 예시 (Default 상태)

별도의 보안 설정(Hardening)이 되어 있지 않다면, 아래와 같이 IHS 버전의 기본값(Default)들이 출력됩니다.

SSL default cipher lists:
SSL protocol SSLV2, FIPS off, defaults = (None)
SSL protocol SSLV3, FIPS off, defaults = TLS_RSA_WITH_AES_128_CBC_SHA(2F), ...
SSL protocol TLSv10, FIPS off, defaults = TLS_RSA_WITH_AES_128_CBC_SHA(2F), ...
SSL protocol TLSv11, FIPS off, defaults = TLS_RSA_WITH_AES_128_CBC_SHA(2F), ...
SSL protocol TLSv12, FIPS off, defaults = TLS_RSA_WITH_AES_128_GCM_SHA256(9C), ...
Syntax OK

해석 주의 (Analysis):
위 출력 결과에 SSLV3 항목이 보인다면, 현재 서버는 보안에 취약한 SSLv3 프로토콜 통신을 허용하고 있다는 뜻입니다. 보안 강화를 위해 비활성화가 필요합니다.

2. 외부 도구를 이용한 교차 검증 (Verification)

서버 내부 설정뿐만 아니라, 외부에서 실제로 접속을 시도하여 어떤 Cipher가 노출되는지 확인하는 것이 가장 정확합니다.

1) nmap 사용 (Linux)

nmap의 스크립트 엔진을 사용하여 지원하는 Cipher 목록을 조회합니다.

nmap --script ssl-enum-ciphers -p 443 [서버IP]

2) OpenSSL 사용

특정 프로토콜로 접속이 되는지 테스트합니다.

# SSLv3 접속 시도 (접속 실패해야 안전함)
openssl s_client -connect [서버IP]:443 -ssl3

3. 보안 설정 강화 (Next Step)

취약한 프로토콜과 Cipher를 확인했다면, httpd.conf 파일에서 이를 차단해야 합니다.

설정 예시 (httpd.conf)

IHS에서는 SSLCipherSpec 지시어를 사용하여 특정 Cipher를 허용하거나 차단합니다.

<VirtualHost *:443>
    SSLEnable
    
    # 1. 취약한 프로토콜 비활성화 (TLS 1.2만 허용 권장)
    SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
    SSLProtocolEnable TLSv12

    # 2. 강력한 Cipher Suite만 허용 (예시)
    # 128비트 미만 차단, RC4/MD5 차단
    SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA
    SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA
    # 필요에 따라 추가...
</VirtualHost>

4. 참고 자료 (References)

OpenSSL / IANA Cipher Mapping Guide: Cipher 이름 매핑 정보
Qualys SSL Labs: 공인 도메인 SSL 보안 등급 진단 도구

Read Log →

#IBM HTTPServer

[IHS/Apache] 보안 강화를 위한 불필요 HTTP Method(PUT, DELETE, TRACE) 차단 설정

웹 서버 운영 시 보안 취약점(파일 변조, 정보 노출 등)을 방지하기 위해 GET, POST를 제외한 불필요한 HTTP Method(PUT, DELETE, TRACE, OPTIONS)를 차단하는 방법을 정리합니다. IBM HTTP Server(Apache) 설정과 WAS(web.xml) 설정 두 가지 방식을 다룹니다.

0. 배경 지식 (Context)

기본적으로 웹 서버는 다양한 HTTP Method를 지원하지만, 실제 서비스에서는 대부분 GET과 POST만 사용합니다. 불필요한 메소드를 열어둘 경우 다음과 같은 보안 위험이 있습니다.

PUT, DELETE: 악의적인 사용자가 서버의 파일을 생성, 수정, 삭제할 수 있음.
TRACE: XST(Cross-Site Tracing) 공격에 악용되어 쿠키/세션 정보가 탈취될 수 있음.
OPTIONS: 서버가 지원하는 메소드 정보를 노출함.

Test Environment

OS: CentOS 7.2
Web Server: IBM HTTP Server v8.5 (Apache 2.2 Base)

1. Web Server 레벨 차단 (httpd.conf)

가장 앞단의 웹 서버에서 원천 차단하는 것이 리소스 낭비를 막고 안전합니다. 두 가지 방법 중 하나를 선택하여 적용하십시오.

Method A: LimitExcept 지시어 사용 (권장)

특정 디렉토리나 URL 패턴에 대해 허용할 메소드를 정의하고 나머지는 거부하는 방식입니다.

# 1. 특정 디렉토리 기준 차단
<Directory "/WAS/htdocs">
    Options FollowSymLinks
    AllowOverride None
    
    # GET, POST를 제외한 모든 메소드 거부
    <LimitExcept GET POST>
        Order allow,deny
        Deny from all
    </LimitExcept>
</Directory>

# 2. 전역(URL) 기준 차단 (Directory 설정이 모호할 때)
<Location "/*">
    <LimitExcept GET POST>
        Order allow,deny
        Deny from all
    </LimitExcept>
</Location>

버전별 문법 주의 (Note):
IHS v8.5(Apache 2.2)는 Order/Deny를 사용하지만, IHS v9.0(Apache 2.4) 이상에서는 Require all denied 문법을 사용해야 합니다.

Method B: Mod_Rewrite 사용

mod_rewrite 모듈을 사용하여 메소드 조건을 검사하고 강제로 에러 코드를 반환하는 방식입니다.

LoadModule rewrite_module modules/mod_rewrite.so

<IfModule mod_rewrite.c>
    RewriteEngine On
    
    # 조건: 요청 메소드가 GET 또는 POST가 아니라면
    RewriteCond %{REQUEST_METHOD} !^(GET|POST)
    
    # 규칙: 405 (Method Not Allowed) 에러 반환
    RewriteRule .* - [R=405,L]
</IfModule>

2. WAS 레벨 차단 (web.xml)

웹 서버 설정이 불가능하거나, 애플리케이션(WAR) 단위로 제어가 필요한 경우 표준 배포 서술자(web.xml)를 사용합니다.

설정 방법

web.xml에 security-constraint를 추가하여 특정 메소드에 대한 접근을 제한합니다.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Restricted Methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        
        <!-- 차단할 메소드 명시 -->
        <http-method>PUT</http-method>
        <http-method>DELETE</http-method>
        <http-method>TRACE</http-method>
        <http-method>OPTIONS</http-method>
        <http-method>HEAD</http-method>
    </web-resource-collection>
    
    <!-- 중요: auth-constraint를 비워두면 누구에게도 권한을 주지 않음(차단) -->
    <auth-constraint />
</security-constraint>

3. 검증 (Verification)

설정 적용 후 반드시 테스트를 통해 차단 여부를 확인해야 합니다. telnet 또는 curl을 사용합니다.

Telnet을 이용한 테스트

$ telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.

# OPTIONS 메소드 요청 입력
OPTIONS / HTTP/1.0
Host: localhost
(엔터 두 번)

# 결과 확인 (403 Forbidden 또는 405 Method Not Allowed 확인)
HTTP/1.1 403 Forbidden
Date: Wed, 04 Jul 2018 01:44:40 GMT
...

Curl을 이용한 테스트 (간편)

# -X 옵션으로 메소드 지정, -I 옵션으로 헤더만 확인
curl -v -X OPTIONS http://localhost/

# 결과: < HTTP/1.1 403 Forbidden 확인

Next Step:
메소드 차단 외에도 ServerTokens Prod 설정을 통해 헤더에 노출되는 웹 서버 버전 정보를 숨기는 보안 조치를 추가로 검토해 보시기 바랍니다.

Read Log →

#IBM HTTPServer

[IBM HTTP Server ] IBM HTTP Server v8.5 vs v9.0: Apache Base Version 확인 및 차이점 (Apache 2.2 vs 2.4)

IBM HTTP Server(IHS)는 Apache HTTP Server를 기반으로 만들어졌습니다. IHS v8.5(Apache 2.2 기반)와 IHS v9.0(Apache 2.4 기반)의 버전 정보를 확인하고, 엔진 업그레이드에 따른 설정 파일(httpd.conf) 호환성 주의사항을 정리합니다.

1. 버전 확인 방법 (Check Version)

IHS의 실행 파일(apache.exe 또는 httpd)에 -V 옵션을 주어 컴파일 옵션과 기반 버전을 확인할 수 있습니다.

명령어

# Windows
cd [IHS_HOME]\bin
.\apache.exe -V

# Linux/Unix
cd [IHS_HOME]/bin
./apachectl -V

2. 버전별 상세 정보 (Output Analysis)

IHS v8.5 (Apache 2.2 Base)

IHS 8.5.5는 Apache 2.2.8 버전을 베이스로 하여 IBM의 추가적인 패치와 보안 수정이 적용된 버전입니다.

PS E:\app\was\HTTPServer\bin> .\apache.exe -V
Server version: IBM_HTTP_Server/8.5.5.0 (Win32)
Apache version: 2.2.8 (with additional fixes)  <-- Check Point
Server built:   Feb 20 2013 13:50:05
Architecture:   32-bit
Server MPM:     WinNT
  threaded:     yes (fixed thread count)
  forked:       no
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/winnt"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D HTTPD_ROOT="/apache"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

IHS v9.0 (Apache 2.4 Base)

IHS 9.0은 Apache 2.4.12 버전을 베이스로 합니다. Apache 2.4로 넘어오면서 성능 개선(Event MPM 등)과 설정 문법의 변화가 생겼습니다.

PS E:\software\IBM\HTTPServer9\bin> .\apache.exe -V
Server version: IBM_HTTP_Server/9.0.0.0-PI56034 (Win32)
Apache version: 2.4.12 (with additional fixes) <-- Check Point
Server built:   Apr 18 2016 20:28:53
Architecture:   32-bit
Server MPM:     WinNT
  threaded:     yes (fixed thread count)
  forked:       no
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/apache"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

3. 마이그레이션 주의사항 (Apache 2.2 vs 2.4)

IHS v8.5에서 v9.0으로 업그레이드할 때 가장 주의해야 할 점은 접근 제어(Access Control) 구문의 변화입니다. 기존 httpd.conf를 그대로 사용하면 에러가 발생할 수 있습니다.

주요 변경 점 비교

구분	IHS v8.5 (Apache 2.2)	IHS v9.0 (Apache 2.4)
모든 요청 허용	Order allow,deny Allow from all	Require all granted
모든 요청 거부	Order deny,allow Deny from all	Require all denied
특정 IP 허용	Order deny,allow Deny from all Allow from 127.0.0.1	Require ip 127.0.0.1

Warning: IHS 9.0에서 기존 2.2 문법(Order/Allow)을 사용하려면 mod_access_compat 모듈을 로드해야 합니다. 하지만 장기적으로는 신규 문법(Require)으로 전환하는 것을 권장합니다.

Next Step:
IHS 버전을 업그레이드할 계획이라면, 운영 중인 httpd.conf 파일 내의 접근 제어 구문을 미리 전수 조사하여 Apache 2.4 문법으로 변환하는 작업을 진행해 보십시오.

Read Log →

#IBM HTTPServer

[IBM HTTPServer] 로그 로테이션(Log Rotation) 설정 (rotatelogs)

IBM HTTPServer(Apache 기반)의 로그 파일이 단일 파일로 무한정 커지는 것을 방지하기 위해 rotatelogs 유틸리티를 사용하여 일(Day) 단위 등으로 로그를 자동 분할(Rotation)하는 설정 방법을 정리합니다.

Test Environment

OS: CentOS 7.2
Web Server: IBM HTTPServer v8.5

1. httpd.conf 설정 수정

IBM HTTPServer는 Apache 기반이므로 내장된 rotatelogs 바이너리를 파이프(|)로 연결하여 로그를 제어할 수 있습니다.

설정 파일 경로

위치: /IBM/HTTPServer/conf/httpd.conf

수정 내용

기존 ErrorLog와 CustomLog 설정을 주석 처리하고, 아래와 같이 파이프라인 구문을 추가합니다. 86400은 초 단위(24시간)를 의미합니다.

# 1. Error Log Rotation 설정
# ErrorLog logs/error_log (기존 주석 처리)
ErrorLog "|/IBM/HTTPServer/bin/rotatelogs /IBM/HTTPServer/logs/error_%Y%m%d.log 86400"

# 2. Access Log Rotation 설정
# CustomLog logs/access_log common (기존 주석 처리)
CustomLog "|/IBM/HTTPServer/bin/rotatelogs /IBM/HTTPServer/logs/access_%Y%m%d.log 86400" common

2. 로그 포맷 스트링 (Format Strings)

로그 파일명 생성 시 날짜 형식을 지정하기 위해 사용하는 주요 포맷 코드입니다.

Format	Description
%Y	4자리 연도 (예: 2024)
%y	2자리 연도 (예: 24)
%m	2자리 월 (01~12)
%d	2자리 일 (01~31)
%H	24시간제 시간 (00~23)
%M	분 (00~59)
%S	초 (00~59)
%a / %A	요일 이름 (단축 / 전체)
%b / %B	월 이름 (단축 / 전체)

Next Step:
설정을 변경한 후에는 반드시 IBM HTTPServer를 재기동(Restart)해야 로그 로테이션 프로세스가 정상적으로 시작됩니다. 재기동 후 logs 디렉토리에 날짜가 붙은 파일이 생성되는지 확인하십시오.

Read Log →

#IBM HTTPServer#security#SSL

[IBM HTTPServer] SSL(HTTPS) 구성 및 가상 호스트 설정 가이드

IBM HTTP Server(IHS)에 SSL 인증서를 적용하여 HTTPS 통신을 활성화하고, WebSphere Application Server(WAS)와 정상적으로 연동하기 위한 설정 절차를 정리합니다. httpd.conf 설정, 키 파일(KDB) 지정, 그리고 WAS 가상 호스트 포트 등록 과정을 포함합니다.

Test Environment

OS: CentOS 7.2 (경로는 Linux 기준, Windows는 드라이브명 참조)
Web Server: IBM HTTP Server v8.5
WAS: WebSphere Application Server v8.5

1. 웹 서버 설정 (httpd.conf)

IHS의 메인 설정 파일에서 SSL 모듈을 로드하고, 443 포트에 대한 VirtualHost를 구성해야 합니다.

설정 파일 수정

파일 위치: [IHS_ROOT]/conf/httpd.conf
주요 작업: 모듈 주석 해제, 포트 리슨, 인증서 키 파일(KDB) 경로 지정

### 1. SSL Module Load ###
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

### 2. Port Listen ###
Listen 0.0.0.0:443

### 3. Virtual Host Configuration ###
# 80 포트 (HTTP) 설정
<VirtualHost *:80>
    ServerName ad1.test.com
    DocumentRoot "/opt/IBM/HTTPServer/htdocs"
    # Redirect permanent / https://ad1.test.com/  (필요 시 HTTPS로 리다이렉트)
</VirtualHost>

# 443 포트 (HTTPS) 설정
<VirtualHost *:443>
    SSLEnable
    SSLClientAuth none
    ServerName ad1.test.com
    DocumentRoot "/opt/IBM/HTTPServer/htdocs"
    
    # 로그 설정 (권장)
    ErrorLog logs/ssl_error_log
    CustomLog logs/ssl_access_log common
</VirtualHost>

### 4. Global SSL Config ###
# VirtualHost 밖에서 전역 설정으로 Keyfile 지정
SSLDisable
Keyfile "/opt/IBM/HTTPServer/ssl/key.kdb"

# 보안 강화를 위한 프로토콜 설정 예시 (TLS 1.2만 허용 시)
# SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
# SSLProtocolEnable TLSv12

Note: Keyfile 지시어는 kdb 파일의 경로를 지정합니다. 해당 경로에 key.sth (Stash file)이 함께 존재해야 암호를 묻지 않고 구동됩니다.

2. 인증서 키 파일 (KDB) 준비

IHS는 CMS Key Database (.kdb) 포맷을 사용합니다. ikeyman GUI 툴이나 gskcapicmd(CLI)를 사용하여 개인키와 인증서를 관리합니다.

도구 위치: [IHS_ROOT]/bin/ikeyman (GUI 실행 시 X-Window 필요)
작업 내용:
- 새로운 KDB 파일 생성 (CMS 타입)
- 개인키 생성 (CSR) 및 발급받은 인증서(Signer, Personal) Import
- 중요: "Stash password to a file" 옵션을 체크하여 .sth 파일 생성 필수

3. WAS 가상 호스트 (Virtual Host) 등록

웹 서버 설정을 마쳤더라도, WAS의 가상 호스트 목록에 SSL 포트(443)가 등록되어 있지 않으면 플러그인이 요청을 거부하거나 WAS가 요청을 인식하지 못할 수 있습니다.

관리 콘솔 설정

위치: 환경(Environment) > 가상 호스트(Virtual Hosts) > default_host (또는 사용하는 가상 호스트) > 호스트 별명(Host Aliases)
작업: 새로 작성(New) 클릭
입력:
- 호스트 이름: * (모든 호스트) 또는 ad1.test.com
- 포트: 443
저장: 마스터 구성에 저장 후 변경 사항 동기화.

4. 검증 및 재기동

설정 파일의 문법 오류를 체크하고 웹 서버를 재기동하여 변경 사항을 적용합니다.

Syntax Check

# IHS bin 디렉토리로 이동
./apachectl -t

# 결과가 'Syntax OK'여야 함

Server Restart

./apachectl restart

Next Step:
브라우저에서 https://ad1.test.com으로 접속하여 자물쇠 아이콘이 정상적으로 표시되는지 확인하고, SSL Labs 등의 도구를 통해 적용된 암호화 프로토콜(TLS 1.2 등)의 보안 등급을 점검해보시기 바랍니다.

Read Log →

#IBM HTTPServer#WebSphere

[WebSphere] WEB/WAS 정적(Static) 및 동적(Dynamic) 컨텐츠 분리 처리 전략

웹 시스템 성능 최적화를 위해 이미지, CSS, JS 등 정적 리소스는 Web Server(IHS)가 처리하고, JSP, Servlet 등 동적 리소스는 WAS가 처리하도록 역할을 분리하는 방법을 정리합니다. plugin-cfg.xml 제어 방식과 WAS의 fileServingEnabled 옵션 사용법을 다룹니다.

Test Environment

OS: CentOS 7.2
Web Server: IBM HTTP Server v8.5
WAS: WebSphere Application Server v8.5

1. 개요 및 목적

기본적으로 WebSphere 플러그인은 모든 요청을 WAS로 전달하도록 구성될 수 있습니다. 하지만 정적 파일(*.jpg, *.css 등)까지 WAS가 처리하게 되면 컨테이너의 스레드 자원을 낭비하게 됩니다. 따라서 이를 분리하여 시스템 효율성을 높여야 합니다.

2. Method 1: Plugin-cfg.xml 수동 제어

가장 직관적인 방법은 웹 서버 플러그인 설정 파일(plugin-cfg.xml)에서 WAS로 넘길 요청의 패턴(URI)을 강제로 지정하는 것입니다.

설정 파일 수정

파일 위치: [IHS_ROOT]/Plugins/config/[WebServerName]/plugin-cfg.xml
수정 내용: UriGroup 내에서 WAS가 처리해야 할 확장자만 남기고 나머지는 제거하거나 주석 처리합니다.

<UriGroup Name="default_host_server1_root-PCNode01_Cluster_URIs">
    <!-- WAS가 처리할 동적 컨텐츠만 명시 -->
    <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/>
    <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.do"/>
    <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/servlet/*"/>
</UriGroup>

위와 같이 설정하면 명시되지 않은 이미지나 HTML 파일 등은 플러그인을 타지 않고 웹 서버(IHS)가 자신의 DocumentRoot 또는 Alias 경로에서 파일을 찾아 처리합니다.

3. Method 2: WAS fileServingEnabled 옵션 사용

WebSphere 애플리케이션 배포 설정에서 정적 파일 서빙 기능을 비활성화(False)하여, 플러그인 생성 시 정적 파일에 대한 URI 매핑을 자동으로 제외하는 방법입니다.

설정 파일 위치 및 수정

애플리케이션의 WEB-INF 디렉터리에 있는 확장 설정 파일을 수정합니다.

경로 예시: [Profile_Root]/installedApps/[CellName]/[AppName].ear/[WarName].war/WEB-INF/

1) ibm-web-ext.xmi (구버전 스타일)

<webappext:WebAppExtension ... fileServingEnabled="false" ...>
</webappext:WebAppExtension>

2) ibm-web-ext.xml (WAS v7.0 이상 권장)

<web-ext xmlns="http://websphere.ibm.com/xml/ns/javaee/web-ext/1.0" ...>
    <!-- 정적 파일 서빙 비활성화 -->
    <enable-file-serving value="false"/>
</web-ext>

적용 절차

설정 파일 수정 (fileServingEnabled="false")
WAS 관리 콘솔에서 플러그인 재생성 (Generate Plug-in)
재생성된 plugin-cfg.xml을 웹 서버로 전파 (Propagate)

이 과정을 거치면 plugin-cfg.xml 내에 정적 파일(*.html, *.jpg 등)에 대한 URI 정의가 자동으로 삭제됩니다.

4. WebServer (IHS) Alias 설정

WAS로 요청이 넘어가지 않는 정적 파일들을 웹 서버가 찾아서 제공할 수 있도록 물리적 경로를 매핑해야 합니다.

httpd.conf 설정

파일 위치: [IHS_ROOT]/conf/httpd.conf
설정 예시: URL의 /images 요청을 실제 서버의 /home/images 디렉터리로 연결

# 정적 리소스 경로 매핑
Alias /images /home/images

<Directory "/home/images">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

5. 요약 및 주의사항

Full URI 패턴 주의: plugin-cfg.xml에 Name="*" 와 같은 설정이 있다면 모든 요청이 WAS로 넘어갑니다. 성능 저하의 주원인이므로 삭제해야 합니다.
동기화: fileServingEnabled 옵션을 변경했다면 반드시 플러그인을 재생성 및 전파하고 웹 서버를 재기동(Restart) 해야 적용됩니다.
배포 전략: 정적/동적 분리 구성 시, 개발팀은 정적 리소스(이미지 등)를 WAS 배포 패키지(WAR/EAR)와 별도로 웹 서버 경로에 배포하는 프로세스를 수립해야 합니다.

Next Step:
구성이 완료되었다면 브라우저 개발자 도구(F12)의 Network 탭을 통해 정적 파일 요청 시 Response Header에 Server: IBM_HTTP_Server가 찍히는지(WAS 정보가 아닌지) 확인하여 분리 처리가 정상적인지 검증해보십시오.

Read Log →

#IBM HTTPServer

[WebSphere] IHS Plugin Key(kdb) 만료일 확인 및 패스워드 갱신 (gsk7capicmd)

IBM HTTP Server(IHS) 플러그인이 사용하는 키 데이터베이스 파일(plugin-key.kdb)에는 내부 패스워드 만료일이 존재합니다. 만료 시 웹 서버 플러그인이 HTTPS 통신을 초기화하지 못해 장애가 발생할 수 있습니다. 이를 확인하고 갱신하는 gsk7capicmd 명령어 사용법을 정리합니다.

1. 문제 상황 및 증상

플러그인 키 파일의 패스워드가 만료되면 웹 서버(IHS) 재기동 시 또는 플러그인 전파(Propagation) 후 다음과 같은 에러가 발생하며 WAS와의 SSL 통신이 실패합니다.

ERROR: lib_security: initializeSecurity: Failed to initialize GSK environment
ERROR: ws_transport: transportInitializeSecurity: Failed to initialize security

2. 만료일 확인 (Check Expiry)

gsk7capicmd 명령어를 사용하여 현재 plugin-key.kdb 파일의 패스워드 만료일을 확인합니다.

기본 정보:

기본 패스워드: WebAS
명령어 위치: [IHS_ROOT]/bin 또는 [GSK_ROOT]/bin

Windows 환경

C:\IBM\HTTPServer\bin> gsk7capicmd -keydb -expiry -db "C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-key.kdb" -pw WebAS

Validity: Thursday, 26 April 2012 11:20:31 AM Eastern Daylight Time

Unix/Linux/AIX 환경

# 경로 이동 (예시)
cd /usr/bin
# 또는 /usr/opt/ibm/gskta/bin/gsk7capicmd

# 만료일 확인
./gsk7capicmd -keydb -expiry -db "/IBM/Plugins/config/webserver1/plugin-key.kdb" -pw WebAS

Validity: Friday, 27 April 2012 00:20:31 AM KORST

3. 패스워드 변경 및 만료일 연장 (Change Password)

패스워드를 변경함과 동시에 만료 기간을 연장합니다. 변경된 패스워드는 반드시 -stash 옵션을 사용하여 저장해야 플러그인이 자동으로 파일을 읽을 수 있습니다.

주요 옵션 설명

-changepw: 패스워드 변경 모드
-new_pw: 새로운 패스워드 (기존 패스워드 재사용 불가)
-expire: 만료일 설정 (일 단위). 0으로 설정 시 만료되지 않음(권장).
-stash: 패스워드를 .sth 파일에 암호화하여 저장 (필수)

명령어 실행 예시

# Windows
gsk7capicmd -keydb -changepw -db "C:\path\to\plugin-key.kdb" -pw WebAS -new_pw WebAS1 -expire 0 -stash

# Unix/Linux/AIX
./gsk7capicmd -keydb -changepw -db "/path/to/plugin-key.kdb" -pw WebAS -new_pw WebAS1 -expire 0 -stash

Note: GSKit 7.0.3.17 이전 버전은 -expire 파라미터를 지원하지 않을 수 있습니다. 이 경우 최신 버전으로 업데이트하거나 패스워드를 주기적으로 변경해야 합니다.

4. 기타 플랫폼별 대응 (z/OS, IBM i)

z/OS (gskkyman 사용)

plugin-key.kdb 파일 위치로 이동 후 gskkyman 실행.
메뉴에서 "3 - Change database password" 선택.
현재 패스워드(WebAS) 및 신규 패스워드 입력.
만료일(Expiration days) 입력 프롬프트에서 엔터(Enter)를 눌러 만료 없음(No expiration) 설정.
변경 후 반드시 Stash 파일 갱신: gskkyman -s -k plugin-key.kdb

IBM i (Digital Certificate Manager 사용)

IBM i 환경(V5R4, V6R1, V7R1)에서는 브라우저 기반의 DCM 도구를 사용합니다.

HTTP Admin 서버 시작: STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
브라우저 접속: http://[machine]:2001
Digital Certificate Manager > Select a certificate store 선택.
Other System Certificate Store 선택 후 plugin-key.kdb 경로 입력.
Reset password 클릭 후 신규 패스워드 설정.
옵션에서 "Password does not expire" 및 "Automatic login"(Stash 효과) 체크.

Next Step:
작업 완료 후 반드시 웹 서버(IHS)를 재기동하여 플러그인이 갱신된 plugin-key.kdb 및 stash 파일을 정상적으로 로드하는지 확인하십시오.

Read Log →