Whose Security Is It, Anyway?Security Expectations for Webmasters

Bo Pitsker, Communications AnalystLawrence Livermore National LaboratoryDecember 4, 2002

Disclaimer

This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes.

This work was performed under the auspices of the U.S. Department of Energy by the University of California, Lawrence Livermore National Laboratory under Contract No.W-7405-Eng-48.

Our agenda today is straightforward

• Brief background

• Dividing up the security space

• Application security

• Web application architectures

• Securing your web site

• Summary

• Q & A

What is our security perspective?

“To provide a world-class research and development environment that enables the scientific and technological missions at LLNL without sacrificing its intellectual property or compromising sensitive information”

How will we do this?

The security infrastructure will strive to make legitimate access to information as transparent as possible, yet become "opaque" to hostile actions.

Assumptions of this presentation

• You already know that DOE and the Federal government have mandated numerous security policies

• You are not a security professional

• You are a webmaster, or are responsible for a web site

• You are moderately technical, or are faking it

What’s my background?

• LLNL developer, desktop publishing, analyst during the 1980s

• Worked in all aspects of industry in the 1990s• Deployed 1000s of nodes into trade shows• Managed system operations worldwide for Pilot

Network Services– Highly secure web sites– Internet access protection– VPNs and remote access– Secure data centers

• Caution: I am not a security expert

Some basic facts about web security

• There’s a huge variation the volume of attacks by industry– Entertainment– Financial services– Government and higher education

• The perpetrators range from 14-year old boys to highly skilled professionals

• Overall computer security compromises are more frequently inside jobs, but web sites are usually attacked from the outside

Attack types are varied, but fall into a few basic categories

• Defacements – altering the appearance or what is presented to the browser

• Web content alteration – may not be obvious

• Site hijacking – using the site systems for other purposes, such as launching DDOS attacks, for which the site will be blamed

• Denial/Distributed Denial of Service attacks – cripples the site to make it unavailable to users

Why web security is hard – there’s too many moving parts!

• Browsers

• Servers

• Protocols

• Operating systems

• Applications

The OSI network model can be adapted for a security threat model

• Only three layers matter:– Network– Operating system– Application

• Web servers and web sites are applications!

• However: the dividing line between operating systems and applications is fuzzy

Network security is the first line of defense

• Design networks to enhance security– Use many subnets; each one should be dedicated to a single

function

– Used dedicated VLANs

• Screen out unwanted protocols, networks and users– Routers can help with aggressive ACLs

– Firewalls can help with stateful inspection

– Proxy servers can help with application-level filtering

Network security is the first line of defense (cont.)

• Perform AAA at the network layer• Employ intrusion detection systems (IDS)• Turn your network management system into

an IDS by watching for the wrong traffic on the wrong subnets– FTP on the web subnet = wrong!– HTTP on the mail subnet = wrong!– SQLnet traffic on the web subnet = wrong!– Telnet anywhere = wrong!

Operating system security is designed to “lockdown” servers (and workstations)

• Use stripped down kernels with minimal functionality

• Apply OS patches religiously• Disable all services and ports not needed by

the applications on that system• Use only secure means of access, and cripple

the rest– Disable telnet, FTP, RAS etc.– Use SSH, SFTP, SCP instead

Application security is the “soft underbelly” of computer security – why?

• Far less standardization– Little or no shared experience– Diversity of protocols, UIs, and APIs

• Many applications trust the OS too much– Assume local (system) users are validated by OS– Assume system routines aren’t vulnerable

• Application developers have little or no exposure to security issues– Lack treat analysis and risk assessment– May or may not understand AAA requirements– Frequently rely on unproven algorithms or code samples

Let’s review web site application architectures

• The level of web site sophistication varies– Static HTML display on single server– Basic CGI scripts and scripting languages– Multiple services on same system; e.g. Apache and

PHP– Two-tier architectures; Apache web server with

MySQL database– Three or n-tier architecture; e.g. web server-

application server-database server

Where do web applications live?

• Client side – usually Java applet or ActiveX control

• Server side – server-side includes, Java, Javascript, ASP pages, etc.

• Distributed applications – frequently relies on middleware such as CORBA, DCOM, RMI etc.

Web sites can be characterized by the degree of exposure to the Internet

• Open to the entire Internet; e.g “public” servers– Can’t screen users– Resides on Green (i.e. DMZ) network– Has maximum vulnerability

• Open to controlled user from Internet– Can screen users via AAA– Also resides on Green network– Network security may reduce some risks

Web sites can be characterized by the degree of exposure to the Internet (cont.)

• Open to the Internet but not accessible from the Internet– No external users per se– Internal users always initiate connections to the

Internet– Resides on Yellow (i.e. restricted) network– Still has some vulnerabilities

• UDP services hard to protect• Spyware, trojans, or malware can lead to compromises

of systems

Defense against users: the triple play -AAA• Authentication

– Determines who the user is– Numerous security levels, from simple cookie setting to

two-factor authentication with “hard tokens”– May require assertion of “role”, not just identity

• Authorization– Defines the resources a particular authenticated user may

access– May define privileges for each user/resource combination– May include role-based privilege sets– Should enforce the “principle of least privilege”

Defense against users: the triple play –AAA (cont.)

• Accounting– Logs resource usage

• Management logs

• Security logs

• Billing records; e.g. chargebacks

– Record retention requirements• LLNL retains web log files a minimum of 60 days for security

purposes

– Numerous logging mechanisms exist, but require specialized analysis tools or scripts to interpret

– Transaction-based systems may use a TP monitor

Securing your web site

• Getting started

• Design and architecture

• Securing the web server processes

• Evaluating off the shelf software

• Check external sources for possible compromises of your applications

• Developing reasonably secure in-house applications

Getting started

• Perform a threat analysis and risk assessment– Who could be interested in your site?

– What’s the value of the information on your site?

– What harm could occur if someone gets root on one of your systems?

– What legal liabilities or obligations apply to you?

• Ensure network security is in place for all networks supporting your web site

• Ensure OS security is in place for all systems supporting your web site

Design and architectural considerations

• Ensure that your web server is on an isolated subnet• Break up site components on separate systems and

networks– See if you can “push” data from a secure server to the

public server (e.g. using rdist)

– If data can’t/shouldn’t be pushed, then put each system on a different subnet

– Each system should accept only restricted network connection types, and possibly, restricted networks

– Move functionality deeper into network

Secure the web server processes

• Run web server and related process under a unique UID – not root

• If superuser privileges needed, e.g. to bind ports, initialize with one program, then execute the remainder without privileges

• Limit server process directory/file access• Turn on logging, and rotate logs off server every day• Tune system resource usage to withstand DOS

attacks; e.g. max threads, TCP timeout parameters, etc.

Evaluate off the shelf software

• Ensure you obtained the application from a trusted source – trojan software is appearing more frequently

• Look at privileges required by application – just like system processes, should not run as a daemon, require access to entire file system, etc.

• Ensure that any administrative interface is on a different port than the ordinary user

Evaluate off the shelf software (cont.)

• Check that appropriate protection is given to non-public information– Logins should be protected with SSL/TLS– Stored information should be encrypted– Stored information should be kept deeper in the network

behind additional firewalls– AAA should be available, at least as an option

• Check various sources for known vulnerabilities– Your CISSO or security professsional– Public organizations: CERT, CIAC, FIRST– Private organizations: Bugtraq, SANS Institute

• Patch, patch, patch! Do not fall behind on patch levels

Developing reasonable secure in-house applications

• By all means consider open source if commercial applications aren’t the best choice

• Incorporate your threat analysis and remediation into your specs

• Scrutinize carefully external scripts, libraries, plug-ins or CGIs

Thou shalt filter thy inputs aggressively!

• Where does user input come from?– URL parameter strings– HTML forms (GETs and POSTs)– Browser-stored information (e.g. cookies)– Database queries– Environmental variables set by other processes accessible to a user

• Reject anything not expected– Ensure that you are receiving a string– Accept only those characters needed by a specific field (positive input

filtering)– Accept specific field formats only– Truncate input to a reasonable maximum length

Follow CERT recommendations for mitigating output vulnerabilities

• Specify which character set is being used; e.g. ISO-8859-1

• Consider how browsers might interpret HTML special characters

• Consider encoding dynamic output elements (e.g. using numeric entry values)

• Filter your output, much like you filter input• Filter cookie values to ensure malicious values

haven’t been set

Check your sites for consistency with DOE and other Federal government mandates

• Section 508 ADA requirements

• Privacy restrictions and notifications– Privacy policies of various agencies– Cookie restrictions

• Session cookies require warning to users

• Persistent cookies can’t be used without permission from DOE

– HIPPA (covers patient data and medical records)– Federal Privacy Act of 1974

Summary (and you thought we’d never get there!)

• The security responsibilities of the webmaster include:– Ensuring that security is considered early and often– Ensuring that network and operating system environments

are sufficiently secure– Ensuring that the design and implementation of the web

site follows security “best practices”– Ensuring that continued monitoring and reviews are

performed• If this seems overwhelming, get professional help!• Contrary to popular opinion, public sites can be made

secure; it’s just a matter of hard work

Q & A