...

It is recommended to use cron in conjuction with find to periodically purge client logs. For example, to check for outdated logs every 24 hours and delet delete all logs older than 30 days add the following cron task

...

logs
---- gc-core.log.0
---- gc-core.log.1
---- gc-core.log.2.current

Mediasessions statistics logs

Since build 5.2.1883a current mediasessions statistics may be collected. The statistics may be logged to save it to a file when mediasession is closed.

The mediasessions statistics is logged to the /usr/local/FlashphonerWebCallServer/logs/stats/media-session-connection-stats.log file in CSV form

#{mediaSessionId}; {channels_not_writable}; {decodable_drops_old}; {incomplete_drops_old}; {decodable_drops_reset}; {incomplete_drops_reset}; {decodable_drops_pli}; {incomplete_drops_pli}; {data_packets_with_empty_payload}; {missed_h264_units}; {dropped_audio_data_packets}

Where

• mediaSessionId - mediasession id
• channels_not_writable - TCP channels not writable events count
• decodable_drops_old - H264 decodable frames dropped count
• incomplete_drops_old - H264 incomplete frames dropped count
• decodable_drops_reset - H264 decodable frames dropped before a new decoding point count
• incomplete_drops_reset - H264 incomplete frames dropped before a new decoding point count
• decodable_drops_pli - H264 decodable frames dropped on PLI receiving count
• incomplete_drops_pli - H264 incomplete frames dropped on PLI receiving count
• data_packets_with_empty_payload - data packets with empty payload sent to test a channel quality when TWCC is enabled count
• missed_h264_units - missed H264 units count, per mediasession
• dropped_audio_data_packets - audio packets dropped before passing them to server engine

The record example

f49f8cb0-dc52-11ee-81df-51ad589334c0; 0; 0; 7; 0; 0; 0; 10; 0; 443; 0

The statistics logging should be set up in log4j.properties file as follows

log4j.logger.MediaSessionConnectionStats=error, mediaSessionConnectionStatsAppender
log4j.additivity.MediaSessionConnectionStats=false
log4j.appender.mediaSessionConnectionStatsAppender=com.flashphoner.common.logging.NewLogForEachRunFileAppender
log4j.appender.mediaSessionConnectionStatsAppender.DatePattern='.'yyyy-MM-dd-HH
log4j.appender.mediaSessionConnectionStatsAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.mediaSessionConnectionStatsAppender.layout.ConversionPattern=%m%n
log4j.appender.mediaSessionConnectionStatsAppender.File=${com.flashphoner.fms.AppHome}/logs/stats/media-session-connection-stats.log

CVE-2021-44228 vulnerability

CVE-2021-44228 vulnerability in Apache log4j library cannot be exploited on WCS server. The logger can be configured via log4j.properties only, so attacker must have access to server file system. The vulnerability cannot be exploited via input fields etc. Let's check:

1. Use the URL https://log4shell.huntress.com/ to check the server. This page will generate an unique link to insert to a web page input fields

2, Open Two Way Streaming example page on demo server https://demo.flashphoner.com:8888/client2/examples/demo/streaming/two_way_streaming/two_way_streaming.html, click Connect and insert the test link to stream name fields. Publish and play a stream:

Image Added

3. Open a special link to view test results. If vulnerability is exploited, IP address and Date/Time columns will show connections from tested server

Image Added

As test shows, the CVE-2021-44228 vulnerability cannot be exploited in latest WCS build 5.2.1109

Under the hoods: why WCS is not vulnerable

WCS uses Apache log4j 1.2.17. This old version does not support JDNI feature which is added since log4j 2.0-beta9. Therefore, CVE-2021-44228 vulnerability cannot be exploited in WCS.