Security basics

• No such thing as "perfect security"
  • complexity of software, machines, and network.
  • basic insecurity of network design.
• Security is a result of effective policy.
  • on what's important.
  • on what's permissible.

Security Illusions

• If I use the right tools, I'm secure.
• If I use 'secure' software, I'm secure.
• If I'm careful about what I do, I'm secure.

All security decisions are tradeoffs between:

• convenience/user tolerance
• value of protected items
• cost of violating security

Some guiding principles:

• "A system is only truely 'secure' if it left disconnected and encased in 15 feet of concrete."
• "A system is 'secure' if it costs more to break into it than the access is worth to the cracker."
• "An encryption method for data is 'secure' if the time it takes to break it renders the protected data worthless."

Parts of Security

• Policy: what's important to protect?
• Architecture: general plan for enforcing policy.
• Implementation: specifics of insuring security.

Policy

• What is our mission?
• What do we need to protect to accomplish that mission?
• What is the relative importance of each thing we protect?
• What services do we need to avoid compromising in order to accomplish that mission?
• What is the relative importance of each service we must provide?

Role of policy

• documents best practices.
• assures consistency of application.
• assures management backing for your actions.
• protects from various liabilities.

Without policy

• you don't know what you're protecting.
• you don't know what you can do.
• you may not even know what's wrong.

True story

• didn't have a Tufts Responsible Use Policy.
• students didn't know what was incorrect behavior.
• sometimes we didn't, either.
• result: ad-hoc enforcement, which means that anyone with a good lawyer escaped punishment.
• (real case: we denied access to suns to a known hacker and had to endure 2 hours of being yelled at by his lawyer.)

Real policies

• wider range that security
• Source: Barbara Dijker, "A Guide to Developing Computing Policy Documents", SAGE Short Topics in System Administration, 1996.

Scope of a real policy

• usage: what can users expect?
• security: how will we preserve data integrity?
• safety: how will we preserve physical integrity (no sodas in the lab!)?
• facilities and resources: breakdown of rights and privileges to utilize each computing resource.
• responsible use agreements: documents that users sign to assure that they will abide by appropriate policies.

What are we protecting?

• Integrity of data.
• Privacy of data.
• Reliability of service.
• Authenticity of users and transactions.
• against Liability in being used as an intermediary.

Policy realities

• As an administrator, your power only extends as far as outside forces allow:
  • management tolerance.
  • legal liabilities and limits.
  • strategic mission objectives.
  • ethical limits of your profession.
• You need the power of law to back you up when you make policy decisions.
• You must prove that your administrative policy doesn't conflict with any of the above.
• Truly effective policies are not made by mere mortals, but by committees containing you, management, and lawyers.

Legal limits upon system administrators

• Privacy laws
  • Family Educational Rights and Privacy Act (FERPA) (for student records).
  • various Medical record privacy acts (for patients).
• Computer Crime laws
  • anti-hacking (breakins and denial of service)
  • anti-fraud (authenticity issues)
• Patent and Trademark infringement.
  • public key encryption was patented in the US (but not abroad) Using it outside patent agreement was illegal in the US (but not in Europe)
• International Trade in Arms Regulations (ITAR).
  • public key encryption is technically a munition. Exporting without a license is illegal.
• "Due dilligence"
  • if someone breaks into your system, are you liable for what the other person does, or negligent because you didn't prevent it?

Ethical limits upon system administrators

• Ethics: a system of beliefs about proper and correct behavior that is more stringent that the law.
• Really a social contract between you and your users.
• double-edged: what you can do and what they can do.

Parts of System Administrator Ethics

• Insuring trust
• Preserving privacy
• Preserving system integrity and availability.
• "Do no harm"

What to do when policies go wrong

• Case example: your policy asks you to do something illegal (e.g., pirate software).
• Ethical dilemma: you've been asked to do something unethical (against the SAGE code of ethics)
• Legal dilemma: it's also illegal.
• SAGE advice (SAGE Ethics Committee, Hal Pomerantz)
  • Explain situation to management.
  • If they insist, get it in writing.
  • In other words, make the organization liable for its actions!

Example: sketch of EECS policies

• Users are given access for pursuit of coursework and research.
• Home directories of users are private unless there is evidence of wrongdoing.
• Wrongdoing includes:
  • academic dishonesty
  • cracking other systems.
  • unauthorized access to other users' accounts.
  • harassment.
• Wrongdoing can lead to loss of privileges and academic or disciplinary action.
• We strive to maintain a network on which you can do coursework.
• Other privileges (such as publishing access, games, etc) are provided as convenient, but may disappear without notice.

The double edge:

• Policy tells what we will do but also what we won't.
• This is not just a network, but a community.
• Policy defines what it is to be a citizen, what you can expect from being one, and what we expect from you.

Know the enemy

• Hacking is not an intellectual activity, but a social one.

Social Engineering

Reverse Social Engineering

General security principles

• avoid exposure.
• deny unnecessary services.
• monitor allowed services.
• update insecure software.

Security activities

• Risk assessment: actions that determine how likely incidents are.
• Prevention: actions that keep incidents from happening.
• Mitigation: actions that cope with incidents as they happen.
• Detection: actions to monitor and detect problems (without implied action).
• Recovery: actions that can recover (when appropriate) from detected states.

Prevention

• keeping software up to date.
• Obeying Computer Emergency Response Team (CERT) advisories (www.cert.org)
• limiting user actions.

Mitigation

• Filtering/control
  • of events/requests
  • of network traffic
  • of service requests

Detection

• Monitoring
  • system configurations.
  • log file contents.
  • network traffic.

Recovery

• Keeping recoverable copies of
  • data and transactions.
  • system programs.
  • user files.

Detection includes State Monitoring

• watch system configuration for problems.
• detect ASAP.
• alert appropriate humans.

Detection includes Event Monitoring

• watch incoming requests for service
• detect possible attacks.
• alert appropriate humans.

Mitigation means some form of filtering

• classify events
• allow some, deny others.
• record if and when people attempt illegal acts.

Examples of security tools in action:

• prevention: OPIE
• prevention: sudo
• detection: tripwire
• mitigation: SWatch
• mitigation: tcp wrappers

Firewalls

• One way of avoiding exposure.
• Goal: make a target host difficult to access.
• Complementary activity to hardening: make an accessible host difficult to compromise.

References

• man ipchains
• /usr/doc/HOWTO/IPCHAINS-HOWTO
• /usr/doc/HOWTO/Firewall-HOWTO
• ipchains --help (as root)

Setting up a firewall

• turn off all non-essential services.
• wrap all essential services.
• patch out all problems.
• install two network interface cards.
  • different vendors: if made by same vendor there's an evil driver bug.
  • different subnets: one is inside, one is outside.

Chains

• a chain is a sequence of filter instructions that may call other chains as subroutines.
• elements of a chain are patterns to match together with appropriate actions to take.
• Note: ipchains is the mechanism for firewalling in RedHat 6.2 but has already been replaced by ipfwadm in newer kernels!

Using chains:

• design an appropriate set of flows you desire.
• design an appropriate set of chains to accomplish those flows.
• implement each chain as a series of filters.
• activate each chain by entering the filters into kernel memory.

Chaining concepts:

• chokes (limit access)
  • filtering: denying access to certain packets based upon content.
• gates (allow access)
  • proxying: creating a controlled channel to the Internet via a helper program or proxy.
  • masquerading: creating a controlled channel to the Internet by pretending to be only the gateway host.

Ipchains doesn't use files

• filter list is kept in the running kernel.
• must issue root commands to modify or otherwise access the list.

Filtering

• specifying which hosts can connect to you.
• as short a list as possible.
• ACCEPT and DENY rules.
• first matching rule in chain wins

   conforming packet ----> IPCHAINS ----> ACCEPT forwarded through!
   non-conforming packet->                DENY   stopped dead!
  

• Example

   ipchains --new test 
   ipchains --add test --source 192.168.1.0/24 ACCEPT
   ipchains --add test --source 130.64.0.0/16 ACCEPT
   ipchains --policy test DENY
  

  • accepts all packets from 192.168.1.*.
  • accepts all packets from 130.64...
  • denies all packets from elsewhere.

     ipchains --list test 
    

  • shows what you've done.
• To make this actually take effect, on an input chain, install it:

   ipchains --add input --protocol tcp --jump test
   ipchains --policy input ACCEPT
  

  • if you get a tcp packet, jump to 'test' chain.
  • if you don't, just accept it.
• Effect: non-conforming TCP packets get bounced.

Caveat:

• IPCHAINS works on the IP level.
• You think on the SERVICE level.
• There has to be some INTERFACE to make it clear what you're doing.
• Recall /etc/services (list of port numbers)

Proxies

• Your server acts on the Internet on your behalf.
• You give a request to the server, it passes it on, and you get the result from the server:

   you                     proxy (2 IP's)             server
   192.168.1.15:?     192.168.1.1 130.64.23.13:?       201.34.2.12:80
     SENDS ----------------> PROXIES --------------->  RECEIVES request
      From 192.168.1.15:X     From 130.64.23.13:Y
      To   192.168.1.1:8080   To   201.34.2.12:80
      YOU GET <------------- REWRITES  <-------------  SENDS answer
                              From 201.34.2.12:80        From 201.34.2.12:80
                              To   192.168.1.15:X        To   130.64.23.13:Y
   you                     proxy (2 IP's)                server
   give me http://foo.com->give me http://foo.com---->sends file
   gets from proxy<--------gets from server<----------
   192.168.1.15:?    192.168.1.1:8080 130.64.23.13:?       201.34.2.12:80
  

• Setting up a simple proxy (http)
  • number internal network on a private address scheme (RFC1597: 10..., 172.16..* or 192.168.*.*)
  • number external network on a public address scheme provided by your ISP.
  • deny all access to http straight through the firewall.

     ipchains --new http
     ipchains --add http --destination 192.168.0.0/16 --source-port 80 DENY
     ipchains --add http --source 192.168.0.0/16 --destination-port 80 DENY
     ipchains --add http --jump RETURN 
     ipchains --add input --jump http 
    

    • http is a subroutine.
    • any thing from internal network to port 80 or from port 80 to internal network gets dumped.
  • Run a proxy server on port 8080 inside the firewall.
    • edit /etc/squid/squid.conf
    • run squid from /etc/rc.d/rc3.d. (I turned it off!)
  • Set your browser to proxy to the firewall on port 8080.

Transparent Proxy

• users don't like configuring that !@#%^& proxy on their browsers.
• we can arrange instead for transparent proxy of requests.
• this requires rewriting requests at the firewall (which BTW must be routing traffic anyway).

   you                     proxy (2 IP's)             server
   192.168.1.15:?     192.168.1.1 130.64.23.13:?       201.34.2.12:80
     SENDS ----------------> REWRITES
      From 192.168.1.15:X     From 192.168.1.15:X
      To   201.34.2.12:80     To   192.168.1.1:8080
                             PROXIES --------------->  RECEIVES request
                              From 130.64.23.13:Y
                              To   201.34.2.12:80
      YOU GET <------------- REWRITES  <-------------  SENDS answer
                              From 201.34.2.12:80        From 201.34.2.12:80
                              To   192.168.1.15:X        To   130.64.23.13:Z
  

• naive host inside network just tries to send directly to an external host.
• This won't work, as there's a block up.
• Instead, the firewall rewrites the packet so that it seems to be a proxy request.
• Thus it becomes proxied without anyone having to set the browser differently.
• Thus the packet can be routed and reach its destination.
• Upon return, the firewall REWRITES THE RETURN PACKET to go to the appropriate target.
• Example:

   ipchains --new http
   ipchains --add http --destination 192.168.0.0/16 --source-port 80 DENY
   ipchains --add http --source 192.168.0.0/16 --destination-port 80 \
      --jump REDIRECT 8080
   ipchains --add http --jump RETURN 
   ipchains --add input --jump http 
  

Masquerading

• In some conditions, transparent proxying is 'too much trouble'.
  • protocol difficult to proxy (e.g., ftp)
  • everyone trusted behind the firewall (e.g., connecting to an external ISP)
• Can instead instruct the firewall to 'pretend' that it is you.
• It maintains tables of how to map between inside and outside.

   you                     masquerader                server
   192.168.1.15:?     192.168.1.1 130.64.23.13:?       201.34.2.12:80
     SENDS ----------------> REWRITES -------------->  RECEIVES
      From 192.168.1.15:X     From 130.64.23.13:Z
      To   201.34.2.12:Y      To   201.34.2.12:Y 
                             REWRITES  <-------------  SENDS
                              From 201.34.2.12:Y        From 201.34.2.12:Y
                              To   192.168.1.15:X       To   130.64.23.13:Z
  

• Example:

   ipchains --new http
   ipchains --add http --source 192.168.0.0/16 --destination-port 80 \
      --jump MASQ 
   ipchains --add http --jump RETURN 
   ipchains --add input --jump http 
  

Principles of gate design

• Everything not allowed is denied

Patterns

• --protocol <protocol>
  • selects protocol of incoming/outgoing packet
  • protocols include tcp, udp, icmp, all
  • --protocol tcp - select tcp
  • --protocol ! icmp - select non-icmp
• --source <address/mask>
  • matches originating address.
  • --source 192.168.1.0/255.255.255.0 - our subnet
  • --source 192.168.1/24 - also our subnet
  • --source ! 192.168.1.1/255.255.255.255 - any host but tcp
  • --source ! 192.168.1.1/32 - also any host but tcp
• --source-port <port> - the source port number.
• --destination <address/mask>
  • matches receipt address.
  • --destination 192.168.1.0/255.255.255.0 - our subnet
  • --destination 192.168.1/24 - also our subnet
  • --destination ! 192.168.1.1/255.255.255.255 - any host but tcp
  • --destination ! 192.168.1.1/32 - also any host but tcp
• --destination-port <port> - the destination port number.
• --icmp-type <typename> - matches the type of ICMP request.

   [root@tcp /root]# /sbin/ipchains -help icmp
   ipchains 1.3.8, 27-Oct-1998
   
   Valid ICMP Types:
   echo-reply (pong)
   destination-unreachable
      network-unreachable
      host-unreachable
      protocol-unreachable
      port-unreachable
      fragmentation-needed
      source-route-failed
      network-unknown
      host-unknown
      network-prohibited
      host-prohibited
      TOS-network-unreachable
      TOS-host-unreachable
      communication-prohibited
      host-precedence-violation
      precedence-cutoff
   source-quench
   redirect
      network-redirect
      host-redirect
      TOS-network-redirect
      TOS-host-redirect
   echo-request (ping)
   router-advertisement
   router-solicitation
   time-exceeded (ttl-exceeded)
      ttl-zero-during-transit
      ttl-zero-during-reassembly
   parameter-problem
      ip-header-bad
      required-option-missing
   timestamp-request
   timestamp-reply
   address-mask-request
   address-mask-reply
  

• --interface <interface-name> - interface (eth0) through which a packet is received.
• --jump <action> - action to take if there's a match.

Rule modifiers

• --bidirectional - simulate writing another rule with source and destination reversed.
• --syn - only match tcp initiation packets; used to create assymetrical filters.
• --verbose - tell what you're doing at each step.
• --numeric - don't use DNS or service names in reporting output.
• --log - turn on kernel logging on matching packets.

Packet chain actions

• <chain name> - call a new (user-defined) chain.
• ACCEPT - let packet through.
• DENY - drop packet.
• REJECT - drop packet and send ICMP deny.
• MASQ - masquerade as local host.
  • only legal for input and user chains.
  • resets source IP address to that of local host.
• REDIRECT - redirect to local port even if targeted for remote host.
  • only legal for input and user chains.
  • resets destination IP address to that of local host.
• RETURN - return from a call chain to a previous one.

Editing chains

• ipchains are stored in the running kernel.
• to access, use command /sbin/ipchains.

   [root@tcp /root]# /sbin/ipchains -help
   ipchains 1.3.8, 27-Oct-1998
   
   Usage: /sbin/ipchains -[ADC] chain rule-specification [options]
          /sbin/ipchains -[RI] chain rulenum rule-specification [options]
          /sbin/ipchains -D chain rulenum [options]
          /sbin/ipchains -[LFZNX] [chain] [options]
          /sbin/ipchains -P chain target [options]
          /sbin/ipchains -M [ -L | -S ] [options]
          /sbin/ipchains -h [icmp] (print this help information, or ICMP list)
   
   Commands:
   Either long or short options are allowed.
     --add     -A chain            Append to chain
     --delete  -D chain            Delete matching rule from chain
     --delete  -D chain rulenum
                                   Delete rule rulenum (1 = first) from chain
     --insert  -I chain [rulenum]
                                   Insert in chain as rulenum (default 1=first)
     --replace -R chain rulenum
                                   Replace rule rulenum (1 = first) in chain
     --list    -L [chain]          List the rules in a chain or all chains
     --flush   -F [chain]          Delete all rules in  chain or all chains
     --zero    -Z [chain]          Zero counters in chain or all chains
     --check   -C chain            Test this packet on chain
     --new     -N chain            Create a new user-defined chain
     --delete  -X chain            Delete a user-defined chain
     --policy  -P chain target
                                   Change policy on chain to target
     --masquerade -M -L            List current masqerading connections
     --masquerade -M -S tcp tcpfin udp
                                   Set masquerading timeout values
   
   Options:
     --bidirectional -b            insert two rules: one with -s & -d reversed
     --proto       -p [!] proto    protocol: by number or name, eg. `tcp'
     --source      -s [!] address[/mask] [!] [port[:port]]
                                   source specification
     --source-port [!] [port[:port]]
                                   source port specification
     --destination -d [!] address[/mask] [!] [port[:port]]
                                   destination specification
     --destination-port [!] [port[:port]]
                                   destination port specification
     --icmp-type [!] typename      specify ICMP type
     --interface   -i [!] name[+]
                                   network interface name ([+] for wildcard)
     --jump        -j target [port]
                                   target for rule ([port] for REDIRECT)
     --mark        -m [+-]mark     number to mark on matching packet
     --numeric     -n              numeric output of addresses and ports
     --log         -l              turn on kernel logging for matching packets
     --output      -o [maxsize]    output matching packet to netlink device
     --TOS         -t and xor      and/xor masks for TOS field
     --verbose     -v              verbose mode
     --exact       -x              expand numbers (display exact values)
   [!] --fragment  -f              match second or further fragments only
   [!] --syn       -y              match TCP packets only when SYN set
   [!] --version   -V              print package version.
   [root@tcp /root]# 
  

Ipchains commands

• --new <chain> makes a new user-defined chain.
• --delete <chain> destroys a user-defined chain.
• --add <chain> <filter> adds a new filter to the chain at the end.
• --delete <chain> <rulenum> deletes a filter from the chain by number.
• --insert <chain> <rulenum> <filter> inserts a filter in the middle of the chain.
• --replace <chain> <rulenum> <filter> replaces a filter.
• --list <chain> lists filters in a chain.
• --policy <chain> <action> sets default policy for a chain.

where

• <chain> - chain number:
  • input - packets received.
  • output - packets ready to transmit out.
  • forward - packets being routed from one subnet to another.
  • a number means a user-defined chain.
• <filter> - a filter specification as above.
• <rulenum> - the number for the rule in the last listing.
• <action> - an action to take by default (if no rules match).

A quick note on laziness

• short abbreviations are fine
• except when your job is on the line.
• use long names to know what you're doing!

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.

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!