THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4 and later

DISCUSSION

Log levels in EFT all default to the TRACE (INFO) setting, which is standard or typical logging. If you need more details in your logs, change the logging configuration to extended or verbose log level in logging.cfg (i.e., to DEBUG). This extended level of detail in your logs will help you pinpoint where the trouble lies.

For example, with the SSL logging level set to DEBUG, you would see whether the connection was accepted, and which protocol version, cipher, and key length were used in the connection:

DEBUG SSL <> - SSL connection accepted; protocol version = TLSv1.2, cipher = ECDHERSA-AES128-GCM-SHA256, key length = 128

Note: it is recommended that you only use verbose logging during debugging or troubleshooting. It will produce a large amount of data and quickly use up your processing speed and drive space.

Use the following example for logging SFTP information to set up a separate file appender for verbose logs, which should make data capture and analysis a bit more manageable.

1. Specify the following settings in the logging.cfg file:

log4cplus.appender.SFTPFileAppender=log4cplus::RollingFileAppender

log4cplus.appender.SFTPFileAppender.File=${AppDataPath}\EFT-SFTP-${COMPUTERNAME}.log
(This is the separate location where the logs will be saved.)

log4cplus.appender.SFTPFileAppender.MaxFileSize=20MB

log4cplus.appender.SFTPFileAppender.MaxBackupIndex=5

log4cplus.appender.SFTPFileAppender.layout=log4cplus::TTCCLayout

log4cplus.appender.SFTPFileAppender.layout.DateFormat=%m-%d-%y %H:%M:%S,%q

log4cplus.logger.SFTP=TRACE, SFTPFileAppender

log4cplus.additivity.SFTP=false

log4cplus.appender.SFTPFileAppender.filters.1=log4cplus::spi::StringMatchFilter

log4cplus.appender.SFTPFileAppender.filters.1.StringToMatch=Received SSH_MSG_KEXINIT

log4cplus.appender.SFTPFileAppender.filters.1.AcceptOnMatch=true

log4cplus.appender.SFTPFileAppender.filters.2=log4cplus::spi::StringMatchFilter

log4cplus.appender.SFTPFileAppender.filters.2.StringToMatch=Handling SSH_MSG_USERAUTH_REQUEST for user

log4cplus.appender.SFTPFileAppender.filters.2.AcceptOnMatch=true

log4cplus.appender.SFTPFileAppender.filters.3=log4cplus::spi::DenyAllFilter

2. After using verbose logging for few days (or however long is needed), copy the EFT-SFTP-*.log files to a new folder for processing. (You have to copy the log files to a separate folder for analysis because the PowerShell cannot open files that EFT is holding open.)
3. Run the attached PowerShell script (specific to this SFTP example) against those log files in that new folder from the last step to generate a CSV file with the results. Be sure to change the path in the script to the location in which you have created a new folder.

Analysis can be performed against the results easily in Excel.

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.2.1 and later

DISCUSSION

In this article, we explain how Workspaces licensing works for internal, external, and guest users, and how EFT Outlook Add-In invited guests use Workspaces licenses. 

Licensing Workspaces

Licenses are purchased per number of Workspaces owners, not the number of Workspaces created. For example, if you purchase a 25-seat license, 25 users can create Workspaces; there is no limit to the number of Workspaces each owner may possess. During the EFT 30-day trial, you can have up to 100 Workspaces owners. You can allow or deny Workspaces creation to specific users.

• If you are using an EFT version prior to 7.4.7, you should disallow the creation of Workspaces on Guest accounts to ensure that Workspaces license are available for internal users.
• In v7.4.7 and later, the ability to create Workspaces is disabled be default on the Guest Accounts Settings Template. Disabling creation of Workspaces on Guest Accounts ensures that Workspaces licenses are available for internal users. On the Connections tab, you can disable or enable the creation of Workspaces on the Guest Accounts Settings Template for all Guest accounts or on each Guest account individually.
• After a guest has been invited to join a Workspace--either from the WTC or the EFT Outlook Add-In--and has created an account and logged in, the guest account will appear (if so configured) in theGuest Users Settings Template. In EFT versions prior to 7.4.7, this account will consume a Workspaces licenses until you disallow the creation of Workspaces on that account or in the Settings Template.

Workspaces are viewed and created in the Web Transfer Client (WTC); therefore, if a user does not have access to the Web Transfer Client, the user cannot create or access a shared Workspace. If the user cannot access the WTC, the "plain text client" (PTC) appears when the user logs in.

Transactional Workspaces (via EFT Outlook Add-In)

A Transactional Workspaces is a Workspace that results from sending a file for pick up from the EFT Outlook Add-In.

• If you are using an EFT version prior to 7.4.7, you should disallow the create of Workspaces on Guest accounts to ensure that Workspaces license are available for internal users.

The recipient only has download permission on the file(s) received. Transactional Workspace participants cannot see each other and cannot subscribe to notifications.

A Transactional Workspace is different from normal Workspaces in that:

• Accepts anonymous access, if the administrator allows it and the owner/sender chooses.

• In the VFS, unregistered users will have an exclamation point on the anonymous-access folder. 

• Grants permission to download only

• Can't have participants added post creation

• Owner will have little power over it once created (but EFT Admins can delete it)

• Is private access, in that participants can't see each other and can't subscribe to notifications (although owner/sender can)

• Is represented in the EFT administration interface VFS tab using the Subject line and the sender's username

• Is represented differently in the WTC

• Content gets deleted when it expires

• Is more likely to have a shorter maximum expiration period than regular Workspaces

• Supports self-expiring, single-use file links, which are not supported in regular Workspaces

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT 7.4.7.15 and later

DISCUSSION

EFT v7.4.7.15, the Advanced Workflow Engine was udpated to a new version. In this new version, the SMTP server registry key was updated to the following:

[HKEY_LOCAL_MACHINE\Software\WOW6432Node\Automate\Automate 10\TaskService\Mail]

Values:

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT, v7.4.9

SYMPTOM

Workspaces Guest account is automatically disabled after administrator has re-enabled it.

When a new Workspace is created for a guest user, an expiration timer is set. After the timer has expired, the Guest account is disabled.

The EFT administrator can then re-enable that account. However, the expiration timer was not reset. Therefore, the Guest account is again disabled.

WORKAROUND

There is no workaround at this time, other than recreating the account. The timer reset issue is expected to be fixed in a subsequent release.

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.2 and later

QUESTION

Is calling a REST web service from AWE available in EFT Enterprise?

ANSWER

Yes. The ability to invoke a RESTful web service is included in the EFT Event Rules, documented in Invoke Web Server from URI Action. The fields in the action, such as Type, are only pre-populated if you provide a WSDL URI so that it can pull the various known values from the service description.

Keep in mind that if you’ve created, defined, or modified any variables in an AWE task, the variables and their values will be passed back to any subsequent actions in EFT. As noted in the online help, executing the AWE task requires at least one “if action FAILED then” action to be defined, including checking the box to stop processing the rule; otherwise EFT will launch the AWE process in a separate thread and it will run while EFT moves on with the rest of the rule.

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT, v7.x and later

SYMPTOM

Event Rule with DSA ssh key still running while FIPS enabled

WORKAROUND

Restart the EFT server service after enabling FIPS.

MORE INFORMATION

EFT sets FIPS mode at server starting time and caches the connection; therefore, a restart is required for the EFT server service to "re-read" FIPS mode status.

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT, v7.1 and later
• EFT Insight

SYMPTOM

Cannot register EFT Insight.

WORKAROUND

A Windows setting is preventing Insight from connecting to the registration server. Temporarily disabling the FIPSAlgorithmPolicy setting in the registry is required to allow Insight to reach the registration server, as described below.

Change FIPSAlgorightmPolicy\Enabled to 0 before attempting to connect to registration server. Re-enable the setting (i.e., set it back to 1) after EFT Insight registration is complete.

HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled

Type: DWORD

Value name: Enabled

Default Value: 0 (not enabled)

Cached: yes

Backup/Restore: yes

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.10 and later

DISCUSSION

In the Web Transfer Client, you can display the full name of a user instead of the username by creating the registry setting described below.

(Workspaces much be enabled to display the full user name in the WTC.)

​HKEY_LOCAL_MACHINE\Software\WOW6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: DWORD

Value name: DisplayUserFullNameInJument

Default Value: 1

Cached: yes

Backup/Restore: yes

(There is no 32-bit version because there is no 32-bit OS supported.)

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT, all versions

DISCUSSION

Globalscape EFT platform relies on a number of libraries, frameworks, and toolkits for everything from web-facing, front-end functionality, such as jQuery, to back-end functions, such as authentication subsystems (RSA SecurID®). These libraries are monitored and evaluated for change, including new-version releases that include bug fixes, new features, and the occasional security vulnerability fix.

Depending on the nature of the change, the Globalscape development and product teams must determine whether they should introduce the updated library in a given release, defer to a subsequent release, or on occasion, decide to replace the library, framework, or toolkit with an alternative technology. Such decisions are often predicated on a number of criteria, such as the:

• amount of risk associated with introducing the change (this is important if the new version of the library or framework has undergone substantial modifications),
• nature of the fix (was it to address a security vulnerability or add functionality that may or may not be needed),
• and the amount of work necessary to introduce the updated library (as it is seldom the case that it is a drop-in replacement).

One recent example of this decision-making process was deciding whether to update the current version of jQuery, used in the EFT Web Transfer Client (WTC). Although there have been newer versions of jQuery released over the months and years, the functionality of the WTC was not affected by these changes, including fixes to security bugs that existed in jQuery functions that were never accessed by the WTC. Over time, newer technologies have started to evolve that are displacing jQuery as the framework of choice for evolving web applications (such as Angular JS). Replacing jQuery with Angular JS (or other such tools) includes revisiting the entire WTC architecture—a design and implementation process that will require several months of effort, all running in parallel with routine releases of the WTC.

The philosophy of Globalscape is to try to balance the temptation to always be on the latest version of a framework with the practically of doing so, measuring risk versus reward, and alignment with strategic direction versus achieving short term tactical gains, to reach the right decision for both Globalscape and our valued customers.

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.10 and later

DISCUSSION

In EFT v7.4.10 and later, cloud transfers are performed in multi-part sequential files. You can create the registry setting below revert to legacy behavior (chunked transfers in parallel).

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: BOOL

Value name: CloudMultiPartSequentialTransfers

Default Value: 0 = legacy behavior; otherwise = multipart (default)

Restart Required: yes

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• All products

QUESTION

Can I use EFT and DMZ Gateway remote from each other across a WAN?

ANSWER

Globalscape officially supports a network configuration between EFT and DMZ Gateway in which the physical systems are no more than one network “hop” away with an average network latency no greater than 50ms, with zero percent packet loss, and normal packet flow.

Please note that this does not preclude customers from configuring EFT and DMZ Gateway in different network zones over multiple hops with higher than average latencies, greater than zero packet loss, malformed or re-arranged packets, high amounts of jitter, and so on; however, the officially supported configuration is the one we test in QA, and thus is officially supported under our maintenance and support agreement.

For customer-initiated configurations in which EFT and DMZ Gateway are on networks that are remote from each other, such as over a WAN, Globalscape highly recommends that the EFT to DMZ Gateway Peer Notification Channel (PNC) be configured to use encrypted mode, along with client/server certificate verification.

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• All products

QUESTION

Is EFT affected by the LibSSH vulnerability?

ANSWER

No. EFT uses the OpenSSH library and is therefore not susceptible to any vulnerabilities in the LibSSH library.

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.11 and later

DISCUSSION

To calculate disk quota for "never logged in" users and/or for disabled users:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: DWORD

Value names:

• CalculateQuotaForNeverLoggedInUsers
  • 1 = prevent EFT from calculating disk quota for a user until their first log-in. 
• CalculateQuotaForDisabledUsers
  • 1 = do not calculate disk quota for a user that is disabled

Restart Required: yes

Backup/Restore: yes

Hide or Display Disk Quota Controls 

To hide or show the Disk Quota controls in the administration interface:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: DWORD

Value name: showQuotaControls

Default Value: 0 = on/displayed in administration interface; 1 = off/hidden

• That is, to hide disk quota options, set showQuotaControls to 1. Although the controls are not displayed, the functionality is still there. 

Restart Required: yes

Backup/Restore: yes

NOTE: If the disk quota option was set in a prior version of EFT, it is still present after upgrading.

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.11 and later

DISCUSSION

The domain (host) values in EFT are automatically accepted when included in host headers. This applies to the Server administrator listening IP(s) on the Server > Administration tab, and all of the listening IPs, IP ranges, and host name in the Domain box on the Site's Connections tab. To add additional trusted domain and IPs, you can create a whitelist in the registry that will apply to all Sites and the Server.

To specify a whitelist of additional, trusted domains and IPs that EFT can accept, create the following registry setting:

HKEY_LOCAL_MACHINE\Software\WOW6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: DWORD

Value name: AllowedHostHeaderList

Default Value: Allowed host header values are:

• Site Domain (Connections tab)
• Site listening IPs

Restart Required: yes

Backup/Restore: yes

When a connection is attempted:

• If the connecting host header value is in the whitelist, the EFT accepts the host header value.
• If the connecting host header value is not in the whitelist or a known EFT domain/IP value, the connection is denied, EFT logs a warning to let administrator know about the injection attack. e.g:

"WARN HTTP- Access denied for unknown header value: 'desktop-7c01b33'"

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.11 and later

DISCUSSION

EFT v7.4.11 was updated to use the /n 2016 EDI Integrator component, which includes the option to specify allowed signature/ encryption algorithms for inbound transactions. The MDN (Message Disposition Notification) is signed using the specified algorithm. Which algorithms to use can be configured in the registry, as described below.

Available signature algorithms for inbound transactions include:

• 0 As Requested
• 1 As Requested Or SHA1
• 2 SHA1
• 3 MD5
• 4 None
• 5 SHA-256
• 6 SHA-384
• 7 SHA-512
• 8 SHA-224
• 9 As Requested Or SHA-256 (default)

Available encryption algorithms include:

• 3DES
• DES
• AESCBC128
• AESCBC192
• AESCBC256

All available algorithms except "DES" are selected by default.

To specify one or more algorithms, create the following registry settings:

HKEY_LOCAL_MACHINE\Software\WOW6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: STRING

Value names:

• AS2EncryptionAlgorithm
• AS2SignatureAlgorithm

Restart Required: yes

Backup/Restore: yes

In the COM API, these options are configurable via the COM API properties "Signature Algorithm" and "Encryption Algorithm".

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.11 and later

DISCUSSION

To ignore or enforce the SAML assertion signature or SAML message signature, create the registry settings below.

(This is useful if you have separate certificates for encryption and signing.)

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: DWORD

Value name: SamlAssertionSignatureEnforcementLevel

Level of SAML assertion signature enforcement:

0 - required (default)

1 - not required if message signed

2 - enforce if present

3 - ignore result

4 - do not attempt verification.

Restart Required: yes

Backup/Restore: yes

----------------------------

Type: DWORD

Value name: SamlMessageSignatureEnforcementLevel

Level of SAML message signature enforcement:

0 - required

1 - enforce if present (default)

2 - ignore result

3 - do not attempt verification

Restart Required: yes

Backup/Restore: yes

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.11 and later

DISCUSSION

When using DMZ Gateway as a proxy, the DNS lookup is handled on EFT. With the registry setting below, you can specify whether to do DNS lookups on the local EFT Server or DMZ Gateway Server. Enabling this feature would allow secured environments.  that may have limited or no DNS services, to handle the lookup in the DMZ zone. It is also useful if the customer has configured a split DNS between EFT and DMZ Gateway. 

With this setting enabled, all outbound ClientFTP transfers in which Socks5 is used (DMZ Gateway) will send a host name to DMZ Gateway.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: BOOL

Value name: DMZResolvesDNSNames

Values: Default is 0 (disabled); 1 = enabled

Restart Required: yes

Backup/Restore: yes

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.11 and later

DISCUSSION

The Content Security Policy (CSP) HTTP response header declares which dynamic resources are allowed to load in the browser. Not having this header can cause the Web Transfer Client to be flagged as misconfigured or weak in external web security reports. Use the string in the registry setting below as a custom CSP header.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: STRING

Value name: CSPHeaderOverride

Values: Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data:;

The value is a string with the following meaning:

If not present means default

If present and not empty use it as custom CSP

An empty string turns off CSP header

Restart Required: No

MORE INFORMATION

default-src 'self' = default policy for loading content

'unsafe-inline' = allow use of inline source elements such as style attribute, onclick, script tag bodies, javascript: URIs

'unsafe-eval' = allows unsafe dynamic code evaluation such as JavaScript eval()

For information about CSP headers, refer to https://content-security-policy.com/.

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.11 and later

DISCUSSION

The Web Transfer Client for EFT uses form-based authentication. Basic auth is provided to remain compliant with RFC 7617. As added assurance that best practices are followed, EFT administrators can force use of HTTPS for all connections.

You can disallow (shut off) basic authentication for HTTPS using the registry setting below.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: BOOL

Value name: DisableHTTPBasicAuthentication

Values: Default = 0; 1 = disable basic authentication for HTTPS.

Restart Required: Yes

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.10 and later

DISCUSSION

The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead. When the Strict Transport Security header is delivered to the browser, it updates the expiration time for that site, so sites can refresh this information and prevent the timeout from expiring.

Some clients would like to modify the Header String Transport Security (HSTS) value to conform to their security best-practices or recommendations. The registry setting below is used to set the max-age value for HSTS in seconds. When the Web Transfer Client sends the Strict Transport Security header, it should modify the max-age parameter to what is set in the registry entry.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.4\

Type: DWORD

Value name: HSTSMaxAge

Default Value: 900 (15 minutes)

Minimum Value: 1

Maximum Value: 63072000

Restart Required: yes

Backup/Restore: yes