Transcript MWS_AWS_C2_S14_S7_20141215211736859

SVU University
SW course
Network Security in Layers
Lecture 7
Dr. Moutasem Shafa’amry
[email protected]
‫أمن الوب‬
‫•‬
‫– أخالقيات استخدام االنترنت والقوانين المتعلقة بها‬
‫– مقدمة في أمن المعلومات‬
‫•‬
‫•‬
‫•‬
‫•‬
‫التحكم بالنفاذ ‪Access control‬‬
‫التعمية المتناظرة وغير المتناظرة ‪Cryptography‬‬
‫التوقيع الرقمي ‪Digital Signature‬‬
‫الشهادات الرقمية ‪Digital Certificate‬‬
‫– بروتوكوالت االنترنت‪:‬و المشاكل األمنية فيها‬
‫– برتوكوالت الحماية ‪ SSL, TLS, HTTPS, PGP‬واستخداماتها في‬
‫تطبيقات الوب‬
‫– أنواع الهجوم على الوب‪:‬‬
‫• )‪Cross-Site Request Forgery (CSRF‬‬
Security in Layers
Security in Layers
Security Protocol Layers
Application
E-Commerce
protocol/ https
Application
E-Mail
S/MIME, PGP
E-mail
TCP/Higherlevel net
protocols
IP
SSL, TLS,SSH
IPSEC
TCP/Higherlevel net
protocols
IP
Data Link
Hardware Link
Data Link
Physical
Kerberos
Encryption
Physical
4
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
»
Large range of algorithms and formats supported
Not supported by browsers (or much else)
SSH
•
•
• Encrypted documents
5
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
•
•
•
•
•
•
6
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
–
7
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:
SSH
– • 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)
8
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
DNSSEC
•
•
•
•
•
•
– 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
9
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
DNSSEC (ctd
• All of these points present security vulnerabilities
10
DNSSEC (ctd)
• DNSSEC splits the service into name server and
zone manager
– • Zone manager signs zone data
– • Name server publishes signed data
DNSSEC (ctd
• – Compromise of name server doesn’t compromise DNSSEC
• Resolvers need to store at least one top-level zone
key
11
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
DNSSEC (ctd
• – Allows authenticated denial of the existence of a name
– • These RR’s have signature start and end times,
require coordinated clocks on hosts
12
DNSSEC (ctd)
• Transaction signature guarantees the response came from
a given server
– • Signature covers query and response
• Also used for
DNSSEC (ctd
– • 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
13
Application
E-Commerce protocol
Application
E-mail Security:
PGP and S/MIME
E-Mail
S/MIME, PGP
E-mail
Higher-level net
protocols
SSL, TLS,SSH
TCP/IP
IPSEC
TCP/IP
Data Link
Hardware Link
Data Link
Kerberos
Higher-level net
protocols
Encryption
Physical
Physical
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
15
Outline
• PGP
– services
– message format
– key management
– trust management
• S/MIME
– services
– message formats
– key management
16
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)
17
PGP services
PGP / services
• messages
– authentication
– confidentiality
– compression
– e-mail compatibility
– segmentation and reassembly
• key management
– generation, distribution, and revocation of
public/private keys
18
Message authentication
• based on digital signatures
• supported algorithms: RSA/SHA and DSS/SHA
Ksnd-1
m
receiver
PGP / services
sender
m
hash
h
h
hash
s
enc
h
compare
accept / reject
dec
s
Ksnd
19
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
– asymmetric: RSA,mElGamal
prng Krcv
sender
PGP / services
{k, iv}Krcv
s.enc
k, iv
a.enc
{m}k
20
Compression
PGP / services
• 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
21
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
PGP / services
0
5
0
0
7
5
0
0
7
5
0
5
6-bit character 6-bit character
value encoding value encoding
0
…
25
26
…
51
A
...
Z
a
…
z
52
…
61
62
63
(pad)
0
…
9
+
/
=
22
Combining services
X := file
signature?
yes
generate signature
X := s(X) || X
yes
generate envelop
X := {k}Krcv || {X}k
no
PGP / services
compress
X := Z(X)
encryption?
no
radix 64
X := R64(X)
23
PGP message format
key ID of Krcv
session key k
{ }Krcv
session key
component
timestamp
key ID of Ksnd
leading two octets of hash
R64
timestamp
{ }k
filename
ZIP
PGP / message format
hash
{ }Ksnd-1
signature
message
data
24
Key IDs
PGP / key and trust management
• 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
25
Random number generation
PGP / key and trust management
• 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
26
True random numbers
PGP / key and trust management
• 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
27
Pseudo-random numbers
PGP / key and trust management
K1, K
• based on the ANSI X9.17
PRNG
standard
2
DTi
3DES
+
Vi
+
3DES
Vi+1
3DES
Ri
28
Pseudo-random numbers
PGP / key and trust management
dtbuf
E
+
rseed
true
random
bits
+
E
E
+
+
E
E
+
+
E
rseed’
E
+
+
+
IV[0..7]
K[8..15]
K[0..7]
 CAST-128 is used instead of 3DES with key rkey
29
Pseudo-random numbers
PGP / key and trust management
• 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
30
PGP / key and trust management
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
private key
– user ID (indexed)
passphrase
hash
enc
encrypted private key
31
Public-key ring
PGP / key and trust management
• 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
32
Trust management
PGP / key and 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
33
Trust management
PGP / key and 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
34
Example – key legitimacy
X = 1, Y = 2

PGP / key and trust management
G
C
H
B


D
user
F
untrusted / usually untrusted

A
I
E

K
usually trusted
always trusted


L
J
M
ultimately trusted (you)
signature

legitimate
35
Public-key revocation
PGP / key and trust management
• 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
36
What is S/MIME?
•
•
•
•
•
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
37
RFC 822
S/MIME / introduction
• 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” <[email protected]>
Subject: Test
To: [email protected]
Blablabla
38
Problems with RFC 822 and SMTP
S/MIME / introduction
• 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
39
MIME
S/MIME / introduction
• 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
40
MIME - New header fields
S/MIME / introduction
• 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)
41
MIME – Content types and
subtypes
•
•
•
•
•
•
S/MIME / introduction
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/externalbody
42
MIME – Transfer encodings
S/MIME / introduction
• 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
43
MIME – Example
MIME-Version: 1.0
From: Nathaniel Borenstein <[email protected]>
To: Ned Freed <[email protected]>
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.
S/MIME / introduction
--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--
44
MIME – Example cont’d
--unique-boundary-1
Content-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>
S/MIME / introduction
--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--
45
S/MIME services
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 46
Cryptographic algorithms
S/MIME / services
• 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
47
Securing a MIME entity
S/MIME / services
• 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
48
PKCS7 “signed data”
Version
(Set of) Digest Algorithms
Content type
Content Info
S/MIME / message formats
Content
Set of certificates
Version
Set of CRLs
Signer ID (issuer and ser. no.)
Digest Algorithm
Signer Info
Authenticated Attributes
Digest Encryption Alg.
Encrypted digest (signature)
49
PKCS7 “enveloped data”
Version
Originator Info
Version
Recipient ID (issuer and s.no.)
S/MIME / message formats
Recipient Info
Key Encryption Algorithm
Encrypted Key
Encrypted Content Info
Content type
Content Encryption Alg.
Encrypted Content
50
Enveloped data – Example
S/MIME / message formats
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
51
Clear-signed data – Example
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
S/MIME / message formats
--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-52
Key management
S/MIME / 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
53
Intrusion detection and Web
Security
Intrusion detection
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 Email 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
55
Intrusion detection
•
•
•
•
•
•
•
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.
56
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.
Intrusion detection
• 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.
57
Intrusion detection
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
58
Port scanning
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.
59
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
60
Site Security and checklist
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.
62
Site security and the future
Site Security
• 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.
63
Site security and the future
Site Security
• 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
64
Analysis and checklist
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)
65
Analysis and checklist
– Modems (don't forget these!)
– Backdoors
– Dependencies. Denial of service attacks.
Analysis and checklist
• 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?
66
Analysis and checklist
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.67
Analysis and checklist
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?
68
– How safe is E-mail? Privacy?
Analysis and checklist
Analysis and checklist
• Authentication
– Smartcards/javacards
– Biometric authentication?
– Digital signatures.
– Kerberos
• Denial of service attacks
– Router filters
– Firewall susceptible
– Intrusion detection system vulnerable
– Spam?
69
Analysis and checklist
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)
70
Analysis and checklist
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
71
The future of security
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?
72