Web Server Security

1
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

2
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.

3
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.

4
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.

5
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

6
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.

7
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

8
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.

9
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

10
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 owners permission
• Next three r-x groups permission
• Final three r everyone elses permission
• To modify permission, chmod command
• More on this later

11
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

12
SSL
13
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, for automatically determining
  whether the data has been altered in transit.

14
SSL

• Encrypted SSL session
• Browser generates symmetric session key, encrypts
  it with servers 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).

15
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

16
Overview of SSL handshaking process
17
Network Security - Public Key Encryption
18
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

19
Open Security Issues

• An intruder could intercept the order and obtain
  bobs 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

20
Summary of the steps in the handshaking process

1. 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.
2. 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.
3. 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.

21
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.

22
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.

23
Server Authentication DNDistinguished name
24
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.

25
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.

26
Client Authentication
27
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.

28
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.

29
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)

30
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

31
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

32
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

33
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

34
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 RSA-based
  authentication methods used
• Encryption include Blowfish, DES and IDEA. Idea
  is the default.
• IDEA International data encryption algorithm

35
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

36
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 issuers name
• The entity for whom the certificate is being
  issued
• The public key of the subject
• Time stamp