web server security

36
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

Upload: raziya

Post on 05-Jan-2016

47 views

Category:

Documents


1 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 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

Page 2: Web Server Security

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.

Page 3: Web Server Security

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.

Page 4: Web Server 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.

Page 5: Web Server Security

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

Page 6: Web Server Security

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.

Page 7: Web Server Security

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

Page 8: Web Server 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.

Page 9: Web Server Security

9

example

#!/usr/local/bin/perlprint “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

Page 10: Web Server Security

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’ 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

Page 11: Web Server Security

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

Page 12: Web Server Security

12

SSL

Page 13: Web Server Security

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.

Page 14: Web Server Security

14

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

Page 15: Web Server Security

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

Page 16: Web Server Security

Overview of SSL

handshaking process

Page 17: Web Server Security

17

Network Security - Public Key Encryption

Page 18: Web Server Security

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

Page 19: Web Server Security

19

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

Page 20: Web Server Security

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.

Page 21: Web Server Security

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.

Page 22: Web Server Security

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.

Page 23: Web Server Security

ServerAuthentication

DN=Distinguished name

Page 24: Web Server Security

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.

Page 25: Web Server Security

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.

Page 26: Web Server Security

Client Authentication

Page 27: Web Server Security

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.

Page 28: Web Server Security

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.

Page 29: Web Server Security

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)

Page 30: Web Server Security

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

Page 31: Web Server Security

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

Page 32: Web Server Security

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

Page 33: Web Server Security

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

Page 34: Web Server Security

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

Page 35: Web Server Security

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

Page 36: Web Server Security

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 issuer’s name– The entity for whom the certificate is being issued– The public key of the subject– Time stamp