10/23/12. Fundamentals of Linux Platform Security. Linux Platform Security. Roadmap. Security Training Course. Module 9 Application Security

(1)

Fundamentals of

Linux Platform Security

Security Training Course

Dr. Charles J. Antonelli The University of Michigan

2012

Linux Platform Security

Module 9

Application Security

Roadmap

• ssh

• SSL

• IPsec & VPNs

10/12 cja 2012 ₃

(2)

ssh

What is ssh?

• Secure shell

 Secure interactive connections to remote hosts over an insecure network

 Secure data transfers

10/12 cja 2012 ₅

Security Requirements

1. Authentication

(who are you?)

2. Authorization

(what are you allowed to do?)

3. Confidentiality

(nobody else can see the

data without 1 & 2)

4. Integrity

(nobody else can change it)

5. Availability

(you can see the data whenever

you want to)

(3)

Security Requirements

• rtools et alia are naîve nowadays

 rsh, rcp, rexec, rlogin, rsync – weak client authentication, no server authentication, no confidentiality or integrity

 telnet, ftp – cleartext client authentication, no server authentication, no confidentiality or integrity

10/12 cja 2012 ₇

ssh features

•  Remote access like telnet and rlogin •  Remote transfers like rcp (scp) and ftp (sftp) •  Transparent connection tunnelling:

 POP, IMAP, SMTP

 X connections (-X), VNC, Remote Desktop

 LDAP clients

 CVS (CVS_RSH), rsync (RSYNC_RSH)

 …

•  SSHFS: securely mount remote directory

10/12 cja 2012 ₈

• You (have to) type them all the time

 Single sign-on remains elusive

• Conflict between usability & security

 Too many passwords

 Varying strength rules

 Varying length and character class limits

 Varying aging policies

But, passwords

(4)

Public-key authentication

• Public-key quick tour

 Instead of one key (think password) there are two:

 Public key: published widely

 Private key: kept secure

 Something encrypted by one key can only be decrypted by the other

 To encrypt a message: encrypt with receiver s public key, receiver decrypts with their private key

 To sign a message: encrypt with your private key, receiver decrypts with your public key

10/12 cja 2012 ₁₀

Public-key and ssh

•  Generate your key-pair once.

•  Install public key on remote host once.

•  Server authenticates client:

 Server picks a number n, encrypts with my public key, sends it

 My client decrypts n with my private key

 My client re-encrypts n+1 with my private key , sends it

 Server decrypts with my public key

 You re authenticated if server recovers n+1 •  No passwords required!

10/12 cja 2012 ₁₁

lab: public-key ssh

ssh-keygen -t rsa -b 2048!

 never use RSA-1 (uses SSH1, which we said was broken)

 You will be asked for a passphrase, which is used to encrypt

your private key for secure storage on your computer. Think of this passphrase as a PIN securing your private key.

 Don t leave passphrase blank unless you want anyone to be

able to read it cd ~/.ssh/! cat id_rsa.pub! ls -ltra !

(5)

lab: public-key ssh

Copy your public key to your .ssh directory on the remote host

ssh user@remotehost mkdir .ssh! scp id_rsa.pub user@remotehost:.ssh/!

 You ll be prompted for your password! Connect to the remote machine ssh user@remotehost!

 You ll be prompted for your private key passphrase

! !

10/12 cja 2012 ₁₃

But, passphrases

•  But I m still typing my passphrase!

 Yes, but your password isn t going to the server

 So a malicious server can t steal it

 But I m still typing my passphrase!

•  Enter the ssh-agent

 Handles your private key(s)

  Which can be on a smartcard: ssh -I

 Unlocks private key once, keep in memory

 So trading some security for convenience

 Supplies your private key through intervening machines

 So trading more security for convenience

10/12 cja 2012 ₁₄

lab: ssh-agent and ssh-add

ssh-agent $SHELL!

 alternatively: eval `ssh-agent` !

 this second form is easy to add to login scripts!

 ps ax | grep ssh-agent!

ssh-add id_rsa!

 enter your passphrase

ssh remotehost!

 You shouldn t be asked for a passphrase!

(6)

ssh as plumbing

•  ssh & CVS? export CVS_RSH=ssh 

!

•  ssh & rsync? export RSYNC_RSH=ssh

•  ssh & tar? (this copies over contents of /bin, and doesn t

overwrite /bin on the remote host)

ssh remotehost cd /; tar cf – bin/ | tar xvf –

•  fire & forget

eval `ssh-agent` ; ssh-add ; startx!

10/12 cja 2012 ₁₆

ssh as plumbing

•  ssh & Kerberos?

•  Add to client s .ssh/config:

Host remotehost.fqdn  !GSSAPIAuthentication yes  !GSSAPIDelegateCredentials yes  !GSSAPITrustDNS yes!

• kinit!

 Obtain Kerberos creds

• ssh remotehost!

 You ll be logged in with Kerberos credentials!

10/12 cja 2012 ₁₇

Some final thoughts

•  Should I keep upgrading? (yes!)

•  EnableRootLogin?

•  Disable passwords altogether?

•  Protocol 2,1?

•  Read the logfiles -- look for `attack', at least.

  I keep getting tons of brute-force login attempts!

(7)

References

•  HQ: snailbook.com

•  man pages: ssh, sshd, ssh_config, sshd_config

•  Harvey Allen, Security with SSH, Pre-SANOG VI Workshop, Thimphu Bhutan, 2005.

http://ws.edu.isoc.org/workshops/2005/pre-SANOG-VI/ha/security/sec-ssh.pdf

•  Acoustic password guessing attacks (90% of 5-character passwords in less than 20 tries, 80% of 10-char < 75) :

  http://www.freedom-to-tinker.com/?p=893   http://www.cs.berkeley.edu/~tygar/papers/

Keyboard_Acoustic_Emanations_Revisited/preprint.pdf

•  CRC32 exploit:

  CITI research: http://www.citi.umich.edu/u/provos/ssh/

  Warning: http://www.ciac.org/ciac/techbull/CIACTech02-001.shtml   Analysis: http://staff.washington.edu/dittrich/misc/ssh-analysis.txt 10/12 cja 2012 ₁₉

SSL

21

X.509

•  An ITU (nee CCITT) standard PKI

•  Defines standard formats for

  Public key certificates

 Binds public key to X.500-flavor distinguished name or alternative (email address, …)

  Certification path algorithms

 Certification chain anchored by trusted root certificates

•  Hierarchical Certification Authorities (CAs)

•  Coin of the browser realm

  … because SSL uses X.509

(8)

22

TLS - Transport Layer Security

Aka Secure Sockets Layer (SSL) •  Operates at transport layer

 Applications don t have to change

•  Creates secure channel between peers  Authenticates server to client

 Client validates server PK certificate

 Supports optional mutual authentication

 Provides confidentiality and integrity

10/12 cja 2012

SSL

• Secure Socket Layer

 HTTPS on TCP port 443  vendor-driven consortium

• SSLv2/PCT/SSLv3/TLS

• Global PKI

• Trusted Certificate Authorities

 CA keys built into web browsers  x509

10/12 cja 2012 ₂₃

SSL

•  Verify certificate chain •  Exchange symmetric keys

•  Cookies can be marked secure-only •  Problems

 Self-signed certificates

 Costs a non-trivial amount of money to get a real SSL key

 Trusting trust

 CAs pay to include their CERTs in web browsers

 Privacy backfires

 You can t see the data either

(9)

IPsec & VPNs

26

Roadmap

• Definition

• Types of VPNs

• Details

• Pros and Cons

10/12 cja 2012

27

Definition

A VPN is a link over a shared public

network, typically the Internet, that

simulates the behavior of dedicated WAN

links over leased lines.

A VPN uses strong encryption to

secure

your data as it travels over an insecure

network .

(10)

28

Types of VPNs

•  Application  ssh •  Protocol  IPSec  IETF standard

 Supports all protocols

 Flexible & complicated

 SSL

 Vendor consortium

 HTTP protocol only

 Rigid & simple(r)

10/12 cja 2012

29

IPSec

IPSec protocol

 Authentication Headers (AH)

 Encapsulating Security Protocol (ESP)

10/12 cja 2012

IPSec Details – AH

(Protocol 51)

•  AH Transport – Used to authenticate the integrity of the datagram

All Authenticated (except non mutable fields), e.g., TTL

As the entire packet is authenticated, there are some limitations. If using NAT or a firewall where a gateway changes your address, then the packet will fail to authenticate at the far end as the source IP has changed. This is not to say that you cannot use IPSec with a NAT gateway, just that the Gateway will have to be considered the endpoint.

30

IP Header (with

options) AH Transport Layer Header Transport Layer Data

(11)

IPSec Details – ESP

(Protocol 50)

•  Encapsulation Security Payload

  ESP will encrypt the payload so that it is private as it passed through the network

  As you can note, the ESP authentication does not authenticate the IP header so this does not have a problem with working behind NAT.

31

IP Header

(with options) HeaderESP Layer HeaderTransport Layer DataTransport TrailerESP AuthenticationESP

Encrypted Authenticated 10/12 cja 2012 32

Pros/Cons

• IPSec

 Full remote access  All applications supported  All protocols supported

• SSL

 Access through firewall (443)  Clientless

10/12 cja 2012

33 Logical Connection to VPN Concentrator

Remote Access client (Split Tunnel ) Public Network Ethernet C I S C OSY S T E MS Cisco 3030 Ethernet ARBL COOL ARBL COOL 141. 211.255. 196 192.168. 4.6 Pool 192.168.4. 10 – 192.168.7. 249 UM Backbone Tunneled Yahoo Pool 141.211. 12.10 – 141.211. 12.250

Wireless User (non-split tunnel) Internal Server

(12)

lab – install VPN

•  Free encryption

 VPN

 Cisco VPN client (ITCom)

http://www.itcom.itd.umich.edu/vpn/

 Built-in Mac OS X VPN client configuration files

http://www.engin.umich.edu/caen/network/wireless/docs/ macosvpn/

 SSH, SFTP, SCP

 SSH Secure Shell (U-M Blue Disc)

https://www.itcs.umich.edu/bluedisc/  PuTTY http://www.chiark.greenend.org.uk/~sgtatham/putty/ 34 10/12 cja 2012

References

•  Steve Friedl, An Illustrated Guide to IPsec, retrieved October 2009.

http://unixwiz.net/techtips/iguide-ipsec.html

•  S. Kent and K. Seo, Security Architecture for the Internet Protocol, RFC 4301, IETF, December 2005. http://www.ietf.org/rfc/rfc4301.txt

35