1. Network Security in Layers Dr. Moutasem Shafa’amry t_mshafaamri@svuonline.org Lecture 7 SVU University SW course

2. أمن الوب –أخلاقيات استخدام الانترنت والقوانين المتعلقة بها –مقدمة في أمن المعلومات التحكم بالنفاذ Access control التعمية المتناظرة وغير المتناظرة Cryptography التوقيع الرقمي Digital Signature الشهادات الرقمية Digital Certificate –بروتوكولات الانترنت : و المشاكل الأمنية فيها –برتوكولات الحماية SSL, TLS, HTTPS, PGP واستخداماتها في تطبيقات الوب –أنواع الهجوم على الوب : Cross-Site Request Forgery (CSRF)

3. Security in Layers

4. 4 Security Protocol Layers Application E-Commerce protocol/ https Application E-Mail S/MIME, PGP E-mail TCP/Higher- level net protocols SSL, TLS,SSH TCP/Higher- level net protocols Kerberos IP IPSEC IP Data Link Hardware Link Data Link Encryption Physical

5. 5 S-HTTP Designed by Terisa in response to CommerceNet RFP, –http://www.terisa.com/shttp/intro.html Predates SSL and S/MIME Security extension for HTTP (and only HTTP) Document-based: – (Pre-)signed documents » Encrypted documents Large range of algorithms and formats supported Not supported by browsers (or much else) SSH

6. 6 Originally developed in 1995 as a secure replacement for rsh, rlogin, et al (ssh = secure shell), – http://www.cs.hut.fi/ssh/ Also allows port forwarding (tunneling over SSH) Built-in support for proxies/firewalls Includes Zip-style compression Originally implemented in Finland, available worldwide SSH v2 submitted to IETF for standardisation Can be up and running in minutes SSH

7. 7 SSH Protocol Server uses two keys: – Long-term server identification key – Short-term encryption key, changed every hour Client Server  Long-term + short-term keys Double-encrypted session key   Encrypted confirmation Encrypted data  Encrypted data Long-term server key binds the connection to the server Short-term encryption key makes later recovery impossible – Short-term keys regenerated as a background task SSH

8. 8 SSH Authentication Multiple authentication mechanisms – Straight passwords (protected by SSH encryption) – RSA-based authentication (client decrypts challenge from server, returns hash to server) Plug-in authentication mechanisms, eg SecurID Developed outside US, crippled crypto not even considered: – 1024 bit RSA long-term key – 768 bit RSA short-term key (has to fit inside long-term key for double encryption) – Triple DES session encryption (other ciphers available) SSH

9. 9 DNSSEC DNS name space is divided into zones, each zone has resource records (RR’s) Owner_name Type Class TTL Rdlength Rdata – Owner = name of node – Type = RR type – A = Host address – NS = authoritative name server – CNAME = canonical name for alias – SOA = start of zone authority – PTR = domain name pointer – MX = mail exchange – Class = IN (Internet) – TTL = time for which RR may be cached DNSSEC

10. 10 DNSSEC (ctd) Name servers hold zone information – Each zone has primary and secondary servers – Secondaries perform zone transfers to obtain new data from primaries Resolvers extract information from name servers – Cached entry is returned directly – Interative query returns referral to the appropriate server – Recursive query queries other server and returns result All of these points present security vulnerabilities DNSSEC (ctd

11. 11 DNSSEC (ctd) DNSSEC splits the service into name server and zone manager – Zone manager signs zone data – Name server publishes signed data – Compromise of name server doesn’t compromise DNSSEC Resolvers need to store at least one top-level zone key DNSSEC (ctd

12. 12 DNSSEC (ctd) RR’s are extended with new types – KEY, server public key – SIG, signature on RR – NXT, chains from one name in a zone to the next – Allows authenticated denial of the existence of a name – These RR’s have signature start and end times, require coordinated clocks on hosts DNSSEC (ctd

13. 13 DNSSEC (ctd) Transaction signature guarantees the response came from a given server – Signature covers query and response Also used for – Secure zone transfer – Secure dynamic update (replaces editing the zone’s master file) – Offline update – Uses authorising dynamic update key for update – Zone data is signed later with the zone key DNSSEC (ctd

14. Application E-Commerce protocol Application E-Mail S/MIME, PGP E-mail Higher-level net protocols SSL, TLS,SSH Higher-level net protocols Kerberos TCP/IP IPSEC TCP/IP Data Link Hardware Link Data Link Encryption Physical E-mail Security: PGP and S/MIME

15. 15 Email Security Problems with using email for secure communications include – Doesn’t handle binary data – Messages may be modified by the mail transport mechanism – Trailing spaces deleted – Tabs  spaces – Character set conversion – Lines wrapper/truncated – Message headers mutate considerably in transit Data formats have to be carefully designed to avoid problems

16. 16 Outline PGP – services – message format – key management – trust management S/MIME – services – message formats – key management

17. 17 What is PGP? PGP - Pretty Good Privacy general purpose application to protect (encrypt and/or sign) files can be used to protect e-mail messages can be used by corporations as well as individuals based on strong cryptographic algorithms (IDEA, RSA, SHA-1) available free of charge at http://www.pgpi.orghttp://www.pgpi.org first version developed by Phil Zimmermann PGP is now on an Internet standards track (RFC 3156)

18. 18 PGP services messages – authentication – confidentiality – compression – e-mail compatibility – segmentation and reassembly key management – generation, distribution, and revocation of public/private keys – generation and transport of session keys and IVs PGP / services

19. 19 Message authentication based on digital signatures supported algorithms: RSA/SHA and DSS/SHA hash enc hash dec compare accept / reject mh  K snd -1 K snd mh  h sender receiver PGP / services

20. 20 Message confidentiality symmetric key encryption in CFB mode with a random session key and IV session key and IV is encrypted with the public key of the receiver supported algorithms: – symmetric: CAST, IDEA, 3DES,AES – asymmetric: RSA, ElGamal prng s.enc m K rcv sender a.enc k, iv {m} k {k, iv} Krcv PGP / services

21. 21 Compression applied after the signature – enough to store clear message and signature for later verification – it would be possible to dynamically compress messages before signature verification, but … – then all PGP implementations should use the same compression algorithm – however, different PGP versions use slightly different compression algorithms applied before encryption – compression reduces redundancy  makes cryptanalysis harder supported algorithm: ZIP PGP / services

22. 22 E-mail compatibility encrypted messages and signatures may contain arbitrary octets most e-mail systems support only ASCII characters PGP converts an arbitrary binary stream into a stream of printable ASCII characters radix 64 conversion: 3 8-bit blocks  4 6-bit blocks 070707 05050505 character encoding 6-bit value 520… 619 62+ 63/ (pad)= 0A …... 25Z 26a… 51z character encoding 6-bit value PGP / services

23. 23 Combining services X := file signature? compress X := Z(X) compress X := Z(X) encryption? radix 64 X := R64(X) radix 64 X := R64(X) generate signature X :=  (X) || X generate signature X :=  (X) || X generate envelop X := {k} Krcv || {X} k generate envelop X := {k} Krcv || {X} k yes no PGP / services

24. 24 PGP message format session key component signature message key ID of K rcv session key k timestamp key ID of K snd leading two octets of hash hash filename timestamp data { } Krcv { } Ksnd -1 { } k ZIP R64 PGP / message format

25. 25 Key IDs a user may have several public key – private key pairs – which private key to use to decrypt the session key? – which public key to use to verify a signature? transmitting the whole public key would be wasteful associating a random ID to a public key would result in management burden PGP key ID: least significant 64 bits of the public key – unique within a user with very high probability PGP / key and trust management

26. 26 Random number generation true random numbers – used to generate public key – private key pairs – provide the initial seed for the pseudo-random number generator (PRNG) – provide additional input during pseudo-random number generation pseudo-random numbers – used to generate session keys and IVs PGP / key and trust management

27. 27 True random numbers PGP maintains a 256-byte buffer of random bits each time PGP expects a keystroke from the user, it records – the time when it starts waiting (32 bits) – the time when the key was pressed (32 bits) – the value of the key stroke (8 bits) the recorded information is used to generate a key the generated key is used to encrypt the current value of the random-bit buffer PGP / key and trust management

28. 28 Pseudo-random numbers based on the ANSI X9.17 PRNG standard 3DES + + DT i ViVi V i+1 K 1, K 2 RiRi PGP / key and trust management

29. 29 Pseudo-random numbers E E E E E E + + E E E E + + E E E E + + + ++ dtbuf rseed rseed’ IV[0..7]K[8..15]K[0..7] true random bits  CAST-128 is used instead of 3DES with key rkey PGP / key and trust management

30. 30 Pseudo-random numbers dtbuf[0..3] = current time, dtbuf[4..7] = 0 pre-wash – take the hash of the message this has already been generated if the message is being signed otherwise the first 4K of the message is hashed – use the result as a key, use a null IV, and encrypt (rkey, rseed) previous in CFB mode if (rkey, rseed) previous is empty, it is filled up with true random bits – set (rkey, rseed) current to the result of the encryption post-wash – generate 24 more bytes as before but without XORing in true random bytes – encrypt the result in CFB mode using K and IV – set (rkey, rseed) previous to the result of the encryption PGP / key and trust management

31. 31 Private-key ring used to store the public key – private key pairs owned by a given user essentially a table, where each row contains the following entries: – timestamp – key ID (indexed) – public key – encrypted private key – user ID (indexed) enc passphrase hash private key encrypted private key PGP / key and trust management

32. 32 Public-key ring used to store public keys of other users a table, where each row contains the following entries: – timestamp – key ID (indexed) – public key – user ID (indexed) – owner trust – signature(s) – signature trust(s) – key legitimacy PGP / key and trust management

33. 33 Trust management owner trust – assigned by the user – possible values: unknown user usually not trusted to sign usually trusted to sign always trusted to sign ultimately trusted (own key, present in private key ring) signature trust – assigned by the PGP system – if the corresponding public key is already in the public-key ring, then its owner trust entry is copied into signature trust – otherwise, signature trust is set to unknown user PGP / key and trust management

34. 34 Trust management key legitimacy – computed by the PGP system – if at least one signature trust is ultimate, then the key legitimacy is 1 (complete) – otherwise, a weighted sum of the signature trust values is computed always trusted signatures has a weight of 1/X usually trusted signatures has a weight of 1/Y X, Y are user-configurable parameters – example: X=2, Y=4 1 ultimately trusted, or 2 always trusted, or 1 always trusted and 2 usually trusted, or 4 usually trusted signatures are needed to obtain full legitimacy PGP / key and trust management

35. 35 Example – key legitimacy X = 1, Y = 2 user A B C D E F G H I J K M L untrusted / usually untrusted usually trusted always trusted ultimately trusted (you) signature legitimate PGP / key and trust management

36. 36 Public-key revocation why to revoke a public key? – suspected to be compromised (private key got known by someone) – re-keying the owner issues a revocation certificate … – has a similar format to normal public-key certificates – contains the public key to be revoked – signed with the corresponding private key and disseminates it as widely and quickly as possible if a key is compromised: – e.g., Bob knows the private key of Alice – Bob can issue a revocation certificate to revoke the public key of Alice – even better for Alice PGP / key and trust management

37. 37 What is S/MIME? Secure / Multipurpose Internet Mail Extension a security enhancement to MIME provides similar services to PGP based on technology from RSA Security industry standard for commercial and organizational use RFC 2630, 2632, 2633 What is S/MIME?

38. 38 RFC 822 defines a format for text messages to be sent using e-mail Internet standard structure of RFC 822 compliant messages – header lines (e.g., from: …, to: …, cc: …) – blank line – body (the text to be sent) example Date: Tue, 16 Jan 1998 10:37:17 (EST) From: “Levente Buttyan” Subject: Test To: afriend@otherhost.bme.hu Blablabla S/MIME / introduction

39. 39 Problems with RFC 822 and SMTP executable files must be converted into ASCII – various schemes exist (e.g., Unix UUencode) – a standard is needed text data that includes special characters (e.g., Hungarian text) some servers – reject messages over a certain size – delete, add, or reorder CR and LF characters – truncate or wrap lines longer than 76 characters – remove trailing white space (tabs and spaces) – pad lines in a message to the same length – convert tab characters into multiple spaces S/MIME / introduction

40. 40 MIME defines new message header fields defines a number of content formats (standardizing representation of multimedia contents) defines transfer encodings that protects the content from alteration by the mail system S/MIME / introduction

41. 41 MIME - New header fields MIME-Version Content-Type – describes the data contained in the body – receiving agent can pick an appropriate method to represent the content Content-Transfer-Encoding – indicates the type of the transformation that has been used to represent the body of the message Content-ID Content-Description – description of the object in the body of the message – useful when content is not readable (e.g., audio data) S/MIME / introduction

42. 42 MIME – Content types and subtypes text/plain, text/enriched image/jpeg, image/gif video/mpeg audio/basic application/postscript, application/octet-stream multipart/mixed, multipart/parallel, multipart/alternative, multipart/digest (each part is message/rfc822) message/rfc822, message/partial, message/external- body S/MIME / introduction

43. 43 MIME – Transfer encodings 7bit – short lines of ASCII characters 8bit – short lines of non-ASCII characters binary – non-ASCII characters – lines are not necessarily short quoted-printable – non-ASCII characters are converted into hexa numbers (e.g., =EF) base64 (radix 64) – 3 8-bit blocks into 4 6-bit blocks x-token – non-standard encoding S/MIME / introduction

44. 44 MIME – Example MIME-Version: 1.0 From: Nathaniel Borenstein To: Ned Freed Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages. --unique-boundary-1 Content-type: text/plain; charset=US-ASCII … Some text … --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here... --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64... base64-encoded image data goes here... --unique-boundary-2-- S/MIME / introduction

45. 45 MIME – Example cont’d --unique-boundary-1 Content-type: text/enriched This is enriched. as defined in RFC 1896 Isn’t it cool? --unique-boundary-1 Content-Type: message/rfc822 From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in US-ASCII) Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable... Additional text in ISO-8859-1 goes here... --unique-boundary-1-- S/MIME / introduction

46. 46 S/MIME services enveloped data (application/pkcs7-mime; smime-type = enveloped-data) – standard digital envelop signed data (application/pkcs7-mime; smime-type = signed-data) – standard digital signature (“hash and sign”) – content + signature is encoded using base64 encoding clear-signed data (multipart/signed) – standard digital signature – only the signature is encoded using base64 – recipient without S/MIME capability can read the message but cannot verify the signature signed and enveloped data – signed and encrypted entities may be nested in any order S/MIME / services

47. 47 Cryptographic algorithms message digest – must: SHA-1 – should (receiver): MD5 (backward compatibility) digital signature – must: DSS – should: RSA asymmetric-key encryption – must: ElGamal – should: RSA symmetric-key encryption – sender: should: 3DES, RC2/40 – receiver: must: 3DES should: RC2/40 S/MIME / services

48. 48 Securing a MIME entity MIME entity is prepared according to the normal rules for MIME message preparation prepared MIME entity is processed by S/MIME to produce a PKCS object the PKCS object is treated as message content and wrapped in MIME S/MIME / services

49. 49 PKCS7 “signed data” Version (Set of) Digest Algorithms Content Info Set of certificates Set of CRLs Signer Info Version Signer ID (issuer and ser. no.) Digest Algorithm Authenticated Attributes Digest Encryption Alg. Encrypted digest (signature) Content type Content S/MIME / message formats

50. 50 PKCS7 “enveloped data” Version Encrypted Content Info Recipient Info Version Recipient ID (issuer and s.no.) Key Encryption Algorithm Encrypted Key Content Encryption Alg. Content type Encrypted Content Originator Info S/MIME / message formats

51. 51 Enveloped data – Example Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V S/MIME / message formats

52. 52 Clear-signed data – Example Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message. --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- S/MIME / message formats

53. 53 Key management S/MIME certificates are X.509 conformant key management scheme is between strict certification hierarchy and PGP’s web of trust – certificates are signed by certification authorities (CA) – key authentication is based on chain of certificates – users/managers are responsible to configure their clients with a list of trusted root keys K S/MIME / key management

54. Intrusion detection and Web Security

55. 55 Intrusion detection What is an intrusion or an attempted intrusion? This can be difficult to define. If someone tries to login at root once? If someone tries to login at root fifty times? Port scanning, SATAN or ISS scan? Someone trying a known security hole? The aim of an intrusion detection system is to detect break-ins in progress so that something can be done about them. Obviously the first thing one should worry about is how difficult it is to break in in the first place. If we have done the job of securing data well enough, why are we worried that anyone will be able to get in? How will we be alerted or notified about intrusions? By alarm on the screen? By E-mail or pager alert? What if the attacker first knocks out E- mail or the pager link? In 1986 Dorothy Denning published a paper "An intrusion detection model" which has been the basis of much of current thinking on the subject. Basically one audits the activities of the system, and the communications traffic on the network, looking for suspicious signatures. What is a signature? File existence/checksum violations (Viruses, Trojan horses) File permission violations Illegal processes/missing processes Intrusion detection

56. 56 Intrusion detection Packet sniffers Port scanners (nmap) Covert communications (eggdrop, irc-bots) Suspicious traffic Tampering with a honey-pot. Analyzing network traffic becomes impossible as traffic is encrypted, so this approach does not have much of a future, when IPv6 comes along. Today intrusion detectors have to try to reassemble fragmented packets to follow data streams long enough to analyze their content. This requires work at very high speed. Packets get dropped. The detectors can be fooled. They probably have exploitable bugs. Intrusion detection

57. 57 Intrusion detection There are two types of intrusion detection – Rule based intrusion detection: testing for specific occurrences, e.g. seeing whether a particular private port is accessed. – Statistical anomaly detection: looking for anything out of the ordinary, by collecting data on what `ordinary' is. What is suspicious? This requires a large knowledge-base of things which people have identified as suspicious already. Signatures are also specific to OS flavours, in practice that means you will find off-the-shelf stuff for NT and Solaris, maybe GNU/Linux. The databases need to be updated all the time to detect new signatures. Intrusion detection

58. 58 Anomaly detection anomaly detection we are looking for anything abnormal. That could come from abnormal traffic, patterns of kernel activity, changes in the statistical profiles of usage. Need some method for tracking patterns in statistical samples. Neural networks have been used for this, but the problem here is that no one really understands how neural networks work: they classify information by lumping similar things into similar categories. Neural networks first have to be trained using "normal" data, then they can be switched into production mode in order to detect anomalies. There is a coarse graining of information which means that networks throw away all but the information parameters which the network models. When a network detects a signature, there is never enough information left to be able to say why they produce the result they do! This can lead to embarrassing problems. Basically anomaly detection is an unsolved problem, but there is a lot of research into it because it is very interesting and it has the potential to solve a general problem without a rule-base. But these systems have to look at data over long periods of time and this costs a lot of data storage Intrusion detection

59. 59 Port scanning A common way for hackers to gather information about a network, is to perform a port scan. A port scanner is simply a program which attempts to establish a network connection to every single port number 1,2,3,4,5....5000,... on every host on the network. By seeing what kind of response it gets, the program is able to guess what network servives are running on which hosts. This gives hackers a good idea about what services can be exploited. Often it is also possible to see version numbers of software and thereby idetify any servers which have known security holes. Port Scanning

60. 60 Some intrusion detection tools Cfengine/Tripwire - checksums and file permissions Cfengine - other configuration issues Cfengine TCP wrappers - service requests TCP dump/snoop - net traffic Network Flight Recorder Argus

61. Site Security and checklist

62. 62 Site security and the future Zones of security clearance The first thing to decide is the nature of the organization we are trying to protect. Many companies, like banks or large cooperate empires require many levels of security. Information is provided on a need to know basis. There might be physical security checkpoints and logical security checkpoints.

63. 63 Site security and the future The enemy within... Remember that most major hacking and net crime cases have been carried out by insiders. There is a balance to be struck between trusting workers and checking their behaviour. If we are too lax, someone will try it on. If we are too strict, we will generate bad feelings and encourage staff to turn against the organization. Site Security

64. 64 Site security and the future Insecure operating systems These have no memory protection or file protection. They are trivially infected with viruses. The only thing one can do with these is to place them behind a firewall and cross your fingers. You can try to drill users to avoid making the worst mistakes with such machines, but probably you will not be able to make them understand or listen. Insecure operating systems which are used for important work should never be attached to a public network, or be available to unauthorized persons. It is difficult to trust an operating system which is wide open to attack, both from the console and from the network Site Security

65. 65 Analysis and checklist Basics – Backup, redundancy plan, recovery plan – Access controls on backup media. – One host per task is easiest to secure, but costly. – Security policy (avoid too much inconvenience to users) – Physical security of machines and the site. – Inform users about policy. (They need to understand the ramifications) – Train users against social engineering. Who do you trust on the telephone? If your boss asks you for your password, do you give it to him? Understand the trust relationships in your network. – Look at network topology: how many ways in/out are there? – How many routes in? – What access controls on routed traffic? – Honey pots, sacrificial lambs – Firewall (do not protect against data attacks) Analysis and checklist

66. 66 Analysis and checklist – Modems (don't forget these!) – Backdoors – Dependencies. Denial of service attacks. Examine the hosts on the network: – What operating systems do they run? – Are they properly configured, according to the security policy? – What security problems are known to exist on those operating systems? Analysis and checklist

67. 67 Analysis and checklist – Have the operating systems been upgraded with the latest security patches? – What access controls are in use on files? – Privacy of data with VPN, encryption or use of access rights. – Examine the setuid privileged programs on the system: do they all need to have those permissions? (e.g. removing the setuid flags from the Common Desktop Environment window system has saved us here on several occasions!) – Is software installed correctly? – Monitor permissions and configuration constantly. Analysis and checklist

68. 68 Analysis and checklist Examine network services – Look at router filters. RPC (SMB) and SNMP should not be passed outside domain. – What access rights do services run with? (Don't run privileged if you can avoid it) – What information could services be exploited to provide? – Do they have a history of software errors? – What access controls are in use? (TCP wrappers/firewalls) – What dependencies exist between services? – How safe is E-mail? Privacy? Analysis and checklist

69. 69 Analysis and checklist Authentication – Smartcards/javacards – Biometric authentication? – Digital signatures. – Kerberos Denial of service attacks – Router filters – Firewall susceptible – Intrusion detection system vulnerable – Spam? Analysis and checklist

70. 70 Analysis and checklist WWW security – Run as non-privileged user www – CGI scripts - never setuid. Check content. – CGI scripts can circumvent any.htaccess security – File permissions - data files should not be owned by www user! – Mail is always anonymous (as www user) – Use HTTPS for privacy. (e.g. mod_ssl in Apache) Analysis and checklist

71. 71 Analysis and checklist Intrusion detection to estimate how often you are being attacked. (You will never find the clever ones...) This should be the last thing you spend money on, since it is probably only for curiousity. – Look for tell-tale files: nuke rootkit cloak zap icepick toneloc.mo etc – Set up an md5 checksum database on /usr Analysis and checklist

72. 72 The future of security Who knows what the future will be bring? The need for security has always existed. What we have seen in this course is that computer security is nothing very special. It is the application of a few basic security principles to the computer arena. It is only the technological climate which focuses attention on specific issues The security problem will never be solved because it all has to do with trust. If you understand one thing from this course, it should be this: every security problem has its roots in trust. We can use technology to move trust from place to place, but we can never avoid the final judgement. – Why should we bother with security? The future of security