Transcript security

Web Server Security
• Determine What Is Running on Your Machine
• Determine Which Ports Accept Connections. Set up a
Safe User to Run the Web Server
• Modify the User That Will Run the Web Server
• Understand File Permissions and Ownership
• Understand Risks of Web-Server File Ownership
• Protect Against the Risks of Directory Browsing
• Determine a Safe User to Run CGI
• Identify Risks from Poor Programming
• Know How to Check and Work Around Unsafe
Characters in CGI Input
1
Web Server Functionality

A Web server is a piece of software that runs on a
computer. The computer it runs on is its host. The Web
server software is no different than the word processor,
calculator, or adventure games you also run on your
computer. The only difference is the functionality they
all serve.

Since the operating system plays such a major
role and is solely responsible for controlling the
machine's resources, it is imperative that it be secure.
Additionally, the software that the operating system
controls also needs to be secure, along with the physical
host machine itself.
2
Web Server Security
 Probably the biggest mistake that
administrators make is running a machine with
the out-of-box configuration. This is the
configuration the vendor or manufacturer
chose as the default. Typically, it focuses far
more on functionality than on security.
3
Web Server Security

When configuring a web server it is
important to not give the web server more
privilege than it requires to do its task.

Since there is only one user account on a
single-user operating system, the operating
system does not need to keep track of any
usernames. A multi-user operating system
grants various access rights and permissions
to each user. Different user accounts have
different access rights; thus, a file that can be
modified by one user may only be able to be
read by another.
4
Access Rights
• Multi-user OS grants various access rights and
permissions to each user
• Typically, there is one user that can do
anything - superuser
– Root in UNIX, Administrator in Windows
• For better security, a user should only be
granted the minimum access rights required to
perform the tasks in everyday use of the
computer
• May access rights given on a per-file basis
5
File Security

A file is relatively safe from modification if no one
has write permission to it. If write permission were
turned on for the Web server user, and a security hole
was found in the Web server software, they could be in
trouble.

The only permission that must be granted to serve
a file out via a Web server is read permission for the
Web-server user. If the Web-server user can read the
file, it can serve the file out to anyone connecting into
the Web server that requests that file.

Some Web servers have a feature allowing a
Webmaster to disable directory browsing. If your Web
server has this feature, put the read access back on the
directory you created and turn off directory browsing in
the Web server's configuration.
6
CGI Security
• CGI one of the largest security risks
• Webmaster is responsible for CGI programs
and scripts
• Web server must be run as an unprivileged
user – users from all around the web run the
programs on the web server
• Web servers that allow you to define a
separate CGI user from the Web server user
provide some additional security
7
CGI Scripts Security

Since CGI programs and scripts are run
virtually anonymously, they, too, should be
run as a user with very few privileges.

The user chosen to run CGI is almost
more important than the Web server user. The
reason for this is because unlike the Web
server software, CGI programs and scripts can
be written to do anything imaginable and have
a wide range of functionality.
8
example
#!/usr/local/bin/perl
print “Content-type: text/plain\n\n”;
print “removing all files from the file system\n”;
system(“rm –rf /*”);
This piece of perl code would delete all the files
on the hard disk if the user running the script
has the privilege to do so. Only the superuser
has this privilege. Clearly, CGI should not be
run as a superuser
9
Access Rights - Unix
• User cannot take away access from the
superuser
• Example: -rwxr-xr—
–
–
–
–
–
‘r’ read, ‘w’ write, ‘x’ execute
First ‘-’ means this is an ordinary file
First three ‘rwx’ owner’s permission
Next three ‘r-x’ group’s permission
Final three ‘r—’ everyone else’s permission
• To modify permission, chmod command
• More on this later
10
SSL
• Secure socket layer
• Protocol designed to provide data encryption
and authentication between a web client and a
web server
• Begins with a handshake phase that
negotiates an encryption algorithm and keys,
and authenticate the server to the client
• All data is encrypted using session keys
negotiated during the handshake phase
11
SSL
12
Fundamental Security Concerns
• SSL server authentication allows a user to confirm a
server's identity. SSL-enabled client software can use standard
techniques of public-key cryptography to check that a server's
certificate and public ID are valid and have been issued by a
certificate authority (CA) listed in the client's list of trusted
CAs.
• SSL client authentication allows a server to confirm a
user's identity. Using the same techniques as those used for
server authentication, SSL-enabled server software can check
that a client's certificate and public ID are valid and have been
issued by a certificate authority (CA) listed in the server's list
of trusted CAs.
• An encrypted SSL connection requires all information sent
between a client and a server to be encrypted by the sending
software and decrypted by the receiving software, thus
providing a high degree of confidentiality. Confidentiality is
important for both parties to any private transaction. In
addition, all data sent over an encrypted SSL connection is
protected with a mechanism for detecting tampering--that is,
13
for automatically determining whether the data has been
altered in transit.
SSL
Encrypted SSL session:
• Browser generates symmetric session key, encrypts it with
server’s public key, sends encrypted key to server.
• Using private key, server decrypts session key.
• Browser, server know session key
– All data sent into TCP socket (by client or server) encrypted
with session key.
• SSL: basis of IETF Transport Layer Security (TLS).
14
SSL Layering
• Two layers
• SSL Record layer
– Provides confidentiality, authenticity, replay
protection over a TCP connection
• SSL handshake protocol
– Key exchange protocol which initializes and
synchronizes cryptographic state at two endpoints
15
Overview of
SSL
handshaking
process
Network Security - Public Key
Encryption
17
Objectives for SSL Handshake
• Authenticate the server to the client.
• Allow the client and server to select the
cryptographic algorithms, or ciphers, that they
both support.
• Optionally authenticate the client to the
server.
• Use public-key encryption techniques to
generate shared secrets.
• Establish an encrypted SSL connection
18
Open Security Issues
• An intruder could intercept the order and
obtain bob’s payment card information
• The site could display the logo of the company
but actually be a site maintained by someone
else
• The signed certificate that bob receives from
alice assures bob that he is really dealing with
alice. However, this does not indicate whether
alice is authorised to accept payment card
purchases
– This opens the door for merchant fraud
19
Summary of the steps in the
handshaking process
1.
2.
3.
The client sends the server the client's SSL version number,
cipher settings, randomly generated data, and other
information the server needs to communicate with the client
using SSL.
The server sends the client the server's SSL version number,
cipher settings, randomly generated data, and other
information the client needs to communicate with the server
over SSL. The server also sends its own certificate and, if the
client is requesting a server resource that requires client
authentication, requests the client's certificate.
The client uses some of the information sent by the server to
authenticate the server. If the server cannot be
authenticated, the user is warned of the problem and
informed that an encrypted and authenticated connection
cannot be established. If the server can be successfully
authenticated, the client goes on to Step 4.
20
Summary of the steps in the
handshaking process
4.
Using all data generated in the handshake so far, the client (with the
cooperation of the server, depending on the cipher being used)
creates the premaster secret for the session, encrypts it with the
server's public key (obtained from the server's certificate, sent in
Step 2), and sends the encrypted premaster secret to the server.
5.
If the server has requested client authentication (an optional step in
the handshake), the client also signs another piece of data that is
unique to this handshake and known by both the client and server. In
this case the client sends both the signed data and the client's own
certificate to the server along with the encrypted premaster secret.
6.
If the server has requested client authentication, the server attempts
to authenticate the client If the client cannot be authenticated, the
session is terminated. If the client can be successfully authenticated,
the server uses its private key to decrypt the premaster secret, then
performs a series of steps (which the client also performs, starting
from the same premaster secret) to generate the master secret.
21
Summary of the Steps in the
handshaking process
7.
Both the client and the server use the master secret to generate the
session keys, which are symmetric keys used to encrypt and
decrypt information exchanged during the SSL session and to verify
its integrity--that is, to detect any changes in the data between the
time it was sent and the time it is received over the SSL connection.
8.
The client sends a message to the server informing it that future
messages from the client will be encrypted with the session key. It
then sends a separate (encrypted) message indicating that the client
portion of the handshake is finished.
9.
The server sends a message to the client informing it that future
messages from the server will be encrypted with the session key. It
then sends a separate (encrypted) message indicating that the
server portion of the handshake is finished.
10. The SSL handshake is now complete, and the SSL session has
begun. The client and the server use the session keys to encrypt and
decrypt the data they send to each other and to validate its integrity.
22
Server
Authentication
DN=Distinguished name
Man in the middle attack
• The "man in the middle" is a malicious
program that intercepts all communication
between the client and a server with which the
client is attempting to communicate via SSL.
The malicious program intercepts the
legitimate keys that are passed back and forth
during the SSL handshake, substitutes its
own, and makes it appear to the client that it
is the server, and to the server that it is the
client.
24
Man in the middle attack
• The encrypted information exchanged at the beginning of the
SSL handshake is actually encrypted with the malicious
program's public key or private key, rather than the client's or
server's real keys.
• The malicious program ends up establishing one set of session
keys for use with the real server, and a different set of session
keys for use with the client.
• This allows the malicious program to read all the data that
flows between the client and the real server, and to change
the data without being detected.
• It is extremely important for the client to check that the
domain name in the server certificate corresponds to the
domain name of the server with which a client is attempting
to communicate--in addition to checking the validity of the
certificate by performing the other steps described in Server
Authentication.
25
Client Authentication
SSL Record Layer - Ciphers used
• These ciphering algorithms can be used:
– DES. Data Encryption Standard, an encryption algorithm used by
the U.S. Government.
– DSA. Digital Signature Algorithm, part of the digital
authentication standard used by the U.S. Government.
– KEA. Key Exchange Algorithm, an algorithm used for key
exchange by the U.S. Government.
– MD5. Message Digest algorithm developed by Rivest.
– RC2 and RC4. Rivest encryption ciphers developed for RSA Data
Security.
– RSA. A public-key algorithm for both encryption and
authentication. Developed by Rivest, Shamir, and Adleman.
– RSA key exchange. A key-exchange algorithm for SSL based on
the RSA algorithm.
– SHA-1. Secure Hash Algorithm, a hash function used by the U.S.
Government.
– SKIPJACK. A classified symmetric-key algorithm implemented in
FORTEZZA-compliant hardware used by the U.S. Government.
– Triple-DES. DES applied three times.
27
Which Ciphering algorithm to
choose?
• Decisions about which cipher suites a
particular organization decides to enable
depend on trade-offs among the sensitivity of
the data involved, the speed of the cipher, and
the applicability of export rules.
• Some organizations may want to disable the
weaker ciphers to prevent SSL connections
with weaker encryption.
28
IPSec
• Two principal protocols in IPsec
– Authentication header (AH) protocol
– Encapsulation Security Payload (ESP) protocol
• AH provides source authentication and data
integrity, and ESP adds confidentiality on top
of that
• In both of these protocols, before secured
datagrams are sent, the source and network
hosts handshake and create a network-layer
logical connection – a security association (SA)
29
IPsec: Network Layer Security
• Network-layer secrecy:
– sending host encrypts the
data in IP datagram
– TCP and UDP segments;
ICMP and SNMP messages.
• Network-layer authentication
– destination host can
authenticate source IP
address
• Two principle protocols:
– authentication header (AH)
protocol
– encapsulation security
payload (ESP) protocol
• For both AH and ESP, source,
destination handshake:
– create network-layer
logical channel called a
service agreement (SA)
• Each SA unidirectional.
• Uniquely determined by:
– security protocol (AH or
ESP)
– source IP address
– 32-bit connection ID
30
Security at the network layer
• Ipsec provides security at the network layer
• What does it mean to provide security at the
network layer?
– Confidentiality – encrypting the data in IP packets
– Source authentication – prevents IP spoofing
31
Service Agreement - SA
• An SA is uniquely identified by:
– A security protocol (AH or ESP) identifier
– The source IP address for the simplex connection
– A 32-bit connection identifier called the security
parameter index (SPI)
• For a given SA each Ipsec datagram will have
equal SPI value
32
Proxy
• Acts as a relay between between the client
and the server host
• A client wishing to connect to the server
actually connects to the firewall instead
• The firewall then sets up the second half of
the connection from itself to the actual server
• The firewall relays data between the actual
client and the actual server after it examines it
• Most commercial firewall software today is a
hybrid between a packet filtering firewall and a
proxy
33
SSH – Secure shell
• A program for logging into remote machine
and for executing commands on a remote
machine
• Provides secure encrypted communications
between two untrusted hosts over an insecure
network
• For authentication, a combination of RSAbased authentication methods used
• Encryption include Blowfish, DES and IDEA.
Idea is the default.
• IDEA – International data encryption algorithm
34
Proxy
• Proxies are considered secure since any attack
would be on a proxy rather than on a machine
itself
• The outside network will have little knowledge
of what is behind the proxy
• Downside – sometimes complicated to
establish a connection via proxy
• Proxy has to be very quick
– If not, the connection quality is reduced
35
TLS
• SSL developed by netscape
• A de-facto standard
• TLS essentially the latest version of SSL
– But not as widely available in browsers
• Digital certificates contain:
–
–
–
–
The certificate issuer’s name
The entity for whom the certificate is being issued
The public key of the subject
Time stamp
36