RECOMMENDATION FOR SSH/SFTP ACCESS TO WEB HOSTING
Generally, the audience for Web Hosting falls into two distinct groups. Content Editors (est. 200) are typically users
who manage HTML content, usually using a tool like Adobe Dreamweaver. Content editors are often users with
limited technology skills. Developers (est. 50) typically are working on ColdFusion, PHP or Java Web applications
and have more advanced needs.
Content editors and developers using the current Maple and Gecko Web services use WebDAV for file
transmission. The WebDAV protocol uses port 80 or port 443 and is therefore usually allowed through firewalls
along with regular Web traffic. There is no formal shell account support for currently users of these services.
In the new Web Hosting architecture, content editors and developers will use the SFTP protocol, which has
numerous advantages over WebDAV, including wider client support, filesystem-native permissions and much
faster file transmission. Select developers will also have shell access to the file and Web servers to allow a greater
degree of control over their Web configurations. Allowing SSH and SFTP traffic into the DMZ would require the
opening of port 22 in the firewall and/or a VPN requirement for a successful connection. The Web team has
evaluated four options to meet the SFTP and shell requirements of our users while maintaining a secure
environment.
Option 1: Require VPN login for SSH and SFTP
Pro
Con






Audience Impact
Minimal likelihood of brute force attacks
No DMZ machines exposed over port 22
Additional layer of security inherent in dual login
Content Editors/Developers would have to be logged into VPN for every upload
Transfer speed constrained by VPN
End-user frustration and training
Option 2: Require VPN login for SSH; leave SFTP (shell disallowed) open over port 22 into DMZ
Pro
Con




Audience Impact
Content Editors not required to log in to VPN
DMZ exposure on port 22 limited to single server with shell-disallowed daemon
Developers would be required to log into VPN for shell access
File server in DMZ exposed over port 22 (w/ shell disallowed)
Option 3: Open port 22 into DMZ for both shell and SFTP access using custom two-factor authentication
Pro
Con






Audience Impact
Content Editors and Developers not required to log in to VPN
Additional authentication challenge from LDAP
Minimal retraining and inconvenience
File server in DMZ exposed over port 22 (w/ shell disallowed)
Web servers in DMZ exposed over port 22 (w/ shell enabled)
Maintenance of custom module for logins
Option 4: Provide shell users with RSA SecurID fobs; leave SFTP (shell disallowed) open over port 22 into DMZ
Pro
Con







Audience Impact
Content Editors and Developers not required to log in to VPN
Vendor-supplied and supported
High degree of security
Expensive; infrastructure doesn’t exist
Maintenance infrastructure required for lost or faulty fobs
Only usable for shell access; SFTP would still require open firewall port
Not compatible with end-user tools
Given the desire to offer end-users a convenient experience while maintaining maximum security in the DMZ, the
Web and Communications group recommends Option 2. By allowing limited SFTP access to the Web Hosting file
server only, the chances of a successful attack are minimal. Requiring VPN access for developers desiring shell
access is in-line with current UTS practices for other shell-enabled machines in the DMZ and is a reasonable
security measure.
COMPROMISE RISK IMPACT
IMPACT OF ALLOWING SECURE SHELL ACCESS (SSH [PORT 22]) FOR SFTP ONLY
Considerations
Using SSH only as a secure file transport opens the possibility of a remote exploit that directly yields privileged
access. The exposure is otherwise similar to alternate means of secure file transfer.
Assessment
The code has been publicly available and widely used for many years, decreasing the likelihood of a new "remote
root" exploit. The additional risk of using SFTP over webDAV is small.
The portion of code that specifically disables shell access should be open for internal review.
IMPACT OF ALLOWING SECURE SHELL ACCESS (SSH [PORT 22])
Considerations
Allowing shell access opens the possibility that a compromise without privilege could use a local exploit to gain
privileged access. The command-line interface is offered as an auxiliary method of access that will be enabled only
for specific users. The Web and Communications team will follow recommendation from the security team with
regard to whether VPN will be a prerequisite for shell access into the DMZ.
The threat of a command-line must be considered in context. Similar exposure exists in CGI and other integral
features of web hosting. The contrast between these is largely in "hardening." Greater hardening of the web
programming tools is due to a greater threat: anonymous, remote access.
While the notion that command-line access may expose sensitive system information is certainly true, the reality
could be that administrators, wary of this possibility, will be appropriately diligent in guarding against the risk
instead of demonstrating lax disregard.
Assessment
Generic, brute force attacks are common but are unlikely to succeed unless weak passwords intersect accounts
with common names. Stolen credentials represent no greater risk than the file transfer access unless paired with a
local exploit or inappropriate permissions on system data.
Existing options to tighten exposure of a shell include using a “restricted” shell and “change root” (or process
“jail”), which creates a non-system file hierarchy. The “restricted” shell imposes limitations that are not conducive
to developer access. It is intended to disallow execution of all non-prescribed programs and disables navigating
the file hierarchy interactively. Although the “change root” capability exists, this feature is meant for service
specific not user specific “jails” and would require the creation and maintenance of programmatically instantiated
jails. The “change root” functionality has been incorporated into richer facilities such as “containers” or “zones,”
but these are better suited for host virtualization. A custom solution would be necessary to achieve the desired
combination of permitted and restricted actions, but the development and support effort are high compared to
the relative risk.
Hardening the system against compromise by disabling unused services and setID programs is advisable to reduce
the exposure to local exploits. Users with shell access will not receive extended privileges, so role-based access
controls will not apply.
Precautions appropriate to the low risk exposure of shell access should be taken.







Shell access should not be enabled automatically.
System hardening should be done.
An automated audit of sensitive permission settings should be performed regularly.
Inactive users should have their access disabled.
A second challenge is recommended as it may frustrate brute force attacks.
Policy should be used to guide affiliated, authorized users.
Additional conditions could be imposed on unaffiliated users seeking access to fulfill contracted work.
WEB HOSTING SECURITY RISK ASSESSMENT
STANDARD AND ADVANCED HOSTING
LOSS OF SERVICE
Impact
The web is our most powerful communication medium. Any outage in Web Hosting disrupts communication and
can negatively impact the image of Emory University.
Response
All but a minor compromise would demand at least an unscheduled maintenance outage and at worse a total
service outage. The maximum duration of a total outage would be the greater of (1) the time needed to chose and
execute a full restore from backups or (2) the time to identify and patch the vulnerability exercised.
THEFT OF INFORMATION
Impact
Exposure of sensitive information could result in harm -- likely financial -- to individuals, organizational units, or the
entire university. If warranted, public disclosure of an information theft would negatively impact the image of
Emory University.
Response
Any compromise would require an assessment of data accessible to the attacker. Public disclosure of the
compromise and the type of information exposed may be warranted.
CORRUPTION OF INFORMATION
Impact
Overt changes [vandalism] would negatively impact the image of Emory University and could damage our message.
Any malign change could cause a range of harm. Non-visual elements could be modified to propagate attacks (e.g.
browser scripting attack). Subtle changes could be used to augment further compromise (e.g. social hacking).
Response
Any compromise would necessitate checking the integrity of exposed data.
Any inappropriate modifications would need to be rolled back by manual edits or restoration from backups.
GENERAL PRECAUTIONS







Access to privileged accounts must be limited.
Access should be recorded in a log and made available for review.
The responsibility of the user should be well documented and high profile.
Access should be subject to controls to mitigate denial of service.
The password policy should be reviewed annually, at least.
The integrity of the system and user data should be verifiable and monitored for changes.
Retention of data for forensic purposes should be used, as reasonable.
USER ACCESS CONSTRAINTS
Fine-grained Access
User data in the Web Hosting service is restricted on a per directory basis to a list of authorized users. Delegated
administration allows users to grant access on an individual basis.
Expiration of Rights
Expiring modification rights would be advisable, but the irritation to the users could be considerable. Expiration is
currently optional and rarely used. No effort has been made to continue this feature.
Password Aging
Disabling passwords that have not changed for a specific period of time has some value for the organization as a
whole, but it would have little impact on Web Hosting. An adversary with stolen credentials is likely to use those
credentials in a timely fashion.
Network Host Restriction [VPN]
Restricting access by host will not scale to the size of the community of content producers using Web Hosting. A
Virtual Private Network (VPN) offers no advantage in the cases where the does not require additional credentials
or when the adversary has access to the end-user machine (or another with VPN access established).
One-time credentials [SecureID]
One-time passwords and hardware tokens could provide a high level of assurance that observed credentials are
invalid. The obstacles to using either of these include (1) large number of users, (2) user irritation, and (3)
integration with a client tool such as Dreamweaver. Effective use would require equal integration into the file
transfer service and the web interface. Shell access, if permitted, would have similar rights and should use the
same constraints.
APPENDIX 1
ATTACK VECTORS
Denial of Service: An adversary degrades normal operation without an access compromise.
Imposing limits, such as limiting a network connection rate, may allow service to continue and may reduce
the impact to other components sharing the targeted system.
Remote Exploit: A remote adversary gains access by exploiting a software flaw.
Exposure can be reduced by running with minimum privilege and disabling privileged access whenever
possible.
Some forms of abatement may be available, such as disabling stack execution, mandatory access controls,
or “safe” libraries.
A code audit may improve risk assessment.
Brute Force: A remote adversary gains access using a valid username and password as a result of successive
guesses.
Hard to guess passwords and mechanisms to throttle successive attempts can thwart an attack. If
possible, privileged accounts should be disabled or further restricted.
These attacks are usually susceptible to atypical behavior.
Stolen Credentials: Valid credentials are observed or captured.
One time passwords and temporal authenticators can prevent observed credentials from being reused.
Educating users to prevent the exposure of passwords is arguably the most important protection.
Local Exploit
An adversary with access exploits a system or software flaw to exercise elevated privileges.
Most operation environments are built on a large volume of code making the local system hard to secure
without impairing functionality. Application isolation and control of program execution is required to
narrow the observable system effectively.