A good testing tool is CuteFTP Professional.
Below is a collection of suggestions and guidelines for installing, configuring, and deploying the Server and/or DMZ Gateway software in a production environment, including best practices for security.
As with any mission-critical software or hardware, it is recommended that a testing, validation, development, or usability lab be established to provide a "sandbox" into which EFT Server and DMZ Gateway Server software can be deployed. This initial deployment allows for validation of the interoperability with other dependent components as well the validation of expected usage scenarios.
The lab environment should emulate (if not duplicate) the production environment at a network topography and application level. To do this, a clear vision of the production network and the proposed deployment of EFT Server and DMZ Gateway must exist. Typical deployments of EFT Server and DMZ Gateway consist of many other components from the enterprise, including Active Directory Server, SQL Server, SMTP Server, and a storage system such as a SAN . For DMZ Gateway, a firewall such as Microsoft ISA might be applicable. Finally, some deployments also include Clustering, in which case various components are replicated to provide clustered resources.
For increased business continuity and risk mitigation, you should use the development lab environment as the starting point for any configuration changes in the system. That is, make the change in development and validate it prior to making the change in production.
|
|
A good testing tool is CuteFTP Professional. |
The installation and configuration of EFT Server in either a lab or a production environment should be validated by EFT Server administrators/operators to ensure that the functions are working as expected. Use the checklist below to validate key items for a Server and DMZ Gateway deployment. Print a PDF of the table below to check off items as you test. (You need Acrobat Reader to open the PDF.) Also refer to the section below this table for Security Best Practices.
|
Service |
|
|
|
Make sure that the GlobalSCAPE Server service is started on the computer. |
|
|
Make sure that the service is listening on the expected IP:PORT socket addresses on EFT Server. (To view the listening sockets, use "netstat -ona" from a command line or an application such as PrcView or TcpView.) |
|
|
Check the Event Viewer log to ensure that there are no errors in the Application log related to EFT Server or DMZ Gateway Server. |
|
|
Confirm that the administration interface shows the status of the system when it is launched and connected to EFT Server. |
|
Server User Management |
|
|
|
For each Site on EFT Server, ensure that the expected user accounts exist. |
|
|
To ensure that authentication is working as expected, attempt to log in to EFT Server as a user account on the system (using any protocol). |
|
|
To confirm that permissions for the user account are working as expected, attempt a file transfer. |
|
Protocol/Network |
|
|
|
For each protocol enabled on EFT Server, attempt a connection directly to EFT Server using a client that supports that protocol. |
|
|
For each protocol enabled through DMZ Gateway, attempt a connection to the appropriate DMZ Gateway IP:PORT and confirm that this route works as expected. |
|
Auditing/Logging |
|
|
|
View the audit traces generated by the validation steps above. |
|
|
Confirm that the Auditing and Reporting module database has been populated with appropriate data (using either EFT Server Reporting interface or direct access to the SQL Server being used). |
|
|
Confirm that the text log files generated by EFT Server have been populated with the appropriate data. |
|
Event Rules/Workflow Each customer has a unique set of Event Rule/workflow requirements, but these are the general validation steps. Confirm the following are working as expected: |
|
|
|
E-mail notifications. Test e-mail notifications by triggering an Event Rule that has an e-mail notification Action to confirm that Event Rules fire and that the SMTP configuration is correct. |
|
|
PGP operations. Confirm that OpenPGP keys are configured properly. |
|
|
Move/Copy/Download actions. Initiate Event Rules that perform remote file uploads/copies/download so that connectivity originating from EFT Server to a remote system is properly configured. In this step, also confirm that a log file is generated that audits outbound connection information (a "cl*.log" file in the designated Server Log File location). |
|
|
Custom Commands. EFT Server is responsible for triggering those external commands, so that is what should be validated with respect to EFT Server. Any actions carried out by those external tools should be validated independently. Confirm that a "CMDOUT.LOG" file is generated as the result of an invoked Custom Command. |
|
|
Folder Monitor Rules. Ensure that the Event Rules are properly enabled and responsive to files added to the folder being monitored. |
|
Cluster/Failover Testing |
|
|
|
For cluster deployments, the failover and failback operations of the cluster should be confirmed. After a failover/failback, confirm that the newly active server behaves properly; that is, the failover is transparent and the configuration/operation is as expected. This can be summarized by the prior set of tests operating against the newly active node in the cluster. |
|
Load Testing |
|
|
|
If you expect high volumes of traffic or back-end processing within EFT Server, you should verify that the resource utilization levels on the Server are within acceptable tolerances. There are numerous load-testing tools available, ranging from simple batch files running command-line FTP to highly complex synthetic transaction generators. GlobalSCAPE's Quality Assurance team performs load testing of our servers as part of our standard validation process for releasing software. |
Numerous other features can be validated within EFT Server. The above set represents the key elements that are most often used and are the most critical to successful operation in a production environment.
The following settings are recommended for increased security. Print a PDF of the table below to check off items as you test. (You need Acrobat Reader to open the PDF.)
|
Administration Security |
|
|
|
Create a specific AD account on which EFT Server’s service is to run. |
|
|
Create an Event Rule or manually backup the entire Server configuration at least daily. |
|
|
Do not use any default administrator names (e.g., "admin"). |
|
|
Do not use the default administration port. |
|
|
Only turn on remote administration if absolutely essential. |
|
|
Turn on SSL if using remote administration. |
|
|
Create sub-administrator accounts with the least amount of privileges necessary for helpdesk or operational administrators. |
|
|
Set administrator passwords to expire every 60 or 90 days. |
|
|
|
|
|
Lockout administrators upon multiple failed login attempts. |
|
|
Run a PCI DSS report to detect any lax security configuration settings (either manually or on a schedule with an Event Rule). |
|
|
Periodically check the GlobalSCAPE support site for latest version, security patches, etc. and upgrade accordingly. |
|
User/Password Security |
|
|
|
Expire accounts that are non-active for a specified period. |
|
|
Set user passwords to expire every 60 or 90 days. |
|
|
Define complex password security scheme for users. |
|
|
|
|
|
Automatically kick or ban users after repeated failed logins. |
|
|
Automatically ban IP addresses with repeated failed username attempts. |
|
|
E-mail user login credentials separately or only send username and communicate password via phone or other means. |
|
File System Security |
|
|
|
Segregate user’s folders. (Do not share folders/resources across users when possible.) |
|
|
Restrict users to their home folders and set the home folder as ROOT for that user. |
|
|
Use Settings Templates to inherit user permissions rather than modifying them for each user. |
|
|
Use Groups to simplify control over user access to resources. |
|
|
Limit resource permissions to the minimum necessary. |
|
|
Specify a maximum disk space (quota) for each user (or Settings Template). |
|
Auditing Security |
|
|
|
Enable verbose logging (Log Type). |
|
|
|
|
|
Always use extended auditing (ARM). |
|
Data Security |
|
|
|
Encrypt data at rest using EFS encryption, PGP, or 3rd-party encryption. |
|
|
Keep data separate (DAS/SAN/NAS). |
|
|
Define data recovery procedures in case of data corruption/loss/theft. |
|
|
Scan uploaded files for viruses (3rd-party tool required). |
|
|
Never store data in the DMZ, even temporarily. (Use DMZ Gateway instead.) |
|
|
Create a legacy data clean-up rule according to your company policy. |
|
|
Enable data wiping for deleted data. |
|
Protocols Security |
|
|
|
|
|
|
Only allow high security ciphers, hashes, key lengths. |
|
|
Mask the server identity by using generic banner messages. |
|
|
Specify a maximum limit for connections and transfers for each user/template. |
|
|
Specify allowed IP address ranges for user/partner connections when possible, denying connections from all other IP addresses. |
The following are guidelines for maintaining the good health of a Server and DMZ Gateway deployment, and reducing long-term costs of maintenance and operation.
Configuration Backup - For disaster recovery and business continuity, it is important to keep backups of the Server and DMZ Gateway configuration. Backing up the configuration can be accomplished with a variety of tools such as Symantec Backup Exec, Ghost / VMWare to make images of the system, GlobalSCAPE Continuous Data Protection (CDP), or even a simple script file.
Database Backup and Truncation - If you are using the Auditing and Reporting module (ARM), the SQL Server to which the audit records are stored should include EFT Server ARM tables as part of the typical database maintenance plan. This includes proper monitoring of the tables and transaction logs, backing up the data and having a retention policy to archive (or purge) old data.
Data Archival and Retention - You should put into place and enforce a policy by which old data is periodically archived and/or purged, because no disk is limitless and performance can degenerate as more files are added to EFT Server. Therefore, a storage management policy should include regular inspection of available hard disk space and health (error count, fragmentation, etc.) as well as archiving and/or purging user data and Server Log Files (CMDOUT.log found in the application folder, and all other logs found in the Log folder specified on the Server).
Restarting Services - Given the facility of the Microsoft Cluster in failing over and failing back while providing high resource availability, it is recommended that you design a maintenance schedule in which the EFT Server service is cycled at least once per quarter to once per month. Failing over to the backup node, restarting the service, then failing back and restarting the other node would suffice in re-establishing a baseline state of the EFT Server service to ensure optimal health.
Performance Counter Monitoring - DMZ Gateway provides a Performance Counter object to the computer on which it is installed. This object provides a standard Windows mechanism to view activity through DMZ Gateway and, in general, assess the fundamental health of the system as a whole. It is recommended that the enterprise operations practices include monitoring the key performance counters (automatically is preferred) by adding the "Gateway" performance object to Microsoft's Perfmon, and monitoring items such as "Active Sites" (indicates up/down state of EFT Server through DMZ Gateway) and "Active Client Connections" (indicates activity through the DMZ Gateway to EFT Server).
Event Log Alerting - EFT Server will log error conditions to the standard Windows Event Viewer. It is recommended that the operations team for an enterprise include EFT Server error checks in their monitoring techniques, looking for an ERROR event generated with a source of "EFT Server" or "GlobalSCAPE Gateway" service.
Below are few recommendations for achieving a backup server image that is ready to be turned on quickly and accept "real" traffic.
|
|
In all situations, if you are copying a configuration file from one system to another, care must be taken with hardware-specific resources, such as IP addresses, physical paths/partitions, and so on. If possible, it is recommended that the EFT Server configuration use the generic "All Incoming" IP Address for incoming socket connections so that differences in computer IP addresses do not prevent proper operation of the system if the Cold Standby comes online. |
Virtualization Software - A great solution from a cost- and resource-saving standpoint, virtualization software is also quite easy to manage due to the "software" nature of the solution. The approach would be to create an image within a virtual system (using a tool such as VMWare or Microsoft Virtual PC) by installing and activating the EFT Server or DMZ Gateway software. Once this is done, the steps required to bring the system online include first copying the configuration files (which were backed up using a process described above), then bringing the virtual image online and starting the service.
System Backup Software - Another quick and easy option is to create a disk or system image of a configured EFT Server or DMZ Gateway (using a product such as Norton Ghost); when a Cold standby needs to be "stood up" and made hot, the image can be installed on a computer, backup configuration copied, and the service started.
Periodic Backup to Cold Standby Machine - If resources permit, the quickest way to get a "Cold" computer to become "Hot" is to have a computer dedicated to this function. It should have EFT Server and/or DMZ Gateway installed and activated, but the service should be stopped. A process to copy the configuration periodically from the "Hot" server to the "Cold" server would keep the two in synch, and if the "Hot" system goes down, the "Cold" system can simply start the service.
