Latest Posts

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

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 반영 결과

정보 노출 테스트 결과

WAS | WebSphere when native_stdout file capacity continues to increase

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

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

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

WEB | Converting p12 to kdb files using gskcmd

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"

WAS | WebSphere 보안 취약점 관련 access Log 설정

WebSphere 보안 취약점 관련 access Log 설정


Test Environment

  • Test Version : WebSphere v8.5

NCSA access Log and HTTP error log set up

HTTP Access

  1. 전체 로그 설정
  • Click Servers > Server Types > WebSphere application servers > server_name > NCSA access and HTTP error logging.
  • Select Enable logging service at server start-up.
  • Ensure that Enable access logging is selected.
  1. 컨테이너별 로그 설정 part 1
  • Application servers > server1 > Web container transport chains > HttpQueueInboundDefault > HTTP inbound channel (HTTP_2)
  • Select Enable logging.
  1. 컨테이버별 로그 설정 part 2
  • Application servers > server1 > Web container transport chains > WCInboundDefault > HTTP inbound channel (HTTP_2)

로그 포맷 변경시

참조 링크

https://www.ibm.com/support/knowledgecenter/ko/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/ttrb_access_logging.html

설정 위치

  • Go to the custom properties page for the wanted transport chain. Click Servers > Server Types > WebSphere application servers > server_name > Web Container Settings > Web container transport chains > chain_name > HTTP_channel_name > Custom properties.

  • Costum properties

    • key

    accessLogFormat

    • value

    %h %u %t "%r" %s %b %D "%{Referer}i" "%{User-agent}I" %{JESSIONID}C
    %h %i %u %t "%r" %s %b %D

SSL | WebSphere TLS Clearing issues

WebSphere TLS Clearing issues

Is TLS v1.2 supported in WebSphere Full Profile 7.0, 8.0, 8.5? What's minimum fix pack?

Answer: TLsv1.2 Suppport on V7.0.0.23 on wards TLsv1.2 Support on 8.0.0.3 onwards and 8.5.0.0.

  • TLS v1.2 supported in WebSphere with following JDK version. 7.0.0.23 comes JDK version as follows and TLSv1.2 supported SDK 6
    (32-bit) pap3260sr10fp1-20120321_01(SR10 FP1)
    (64-bit) pap6460sr10fp1-20120321_01(SR10 FP1)​

  • 8.0.0.3 comes with JDK version follows and TLSv1.2 supported
    SDK 6.0.1 (J9 2.6)
    (32-bit) pap3260_26sr1fp1-20120309_01(SR1 FP1)
    (64-bit) pap6460_26sr1fp1-20120309_01(SR1 FP1)

  • 8.5 comes with JDK version follows and TLSv1.2 supported
    SDK 6.0.1 (J9 2.6)
    (32-bit) pap3260_26sr2ifix-20120419_02(SR2+IV19661)
    (64-bit) pap6460_26sr2ifix-20120419_02(SR2+IV19661)

This change allows TLS 1.1 and 1.2 to be configured at the webserver plugin in 8.0 and later on distributed platforms.

  • TLS 1.1 and 1.2 is not supported on zOS at this time.
  • Despite this APAR being listed in 7.0 fixpacks, 7.0 does not support TLs1.1 and TLS1.2 due to the use of GSKit V7.

WAS

Click Security > SSL configurations CellDefaultSSLsetting , NodedefaultSSLsetting and any other SSLConfig

1. Select each SSL Configuration described above, then click Quality of protection (QoP) settings under Additional Properties.

2. On the **Quality of protection (QoP)** settings panel, select TLSv1.2 from the pull-down list in the box named Protocol. change the protocol to TLSV1.2

3. update ssl.client.props
This must be done for each **ssl.client.props** file under the following directories:
For Node example WAS_install\profiles\AppSrv01\properties
For DMGR example WAS_install\profiles\Dmgr01\properties

 **com.ibm.ssl.protocol=TLSv1.2**

4. stopNode.sh && stopManager.sh 

5. startManager.sh

6. syncNode.sh dmgrhostname dmgrsoapport -username userid -password password

7. startNode.sh

8. Click Protocol : openssl s_client -connect webspherehostname:9443 -tls1_2

WEB

update httpd.conf

VirtualHost
SSLProtocolEnable TLSv12
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11

Plg

Why do I receive a GSK_ERROR_SOCKET_CLOSED (gsk rc = 420) error, when WebSphere Application Server and IBM HTTP Server are configured to use TLSv1.2? Answer: you need to have StrictSecurity="true" in the plugin-cfg.xml for TLSv1.2 to work. More details see the following link

WAS | Liberty Core installUtility command

To use the Liberty installUtility command.


version : IBM Liberty Core 20.0.0.6 OS : CentOS 7.2


feature Search

# installUtility find {feature_name} --type=feature

feature Download

# installUtility Download {feature_name} --location={download_path} --acceptLicense

repositories

저장소 저장을 위해 repositories.properties 작성

properties file path ${wlp.install.dir}/etc/repositories.properties file.

# feature download path or featue zip path
local-rep.url=/SW/img/LibertyUtility

viewSettings

testConnection

저장소 연결 테스트

# installUtility testConnection default

fixpackCenter feature Download

wlp Info Center
feature fix

WAS | WebSphere v9.0.5.1 Basic install guide

WebSphere v9.0.5.1 Basic install guide


OS : CentOS 7 3.10.0-957.el7.x86_64

IM imcl install

tip. Check the package name simply {img_file}/Offerings

IM install

./imcl install com.ibm.cic.agent -repositories "/sw/img/im/repository.config" -installationDirectory "/sw/IBM/InstallationManager/eclipse" -sharedResourcesDirectory "/sw/IBM/IMShared" -acceptLicense -sP

In this guide, use the existing Installation Manager.

# cd /sw/IBM/InstallationManager/eclipse/tools

WebSphere install

./imcl install com.ibm.websphere.BASE.v90_9.0.5001.20190828_0616 -repositories "/sw/img/base" -installationDirectory "/sw/was/AppServer9" -sharedResourcesDirectory "/sw/IBM/IMShared" -acceptLicense -properties cic.selector.nl=ko -sP

tip. Starting with websphere version 9.0, Java installation should also proceed.

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

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

IBM HTTPServer install

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

#fix
./imcl install com.ibm.websphere.IHS.v90_9.0.5003.20200226_0941 -acceptLicense -installationDirectory "/sw/web/IHS9" -repositories "/sw/img/fixweb" -sP

Plugins install

./imcl install com.ibm.websphere.PLG.v90_9.0.5001.20190828_0616 com.ibm.java.jdk.v8_8.0.5041.20190924_1031 -repositories "/sw/img/plg","/sw/img/sdk"  -installationDirectory "/sw/web/Plugins9" -sharedResourcesDirectory "/sw/IBM/IMShared" -acceptLicense -sP

#fix
./imcl install com.ibm.websphere.PLG.v90_9.0.5003.20200226_0941 -acceptLicense -installationDirectory "/sw/web/Plugins9" -repositories "/sw/img/fixweb" -sP

version Info

  1. imcl listInstalledPackages
  2. {install_home}/bin/versionInfo.sh

이 블로그 검색

Popular Posts

WEB&&WAS

OS

Reviews