Secure Remote Access to an Internal Web Secure Remote Access to an Internal Web ServerServer
Christian Gilmore, David Kormann, and Aviel D. Rubin
ATT Labs - Research
“The security policy usually amounts to total trust of all insiders and total mistrust of outsiders, where the firewall defines the
boundary.”
2
OutlineOutline
• Requirements vs. the current architecture constrains.• Proposed solution.• Security assessment of the proposed solution.• Conclusion.• Questions.
3
RequirementsRequirements
• Access to the internal web server from outside of the firewall boundary.
• Proposed solution should not involve – changes to the firewall configuration on the network or...– changes to the firewall policies
4
EnvironmentEnvironment
• Firewall– “[Inside user] …can establish TCP connection to hosts
outside the firewall on any port, while inbound connections are tightly restricted.”
– “[Firewall] … tears down inactive connections every 15 min.”• DWT (dumb Web Terminal)
– “We strive to treat the DWT as “untrusted” as possible”
5
Possible of the shelf solutionsPossible of the shelf solutions
• Telnet or text-based browser such as Lynx– Disadvantage:
• HTML travels in plain text over the network• No support for multimedia
• Tunneling protocols (IPSpec, SSLtelnet).– Disadvantage:
• requires advance access to the remote client browser settings and computer settings.
6
ArchitectureArchitecture
Internet
DWT
Proxy
Authentication
Server
Web
Server
Firewall
7
ProxyProxy
PushWeb Absent DWTWeb
Server Firewall
Control Connection
Data Connection
Web Request
Web Reply
Web Request
Web Reply
8
Authentication and SecurityAuthentication and Security
• User Authentication
– Hash Chaining– User has to re-enter password every 20 minutes
• Connection Confidentiality
– HTTP over SSL - Secure Socket Layer.
9
ProxyProxy
PushWeb Absent DWTWeb
Server
Firewall
Control Connection
Data Connection
Web Request
Web Reply
Web Request
Web Reply
SSL Session
10
Connection ConfidentialityConnection Confidentiality
• After the user was successfully authenticated the PushWeb establishes the SSL connection to the DWT.
• The SSL on the Server is configured to restrict the set of ciphers supported only to those that provide USA domestic-quality encryption.
11
Security AssessmentSecurity Assessment
• Compromise of Absent– DoS attack - not preventable– Eavesdrop on the user session - SSL prevents it.– Replay attack - SSL makes it almost impossible.– Spoofing - user must check SSL certificate.– Obtain root on PushWeb or access the internal web:
• data cannot be moved over control connection• the same effort as from any other outside host
12
Security Assessment (Continued)Security Assessment (Continued)
• Compromise of PushWeb– PushWeb has limited access rights on the network– No other services are available from the PushWeb– No user data stored on the PushWeb
13
ConclusionConclusion
• The solution achieved its goal:– No changes were required to the network infrastructure– The system provides “...internal Web access from sites such
as terminal rooms and Internet cafes.”
• The system is using well tested protocols - one time password and SSL, but “… protocol composition is a very hard problem and has led to security problems in the past.”
14
QuestionsQuestions
• To overcome the firewall policy authors used PushWeb / Absent configuration. Is there any security gain in connecting through Absent machine as oppose to connecting straight through a firewall?
• If there is a gain, than against what type of attacks?
Internet
DWT
SSL
Web
Server
Firewall
PushWeb Absent
Recommended