Network Security in LayersNetwork Security in Layers

Dr. Moutasem Shafa’amry t_mshafaamri@svuonline.org

Lecture 7Lecture 7

SVU UniversitySVU UniversitySW courseSW course

الوب أمن• 

المتعلقة – والقوانين االنترنت استخدام أخالقياتبها

المعلومات – أمن في مقدمةبالنفاذ • Access controlالتحكمالمتناظرة • وغير المتناظرة Cryptographyالتعميةالرقمي • Digital Signatureالتوقيعالرقمية • Digital Certificateالشهادات

– : فيها األمنية المشاكل و االنترنت بروتوكوالتالحماية – SSL, TLS, HTTPS, PGPبرتوكوالت

الوب تطبيقات في واستخداماتها–: الوب على الهجوم أنواع

•Cross-Site Request Forgery (CSRF)

Security in Layers

Secu

rity

in L

ayer

s

4

Security Protocol LayersApplication E-Commerce

protocol/ httpsApplication

E-Mail S/MIME, PGP E-mail

TCP/Higher-level net

protocols

SSL, TLS,SSH TCP/Higher-level net

protocolsKerberos

IP IPSEC IP

Data Link Hardware Link Data LinkEncryption

Physical Physical

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

SSH

• 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

SSH Protocol• Server uses two keys:

– • Long-term server identification key– • Short-term encryption key, changed every hour

Client Server Long-term + short-term keysDouble-encrypted sessionkey

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

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

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

DN

SSE

C

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

DN

SSE

C (c

td

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

DN

SSE

C (c

td

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

DN

SSE

C (c

td

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

DN

SSE

C (c

td

Application E-Commerce protocol Application

E-Mail S/MIME, PGP E-mail

Higher-level net protocols

SSL, TLS,SSHHigher-level net

protocolsKerberos

TCP/IP IPSEC TCP/IP

Data Link Hardware Link Data Link

Encryption

Physical Physical

E-mail Security:PGP and S/MIME

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

Outline • PGP

– services– message format– key management– trust management

• S/MIME– services– message formats– key management

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.org• first version developed by Phil Zimmermann• PGP is now on an Internet standards track (RFC 3156)

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

/ ser

vice

s

19

Message authentication• based on digital signatures• supported algorithms: RSA/SHA and DSS/SHA

hash enc

hash deccompare

accept / reject

m h

Ksnd-1

Ksnd

m h h

send

erre

ceiv

er

PGP

/ ser

vice

s

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

mKrcv

send

er a.enck, iv

{m}k

{k, iv}Krcv

PGP

/ ser

vice

s

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

/ ser

vice

s

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

0 7 0 7 0 7

0 5 0 5 0 5 0 5

characterencoding

6-bitvalue

52 0… …61 962 +63 /(pad) =

0 A… ...25 Z26 a… …51 z

characterencoding

6-bitvalue

PGP

/ ser

vice

s

23

Combining servicesX := file

signature?

compressX := Z(X)

encryption?

radix 64X := R64(X)

generate signatureX := (X) || X

generate envelopX := {k}Krcv || {X}k

yes

yes

no

no

PGP

/ ser

vice

s

24

PGP message formatsession keycomponent

signature

message

key ID of Krcv

session key k

timestampkey ID of Ksnd

leading two octets of hash

hash

filenametimestamp

data

{ }Kr

cv{ }

Ksnd

-1

{ }k

ZIP

R64

PGP

/ mes

sage

form

at

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

trus

t man

agem

ent

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

trus

t man

agem

ent

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

trus

t man

agem

ent

28

Pseudo-random numbers

• based on the ANSI X9.17 PRNG standard

3DES

3DES

3DES

+

+

DTi

Vi

Vi+1

K1, K2

Ri

PGP

/ key

and

trus

t man

agem

ent

29

Pseudo-random numbersE

EE+

+ EE+

+ EE+

+

+ + +

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

trus

t man

agem

ent

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

trus

t man

agem

ent

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)

encpassphrase hash

private key

encrypted private key

PGP

/ key

and

trus

t man

agem

ent

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

trus

t man

agem

ent

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

trus

t man

agem

ent

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

trus

t man

agem

ent

35

Example – key legitimacyX = 1, Y = 2

user

A

B

C

D

E

F

G H

I

J

K

ML

untrusted / usually untrusted

usually trusted

always trusted

ultimately trusted (you)

signature

legitimate

PGP

/ key

and

trus

t man

agem

ent

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

trus

t man

agem

ent

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

Wha

t is

S/M

IME

?

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” <buttyan@hit.bme.hu>Subject: TestTo: afriend@otherhost.bme.hu

Blablabla

S/M

IME

/ in

trod

uctio

n

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/M

IME

/ in

trod

uctio

n

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/M

IME

/ in

trod

uctio

n

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/M

IME

/ in

trod

uctio

n

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/M

IME

/ in

trod

uctio

n

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/M

IME

/ in

trod

uctio

n

44

MIME – Example MIME-Version: 1.0From: Nathaniel Borenstein <nsb@nsb.fv.com>To: Ned Freed <ned@innosoft.com>Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)Subject: A multipart exampleContent-Type: multipart/mixed; boundary=unique-boundary-1

This is the preamble area of a multipart message. Mail readers that understand multipart formatshould 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-1Content-type: text/plain; charset=US-ASCII

… Some text …

--unique-boundary-1Content-Type: multipart/parallel; boundary=unique-boundary-2

--unique-boundary-2Content-Type: audio/basicContent-Transfer-Encoding: base64

... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here ...

--unique-boundary-2Content-Type: image/jpegContent-Transfer-Encoding: base64

... base64-encoded image data goes here ...

--unique-boundary-2--

S/M

IME

/ in

trod

uctio

n

45

MIME – Example cont’d--unique-boundary-1Content-type: text/enriched

This is <bold><italic>enriched.</italic></bold><smaller>as defined in RFC 1896</smaller>Isn’t it <bigger><bigger>cool?</bigger></bigger>

--unique-boundary-1Content-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-1Content-Transfer-Encoding: Quoted-printable

... Additional text in ISO-8859-1 goes here ...

--unique-boundary-1--

S/M

IME

/ in

trod

uctio

n

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/M

IME

/ se

rvic

es

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/M

IME

/ se

rvic

es

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/M

IME

/ se

rvic

es

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/M

IME

/ m

essa

ge fo

rmat

s

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/M

IME

/ m

essa

ge fo

rmat

s

51

Enveloped data – Example Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7mContent-Transfer-Encoding: base64Content-Disposition: attachment; filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT67n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9Hf8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF40GhIGfHfQbnj756YT64V

S/M

IME

/ m

essa

ge fo

rmat

s

52

Clear-signed data – Example Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42

--boundary42Content-Type: text/plain

This is a clear-signed message.

--boundary42Content-Type: application/pkcs7-signature; name=smime.p7sContent-Transfer-Encoding: base64Content-Disposition: attachment; filename=smime.p7s

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF47GhIGfHfYT64VQbnj756

--boundary42--

S/M

IME

/ m

essa

ge fo

rmat

s

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/M

IME

/ ke

y m

anag

emen

t

Intrusion detection and Web Security

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

Intr

usio

n de

tect

ion

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.

Intr

usio

n de

tect

ion

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.

Intr

usio

n de

tect

ion

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

Intr

usio

n de

tect

ion

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

Sca

nnin

g

60

Some intrusion detection tools

• Cfengine/Tripwire - checksums and file permissions • Cfengine - other configuration issues • TCP wrappers - service requests • TCP dump/snoop - net traffic • Network Flight Recorder • Argus

Site Security and checklist

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

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

Sec

urity

64

Site security and the future

• Insecure operating systemsThese 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

Sec

urity

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)

Ana

lysi

s an

d ch

eckl

ist

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?

Ana

lysi

s an

d ch

eckl

ist

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.

Ana

lysi

s an

d ch

eckl

ist

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?

Ana

lysi

s an

d ch

eckl

ist

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?

Ana

lysi

s an

d ch

eckl

ist

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)

Ana

lysi

s an

d ch

eckl

ist

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

Ana

lysi

s an

d ch

eckl

ist

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

futu

re o

f sec

urity