Docstoc

CIS

Document Sample
CIS Powered By Docstoc
					World Wide Web Development
      Hosting & Security




                             CIS
                             Hosting


• Websites need to be placed on a server in order to be shared
  online.
• Thus you'll need somewhere to host them.Selecting a host
  involves two main areas of concern:
   • Server issues
   • Provider issues




                                                                 2
                              Server Issues


• Here we're concerned with issues such as:
   • How much space do you have on the hard drive?
   • How fast is the server?
   • How much load is it under?
   • How current many transactions can it handle?
   • What is installed on the server?
      • CGIs?
      • Discussion Forums?
      • Databases?
   • What server side processing options are available?
      • Perl?
      • PHP?
   • Can you access log files?
   • How do you upload data to the site

                                                          3
                              Provider Issues


• On the provider side of the equation, we're interested in:
   • What level of support is provided?
   • How much control do they provide/permit over domains?
   • If the servers require maintenance, how will this be handled?
   • How reliable are their servers?
   • How much do they charge?
   • What level of security do they provide?
        • Network security?
        • Physical security?
   • How many email addresses can you have?




                                                                     4
                         Hosting Options


• You own the server:
   • Co-location
   • In-house
       • Dedicated
       • Shared
• You don't own the server:
   • Outsourcing
   • Virtual Hosting
   • Dedicated Hosting




                                           5
                               Outsourcing


• You develop your own site, but all technical issues - hosting,
  maintenance and so on - are someone else's problem.
• It is attractive, but you have little control.
    • What if something goes wrong? How will you access your site?
    • Can you move it if there is a problem with the provider?
    • Are there any significant privacy/security issues?




                                                                     6
                               Virtual Hosting


• With virtual hosting, your site is kept on a server provided by the
  host provider.
• However, that server is shared with other clients.
• Each client receives space on the hard drive, with one web server
  package (typically Apache) handling all the sites.
• Each site receives its own domain, so it appears as if it is
  independent.
   • This is referred to as multi-addressing.




                                                                        7
                   Virtual Hosting: Multi-Addressing


• There are two methods of handling multi-addressing:
   • Virtual servers
   • Virtual domains
• The difference, as will become clear, is slight - while there were
  early problems with virtual domains, they work well now, and are
  the most common option.




                                                                       8
                 Virtual Hosting: Multi-Addressing


• With a virtual domain, multiple domain names are assigned to a
  single IP address. The server determines which hosted website is
  referred to by each request based on the domain name used.




                                                                     9
                 Virtual Hosting: Multi-Addressing


• With the virtual server model, each domain name points to a
  separate IP address. But all the IP addresses point to the same
  computer (often through multiple network cards).




                                                                    10
                          Dedicated Servers


• In this model, the hosting provider owns the hardware.
• However, rather than being given a certain amount of space on
  the hard drive, you rent the whole computer. It is still hosted at the
  provider's site, and you are unlikely to be able to physically
  access the server, but you have a high degree of freedom as to
  the configuration of the server.




                                                                       11
                     Virtual vs. Dedicated Servers


• Virtual servers may be better for:
   • Small sites
   • Medium-sized sites with reasonably low levels of traffic or low levels of
     dynamic content
   • Situations where the standard server configuration is sufficient (PHP +
     MySQL, etc)
   • When security is not a core issue




                                                                                 12
                      Virtual vs. Dedicated Servers


• Dedicated servers may be better for:
   •   Large sites
   •   Sites with very heavy traffic
   •   Sites that involve considerable server-side processing
   •   Sites that require specialized software
   •   Sites where security is a significant concern




                                                                13
                            Co-Location


• Co-location is when you own the physical server hardware.
• But you keep that hardware at a third party's premises. The third
  party provides network access, physical security, and (hopefully)
  other services. Unlike dedicated hosting solutions, you typically
  have (and need) physical access to your server.




                                                                      14
                             Hosting Centers


• All of the previous options typically involve the use of hosting
  centers.
   •   Hosting centers provide:
   •   Physical security
   •   Uninterruptable Power Supplies (UPS) for back-up power
   •   24 hour emergency support
   •   Network backup
   •   Air conditioned server room
   •   Fire suppression systems




                                                                     15
                            In-House Hosting


• If you have a dedicated server room, this can work well:
   • Provides physical security
   • UPS
   • Air conditioning
• If not, this involves either running your server from a locked room
  somewhere, sticking it in a corner and hoping that no-one turns it
  off, or putting it under your desk.




                                                                        16
                             In-House Hosting


• It is a good option if:
    • You're very concerned about security, and have the resources to ensure
      that it is maintained.
    • You have a small site with relatively low loads.
    • You have good internet access and a static IP address/domain name.
    • You're confident in your ability to set-up and maintain the server.
    • The server is intended for intranet applications.




                                                                               17
                           Purchasing a Server


• Some general issues to keep in mind:
   • How scalable is the system?
   • Will it run your desired operating system?
   • How will back-ups be handled?
      • Over the network?
      • Through a mirrored hard drive?
      • Physically?
   • Do you have redundant power supplies?
• The more essential the website is to the business, the more
  important these issues become.



                                                                18
                   Operating Systems for Servers


• The choice of operating systems tend to be compromise between
  scalability, stability, difficulty and the degree of security.
• For example, Unix, Linux and Solaris are all difficult to learn (to
  varying degrees), highly stable and scalable, and provide
  (potentially) good security. (Note that Mac OS X is also based on
  Unix).
• Windows NT, XP, 2000 all provide simpler interfaces, but vary in
  their stability and scalability. Security has tended to be an issue
  with Windows, but recent changes are reducing the problem.




                                                                        19
                         Server Software


• Setting up and configuring a web server is beyond the scope of
  this course.
• However, if you want to run a web server for development, we'd
  recommend Xamp: a combination of Apache, MySQL and other
  packages in a neat portable distribution.




                                                                   20
                               Security


• As you start thinking about hosting, security becomes an issue
• Mind you, it should already have been one.A full discussion of
  security is outside the scope of this course, but we'll cover a few
  things worth remembering.




                                                                        21
                             Perfect Security


• To guarantee that your server is secure:
   • Unplug it from the network
   • Remove all IO devices (disk drives, monitors, USB ports)
   • Bury it in cement
• Nothing less will be sufficient.




                                                                22
                           Imperfect Security


• Always assume that you can't get perfect levels of security.
• Therefore, whenever you add something to your server that needs
  to be secure, question whether or not you really should be adding
  it to the server. The best security is not putting it online in the first
  place.




                                                                         23
                    Improving Your Server's Security


• Access to the Server:
   • Limit the number of people who have either physical or network access to
     the server.
   • Make sure that old accounts are removed as soon as they are no longer
     required.
• Ensure good passwords:
   • Letters + numbers
   • Pass phrases may be worth considering
   • Try not to maintain a list of user passwords: generate new passwords
     instead.
   • Try to avoid global password generation techniques, such as "first for
     letters of family name + the year of birth"


                                                                                24
                    Improving Your Server's Security


• Check your permissions:
   • Not every file needs to be executable, and not every directory needs to be
     publicly writable.
   • Indeed, files should only be publicly ("All") executable and writable if there
     is no other choice.
• Ensure that your patches are up-to-date, and that the continue to
  be good.
   • Remember: once a security hole has been announced, the bad guys know
     about it too.




                                                                                      25
                     Improving Your Server's Security


• Regularly check log files for suspicious activities.
• Turn off unused services: if you don't need ftp, don't provide it.
  Make sure your web server software runs with a minimum set of
  permissions:
   • Thus they can't alter anything outside of their own files directly.
   • And they can't run system commands.
   • Therefore they will have a far higher degree of security.




                                                                           26
                    Improving Your Site's Security


• Don't rely entirely on security through obscurity.
• It is unlikely that someone would guess that:
     http://www.yoursite.com/u126234/213723_asgdsf2.dat
  contains the credit card numbers of all your clients.
• But if someone did, it would be bad.




                                                          27
                       Improving Your Site's Security


• Sensitive information, such as passwords, shouldn't go in the http
  tree. For example:
   • Many PHP developers put the password to the database in a text config
     file, and store it in the same directory as the rest of the site.
   • If everything is perfect, the server will parse the config file if it was
     requested, hiding the password.
   • But if something went wrong, the server won't parse the file, thus sending
     the password to the client.
   • If the config fie wasn't directly accessible to the server (not in the http tree)
     this could never happen.




                                                                                     28
                    Improving Your Site's Security


• Avoid overlapping ftp and http directories.
• A user could upload a malicious CGI, and then use their browser
  to execute it.
• If you need a public ftp area, make sure that the files in that area
  can't be executed, nor directly accessed via the web.




                                                                         29
                      Restricting Access to Files


• You can limit access to areas of your site by IP address or domain
  name.
• If the IP address or domain is in an acceptable range, someone
  can see the material. If not, they can't.
• This is good, as it means that those who need access can do so
  without needing to enter a password. This is bad, because:
   • Not everyone who needs access will be from the correct domain (eg
     working form home)
   • Not everyone in the domain should necessarily have access.




                                                                         30
                       Restricting Access to Files


• Alternatively, you can limit access based on user name and
  password (for example, much of UniSA's website).
• This is good, as you don't need to be within the network to access
  the material.
• This is bad, because:
   • Poor passwords represent significant security holes.
   • Maintaining the separate accounts can be difficult.




                                                                   31
                            Secure Servers


• https signifies that you are using the Secure Sockets Layer for
  communication.
• This uses public-key cryptography to encrypt server/browser
  communications. While not for the faint-hearted to configure, it is
  essential for high levels of security - for example, highly sensitive
  passwords/materials and credit card details.




                                                                          32
                              Physical Security


• All of this is pointless if someone can walk up to your server and
  steal your material.
• Thus physical security matters as well. Consider:
   •   Locking the server into a secure area.
   •   Keeping the server in a locked cage.
   •   Limiting physical access to essential people only.
   •   Running security checks on those with access to the server.




                                                                       33
                                   Backup


• Never ignore backup.
• Data backup:
   • Consider issues such as frequency, rotation of media, and off-site storage.
     (Your backups won't help much if they get destroyed along with the fire that
     burnt your server)
• Backup power supplies (generators, UPS)
• Redundancy (hardware, hard drives, power supplies, network
  connections)
• Support staff (24/7 monitoring and response)



                                                                               34
                        Security in General


• Remember: security matters.
• And when it really matters, it should be handled by someone who
  knows what they are doing.
• Thus: consider hiring a security expert. Experts are good




                                                                35
                               Payment Systems


• Collecting payments is a tad tricky.
• Options include:
   • Collecting credit card details online yourself.
   • Working through third parties.
   • Not collecting credit card details online at all.




                                                         36
                            Payment Systems


• First, consider not requesting credit card details at all.
• Instead ask the client to provide their contact details, and ring
  them to organise payment.
• It isn't elegant, but it is secure.
• Harvey Norman employed this approach, partially to reduce credit
  card fraud.




                                                                      37
                            Payment Systems


• The important thing is:
     If you want users to provide their credit card information, you must use a
     secure server to protect it. And when you get that information, it must be
     stored securely (if it is stored at all) - preferably offline.
• For example: it is bad form to ask someone to enter their credit
  card details into a form, with no security, and then email their
  details to your account. Yet this happens surprisingly often.




                                                                                  38
                           Payment Systems


• In general, a better approach is to use third parties.
• Companies such as Camtech and ANZ will provide credit card
  gateways, allowing payments to be made. You'll still need a
  merchant account with a bank, though.
• Alternatively, you can use companies like PayPal or Google
  Checkout to collect money for you. The cost to you per
  transaction will be higher, but there is little in the way of set-up
  costs.




                                                                         39
The End




          40

				
DOCUMENT INFO