A boring day ~

#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 →

#JBoss

[JBoss EAP 6] 커스텀 기동/정지 스크립트 작성 가이드 (Config 분리 및 JVM 튜닝)

JBoss EAP 6 Standalone 모드의 운영 효율성을 높이기 위해, JVM 옵션과 환경 변수를 별도의 설정 파일(Config Shell)로 분리하고 이를 로드하여 서버를 제어(Start/Stop/Status)하는 커스텀 쉘 스크립트 작성법을 공유합니다.

Test Environment

OS: CentOS 7.2
Middleware: JBoss EAP 6.4

1. 스크립트 구조 및 전략

유지보수성과 확장성을 위해 스크립트를 두 개의 파일로 분리합니다.

Config Script (config1.sh): JVM 옵션, 경로, IP, 포트 등 변수 정의.
Control Script (jboss_ctl.sh): Config를 로드하여 실제 프로세스를 제어하는 로직.

2. 설정 스크립트 (config1.sh)

서버 인스턴스별 고유한 설정을 이곳에 정의합니다. JAVA_OPTS를 통해 메모리 및 GC 로그 설정을 상세하게 튜닝할 수 있습니다.

#!/bin/sh
DATE=`date +%Y%m%d%H%M%S`

##### 1. Basic Configuration #####
export JBOSS_HOME=/SW/was/JBoss
export SERVER_HOME=/SW/was/JBoss/TEST/TESTServer11
export LOG_PATH=/app/logs/was
export NODE_NAME=TESTServer11
export CONFIG_FILE=standalone-ha.xml

# Network & Port Offset
export SERVER_IP=10.252.16.25
export PORT_OFFSET=750
export MGMT_ADDR=$SERVER_IP

# Controller Port Calculation (Base 9999 + Offset)
let CONTROLLER_PORT=9999+$PORT_OFFSET
export CONTROLLER_PORT

# Admin User (Shutdown용)
export USER=admin

##### 2. JVM Options (Memory & GC) #####
# Heap Memory
export JAVA_OPTS="-server -Xms1024m -Xmx2048m -XX:MaxPermSize=256m"

# GC Logging
export JAVA_OPTS=" $JAVA_OPTS -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails "
export JAVA_OPTS=" $JAVA_OPTS -Xloggc:$LOG_PATH/log/gclog/gc_$DATE.log "

# GC Algorithm (ParallelGC)
export JAVA_OPTS=" $JAVA_OPTS -XX:+UseParallelGC -XX:+ExplicitGCInvokesConcurrent"

# Heap Dump on OOM
export JAVA_OPTS=" $JAVA_OPTS -XX:-HeapDumpOnOutOfMemoryError "
export JAVA_OPTS=" $JAVA_OPTS -XX:HeapDumpPath=$LOG_PATH/heap/$NODE_NAME "

##### 3. System Properties (-D options) #####
export JAVA_OPTS=" $JAVA_OPTS -Djava.net.preferIPv4Stack=true"
export JAVA_OPTS=" $JAVA_OPTS -Dorg.jboss.resolver.warning=true"
export JAVA_OPTS=" $JAVA_OPTS -Djava.awt.headless=true"
export JAVA_OPTS=" $JAVA_OPTS -DjvmRoute=$NODE_NAME"

# JBoss Path & Binding
export JAVA_OPTS=" $JAVA_OPTS -Djboss.server.base.dir=$SERVER_HOME"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.server.log.dir=$LOG_PATH/$NODE_NAME"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.socket.binding.port-offset=$PORT_OFFSET"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.node.name=$NODE_NAME"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.bind.address.management=$MGMT_ADDR"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.bind.address=$SERVER_IP"

# Clustering (Multicast)
export JAVA_OPTS=" $JAVA_OPTS -Djboss.default.jgroups.stack=tcp"
# export JAVA_OPTS=" $JAVA_OPTS -Djboss.default.multicast.address=230.1.0.1"

echo "Configuration Loaded: $NODE_NAME"

3. 제어 스크립트 (jboss_ctl.sh)

실제 기동 및 정지를 담당하는 메인 스크립트입니다. ./config/config1.sh를 로드하여 변수들을 가져옵니다.

#!/bin/sh

# Config 파일 로드 (경로 주의)
. ./config/config1.sh

start(){
    # 프로세스 중복 실행 방지
    PID=`ps -ef | grep java | grep "jboss.node.name=$NODE_NAME " | awk '{print $2}'`
    
    if [ "x$PID" != "x" ]; then
        echo "###############################################"
        echo "ERROR: JBoss SERVER ($NODE_NAME) is already RUNNING (PID=$PID)"
        echo "###############################################"
        exit 1
    fi

    echo "#######################"
    echo "   Starting JBoss EAP  "
    echo "#######################"
    
    # nohup으로 백그라운드 실행, 로그 리다이렉션
    nohup $JBOSS_HOME/bin/standalone.sh --server-config=$CONFIG_FILE >> $LOG_PATH/console.log 2>&1 &

    echo "Starting... Wait for checking status..."
    sleep 5
    status
}

stop(){
    echo "#######################"
    echo "    Stopping JBoss     "
    echo "#######################"
    
    # 보안을 위해 패스워드는 입력받도록 처리 (자동화 시 변수로 대체 가능)
    echo -n "Enter Controller Password: "
    read -s PASSWORD
    echo ""

    # CLI를 이용한 안전한 종료 (Graceful Shutdown)
    $JBOSS_HOME/bin/jboss-cli.sh --connect --controller=$SERVER_IP:$CONTROLLER_PORT --command=:shutdown --user=$USER --password=$PASSWORD
}

status() {
    # 포트 리슨 상태로 구동 여부 확인
    _up=`netstat -an | grep $CONTROLLER_PORT | grep LISTEN | wc -l`
    
    if [ "$_up" -ne 0 ]; then
        PID=`ps -ef | grep java | grep "jboss.node.name=$NODE_NAME " | awk '{print $2}'`
        echo "###############################################"
        echo " JBoss Server is RUNNING !! "
        echo " Node: $NODE_NAME (PID: $PID)"
        echo " Port: $CONTROLLER_PORT (Management)"
        echo "###############################################"
    else
        echo "##################################"
        echo " JBoss Server is STOPPED !! "
        echo " Node: $NODE_NAME "
        echo "##################################"
    fi
}

# 파라미터 처리
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  status)
    status
    ;;
  restart)
    stop
    sleep 5
    start
    ;;
  *)
    echo "Usage: $0 {start|stop|status|restart}"
    exit 1
esac
exit 0

4. 사용 방법 및 주의사항

사용법

# 실행 권한 부여
chmod +x jboss_ctl.sh

# 기동
./jboss_ctl.sh start

# 상태 확인
./jboss_ctl.sh status

# 정지 (패스워드 입력 필요)
./jboss_ctl.sh stop

Tip: config1.sh 파일 내의 PORT_OFFSET 변수를 활용하면, 하나의 물리 서버에서 포트 충돌 없이 여러 개의 인스턴스를 띄울 수 있습니다. (예: 0, 100, 200...)

Read Log →

#Linux#WebSphere

[Linux/Java] High CPU 트러블슈팅: OS 스레드와 Java 스레드 매핑 분석 가이드

Java 프로세스(JVM)가 고부하 상태일 때, CPU를 점유하고 있는 범인(특정 스레드)을 찾아내는 방법을 정리합니다. OS 명령어(ps, top)로 문제의 스레드 ID(TID)를 식별하고, 이를 16진수로 변환하여 Java Thread Dump와 매핑하는 과정을 다룹니다.

Test Environment

OS: RedHat Linux (CentOS 호환)
Target: Java Process (WebSphere/Tomcat 등)

1. 프로세스 및 스레드 식별 (Identify Usage)

먼저 CPU를 많이 사용하는 Java 프로세스의 PID(Process ID)를 찾고, 그 내부에서 실제로 리소스를 소모하는 스레드(LWP, Light Weight Process)를 식별해야 합니다.

전체 프로세스 확인

# Java 프로세스 PID 확인
ps -ef | grep java

스레드별 CPU 점유율 확인 (top)

-H 옵션을 사용하여 프로세스 내부의 스레드 단위로 리소스를 모니터링합니다.

# PID가 12345인 경우
top -H -p 12345

출력 화면에서 PID(실제로는 TID/LWP) 컬럼과 %CPU 컬럼을 확인하여 가장 상단에 있는 번호를 기록합니다.

스레드별 CPU 점유율 확인 (ps)

ps 명령어를 통해서도 스레드 정보를 확인할 수 있습니다. -lmT 옵션이나 -L 옵션을 사용합니다.

# LWP(Light Weight Process) 확인
ps -lmT [PID]

# 또는 커스텀 포맷 사용
ps -eLo pid,lwp,pcpu,comm | grep [PID]

2. 스레드 ID 변환 (Decimal to Hex)

OS에서 확인한 스레드 ID는 10진수(Decimal)이지만, Java Thread Dump 파일(Javacore 등)에서는 스레드 ID가 16진수(Hexadecimal)로 기록됩니다. 따라서 매핑을 위해 변환 과정이 필요합니다.

변환 예시

OS TID: 9091 (10진수)
Hex TID: 0x2383 (16진수)

변환 명령어

# 쉘에서 바로 변환하기 (예: 9091 -> 2383)
printf '%x\n' 9091

3. 스레드 덤프 생성 및 분석 (Thread Dump)

현재 JVM의 상태를 스냅샷으로 남기기 위해 스레드 덤프를 생성합니다.

덤프 생성 (Kill -3)

kill -3 시그널은 프로세스를 종료하지 않고 표준 출력(stdout)이나 로그 파일로 스레드 정보를 출력합니다.

kill -3 [PID]

IBM JDK (WebSphere): javacore.YYYYMMDD.HHMMSS.pid.txt 파일 생성
Oracle/Open JDK: catalina.out 또는 지정된 로그 파일에 출력

로그 매핑 분석

생성된 덤프 파일에서 앞서 변환한 16진수 값(예: 0x2383)을 검색합니다. IBM JDK의 경우 nid(Native ID) 또는 native_thread_id 항목과 매칭됩니다.

/* Javacore 예시 */
"WebContainer : 5" (TID:0x12345600, sys_thread_t:0x789abc00, state:R, native ID:0x2383) prio=5
    at com.example.MyClass.infiniteLoop(MyClass.java:45)
    at ...

분석 포인트:

16진수 ID로 검색하여 해당 스레드를 찾습니다.
해당 스레드의 상태(Runnable, Waiting 등)를 확인합니다.
Stack Trace를 통해 현재 어떤 코드(메소드)가 실행 중인지 파악하여 병목 지점을 수정합니다.

Next Step:
주기적인 모니터링이 필요하다면 top -H와 jstack을 결합한 쉘 스크립트를 작성하여, CPU 임계치 초과 시 자동으로 덤프를 남기도록 자동화해 보십시오.

Read Log →

#JBoss

[JBoss EAP 6] CLI 기반 패치 적용(Apply) 및 롤백(Rollback) 완벽 가이드

JBoss EAP 6 환경에서 Management CLI(jboss-cli)를 사용하여 보안 패치나 버그 픽스를 적용(Apply)하고, 문제 발생 시 이전 상태로 되돌리는 롤백(Rollback) 절차를 정리합니다. 패치 이력 관리와 설정 초기화 옵션에 대한 이해가 필수적입니다.

0. 배경 지식 (Context)

JBoss EAP 6의 패치 시스템은 누적(Cumulative) 방식과 단일(One-off) 방식으로 나뉩니다. 패치를 적용하면 내부적으로 .installation 디렉토리에 변경 내역이 저장되며, 이를 통해 언제든 이전 시점으로 복원할 수 있습니다.

Test Environment

OS: Windows 10 (Linux 명령어 포함)
Middleware: JBoss EAP 6.4
Patch File: jboss-eap-6.4.19-patch.zip

1. 패치 적용 (Patch Apply)

패치 파일을 다운로드한 후, JBoss가 가동된 상태(또는 Embed 모드)에서 CLI를 통해 적용합니다.

명령어 구문

# 기본 구문
patch apply [패치파일_경로]

OS별 실행 예시

Linux

$JBOSS_HOME/bin/jboss-cli.sh --connect
[standalone@localhost:9999 /] patch apply /was/img/fix/jboss-eap-6.4.19-patch.zip

Windows

%JBOSS_HOME%\bin\jboss-cli.bat --connect
[standalone@localhost:9999 /] patch apply F:\app\was\jboss-eap-6.4.19-patch.zip

Note: 패치 적용 후에는 변경된 모듈을 로드하기 위해 반드시 서버를 재기동(Restart)해야 합니다.

2. 패치 이력 확인 (Verification)

패치가 정상적으로 적용되었는지, 혹은 롤백을 위해 돌아갈 시점(ID)을 확인해야 합니다.

CLI에서 확인

# 패치 정보 조회
[standalone@localhost:9999 /] patch history

# 상세 정보 조회
[standalone@localhost:9999 /] patch info

파일 시스템에서 확인

JBoss 설치 경로 내의 숨김 폴더를 통해서도 확인 가능합니다.

경로: {JBoss_HOME}/.installation/patches

3. 패치 롤백 (Patch Rollback)

패치 적용 후 애플리케이션에 문제가 생겼다면 즉시 이전 상태로 되돌려야 합니다.

사전 준비: Patch ID 확인

롤백할 대상 ID를 알아야 합니다. patch history 명령어로 가장 최근에 적용된 패치 ID를 확인하십시오.

롤백 명령어

# 구문
patch rollback --patch-id=[PATCH_ID] --reset-configuration=[TRUE|FALSE]

핵심 옵션 설명 (--reset-configuration)

TRUE (권장): 패치 적용 시 변경되었던 설정 파일(standalone.xml 등)도 패치 이전 상태로 되돌립니다.
FALSE: 설정 파일은 현 상태를 유지하고 모듈(Jar)만 롤백합니다. 설정 충돌로 인해 서버 기동이 실패할 수 있으므로 주의해야 합니다.

실행 예시

# 설정까지 완벽하게 이전으로 복구
[standalone@localhost:9999 /] patch rollback --patch-id=CP19 --reset-configuration=true

4. 관리 콘솔(GUI)을 이용한 방법

CLI 사용이 어렵다면 웹 관리 콘솔에서도 동일한 작업을 수행할 수 있습니다.

접속: http://localhost:9990/console
메뉴: 상단 Patching 탭 선택
작업: 패치 마법사를 통해 파일 업로드 및 적용 (롤백 기능 포함)

JBoss Management Console Patching Screen

[그림] JBoss 관리 콘솔의 패치 관리 화면

Next Step:
패치 작업 전에는 만약을 대비해 standalone 또는 domain 디렉토리 전체를 압축하여 별도로 백업해두는 것을 강력히 권장합니다.

Read Log →

#WebSphere

[WebSphere] 디렉토리 리스팅(Directory Listing) 제거 및 보안 설정 (directoryBrowsingEnabled)

웹 서버가 특정 디렉토리 내의 파일 목록을 브라우저에 노출하는 '디렉토리 리스팅' 취약점을 해결하기 위한 WebSphere 설정 가이드입니다. 애플리케이션 레벨(xml) 수정 방식과 관리 콘솔(Admin Console)을 통한 전역 설정 방식을 다룹니다.

0. 배경 및 원인 (Context)

디렉토리 리스팅이 활성화되어 있으면 공격자가 서버의 디렉토리 구조와 파일 목록(백업 파일, 소스 코드 등)을 파악할 수 있어 2차 공격의 빌미가 됩니다.

WebSphere는 정적 파일 처리를 위한 fileServingEnabled 속성과 목록 노출을 위한 directoryBrowsingEnabled 속성을 가지고 있으며, 이를 적절히 제어해야 합니다.

Test Environment

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

1. Method A: 애플리케이션 설정 파일 수정

개별 애플리케이션 단위로 설정을 적용할 때 사용합니다. WAR/EAR 파일 내부의 IBM 확장 설정 파일을 직접 수정합니다.

설정 파일 대상

WAS v7.0 이상: ibm-web-ext.xml
WAS v6.1 이하: ibm-web-ext.xmi (Legacy)

설정 내용 (ibm-web-ext.xml)

enable-directory-browsing 속성을 false로 명시합니다.

<?xml version="1.0" encoding="UTF-8"?>
<web-ext
    xmlns="http://websphere.ibm.com/xml/ns/javaee/web-ext/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee/web-ext/1.0 http://websphere.ibm.com/xml/ns/javaee/web-ext/1.0/web-ext.xsd">

    <!-- 정적 파일 서빙 활성화 (이미지, HTML 등) -->
    <enable-file-serving value="true"/>
    
    <!-- 핵심: 디렉토리 리스팅 비활성화 -->
    <enable-directory-browsing value="false"/>

</web-ext>

2. Method B: 웹 컨테이너(Web Container) 전역 설정

WAS 관리 콘솔에서 서버 단위로 속성을 추가하여 제어하는 방식입니다. 애플리케이션을 재배포하지 않고 설정을 변경할 수 있어 운영 환경에서 선호됩니다.

설정 경로

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

주요 속성 값

아래 속성을 새로 작성(New)하여 추가합니다.

이름 (Name)	값 (Value)	설명
directoryBrowsingEnabled	false	디렉토리 목록 조회 기능을 비활성화합니다. (보안 필수)
fileServingEnabled	true	WAS가 정적 파일(html, img 등)을 처리할지 여부입니다. (false 설정 시 정적 파일 처리가 불가할 수 있음)

참고: fileServingEnabled를 false로 설정하면 디렉토리 리스팅도 차단되지만, WAS가 이미지나 CSS 같은 정적 리소스를 전혀 제공하지 않게 되므로 주의가 필요합니다. 일반적으로는 directoryBrowsingEnabled만 false로 설정합니다.

3. 검증 (Verification)

설정 적용 후 WAS 인스턴스를 재기동합니다.
브라우저에서 index.html이 없는 디렉토리 경로(예: http://domain/images/)로 접속합니다.
403 Forbidden 에러가 발생하면 보안 설정이 정상적으로 적용된 것입니다.

Read Log →

#apache#SSL

[OpenSSL/Apache] 사설 인증서(Self-Signed Certificate) 생성 및 적용 완벽 가이드

개발 및 테스트 환경의 HTTPS 구현을 위해 OpenSSL로 사설 인증서를 생성하는 방법을 정리합니다. 실무에서 혼동하기 쉬운 Key, CSR, CRT 파일의 정확한 역할 정의부터, 개인키 패스워드 제거 및 Apache 적용까지의 전체 프로세스를 다룹니다.

0. 배경 지식: 인증서 파일의 종류와 역할

SSL 인증서 발급 과정은 개인키 생성 → 인증 요청(CSR) → 인증서 발급(CRT)의 순서로 진행됩니다. 각 단계에서 생성되는 파일의 역할을 명확히 이해해야 합니다.

1. Private Key (.key):
- 서버가 갖는 비밀 열쇠입니다. 데이터를 암호화/복호화하는 핵심 파일로, 절대 외부로 유출되어서는 안 됩니다.
- 이 키를 분실하면 인증서를 재발급받아야 합니다.
2. CSR (.csr - Certificate Signing Request):
- 인증 기관(CA)에 "내 인증서를 만들어 달라"고 보내는 신청서입니다.
- 공개키(Public Key) 정보와 도메인, 회사 정보(DN)가 포함되어 있습니다.
3. Certificate (.crt):
- 최종적으로 발급된 인증서(신분증)입니다.
- CSR 내용을 바탕으로 CA(혹은 본인)가 전자 서명을 한 파일이며, 클라이언트(브라우저)에게 전송됩니다.

Test Environment

OS: CentOS 7.2
Web Server: Apache HTTP Server
Tool: OpenSSL

1. 개인키(Private Key) 생성

가장 먼저 모든 암호화 통신의 기반이 되는 개인키를 생성합니다.

1) 암호화된 개인키 생성

des3 알고리즘을 사용하여 2048비트 길이의 RSA 키를 생성합니다. 이때 설정하는 패스워드(Pass Phrase)는 키를 보호하기 위한 장치입니다.

[root@web01 test]# openssl genrsa -des3 -out test.vn.key 2048

Generating RSA private key, 2048 bit long modulus
..........................+++
e is 65537 (0x10001)
Enter pass phrase for test.vn.key: [패스워드 입력]
Verifying - Enter pass phrase for test.vn.key: [패스워드 확인]

2) 개인키 패스워드 제거 (필수 권장)

패스워드가 걸린 키를 웹 서버에 그대로 적용하면, 서버가 재기동될 때마다 관리자가 매번 패스워드를 입력해야 합니다. 자동 운영을 위해 패스워드를 제거한 키를 다시 생성합니다.

# 1. 원본 키 백업
cp test.vn.key test.vn.key.orig

# 2. 패스워드가 제거된 키 생성 (덮어쓰기)
openssl rsa -in test.vn.key.orig -out test.vn.key

# 결과 메시지
Enter pass phrase for test.vn.key.orig: [기존 패스워드 입력]
writing RSA key

2. 인증 요청서(CSR) 생성

생성된 개인키(.key)를 바탕으로 인증서 발급 신청서(.csr)를 작성합니다.

CSR 생성 명령어

openssl req -new -key test.vn.key -out test.vn.csr

주요 입력 정보 (DN: Distinguished Name)

명령 실행 후 입력해야 할 정보입니다. 다른 정보는 임의로 입력해도 되지만, Common Name은 반드시 정확해야 합니다.

Country Name: 국가 코드 (예: KR, VN)
State / Locality: 지역 정보 (예: Seoul)
Organization: 회사명/부서명 (예: IT Team)
Common Name (CN): 서비스 도메인 주소 (가장 중요! 예: *.test.vn)

Note: 추가 정보인 'Challenge password' 등은 입력하지 않고 Enter를 눌러 넘어가도 무방합니다.

3. 사설 인증서(CRT) 생성 (Self-Signing)

우리는 공인 인증 기관(VeriSign 등)이 없으므로, 생성한 CSR에 내 개인키로 직접 서명(Self-Sign)하여 인증서(CRT)를 만듭니다.

인증서 생성

유효기간을 365일로 설정하여 최종 인증서를 생성합니다.

# -req : CSR을 입력받음
# -signkey : 스스로 서명할 키 지정
openssl x509 -req -days 365 -in test.vn.csr -signkey test.vn.key -out test.vn.crt

# 성공 시 출력 메시지
Signature ok
subject=/C=VN/ST=Hanoi/L=lotte/O=admin/OU=admin/CN=*.test.vn
Getting Private key

최종 파일 확인

작업이 완료되면 다음 3개의 파일이 있어야 합니다.

test.vn.key: 개인키 (패스워드 제거됨, 서버 설정에 사용)
test.vn.crt: 인증서 (서버 설정에 사용)
test.vn.csr: 신청서 (발급 완료 후에는 불필요)

4. Apache 설정 및 검증

생성된 키와 인증서를 Apache 설정 파일(httpd.conf 또는 ssl.conf)에 등록하여 HTTPS를 활성화합니다.

설정 적용

# SSL 엔진 활성화
SSLEngine on

# 1. 인증서 파일 경로 지정 (.crt)
SSLCertificateFile /etc/httpd/conf/ssl/test.vn.crt

# 2. 개인키 파일 경로 지정 (.key)
SSLCertificateKeyFile /etc/httpd/conf/ssl/test.vn.key

검증 (Verification)

Apache를 재기동하고 브라우저로 접속해 봅니다. 패스워드를 묻지 않고 기동되어야 정상입니다.

재기동: systemctl restart httpd
브라우저 접속: https://test.vn

주의 (Warning):
사설 인증서는 브라우저가 신뢰하는 기관(CA) 목록에 없으므로, 접속 시 "주의 요함" 또는 "안전하지 않음" 경고가 뜨는 것이 정상입니다. 테스트 환경에서는 예외를 추가하여 진행하면 됩니다.

Read Log →

#JBoss

[JBoss/Apache] mod_cluster 연동 완벽 가이드: 동적 클러스터링 및 멀티캐스트 설정

JBoss EAP 6와 Apache HTTP Server를 mod_cluster 모듈을 사용하여 연동하는 방법을 정리합니다. 정적인 설정 없이도 WAS의 추가/삭제를 자동으로 감지하는 동적 클러스터링을 구현하며, 멀티캐스트(Advertise) 설정을 중심으로 다룹니다.

0. 사전 준비 (Prerequisites)

OS: Windows 10 (테스트 환경)
Web Server: Apache 2.2.x (JBoss EWS 포함 버전 권장)
Middleware: JBoss EAP 6.4.x

버전 호환성 주의: Apache 버전에 맞는 mod_cluster 모듈(.so)을 사용해야 합니다. JBoss EWS(Enterprise Web Server) 패키지를 사용하면 이미 최적화된 모듈이 포함되어 있습니다.

1. Apache 설정 (Web Server)

Apache에 mod_cluster 관련 모듈을 로드하고, JBoss가 보낸 멀티캐스트 신호를 수신할 수 있도록 설정합니다.

1) 필수 모듈 복사

JBoss EAP 설치 경로에 포함된 mod_cluster 관련 모듈(.so)을 Apache의 modules 디렉토리로 복사합니다.

원본 위치: [EAP_HOME]/modules/system/layers/base/native/lib64/httpd/modules
복사할 파일:
- mod_advertise.so
- mod_manager.so
- mod_proxy_cluster.so
- mod_slotmem.so

2) mod_cluster.conf 작성

httpd.conf에서 include 할 설정 파일을 작성합니다. 핵심은 VirtualHost 내의 ServerAdvertise On 설정입니다.

# 필수 모듈 로드 (순서 중요)
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so

# 공유 메모리 파일 위치 지정
MemManagerFile "C:/Apache/logs/mod_cluster"


  # JBoss 상태 관리 및 Advertise 수신 포트
  Listen 6666
  
    
      Order deny,allow
      Deny from all
      Allow from 127.0.0.1  # 보안상 로컬 접근만 허용 권장
    
    
    # 멀티캐스트 광고 활성화 (핵심)
    ServerAdvertise on
    EnableMCPMReceive

    # 관리 콘솔 URL
    
      SetHandler mod_cluster-manager
      Order deny,allow
      Allow from all

2. JBoss 설정 (Middleware)

JBoss가 기동될 때 자신의 정보를 멀티캐스트로 전파하거나, 프록시(Apache) 리스트를 받아오도록 설정합니다.

1) Instance ID 설정 (domain.xml)

Sticky Session을 위해 각 서버 인스턴스에 고유한 ID를 부여해야 합니다. ${jboss.server.name} 변수를 사용하면 편리합니다.

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="${jboss.server.name}" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
    ...
</subsystem>

2) 소켓 바인딩 (Socket Binding) - 멀티캐스트 주소

동일 네트워크 내에 여러 JBoss 클러스터가 존재할 경우 혼선을 방지하기 위해 멀티캐스트 주소나 포트를 변경해야 합니다.

domain.xml 수정 (socket-binding-group):

<socket-binding-group name="full-ha-sockets" default-interface="public">
    
    ...
</socket-binding-group>

Tip: XML을 수정하지 않고 기동 시 파라미터(System Property)로 주소를 변경할 수 있습니다.
-Djboss.modcluster.multicast.address=224.10.1.1

3. 검증 및 테스트

설정 완료 후 Apache -> JBoss 순서로 기동합니다.

1) Apache 관리 콘솔 접속

브라우저에서 http://[Apache_IP]:6666/mod_cluster_manager 로 접속합니다.

정상: 하단에 연결된 JBoss Node(Node Name, IP, Port) 리스트가 나타납니다.
실패: 리스트가 비어있다면 멀티캐스트 통신이 방화벽에 막혀있거나, Advertise 설정이 잘못된 것입니다.

2) 클러스터링 동작 확인

애플리케이션 호출 시 세션이 유지되는지 확인하고, 한 쪽 노드를 셧다운 시켰을 때 Failover가 일어나는지 테스트합니다.

[그림] mod_cluster 매니저 화면 (노드 인식 성공)

Next Step:
멀티캐스트 사용이 불가능한 클라우드 환경이라면, mod_cluster 설정을 TCP 유니캐스트(Proxy List 지정 방식)로 변경하여 구성하는 방법을 검토해 보십시오.

Read Log →

#JBoss

[JBoss EAP 6] Windows Service 등록 가이드 (service.bat install)

Windows 환경에서 JBoss EAP 6를 백그라운드 서비스로 등록하여, 시스템 부팅 시 자동으로 시작되도록 설정하는 방법을 정리합니다. JBoss Native 패키지에 포함된 service.bat 스크립트를 사용합니다.

0. 사전 준비 (Prerequisites)

서비스 등록 작업을 수행하기 위해 관리자 권한(Run as Administrator)으로 실행된 명령 프롬프트(CMD)가 필요합니다.

시스템 환경 변수 설정

JBoss가 서비스로 구동될 때 참조할 필수 변수를 시스템 환경 변수에 등록해야 합니다.

JBOSS_HOME: JBoss EAP 6 설치 디렉토리 (예: C:\jboss-eap-6.4)
NOPAUSE: 값을 1로 설정.
(※ 중요: 이 설정이 없으면 서비스 종료 시 배치 스크립트가 "Press any key..." 상태로 대기하여 서비스가 정상적으로 멈추지 않는 문제가 발생합니다.)

1. 서비스 설치 스크립트 위치

JBoss EAP 6는 Windows 서비스 등록을 위한 Native 유틸리티를 내장하고 있습니다. 해당 경로로 이동합니다.

:: 경로 이동 (설치 환경에 따라 경로가 다를 수 있음)
cd %JBOSS_HOME%\modules\system\layers\base\native\sbin

:: 파일 확인
dir service.bat

2. 서비스 등록 (Install Command)

service.bat install 명령어를 사용합니다. 운영 모드(Standalone / Domain)에 따라 옵션이 다릅니다.

Case A: Standalone Mode (단독 인스턴스)

가장 일반적인 구성입니다. 로그 레벨을 지정하여 설치합니다.

service.bat install /loglevel INFO

Case B: Domain Mode (도메인 구성)

도메인 컨트롤러(Domain Controller)와 연결해야 하므로 컨트롤러 정보가 필요합니다.

:: 기본 구문
service.bat install /controller [Host:Port] /host [HostName] /loglevel INFO

:: 사용 예시 (로컬이 마스터인 경우)
service.bat install /controller localhost:9990 /host master /loglevel INFO

주요 옵션 설명

옵션	설명
`/name`	서비스 이름 지정 (기본값: JBossEAP6)
`/desc`	서비스 설명 지정
`/serviceuser`	서비스를 실행할 Windows 계정 (DOMAIN\User)
`/servicepass`	실행 계정의 암호

3. 등록 확인 및 제어 (Verification)

설치가 완료되면 Windows 서비스 관리자에서 확인할 수 있습니다.

실행 창(Win+R) > services.msc 입력.
"JBoss Enterprise Application Platform 6" 서비스를 찾습니다.
서비스를 시작(Start) 하고, 상태가 '실행 중'으로 바뀌는지 확인합니다.
브라우저로 JBoss 관리 콘솔이나 메인 페이지에 접속하여 실제 구동 여부를 체크합니다.

4. 서비스 삭제 (Uninstall)

설정을 변경하거나 경로를 바꿀 경우, 기존 서비스를 삭제하고 다시 등록해야 합니다.

:: 서비스 중지 (먼저 수행 필수)
service.bat stop

:: 서비스 삭제
service.bat uninstall

주의: 서비스 삭제 후 services.msc 목록에 잔상이 남아있다면, 윈도우를 재부팅하거나 관리자 권한 CMD에서 sc delete [서비스명]을 강제로 수행해야 할 수 있습니다.

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 →