Issue:

Messaging Security Gateway (MSG) appliance is reporting the following alerts:

• crit eid.plinx.log.sel Battery ROMB Battery | Low | Asserted
• err eid.plinx.raid Raid is in Write-Through Mode, Performance will be degraded.

Resolution:

These alerts are related to the RAID battery relearning and are completely normal behaviour for the appliance.

Battery relearns occur every 90 days by Hardware default. During a battery relearn, the battery fully discharges and gains statistical information regarding its overall State of Health (SoH). When the battery charge drops below a charge threshold, the disk write-cache policy changes to Write-Through.

What does disk Write-Through mean? This means that the data writes occur twice (to Memory and Disk) to protect and preserve the data in the event of a critical hardware failure or disk failure.

The battery will fully discharge, and when the disk write-cache policy changes to Write-Through, the Appliance RAID is degraded and performance is affected. Any changes to hardware or something that will trigger an asserted failure (such as ROMB Battery failed (since it's discharged entirely)), will generate a PPS alert.

As the battery recharges, the disk write-cache policy changes to Write-back. As this is the normal state of the hardware, the alerts will cease as the battery is operational and the SoH is good.

As this happens every 90 days for each appliance where a RAID Controller is present, you should expect to see these alerts reoccur regularly. If the appliance doesn't recover (can be expected to happen in a few hours), open a support ticket.

Issue:

A mail targeted to multiple recipients returns with the message saying that "the following addresses had permanent fatal errors", followed by a list of all recipients. However when sending the same message to individual users it seems to work. It seems that if one recipient is invalid, all recipients get the same label, why is this happening?

When checking the message in Smart Search in the MSG Web UI, the MTA logs contains the following error:
relay=[], dsn=5.0.0, reply=550 5.1.1 User unknown, stat=Service unavailable

Resolution:

The entry from the MTA logs list a reply from a server relaying the mail to the final recipient, so the problem is not within MSG but coming from the relay server of the recipient.
This is something that the recipient needs to verify on their end. If the recipient causing these errors is a legit user, they might be missing from a user verification database on the receiving end and their relay server might be set up to reject messages where any of the recipients are unknown.

Issue:

Emails are blocked by the Messaging Security Gateway (MSG) or Protection Service for Email (PSE) maxsize firewall rule despite being seemingly smaller than the limit.

Resolution:

The maxsize firewall rule may include multiple criteria. Most likely one of the other criteria are being met by the message. Here is an example of the maxsize firewall rule criteria:

Message size greater than 52428800 Bytes
OR  Attachment count greater than 256
OR  Total Uncompressed Attachment size greater than 52428800 Bytes
OR  File count in archive greater than 256
OR  File depth in archive greater than 20

To check and modify the rule used in your appliance:

1. Log in to the MSG Web UI
2. Select the Email Protection-tab
3. Navigate to Email Firewall -> Rules using the left-side menu
4. Locate the rule called maxsize from the list of rules

• The settings of the rule can be checked directly from the list
• To modify the rule, click on Edit Rule, make the necessary changes and click Save changes

Issue:

Linux Security 64 failed to be installed successfully and the installation process is stuck at "Installing BaseGuard" stage

Resolution:

During the installation of Linux Security 64, it will connect to the Policy Manager Server and check for the latest database updates. If Policy Manager Server does not have the latest database updates and the internet connection is blocked for such update, then the installation of Linux Security 64 will fail. Therefore, it is important to enable the internet connection for Policy Manager Server so that the database update could be done successfully which contributes to the successful installation of Linux Security 64.

Other than that, make sure that the connection between Linux Security 64 and Policy Manager Server could be established successfully.

You could verify the connection to the Policy Manager Server is working successfully by using a web browser or command line as below.

In case of web browser:

1. Open any browser.

2. Enter the following URL with a hostname or IP address of Policy Manager Server.
    https://<name or IP address for the Policy Manager Server>:443

3. Check the result whether the following message is displayed.
    "If you see this message, Policy Manager Server is installed and is working fine."

In case of command line:

1. Run the following command on Terminal.
    curl –insecure https://<name or IP address for the Policy Manager Server>:443

2. Check the result whether the following message is displayed.
    "If you see this message, Policy Manager Server is installed and is working fine."

If you could see the message above, it means that the connection to the Policy Manager Server could be done successfully. 
If other message is displayed, you need to check your network or firewall settings as it is blocking the connection.

Issue:

Linux Security 64 failed to activate with error message "SELinux integration for F-Secure Linux Security 64 is supported only with the
'targeted' policy on this system (detected policy: '').

Installation is successful. 

Resolution:

Root cause is due to missing "SELINUXTYPE=targeted"

Example from /etc/selinux/config

# SELINUXTYPE= can take one of three two values:
#     targeted – Targeted processes are protected,
#     minimum – Modification of targeted policy. Only selected processes are protected.
#     mls – Multi Level Security protection.
SELINUXTYPE=targeted

Note that SELINUX can be any value, but SELINUXTYPE must be set to "targeted".

Reinstallation is required after fixing the value. 

1. Uninstall Linux Security 64
2. Remove Linux Security folders (rm -rf /opt/f-secure /etc/opt/f-secure /var/opt/f-secure)
3. Add SELINUXTYPE=targeted to the config file /etc/selinux/config
4. Reboot system (recommended)
5. Install Linux Security 64

Issue:

I launched a manual scan(fsanalyze) as a non-root user in Linux Security 64(LS64) and it fails with the following error:

fsanalyze: failed to connect to pmd:failed to connect to ctrl socket: /opt/f-secure/linuxsecurity/var/lspmd/run/socket: Permission denied

Resolution:

When a non-root user executes the fsanalyze command, “Permission denied” is output, the file will still be scanned by the fsanalyze tool.

Here is a sample output:

[azlaaz@ip-192-168-175-229 Desktop]$ /opt/f-secure/linuxsecurity/bin/fsanalyze --list test.txt
fsanalyze: failed to connect to pmd:failed to connect to ctrl socket: /opt/f-secure/linuxsecurity/var/lspmd/run/socket: Permission denied
test.txt: result=clean
 
Engine versions: F-Secure Corporation Aquarius/18.0.790/2021-08-25_02 F-Secure Corporation Hydra/6.0.391/2021-08-25_01 F-Secure Corporation FMLib/17.0.607.475  (cf1875a)/2020-04-07_01  fsicapd/2.0.202
 
1 files scanned

The impact of this error is that alerts (scan errors and detections) will not be sent to the Policy Manager and syslog. Therefore for example, if a non-root user scans an eicar file using the fsanalyze tool, the detection log will not be sent to syslog and Policy Manager. It will only be shown on the terminal for this non-root user to see.

The known issue is also being recorded in the LS64 changelog under the latest component update on 18 Aug.

Known Issues:
・Scanning files as a non-root user using fsanalyze command-line utility cause error message to be shown.
 

Issue:

Email messages are delivered but the sender gets an empty permerror email notification from MSG.

Resolution:

The PermError condition means the sender published SPF record could not be verified. Permerror are usually caused by an incorrect SPF syntax or format error in the SPF record.

You may advise the sender to ensure their SPF record is set up correctly and does not have any extra spaces or unrecognizable characters in the DNS TXT record.

To prevent the sender from getting the same message, please follow these instructions:

1. Logon to your MSG admin web user interface.
2. Click Email Protection tab.
3. Expand Email Authentication > SPF > Rules.
4. Click on the Edit Rule option of SPF Permanent Error.
5. Under Dispositions, untick the "Reply to sender based on detected language" check box.

By disabling the option, senders should not receive the e-mail notification. If you want to use that option, leave the check box ticked and write some message in the Subject and Message field.

Issue:

Linux Security 64 "Master-Switch" command cannot stop/start the process/service since after update, Linux Security 64 (12.0.222), BaseGuard (1.0.532) and FSBG (1.0.508).
This problem is not happening in PSB mode/Standalone mode.

Resolution:

This problem is happening due to policy setting in LS64.  

1. Login to Policy Manager.
2. Change "Allow users to unload products" to "Allowed always"
3. Deploy new policy to LS64.

Issue:

Linux Security 64: Installation failure with error "activate: No such file or directory" when mounted "/var/opt/f-secure" as separate filesystem

# bash f-secure-linuxsecurity/f-secure-linuxsecurity-installer
f-secure-linuxsecurity/f-secure-linuxsecurity-installer: line 68:
/opt/f-secure/linuxsecurity/bin/activate: No such file or directory
Failed to activate the product!

[df.txt]
/dev/mapper/cl-var                 2.0G  513M  1.5G   26% /var
/dev/mapper/cl-var_opt_f–secure   3.0G  164M  2.9G    6% /var/opt/f-secure

Resolution:

Mounting "/var/opt/f-secure directory" on a separate filesystem is not supported, thus failed to install Linux Security 64.
But alternatiely can consider to mount the whole "/var" directory on a separate filesystem, which is supported.
 

Issue:

How to check schedule scanning log message's "Severity" and "Facility"?

lspmd-start: alert [source=schedule scan]: path=/root/download/eicar.txt.malware; action=rename; infection=EICAR_Test_File
 

Resolution:

If you run journalctl with "-o verbose" you can see priority and facility for each log message.
For lspmd's log, you can run command below:
 

journalctl -o verbose -u f-secure-linuxsecurity-lspmd | egrep 'PRIORITY|FACILITY' | sort -u

Example:
[root@centos7test ~]# journalctl -o verbose -u f-secure-linuxsecurity-lspmd | egrep 'PRIORITY|FACILITY' | sort -u
    PRIORITY=6
    SYSLOG_FACILITY=3