IBM HTTP Server(IHS)와 WebSphere Liberty 환경에서 X-Powered-By 헤더(예: Servlet/3.1) 노출을 차단하는 방법을 정리합니다. 보안 강화를 위해 웹 서버(IHS) 단에서의 필터링과 WAS(Liberty) 단에서의 생성 금지 설정을 모두 적용하는 것을 권장합니다.

0. 배경 및 전략 (Context)

보안 취약점 조치 시, 정보 노출 방지는 다계층 방어(Defense in Depth)가 중요합니다.

Test Environment

• Web Server: IBM HTTP Server v9.0 (Apache 2.4 Base)
• WAS: WebSphere Liberty Core 20.0.x

1. IBM HTTP Server (IHS) 설정

Apache 기반인 IHS에서는 mod_headers 모듈을 사용하여 응답 헤더를 제어합니다.

httpd.conf 수정

설정 파일(httpd.conf)을 열어 아래 내용을 적용합니다.

# 1. 모듈 로드 확인 (주석 해제 필수)
LoadModule headers_module modules/mod_headers.so

# 2. 헤더 제거 설정 (Global 영역 또는 VirtualHost 내부에 작성)
<IfModule mod_headers.c>
    # 보안 조치: 기술 스택 정보 숨김
    Header unset X-Powered-By
    
    # (선택) 추가적인 정보 노출 헤더 차단
    Header unset X-AspNet-Version
    Header unset X-Runtime
</IfModule>

# 3. 서버 버전 정보 최소화 (OS 정보 등 숨김)
ServerTokens Prod

2. WebSphere Liberty 설정

Liberty는 server.xml 파일 하나로 대부분의 설정을 처리합니다. webContainer 요소를 추가하거나 수정하여 헤더 생성을 비활성화합니다.

server.xml 수정

<server description="Liberty Server">

    <!-- Feature Manager (기본 설정) -->
    <featureManager>
        <feature>servlet-3.1</feature>
    </featureManager>

    <!-- [보안 조치] X-Powered-By 헤더 비활성화 속성 추가 -->
    <webContainer disableXPoweredBy="true" />

</server>

Liberty는 동적 설정을 지원하므로 파일 저장 시 즉시 반영되지만, 운영 환경에서는 확실한 적용을 위해 서버 재기동을 권장합니다.

3. 검증 (Verification)

curl 명령어를 사용하여 조치 전후의 응답 헤더를 비교합니다.

조치 전 (Before)

HTTP/1.1 200 OK
X-Powered-By: Servlet/3.1
Server: IBM_HTTP_Server/9.0.5...
...

조치 후 (After)

curl -I http://localhost:80/

HTTP/1.1 200 OK
Server: IBM_HTTP_Server   <-- (Prod 설정으로 버전 숨김)
Content-Type: text/html
...                       <-- (X-Powered-By 헤더 삭제됨)

Next Step:
헤더 조치가 완료되었다면, HTTP 메소드 제한(GET, POST 외 차단) 및 SSL/TLS 프로토콜 버전(TLS 1.2 Only) 설정을 통해 웹 서비스 보안을 한 단계 더 강화해 보십시오.

Apache 웹 서버 운영 시 기본적으로 노출되는 서버 버전(Version), 운영체제(OS), 모듈(Module) 정보를 숨겨 보안성을 높이는 방법을 정리합니다. httpd.conf 파일의 ServerTokens 및 ServerSignature 지시어를 최적화하여 정보 유출 취약점을 조치합니다.

0. 배경 및 취약점 (Context)

공격자는 Banner Grabbing 기법을 통해 대상 서버의 구체적인 버전 정보를 수집하고, 해당 버전에 알려진 취약점(CVE)을 이용해 공격을 시도합니다. 따라서 서버 정보 노출을 최소화하는 것은 보안 강화(Hardening)의 첫걸음입니다.

1. 필수 설정 (Basic Configuration)

Apache 설정 파일(httpd.conf 또는 security.conf)에서 다음 두 가지 지시어를 찾아 수정하거나 추가합니다.

1) 헤더 정보 제한 (ServerTokens)

HTTP 응답 헤더의 Server 필드에 표시되는 정보량을 제어합니다.

• 기본값 (Full): Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.0 ... (모두 노출)
• 권장값 (Prod): Apache (제품명만 노출)

# Server 헤더에 제품명(Apache)만 표시
ServerTokens Prod

2) 에러 페이지 서명 제거 (ServerSignature)

404 Not Found, 403 Forbidden 등 에러 페이지 하단에 표시되는 서버 정보를 제어합니다.

• 기본값 (On): 에러 메시지 하단에 서버 버전과 포트 정보가 표시됨
• 권장값 (Off): 하단 서명 라인을 제거함

# 에러 페이지 하단에 서버 정보 숨김
ServerSignature Off

2. 심화 설정 (Advanced Configuration)

위의 ServerTokens Prod 설정을 적용해도 Server: Apache라는 정보는 여전히 남습니다. 보안 감사를 위해 이 헤더조차 아예 삭제하고 싶다면 mod_headers 모듈을 사용해야 합니다.

<IfModule mod_headers.c>
    # Server 헤더 자체를 응답에서 제거 (권장)
    Header unset Server
    
    # 또는 다른 이름으로 위장 (Security by Obscurity)
    # Header set Server "MySecureServer"
</IfModule>

3. 설정 적용 및 검증 (Verification)

서비스 재기동

# Syntax 검사
apachectl -t

# 서비스 재기동 (CentOS/RHEL)
systemctl restart httpd

# 서비스 재기동 (Ubuntu/Debian)
systemctl restart apache2

적용 확인 (curl)

curl -I 옵션을 사용하여 응답 헤더만 조회해 봅니다.

# 명령 실행
curl -I http://localhost

# [Before]
HTTP/1.1 200 OK
Server: Apache/2.4.6 (CentOS) ... (취약)

# [After 1 - Prod 적용]
Server: Apache

# [After 2 - Header unset 적용]
(Server 헤더가 아예 보이지 않음)

Next Step:
서버 정보 숨김 조치가 완료되었다면, 추가적인 보안 강화를 위해 X-Content-Type-Options, X-Frame-Options 등 보안 헤더 적용을 검토해 보십시오.

Apache Log4j 취약점(CVE-2021-44228 등)이 IBM WebSphere Application Server(WAS)에 미치는 영향을 분석합니다. WAS 9.0의 관리 콘솔 도움말(kc.war)과 전 버전의 UDDI 레지스트리(uddi.ear)에 포함된 취약한 라이브러리를 제거하는 임시 조치(Mitigation) 방법을 정리합니다.

1. 영향받는 제품 및 버전 (Affected Products)

사실상 현재 운영 중인 대부분의 WebSphere 버전이 직간접적인 영향권에 있습니다.

2. 취약점 상세 및 조치 가이드 (Remediation)

WAS 엔진 자체보다는 번들로 제공되는 특정 애플리케이션 내의 라이브러리가 문제입니다. 사용하지 않는 기능이라면 과감하게 삭제하는 것이 가장 확실한 방법입니다.

Case A: WAS 9.0 - kc.war (관리 콘솔 도움말)

WAS 9.0 관리 콘솔의 '도움말(Knowledge Center)' 기능에 Log4j 2.x 취약 버전이 포함되어 있습니다.

• 대상: WAS 9.0 사용자
• 조치 방법: 해당 라이브러리 파일 삭제

# 1. 배포된 디렉토리에서 라이브러리 제거
rm -f [WAS_HOME]/systemApps/isclite.ear/kc.war/WEB-INF/lib/log4j*.jar

# 2. 설치 가능 앱 디렉토리에서 원본 앱 제거 (재설치 방지)
rm -rf [WAS_HOME]/installableApps/kc.war

# 3. 서버 재기동
./stopServer.sh server1 && ./startServer.sh server1

Case B: 전 버전 - uddi.ear (UDDI 레지스트리)

UDDI(Universal Description, Discovery, and Integration) 서비스에 Log4j 라이브러리가 포함되어 있습니다. 대부분의 최신 환경에서는 사용하지 않는 기능입니다.

• 대상: WAS 7.0 ~ 9.0 전체
• 조치 방법: 사용하지 않는다면 파일 삭제

# 미사용 시 (권장)
rm -f [WAS_HOME]/installableApps/uddi.ear

# 사용 중일 경우 (라이브러리만 교체/삭제 후 재배포 필요)
# uddi.ear 압축 해제 -> log4j*.jar 삭제 -> 다시 압축 -> Redeploy

3. Log4j 1.x 관련 추가 조치 (CVE-2021-4104)

Log4j 1.x 버전은 Log4Shell(RCE) 취약점의 직접적인 대상은 아니지만, JMSAppender를 사용할 경우 유사한 공격이 가능합니다. (WAS 기본 설정에는 JMSAppender가 없으나, 애플리케이션에서 사용할 수 있음)

조치 방법 (JMSAppender 제거)

Log4j 1.x는 더 이상 보안 패치가 나오지 않으므로(EOL), 취약한 클래스 파일만 강제로 삭제하는 것이 유일한 방법입니다.

# 시스템 전체에서 log4j-1.2.x.jar 파일을 찾아 JMSAppender 클래스 제거
zip -q -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

4. 참고 자료 (Reference)

• IBM Security Bulletin: Log4j vulnerability (CVE-2021-44228)

WebSphere v8.5 환경에서 보안 감사 및 트러블슈팅을 위해 NCSA Access Log를 활성화하는 방법을 정리합니다. 서버 전역 설정과 전송 체인(Transport Chain)별 설정을 모두 적용해야 하며, accessLogFormat 속성을 통해 클라이언트 IP, 수행 시간, User-Agent 등을 기록하도록 포맷을 변경하는 방법을 다룹니다.

0. 배경 및 필요성 (Context)

WAS 앞단에 웹 서버(Web Server)가 있다면 웹 서버 로그를 분석하면 되지만, WAS로 직접 들어오는 요청이나 내부 통신, 혹은 상세한 애플리케이션 수행 시간 분석을 위해서는 WAS 자체의 Access Log가 필요합니다. WebSphere는 NCSA 표준 포맷을 지원합니다.

Test Environment

• Version: WebSphere Application Server v8.5

1. 전역 로깅 서비스 활성화 (Global Setting)

가장 먼저 서버 차원에서 로깅 서비스를 켜야 합니다.

1. 관리 콘솔에서 Servers > Server Types > WebSphere application servers > [서버명] 클릭
2. 우측 하단의 Troubleshooting 섹션에서 NCSA access and HTTP error logging 클릭
3. 설정 체크:
   • Enable logging service at server start-up (서버 기동 시 서비스 활성화)
   • Enable access logging (액세스 로깅 활성화)

2. 전송 체인별 로깅 활성화 (Chain Setting)

전역 설정을 했더라도, 실제 통신을 담당하는 전송 체인(Transport Chain)에서 로깅을 켜지 않으면 로그가 남지 않는 경우가 많습니다. 사용하는 포트(9080, 9443 등)에 해당하는 체인을 수정해야 합니다.

설정 경로

[서버명] > Web Container Settings > Web container transport chains

설정 방법

주로 사용되는 체인(WCInboundDefault, HttpQueueInboundDefault 등)을 선택하여 아래 작업을 반복합니다.

1. 체인 이름 클릭 (예: WCInboundDefault)
2. HTTP inbound channel (HTTP_2) 클릭
3. Enable logging 체크박스 선택

3. 로그 포맷 커스터마이징 (Custom Properties)

기본 포맷(Common Log Format)은 정보가 부족할 수 있습니다. 수행 시간이나 세션 ID, User-Agent 등을 남기기 위해 사용자 정의 속성을 추가합니다.

속성 추가 위치

위의 HTTP inbound channel (HTTP_2) 설정 화면에서 우측의 Custom properties (사용자 정의 특성) 메뉴로 진입합니다.

속성 값 (Key & Value)

• Name: accessLogFormat
• Value: (아래 예시 중 선택)

# 예시 1: 표준 확장 포맷 (IP, 시간, 요청, 상태, 크기, 수행시간)
%h %u %t "%r" %s %b %D

# 예시 2: 전체 정보 포함 (Referer, User-Agent, SessionID 포함)
%h %u %t "%r" %s %b %D "%{Referer}i" "%{User-agent}i" %{JSESSIONID}C

4. 주요 포맷 지시어 설명

Next Step:
모든 설정을 마친 후에는 반드시 서버를 재기동해야 로그가 남기 시작합니다. logs/[서버명]/http_access.log 파일이 생성되는지 확인하십시오.

WebSphere Application Server v7.0, v8.0, v8.5 환경에서 TLS 1.2 프로토콜을 활성화하기 위한 최소 요구 사항(Fix Pack, JDK)을 확인하고, WAS, IHS, Plugin 각 계층별 필수 설정 방법을 정리합니다. 특히 플러그인 연결 시 발생하는 GSK_ERROR_SOCKET_CLOSED 에러 해결법을 포함합니다.

1. 버전별 TLS 1.2 지원 현황 (Prerequisites)

TLS 1.2를 사용하려면 WAS 버전에 따른 최소 픽스팩(Fix Pack)과 JDK 버전이 충족되어야 합니다.

2. WAS 설정 (Application Server)

관리 콘솔에서 SSL 설정을 변경하고, 관리 명령(stop/sync) 수행을 위해 클라이언트 설정 파일도 함께 수정해야 합니다.

1) 관리 콘솔 설정 (QoP)

Security > SSL certificate and key management > SSL configurations 메뉴로 이동합니다. CellDefaultSSLSettings, NodeDefaultSSLSettings 등 사용 중인 모든 설정을 수정합니다.

1. 설정 이름 클릭 (예: CellDefaultSSLSettings)
2. 우측의 Quality of protection (QoP) settings 클릭
3. Protocol 드롭다운 메뉴에서 TLSv1.2 선택
4. 저장 (Save)

2) ssl.client.props 수정 (중요)

이 설정을 하지 않으면 WAS가 TLS 1.2로 전환된 후, stopNode나 syncNode 같은 관리 명령어가 구형 프로토콜로 통신을 시도하여 실패하게 됩니다.

• 대상 파일:
  • [PROFILE_HOME]/properties/ssl.client.props

# 파일 내 해당 라인 수정
com.ibm.ssl.protocol=TLSv1.2

3) 재기동 및 동기화

설정 적용을 위해 DMGR부터 순서대로 재기동합니다.

# 1. 노드 및 DMGR 중지
./stopNode.sh
./stopManager.sh

# 2. DMGR 기동
./startManager.sh

# 3. 노드 동기화 (수동 동기화 권장)
./syncNode.sh [Dmgr_Host] [Dmgr_SOAP_Port] -username [ID] -password [PW]

# 4. 노드 기동
./startNode.sh

3. Web Server (IHS) 설정

IBM HTTP Server의 httpd.conf 파일에서 SSL 설정을 강화합니다.

<VirtualHost *:443>
    SSLEnable
    
    # TLS 1.2 활성화
    SSLProtocolEnable TLSv12
    
    # 취약한 하위 프로토콜 비활성화
    SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
</VirtualHost>

4. Plugin 설정 (Troubleshooting)

WAS와 IHS를 모두 TLS 1.2로 설정했는데도 http_plugin.log에 GSK_ERROR_SOCKET_CLOSED (gsk rc = 420) 에러가 발생하며 연결이 안 될 수 있습니다. 이는 플러그인이 기본적으로 보안 수준을 엄격하게 검사하지 않아서 발생하는 호환성 문제입니다.

해결 방법: StrictSecurity 적용

plugin-cfg.xml 파일의 최상단 Config 태그에 속성을 추가해야 합니다.

<Config StrictSecurity="true">
    <Log LogLevel="Error" Name="..." />
    ...
</Config>

5. 검증 (Verification)

openssl 명령어를 사용하여 서버가 TLS 1.2만 허용하는지 테스트합니다.

# TLS 1.2 접속 성공 확인
openssl s_client -connect [Host]:9443 -tls1_2

# TLS 1.0 접속 실패 확인 (핸드쉐이크 에러가 나야 정상)
openssl s_client -connect [Host]:9443 -tls1

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

2. WebSphere (WAS) 설정

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

설정 경로

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

주요 속성 (택 1)

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

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) 차단 설정을 통해 불필요한 요청을 막는 웹 서버 강화 작업을 진행해 보십시오.

웹 서버 응답 헤더에 포함된 X-Powered-By 정보(예: Servlet/3.1)는 불필요한 서버 정보를 노출하여 보안 취약점으로 분류됩니다. IBM WebSphere Application Server(WAS) v8.5 이상에서 웹 컨테이너 사용자 정의 속성을 통해 이 헤더를 제거하는 방법을 정리합니다.

0. 배경 및 원인 (Context)

기본적으로 WAS는 클라이언트에게 응답을 보낼 때, 자신이 사용한 기술 스택을 헤더에 포함합니다.

• X-Powered-By: 구현 기술 정보 (예: Servlet/3.0, JSP/2.2)
• Server: 웹 서버 소프트웨어 정보 (예: WebSphere Application Server/8.5)

공격자는 이 정보를 바탕으로 특정 버전에 존재하는 알려진 취약점(CVE)을 공격할 수 있으므로, 운영 환경에서는 반드시 숨겨야 합니다.

Test Environment

• OS: CentOS 7.2
• WAS: WebSphere Application Server v8.5.5

1. X-Powered-By 헤더 제거 설정

WAS 관리 콘솔(Admin Console)에서 웹 컨테이너 설정을 변경합니다.

설정 경로

서버(Servers) > 서버 유형(Server Types) > WebSphere application servers > [서버명] > 웹 컨테이너 설정(Web Container Settings) > 웹 컨테이너(Web container) > 사용자 정의 특성(Custom properties)

속성 추가 (New)

2. 검증 (Verification)

설정 저장 후 서버를 반드시 재기동해야 적용됩니다. curl 명령어나 브라우저 개발자 도구(F12)를 통해 응답 헤더를 확인합니다.

명령어 확인 (Linux)

# -I 옵션으로 헤더만 조회
curl -I http://localhost:9080/

# 적용 전 (노출됨)
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
Content-Type: text/html
...

# 적용 후 (사라짐)
HTTP/1.1 200 OK
Content-Type: text/html
...

브라우저 확인

Chrome 개발자 도구 > Network 탭 > 아무 요청 클릭 > Response Headers 섹션에서 해당 항목이 사라졌는지 확인합니다.

Next Step:
WAS 설정뿐만 아니라 앞단의 웹 서버(IHS/Apache)에서도 ServerTokens Prod 설정을 통해 Apache 버전 정보 노출을 최소화해야 완벽한 보안 조치가 됩니다.

보안 컴플라이언스 준수를 위해 JBoss EAP 7의 standalone.xml 또는 domain.xml 파일 내에 저장되는 DB 패스워드를 암호화하는 방법을 정리합니다. org.picketbox 모듈을 이용하여 암호화된 문자열을 생성하고, Security Domain을 통해 데이터소스와 연동합니다.

0. 배경 및 준비 (Context)

JBoss 설정 파일에 비밀번호를 평문으로 저장하면 보안 감사 시 지적 대상이 됩니다. 이를 해결하기 위해 JBoss는 Security Domain을 통해 인증 과정을 위임하는 방식을 제공합니다.

Test Environment

• OS: CentOS 7.2
• WAS: JBoss EAP 7.2
• JDK: 1.8

1. 비밀번호 암호화 문자열 생성 (Encryption)

가장 먼저 실제 DB 패스워드를 암호화된 문자열로 변환해야 합니다. JBoss 내부 모듈인 picketbox를 Java로 실행하여 변환합니다.

암호화 스크립트 (create_encrypt_pw.sh)

JBoss 패치(CP)가 적용되면 .overlays 디렉토리에 라이브러리가 변경될 수 있습니다. 아래 스크립트는 패치 여부를 자동으로 감지하여 적절한 jar 파일을 찾아 실행합니다.

#!/bin/sh

# 1. 환경 변수 설정 (사용자 환경에 맞게 수정 필수)
export JAVA_HOME="/SW/was/java1.8"
export PATH="$JAVA_HOME/bin:$PATH"
JBOSS_HOME="/SW/was/JBoss7.2"

# 2. 라이브러리 경로 탐색 (Overlay 지원)
OVERLAY_DIRECTORY="$JBOSS_HOME/modules/system/layers/base/.overlays"
SEARCH_DIRECTORY="$JBOSS_HOME/modules/system/layers/base/org/picketbox/main"

if [ -d "$OVERLAY_DIRECTORY" ]; then
    # 최신 패치 디렉토리 확인
    PATCH_SUBDIRECTORY=$(ls -dt $OVERLAY_DIRECTORY/* | grep "CP" | head -n 1)
    if [ -n "$PATCH_SUBDIRECTORY" ]; then
        echo "Info: Patch directory detected: $PATCH_SUBDIRECTORY"
        SEARCH_DIRECTORY="$PATCH_SUBDIRECTORY/org/picketbox/main"
    fi
fi

# 3. Classpath 설정
export CLASSPATH=$(find "$SEARCH_DIRECTORY" -name "*.jar" -print | tr '\n' ':')$CLASSPATH

# 4. 암호화 실행
echo ""
read -p "Enter Database Password : " PASSWORD
echo ""
echo "####################################################"
java org.picketbox.datasource.security.SecureIdentityLoginModule "$PASSWORD"
echo "####################################################"
echo ""

실행 결과 예시

Encoded password: 9fdd42c2a7390d3

출력된 Encoded password 값을 복사해 둡니다.

2. Security Domain 설정 (standalone.xml)

생성한 암호화 패스워드를 사용하는 보안 도메인을 정의합니다. security 서브시스템 내에 작성합니다.

설정 내용

<subsystem xmlns="urn:jboss:domain:security:2.0">
    <security-domains>
        
        <security-domain name="encryptedSecurityDB" cache-type="default">
            <authentication>
                <login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
                    <module-option name="username" value="sa"/>
                    <module-option name="password" value="9fdd42c2a7390d3"/> <!-- 암호화된 값 -->
                    <module-option name="managedConnectionFactoryName" value="jboss.jca:service=LocalTxCM"/>
                </login-module>
            </authentication>
        </security-domain>
        
    </security-domains>
</subsystem>

3. Datasource 연동 설정

이제 데이터소스가 평문 비밀번호 대신 위에서 만든 Security Domain을 바라보도록 수정합니다.

수정 전 (Before)

<datasource ...>
    ...
    <security>
        <user-name>sa</user-name>
        <password>admin1234</password>
    </security>
</datasource>

수정 후 (After)

user-name과 password 태그를 삭제하고 security-domain 태그를 추가합니다.

<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
    <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
    <driver>h2</driver>
    
    <security>
        <security-domain>encryptedSecurityDB</security-domain>
    </security>
</datasource>

4. 검증 (Verification)

1. 설정 저장 후 JBoss 서버를 재기동(Reload)합니다.
2. 관리 콘솔 또는 CLI에서 Test Connection을 수행하여 연결 성공 여부를 확인합니다.
3. 연결 성공 시, 설정 파일에 비밀번호 평문이 남아있지 않은지 재확인합니다.

Next Step:
만약 비밀번호 뿐만 아니라 키스토어 패스워드 등 JBoss 설정 전반의 민감 정보를 보호해야 한다면, Vault(볼트) 구성을 추가로 검토해 보십시오.

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가 요청을 인식하지 못할 수 있습니다.

관리 콘솔 설정

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

4. 검증 및 재기동

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

Syntax Check

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

# 결과가 'Syntax OK'여야 함

Server Restart

./apachectl restart

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