WebSphere Application Server & Liberty

 View Only

WebSphere Automation "How To" Series #23 : How to update all servers vulnerable to a specific fix using APIs

By Brian Hanczaryk posted Mon April 03, 2023 10:30 AM

  

WebSphere Automation "How To" Series #23 : How to update all servers vulnerable to a specific fix using APIs

Previous blogs in this WebSphere Automation "How To" series :
WebSphere Automation "How To" Series #1 : How to get WebSphere Automation UI URL 
WebSphere Automation "How To" Series #2 : How to specify user roles and permissions 
WebSphere Automation "How To" Series #3 : How to configure WebSphere Automation with an Enterprise LDAP 
WebSphere Automation "How To" Series #4 : How to register WebSphere Application Server traditional servers using configuretWasUsageMetering.py script 
WebSphere Automation "How To" Series #5 : How to register WebSphere Liberty servers 
WebSphere Automation "How To" Series #6 : How to configure email server and email addresses for notifications 
WebSphere Automation "How To" Series #7 : How to setup Instana to send alerts to WebSphere Automation 
WebSphere Automation "How To" Series #8 : How to setup secure access to Linux or UNIX servers 
WebSphere Automation "How To" Series #9 : How to trigger a memory leak health investigation when used heap is over 80 percent 
WebSphere Automation "How To" Series #10 : How to view WebSphere Automation REST APIs using Swagger UI
WebSphere Automation "How To" Series #11 : How to get and delete assets using APIs
WebSphere Automation "How To" Series #12 : How to get security bulletins using APIs
WebSphere Automation "How To" Series #13 : How to retrieve a list of vulnerabilities using APIs
WebSphere Automation "How To" Series #14 : How to get CVE impact summaries using APIs 
WebSphere Automation "How To" Series #15 : How to install interim fixes and fix packs using WebSphere Automation UI
WebSphere Automation "How To" Series #16 : How to retrieve and delete installations using APIs
WebSphere Automation "How To" Series #17 : How to retrieve fixes using APIs 
WebSphere Automation "How To" Series #18 : How to register WebSphere Liberty servers running in containers 
WebSphere Automation "How To" Series #19 : How to install WebSphere Automation to Red Hat® OpenShift® Local
WebSphere Automation "How To" Series #20 : How to retrieve all fix names using APIs
WebSphere Automation "How To" Series #21 : How to list all registered hostnames and versions using APIs
WebSphere Automation "How To" Series #22 : How to list all servers vulnerable to a specific fix using APIs

This post will focus on how to update all servers vulnerable to a specific fix using APIs.

The WebSphere Automation REST APIs are technology preview in this release.  IBM Docs directly related to WebSphere Automation REST API are located at https://www.ibm.com/docs/en/ws-automation?topic=technology-preview-viewing-rest-api.  

To utilize WebSphere Automation REST APIs through CLI, we need the URL and token values.  IBM Docs https://www.ibm.com/docs/en/ws-automation?topic=technology-preview-viewing-rest-api shows the following details on how to acquire the necessary token value for an authorized user profile.

Get the password for the administrator account.

oc -n WSA_INSTANCE_NAMESPACE get secret admin-user-details -o jsonpath='{.data.initial_admin_password}' | base64 -d && echo

WSA_INSTANCE_NAMESPACE is the namespace of the instance where WebSphere Automation is installed.

Replace <password> in the following command with the value returned from the command above, and use the correct value for WSA_INSTANCE_NAMESPACE.

curl -k -X POST -H 'Content-Type: application/json' -d '{"username":"admin","password":"<password>"}' https://$(oc get route -n WSA_INSTANCE_NAMESPACE -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/icp4d-api/v1/authorize | jq -r .token

To get the necessary URL value to use in the curl commands, we can append a prefix of 'https://' and a suffix of '/websphereauto/secvul/apis' around the result of the following command.

oc get route -n WSA_INSTANCE_NAMESPACE -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}'

To set a URL variable on Linux, we could use the following

URL=https://$(oc get route -n WSA_INSTANCE_NAMESPACE -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/websphereauto/secvul/apis

Now that we've captured the token and URL values, we can show how to update all servers vulnerable to a specific fix.

For this example, we've registered several WebSphere Application Server traditional servers with v8 ranging from v8.5.5.15 through v8.5.5.22 and v9 ranging from v9.0.5.4 through 9.0.5.14.   

Security_1



As referenced in the previous article, WebSphere Automation "How To" Series #20 : How to retrieve all fix names using APIs  we can find all the fix names applicable to the environment.  

As an example for CVE-2022-22477, WebSphere Application Servers for V9.0.0.0 through V9.0.5.13 in the environment would result in the fix name 9.0.0.0-WS-WASProd-IFPH50116 being applicable.  WebSphere Application Servers for V8.5.0.0 through V8.5.5.22 in the environment would result in the fix name 8.5.5.0-WS-WASProd-IFPH50116 being applicable.

We can use the following shell script to update all traditional WebSphere Application Servers vulnerable to a specific fix name.  This is just one example of how APIs and scripting can be utilized to achieve this result.  The following is an example shell script. 

[root@XXX.ibm.com Demo]# cat updateServersVulnerableToFix.sh 
#!/bin/sh
if [ $# -lt 1 ]
then
 echo "Must pass in fix name"
 exit 99
fi

########## Begin List HostName and Version
rm -f temphostNameAndVersion.txt
curl -s -k -X GET "${URL}/assets?limit=100&type=traditional" -H "accept: application/json" -H "Authorization: Bearer $TOKEN" | jq . > json_get_assets.json
echo

rm -f hostName.txt
rm -f version.txt
grep hostName json_get_assets.json | cut -d '"' -f4 > hostName.txt
grep version json_get_assets.json | grep -v description | cut -d '"' -f4 > version.txt

X=1
XEND=$(wc -l version.txt | awk '{print $1}')

while [ $X -le $XEND ]
do
 HN=$(awk 'NR=='${X} hostName.txt)
 V=$(awk 'NR=='${X} version.txt)
 echo "$HN $V" >> temphostNameAndVersion.txt
 X=`expr $X + 1`
done

rm -f json_get_assets.json
rm -f hostName.txt
rm -f version.txt

cat temphostNameAndVersion.txt | sort -k 2 > hostNameAndVersion.txt
rm -f temphostNameAndVersion.txt
########## End List HostName and Version

########## Begin determination if server is impacted and update
rm -f temp.txt
curl -s -k -X GET "${URL}/fixes?limit=1&name=${1}" -H "accept: application/json" -H "Authorization: Bearer $TOKEN" | jq . > temp.txt
clear

FIXID=$(cat temp.txt | awk 'NR==7' | cut -d '"' -f4)
echo $FIXID 

rm -f impacted.txt
touch impacted.txt
P=0
while read line
do
 Z=${line:1:17}

 if [ "$Z" == "," ]
 then 
  P=0
 fi

 if [ $P -eq 1 ]
 then 
  Y=$(echo "$line" | cut -d '"' -f2)
  echo "$Y" >> impacted.txt
 fi

 if [ "$Z" == "appliesToVersions" ]
 then 
  P=1
 fi

done < temp.txt
echo

while read line
do
 HN=$(echo $line | awk '{print $1}')
 VER=$(echo $line | awk '{print $2}')
 while read atv
 do
  if [ "$VER" == "$atv" ]
  then 
   rm -f temp.txt
   curl -s -k -X GET "${URL}/assets?limit=1&hostName=${HN}&type=traditional" -H "accept: application/json" -H "Authorization: Bearer $TOKEN" | jq . > temp.txt
   ASSETID=$(cat temp.txt | awk 'NR==7' | cut -d '"' -f4)
  
   echo "name=${1}  ASSETID=${ASSETID}  FIXID=${FIXID}" 
   curl -s -k -X POST "${URL}/installations" -H "accept: */*" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d "{ \"name\": \"${1}\", \"type\": \"install\", \"assetIds\": [\"${ASSETID}\"], \"fixIds\": [\"${FIXID}\"], \"autoInstall\": true, \"backupNeeded\": false }"
  fi 
 done < impacted.txt
done < hostNameAndVersion.txt
########## End determination if server is impacted and update

rm -f temp.txt
rm -f hostNameAndVersion.txt
rm -f impacted.txt

The script gathers the list of hostnames and version, determines whether that server is impacted by the fix name specified and updates accordingly.  For this example script, in the event that more than one server on a WebSphere Installation is scheduled to have the fix installed, only the first API POST command will succeed and perform the installation.  All subsequent API POSTs will report a message stating that other fixes are being installed on the host.

You can find more IBM Docs related to WebSphere Automation at https://www.ibm.com/docs/en/ws-automation.

#WebSphereAutomation #WebSphere #automation 

Permalink