We already know about:

• proxies: programs that work on behalf of a client to protect the client.
• masquerading: firewall operation in which a firewall rewrites source addresses on outgoing requests, and destination addresses on responses.
• redirection: transparently rewriting destination address on an outgoing request to direct it to use a proxy.

Other techniques:

• tunnelling: 'wrapping' packets for one protocol in another, to protect them from chokes or sniffing.
• virtual private networks (VPN): an application of tunnelling to the problem of Windows-NT security (among others).

Tunnelling (a.k.a. encapsulation)

• Send a packet from your machine in a normal way.
• Intermediary router 'wraps' it inside another protocol and sends it to another router via this protocol.
• The other router 'unwraps' it and sends it on its way again as a normal packet.

Tunnelling example: PPP

• start as an IP packet.
• hit ppp host.
• translate into ppp.
• transmit through tunnel.
• translate back at other end.
• normal IP again!

   normal packet 
      | normal ip routing
      v
   [first ppp endpoint machine]
      | convert to ppp format (compress) 
      v
   ip encapsulated in ppp
      | send to other peer
      v
   [second ppp endpoint machine]
      | convert back to ip from ppp format (uncompress) 
      v
   normal packet 
      | on its way via normal ip routing
      v
  

Advanced tunnelling: ssh

• run ssh daemon on server.
• run ssh client on local workstation.
• specify ports to 'forward'
• target requests at localhost (127.0.0.1)
• result: requests tunnelled to server!

   client request to 127.0.0.1:port
     | ssh client translate, encrypt, transmit
     v
   client request to server:port
     | sshd server transmits request to server:port, receives answer. 
     v
   answer generated from server:port
     | sshd server sends answer to client
     v
   answer for server:port
     | ssh client translates back to local request
     v
   answer from 127.0.0.1:port
  

Practical SSH example:

• your firewall doesn't pass POP.
• but it allows ssh.
• so wrap your POP session in ssh, so it gets through the firewall.

   client
    | pop request
    v
   ssh 
    | encap. pop request
    v
   firewall
    | encap. request gets through
    v
   ssh server
    | unencap. pop
    v
   local pop server
  

• other unencapsulated requests will bounce off the firewall.

Tunnelling application: VPN

• ssh is selective about what it forwards.
• sometimes we want to forward everything.
• particular application: inflexible microsoft software.
• Problematic example:

   secure client
     | packet to trusted host
     v
   insecure network (the internet) 
     | possibly corrupt/compromised packet
     v
   trusted host 
  

• a VPN is made from a general-purpose encrypted tunnel.
  • software on router translates packets into encrypted form.
  • software (and hardware) on client translates packets back.
  • from the point of the client, it's talking on the internet.
  • except that the Internet can't interpret the transaction.
• The VPN 'bandaid' looks like this:

   secure client communicates with 130.64.25.*
        ^
        | 
        v
     vpn card encrypts traffic to 130.64.25.*
        ^
        | 
        v
     internet forwards encrypted info (spoofing and snooping difficult)
        ^
        |
        v
     vpn module decrypts traffic from client. 
     firewall in 130.64.25.*
        ^
        | regular IP packet
        v
     normal server in 130.64.25.*
  

The Practice of Firewalling

• not just knowing ipchains
• but also the true impact of your actions
• common sense doesn't work.

Network Security Risks

• snooping: knowing what information has been sent. This allows 'replay attacks' in which the cracker replays what you sent.
• spoofing: pretending to be one host when you're actually another for the purpose of subverting security. This is related to replay, and allows a host to circumvent most host-based security mechanisms.
• man-in-middle attack (form of spoofing):
  • take control of an intermediary router
  • hijack a session after it's running and authenticated.
  • do what you want.

Case study: illusion of security

• Put up a firewall.
• proxy telnet sessions from outside.
• Telnet is vulnerable to snooping, so
• crackers can get telnet passwords, so
• they're inside your network.
• moral: seemingly innocent 'exceptions' can be deadly.

Case study: illusion of insecurity

• You're told telnet is 'bad' so you dissallow it.
• You're on a switched internal network, so
• sniffing isn't possible, so
• there's no impact in sending cleartext passwords in this domain, and
• you've just limited users' options without cause.
• moral: it's possible to accomplish nothing with a lot of work.

Algebra of insecurity:

• data is tainted if it comes from a possibly corrupt (spoofable) source.
• any result computed from tainted data is tainted.
• data is snoopable if it can be read from the network by a cracker.
• data is snoopable if any channel upon which it is transmitted exposes it.
• a machine is compromised if any unauthorized person has root access.
• if a machine is compromised, all data on the machine is suspect.
• if a machine is compromised, all machines on the same network are potentially compromised as well.

Algebra of maintenance:

• any database of network entities must be maintained, i.e., kept up to date.
• cost of maintenance is proportional to
  • volatility: how quickly information changes.
  • scale: how large the database becomes.
  • locality: how distributed the database becomes as we add stations.
• maintenance tasks include:
  • periodic accuracy audits to assure accurate information.
  • tracking of all entities that could pose a security risk.

Case study:

• Pc's in administrative offices were obsolete.
• Staff 'erased' the hard disks and threw them away.
• Someone noticed that one could 'recover' the original data.
• Consisting of many private records from the company!
• Throwing away old computers is more of a security risk than crackers!

Get real

• we could set up a network in which:
  • all hosts encrypt transmissions to all others,
  • we use strong encryption to assure lack of snooping and spoofing.
• but software we must use every day doesn't support this:
  • we're thus forced to retrofit security into otherwise insecure packages.
  • this is a legacy issue!
• and retrofitted band-aids are very valuable => expensive.
  • in financial outlay.
  • in configuration time and management requirements.
  • in cpu cycles and processing required.
• thus we have a difficult decision:
  • can't afford to run VPN from every host.
  • must decide upon a minimal set of VPN links.

Realities

• VPN is expensive and a last resort
• many solutions to the same problem:
  • hardware VPN
  • ssh tunnelling
  • ssl/https (www)
  • pgp (email)
• cost is proportional to versatility.

Basic design rules:

• to eliminate snooping/spoofing, on the segments where it's a risk, either:
  1. use tunnelling or some variant (VPN, ssh, https, ...)
  2. secure the physical wires and stations from untrusted persons.
• if a network's state is questionable, it's insecure.
• but what's at risk?

Risk assessment

• difference between blind application and intelligent and focussed problem study.
• inherently a nontechnical task.
• inherently financial, legal, and political in character.
• determine
  • what can happen.
  • how likely it is.
  • how much it'll cost you if it does.
  • what can be done to limit this.
  • how much it'll cost.

Cost of doing something to remedy a problem

• purchase price
• staff time to change servers and clients
  • low for server changes.
  • high if 1000 clients must be modified.
• staff time to debug configuration
  • low if simple measure
  • high if complex system with many options.

Cost of not doing something

• cost of repairing problems
• cost related to downtime or loss of services.
• legal costs or liabilities.

Insurance

• theory of insurance: pay a little now to avoid paying a lot later.
• action depends greatly upon balances in cost (of doing or not doing something).

Two kinds of failures

• infrequent: unlikely, unusual, not modelled accurately by laws of averages.
  • low cost: perhaps negligible/nuisance
    • breakins to employee workstations
    • problems that can be easily repaired.
  • high cost: catastrophic
    • server catches fire
    • master accounts database/transaction log corrupted.
  • model: cost of an activity is the cost of repairing damage. This must be modelled as if the damage will occur.
• frequent: likely enough that one can utilize models of average behavior to predict cost.
  • account stealing (by sniffing)
  • password sharing
  • user fraud
  • password cracking/dictionary attack
  • model: average cost of a problem is the cost of repairing it times the probability that it'll occur.

Contingency planning

• 'Circles of defense'
• If this happens, we'll do that...
• If that doesn't work, we'll do the next thing...
• Many levels:
  • catastrophic failure: unlikely but possible
    • off-site storage for critical files.
    • hardware replacement insurance.
    • disaster recovery plan.
  • hardware failures
    • hardware contracts for quick replacement of critical parts.
    • maintenance of a stock of parts replacements.
    • hardware monitoring and preventive maintenance plan.
  • everyday nuisances
    • software monitoring and testing plan.
    • software change and version control.

Active and Passive strategies

• active: requires intervention by an operator.
• passive: works all by itself.