1 / 71

Lecture 22 Network Security

Lecture 22 Network Security. CPE 401 / 601 Computer Network Systems. slides are modified from Dave Hollinger. Terminology. Authentication : identifying someone (or something) reliably. Proving you are who you say you are. Authorization : permission to access a resource. Terminology.

blaise
Download Presentation

Lecture 22 Network Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 22Network Security CPE 401 / 601Computer Network Systems slides are modified from Dave Hollinger

  2. Terminology • Authentication: identifying someone (or something) reliably. Proving you are who you say you are. • Authorization: permission to access a resource. Netprog: Security

  3. Terminology • Encryption: Scramble data so that only someone with a secret can make sense of the data. • Decryption: Descrambling encrypted data. • DES: Data Encryption Standard: secret key cryptographic function standardized by NBS (NIST). Netprog: Security

  4. Terminology (cont.) • Secret Key Cryptography: a cryptographic scheme where the same key is used to encrypt and decrypt. • Public Key Cryptography: a cryptographic scheme where different keys are used for encryption and decryption. Netprog: Security

  5. Terminology (more!) • Firewall: a network component that separates two networks and (typically) operates in the upper layers of the OSI reference model (Application layer). • Screening Router: a discriminating router that filters packets based on network layer (and sometimes transport layer) protocols and addresses. Netprog: Security

  6. Unix Network Security Some basic approaches: • Do nothing and assume requesting system is secure. • Require host to identify itself and trust users on known hosts. • Require a password (authentication) every time a service is requested. Netprog: Security

  7. Traditional Unix Security (BSD) • Based on option 2 – trust users on trusted hosts. • if the user has been authenticated by a trusted host, we will trust the user. • Authentication of hosts based on IP address! (doesn’t deal with IP spoofing) Netprog: Security

  8. Reserved Ports • Trust only clients coming from trusted hosts with source port less than 1024. • Only root can bind to these ports. • We trust the host. The request is coming via a trusted service (a reserved port) on the host. Netprog: Security

  9. Potential Problem • Anyone who knows the root password can replace trusted services. • Not all Operating Systems have a notion of root or reserved ports! • It’s easy to impersonate a host that is down. Netprog: Security

  10. Services that use the BSD security model • lpd – line printing daemon. • rshd – remote execution. • rexec – another remote execution. • rlogin – remote login. Netprog: Security

  11. BSD Config Files • /etc/hosts.equiv – list of trusted hosts. • /etc/hosts.lpd – trusted printing clients. • ~/.rusers – user defined trusted hosts and users. Netprog: Security

  12. lpd security check client's address for reserved port and check /etc/hosts.equiv for client IP or check /etc/hosts.lpd for client IP Netprog: Security

  13. rshd, rexecd, rlogind security • As part of a request for service a username is sent by the client. • The username must be valid on the server! Netprog: Security

  14. rshd security • check client’s address for reserved port if not a reserved port – reject request. • check for password entry on server for specified user. if not a valid username – reject request. Netprog: Security

  15. rshd security (cont.) • check /etc/hosts.equiv for client’s IP address. if found – process request. • check users ~/.rhosts for client's IP address. if found – process request, otherwise reject. Netprog: Security

  16. rexecd security client sends username and password to server as part of the request (plaintext). • check for password entry on server for user name. • encrypt password and check for match. rexecd is rarely used! Netprog: Security

  17. rlogind security • Just like rshd. • If trusted host (user) not found – prompts for a password. Netprog: Security

  18. Special Cases • If username is root requests are treated as a special case: • look at /.rhosts • often disabled completely. Netprog: Security

  19. TCP Wrapper • TCP wrapper is a simple system that provides some firewall-like functionality. • A single host (really just a few services) is isolated from the rest of the world. • Functionality includes logging of requests for service and access control. Netprog: Security

  20. TCP Wrapper Picture Single Host TCP wrapper (tcpd) TCP based Servers TCP Ports The World Netprog: Security

  21. tcpd • The tcpd daemon checks out incoming TCP connections before the real server gets the connection. • tcpd can find out source IP address and port number (authentication). Netprog: Security

  22. tcpd (cont.) • A log message can be generated indicating the service name, client address and time of connection. • tcpd can use client addresses to authorize each service request. Netprog: Security

  23. Typical tcpd setup SuperServer • inetd (the ) is told to start tcpd instead of the real server. • tcpd checks out the client by calling getpeername on descriptor 0. • tcpd decides whether or not to start the real server (by calling exec). Netprog: Security

  24. tcpd configuration • The configuration files for tcpd specify which hosts are allowed/denied which services. • Entire domains or IP networks can be permitted or denied easily. • tcpd can be told to perform RFC931 lookup to get a username. Netprog: Security

  25. Secret Key Cryptography • Single key used to encrypt and decrypt. • Key must be known by both parties. • Assuming we live in a hostile environment (otherwise - why the need for cryptography?), it may be hard to share a secret key. Netprog: Cryptgraphy

  26. Public Key Cryptography(a.k.a. asymmetric cryptography) • Relatively new field - 1975 (as far as we know, the NSA is not talking). • Each entity has 2 keys: • private key (a secret) • public key (well known). Netprog: Cryptgraphy

  27. Using Keys • Private keys are used for decrypting. • Public keys are used for encrypting. encryption plaintext ciphertext public key decryption ciphertext plaintext private key Netprog: Cryptgraphy

  28. Digital Signature • Public key cryptography is also used to provide digital signatures. signing plaintext signed message private key verification signed message plaintext public key Netprog: Cryptgraphy

  29. Transmitting over an insecure channel. Alice wants to send Bob a private message. Apublicis Alice’s public key. Aprivateis Alice’s private key. Bpublicis Bob’s public key. Bprivateis Bob’s private key. Netprog: Cryptgraphy

  30. Hello Bob,Wanna get together? Alice Bob encrypt using Bpublic decrypt using Bprivate Netprog: Cryptgraphy

  31. OK Alice,Your place or mine? Alice Bob decrypt using Aprivate encrypt using Apublic Netprog: Cryptgraphy

  32. Bob’s Dilemma • Nobody can read the message from Alice, but anyone could produce it. • How does Bob know that the message was really sent from Alice? • Bob may be comforted to know that only Alice can read his reply. Netprog: Cryptgraphy

  33. Alice can sign her message! • Alice can create a digital signature and prove she sent the message (or someone with knowledge of her private key). • The signature can be a message digest encrypted with Aprivate. Netprog: Cryptgraphy

  34. Message Digest • Also known as “hash function” or “one-way transformation”. • Transforms a message of any length and computes a fixed length string. • We want it to be hard to guess what the message was given only the digest. • Guessing is always possible. Netprog: Cryptgraphy

  35. Alice’s Signature • Alice feeds her original message through a hash function and encrypts the message digest with Aprivate. • Bob can decrypt the message digest using Apublic. • Bob can compute the message digest himself. • If the 2 message digests are identical, Bob knows Alice sent the message. Netprog: Cryptgraphy

  36. Revised Scheme Alice Bob Sign with Aprivate check signature using Apublic decrypt using Bprivate encrypt using Bpublic Netprog: Cryptgraphy

  37. Why the digest? • Alice could just encrypt her name, and then Bob could decrypt it with Apublic. • Why wouldn’t this be sufficient? Netprog: Cryptgraphy

  38. Implications • Suppose Alice denies she sent the message? • Bob can prove that only someone with Alice’s key could have produced the message. Netprog: Cryptgraphy

  39. Another possible problem • Suppose Bill receives a message from Alice including a digital signature. “meet me at the library tonight” • Bill sends the same message to Joe so that it looks like the message came from Alice. • Bill includes the digital signature from the message Alice sent to him. • Joe is convinced Alice sent the message! Netprog: Cryptgraphy

  40. Solution? • Always start your messages with: • Dear Bill, • Create a digest from the encrypted message and sign that digest. • There are many other schemes as well. Netprog: Cryptgraphy

  41. Speed • Secret key encryption/decryption algorithms are much faster than public key algorithms. • Many times a combination is used: • use public key cryptography to share a secret key. • use the secret key to encrypt the bulk of the communication. Netprog: Cryptgraphy

  42. Secure Protocols • There are a growing number of applications for secure protocols: • email • electronic commerce • electronic voting • homework submission Netprog: Cryptgraphy

  43. Secure Protocols • Many application protocols include the use of cryptography as part of the application level protocol. • The cryptographic scheme employed is part of the protocol. • If stronger cryptographic tools become available we need to change the protocol. Netprog: Cryptgraphy

  44. SSL and TLS • Secure Sockets Layer (SSL) is a different approach - a new layer is added that provides a secure channel over a TCP only link. • TLS is Transport Layer Security (IETF standard based on SSL). Netprog: Cryptgraphy

  45. Application Application SSL SSL TCP TCP IP IP SSL layer Netprog: Cryptgraphy

  46. Advantages of SSL/TLS • Independent of application layer • Includes support for negotiated encryption techniques. • easy to add new techniques. • Possible to switch encryption algorithms in the middle of a session. Netprog: Cryptgraphy

  47. HTTPS Usage • HTTPS is HTTP running over SSL. • used for most secure web transactions. • HTTPS server usually runs on port 443. • Include notion of verification of server via a certificate. • Central trusted source of certificates. Netprog: Cryptgraphy

  48. Kerberos • Part of project Athena (MIT). • Trusted 3rd party authentication scheme. • Assumes that hosts are not trustworthy. • Requires that each client (each request for service) prove it’s identity. • Does not require user to enter password every time a service is requested! Netprog: Kerberos

More Related