GoAnywhere MFT 5.4 - Security Hardening
Posted: 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:
<snip>
MySQL
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'.
</snip>
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!
Daniel
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:
<snip>
MySQL
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'.
</snip>
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!
Daniel