Apache/IHS 성능 튜닝: MaxRequestWorkers

"서버가 자주 죽어요", "사용자가 몰리면 응답이 없어요." 이런 문제의 상당수는 Apache/IHS의 동시 접속자 처리 설정, 즉 MPM(Multi-Processing Module) 설정과 관련이 깊습니다. 이 가이드에서는 서버의 물리적 한계 내에서 최대 성능을 끌어내는 MPM 튜닝, 특히 MaxRequestWorkers 설정을 정복하는 방법을 단계별로 안내합니다.

(참고: Apache 2.2의 MaxClients는 2.4 버전부터 MaxRequestWorkers로 이름이 변경되었습니다. 기능은 동일합니다.)

Busy server rack with many network cables

서버의 성능은 올바른 설정에서 시작됩니다.


1. 모든 것의 시작: 핵심 공식

MaxRequestWorkers 튜닝은 감으로 하는 것이 아니라, 서버의 물리적 RAM을 기준으로 한 명확한 계산에서 시작해야 합니다.

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

이 공식의 목표는 간단합니다. 메모리 부족으로 인한 스왑(Swap) 발생을 막아, 서버가 급격히 느려지는 재앙을 피하는 것입니다.


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

최적의 MaxRequestWorkers 값을 찾기 위해 아래 3단계를 순서대로 진행합니다.

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

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

# SSH로 서버에 접속하여 아래 명령어를 실행합니다.
ps -ylC httpd --sort:rss | awk '{sum+=$8; ++n} END {print "Average RSS: " sum/n/1024 " MB"}'

결과로 Average RSS: 45.5 MB 와 같이 나옵니다. 이 값이 공식의 분모가 됩니다.

2단계: Apache가 사용할 수 있는 RAM 산정

서버의 전체 RAM에서 OS, DB 등 다른 서비스가 사용하는 메모리를 제외하여 Apache가 독점적으로 사용할 수 있는 RAM을 계산합니다.

# 사용 가능한 메모리를 MB 단위로 확인합니다.
free -m

예시: 총 16GB RAM 서버에서 DB가 4GB, OS 및 기타 서비스가 2GB를 사용한다면, Apache를 위해 할당할 수 있는 RAM은 16 - 4 - 2 = 10GB (10240 MB) 입니다. 이것이 공식의 분자가 됩니다.

3단계: 최종 값 계산

이제 1, 2단계에서 구한 값들을 공식에 대입합니다.

  • 계산: 10240 MB / 45.5 MB = 225.05
  • 결론: 소수점 이하는 버리고, MaxRequestWorkers의 최적값은 225로 산출할 수 있습니다.

3. 보이지 않는 벽: Limit 지시어 이해하기

MaxRequestWorkers 값을 계산했더라도, 이 값이 제대로 동작하려면 ServerLimitThreadLimit이라는 '보이지 않는 벽'을 이해해야 합니다. 이들은 각각 MaxRequestWorkersThreadsPerChild의 설정 가능한 최댓값을 제한하는 '하드 리밋'입니다.

  • 규칙 1: MaxRequestWorkers <= ServerLimit * ThreadsPerChild
  • 규칙 2: ThreadsPerChild <= ThreadLimit

만약 이 Limit 지시어들이 설정 파일에 보이지 않는다면, Apache는 내부 기본값(보통 ServerLimit 16, ThreadLimit 64)을 사용합니다. 계산된 MaxRequestWorkers 값이 이 기본 한계를 초과한다면, 반드시 설정 파일에 ServerLimitThreadLimit을 명시적으로 추가해야 합니다.


4. 최적의 튜닝 전략: 안정성 vs 효율성

더 많은 요청을 처리하기 위해 ServerLimit(프로세스 수)과 ThreadsPerChild(프로세스당 스레드 수) 중 무엇을 늘려야 할까요?

ServerLimit (프로세스 증가) ThreadsPerChild (스레드 증가)
안정성 높음 (프로세스 독립, 하나가 죽어도 나머진 생존) 낮음 (스레드 메모리 공유, 하나가 죽으면 프로세스 전체 다운)
메모리 효율 낮음 (프로세스마다 독립적인 메모리 필요) 높음 (메모리 공유로 자원 절약)
권장 사항 적극 권장 신중한 접근 필요 ⚠️

결론은 명확합니다. 서버의 안정성을 최우선으로 고려해야 하므로, ThreadsPerChild는 25와 같이 검증된 값으로 고정하고, 성능 확장은 ServerLimit을 늘려서 대응하는 것이 표준적인 모범 사례입니다.


5. 최종 설정 예시 (Event MPM 기준)

위의 모든 내용을 종합하여, MaxRequestWorkers1000으로 설정하는 경우의 최종 httpd.conf (또는 mpm.conf) 설정 예시입니다.

# /etc/httpd/conf.d/mpm_event.conf

<IfModule mpm_event_module>
    # 1. ThreadsPerChild는 25로 고정 (ThreadLimit 기본값 64보다 작으므로 생략 가능)
    ThreadsPerChild         25

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

    # 3. 목표 MaxRequestWorkers 설정 (40 * 25 = 1000 이므로 유효)
    MaxRequestWorkers       1000

    # 4. 기타 옵션은 서버 상황에 맞게 설정
    StartServers            4
    MinSpareThreads         75
    MaxSpareThreads         250
    MaxConnectionsPerChild  0
</IfModule>

Windows에서 npm 실행 정책 오류 해결하기

Windows에서 npm 실행 정책 오류 해결하기

Node.js는 설치했지만 npm 명령어를 실행할 때 PowerShell 실행 정책 오류가 발생하는 경우가 있습니다. 이는 Windows의 보안 정책 때문인데, 간단한 설정 변경으로 해결할 수 있습니다.

🚨 문제 상황

Node.js가 정상적으로 설치되었지만 npm 명령어 실행 시 다음과 같은 오류가 발생합니다.

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

💡 원인 분석

이 문제는 PowerShell의 실행 정책(Execution Policy) 때문에 발생합니다. Windows는 보안을 위해 기본적으로 모든 스크립트 실행을 차단하는 "Restricted" 정책을 사용하는데, npm은 실제로 PowerShell 스크립트로 구현되어 있어 이 정책에 막히는 것입니다.

🔧 해결 방법

1현재 실행 정책 확인

먼저 현재 시스템의 실행 정책을 확인해보겠습니다.

Get-ExecutionPolicy

대부분 "Restricted"로 표시될 것입니다.

2PowerShell 관리자 권한으로 실행

시작 메뉴에서 "PowerShell"을 검색하고 우클릭하여 "관리자 권한으로 실행"을 선택합니다.

3실행 정책 변경 (권장 방법)

사용자 수준에서만 정책 변경:
이 방법은 현재 사용자에게만 적용되어 시스템 전체 보안에 영향을 주지 않습니다.
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

확인 메시지가 나타나면 Y를 입력하여 변경을 승인합니다.

4npm 동작 확인

이제 npm이 정상적으로 작동하는지 확인해보겠습니다.

npm --version

5MCP 설치 진행

문제가 해결되었다면 원래 목표였던 MCP를 설치할 수 있습니다.

npm install -g @modelcontextprotocol/cli

🛡️ 보안 고려사항

RemoteSigned 정책이란?
로컬에서 작성된 스크립트는 실행을 허용하되, 인터넷에서 다운로드된 스크립트는 디지털 서명이 있을 때만 실행을 허용하는 균형잡힌 보안 정책입니다.

🔄 대안 방법들

임시 해결책

현재 PowerShell 세션에서만 임시로 정책을 변경하려면 다음 명령어를 사용하세요.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process

명령 프롬프트(cmd) 사용

PowerShell 대신 전통적인 명령 프롬프트를 사용하는 방법도 있습니다. cmd는 PowerShell의 실행 정책 제약을 받지 않기 때문에 npm이 정상적으로 작동합니다.

🎯 결론

Windows에서 npm 실행 정책 오류는 매우 흔한 문제이지만, PowerShell의 실행 정책을 적절히 조정하면 쉽게 해결할 수 있습니다. 사용자 수준에서만 정책을 변경하는 것이 보안과 편의성의 균형을 맞추는 가장 좋은 방법입니다.

핵심 포인트: RemoteSigned 정책으로 변경하여 npm과 같은 합법적인 도구는 사용할 수 있게 하되, 의심스러운 스크립트는 여전히 차단하는 것이 중요합니다.

Apache 보안 취약점 조치 - 버전 정보 노출 방지

Apache 웹 서버는 기본 설정으로 버전 정보 및 모듈 정보를 외부에 노출합니다. 이 정보는 공격자가 취약점을 탐지하는 데 활용될 수 있으므로, 보안 강화를 위해 노출을 최소화해야 합니다.

1. ServerTokens 설정

항목 기본값 변경값 설명
ServerTokens Full Prod Apache 버전, OS, 모듈 정보까지 모두 노출 → "Apache"로만 표시되도록 제한
ServerTokens Prod

2. ServerSignature 설정

항목 기본값 변경값 설명
ServerSignature On Off 에러 페이지 하단에 Apache 버전 정보 노출 → 정보 비표시
ServerSignature Off

3. Server 헤더 제거 (선택 사항)

mod_headers 모듈 사용 시 HTTP 헤더 내의 Server 정보를 완전히 제거할 수 있습니다.

Header unset Server

참고: 클라이언트나 일부 시스템에서 호환성 문제가 발생할 수 있으므로 사전 테스트 권장

4. 설정 적용

설정 변경 후 Apache를 재시작하여 적용합니다.

# CentOS / RHEL
systemctl restart httpd

# Ubuntu / Debian
systemctl restart apache2

참고

  • 추가 보안을 위해 X-Content-Type-Options, X-Frame-Options, Content-Security-Policy 등의 보안 헤더 설정도 함께 고려하세요.

JBoss EAP 7.x - 데이터소스 비밀번호 암호화 (Password Vault)

이 문서는 JBoss EAP 7.x 환경에서 데이터소스 비밀번호를 암호화하여 안전하게 관리하는 방법을 정리한 것입니다. Windows와 Linux, Standalone과 Domain 모드를 모두 포함합니다.


1. 절차 개요

  1. KeyStore(저장소) 생성
    • keytool로 JCEKS 형식 KeyStore 파일 생성
  2. Vault 암호화
    • vault.bat / vault.sh로 비밀번호 암호화
    • 암호화 결과를 ${VAULT::...::...::1} 형태로 참조
  3. Vault 구성 등록
    • CLI 명령어 또는 설정 파일 이용
  4. 데이터소스 비밀번호 적용
    • <password>${VAULT::...}</password> 형태로 설정

2. KeyStore 생성

2.1 Windows (keytool.exe 예시)

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"

2.2 Linux (keytool 예시)

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

옵션 설명

  • -storetype jceks : JCEKS 형식
  • -keyalg AES : AES 알고리즘
  • -storepass, -keypass : KeyStore와 키 암호
  • -validity : 키 유효기간(일)

3. 비밀번호 암호화 (Vault 사용)

3.1 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 "RealPassword!" ^
  --enc-dir "D:\app\was\JBoss\vault" ^
  --iteration "44" ^
  --salt "JBo72ssv"

3.2 Linux (vault.sh 예시)

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

실행 후 콘솔에 MASK-xxxx 형태의 비밀키와 ${VAULT::vb::dbpw::1} 같은 참조 문자열이 표시됩니다. 이를 <password>${VAULT::vb::dbpw::1}</password> 형태로 사용합니다.


4. Vault 구성 등록 - CLI 명령어 방식

4.1 Standalone 모드

/core-service=vault:add(vault-options=[
  ("KEYSTORE_URL"      => "D:\app\was\JBoss\vault\vault.keystore"),
  ("KEYSTORE_PASSWORD" => "MASK-xxxx"),
  ("KEYSTORE_ALIAS"    => "vault"),
  ("SALT"              => "JBo72ssv"),
  ("ITERATION_COUNT"   => "44"),
  ("ENC_FILE_DIR"      => "D:\app\was\JBoss\vault\")
])

Linux에서는 경로를 /app/was/JBoss/vault 등으로 변경하고, vault.sh로 작업합니다.

4.2 Domain 모드

/host=<host_name>/core-service=vault:add(vault-options=[
  ("KEYSTORE_URL"      => "D:\app\was\JBoss\vault\vault.keystore"),
  ("KEYSTORE_PASSWORD" => "MASK-xxxx"),
  ("KEYSTORE_ALIAS"    => "vault"),
  ("SALT"              => "JBo72ssv"),
  ("ITERATION_COUNT"   => "44"),
  ("ENC_FILE_DIR"      => "D:\app\was\JBoss\vault\")
])

<host_name> 자리에 실제 호스트명을 기재합니다.


5. Vault 구성 등록 - 설정 파일 편집 방식

5.1 Standalone 모드

standalone.xml 파일에 아래와 같은 <vault> 섹션을 추가합니다.

<vault>
    <vault-option name="KEYSTORE_URL" value="D:\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="D:\app\was\JBoss\vault\"/>
</vault>

5.2 Domain 모드

domain.xml (도메인 컨트롤러, DC)에 Vault 설정을 추가하여 도메인 전체에 공유합니다.
host.xml (각 호스트)에서는 로컬 경로나 권한이 달라질 경우 설정을 재정의할 수 있습니다.

domain.xml 예시

<vault>
    <vault-option name="KEYSTORE_URL" value="D:\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="D:\app\was\JBoss\vault\"/>
</vault>

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

데이터소스 설정(standalone.xml 또는 domain.xml)의 <datasource> 섹션에서 비밀번호를 아래처럼 교체합니다.

<password>${VAULT::vb::dbpw::1}</password>

이로써 실제 비밀번호는 암호화된 상태로 관리됩니다.


JBoss EAP 6.4 도메인 모드에서 Vault를 이용한 데이터소스 비밀번호 암호화

JBoss EAP 6.4 도메인 모드에서 Vault를 이용한 데이터소스 비밀번호 암호화

JBoss EAP 6.4 도메인 모드에서 데이터소스 비밀번호를 암호화하는 방법을 정리했습니다. Vault 기능을 사용하여 데이터소스 비밀번호를 보호하고, 도메인 모드 환경에서 이를 적용하는 방법을 단계별로 설명합니다.

1. Vault 환경 준비 및 Keystore 생성

먼저 암호화를 위한 Keystore를 생성합니다.

keytool -genkey -alias vault -keyalg DESede -keystore vault.keystore

위 명령을 실행하면 비밀번호 입력 및 인증서 정보를 입력해야 합니다.

2. Vault 생성 및 설정

JBoss EAP에서 제공하는 Vault 스크립트를 실행하여 암호화 블록을 생성합니다.

$JBOSS_HOME/bin/vault.sh --keystore vault.keystore --keystore-password [비밀번호] --alias vault --iteration 120 --salt 1234abcd --enc-dir /path/to/vault/

3. host.xml에 Vault 설정 추가

각 호스트(`server1`, `server2`)의 host.xml 파일에 Vault 설정을 추가합니다.

<vault>
    <vault-option name="KEYSTORE_URL" value="/path/to/vault.keystore"/>
    <vault-option name="KEYSTORE_PASSWORD" value="keystore_비밀번호"/>
    <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에서 데이터소스 비밀번호 설정

domain.xml의 데이터소스 설정에서 비밀번호를 Vault 표현식으로 변경합니다.

<password>${VAULT::ds_vault::db_password}</password>

5. 서버 재시작 및 검증

Vault 설정을 적용한 후, 서버를 재시작하여 정상적으로 동작하는지 확인합니다.

📌 Vault 적용 시 서버 이중화 환경에서 설정 방법

서버가 이중화된 경우(`server1: 도메인 컨트롤러`, `server2: 호스트`) Vault 설정 적용 방법은 두 가지가 있습니다.

✅ 방법 1: 개별 서버에서 순차 적용 (무중단 배포)

  1. server2를 먼저 중지
  2. server2host.xml에 Vault 설정 추가 후 재기동
  3. server1 (도메인 컨트롤러) 중지
  4. server1host.xml에 Vault 설정 추가 후 재기동
  5. domain.xml에 Vault 표현식 적용 후 도메인 컨트롤러 재기동

💡 이 방법은 서비스 중단 없이 Vault를 적용할 수 있습니다.

✅ 방법 2: 전체 서버 중지 후 반영 (안정성 우선)

  1. 모든 서버 중지
  2. server1, server2host.xml에 Vault 설정 추가
  3. domain.xml에 Vault 표현식 반영
  4. 전체 서버 재기동

💡 이 방법은 적용 과정에서 오류 없이 설정이 일관되게 반영됩니다.

결론

Vault를 활용하여 JBoss EAP 6.4 도메인 모드에서 보안성을 강화할 수 있습니다.

  • 도메인 모드에서는 host.xml에 Vault 설정을 각각 적용
  • domain.xml에는 Vault 표현식만 반영
  • 운영 환경에 따라 순차 적용(무중단) 또는 전체 서버 중지 후 반영(안정성 우선)을 선택

설정을 올바르게 적용하면, 데이터소스 비밀번호를 평문으로 저장하는 보안 문제를 해결할 수 있습니다. 이 설정을 통해 더욱 안전한 JBoss EAP 환경을 구축하세요!

Liberty에서 SecurityUtility 기능을 활용한 키 설정 방법

Liberty에서 SecurityUtility 기능을 활용한 키 설정 방법

Liberty에서 securityUtility 기능을 사용하여 SSL 인증서를 생성하고 설정하는 방법을 아래에 설명합니다.

SSL 인증서 생성

./securityUtility createSSLCertificate --server=s11 --password=keyPassword --validity=7300 --passwordEncoding=aes --passwordKey=aesPassword
[was@testwas11 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으로 작성되었습니다.
    

server.xml 설정

SSL을 사용으로 설정하려면 server.xml에 다음 행을 추가하십시오.

<featureManager>
    <feature>transportSecurity-1.0</feature>
</featureManager>

<keyStore id="defaultKeyStore" password="{aes}AJS+VEek/Fgo/zp46z8cuIUMTbnMM7sJVmPPbT49n4s6" />
    

추가 서버 설정

./securityUtility createSSLCertificate --server=s12 --password=passw0rd --validity=7300 --passwordEncoding=aes --passwordKey=passw0rd
    

keystore.xml 설정

<include optional="true" location="${shared.config.dir}/keystore.xml"/>

<featureManager>
    <feature>transportSecurity-1.0</feature>
</featureManager>
<keyStore id="defaultKeyStore" password="{aes}AMtKC7lXkUIQygehwW0+8jf1Fj4lrIW4DAh+eKvFPfat" />
    

bootstrap.properties 설정

bootstrap.properties
wlp.password.encryption.key=passw0rd
    

SSL 키 만료일 확인

keytool -list -v -keystore key.p12 -storetype PKCS12 -storepass [keystore_password]
./keytool -list -v -keystore /sw/was/WebSphere/wlp/usr/servers/s12/resources/security/key.p12 -storetype PKCS12 -storepass admin
[root@testwas11 bin]# ./keytool -list -v -keystore /sw/was/WebSphere/wlp/usr/servers/s12/resources/security/key.p12 -storetype PKCS12 -storepass admin
키 저장소 유형: PKCS12
키 저장소 제공자: SUN

키 저장소에 1개의 항목이 포함되어 있습니다.

별칭 이름: default
생성 날짜: 2024. 6. 12.
항목 유형: PrivateKeyEntry
인증서 체인 길이: 2
인증서[1]:
소유자: CN=testwas11, OU=s12, O=ibm, C=us
발행자: OU=memberRoot, O=24ca5bb7-7300-4e29-bb99-908da7ee6c0c, DC=com.ibm.ws.collective
일련 번호: 85835eba9e4
적합한 시작 날짜: Wed Jun 12 16:47:57 KST 2024 종료 날짜: Tue Jun 07 16:47:57 KST 2044
인증서 지문:
         SHA1: 46:88:F4:44:4C:EB:9E:47:E3:D7:89:22:FE:14:5F:A4:DE:E5:FC:1E
         SHA256: 7D:73:5C:F7:70:AD:4E:C5:30:6A:9C:71:55:FD:30:91:7A:B5:AE:3B:95:2F:7F:03:A0:CA:F8:7D:42:3A:30:97
서명 알고리즘 이름: SHA256withRSA
주체 공용 키 알고리즘: 2048비트 RSA 키
버전: 3

확장:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 09 17 C6 7C 51 66 4C AF   EA B5 55 CA E2 BF 20 24  ....QfL...U... $
0010: BD 45 EE 25                                        .E.%
]
]

인증서[2]:
소유자: OU=memberRoot, O=24ca5bb7-7300-4e29-bb99-908da7ee6c0c, DC=com.ibm.ws.collective
발행자: OU=memberRoot, O=24ca5bb7-7300-4e29-bb99-908da7ee6c0c, DC=com.ibm.ws.collective
일련 번호: 62413717a182c
적합한 시작 날짜: Wed Jun 05 10:06:16 KST 2024 종료 날짜: Sun May 30 10:06:16 KST 2049
인증서 지문:
         SHA1: B2:CA:64:2B:32:B3:20:F7:27:B3:74:35:37:ED:7B:1D:98:39:83:13
         SHA256: 42:61:C1:19:4C:57:D0:6A:48:55:3A:57:EE:23:77:1D:4F:80:88:76:AE:E8:9E:70:47:0D:46:AC:42:91:0C:97
서명 알고리즘 이름: SHA256withRSA
주체 공용 키 알고리즘: 2048비트 RSA 키
버전: 3

확장:
    

WebSphere when native_stdout file capacity continues to increase


WAS : JBoss EAP 7.4

issue

How to suppress or change "Server" header and "X-Powered-By" response header returned by JBoss EAP 7.4

보안 취약문제로 Response header "Server", "x-powered-by" 에 노출 되는 버전 정보 문제

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

Solution plan

x-powered-by 옵션 비활성화

cli mod

/subsystem=undertow/servlet-container=default/setting=jsp:write-attribute(name=x-powered-by,value=false)

admin console

Header 값 변경 cli mod

/subsystem=undertow/configuration=filter/response-header=server-header:write-attribute(name=header-value,value=foo)  
/subsystem=undertow/configuration=filter/response-header=x-powered-by-header:write-attribute(name=header-value,value=bar)

조치 결과

startanalone.xml or domain.xml 반영 결과

정보 노출 테스트 결과

WebSphere when native_stdout file capacity continues to increase


OS : CentOS 7 3.10.0-957.el7.x86_64

issue

JVM-"Java"-Logs(SystemOut, SystemErr)의 경우 WebSphere에는 로그 순환을 허용하는 내장 메커니즘이 있다(시간 또는 크기 기반 접근법 또는 두 가지 접근법의 혼합). JVM-"프로세스"-Logs(native_stderr, native_stdout)의 경우 WebSphere에는 이러한 내장 메커니즘이 없다.

특히 native_stderr 파일을 로그 로테이션을 전하고자 하는 주된 이유는 일반적으로 가비지 콜렉션의 verbosegc(Verbose Garbassy Collection) 항목이 포함되기 때문이며, 이 파일은 수행된 모든 가비지 콜렉션(GC) 사이클과 관련 통계(예: GC 실행 전/후 메모리 양)의 레코드 저장소다. 이러한 verbosegc 레코드는 시간이 지남에 따라 크게 증가하므로 native_stderr파일은 상당히 커질수 있다.

  • 상세한 가비지 콜렉션 옵션 On

Solution plan

JVM의 -Xverbosegclog 옵션을 활용해서 GC 로그를 별도로 생성 하는 방식으로 우회해서 사용할 수 있다.

  • 상세한 가비지 콜렉션 옵션 Off
  • JVM -Xverbosegclog 설정 구문
    -Xverbosegclog[:<filename>[,<x>,<y>]]

where <file> specifies a base filename, <X> is the number of files being used and <Y> is the number of GC cycles contained in one file (before rollover).

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

예)

-Xverbosegclog:/app/was/gclogs/websphere/server1/gc.%Y%m%d.%H%M%S.%pid.txt

WebSphere 전체 Log4j 보안 취약점 관련 내용 정리

Security Bulletin: Multiple vulnerabilities in Apache log4j affect the IBM WebSphere Application Server and IBM WebSphere Application Server Liberty (CVE-2021-4104, CVE-2021-45046)


Affected Products and Versions

Affected Product(s) Version(s)
WebSphere Application Server Liberty Continuous delivery
WebSphere Application Server 9.0
WebSphere Application Server 8.5
WebSphere Application Server 8.0
WebSphere Application Server 7.0

관련 취약점 내용

아래의 이슈 사항을 확인 해보면 되지만 간략하게 정리 했습니다. 전체 플랫폼의 이슈되는 APP는 UDDI.ear 이면 기본적으로 구성을 위해 별도의 설치가 필요합니다.(미 사용중이라 영향도 없음)

결국 9.x kc.war 문제가 되며 해당 APP 경우 관리콘솔 도움말에 사용중 인 것으로 보이며, 문제가 되는 클래스 제거하거나 라이브러리를 제거 하는 식으로 임시 조치를 취하고 있습니다.

1. WebSphere Application Server traditional release 9.0 only:

Remove <WAS_HOME>/systemApps/isclite.ear/kc.war/WEB-INF/lib/log4j*.jar from any system running the WebSphere admin console and restart the application server.
Note: If any future service (prior to 8.5.5.21 or or 9.0.5.11) is applied to the install the log4j files will be restored without warning.
If the kc.war application has been installed then uninstall it. For instructions on how to determine if kc.war is installed see question Q9 in our Log4Shell (CVE-2021-44228) FAQ.
Remove <WAS_HOME>/installableApps/kc.war

2. All WebSphere Application Server traditional releases:

Users of the UDDI Registry Application: Remove log4j*.jar from within the <WAS_HOME>/installableApps/uddi.ear
archive and update (redeploy) any installed (deployed) copies of the UDDI Registry application.
Users who do not use the UDDI Registry Application should remove <WAS_HOME>/installableApps/uddi.ear

IBM 보고된 내용 링크
https://www.ibm.com/support/pages/node/6526750

3. Log4j 1.x 추가 사항

웹스피어의 경우 이경우가 UDDI.ear 따로 해당 기능을 사용하지 않으면 추가적인 조치가 필요 없음)

Is Log4j 1.x vulnerable

There is still a lot of information coming out surrounding Log4Shell. At the time this blog was published, Apache said that Log4j 1.2 is vulnerable in a similar way when Log4j is configured to use JMSAppender, which is not part of the default configuration, but is not specifically vulnerable to CVE-2021-44228. This vulnerability in Log4j 1.2 has been assigned CVE-2021-4104.

Is there a patch available for Log4j 1.2?

No, Log4j branch 1.x has reached end of life (EOL) status, and therefore does not receive security updates. Users are instructed to upgrade to Log4j 2.12.2 (for Java 7) or 2.16.0 or greater.

How do I address CVE-2021-4104?

There are a few mitigation options that can be used to prevent exploitation of CVE-2021-4104.

  • Do not use the JMSAppender in the Log4j configuration
  • Remove the JMSAppender class file (org/apache/log4j/net/JMSAppender.class)
  • Limit OS user access to prevent an attacker from being able to modify the Log4j configuration

Converting p12 to kdb files using gskcmd


Test Environment

-Test Version : IBM HTTPServer v9.x

Key file conversion

1. pem to p12

# openssl pkcs12 -export -inkey Wildcard.test.co.kr_pem.key -in Wildcard.cardif.co.kr_pem.pem -out Wildcard.test.co.kr.p12

2. p12 to kdb

  1. You can invoke the gskcapicmd from the install_root/bin directory

  2. Converting key file

# ./gskcapicmd -cert -export -target key.kdb -db /sw/img/Wildcard.cardif.co.kr.p12 -fips -target_type cms -type pkcs12

# ./gskcapicmd -cert -import -target ../ssl/key.kdb -target_pw {password} -db /sw/img/Wildcard.cardif.co.kr.p12 -pw {password}

# ./gskcapicmd -cert -setdefault -db ../ssl/key.kdb -pw {password} -label "*.test.co.kr"