[WebSphere] 실제 IP(Real IP) 인식 불가 해결: trustedHeaderOrigin 설정 가이드 (CVE-2012-5783 대응)

WebSphere Application Server(WAS)의 trustedHeaderOrigin 설정이 개선되었습니다. 기존에는 정확한 IP만 입력해야 했으나, 최신 픽스팩(9.0.5.7, 8.5.5.20)부터는 192.168.*.*와 같은 IP 세그먼트 와일드카드를 지원합니다. 유동 IP 환경에서의 설정법과 적용 버전을 정리합니다.

1. 업데이트 배경: IP 관리가 너무 힘들다?

기존에는 보안(CVE-2012-5783) 이슈로 인해 trustedHeaderOrigin에 앞단 웹 서버의 정확한 IP(Full IP)를 일일이 등록해야 했습니다.

하지만 클라우드(AWS, Azure)나 컨테이너(Docker/K8s) 환경에서는 L4/Web 서버의 IP가 수시로 변경되거나 대역으로 할당되므로, 모든 IP를 나열하는 것이 불가능했습니다. 이를 해결하기 위해 부분 와일드카드(IP Wildcard Segments) 지원이 추가되었습니다.

---

2. 와일드카드 지원 버전 (Target Fixpacks)

아래 버전 이상의 픽스팩(Fix Pack)이 적용된 환경에서는 IP 대역 설정이 가능합니다.

제품군	지원 시작 버전 (Minimum Version)
WAS 9.0	9.0.5.7 이상
WAS 8.5	8.5.5.20 이상
Liberty	21.0.0.2 이상

참고: 위 버전보다 낮은 경우 192.168.*.* 같은 입력을 인식하지 못하고 에러가 발생하거나 IP 인식이 실패할 수 있습니다.

---

3. 설정 가이드 (Configuration)

WAS 관리 콘솔에서 전송 채널의 사용자 정의 속성을 추가합니다.

설정 경로

1. Servers > [서버명] > Web Container Settings > Web container transport chains
2. 대상 체인 선택 (예: WCInboundDefault)
3. HTTP Inbound Channel (HTTP_2) > Custom properties > New

속성 값 입력 예시 (New Feature)

이제 아래와 같이 유연한 설정이 가능합니다.

속성 이름 (Name)	값 (Value) 예시	설명
trustedHeaderOrigin trustedSensitiveHeaderOrigin	10.10.*.*	10.10.0.0/16 대역의 모든 IP 신뢰 (추천)
	192.168.1.*, 10.1.*.*	콤마(,)를 사용하여 여러 대역 동시 지정
	*.ibm.com	호스트네임 기반의 와일드카드 지원

Best Practice:
과거에는 편의상 * (전체 허용)를 사용하는 경우가 많았으나, 이는 보안상 취약합니다.
이제는 10.10.*.* 처럼 내부망 IP 대역만 특정하여 허용함으로써 보안과 편의성을 모두 챙길 수 있습니다.

---

4. 웹 컨테이너 포트 인식 설정 (함께 적용)

IP 대역 설정과 함께, 호스트 헤더의 포트 정보를 올바르게 가져오기 위한 웹 컨테이너 설정도 잊지 마세요.

• 위치: Web Container > Custom properties
• 속성: com.ibm.ws.webcontainer.extractHostHeaderPort = true

---

5. 검증 (Verification)

1. 설정 저장 후 WAS 재기동
2. SystemOut.log에 별다른 에러 메시지가 없는지 확인
3. 애플리케이션에서 request.getRemoteAddr() 호출 시 실제 클라이언트 IP가 출력되는지 확인

[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 속성은 상황에 따라 검토가 필요할 수 있습니다.)

[WebSphere Liberty] DB 연결 총정리: Oracle, DB2, MySQL, Tibero 데이터소스 설정 및 연결 테스트

IBM WebSphere Liberty에서 주요 데이터베이스(Oracle, DB2, MySQL, Tibero)와 연결하기 위한 JDBC 데이터소스 설정 방법을 정리합니다. adminCenter를 활용한 관리 환경 구성, 비밀번호 암호화, 그리고 restConnector를 이용한 연결 테스트까지의 전체 과정을 다룹니다.

0. 전제 조건 (Prerequisites)

• Version: Liberty 25.x 이상 권장
• Java: Java 8 (OpenJ9) 기준
• 필수 기능(Feature): server.xml에 아래 피처들이 등록되어 있어야 합니다.

<featureManager>
    <feature>jdbc-4.3</feature>              <!-- JDBC 표준 지원 -->
    <feature>transportSecurity-1.0</feature> <!-- 암호화 비밀번호 사용 시 -->
    <feature>restConnector-2.0</feature>     <!-- 연결 테스트 API용 -->
    <feature>adminCenter-1.0</feature>       <!-- 관리 UI 및 통합 관리 -->
</featureManager>

---

1. JDBC 드라이버 준비 (Driver Setup)

각 DB 벤더에 맞는 JDBC 드라이버(JAR 파일)를 준비하여 Liberty 공용 리소스 디렉토리에 배치합니다.

DB	파일명 (예시)	다운로드 출처
Oracle	ojdbc8.jar	Oracle MOS 또는 Maven
DB2	db2jcc4.jar	DB 서버의 /sqllib/java
MySQL	mysql-connector-j-8.x.jar	Maven Central
Tibero	tibero6-jdbc.jar	TmaxSoft 테크넷

디렉토리 생성 및 복사

관리 편의성을 위해 ${shared.resource.dir}(기본값: usr/shared/resources) 하위에 벤더별 폴더를 만들어 관리하는 것을 추천합니다.

# Oracle 예시
mkdir -p $WLP_HOME/usr/shared/resources/jdbc/oracle
cp ojdbc8.jar $WLP_HOME/usr/shared/resources/jdbc/oracle/

---

2. 공통 라이브러리 정의 (Library)

server.xml에서 위에서 배치한 JAR 파일을 참조하는 library 태그를 작성합니다.

<!-- Oracle 라이브러리 정의 -->
<library id="OracleLib">
    <fileset dir="${shared.resource.dir}/jdbc/oracle" includes="ojdbc*.jar"/>
</library>

---

3. 데이터소스 정의 (DataSource Configuration)

DB별로 설정 태그(properties)와 클래스명이 다르므로 주의해야 합니다.

Case A: Oracle Database

<dataSource id="OracleDS" jndiName="jdbc/oracleDS" statementCacheSize="60">
    <jdbcDriver libraryRef="OracleLib"
                javax.sql.ConnectionPoolDataSource="oracle.jdbc.pool.OracleConnectionPoolDataSource"/>
    <!-- URL 방식 연결 -->
    <properties.oracle URL="jdbc:oracle:thin:@//192.168.0.101:1521/ORCL"
                       user="scott" password="{aes}..." />
    <connectionManager maxPoolSize="50" connectionTimeout="6s"
                       reapTime="300" maxIdleTime="1800"/>
</dataSource>

Case B: IBM DB2

<dataSource id="DB2DS" jndiName="jdbc/db2" isolationLevel="TRANSACTION_READ_COMMITTED">
    <jdbcDriver libraryRef="DB2Lib"
                javax.sql.ConnectionPoolDataSource="com.ibm.db2.jcc.DB2ConnectionPoolDataSource"/>
    <properties.db2.jcc databaseName="SAMPLE" serverName="localhost" portNumber="50000"
                        user="db2inst1" password="{aes}..." />
</dataSource>

Case C: Tibero (Tmax)

국산 DB인 Tibero는 properties 태그가 별도로 없으므로 일반적인 속성 주입 방식을 사용하거나, Tibero 전용 프로퍼티를 명시해야 할 수 있습니다.

<dataSource id="TiberoDS" jndiName="jdbc/tibero" statementCacheSize="100">
    <jdbcDriver libraryRef="TiberoLib"
                javax.sql.ConnectionPoolDataSource="com.tmax.tibero.jdbc.ext.TbConnectionPoolDataSource"/>
    <!-- properties.tibero 태그 사용 -->
    <properties.tibero url="jdbc:tibero:thin:@192.168.0.111:8629:tibero"
                       user="admin" password="{aes}..." />
</dataSource>

---

4. 비밀번호 암호화 (Security)

설정 파일에 비밀번호를 평문으로 저장하는 것은 보안상 위험합니다. securityUtility를 이용해 AES로 암호화합니다.

암호화 실행

# 암호화 키 지정 (예: passw0rd)
$WLP_HOME/bin/securityUtility encode --encoding=aes --key=passw0rd 'DB_REAL_PASSWORD'
# 결과: {aes}AA6wcy4K2Xm...

키 등록 (bootstrap.properties)

서버가 암호를 복호화할 수 있도록 키를 등록해줍니다.

wlp.password.encryption.key=passw0rd

---

5. 연결 테스트 및 검증 (Validation)

서버를 기동한 후, REST API를 통해 데이터소스 연결 상태를 체크할 수 있습니다.

필수 확인 (Check Point):
해당 API를 호출하거나 웹 관리 콘솔(Admin Center)을 이용하기 위해서는 adminCenter-1.0 및 restConnector-2.0 피처가 반드시 활성화되어 있어야 하며, 접근하는 계정에 관리자(Administrator) 권한이 있어야 합니다.

연결 테스트 명령어 (curl)

# 관리자 계정(admin)으로 인증 후 테스트 API 호출
curl -k -u admin:passw0rd \
  https://localhost:9443/ibm/api/validation/dataSource/OracleDS

성공 시: 200 OK와 함께 JSON 응답 내에 "Valid" 메시지가 포함됩니다.
실패 시: messages.log 파일에서 CWLLG2010E(로드 실패), CWNEN0034E(연결 실패) 등의 에러 코드를 확인합니다.

---

6. 트러블슈팅 체크리스트

• ClassNotFoundException: library 경로 오타 또는 JAR 파일 권한(755) 확인
• Connection Timeout: DB 방화벽(Port) 오픈 여부 확인
• Authentication Failed: bootstrap.properties에 암호화 키가 올바르게 등록되었는지 확인

[WebSphere Liberty] 설정 유연화의 핵심: 변수(Variable) 활용법 및 우선순위 완벽 정리

WebSphere Liberty의 설정 파일(server.xml)에서 포트 번호, DB 접속 정보 등을 하드코딩하지 않고 변수(Variable)로 관리하는 방법을 정리합니다. bootstrap.properties와 server.xml, 환경 변수 간의 우선순위 규칙과 JDBC URL 설정 시 발생하는 슬래시(/) 정규화 문제를 해결하는 팁을 다룹니다.

0. 변수를 왜 사용해야 하나요?

서버 설정을 변수화하면 하나의 server.xml 파일을 여러 서버 인스턴스나 환경(Dev/Test/Prod)에서 공유할 수 있습니다. 변경되는 값(포트, IP 등)만 별도로 분리하여 관리 효율성을 높일 수 있습니다.

---

1. 변수 정의 위치 및 우선순위 (Precedence)

Liberty에서 변수를 정의할 수 있는 곳은 크게 세 군데입니다. 만약 같은 이름의 변수가 여러 곳에 정의되어 있다면, 아래 순서대로 덮어씌워집니다. (아래쪽이 우선순위 높음)

1. 프로세스 환경 변수 (OS Environment Variables): 가장 낮은 우선순위
2. bootstrap.properties: 환경 변수를 덮어씀
3. server.xml (또는 include 된 xml): 가장 높은 우선순위 (최종 승자)

Best Practice:
서버별로 달라지는 고유 설정(예: HTTP 포트)은 bootstrap.properties에 정의하고, 여러 서버가 공유하는 공통 설정(예: DB 설정)은 included xml 파일에 정의하는 것이 좋습니다.

---

2. 변수 사용 방법 (Usage Guide)

Case A: bootstrap.properties 활용

서버 인스턴스 생성 시 자동으로 만들어지는 파일로, key=value 형태로 간단하게 정의합니다.

# bootstrap.properties
# 포트 번호 정의
http.port=8080
https.port=9443

Case B: server.xml 활용

<variable> 태그를 사용하여 정의하거나, 정의된 변수를 ${...} 문법으로 사용합니다.

<!-- 변수 정의 (Global) -->
<variable name="http.port" value="8080" />

<!-- 변수 사용 -->
<httpEndpoint id="defaultHttpEndpoint"
              httpPort="${http.port}"
              httpsPort="${https.port}" />

Case C: 환경 변수(Environment Variable) 활용

OS 환경 변수를 가져올 때는 env. 접두사를 사용합니다.

<!-- OS의 LIBRARY_DIR 환경 변수 사용 -->
<fileset dir="${env.LIBRARY_DIR}" includes="*.jar"/>

---

3. 고급 활용 팁 (Advanced Tips)

1) JDBC URL 슬래시(/) 정규화 문제 해결

Liberty 설정 파서(Parser)는 변수 값에 포함된 연속된 슬래시(//)를 단일 슬래시(/)로 정규화하는 특성이 있습니다. 이 때문에 JDBC URL 등이 깨질 수 있습니다.

해결책: 값을 두 부분으로 나누어 정의하거나, 이중 슬래시로 시작하게 합니다.

# [Bad] 이렇게 하면 jdbc:db2:/host.com 으로 변환되어 에러 발생
# DB_URL="jdbc:db2://host.com"

# [Good] 두 부분으로 나누어 결합
URL_PART_1="jdbc:db2:"
URL_PART_2="//host.com"

<dataSource ...>
    <properties.db2.jcc url="${URL_PART_1}${URL_PART_2}" />
</dataSource>

2) 리스트(List) 변수 처리

콤마(,)로 구분된 값을 단순 문자열이 아닌 리스트로 인식시키려면 ${list(...)} 함수를 사용합니다.

<variable name="ports" value="80,9080"/>

<!-- 문자열 "80, 9080"으로 인식 -->
<myConfig value="${ports}" /> 

<!-- 리스트 ["80", "9080"]으로 인식 -->
<myConfig value="${list(ports)}" />

3) 산술 연산 (Arithmetic)

포트 오프셋 등을 설정할 때 간단한 사칙연산(+, -, *, /)이 가능합니다.

<!-- 기본 포트(8080)에 1을 더해 8081로 설정 -->
<httpEndpoint id="secondaryEndpoint" httpPort="${http.port+1}" />

---

4. 변수 명명 규칙 (Naming Convention)

변수 이름은 반드시 알파벳(문자)으로 시작해야 하며, 아래 문자들만 포함할 수 있습니다.

• 알파벳 문자 (Alphabetic characters)
• 숫자 (Numeric characters)
• 언더스코어 (_)
• 점 (.)

---

Next Step:
이제 server.xml에서 하드코딩된 값을 제거하고 bootstrap.properties로 옮겨보십시오. 이를 통해 Docker 이미지 빌드나 여러 환경 배포 시 설정 관리가 훨씬 수월해질 것입니다.

[WebSphere] Liberty Performance Tuning: 주요 구성 매개변수 가이드

Summary: WebSphere Liberty(Open Liberty) 환경에서 성능 최적화를 위해 조정 가능한 주요 매개변수를 정리한 문서입니다. JVM 힙 설정부터 Connection Pool, Executor, 그리고 유휴 자원 관리까지 server.xml 및 jvm.options를 통한 튜닝 포인트를 다룹니다.

WebSphere Liberty는 기본적으로 자가 튜닝(Self-tuning) 기능을 갖추고 있으나, 운영 환경의 특성이나 애플리케이션의 워크로드 패턴에 따라 명시적인 설정 변경이 필요할 수 있습니다. 본 문서는 IBM Documentation을 기반으로 성능에 직접적인 영향을 주는 핵심 속성들을 정리했습니다.

1. JVM Tuning

가장 기본적이며 중요한 단계입니다. ${server.config.dir}/jvm.options 파일을 사용하여 설정합니다.

• 개발 환경: 빠른 서버 시작을 위해 최소 힙(Min Heap)은 작게, 최대 힙(Max Heap)은 필요한 만큼 설정.
• 운영 환경: 런타임 중 힙 크기 조정(Expansion/Contraction)에 따른 오버헤드를 제거하기 위해 최소 힙과 최대 힙을 동일한 값으로 설정하는 것을 권장합니다.

2. Transport Channel Service Tuning

클라이언트 연결, HTTP I/O 처리, 스레드 풀 및 연결 풀 관리를 담당하는 영역입니다. server.xml에서 설정합니다.

HTTP Options

SSL 핸드셰이크 비용이 높거나 처리량이 중요한 애플리케이션의 경우 지속적 연결(Persistent Connection) 설정을 최적화해야 합니다.

• maxKeepAliveRequests: 단일 HTTP 연결에서 허용되는 최대 요청 수입니다. -1로 설정 시 무제한을 의미하며, 연결 맺는 비용을 절감할 수 있습니다.

<httpOptions maxKeepAliveRequests="-1" />

Connection Manager

데이터베이스 연결 풀(Connection Pool) 성능을 결정짓는 핵심 속성입니다.

• maxPoolSize: 최대 실제 연결 수 (Default: 50). 모든 스레드가 DB 연결을 필요로 한다면 coreThreads와 1:1 매핑을 고려하십시오.
• purgePolicy: Stale Connection 발견 시 처리 정책. 기본값은 EntirePool이나, FailingConnectionOnly로 설정하여 실패한 연결만 제거하는 것이 효율적입니다.
• numConnectionsPerThreadLocal: 실행 스레드별로 DB 연결을 캐싱하여 락 경합(Contention)을 줄입니다. 멀티 코어 시스템에서 성능 향상에 유리합니다.

<connectionManager id="defaultConnectionManager" 
                   maxPoolSize="40" 
                   purgePolicy="FailingConnectionOnly" 
                   numConnectionsPerThreadLocal="1" />

Note: numConnectionsPerThreadLocal 사용 시, maxPoolSize는 (애플리케이션 스레드 수 × 스레드당 연결 수) 이상으로 설정해야 합니다.

3. Data Source Optimization

DB 쿼리 성능 및 데이터 무결성 수준을 조정합니다.

Statement Cache

PreparedStatement 캐싱을 통해 파싱 비용을 줄입니다. 애플리케이션에서 사용하는 고유한 SQL 문장 수보다 크게 설정해야 합니다.

<dataSource ... statementCacheSize="60" > ... </dataSource>

Isolation Level

데이터 무결성과 동시성(Concurrency)은 트레이드오프 관계입니다. isolationLevel 속성으로 조정합니다.

• TRANSACTION_READ_UNCOMMITTED: 성능 최상, 무결성 최저 (Dirty Read 발생).
• TRANSACTION_READ_COMMITTED: Dirty Read 방지.
• TRANSACTION_REPEATABLE_READ: Dirty/Non-repeatable Read 방지.
• TRANSACTION_SERIALIZABLE: 성능 최저, 무결성 최상 (완전한 직렬화).

4. Executor (Thread Pool) Tuning

Liberty의 Executor는 워크로드에 따라 스레드를 동적으로 조절하는 자가 튜닝 로직을 가지고 있습니다.

• 기본 원칙: 특별한 문제가 없다면 설정을 변경하지 않는 것이 권장됩니다.
• 예외 상황: 교착 상태(Deadlock) 해결 로직이 과도하게 작동하거나, 시스템 자원 한계로 스레드 수를 제한해야 할 경우 coreThreads 및 maxThreads를 명시합니다.

5. Reducing Overhead & Startup Time

불필요한 CPU 사이클을 줄이고 기동 시간을 단축하기 위한 설정입니다.

Servlet Response Time

WebContainer가 정적 리소스 처리를 위해 META-INF 디렉토리를 스캔하는 과정을 생략합니다.

<webContainer skipMetaInfResourcesProcessing="true"/>

Idle Server CPU

운영 환경에서는 빈번한 애플리케이션/구성 파일 변경 감지가 불필요하므로, 모니터링 주기를 비활성화하거나 늘립니다.

<!-- 아예 비활성화 (권장) -->
<applicationMonitor dropinsEnabled="false" updateTrigger="disabled"/>
<config updateTrigger="disabled"/>

<!-- 혹은 MBean 트리거로 변경 및 폴링 주기 완화 -->
<applicationMonitor updateTrigger="mbean" pollingRate="60s"/>
<config updateTrigger="mbean" monitorInterval="60s"/>

CDI 1.2 Scanning

CDI 1.2 기능은 기본적으로 모든 아카이브를 스캔합니다. 대규모 애플리케이션에서 기동 속도 저하의 주원인이 되므로, 암시적 스캔(Implicit Bean Archives)을 비활성화합니다.

<cdi12 enableImplicitBeanArchives="false"/>

---

Next Step: 위 설정들은 워크로드의 특성에 따라 효과가 다릅니다. 운영 환경 적용 전, 부하 테스트를 통해 각 파라미터 변경에 따른 처리량(Throughput)과 응답 시간 변화를 측정하시기 바랍니다.

Read Log →

[WebSphere] Liberty Cluster: End-to-End 구축 및 구성 가이드

Summary: WebSphere Liberty Profile(WLP)의 Collective 및 Cluster 기능을 활용한 인프라 구축 가이드입니다. Controller 구성부터 Member 조인, 클러스터링 설정 및 트러블슈팅까지의 전체 과정을 다룹니다.

WebSphere Application Server Liberty Profile(WLP)은 경량화된 구조와 확장성 덕분에 채택률이 높아지고 있습니다. 본 포스트는 WLP Collective와 Clustering 기능을 사용하여 확장 가능한 토폴로지를 구축하는 방법을 단계별로 정리한 엔지니어링 노트입니다.

이 시리즈는 다음 순서로 진행됩니다.

• How to Create and Configure WebSphere Liberty Cluster End-to-End (Current)
• How to Deploy Application in WebSphere Liberty Cluster
• How to Setup Front-End Web Server for WebSphere Liberty Cluster

1. Topology Architecture

이 가이드에서는 Collective Controller 1대와 Collective/Cluster Member 2대로 구성된 토폴로지를 구현합니다. 프론트엔드에는 IBM HTTP Server(IHS)가 배치되며 별도의 배포 서버가 존재하는 구조입니다.

2. Prerequisites & WLP Installation

본 가이드는 WLP 17.0.2 및 CentOS Linux 7.3 환경을 기준으로 작성되었습니다. 설치 전 지원되는 Java 버전이 설치되어 있는지 확인이 필요합니다.

Check System Environment

$> cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

$> ./java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr4fp5-20170421_01(SR4 FP5))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170419_344392)

Base Installation (Machine: 02)

먼저 Controller가 될 머신(Machine: 02)에 WLP를 설치하고 필요한 기능을 추가한 뒤, 이를 패키징하여 Member 서버들(Machine: 03, 04)로 배포하는 전략을 사용합니다.

# Create directory
$> sudo mkdir -p /opt/ibm

# Change ownership
$> sudo chown -R wasadmin:wasgrp /opt/ibm

# Install WLP
$> java -jar wlp-17.0.0.2-all.jar --acceptLicense /opt/ibm

# Verify version
$> cd /opt/ibm/wlp/bin
$> ./productInfo version
Product name: WebSphere Application Server
Product version: 17.0.0.2

Install Required Features

Collective, Cluster, SSL, JMX Connector 등의 필수 기능을 설치합니다.

$> ./installUtility install collectiveController-1.0 collectiveMember-1.0 clusterMember-1.0 websocket-1.1 restConnector-2.0 ssl-1.0 localConnector-1.0 adminCenter-1.0

Package and Distribute

설치된 환경을 wlp_install.jar로 패키징하여 다른 노드에 복제합니다.

# Create defaultServer for packaging context
$> ./server create

# Package server including all binaries
$> ./server package defaultServer --archive=/tmp/wlp_install.jar --include=all
Server defaultServer package complete in /tmp/wlp_install.jar.

생성된 wlp_install.jar를 Machine 03, 04로 전송한 후 동일하게 설치를 진행합니다.

# On Machine 03 & 04
$> sudo mkdir -p /opt/ibm
$> chown -R wasadmin:wasgrp /opt/ibm
$> java -jar wlp_install.jar --acceptLicense /opt/ibm

3. Setup Collective Controller (Machine: 02)

Controller 서버(wlpCntlr)를 생성하고 구성을 초기화합니다.

# Create server
$> ./server create wlpCntlr

# Initialize Collective Controller
$> ./collective create wlpCntlr --keystorePassword=<password> --createConfigFile=/opt/ibm/wlp/usr/servers/wlpCntlr/wlpcntlr_include.xml

위 명령어를 수행하면 인증서 생성 및 wlpcntlr_include.xml 설정 파일이 생성됩니다. 이후 server.xml과 include 파일을 다음과 같이 수정합니다.

Configuration: server.xml (Controller)

<server description="CollectiveController">
    <featureManager>
        <feature>adminCenter-1.0</feature>
        <feature>websocket-1.1</feature>
        <feature>restConnector-1.0</feature>
        <feature>localConnector-1.0</feature>
    </featureManager>

    <!-- Include generated config -->
    <include location="${server.config.dir}/wlpcntlr_include.xml" />

    <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" host="*" />
</server>

Configuration: wlpcntlr_include.xml

자동 생성된 파일에서 quickStartSecurity 부분을 본인의 계정 정보로 수정합니다.

<quickStartSecurity userName="wasadmin" userPassword="{xor}EncryptedPassword..." />

Firewall Configuration

CentOS 방화벽에서 9080, 9443 포트를 허용해야 합니다.

$> sudo firewall-cmd --zone=public --permanent --add-port=9443/tcp
$> sudo firewall-cmd --zone=public --permanent --add-port=9080/tcp
$> sudo firewall-cmd --reload

Start Controller

$> ./server start wlpCntlr

로그(messages.log)에서 CWWKX6011I: The collective controller is ready 메시지를 확인합니다. Admin Center(https://hostname:9443/adminCenter/) 접속도 가능해야 합니다.

4. Setup Collective & Cluster Members

Machine 03과 04에서 멤버 서버를 생성하고 Controller에 Join 시킵니다.

Create & Join Member (Machine: 03)

# Create Server
$> ./server create wlpSrv01

# Join Collective
$> ./collective join wlpSrv01 \
  --host=waslibctlr01 \
  --port=9443 \
  --user=wasadmin \
  --password=<password> \
  --keystorePassword=<password> \
  --createConfigFile=/opt/ibm/wlp/usr/servers/wlpSrv01/wlpsrv01_include.xml

SSL Handshake 과정에서 인증서를 신뢰하겠냐는 프롬프트에 y를 입력합니다.

Configuration: server.xml (Member)

Member 서버의 server.xml에 Cluster 기능을 추가하고, Controller가 배포 관리를 할 수 있도록 remoteFileAccess를 설정합니다.

<server description="Cluster Member">
    <featureManager>
        <feature>webProfile-7.0</feature>
        <feature>restConnector-1.0</feature>
        <feature>localConnector-1.0</feature>
        <!-- Added for Clustering -->
        <feature>clusterMember-1.0</feature>
    </featureManager>

    <include location="${server.config.dir}/wlpsrv01_include.xml" />

    <!-- Define Cluster Name -->
    <clusterMember name="wlpCluster"/>

    <httpEndpoint id="defaultHttpEndpoint" httpPort="9081" httpsPort="9444" host="*" />

    <!-- Write Access for Controller -->
    <remoteFileAccess>
        <writeDir>${server.config.dir}</writeDir>
    </remoteFileAccess>
</server>

Machine: 04 (wlpSrv02)에 대해서도 위 과정을 동일하게 반복합니다.

Security Considerations (LTPA)

클러스터 환경에서 세션 공유 및 보안을 위해 모든 멤버는 동일한 LTPA 키를 사용해야 합니다. 한 서버에서 생성된 ltpa.keys 파일을 다른 멤버 서버들의 동일한 경로(${server.ouput.dir}/resources/security/)로 복사합니다.

5. Start Members & Verification

각 노드에서 멤버 서버를 시작합니다.

$> ./server start wlpSrv01  # On Machine 03
$> ./server start wlpSrv02  # On Machine 04

로그 파일에서 다음 메시지들을 확인하여 정상 구동을 검증합니다.

• CWWKX8112I: Collective Repository에 호스트 정보 게시 성공.
• CWWKX7400I: ClusterMember MBean 활성화 (클러스터 조인 성공).

6. Troubleshooting Notes

설정 과정에서 자주 발생하는 오류와 해결 방법입니다.

• CWWKX0229E (401 Unauthorized / 403 Forbidden)
  collective join 시 인증 실패. quickStartSecurity의 계정 정보가 일치하는지 확인하십시오. 403 에러의 경우 해당 사용자가 administrator-role을 가지고 있는지 확인해야 합니다.
• CWWKS9582E (SSL unresolved)
  IIOP 보안 설정 시 SSL 참조 오류. server.xml에 SSL 구성 및 KeyStore 정의가 명확한지 확인하십시오.
• CWWKO0221E / CWWKS9580E (Port in use)
  한 호스트에 여러 인스턴스를 띄울 경우 JMS 포트(7276)나 IIOP 포트(2809) 충돌이 발생할 수 있습니다. wasJmsEndpoint 및 iiopEndpoint 설정을 통해 포트를 변경해야 합니다.

---

Next Step: 클러스터 구성이 완료되었습니다. 다음 포스트에서는 이 클러스터에 애플리케이션을 배포하는 방법을 다룹니다.

[Tomcat] 주요 설정 파일(server.xml, web.xml) 완벽 분석 및 필수 튜닝 포인트

Apache Tomcat의 동작을 제어하는 핵심 설정 파일들은 모두 /conf 디렉토리에 위치합니다. 가장 중요한 server.xml(포트, 커넥터)과 web.xml(세션, MIME)의 역할과 자주 사용하는 설정 변경 가이드를 정리합니다.

1. 설정 파일 개요 (Configuration Overview)

Tomcat 설치 경로 내 conf 디렉토리에는 다음과 같은 주요 XML 파일들이 존재합니다.

파일명	주요 역할 및 설명
server.xml	Tomcat의 메인 설정 파일입니다. - HTTP/AJP 포트 설정 - 가상 호스트(Host) 및 Context 설정 - 쓰레드 풀(Thread Pool) 관리
web.xml	모든 웹 애플리케이션의 기본 속성을 정의합니다. - 세션 타임아웃(Session Timeout) 설정 - MIME 타입 정의, 기본 서블릿 매핑
context.xml	웹 애플리케이션의 Context 설정을 담당합니다. - JNDI 리소스(DB Connection Pool) 설정 시 주로 사용
tomcat-users.xml	Tomcat Manager/Admin 페이지 접근 계정을 관리합니다.

---

2. server.xml 주요 설정 가이드

엔지니어가 가장 빈번하게 수정하는 파일입니다. 포트 충돌 해결이나 인코딩 처리를 위해 필수적으로 확인해야 합니다.

1) HTTP 포트 변경 및 인코딩 설정

기본 8080 포트를 80으로 변경하거나, 한글 깨짐 방지를 위해 URIEncoding을 설정합니다.

<!-- 기본 설정 -->
<Connector port="8080" protocol="HTTP/1.1" 
           connectionTimeout="20000" 
           redirectPort="8443" />

<!-- 튜닝 설정 예시 -->
<Connector port="80" protocol="HTTP/1.1" 
           connectionTimeout="20000" 
           redirectPort="8443"
           URIEncoding="UTF-8" />

Tip: GET 방식으로 넘어오는 파라미터의 한글이 깨진다면 URIEncoding="UTF-8" 속성이 누락되었을 가능성이 큽니다.

2) AJP 포트 설정 (웹 서버 연동 시)

Apache HTTP Server와 연동할 때 사용하는 AJP 프로토콜 포트입니다. 사용하지 않는다면 주석 처리하여 보안을 강화하는 것이 좋습니다.

<!-- 기본값 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

---

3. web.xml 주요 설정 가이드

모든 애플리케이션에 적용되는 전역(Global) 설정을 담당합니다.

1) 세션 타임아웃 (Session Timeout)

사용자 세션 만료 시간을 설정합니다. (단위: 분)

<session-config>
    <session-timeout>30</session-timeout>
</session-config>

2) 디렉토리 리스팅 비활성화 (보안)

특정 디렉토리 접근 시 파일 목록이 노출되는 것을 방지하기 위해 listings 값을 false로 설정해야 합니다.

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>0</param-value>
    </init-param>
    <init-param>
        <param-name>listings</param-name>
        <param-value>false</param-value> <!-- true면 파일 목록 노출됨 -->
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

---

4. tomcat-users.xml (Manager App)

http://localhost:8080/manager 페이지에 접속하여 GUI로 애플리케이션을 배포하거나 중지하려면 계정 설정이 필요합니다.

<tomcat-users>
  <!-- 역할 정의 -->
  <role rolename="manager-gui"/>
  <role rolename="admin-gui"/>
  
  <!-- 사용자 정의 -->
  <user username="admin" password="password" roles="manager-gui,admin-gui"/>
</tomcat-users>

주의: Manager App은 강력한 권한을 가지므로, 운영 환경에서는 외부 IP 접근을 차단하거나 해당 기능을 비활성화하는 것을 권장합니다.

---

Next Step:
설정 파일 수정 후에는 반드시 Tomcat을 재기동해야 적용됩니다. 다음 단계에서는 실제 운영 환경에서 성능을 최적화하기 위한 JVM 메모리 설정(Heap Size)과 GC 튜닝 방법에 대해 알아보겠습니다.

[IHS/Liberty] 보안 취약점 조치: X-Powered-By 헤더 숨김 및 정보 노출 방지 가이드

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

0. 배경 및 전략 (Context)

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

계층	역할 및 중요성
1. IHS (Web Server)	[필수] 최전방 방어선. 백엔드 WAS가 무엇이든 상관없이 클라이언트로 나가는 모든 응답에서 헤더를 강제 삭제합니다.
2. Liberty (WAS)	[권장] 소스 차단. 내부망에서 WAS로 직접 접속하는 경우나 웹 서버 설정을 우회하는 경우를 대비해 헤더 생성 자체를 막습니다.

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

Tip: 설정 후에는 반드시 ./apachectl -t로 문법을 검사하고 재기동(restart 또는 graceful)해야 합니다.

---

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/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 명령어로 문법 오류가 없는지 확인하고 재기동해야 합니다.

[Node.js] Windows npm 실행 오류 해결: PowerShell 보안 정책(PSSecurityException) 설정 가이드

Windows 환경에서 npm 명령어를 실행할 때 발생하는 "이 시스템에서 스크립트를 실행할 수 없으므로..."(PSSecurityException) 오류를 해결합니다. PowerShell의 실행 정책(Execution Policy)을 이해하고, 보안을 유지하면서 npm을 사용할 수 있도록 RemoteSigned 정책을 적용하는 방법을 정리합니다.

1. 문제 현상 (Issue)

Node.js 설치 후 터미널(VS Code 또는 PowerShell)에서 npm 명령어를 실행하면 다음과 같은 빨간색 에러 메시지가 출력되며 실행이 차단됩니다.

에러 메시지

npm : 이 시스템에서 스크립트를 실행할 수 없으므로 C:\Program Files\nodejs\npm.ps1 파일을 로드할 수 없습니다.
위치 줄:1 문자:1
+ npm install
+ ~~~
    + CategoryInfo          : 보안 오류: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

---

2. 원인 분석 (Root Cause)

이것은 npm의 문제가 아니라 Windows PowerShell의 보안 정책 때문입니다.

• Restricted (기본값): Windows 클라이언트 OS의 기본 정책으로, 모든 스크립트 파일(.ps1)의 실행을 차단합니다.
• npm 명령어는 내부적으로 npm.ps1 스크립트를 실행하려다 이 정책에 막히게 됩니다.

---

3. 해결 방법 (Solution)

보안 정책을 변경하여 스크립트 실행을 허용해야 합니다. 보안과 편의성의 균형을 위해 RemoteSigned 정책을 현재 사용자(CurrentUser)에게만 적용하는 것을 권장합니다.

Step 1: 현재 정책 확인

PowerShell을 실행하고 아래 명령어를 입력합니다.

Get-ExecutionPolicy

결과가 Restricted로 나온다면 실행이 불가능한 상태입니다.

Step 2: 정책 변경 (권장 설정)

PowerShell을 관리자 권한으로 실행한 뒤, 아래 명령어를 입력합니다.

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

정책 설명:

• RemoteSigned: 로컬에서 생성한 스크립트는 실행 허용, 인터넷에서 다운로드한 스크립트는 서명된 것만 허용 (가장 권장되는 설정).
• -Scope CurrentUser: 시스템 전체가 아닌 현재 로그인한 사용자에게만 적용하여 보안 리스크 최소화.

변경 확인 메시지가 나오면 Y (예)를 입력하여 승인합니다.

---

4. 대안 및 팁 (Alternatives)

방법 A: 일회성 허용 (임시)

정책을 영구적으로 바꾸기 부담스럽다면, 현재 열려있는 창에서만 허용할 수 있습니다.

Set-ExecutionPolicy RemoteSigned -Scope Process

방법 B: Command Prompt (cmd) 사용

PowerShell이 아닌 일반 명령 프롬프트(cmd)나 Git Bash에서는 해당 보안 정책의 영향을 받지 않으므로, 별도 설정 없이 npm을 사용할 수 있습니다.

---

5. 검증 (Verification)

설정 후 다시 버전을 확인하거나 명령어를 실행하여 에러가 사라졌는지 확인합니다.

npm --version

---

Next Step:
이제 npm이 정상 작동하므로, npm install을 통해 필요한 패키지를 설치하거나 npx create-react-app 등의 프로젝트 생성 명령어를 실행해 보십시오.

[Apache] 보안 취약점 조치: 서버 버전 정보 숨기기 (ServerTokens, ServerSignature)

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 모듈을 사용해야 합니다.

Pre-check: 이 설정을 사용하려면 LoadModule headers_module modules/mod_headers.so 라인의 주석이 해제되어 있어야 합니다.

<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 등 보안 헤더 적용을 검토해 보십시오.

[JBoss EAP 7] 데이터소스 패스워드 암호화 완벽 가이드: Password Vault 구성 및 적용 (Windows/Linux)

JBoss EAP 7.x 환경에서 평문으로 저장되는 데이터소스 비밀번호를 보호하기 위해 Password Vault를 구성하는 방법을 정리합니다. Windows와 Linux 환경, 그리고 Standalone과 Domain 모드 각각에 대한 설정법을 포괄하며, KeyStore 생성부터 VAULT 문자열 적용까지의 전체 프로세스를 다룹니다.

1. 프로세스 개요 (Process Overview)

Vault 구성은 크게 4단계로 진행됩니다.

1. KeyStore 생성: 암호화 키를 저장할 물리적 파일(.keystore) 생성
2. Vault 초기화 및 암호화: 비밀번호를 암호화하고 JBoss 설정에 필요한 파라미터 생성
3. JBoss Vault 설정: 생성된 KeyStore와 JBoss를 연동 (standalone.xml 또는 host.xml)
4. 데이터소스 적용: 평문 비밀번호를 암호화된 문자열(${VAULT::...})로 교체

---

2. KeyStore 생성 (Generate KeyStore)

Java의 keytool을 사용하여 JCEKS 형식의 키스토어를 생성합니다.

Windows 환경

keytool.exe -genseckey ^
  -alias "vault" ^
  -storetype "jceks" ^
  -keyalg "AES" ^
  -keysize "128" ^
  -storepass "passw0rd" ^
  -keypass "passw0rd" ^
  -validity "7300" ^
  -keystore "D:\app\was\JBoss\vault\vault.keystore"

Linux 환경

./keytool -genseckey \
  -alias "vault" \
  -storetype "jceks" \
  -keyalg "AES" \
  -keysize "128" \
  -storepass "passw0rd" \
  -keypass "passw0rd" \
  -validity "7300" \
  -keystore "/app/was/JBoss/vault/vault.keystore"

---

3. 비밀번호 암호화 실행 (Vault Tool)

JBoss `bin` 디렉토리에 있는 vault 스크립트를 사용하여 실제 DB 패스워드를 암호화합니다.

Windows (vault.bat)

vault.bat --keystore "D:\app\was\JBoss\vault\vault.keystore" ^
  --keystore-password "passw0rd" ^
  --alias "vault" ^
  --vault-block "vb" ^
  --attribute "dbpw" ^
  --sec-attr "RealDBPassword!" ^
  --enc-dir "D:\app\was\JBoss\vault" ^
  --iteration "44" ^
  --salt "JBo72ssv"

Linux (vault.sh)

./vault.sh --keystore "/app/was/JBoss/vault/vault.keystore" \
  --keystore-password "passw0rd" \
  --alias "vault" \
  --vault-block "vb" \
  --attribute "dbpw" \
  --sec-attr "RealDBPassword!" \
  --enc-dir "/app/was/JBoss/vault" \
  --iteration "44" \
  --salt "JBo72ssv"

중요 (Result Check):
명령어 실행 결과에서 아래 두 가지 값을 반드시 기록해 두어야 합니다.
1. Vault Configuration: KEYSTORE_PASSWORD 값 (예: MASK-1234abcd...)
2. Vault Block: 실제 사용될 암호화 문자열 (예: ${VAULT::vb::dbpw::1})

---

4. JBoss Vault 구성 등록 (Configuration)

JBoss가 위에서 만든 KeyStore를 인식할 수 있도록 설정합니다. XML을 직접 수정하거나 CLI를 사용할 수 있습니다.

Standalone Mode (standalone.xml)

<vault> 섹션을 추가합니다. (일반적으로 <extensions> 뒤쪽)

<vault>
    <vault-option name="KEYSTORE_URL" value="D:\app\was\JBoss\vault\vault.keystore"/>
    <vault-option name="KEYSTORE_PASSWORD" value="MASK-xxxx"/> <!-- Vault 실행 결과값 -->
    <vault-option name="KEYSTORE_ALIAS" value="vault"/>
    <vault-option name="SALT" value="JBo72ssv"/>
    <vault-option name="ITERATION_COUNT" value="44"/>
    <vault-option name="ENC_FILE_DIR" value="D:\app\was\JBoss\vault\"/>
</vault>

Domain Mode (host.xml 권장)

도메인 모드에서는 물리적 파일 경로(KeyStore 위치)가 서버마다 다를 수 있으므로, 각 서버의 host.xml에 설정을 추가하는 것이 일반적입니다.

<!-- host.xml의 <management> 또는 <vault> 영역 -->
<vault>
    <vault-option name="KEYSTORE_URL" value="/app/was/JBoss/vault/vault.keystore"/>
    <vault-option name="KEYSTORE_PASSWORD" value="MASK-xxxx"/>
    <vault-option name="KEYSTORE_ALIAS" value="vault"/>
    <vault-option name="SALT" value="JBo72ssv"/>
    <vault-option name="ITERATION_COUNT" value="44"/>
    <vault-option name="ENC_FILE_DIR" value="/app/was/JBoss/vault/"/>
</vault>

---

5. 데이터소스 비밀번호 적용

마지막으로 데이터소스 설정 파일(standalone.xml 또는 domain.xml)에서 평문 비밀번호를 Vault 문자열로 교체합니다.

<datasource jndi-name="java:jboss/datasources/ExampleDS" ...>
    ...
    <security>
        <user-name>dbuser</user-name>
        <!-- 암호화된 문자열 적용 -->
        <password>${VAULT::vb::dbpw::1}</password>
    </security>
</datasource>

---

Next Step:
설정이 완료되었다면 JBoss를 재기동하고 관리 콘솔에서 Test Connection을 수행하여 DB 연결이 정상적으로 이루어지는지 확인하십시오.

[JBoss EAP 6] 도메인 모드 보안 강화: Vault를 이용한 Datasource 패스워드 암호화 및 무중단 적용 전략

JBoss EAP 6.4 도메인 모드(Domain Mode)에서 평문으로 저장된 데이터소스 비밀번호를 보호하기 위해 Vault를 구성하는 방법을 정리합니다. host.xml과 domain.xml의 설정 분리 원칙을 이해하고, 이중화된 환경에서 서비스 중단 없이 적용하는 순차적 배포 전략을 다룹니다.

0. 배경 및 아키텍처 (Context)

보안 감사 요건 충족을 위해 DB 패스워드 암호화는 필수입니다. 도메인 모드에서는 다음과 같은 설정 분리가 필요합니다.

• host.xml: 물리적인 Keystore 파일의 위치와 암호화 키 해독 설정 (Vault 선언)
• domain.xml: 실제 암호화된 문자열을 사용하는 데이터소스 설정 (Vault 참조)

1. Vault 환경 준비 (Keystore 생성)

암호화 키를 저장할 Java Keystore를 생성합니다. JDK의 keytool을 사용합니다.

# Keystore 생성 (알고리즘: DESede 또는 AES)
keytool -genkey -alias vault -keyalg DESede -keystore vault.keystore -keysize 168 -storepass [키스토어_비밀번호] -validity 3650

Tip: 생성된 vault.keystore 파일은 마스터(Master)와 슬레이브(Slave) 서버 모두 동일한 경로(예: EAP_HOME/vault/)에 복사해 두어야 합니다.

---

2. Vault 초기화 및 비밀번호 암호화

JBoss에서 제공하는 스크립트를 사용하여 Vault를 초기화하고, 실제 DB 패스워드를 암호화된 문자열로 변환합니다.

대화형 모드 실행 (Interactive)

$JBOSS_HOME/bin/vault.sh

위 명령 실행 후 옵션 0 (Store a secured attribute)을 선택하여 진행하거나, 아래와 같이 CLI 파라미터로 한 번에 실행할 수도 있습니다.

# CLI 파라미터 예시
$JBOSS_HOME/bin/vault.sh \
--keystore vault.keystore \
--keystore-password [키스토어_비밀번호] \
--alias vault \
--vault-block ds_vault \
--attribute db_password \
--sec-attr [실제_DB_비밀번호] \
--enc-dir /path/to/vault/ \
--iteration 120 \
--salt 1234abcd

결과 확인: 출력되는 VAULT::ds_vault::db_password::1 형태의 문자열과, 화면에 표시되는 XML 설정 블록을 복사해 둡니다.

---

3. host.xml 설정 (Vault 선언)

물리적인 파일 경로를 인식해야 하는 모든 호스트 컨트롤러(Master, Slave)의 host.xml 파일을 수정합니다.

<!-- host.xml의 <management> 섹션 내, 또는 <vault> 섹션 -->
<vault>
    <vault-option name="KEYSTORE_URL" value="/path/to/vault/vault.keystore"/>
    <vault-option name="KEYSTORE_PASSWORD" value="MASK-..."/> <!-- 마스킹된 비밀번호 -->
    <vault-option name="KEYSTORE_ALIAS" value="vault"/>
    <vault-option name="SALT" value="1234abcd"/>
    <vault-option name="ITERATION_COUNT" value="120"/>
    <vault-option name="ENC_FILE_DIR" value="/path/to/vault/" />
</vault>

---

4. domain.xml 설정 (Datasource 적용)

이제 도메인 컨트롤러의 domain.xml에서 데이터소스 비밀번호 부분을 위에서 생성한 Vault 문자열로 대체합니다.

<datasource ...>
    <security>
        <user-name>dbuser</user-name>
        <password>${VAULT::ds_vault::db_password::1}</password>
    </security>
</datasource>

---

5. 운영 환경 적용 전략 (Deployment Strategy)

이중화(HA)된 운영 환경에서 서비스 중단을 방지하기 위해, host.xml 설정과 domain.xml 설정을 분리하여 적용하는 전략이 필요합니다.

Scenario A: 무중단 순차 적용 (Rolling Update)

Host Controller(HC) 설정인 host.xml은 재기동이 필요하지만, domain.xml 변경은 리로드(Reload)로 반영될 수 있음을 이용합니다.

1. Slave 서버(Server2) 작업:
   • Slave HC 중지
   • Slave host.xml에 Vault 설정 추가 및 vault.keystore 파일 배포
   • Slave HC 재기동 (이때 Server2 인스턴스들도 재기동됨)
2. Master 서버(Server1) 작업:
   • Master HC 중지 (도메인 컨트롤러 중지)
   • Master host.xml에 Vault 설정 추가 및 vault.keystore 파일 배포
   • Master HC 재기동
3. Datasource 변경:
   • Master가 기동된 상태에서 domain.xml의 데이터소스 패스워드를 ${VAULT::...}로 변경
   • JBoss CLI 또는 콘솔에서 Datasource Disable/Enable 수행 (또는 reload)

Scenario B: 전체 중단 후 적용 (Cold Restart)

가장 안전하고 확실한 방법입니다. 유지보수 시간(Maintenance Window)이 확보되었을 때 권장합니다.

1. 모든 JBoss 프로세스(Master/Slave) 종료
2. 모든 서버의 host.xml 수정 및 키스토어 배포
3. Master 서버의 domain.xml 수정
4. Master 기동 → Slave 기동 순서로 전체 재시작

---

6. 검증 (Verification)

• 서버 기동 로그(server.log)에 Vault 관련 에러(PBOX000...)가 없는지 확인합니다.
• 관리 콘솔에서 Datasource의 Test Connection을 수행하여 DB 연결이 정상적인지 확인합니다.

[WebSphere Liberty] securityUtility로 SSL 인증서 생성 및 AES 패스워드 암호화 설정 가이드

WebSphere Liberty의 securityUtility 도구를 사용하여 자체 서명된(Self-Signed) SSL 인증서를 생성하고, 보안성을 높이기 위해 Keystore 비밀번호를 AES로 암호화하여 설정하는 방법을 정리합니다.

0. 배경 및 시나리오 (Context)

Liberty 서버는 기본적으로 개발 편의를 위해 SSL 설정을 자동화하지만, 운영 환경에서는 명시적인 인증서 관리와 비밀번호 보안이 필수적입니다. securityUtility를 사용하면 인증서 생성과 비밀번호 암호화(Encoding)를 동시에 수행할 수 있습니다.

Test Environment

• Middleware: WebSphere Liberty Profile (WLP)
• Server Name: s11, s12

---

1. SSL 인증서 생성 및 암호화 (Create Certificate)

securityUtility createSSLCertificate 명령어를 사용하여 키스토어(PKCS12)를 생성합니다. 이때 --passwordEncoding=aes 옵션을 사용하여 설정 파일에 들어갈 비밀번호를 암호화합니다.

명령어 구문

# 구문: securityUtility createSSLCertificate --server=[서버명] --password=[키패스워드] --validity=[유효기간일수] --passwordEncoding=aes --passwordKey=[암호화키]

cd $WLP_HOME/bin
./securityUtility createSSLCertificate --server=s11 --password=passw0rd --validity=7300 --passwordEncoding=aes --passwordKey=passw0rd

실행 결과

키 저장소 /sw/was/WebSphere/wlp/usr/servers/s11/resources/security/key.p12을(를) 작성하는 중입니다.

서버 s11에 대한 SSL 인증서를 작성했습니다. 
이 인증서는 CN=testwas11,OU=s11을(를) 사용하여 SubjectDN으로 작성되었습니다.

Tip: 여기서 생성된 키스토어 파일(key.p12)은 usr/servers/[서버명]/resources/security/ 경로에 저장됩니다.

---

2. 서버 설정 적용 (server.xml)

위에서 생성된 인증서를 서버가 사용하도록 server.xml을 수정합니다. 이때 비밀번호 부분에 {aes}... 로 시작하는 암호화된 문자열을 입력해야 합니다.

<server description="SSL Server">

    <!-- 1. SSL 기능 활성화 -->
    <featureManager>
        <feature>transportSecurity-1.0</feature>
    </featureManager>

    <!-- 2. Keystore 정의 (비밀번호는 암호화된 값 사용) -->
    <keyStore id="defaultKeyStore" 
              location="key.p12"
              password="{aes}AJS+VEek/Fgo/zp46z8cuIUMTbnMM7sJVmPPbT49n4s6" />

</server>

---

3. 암호화 키 등록 (bootstrap.properties)

server.xml에 적힌 {aes} 비밀번호를 서버가 복호화하려면, 암호화할 때 사용했던 Key를 서버에 알려주어야 합니다. 이 설정은 bootstrap.properties 파일에 저장합니다.

• 파일 위치: usr/servers/[서버명]/bootstrap.properties

# securityUtility 실행 시 --passwordKey 옵션에 넣었던 값
wlp.password.encryption.key=passw0rd

주의: 이 설정이 누락되면 서버 기동 시 CWWKS1704E: 비밀번호를 복호화할 수 없습니다. 에러가 발생합니다.

---

4. 인증서 검증 (Verification)

생성된 키스토어 파일이 정상적인지, 유효기간은 맞는지 확인하기 위해 JDK에 포함된 keytool 명령어를 사용합니다.

검증 명령어

# keytool -list -v -keystore [파일경로] -storetype PKCS12 -storepass [비밀번호]
./keytool -list -v -keystore /sw/was/WebSphere/wlp/usr/servers/s12/resources/security/key.p12 -storetype PKCS12 -storepass passw0rd

출력 결과 분석

키 저장소 유형: PKCS12
키 저장소 제공자: SUN

별칭 이름: default
생성 날짜: 2024. 6. 12.
항목 유형: PrivateKeyEntry
인증서 체인 길이: 2

# 유효기간 확인
적합한 시작 날짜: Wed Jun 12 16:47:57 KST 2024 
종료 날짜: Tue Jun 07 16:47:57 KST 2044 (약 20년)

# 소유자 및 서명 알고리즘 확인
소유자: CN=testwas11, OU=s12, O=ibm, C=us
서명 알고리즘 이름: SHA256withRSA
주체 공용 키 알고리즘: 2048비트 RSA 키

---

Next Step:
자체 서명 인증서(Self-Signed)는 브라우저에서 경고가 발생하므로, 운영 환경에서는 CSR을 생성하여 공인 인증기관(CA)의 서명을 받은 후 keytool -import 명령어로 교체해야 합니다.

[JBoss EAP 7] 보안 헤더 숨기기: Server 및 X-Powered-By 정보 노출 방지 (Undertow Filter 설정)

JBoss EAP 7.4 (Undertow)의 HTTP 응답 헤더에 노출되는 서버 버전 정보(Server: JBoss-EAP/7, X-Powered-By: JSP/2.3)를 제거하거나 변경하여 보안성을 강화하는 방법을 정리합니다. CLI 명령어를 이용한 JSP 설정 변경과 필터(Filter) 적용 방법을 다룹니다.

1. 문제 현상 (Issue)

기본 설정 상태에서 JBoss EAP 7.4는 응답 헤더에 구체적인 미들웨어 정보를 노출합니다. 이는 공격자에게 서버 정보를 제공하는 단서가 되므로 보안 취약점으로 분류됩니다.

노출되는 헤더 예시

HTTP/1.1 200 OK
X-Powered-By: Undertow/1
X-Powered-By: JSP/2.3
Server: JBoss-EAP/7
...

2. 해결 방법 (Resolution Plan)

조치는 크게 두 단계로 나뉩니다. ① JSP 엔진이 자동으로 붙이는 헤더 비활성화, ② Undertow 필터를 사용하여 Server 헤더 덮어쓰기입니다.

Step 1: X-Powered-By (JSP) 비활성화

서블릿 컨테이너 설정에서 JSP 엔진이 해당 헤더를 생성하지 못하도록 설정합니다.

[JBoss CLI 명령어]

# JSP 설정의 x-powered-by 속성을 false로 변경
/subsystem=undertow/servlet-container=default/setting=jsp:write-attribute(name=x-powered-by,value=false)

# 설정 적용을 위한 리로드 (필요시)
reload

확인: 관리 콘솔에서도 Configuration > Subsystems > Undertow > Servlet Container > JSP 항목에서 X-Powered-By 체크박스가 해제된 것을 확인할 수 있습니다.

---

Step 2: Server 헤더 변경/삭제 (Undertow Filter)

Server 헤더는 엔진 레벨에서 붙는 경우가 많아 아예 삭제가 어렵다면, 필터(Filter)를 통해 무의미한 값으로 덮어쓰는(Override) 방식을 사용합니다.

[JBoss CLI 명령어]

# 1. 헤더 변경용 필터 생성 (이름: server-header, 값: "Apache" 또는 빈 값)
/subsystem=undertow/configuration=filter/response-header=server-header:add(header-name="Server", header-value="Apache")

# 2. X-Powered-By (Undertow) 헤더 제거 필터 생성 (필요 시)
/subsystem=undertow/configuration=filter/response-header=x-powered-by-header:add(header-name="X-Powered-By", header-value="Unknown")

# 3. 생성한 필터를 기본 호스트(default-host)에 적용
/subsystem=undertow/server=default-server/host=default-host/filter-ref=server-header:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=x-powered-by-header:add

Tip: header-value에 빈 값("")을 넣거나 일반적인 웹 서버 이름("Webserver")을 넣어 공격자에게 혼동을 줄 수 있습니다.

---

3. 조치 결과 확인 (Verification)

설정 적용 후 curl 명령어나 브라우저 개발자 도구를 통해 응답 헤더가 변경되었는지 확인합니다.

변경 전후 비교

헤더(Header)	변경 전 (Before)	변경 후 (After)
Server	JBoss-EAP/7	Apache (설정한 값)
X-Powered-By	JSP/2.3, Undertow/1	(삭제됨) 또는 Unknown

[그림] 조치 후 헤더 정보 노출 테스트 결과

[WebSphere] native_stderr 로그 비대화 해결: Verbose GC 로그 분리 및 로테이션 설정

WebSphere의 native_stderr.log 파일에는 로테이션(Rotation) 기능이 내장되어 있지 않습니다. 따라서 Verbose GC가 활성화된 경우 파일 용량이 무한정 증가합니다. 이를 해결하기 위해 JVM 옵션을 사용하여 GC 로그를 별도 파일로 분리하고 순환시키는 방법을 정리합니다.

1. 원인 분석 (Root Cause)

WebSphere는 SystemOut.log와 SystemErr.log에 대해서는 시간/크기 기반의 로그 순환을 지원합니다. 하지만, JVM 프로세스 자체의 출력을 담는 native 로그는 WAS가 제어하지 못합니다.

• 문제점: 관리 콘솔에서 "Verbose garbage collection"을 체크하면, GC 수행 기록이 native_stderr.log에 누적됩니다.
• 결과: 시간이 지남에 따라 파일이 GB 단위로 커지며, 디스크 Full 장애를 유발할 수 있습니다.

Test Environment

• OS: CentOS 7 (3.10.0-957.el7.x86_64)
• WAS: WebSphere Application Server v8.5 / 9.0
• JDK: IBM JDK (WebSphere 기본)

---

2. 해결 방법: GC 로그 분리 설정

해결의 핵심은 native 로그에 GC 내용을 남기지 않고, 별도의 파일로 빼내는 것입니다. 사용하는 JDK 벤더에 따라 옵션이 다릅니다.

Step 1: 기본 Verbose GC 비활성화

JVM 옵션으로 제어하기 위해, 콘솔의 체크박스 옵션은 해제해야 합니다.

• 경로: 서버 > 서버 유형 > WebSphere Application Server > [서버명] > Java 및 프로세스 관리 > 프로세스 정의 > Java 가상 머신
• 조치: Verbose garbage collection 체크박스 해제 (Uncheck)

[그림] 기본 Verbose GC 옵션 해제

Step 2: 일반 JVM 인수(Generic JVM arguments) 추가

같은 화면의 Generic JVM arguments 입력란에 아래 옵션을 추가합니다.

Case A: IBM JDK 사용 시 (WebSphere 기본)

IBM JDK는 -Xverbosegclog 옵션을 사용하여 로그 파일 경로와 로테이션 규칙을 지정합니다.

# 구문: -Xverbosegclog:[경로/파일명][,X,Y]
# X: 파일 개수, Y: 파일당 GC 사이클 수

# 예시 1: 날짜/PID 포함하여 단일 파일 생성 (가장 일반적)
-Xverbosegclog:${SERVER_LOG_ROOT}/gc.%Y%m%d.%H%M%S.%pid.txt

# 예시 2: 10,000 사이클마다 파일 교체, 총 10개 파일 유지 (로테이션)
-Xverbosegclog:${SERVER_LOG_ROOT}/verbosegc.log,10,10000

Case B: Oracle/HotSpot JDK 사용 시

드물지만 Solaris나 특정 환경에서 HotSpot 계열 JDK를 사용하는 경우입니다.

-verbose:gc
-Xloggc:${SERVER_LOG_ROOT}/verbosegc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=20M
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails

Tip: ${SERVER_LOG_ROOT} 변수를 사용하면 하드코딩된 경로 대신 각 서버의 로그 디렉토리를 자동으로 찾아가므로 관리가 용이합니다.

---

3. 적용 확인 (Verification)

1. 설정 저장 후 서버를 재기동합니다.
2. ps -ef | grep java 명령어로 프로세스를 확인했을 때, 추가한 옵션이 적용되어 있는지 확인합니다.
3. 로그 디렉토리(logs/[서버명]/)에 gc...txt 또는 설정한 이름의 파일이 생성되는지 확인합니다.

---

Next Step:
분리된 GC 로그 파일은 IBM GCMV (Garbage Collection and Memory Visualizer) 도구에 넣어 분석하면 메모리 누수나 튜닝 포인트를 시각적으로 확인할 수 있습니다.

[WebSphere] Log4j 보안 취약점(Log4Shell) 긴급 대응: kc.war 및 uddi.ear 조치 가이드

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

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

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

제품 (Product)	영향 버전 (Versions)
WebSphere Application Server (Traditional)	9.0, 8.5, 8.0, 7.0
WebSphere Liberty	Continuous Delivery (All)

---

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

주의: 향후 9.0.5.11 이전의 픽스팩을 적용하면 삭제한 파일이 복구될 수 있으므로, 패치 후 다시 확인해야 합니다.

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)

Summary:
WAS 운영팀은 kc.war와 uddi.ear 내의 log4j 파일을 삭제하고, 개발팀은 배포하는 애플리케이션(WAR/EAR) 내에 취약한 Log4j 버전이 포함되지 않도록 빌드 의존성을 점검해야 합니다.

[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 적용이 완료됩니다.

[WebSphere] 보안 감사 대응: NCSA Access Log 활성화 및 로그 포맷(User-Agent, Time) 커스터마이징

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 체크박스 선택

Tip: HTTPS(SSL) 요청에 대한 로그도 남기려면 WCInboundDefaultSecure 체인에 대해서도 동일하게 설정해야 합니다.

---

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. 주요 포맷 지시어 설명

지시어	설명
%h	클라이언트 IP 주소 (Host)
%t	요청 시간 (Time)
%r	요청 라인 (Request Line) - Method, URI, Protocol
%s	응답 상태 코드 (Status Code, 예: 200, 404, 500)
%D	요청 처리 소요 시간 (마이크로초 단위, 성능 분석 시 중요)
%{Header}i	특정 요청 헤더 값 (예: %{User-Agent}i)
%{Cookie}C	특정 쿠키 값 (예: %{JSESSIONID}C)

---

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

[WebSphere] TLS 1.2 전환 완벽 가이드: 버전별 지원 현황 및 WAS/IHS/Plugin 필수 설정

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 버전이 충족되어야 합니다.

WAS Version	Minimum Fix Pack	Required SDK Version
v7.0	7.0.0.23 이상	SDK 6 SR10 FP1 이상
v8.0	8.0.0.3 이상	SDK 6.0.1 (J9 2.6) SR1 FP1 이상
v8.5	8.5.0.0 (기본 지원)	SDK 6.0.1 (J9 2.6) SR2 이상

주의 (v7.0 제한사항):
WAS v7.0은 Java 레벨에서는 TLS 1.2를 지원하지만, 함께 제공되는 Web Server Plugin(GSKit V7 사용)은 TLS 1.2를 지원하지 않습니다. 따라서 v7.0 환경에서 웹 서버 연동 구간까지 TLS 1.2를 적용하려면 Plugin 모듈 업그레이드 혹은 아키텍처 검토가 필요할 수 있습니다.

---

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>

Tip: StrictSecurity="true" 설정은 플러그인이 WAS와 통신할 때 TLS 프로토콜을 엄격하게 준수하도록 강제하여, TLS 1.2 핸드쉐이크 문제를 해결합니다.

---

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