Chapter 9 – Securing Business Services

  • 1,984 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,984
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1.
    • Securing Business Services
  • 2. Presentation Structure
    • Securing Internet servers.
    • Securing Web servers.
  • 3. Internet Servers
    • Internet servers (Web, Telnet, Ftp, etc), by their very nature, will be likely targets for intruders.
    • This is because these systems are visible and advertised to the entire Internet community.
  • 4. Securing Internet Servers
    • Host security.
    • This is how to secure individual hosts (machines) as described in Securing the Internet Connection.
    • This is a precondition for any of the other security mechanisms to use.
    • File access control.
    • This is how you set permission over files on the server.
  • 5. Securing Internet Servers
    • Architecture (e.g., the proper design and placement of an Internet server).
    • An architecture used can greatly affect organisational security.
      • E.g., without a firewall before the Internet servers, they may be exposed to Internet attack.
  • 6. Securing Internet Servers
    • Authentication.
    • Selecting a proper type of user authentication is important to protect against Internet intrusion.
    • Integrity tools.
    • The use of integrity software tools is to ensure that the stored data on the server is not changed without proper authorisation.
  • 7. Securing Internet Servers
    • Digital signature.
    • This is the primary means for providing nonrepudiation.
    • Encryption.
    • Encryption provides the greatest protection for information confidentiality, while it is stored and in transit.
  • 8. Host Security
    • Host security is the fundamental security mechanism required to protect your Internet servers.
    • If you don’t individually protect them first, then all of the other security mechanisms currently used (or to use) are worthless.
  • 9. Weak Host Security: What would happen?
    • E.g., assume you’ve implemented a foolproof confidentiality mechanism using public key encryption techniques.
      • You are sure that there is absolutely, positively no way for anyone else, other than the proper recipient to decrypt the data.
      • If your host security is weak, then the intruder doesn’t need to bother with decryption and s/he can simply break into the server and steal your private key.
      • With the private key in hand, the intruder can read confidential messages easily.
  • 10. Securing Individual Hosts
    • Verify that the host is configured correctly using both automated systems (e.g., Bastille, COPS) and by hand using a checklist.
    • Install host-based packet filters (like iptables). Their logs should be regularly examined.
  • 11. Some Features of Bastille
    • File permission security: set more restrictive permissions on the administration utilities, disable SUID status for mount/umount, disable SUID status for ping?
    • Account security: e.g., password aging, the use of cron to administrative accounts.
    • Boot security: e.g., password-protected boot, disable CTRL-ALT-DELETE, password protected single-user mode.
    • Secure Inetd: disable Telnet, disable Ftp.
  • 12. Some of the Features in COPS
    • file, directory, and device permissions/modes.
    • poor passwords.
    • content, format, and security of password and group files.
    • the programs and files run in /etc/rc* and cron(tab) files. (There are a number of services controlled by scripts under /etc/rc.d, such as:
      • sendmail, cron, lpd, sshd, dhcpd, etc…)
    • existence of root-SUID files, their writeability, and whether or not they are shell scripts.
  • 13. Root-SUID Files
    • An examination of the permission bits of the passwd program (a root SUID file) by:
    • ls -l /usr/bin/passwd
    • would probably show an 's' flag for the owner's execution rights, i.e., -r-sr-xr-x.
    • This indicates that the passwd command is a root SUID program.
  • 14. Securing Individual Hosts
    • Activate logging programs available with the operating system.
      • Regularly examine the logs and pay particular attention to unsuccessful attempts to access restricted documents.
  • 15. Securing Individual Hosts
    • Turn off any service on the host that is not used.
    • Limit the number of login accounts on the servers.
      • The more accounts on the server you have, the more likely it is to be broken into.
    • Constantly monitor Internet security mailing lists for any new vulnerabilities.
      • Install patches, e.g., OS patches.
      • E.g., users can register with ThaiCERT at http://thaicert.nectec.or.th/mailinglist/register.php to receive security news through email.
  • 16. File Access Control
    • Set file/directory permission in the right mode to protect against unauthorised attempts, e.g., to overwrite files, change modes.
  • 17. Architecture
    • There are a number of issues in designing an appropriate architecture:
      • placing an Internet server,
      • server ownership (the organisation or a service provider owns the server???)
      • choosing a server platform,
      • selecting a firewall architecture, and
      • availability.
  • 18. Placing an Internet Server
    • The placement of an Internet server has a strong effect on overall security of the Internet server.
    • In Fig. 8.1, pg 269, there are 3 possible locations for a server:
      • inside your corporate network,
      • in the demilitarised zone (DMZ) of a multitiered firewall system (in the screened subnet area), and
      • elsewhere on the Internet with a third party.
  • 19. Server Ownership
    • You may want to offer Internet services, and in this way, you have to purchase your own hardware and provide all the services by yourself.
      • You own the server by yourself.
    • Or you may use an Internet service provider that gives you Internet server space for providing Internet services.
      • The service provider owns the server.
  • 20. Ownership and Placement of a Server
    • There are 3 architectural options for you to select in providing Internet services:
    • 1. Provide your own server and network connection.
      • In this option, you are responsible for everything, including the Internet connection, the network, and the server.
  • 21. Ownership and Placement of a Server
    • 2. Provide your own server, but put it on the service provider’s network.
      • In this option, you supply and maintain the server, but the Internet connection is done through the service provider’s high-speed connection.
  • 22. Ownership and Placement of a Server
    • 3. Lease space on a server provided by an Internet service provider.
      • Many service providers maintain very large Internet servers running Web and FTP servers.
      • You can rent their disk space on a service provider server and put your information/applications thereon.
      • Sometimes this leasing service is marketed as a cyberspace in a virtual mall.
  • 23. The Trade-offs: Security, Flexibility, Control, and ….among the 3 Options
    • Table 8.1, pg 271 shows a comparison among the three architectural options, namely:
    • Own server and own network,
    • Own server but lease network, and
    • Lease server space.
  • 24. Choosing a Server Platform
    • UNIX is perhaps the most common platform in use nowadays for servers.
    • From a source: Gartner Dataquest, March 2003 (sale in billions of dollars)
      • OS 2001 2002
      • Linux $1.3 $2.1 (double the sale)
      • UNIX $19.4 $17.2
      • Windows $13.1 $12.4
      • From http://usatoday.printthis.clickability.com/pt/cpt?action=cpt&expire=&urlID=6897157&fb=Y&partnerID=1661.
  • 25. Choosing a Server Platform
    • For small businesses with minimal UNIX expertise, the Macintosh or Windows-based solutions are probably suitable due to ease of use.
    • But if you are planning for a very large Internet service with many people accessing it, UNIX is probably the way to go.
  • 26. Selecting a Firewall Architecture
    • If you decide to deploy your own server on your own network, the next step is to select an appropriate firewall architecture.
      • You have various architectures to select, depending on your security requirements.
      • E.g., if security is of great concern, a screened subnet firewall is recommended and your server is placed in the DMZ.
  • 27. Availability
    • There are several precautions you can take to ensure system availability, including:
    • Redundant systems
    • You can have two or more identical servers provide the same information. If one breaks down or is penetrated, the other is still available.
    • Storage backup tools can be used to create a mirror image of the primary server at regular intervals.
  • 28. Availability
    • Geographic separation
    • Two servers are configured identically, but in this scheme, they are located in different places.
    • Each place would have its own separate Internet connection.
  • 29. Availability
    • Ultrareliable hardware
    • Installing Internet services on ultrareliable hardware with built-in redundancies (double CPUs, double UPSs, RAID) will reduce the chance that a server with redundancies will go down.
  • 30. Authentication
    • (A number of user authentication methods were already described in SecIntCon.)
    • The more secure the system, the harder or more expensive it is to use.
      • In other words, the higher the security, the lower the ease of use (usability).
    • When deploying Internet services, you need to decide a proper balance between the usability and security of an authentication technique used.
  • 31. Authentication Used Depends on Types of Information
    • Very important information , such as corporate databases , should be protected with extremely strong authentication , regardless of the difficulty/cost to use.
  • 32. Authentication Used Depends on Types of Information
    • Subscriber information : Information provided to customers for a fee paid requires some authentication to ensure that only subscribers can access the information.
    • But t he authentication system can’t be too expensive or difficult to use or else people may not sign up for the service.
    • An authentication scheme using traditional passwords is usually appropriate for this type of service.
  • 33. Authentication Used Depends on Types of Information
    • Marketing/advertising information: Regarded as public information, this kind of information has minimal authentication needs and strong usability requirements.
    • There is little or no authentication at all for this type of information.
  • 34. Server Data Integrity
    • Maintaining and ensuring the integrity of Web pages is a major concern of many organisations.
    • They worry that an intruder will break into a Web server and change the data stored there.
    • If this goes unnoticed, it could be a disaster for the organisation because it may lose a good image of high security.
  • 35. Integrity Tools: Message Integrity
    • Message integrity or hash functions are the most common method used to combat this problem.
    • Hash codes are computed for all the data on the server and stored in a secure place to ensure that hash codes are not altered.
    • At regular intervals, the hash codes should be recomputed and compared with the original computed codes.
      • If they don’t match, then something has changed and should be immediately investigated.
  • 36. Integrity Tools (cont…)
    • Any time data is added, deleted, or modified, the hash code database needs to be updated to reflect the changes.
    • Several public domain programs can be used for this purpose, including Tripwire, developed at Purdue University.
  • 37. Digital Signatures
    • If you plan on opening a cybershop or conducting business on the Internet, then PKI (public/private key infrastructure) will be very important to you and should be implemented on your server.
      • The server will have a private key (digital signature) and provide its public key for the customers to download and install in his browser. This is to verify if the server they are doing transactions with is authentic (not spoofed).
  • 38. Encryption
    • To securely communicate between a client and an Internet server, there are 3 encryption schemes available for use with WWW:
      • EIT’s Secure Hyper-Text transfer Protocol (S-HTTP),
      • Netscape’s Secure Socket Layer (SSL), and
      • Microsoft’s Private Communication Technology (PCT).
    • Make sure to configure the server to transmit data in an encrypted format.
  • 39. Securing Web Servers
    • Web servers have a few security issues of their own, including:
      • Configuring the server securely.
      • Using Common Gateway Interface (CGI) securely.
      • CGI allows you to add custom services to your Web server. If you’re not careful enough however, you could inadvertently open security holes to the intruder.
  • 40. Configuring the Server Securely
    • Below are the steps you should take when running a server under UNIX (as the most commonly used server platform nowadays).
      • Do not run your Web server as a privileged user (root).
      • If an intruder finds a security hole in the server, this will give them complete access to your server!!!.
      • You may run it under a special account, like www.
  • 41. Configuring the Server Securely
      • Appropriately set the directory hierarchy (Fig 8.4, pg286) and permission of the server so that they are owned by a special user and group, e.g., www.
      • See an example of permission setting at http://thaicert.nectec.or.th/paper/unix_linux/apache_chklist.php#23
      • Also at times double-check to verify that noone has ever changed your setting or inserted a Trojan horse into the server directories.
  • 42. Configuring the Server Securely
      • Turn off the features of the Web server that you really don’t use.
      • The more features a server provides, the more trouble (security holes) it may introduce.
      • E.g., turn off using server-side includes. This feature opens security holes, most notably, the possibility of allowing an intruder to execute any command (embeded in an HTML document) on the server with the ‘exec’ include.
  • 43. Common Gateway Interface (CGI)
    • The CGI protocol allows you to add custom services (programs) to your Web server.
    • This protocol acts as interface between software that you write in a standard programming or scripting language and the Web server.
  • 44. How CGI Works
    • The CGI process works as follows:
      • 1.The user, using a Web browser, selects an item that activates a CGI program. The client (user) sends the server the name of the program and any associated data, such as information entered on a form.
  • 45. How CGI Works
      • 2.The server sets up the proper operating environment and calls the CGI program.
      • -- The environment allows the exchange of data between the server and the CGI program.
      • -- The server may have to send the input data from the client (user) to the CGI program to process there.
      • 3.The CGI program executes, using the input data, and returns any output back to the server.
      • The server in turn passes the output (information) to the client (user).
  • 46. Threats of CGI
    • CGI is a major source of security problems in Web servers, since it allows a client to activate (execute) custom programs on the server. There are several potential vulnerabilities, including:
      • A legitimate CGI program may have security holes that allow an intruder to execute unauthorised commands or to discover information about the system.
      • If uploading of files is allowed, intruders may manipulate to place their own malicious CGI programs on your server without your knowledge.
  • 47. Guidelines for Creating CGI Programs
    • Don’t make assumptions about the program’s operating environment. Instead, set the environment variables (such as PATH on UNIX) within your program or use complete path names.
      • This is because if you don’t, the intruder may be able to redirect executing a system command specified in your program to executing the Trojan horse program (command) instead that they manipulated to upload to your server.
  • 48. Setting the PATH Variable
    • The command in your CGI script like:
      • system("ls -l /local/web/foo");
    • will look for program ‘ls’ from PATH.
    • Do set PATH at the beginning of your CGI script:
    • putenv("PATH=/bin:/usr/bin:/usr/local/bin");
      • In general it's not a good idea to put the current directory (".") into the path.
    • However, if possible, use this instead.
      • system("/bin/ls -l /local/web/foo");
  • 49. Guidelines for Creating CGI Programs
    • Don’t use root SUID (SuperUser) shell scripts within UNIX as your CGI programs. Instead, use other equivalent executable code or PERL scripts.
      • These shell SUID scripts do not work securely in most versions of UNIX and can be abused by an intruder to gain root access.
  • 50. Guidelines for Creating CGI Programs
    • Store CGI programs in a central location. Don’t scatter them throughout your system.
      • Placing all of your CGI programs in one location makes it easier to maintain and control.
      • This prevents someone from intentionally or accidentally placing insecure scripts in one of the scattered Web directories without your knowledge.
    • Evaluate public domain CGI programs before using them.