CFObjective notes: Locking Down CF Servers - Pete Freitag
May 17, 2013
Locking Down CF Servers - Pete Freitag
Lots of attacks lately against CF servers.
Much better to get they call "can you help me lock down my server" than the call "I got hacked, can you help me now?"
Talking about protecting against "vulnerabilities that Adobe or Railo have created in the server itself", not focusing on the code.
Avoid defaults
if hackers can't "guess" something easily, they may move on
Lockdown and Patch OS
OS vendors have lockdown guides;
-- NSA OS Guides
Windows Security Compliance Toolkit
ensure network firewall is in place
On Windows, have multiple partitions
1 drive for OS, 1 drive for CF install, 1 drive for web root
limits "path traversal vulnerability" (when hackers do "../../../")
Create an account for CF to run.
Create a dedicated virtual host for CF Admin
- require SSL
- require authentication
- restrict by IP address
Services I Like
-- duo security: two factor authentication
-- RDP, SSH
-Dome9: Cloud Firewall
-- easily grant temporary access to administrative ports, and can do it by IP address
-- so if i'm traveling and need access to the server, i can use this to do so securely.
Installation
-- don't install anything you don't need, reduce the "attack surface"
Secure Profile in CF10
Disables RDS, debugging
Install any/all CF security hot fixes and updates
adobe.com/support/security
Block CFIDE
if possible, block ALL of /CFIDE
Can change "default scripts directory" from /CFIDE/scripts
then create a virtual folder in your web server
...this takes care of the tags that need access to /CFIDE
so if that's the only reason you need /CFIDE open, you can do this and block CFIDE altogether
Block CFIDE server-wide, not just by a particular host
want to make sure hackers can't to go http://IP ADDRESS/CFIDE/ ...and still get to it
Lots of security issues over the last 3 years were related to things in CFIDE
(If you're on Railo, block the Railo-Context)
IIS7 Request Filtering
(7.5 has a GUI, 7.0 you have to do it in the applicationhost.config file. CF9 lockdown guide shows you the config file version, CF10 lockdown guide shows the GUI way to do it).
Blocking folders in the web server does -not- prevent you from being able to use CFCs in those folders via CreateObject() in your code.
A lot of stuff in /CFIDE is a treasure trove of things dating back to CF5!
Block or whitelist URIs
Block or whitelist by file extension
Block or whitelist HTTP verbs
request limits
-content length (the max size of a request. so you can control the size of an upload going to the server, etc)
-url length
-query string length
On Apache
RedirectMatch 404 (?i).*/CFIDE
-- return a 404 for any request to the /CFIDE folder
Block other servlet mappings (defined in web.xml)
/cfform-gateway
/cfform-internal
/rest
/CFIDE/main/rds.cfm
/CFIDE/GraphData.cfm (cfchart)
/WSRPPProducer
/CFFileServlet (used for cfcaptcha and when cfimage serves a file back to the user)
/flashservices/gateway
/flex2gateway
Q: "How many of you are using flash forms?"
-- no hands went up. :)
File System Permissions
don't need to give CF full control to all files on the server
really only needs read-only access for most things
needs to write to its own logs but that's about it for write access
Must run CF10 updates from command line.
java -jar {cold fusion home}\cfusion\hf-updates\hotfix_XXX.jar
Update the JVM to latest version supported (1.7 for CF9 or CF10)
Java 1.6 is no longer supported by Oracle!
-- could pass a "magic number" into the url and cause a thread to crash on the server
Adobe now recommends you run the latest supported JVM instead of specific version numbers
Dedicated User Account
want CF running under its own user account that has minimal permissions
Windows: find the CF Service, go to "properties", under "logon identity", just change it to whatever the user is you want to use
Unix: the installer allows you to specify a CF user
--- the default is "nobody". probably not the best choice, because other CF installs might also use the "nobody" account
Sandbox security
make sure you've disabled any unnecessary risks you don't need (cfexecute, cfregistry)
more flexible in CF Enterprise
CF Standard, only 1 set of rules/sandbox for the entire server.
enterprise -- different sandboxes
Session Mechanism
J2EE or CF Session?
Various differences in them. Not as simple as "pick j2ee", it may not do what you need.
On CF10 we have "session rotate", etc.
-- these don't work with J2EE variables
web.xml file --
servlets - the main thing that does all the work (CFM servlet, processes cfm pages)
servlets have servlet mappings -- which URIs does my servlet listen to
filters -- can look at the request and decided what to do (logging, monitoring, etc)
filters can have uri's that they listen to.
can comment out features that you don't need to use.
could make CF have a smaller footprint and start faster, use less memory
but make sure you don't down the server accidentally.
"defense in depth"
-- block a feature in IIS AND in CF, just in case, so it's blocked at both levels
Tomcat --
has a shutdown port
can send a password via TCP to shut down the server
can turn this off (specify the port to be -1)
(only works on Linux. changing port on Windows causes CF service stop to fail)
Tomcat 7 Security Confirmation Guide for more info
URL for the docs on tomcat.apache.org
CF Admin
make sure "use uuid for cftoken" is enabled
enable "global script protection" (but understand that it's a really weak protection)
change the /CFIDE/scripts URL to something non-default
specify the "missing template" and "side wide" error handlers
max number of POST request per app - set to 100
this is for preventing a "Hash DOS" attack
disable client variables if you're not using them
if nothing else, make sure you don't use the "registry" setting
Datasource settings --
CF10 defaults to just 'CRUD' permissions
CF9 defaults to everything (alter table, drop, grant, etc)
-- most apps don't need that
can disable Flash Remoting in CF admin (and remember to remove the Servlet from web.xml too)
Additional Tools
HackMyCF
FuseGuide
CF Unofficial Updater
Lots of attacks lately against CF servers.
Much better to get they call "can you help me lock down my server" than the call "I got hacked, can you help me now?"
Talking about protecting against "vulnerabilities that Adobe or Railo have created in the server itself", not focusing on the code.
Avoid defaults
if hackers can't "guess" something easily, they may move on
Lockdown and Patch OS
OS vendors have lockdown guides;
-- NSA OS Guides
Windows Security Compliance Toolkit
ensure network firewall is in place
On Windows, have multiple partitions
1 drive for OS, 1 drive for CF install, 1 drive for web root
limits "path traversal vulnerability" (when hackers do "../../../")
Create an account for CF to run.
Create a dedicated virtual host for CF Admin
- require SSL
- require authentication
- restrict by IP address
Services I Like
-- duo security: two factor authentication
-- RDP, SSH
-Dome9: Cloud Firewall
-- easily grant temporary access to administrative ports, and can do it by IP address
-- so if i'm traveling and need access to the server, i can use this to do so securely.
Installation
-- don't install anything you don't need, reduce the "attack surface"
Secure Profile in CF10
Disables RDS, debugging
Install any/all CF security hot fixes and updates
adobe.com/support/security
Block CFIDE
if possible, block ALL of /CFIDE
Can change "default scripts directory" from /CFIDE/scripts
then create a virtual folder in your web server
...this takes care of the tags that need access to /CFIDE
so if that's the only reason you need /CFIDE open, you can do this and block CFIDE altogether
Block CFIDE server-wide, not just by a particular host
want to make sure hackers can't to go http://IP ADDRESS/CFIDE/ ...and still get to it
Lots of security issues over the last 3 years were related to things in CFIDE
(If you're on Railo, block the Railo-Context)
IIS7 Request Filtering
(7.5 has a GUI, 7.0 you have to do it in the applicationhost.config file. CF9 lockdown guide shows you the config file version, CF10 lockdown guide shows the GUI way to do it).
Blocking folders in the web server does -not- prevent you from being able to use CFCs in those folders via CreateObject() in your code.
A lot of stuff in /CFIDE is a treasure trove of things dating back to CF5!
Block or whitelist URIs
Block or whitelist by file extension
Block or whitelist HTTP verbs
request limits
-content length (the max size of a request. so you can control the size of an upload going to the server, etc)
-url length
-query string length
On Apache
RedirectMatch 404 (?i).*/CFIDE
-- return a 404 for any request to the /CFIDE folder
Block other servlet mappings (defined in web.xml)
/cfform-gateway
/cfform-internal
/rest
/CFIDE/main/rds.cfm
/CFIDE/GraphData.cfm (cfchart)
/WSRPPProducer
/CFFileServlet (used for cfcaptcha and when cfimage serves a file back to the user)
/flashservices/gateway
/flex2gateway
Q: "How many of you are using flash forms?"
-- no hands went up. :)
File System Permissions
don't need to give CF full control to all files on the server
really only needs read-only access for most things
needs to write to its own logs but that's about it for write access
Must run CF10 updates from command line.
java -jar {cold fusion home}\cfusion\hf-updates\hotfix_XXX.jar
Update the JVM to latest version supported (1.7 for CF9 or CF10)
Java 1.6 is no longer supported by Oracle!
-- could pass a "magic number" into the url and cause a thread to crash on the server
Adobe now recommends you run the latest supported JVM instead of specific version numbers
Dedicated User Account
want CF running under its own user account that has minimal permissions
Windows: find the CF Service, go to "properties", under "logon identity", just change it to whatever the user is you want to use
Unix: the installer allows you to specify a CF user
--- the default is "nobody". probably not the best choice, because other CF installs might also use the "nobody" account
Sandbox security
make sure you've disabled any unnecessary risks you don't need (cfexecute, cfregistry)
more flexible in CF Enterprise
CF Standard, only 1 set of rules/sandbox for the entire server.
enterprise -- different sandboxes
Session Mechanism
J2EE or CF Session?
Various differences in them. Not as simple as "pick j2ee", it may not do what you need.
On CF10 we have "session rotate", etc.
-- these don't work with J2EE variables
web.xml file --
servlets - the main thing that does all the work (CFM servlet, processes cfm pages)
servlets have servlet mappings -- which URIs does my servlet listen to
filters -- can look at the request and decided what to do (logging, monitoring, etc)
filters can have uri's that they listen to.
can comment out features that you don't need to use.
could make CF have a smaller footprint and start faster, use less memory
but make sure you don't down the server accidentally.
"defense in depth"
-- block a feature in IIS AND in CF, just in case, so it's blocked at both levels
Tomcat --
has a shutdown port
can send a password via TCP to shut down the server
can turn this off (specify the port to be -1)
(only works on Linux. changing port on Windows causes CF service stop to fail)
Tomcat 7 Security Confirmation Guide for more info
URL for the docs on tomcat.apache.org
CF Admin
make sure "use uuid for cftoken" is enabled
enable "global script protection" (but understand that it's a really weak protection)
change the /CFIDE/scripts URL to something non-default
specify the "missing template" and "side wide" error handlers
max number of POST request per app - set to 100
this is for preventing a "Hash DOS" attack
disable client variables if you're not using them
if nothing else, make sure you don't use the "registry" setting
Datasource settings --
CF10 defaults to just 'CRUD' permissions
CF9 defaults to everything (alter table, drop, grant, etc)
-- most apps don't need that
can disable Flash Remoting in CF admin (and remember to remove the Servlet from web.xml too)
Additional Tools
HackMyCF
FuseGuide
CF Unofficial Updater