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

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

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

20. Summary of the steps in the handshaking process • 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.

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 DN=Distinguished 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. 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 IPsec: Network Layer 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

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