Ch14: Physical Security for Servers

1
Ch14 Physical Security for Servers
2
Physical Security Plan

• Descr. Of the physical assets that you are
  protecting
• Descr. Of the physical areas where the asets are
  located
• A descr. Of your security perimeter the boundary
  between the rest of the world and your secured
  area and the holes in the perimeter

3
Physical Security (cont)

• The threats that you are protecting against and
  their likelihood
• Your security defenses, and ways of improving
  them.
• The estimated cost of specific improvments
• The value of the information that you are
  protecting

4
Disaster Recovery Plan

• Establish a plan for rapidly acquiring new
  equipment in the event of theft, fire, or
  equipment failure.
• Test this plan by renting (or borrowing) a
  computer system and trying to restore your
  backups.

5
Other Contingencies

• Loss of phone service or network connections
• Vendor Continuity
• Significant absenteeism of staff
• Death or incapacitation of key personell
• Extreme Natural Disaster

6
Protecting Computer Hardware

• Environment
• Fire
• Smoke
• Dust
• Earthquake
• Explosion
• Temperature Extremes
• Bugs (biological)
• Electrical Noise Lightning
• Vibration
• Humidity Water

7
Physical Access

• Raised Floors Dropped Ceilings
• Air Ducts
• Glass Walls

8
Vandalism

• Ventilation Holes
• Network Cables
• Network Connections

9
Other

• Defending against acts of War and Terrorism

10
Theft

• Ram
• Encryption (data)
• Laptops and portable peripherals

11
Data Protection

• Eavesdropping
• Wiretapping
• Wireless (802.11x)
• Electromagnetic (TEMPEST)
• Fiber Optic cable
• Keyboard monitors (keystroke cache)

12
Backups

• Dont leave backups unattended in a computer room
  that is generally accessible
• Dont entrust backups to a messenger that is not
  bonded
• Sanitize backup tapes before recycling
• Encrypt data before writing
• Verify Backups

13
Ch15 Host Security for Servers
14
Taxonomy of Attacks

• Remote Exploits
• Malicious programs
• Stolen usernames passwords social engineering
• Phishing

15
Frequency of Attack

• By Hand
• Automation (i.e. Script Kiddies)
• Honeypots as a defense
• In 1972, 72 hours to crack RedHat 6.2
• Windows 98 was scanned once an hour and broken
  in less than 24 hours.
• Worst case 15 minutes

16
Script Kiddies

• May 2001 Gibson Research Corp.
• 17 hour Denial of Service attack
• Attacker was a 13 year old girl
• Used more than 400 Windows boxen
• April 19, 2000 Yahoo, ETrade, CNN
• DoS attack that brought down for hours
• 1.7 Billion in damages
• 16 year old Canadian protected by minor laws

17
More serious

• Industrial spies
• Ideologues and national agents
• Organized Crime
• Rogue Employees insurance fraud

18
What they want

• The attack is not the primary target
• Launching probes or exploits against other
  systems
• Participating in a DDoS attack
• Running covert servers (IRC, FTP, httpd)
• Covertly monitoring the network for the goal of
  compromising more systems
• Become a repository for attack tools, stolen
  information, pornography, or other contraband

19
How they get it

• Nc (netcat) Swiss-army knife for IP-based
  networks. Diagnostic and administrative tool
• Trinoo (trin00) Attack server for doing DoS
  attacks.
• Back Orifice and Netbus Windows based Trojans
  that can remotely monitor keystrokes, access
  files, up/download programs and run programs
  remotely

20
How they get it (cont.)

• Bots robots. Not very good but enough to fool
  average person. Distributed by Trojans and
  sometimes legitimately
• Root kits a collection of programs/scripts that
  auto-crack a known system configuration. Plants
  backdoors and erases any trace of the attacker.
  Very sophisticated in design. Easy to use.

21
(Bad) Security Through Policy

• Failure to think about security as a fundamental
  aspect of system setup and design
• Purchase and configuration of computing systems
  based on issues of cost or compatability rather
  than on the desired functionality and security
  needs
• Transmitting of plaintext, reusable passwords
  over networks.

22
(Bad)Security through Policy

• Failure to use security tools properly, if they
  are used at all.
• Failure to obtain and maintain software thats
  free of all known bugs and security holes.
• Failure to track security developments and take
  preventative action
• Lack of adequate logging

23
(Bad) Security through Policy

• Lack of adequate backup procedures
• Lack of adequate system and network monitoring

24
(Good) Security Through Policy Guidelines

• Who is allowed access, what is the nature of that
  access, and who authorizes such access.
• Who is responsible for security, for upgrades,
  for backups, and for maintenance
• What kinds of material are allowed on served
  pages.
• Which sites and external users are to be allowed
  access to pages and data served?
• What kinds of testing and evaluation must be
  performed on software and pages before they are
  installed.

25
(Good) Security Through Policy Guidelines

• How will complaints and requests about the server
  and page content be handled?
• How should the organization react to security
  incidents?
• How and when should the policy itself be updated?
• Who is allowed to speak to members of the press,
  law enforcement, and other entities outside the
  organization in the event of questions or an
  incident

26
Ch16 Securing Web Applications

• A Legacy of Extensibility Risk
• Common Gateway Interface
• Plug-ins, Loadable Modules, APIs
• Embedded scripting languages (ala asp, php,
  server side javascript, and mod_perl)
• Q Why are these bad?
• A They allow any program to run through these
  interfaces.

27
Limiting Damage Caused by Web Applications

• Programs can be inspected and analyzed
• Run programs in restricted environment (this is
  not possible in all environments such as Windows
  95/98/ME or MacOS 7-9)

28
Things to Avoid

• Shells (ala UNIX)
• Too powerful
• Designed for interactive use.
• Default installations
• Files lying around that can give unauthorized
  access
• Always check the cgi-bin!

29
The Seven Design Principles of Computer Security

• Least privilege
• Economy of mechanism
• Complete mediation
• Open design
• Separation of privilege
• Least common mechanism
• Psychological acceptability

30
General Principles for Writing Secure Scripts

• Tons of these!
• Be familiar with the general concepts
• Carefully plan
• Carefully analyze
• Carefully design

31
Securely Using Fields, Hidden Fields, Cookies and
Forms

• Filter the contents of every field, selecting
  characters that are appropriate for each response
• Check the length of every argument after you
  filter. Dont proceed if not correct.
• Make sure that the value provided by the user is
  a legal value (w.r.t. selection lists)
• Revalidate the contents of a form even if you are
  using Javascript to validate forms.

32
(cont.)

• Encrypt field info. Never seen in plaintext
• Use hidden fields to transmit info instead
• Not size limited like cookies
• Isnt displayed to the user
• Back button presents a problem though!
• URL with embedded info is logged to server!
• Vulnerable to a customized url attack
• Crypt handles all but the Back button.

33
Steps to encrypt

• Marshall data
• Timestamp
• Compress
• Embed length
• Encrypt
• Encrypt again
• Encode as raw text
• On a 233Mhz computer, you can do 1000
  secure_encode()
• operations in 90 seconds of cpu time