GoAnywhere MFT 5.4 - Security Hardening

If you have a new question you’d like our support staff to post a response to, please visit our customer community, Data Security Insiders, to pose the question in our Discussion Boards. We have a thread “Ask Our Tech Experts” that our support team monitors on a regular basis, or you can start a new discussion where other GoAnywhere users and support staff can weigh in. Log in or create your new account at https://insiders.helpsystems.com/sign_in.

If you need an immediate response, please create a support ticket or contact our support team by email at [email protected].
2 posts Page 1 of 1


Posts: 4
Joined: Thu Dec 01, 2016 10:34 am

Post by dbeckman » Thu Dec 01, 2016 11:35 am
We have an old instance of GoAnywhere Services 3.4 in production, and I've taken on the task of upgrading to GA MFT 5.x, along with revisiting some of the design decisions made several years ago. (As is common in IT, those decisions were made by people who are no longer around.)

Our current production GA Services 3.4 setup consists of a Linux based GA server connecting to a a MS SQL database, and using various NAS and SAN storage for the data. We've opted not to attempt an upgrade from GA Services 3.4 to GA MFT 5.x, and instead leave that in place and setup a new MFT 5.x environment, exporting and importing the web users (which are internal GA users) to the new environment. This gives us flexibility and allows us the opportunity to change a few things. At this time, we're not going to implement GA clustering, but may at a later phase.

Our DBA team supports MS SQL, MySQL, and Oracle. I'd like to switch to MySQL as that will allow us to host everything on Linux, which makes things easier from a support and troubleshooting perspective. (I'd welcome any suggestions or experiences on the various DB options. I loathe all things Oracle but I'd even entertain the thought if someone says it performs much better.)

So there's the backstory. In examining our current 3.4 setup and my test 5.4.0 setup, I've noticed a couple of things that might be opportunities for security hardening, but of course I don't want to break functionality.

The GA 5.4 user guide (ga5_4_0_user_guide.pdf) includes specific recommendations on the MySQL database:
1. Create a new database(also called schema)by running the statement CREATE DATABASE GADATA CHARSET=UTF8.
2. Create a new database user by running the statement CREATE USER GADATA IDENTIFIED BY 'password'.
3. Grant full permissions to the new database created in step 1 to the user created in step 2 by running the statement GRANT ALL ON GADATA.* to 'GADATA'.

My DBAs do not like the sound of this, along the principle of "lease privilege." Can someone tell me whether "full" permissions are really required? I figured it's worth asking, since in my experience some vendor documentation takes a "hammer" approach to permissions.

I've also noticed that the GA application appears to run as root. Is that an absolute requirement? Does anyone have experience running it under more restricted account?

I'm learning this product from scratch -- any suggestions are welcome. Thanks!



Support Specialist
Posts: 592
Joined: Tue Jul 17, 2012 2:12 pm
Location: Phoenix, AZ

Post by Support_Rick » Thu Dec 01, 2016 12:17 pm

Thanks for reaching out with your questions and what you're trying to accomplish. We will be glad to help as we can.

Concerning your DB...

The userID needed by GoAnywhere to connect to the DB is for a "service" access account. Just like with any domain service account or access, it's used to communicate only between GAMFT and the DB (MySQL, MSSQL, Oracle, DB2, etc). GAMFT needs this access to control the DB (Read/Write/Update) as GAMFT is normally the only one needing this access. If this UserID does not have control over the DB, then when upgrades/updates happen, they will error and things will not go smoothly.

GA Can run as root, or non-root.

There are 2 things to keep in mind here...

1. Some linux installations have port 22 commandeered for SSH Admin access. This conflicts with SFTP access for communication. You will either need to switch one or the other, or install another eth line and use 22 for IP#1 as SSH and 22 for IP#2 as Communication. Or, you will have to pick another IP address for one or the other. In either case, there are work arounds.

2. Remember that non-root users cannot bind ports that are under 1024. If you run under a non-root user, you'll have to setup your listeners as higher than 1024 and configure iptable routes to handle those instances.

If you have any other questions, please contact our Support Group ( [email protected] )
Rick Elliott
Lead Solutions Consultant
(402) 944.4242
(800) 949-4696
2 posts Page 1 of 1