SSH Sentinel 1.3.2 User Manual

Transcription

SSH Sentinel 1.3.2
User Manual
11 June, 2002
This document describes the SSH Sentinel software, an IPSec client
product by SSH Communications Security Corp, providing secure communications over a TCP/IP connection.
2
© 2000-2002 SSH Communications Security Corp.
No part of this publication may be reproduced, published, stored in an
electronic database, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, for any purpose, without
the prior written permission of SSH Communications Security Corp.
This software is protected by international copyright laws. All rights
reserved. ssh® is a registered trademark of SSH Communications Security Corp in the United States and in certain other jurisdictions. SSH2,
the SSH logo, IPSEC Express, SSH Certifier, SSH Sentinel, SSH NAT
Traversal, IPSEC on silicon, Hypermode, SSH Complete VPN, SSH
Accession, SSH Token Master, SSH Secure Shell and Making the Internet Secure are trademarks of SSH Communications Security Corp and
may be registered in certain jurisdictions. All other names and marks
are property of their respective owners.
THERE IS NO WARRANTY OF ANY KIND FOR THE ACCURACY
OR USEFULNESS OF THIS INFORMATION EXCEPT AS
REQUIRED BY APPLICABLE LAW OR EXPRESSLY AGREED IN
WRITING.
SSH Communications Security Corp.
Fredrikinkatu 42
FIN-00100 Helsinki
FINLAND
SSH Communications Security Inc.
1076 East Meadow Circle
Palo Alto, CA 94303
USA
SSH Communications Security K.K.
House Hamamatsu-cho Bldg. 5F
2-7-1 Hamamatsu-cho, Minato-ku
Tokyo 105-0013, JAPAN
http://www.ssh.com/
[email protected] (sales), [email protected] (technical support)
+358 20 500 7030 (Finland), +1 650 251 2700 (USA), +81 3 3459 6830
(Japan)
+358 20 500 7031 (Finland), +1 650 251 2701 (USA), +81 3 3459 6825
(Japan)
© 2002 SSH Communications Security Corp
SSH Sentinel User Manual
3
1
2
3
4
5
6
Introduction
1.1
About SSH Sentinel . . . . . . .
1.2
About This Document . . . . . .
1.3
Internet Protocol . . . . . . . . .
1.4
IPSec, Internet Protocol Security
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
.7
.7
.8
.8
Installing and Removing SSH Sentinel
2.1
Requirements . . . . . . . . . . . . . . . . . .
2.2
Installing SSH Sentinel . . . . . . . . . . . .
2.2.1 Starting the Installation . . . . . . . . .
2.2.2 Generating the Authentication Key Pair
2.2.3 Identity Information . . . . . . . . . .
2.2.4 Choosing the Enrollment Protocol . . .
2.2.5 Encryption Speed Diagnostics . . . . .
2.2.6 Completing the Installation . . . . . . .
2.3
Updating SSH Sentinel . . . . . . . . . . . . .
2.4
Removing SSH Sentinel . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
12
13
13
14
15
15
15
Policy Editor
3.1
SSH Sentinel Software Componenets
3.2
SSH Sentinel Agent . . . . . . . . .
3.3
Opening Policy Editor . . . . . . . .
3.4
Using Policy Editor . . . . . . . . .
3.4.1 Security Policy . . . . . . . .
3.4.2 Key Management . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
19
19
20
20
Managing Multiple Policies
4.1
Multiple Policies . . . . . . . . . . . . . . .
4.2
Managing Policies . . . . . . . . . . . . . .
4.2.1 Adding Policies . . . . . . . . . . . .
4.2.2 Removing Policies . . . . . . . . . .
4.2.3 Viewing and Editing Policy Properties
4.2.4 Activating Policies . . . . . . . . . .
4.3
Policy Properties . . . . . . . . . . . . . . .
4.3.1 General Properties . . . . . . . . . .
4.3.2 Sharing Properties . . . . . . . . . .
4.4
Trusted Policy Servers . . . . . . . . . . . .
4.4.1 What Are Trusted Policy Servers . . .
4.4.2 Managing Trusted Policy Servers . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
21
21
22
22
23
23
23
24
24
24
25
Configuring Policy Rules
5.1
Security Policy Rules . . . . . . . . . .
5.1.1 Traffic Filters . . . . . . . . . . .
5.1.2 IPSec Rules . . . . . . . . . . . .
5.1.3 Default Response Rule . . . . . .
5.2
Establishing Connections . . . . . . . .
5.3
Internet Key Exchange . . . . . . . . . .
5.4
Security Associations . . . . . . . . . .
5.5
Evaluating Rules . . . . . . . . . . . . .
5.5.1 Managing Outgoing Data Packets
5.5.2 Managing Incoming Data Packets
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
27
28
28
28
28
29
29
29
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Traffic Filters
33
6.1
What Is a Traffic Filter? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4
6.2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
34
34
35
35
35
36
36
37
37
IPSec-Protected Connections
7.1
What Are IPSec-Protected Connections? . . . . . .
7.1.1 Virtual Private Network (VPN) Connections
7.1.2 Secured Connections . . . . . . . . . . . . .
7.1.3 Secured Networks . . . . . . . . . . . . . .
7.2
Managing Connection Rules . . . . . . . . . . . . .
7.2.1 Adding VPN Connection Rules . . . . . . .
7.2.2 Adding Secured Connection Rules . . . . . .
7.2.3 Adding Secured Network Rules . . . . . . .
7.2.4 Removing Rules . . . . . . . . . . . . . . .
7.2.5 Viewing and Editing Rules . . . . . . . . . .
7.2.6 Testing Connections . . . . . . . . . . . . .
7.2.7 Enabling and Disabling Rules . . . . . . . .
7.2.8 Auditing Rules . . . . . . . . . . . . . . . .
7.2.9 Opening VPN Connections . . . . . . . . . .
7.3
Rule Properties . . . . . . . . . . . . . . . . . . . .
7.3.1 General Properties . . . . . . . . . . . . . .
7.3.2 Advanced Properties . . . . . . . . . . . . .
7.3.3 Proposal Parameters . . . . . . . . . . . . .
7.3.4 Security Association Lifetimes . . . . . . .
7.3.5 Virtual IP Address . . . . . . . . . . . . . .
7.3.6 Extended Authentication . . . . . . . . . . .
7.3.7 Network Editor . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
39
40
41
41
41
42
42
43
44
44
44
45
45
45
46
47
49
50
52
52
Default Response Rule
8.1
What Is the Default Response ? . . . . . . . . . . .
8.2
Managing Default Response Rule . . . . . . . . . .
8.2.1 Viewing and Editing Default Response Rule
8.2.2 Auditing Default Response Rule . . . . . . .
8.3
IPSec Response . . . . . . . . . . . . . . . . . . .
8.3.1 Audit Options . . . . . . . . . . . . . . . . .
8.4
IP Traffic Handler . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
53
53
53
54
54
55
Authentication Key Management
9.1
What Is Authentication . . . . . . . . . .
9.1.1 Authentication Keys . . . . . . .
9.1.2 Certification Authorities . . . . .
9.1.3 Self-signed Certificates . . . . . .
9.1.4 Exchanging Authentication Keys .
9.2
Key Management . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
57
57
58
58
59
59
6.3
7
8
9
10
Managing Filter Rules . . . . . . . . .
6.2.1 Adding Rules . . . . . . . . . .
6.2.2 Removing Rules . . . . . . . .
6.2.3 Viewing and Editing Rules . . .
6.2.4 Modifying the Evaluation Order
6.2.5 Enabling and Disabling Rules .
6.2.6 Auditing Rules . . . . . . . . .
Filter Rule Properties . . . . . . . . . .
6.3.1 General Properties . . . . . . .
6.3.2 Advanced Properties . . . . . .
6.3.3 Network Editor . . . . . . . . .
Managing My Keys
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
5
10.1
10.2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 61
. 61
. 61
. 62
. 64
. 64
. 64
. 65
. 65
. 66
. 66
. 66
Certificate Management
11.1 What Is a Certificate? . . . . . . . . . . . . . . .
11.2 Managing Certificates . . . . . . . . . . . . . . .
11.2.1 Importing Certificates . . . . . . . . . . .
11.2.2 Exporting Certificates . . . . . . . . . . .
11.2.3 Renaming Certificates . . . . . . . . . . .
11.2.4 Removing Certificates . . . . . . . . . . .
11.2.5 Viewing Certificate Information . . . . . .
11.2.6 Viewing and Editing Certificate Properties .
11.3 Certificate Information . . . . . . . . . . . . . . .
11.4 Certificate Properties . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
69
. 69
. 69
. 69
. 71
. 71
. 71
. 72
. 72
. 72
. 74
Directory Services
12.1 What Are Directory Services? . . . . . . . . .
12.2 Managing Directory Services . . . . . . . . .
12.2.1 Adding Directory Services . . . . . . .
12.2.2 Viewing and Editing Directory Services
12.2.3 Removing Directory Services . . . . .
12.3 Directory Service Properties . . . . . . . . . .
12.3.1 General Properties . . . . . . . . . . .
12.3.2 Advanced Properties . . . . . . . . . .
12.3.3 Proxy and Socks Settings . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
. 77
. 77
. 77
. 78
. 78
. 79
. 79
. 79
. 79
Maintenance
13.1 Auditing . . . . . . . . . .
13.1.1 Auditing Rules . . .
13.1.2 Audit Settings . . . .
13.1.3 Viewing Audit Logs
13.2 IKE Log . . . . . . . . . .
13.3 Connection Diagnostics . .
13.4 Statistics . . . . . . . . . .
13.4.1 Security Associations
13.4.2 IPSec Statistics . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
. 81
. 81
. 82
. 83
. 84
. 85
. 85
. 86
. 86
10.3
11
12
13
14
What Are My Keys? . . . . . . . . . . . . . . .
Managing My Certificates . . . . . . . . . . . .
10.2.1 Accession Keys . . . . . . . . . . . . . .
10.2.2 Creating Certificates . . . . . . . . . . .
10.2.3 Importing Certificates . . . . . . . . . .
10.2.4 Removing the Default Identity Certificate
10.2.5 Polling Certification Requests . . . . . .
Managing Pre-Shared Keys. . . . . . . . . . . .
10.3.1 Creating Pre-Shared Keys . . . . . . . .
10.3.2 Viewing and Editing Pre-Shared Keys . .
10.3.3 Removing Pre-Shared Keys . . . . . . .
10.3.4 Pre-Shared Key Properties . . . . . . . .
Glossary
15
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
Index 101
6
Chapter 1 Introduction
7
1.1
About SSH Sentinel
SSH Sentinel is a software product to secure the network communications of a Windows workstation. The
IP (Internet Protocol) traffic is protected using the IPSec (Internet Protocol Security) protocol as specified
by Internet Engineering Task Force (IETF) standards.
SSH Sentinel is a client-type IPSec application designed for a single user workstation. Important network
connection, like remote access to corporate network, remote administration, file transfer, sending and receiving email (SMTP, POP) and IP telephony can be effectively secured with it. It supports all network connection types, including dial-up.
Although an end-user software designed for a single workstation, SSH Sentinel scales easily up to corporate
use. It functions well in a public-key infrastructure (PKI) and supports central policy management.
SSH Sentinel is currently available to the the following Microsoft Windows operating systems: Windows
95, Windows 98, Windows NT4, Windows Me, Windows 2000 and Windows XP.
Designed for end users, using SSH Sentinel is easy. Key characteristics include intuitive installation and
configuration, as well as a simple way to use certificates for authentication. As a product, it is secure, robust,
and quick to adapt to the network environment at hand.
SSH Sentinel was implemented due to numerous customer and end-user requests to bring out a real IPSec
solution for commercial platforms and to enable full-scale network encryption with strong authentication.
1.2
About This Document
This document gives instructions on the installation and use of SSH Sentinel and is intended for end users
that administrate their own workstations and for system administrators. In addition to simple step-by-step
how-to instructions the document is intended to give background on the security issues.
The document contains the following information:
•
an introduction to the aspects of security policy
•
installing SSH Sentinel
•
configuring filter rules and connection rules
•
managing authentication keys
8
•
troubleshooting
To use the information in this document, you should be familiar with your operating system (Windows) and
the basics of network communications.
For any important last minute information, refer to the SSH Sentinel relese notes. More information, like
answers to frequently asked questions and configuration examples are published by the SSH Sentinel support in http://www.ssh.com/support/sentinel.
1.3
Internet Protocol
The open architecture of the Internet Protocol (IP) makes it a highly efficient, cost-effective and flexible protocol for local and global communications. It is widely adopted, not only on the global Internet, but also in
the internal networks of large corporations.
The Internet Protocol was designed to be highly reliable against random network errors. However, it was not
designed to be secure against a malicious attacker. In fact, it is notorious for being vulnerable to a number of
well-known attacks. This prevents it from being used to its fullest for business and other purposes involving
transmission of confidential data. The most common types of attacks include:
•
Eavesdropping on a transmission, for example, looking for passwords, credit card numbers, or business
secrets.
•
Taking over communications, or hijacking communications, in such a way that the attacker can inspect
and modify any data being transmitted between the communicating parties.
•
Faking network addresses, also known as IP spoofing, in order to fool access control mechanisms based
on network addresses, or to redirect connections to a fake server.
1.4
IPSec, Internet Protocol Security
Internet Engineering Task Force (IETF) has developed the Internet Protocol Security (IPSec) protocol suite
to prevent misuse and attacks on IP. IETF is an international standards body with representation from hundreds of leading companies, universities, and individuals developing Internet-related technologies. Its track
record includes the Internet Protocol itself and most of the other protocols and technologies that form the
backbone of the Internet.
The IPSec protocol suite adds security to the basic IP version 4 protocol and is supported by all leading vendors of Internet products. IPSec is a mandatory part of the next generation of IP protocol, IP version 6.
The IPSec protocol works on the network level. It adds authentication and encryption to each data packets
transmitted. It protects packets against eavesdropping and modification, and provides authentication of the
origin of the packet.
IPSec works independently of the application protocol. Thus, all applications that use IP protocol for data
transfer are equally and transparently protected. IPSec makes it safe to use the Internet for transmitting confidential data. By doing so, it solves the main obstacle that is slowing down the adoption of the Internet for
business use.
However, IPSec alone does not solve the security problems in operating systems and network applications. It
often offers some protection against these problems, and often makes a break-in attempt much more trace-
9
able. Nonetheless, it must still be understood that operating system and application security cannot be overlooked. Furthermore, for smooth operation, IPSec requires a public key infrastructure. Such infrastructures
are still in their infancy, and wide-scale key infrastructures are just emerging on the Internet. All in all, the
management of security policies and access policies is an extremely complicated field, and there are no
magical solutions.
IPSec does, however, solve some of the most critical Internet security problems. It renders most of the commonly used attack methods completely ineffective. It does this by providing confidentiality, integrity and
authentication of traffic.
10
Chapter 2 Installing and Removing SSH Sentinel
11
Chapter 2 Installing and Removing SSH
Sentinel
2.1
Requirements
SSH Sentinel is available to the most popular Microsoft Windows platforms. The supported platforms are
listed in the table below.
Platform
Windows 95
Windows 98
Windows NT 4.0
Windows Me
Windows 2000
Windows XP
Version
OSR1, OSR2
SE
SP3 to SP6
SP1 and SP2
Home, Professional
Notes
Winsock2 required
Interner Explorer 4.0 or newer required
-
Before updating the Windows version on your computer, from Windows NT to 2000, for example, remove
SSH Sentinel and reinstall the software after updating the operating system.
SSH Sentinel is a client-type implementation of IPSec, not an IPSec-gateway software, even though some
of the Windows platforms are able to function as routers.
Before starting the SSH Sentinel installation, make sure that there are no other IPSec implementations, network sniffers, NAT applications, firewalls, or third-party intermediate network drivers installed. SSH Sentinel may affect the functionality of such software.
The recommended minimum configuration of a personal computer to run SSH Sentinel is:
Processor
Memory (RAM)
Hard disk space
Network connection
Pentium 100 MHz
32 MB for Windows 9x, or 64 MB for Windows NT4/2000
30 MB of free disk space
TCP/IP network protocol
The SSH Sentinel installation requires you to have full access rights to the system files on your computer.
On Windows NT, you have to log in with administrator rights.
The installation can only be performed on the local computer. Remote installation of SSH Sentinel is not
possible, because the installation program updates kernel mode components related to networking and
remote access.
12
2.2
Installing SSH Sentinel
When you install the SSH Sentinel software on your computer the following is accomplished:
•
An authentication key pair is created.
•
A self-signed certificate related to the key pair is created. It is considered the default identity certificate.
•
(Optional) A certificate request to a certification authority is created.
•
An initial rule set and trust policy is configured.
2.2.1
Starting the Installation
To begin the installation, double-click the SSH Sentinel installation package icon (Sentinel.exe). The package can be found on the SSH Sentinel CD or in the directory where you have downloaded SSH Sentinel. The
self-extracting package will automatically initiate InstallShield software to install and set up SSH Sentinel.
The SSH Accession Lite software used for managing smart cards, is also installed as part of the procedure.
Figure 2.1 The SSH Sentinel installation package icon
The installer runs the Installation Wizard, which guides you through the process. Note: If a previous version
of the SSH Sentinel software is installed on your computer and you try to install a new version, the wizard
updates the software and the steps described here are skipped. See Section 2.3 ’Updating SSH Sentinel’.
When started, the Installation Wizard will first go through a sequence of basic installation dialogs, displaying the licensing agreement and allowing you to select the installation directory and the program folder.
Note that the installation terminates immediately if you do not accept the licensing agreement. Read the
licensing agreement thoroughly.
2.2.2 Generating the Authentication Key Pair
The SSH Sentinel Installation Wizard first generates a primary authentication key for authentication. The
primary authentication key is a 1024-bit RSA key pair that is used for digital signatures and strong authentication. The general level of security that can be provided with 1024-bit RSA authentication keys is considered military strength.
Authentication key generation begins with random seed generation. A random pool of data is collected from
the user moving the mouse or typing in random text. The data is then used as a seed to ensure that all authentication keys will be unique. With this method, the likelihood of generating two identical authentication keys
is infinitesimal.
Generating the key pair takes about 30 seconds and may momentarily use most of the central processing unit
(CPU) resources of the computer. Once the authentication key generation is complete, click the Next button
to proceed.
2.2.3
13
Identity Information
SSH Sentinel uses certificates and digital signatures as the primary authentication method. SSH Sentinel
processes certificates according to the IETF Public-key Infrastructure X.509v3 standards, allowing you to
take advantage of the public-key infrastructure (PKI). However, you can run the software as a stand-alone
product, separately from any public-key infrastructure. An identity must be associated with the authentication key pair. Use the host domain name, also referred to as the Fully Qualified Domain Name (FQDN) as
the identity whenever the host has a static domain name and it is safe to assume that a name service is available. If not, use the static IP address of the host as the identity. If neither is available, you may use an e-mail
address. However, since IPSec rules are most often bound to static domain names or IP addresses, this jeopardizes establishing IPSec-protected connections to remote hosts.
Select the primary identifier from the list. Type the actual identifier, the host domain name, the host IP
address or the administrator e-mail address in the field provided. Click Next to proceed.
2.2.4
Choosing the Enrollment Protocol
A self-signed certificate is automatically created during the installation. In addition, you can create a certification request to a certification authority. You can either enroll online, in other words create and send the
request immediately, or save the request in a file and deliver it later to the authority. If there is no certification authority available or you for some reason want to postpone the creation of the request, create only the
self-signed certificate.
On the Certificate Enrollment dialog box, choose the option
•
Create a self-signed certificate to only create the self-signed certificate. Click Next to proceed to
encryption speed diagnostics.
•
Create a certification request and enroll for a certificate immediately online to create a certification
request and enroll for it online. The self-signed certificate is also created. Click Next to proceed.
•
Create a certification request and save it in a file for later enrollment to create a certification
request and to save it in a file. The self-signed certificate is also created. Click Next to proceed.
Online Enrollment Information
If you choose to enroll online, the dialog box Certification Authority is displayed next. Fill in the information concerning the certification authority and the enrollment:
Enrollment protocol
Select the enrollment protocol from the drop-down list. Naturally, you should choose a protocol that is
supported by the certification authority. The following protocols are available: Simple Certificate
Enrollment Protocol (SCEP) and Certificate Management Protocol (CMP).
CA server address
Specify the address (URL) of the certification authority server
CA certificate
The certificate of the certification authority is needed to encrypt the certification request before sending
it to the certification authority. You can usually fetch it from the authority's Web site.
To fetch the certificate from the Web site type the (URL) address in this field. Alternatively, you can
specify the certificate name and SSH Sentinel fetches the certificate from the address specified in the
14
previous field. You can also fetch the certificate in advance and save it in a file or copy to the Clipboard.
To import it from the file, click the Browse button to locate the file, to paste from the Clipboard, select
paste from clipboard from the list.
On the Web site or pasted from the Clipboard, the certificate must be in PEM encoded format. In a file,
binary (X.509) and PEM are the alternatives.
Use proxy server
The local host is protected by a firewall and you need to configure the proxy settings. Click the Settings
button to specify the values. Note, that it must be possible to resolve the certification authority address
(URL) on the local host.
Reference number
Only in connection with the Certificate Management Protocol (CMP). The key identifier is used along
with the key to identify the user requesting a certificate.
Key
A shared secret granted by the certification authority to be used in the certification request. Used for
verification of the user requesting a certificate.
Click Next to proceed to encryption speed diagnostics.
Off-line Certification Request
An off-line certification request is simply a file, where the request is stored for later use. The request is of
PKCS#10 format and saved in Privacy Enhanced Mail (PEM) encoded format. You specify the location of
the file on the Certificate Request dialog box. Click the Browse button to navigate the file system. Click
Next to proceed to encryption algorithm diagnostics. To complete the enrollment, you must deliver the
request to the certification authority. You might save the request on a floppy disk and deliver the floppy to
the authority or you might prefer sending the request via e-mail or using an enrollment service in the Web.
2.2.5 Encryption Speed Diagnostics
SSH Sentinel runs diagnostics on the encryption algorithms as the last step of the installation. You can
bypass this step by clicking the Skip button on the dialog box.
The diagnostics reveals the speed of the encryption algorithms compared to each other. SSH Sentinel supports the following ciphers: AES, Twofish, Blowfish, CAST, 3DES, and DES. All except DES can be considered secure for commercial use. The DES encryption algorithm is supported as a fallback option for
interoperability reasons. AES, an encryption algorithm widely considered fast, secure and reliable, is used as
the default cipher by SSH Sentinel.
The diagnostics also reveal the relative speed of your computer running the algorithms. There is a lot of contradictory information available on encryption speeds. The diagnostics give you the chance to use your own
judgment.
The diagnostics measure the encryption speed of your computer within the memory. The data packets are not
transmitted to the network. This is a common way to measure performance among the encryption hardware
vendors. It has the advantage of giving simple figures on the speed: Due to a number of variables that affect
the final result, it would be very complicated to define a standard environment where to reliably measure the
15
overall network throughput. Moreover, the real-world network throughput simply cannot be measured during the installation, because the kernel mode IPSec engine is not available before the first reboot.
An Intel P3 personal computer with a processor speed of 800 MHz should be able to provide a maximum
IPSec throughput of over 40 Mbit/s on the preferred cipher. However, other variables, such as the operating
system, network bandwidth and CPU load, naturally limit the throughput.
Once diagnostics is complete, click Next to proceed.
2.2.6
Completing the Installation
Since the installation of the SSH Sentinel software adds kernel-mode components to the operating system
network management, you have to restart the computer before using the software.
The results of the installation are the following:
•
An initial filter rule set is created.
•
An authentication key pair and the self signed certificate is created. Also, you might have created a certification request to a certification authority.
•
The self-signed certificated is included in the default response rule.
•
The self-signed certificate is included in the trusted certification authorities.
2.3
Updating SSH Sentinel
The system automatically updates the software, if you launch the installation package when there is a previous version of the SSH Sentinel software on your computer. The contents - the policies, the rules, the
authentication keys etc. - are preserved. Only the software version in updated. SSH Accession is not
updated.
2.4
Removing SSH Sentinel
Before removing the software, do the following:
1.
Export and save all such data in the SSH Sentinel that you might need in the future. For example, you
might want to save the trusted root certificates for later use. Since removing the software will delete all
files in connection to the software, save the data in a separate folder.
2.
To be on the safe side, save all unsaved data in other applications and close all open applications.
To remove the software, use the standard Windows procedure: Open Add/Remove Programs under Settings in the Start menu. Select SSH Sentinel in the listing. Complete the removal by restarting the computer. SSH Accession is also removed.
You can reinstall the software after removing it. Import the saved data after installation.
Before updating the Windows version on your computer, from Windows NT to 2000, for example, remove
SSH Sentinel and reinstall the software after updating the operating system.
16
Chapter 3 Policy Editor
17
3.1
SSH Sentinel Software Componenets
You can think of the SSH Sentinel software to be put up of three parts: Policy Editor, Policy Manager and
the engine. The security policy protects your host against harmful attacks from the network. The trust policy
describes whom to trust. In SSH Sentinel, the security policy is broken into rules from which the action on
each outgoing or incoming data packet is derived. You use Policy Editor, the user interface, to configure the
rules that set up the security policy. Also, you manage the trust policy, the authentication keys, with it.
Figure 3.1 The software architecture in detail
The rules are stored in the rule database, a part of Policy Manager. Every time you add, remove or alter a
rule, the rule database is updated.
The actual decision on the action taken on a data packet is made by the engine. The engine monitors the data
traffic, its interceptor traps the appropriate packets and applies the security policy on them. Engine holds an
internal representation of the security policy created by Policy Manager from the rules of the active policy in
the rule database. Every time you update the rule set, Policy Manager recreates the internal representation to
the engine.
18
3.2
SSH Sentinel Agent
The SSH Sentinel icon appears on the system tray, on the right hand side of the Windows taskbar, when the
Policy Manager is running. If Policy Manager is disabled for some reason, the policy rules are not applied on
the network data traffic and the icon is dimmed. Clicking the secondary mouse button opens a floating menu
with the following items:
Figure 3.2 The SSH Sentinel system tray icon
View Statistics
Opens the SSH Sentinel statistics display. Double-clicking the tray icon has the same effect. See Section 13.4 ’Statistics’.
Run Policy Editor
Opens the Policy Editor.
Auditing
View Audit Log
Opens the audit logs to be viewed. For more on audit logs, see Section 13.1 ’Auditing’.
View IKE Log Window
Opens the IKE Log window that can be used for monitoring traffic and trouble-shooting. See Section 13.2 ’IKE Log’ for further reference.
Audit Settings
Open the Audit Settings dialog box to view and modify the settings. For details, see Section 13.1
’Auditing’.
User Key Agent
SSH Accession
Opens SSH Accession Lite which is used for managing smart cards. SSH Accession Lite is
installed simultaneously with the SSH Sentinel Software.
SSH Accession Help
Opens SSH Accession Lite online help.
Select Active Policy
Select the applied policy from the list of policies available on your host.
Select VPN
Opens VPN connections. The VPN connections that are opened automatically on start-up are shown
dimmed on top of the list. Open other connections by selecting them on the list. Remember that you can
only have one connection using the virtual adapter open at a time. See Section 7.3.5 ’Virtual IP
19
Address’ for details. For instructions on how to open VPN connections automatically on start-up, see
Section 7.2.9 ’Opening VPN Connections’.
Start Policy Manager
Enables Policy Manager: The active policy is applied.
Stop Policy Manager
Disables Policy Manager: No policy is applied.
Help
Opens SSH Sentinel online help.
Online Support
Read Me
Opens the SSH Sentinel online support.
Support Request
Fill in a support request.
About
Shows general information on the SSH Sentinel software.
Hide Tray
Hide the tray icon. You can make the icon reappear by starting the SSH Sentinel Agent (from the SSH
Sentinel folder).Even if hidden, the tray icon will reappear on the screen after restarting the computer.
To prevent it from appearing, remove SSH Sentinel Agent from the Startup folder under the Windows
Start menu. Be careful NOT to remove the item from the SSH Sentinel main folder, though! The exact
location of the Startup folder varies according to the Windows version.
3.3
Opening Policy Editor
To open Policy Editor, do one of the following:
•
Select Run Policy Editor in the SSH Sentinel main menu.
•
Open the Windows Control Panel. Double-click the SSH Sentinel icon, or select it with the secondary
mouse button and choose Open in the menu that opens.
•
Open Programs in the Windows Start menu. Select SSH Sentinel Policy Editor under SSH Sentinel.
3.4
Using Policy Editor
You can view and manage the policy rules and the authentication keys on Policy Editor. There are two pages,
Security Policy and Key Management for management of the rules and the keys, respectively.
20
Figure 3.3 The Policy Editor window
3.4.1
Security Policy
The security policies are managed on the Security Policy page of Policy Editor. A security policy consists
of
•
two separate traffic filters,
•
IPSec traffic rules and
•
default response rule handling both incoming IPSec and unprotected IP traffic.
3.4.2 Key Management
On the Key Management page you manage the authentication keys that are classified in the following categories:
•
You can share a security policy available on a trusted policy server. These certificates are common to
all policies in your system.
•
The certification authorities issue certificates to lower level authorities and to end entities (hosts). The
system can automatically trust a certificate of a remote host, if it issued by a certification authority that
you trust.
•
If certification authorities and public-key infrastructures cannot be taken advantage of, self-signed certificates of remote hosts are used in authentication.
•
The authentication keys of the local host are listed under the My Keys branch. The keys include preshared keys, self-signed certificates, and certificates issued by a certification authority.
Also, the directory services are managed on the Key Management page. The services are needed when
working with public-key infrastructures and also when locating policies from remote servers.
Chapter 4 Managing Multiple Policies
21
4.1
Multiple Policies
The SSH Sentinel software supports a multi-layer policy structure meaning that a host can possess an unlimited number of security policy layers. A single policy layer contains a complete security and trust policy.
Common to all policies are the authentication keys of the local host and the certificates of the trusted policy
servers needed in downloading centrally managed policies. Naturally, only one policy layer can be applied,
active at a time.
4.2
Managing Policies
4.2.1
Adding Policies
You can create a new policy from scratch or you can import a policy from a file. SSH Sentinel also supports
centralized policy management by allowing you to share a policy from a server.
To add a policy, go through the following steps.
1.
Select an existing policy by clicking its header with the mouse, and click the Add button.
2.
The dialog box called Add Policy opens. Specify the values:
•
Give the policy a descriptive name. The name is for your reference only.
•
In the lower part of the dialog box, specify if you are creating a new local policy from scratch,
importing it from a file, or sharing a centrally managed policy.
3.
Once ready, click OK. To cancel, click Cancel.
4.
Back on Policy Editor, click Apply or OK to put the new policy into effect. To discard the change, click
Cancel. Note: To apply the new policy, you must set it active. See Section 4.2.4 ’Activating Policies’
for details.
Creating New Local Policies
To configure a new local policy from scratch, select the option Create a local policy on the Add Policy dialog box. Once created, you can freely update the policy. To make the policy available for sharing to other
users, select the option Shared on the Sharing page.
22
Importing Policies
A policy that you import from a file becomes a normal local policy, once you have added it. You can freely
update the policy and make the policy available to others. To import a policy from a file, select the option
Import a policy from this file on the Add Policy dialog box and write the name and path of the file in the
field provided. You can also locate the file by browsing the file system. The policy must be encoded in SPSL
(Simple Policy Specification Language).
You can make the new policy available to others on the Sharing page of the Add Policy dialog box.
Fetching Centrally Managed Policies
To support centralized policy management, SSH Sentinel offers an easy way to fetch a policy from a server.
A shared, centrally managed policy is not locally updateable. To fetch a centrally managed policy, select the
option Fetch a centrally managed policy from this server on the Add Policy dialog box. Specify the
server by the IP address or the domain name in the appropriate field.
You can only share a policy certified by a policy certification authority listed on the Key Management page
of Policy Editor. You should add the certificate of the authority before fetching the policy. If you don't, the
system cannot automatically trust the certificate and it will ask you, if it should fetch the policy and accept
the authority. If your answer is positive, two things will happen:
•
The cached copy of the policy will appear in your system.
•
The certificate will appear in the list of trusted policy servers.
The policy must be encoded in SPSL (Simple Policy Specification Language) and is retrieved using the
Simple Policy Retrieval Protocol (SPRP).
The central management specifies how often the policy must be refetched for updates. A typical interval
would be something like four hours. Furthermore, the updates are automatically refetched every time the
Policy Manager is restarted. You can also fetch the updates manually by clicking the Poll button.
4.2.2
Removing Policies
To remove a policy:
1.
Select the policy on Policy Editor and
2.
click the Remove button.
3.
To make the removal permanent, click Apply.
4.2.3
Viewing and Editing Policy Properties
You can view and edit the properties of a policy layer on the Policy Properties dialog box:
1.
Select the policy you want to view and click the Properties button to open the dialog box.
2.
View and edit the values. Remember, you cannot update your copy of a centrally managed policy.
3.
To save your changes, click OK. To discard, click Cancel.
4.
Back on Policy Editor, click Apply or OK to put your changes into effect. Clicking OK also closes Policy Editor. To discard the changes, click Cancel. Note: These actions affect all modifications in the rule
23
set and the key management. Thus clicking Apply or OK enforces and clicking Cancel discards all
changes made so far.
4.2.4
Activating Policies
Only one policy can be active, applied, at a time. To set a policy active, do one of the following:
•
From Policy Editor: Select the policy you want to activate with the secondary mouse button. Select Set
Active in the menu that opens. The menu item is inactive, if the policy you are handling is the active
policy.
•
From SSH Sentinel tray icon: Open the tray icon menu with the secondary mouse button. Select Select
Active Policy with the left mouse button. Select the correct policy from the list shown.
4.3
Policy Properties
The properties of a policy can be seen on the Policy Properties dialog box with two pages, the General and
the Sharing.
Figure 4.1 The dialog box for adding a new policy
4.3.1 General Properties
Policy type
In SSH Sentinel, there are two types of policies: local and centrally managed.
A local policy is a security policy that is stored and maintained locally. You can create a local policy
from scratch or you can import a policy from a file.
24
A centrally managed policy is a security policy that is created and stored in a remote location. Once
fetched to the local host and it is seen there as a cached copy. All changes made to the policy by the centralized management are automatically downloaded to the local host where it cannot be updated. You
can fetch a policy only from a trusted policy server as explained in Section 4.4 ’Trusted Policy Servers’
Policy source
The policy server and the policy name.
Description
A short free-form description of the policy.
Created
The date and time of the creation of the policy.
Modified
The date and time of the last update on the policy.
Attributes: Active policy
Checked, if this is the applied policy. Out of the multiple policies in your system, only one can be
applied, active, at a time. The active policy is shown in bold letters on Policy Editor.
4.3.2 Sharing Properties
Not Shared/Shared
If you allow others to share your local policy, select the option Shared. If not, select Not Shared. To
fetch your policy, the remote end must support the Simple Policy Retrieval Protocol (SPRP). On the
remote host, your policy appears as a centrally managed policy: It cannot be modified on the remote
host and your changes to the policy will be reflected to it.
Description
A free-form description of the policy. Something descriptive is recommended.
Signature
Sign the policy with your self-signed certificate. The remote end that shares your policy, considers your
host a trusted policy server.
Expiry time
The figure shows how often the remote host sharing the policy should fetch your updates. This is the
maximum interval between two consecutive refreshes. The value is set to four hours by default.
4.4
Trusted Policy Servers
4.4.1 What Are Trusted Policy Servers
You cannot fetch a copy of a centrally managed policy from a remote server, unless the server is regarded a
trusted policy server. The server signs the policy with its digital signature. To fetch the policy, you must have
25
the certificate of the server, in your trust policy. The certificates of the trusted policy servers are stored in the
Trusted Policy Servers branch of the key management tree. You only trust a certificate in this branch when
fetching policies. In other words, the certificate cannot be used for authentication when establishing an
IPSec-protected connection with the server. To add the certificate to your general trust policy, you must add
the certificate to the trusted certification authorities or hosts.
4.4.2 Managing Trusted Policy Servers
The certificates of the trusted policy servers are listed under the Trusted Policy Servers branch on the Key
Management page of Policy Editor. The management of these certificates is similar to managing other certificates. See Chapter 11 ’Certificate Management’ for reference.
26
Chapter 5 Configuring Policy Rules
27
5.1
Security Policy Rules
A security policy protects the local host against harmful attacks from the network. In SSH Sentinel, the security policy is broken into rules from which the action on each incoming or outgoing data packet is derived: Is
the data packet passed through or stopped, is it encrypted, should authentication be demanded? The trust
policy, controlling the authentication keys, is linked to the security policy.
You can view and modify the security policy rules on the Security Policy page of Policy Editor. You cannot
modify a centrally managed policy that you share from a server.
A security policy consists of
•
two separate traffic filters,
•
IPSec traffic rules and
•
default response rules handling both incoming IPSec and unprotected IP traffic.
5.1.1
Traffic Filters
A traffic filter rule simply passes or stops a data packet. The data packet to be affected by a rule is characterized by the following selectors:
•
traffic protocol
•
remote host (or network) IP address and port
•
local host port
•
traffic direction: incoming, outgoing or both
The rule can
•
bypass a data packet, in which case the data packet is not encrypted and will not be affected by any
other rules in the rule set.
•
drop a data packet, in other words discard it.
•
reject a data packet, which means discarding the packet and sending a message on the denial to the initiator.
The traffic filters cannot trap data packets with IPSec encapsulation. To be able to filter IPSec transmissions
in all situations, two separate filters are available:
28
•
the pre-IPSec filter to be applied before the IPSec transformation is performed and
•
the post-IPSec filter to be applied after the IPSec transformation.
The two separate filters can undeniably cause confusion. Consequently you should configure the filter rules
with care to avoid ambiguity. Often, the filtering of the outbound traffic is performed with the pre-IPSec filter and the filtering of the inbound traffic with the post-IPSec filter. However, both filters are applied on all
traffic.
5.1.2 IPSec Rules
The IPSec rules include rules for virtual private networks, secured connections and secured networks. If an
IPSec rule for a remote host exists, your host only accepts IPSec-protected traffic from and to the remote
host. Any data packet that you send to the remote host, is transformed to include the IPSec encapsulation. If
the remote host sends you an unprotected IP packet, the IPSec negotiation is started.
5.1.3
Default Response Rule
The default response rule is applied on the incoming data packet if none of the specific rules can be evaluated. The action on IPSec and unprotected IP traffic is configured separately. The default IPSec rule contains the authentication key to be used. The default response to unprotected IP traffic either drops or allows
the traffic. Denying the traffic means discarding the data packet. Allowing the data packet means that the
data packet passes the default rule but does not avoid the rest of the handling - in other words, the packet is
next forwarded to the post-IPSec filter.
5.2
Establishing Connections
The rules that you configure with Policy Editor, are stored in the rule database. From these rules, Policy
Manager creates a code understood by the engine, which is responsible for detecting data packets and applying the security policy to them. Assume that you create a secured connection rule on the data traffic to an
arbitrary host in the Internet. As you add the rule with Policy Editor, it is stored in the rule database and Policy Manager recreates the code used by the engine to apply the security policy.
Next, assume that the interceptor in the engine traps a data packet you are transmitting to the host. Based on
the code derived from the rule set, the engine knows that the data packet should be IPSec-encapsulated but it
does not know how. For example, it does not know which encryption algorithm to use, it just knows that the
data should be encrypted. The details of the IPSec transformation are presented to the engine in a form of a
security association (SA). If the security associations do not exists, the engine signals Policy Manager to create them.
5.3
Internet Key Exchange
To create the necessary security associations, Policy Manager starts Internet Key Exchange (IKE) with the
remote host. In IKE, the communicating entities are called the initiator and the responder - the former being
the one who started the process. During the first phase of the process, IKE phase one, the Internet Key
Exchange security associations, IKE SAs for short, are created. The IPSec security associations are then
established in the next step, IKE phase two, under the protection provided by the IKE security associations.
5.4
29
Security Associations
An IPSec security association is a contract between the two communicating entities - the local and the
remote host - on how the communication should be secured. Among other things, the contract dictates the
encryption algorithm and the authentication keys used. A security association is always one way, meaning
that in a typical situation two are needed: one from the local host to the remote host and another from the
remote to the local. When negotiating the security associations, the communicating entities also settle their
lifetimes. Once the period has run out, the association is not valid any more. If there is communication going
on between the two hosts, new associations are set up.
Going back to the example, when the security associations are set up, the data packet being transmitted from
your host to the remote host, is IPSec-encapsulated according to the IPSec security association and sent to
the remote host.
5.5
Evaluating Rules
The rules are evaluated in the order they appear in the user interface:
1.
pre-IPSec filter
2.
IPSec rules
•
virtual private network rules
•
secured connection rules
•
secured network rules
3.
default response rule
4.
post-IPSec filter
5.5.1
Managing Outgoing Data Packets
Pre-IPSec Filter
The pre-IPSec filter is first applied on an outgoing data packet. The outcome can be one of the following:
•
A bypass rule matches the data packet and the data packet passes all other rules.
•
A drop or reject rule matches the data packet, in which case the data packet is discarded.
•
No rule matches the data packet and the packet is forwarded to the IPSec rules.
IPSec Rules
If an IPSec rule matches the data packet, then the connection negotiations with the other end are started,
unless the security associations exists as a result of a previous successful negotiation. If the negotiation is
successful, the security associations are established and the data packet is forwarded to the IPSec transformation. After the transformation, the data packet, now of ESP (encapsulated security payload) protocol is
forwarded to the post-IPSec filter. If the negotiation fails, the data packet is dropped.
If none of the IPSec rules matches, the data packet is forwarded untouched to the post-IPSec filter.
30
Post-IPSec Filter
The post-IPSec filter is applied on all traffic not dropped or bypassed by previous rules. Again, the outcome
can be one of the following
•
A bypass rule matches the data packet and the data packet is passed to the network.
•
•
No rule matches the data packet and the packet is forwarded to the network.
Figure 5.1 Managing outgoing data packets
Words of Caution
To minimize the risk of creating ambiguous filter rules, use the pre-IPSec filter primarily to filter the outgoing and the post-IPSec filter to filter the incoming data traffic.
Dropping traffic of all protocols drops literally all packets, including the ESP (IPSec-protected) packets. As
a rule of thumb, do not create "drop all" type of rules.
If you bypass all protocols to a host in your pre-IPSec filter, then the packet is never tested against the IPSec
rules. Consequently, even if you had a secured connection rule to a host, the traffic is not protected by IPSec.
You are not informed, if the packets are dropped due to a failed negotiation. It is therefore recommended that
you run the connection diagnostics already when you create an IPSec rule. The diagnostics tries to set up the
connection and informs you if something goes wrong.
To be able to establish IPSec connections, the IKE negotiations must not fail. Consequently, bypass the IKE
traffic (service) in the pre-IPSec filter. The rule is created automatically when the software is installed. Rules
bypassing the DHCP and SPRP packets are also created when installing the software.
5.5.2
31
Managing Incoming Data Packets
Pre-IPSec Filter
The pre-IPSec filter is first applied on an incoming data packet. The outcome can be one of the following:
•
A bypass rule matches the data packet: the data packet passes all other rules and is forwarded to the
TCP/IP stack
•
•
No rule matches the data packet and the packet is forwarded to the IPSec rules.
IPSec Rules and Default Response
The incoming data packet is next checked against the IPSec rules. Let us first consider the case, when the
incoming data packet is of ESP protocol. In that case, the IPSec connection, based either on a specific rule or
the default response rule has previously been established with the remote host. So, the corresponding security association should be available and the packet is next forwarded to the IPSec de-capsulation and to the
post-IPSec filter. If not, the IPSec negotiation is started to establish the security associations. If successful,
the packet is forwarded to the IPSec de-capsulation and to the post-IPSec filter. However, if the negotiation
fails, the data packet is discarded. If no IPSec rule matches the incoming IPSec-protected data packet, the
default response rule is evaluated. Based on the defined parameters, the system tries to negotiate an IPSec
connection. If successful, the packet is forwarded to the IPSec de-capsulation and to the post-IPSec filter. If,
however, the negotiation fails, the data packet is discarded.
If there is an IPSec rule but an unprotected IP packet from the remote host is received, the system tries to
negotiate an IPSec connection with the host. If successful, the security associations are set up, the remote
host retransmits the data packet, now IPSec-encapsulated, and the packet is then handled normally: it is forwarded to the IPSec de-capsulation and on to the post-IPSec filter.Finally, if no IPSec-rule matches the
unprotected IP packet, the transmission is replied to by the default response. The default response may
•
deny (discard) the data packet or
•
allow the data packet (forward it to the post-IPSec filter).
Figure 5.2 Managing incoming data packets
32
Post-IPSec Filter
After de-capsulation, the IPSec traffic has become plain IP packets which can be filtered by the post-IPSec
filter. Naturally, the unprotected traffic that has not been bypassed or dropped by previous rules, is filtered
also. Again, the outcome can be one of the following
•
A bypass rule matches the data packet and the data packet is passed to the TCP/IP stack.
•
•
No rule matches the data packet and the packet is forwarded to the TCP/IP stack.
Words of Caution
Since ESP packets cannot be trapped by a filter rule, the incoming IPSec traffic should be filtered with the
post-IPSec filter, which is evaluated after the IPSec transformation is performed on the data packet.
However, rules that affect all traffic protocols, affect also ESP packets. Therefore, if you drop all protocols
in the pre-IPSec filter, the incoming IPSec traffic is dropped also. If you pass all protocols in the pre-IPSec
filter, the incoming ESP packets are also passed straight to the TCP/IP stack, where they are dropped, since
the stack does not know how to process them. As a rule of thumb, do not create "pass/drop all" type of rules.
To be able to establish IPSec connections, the IKE negotiations must not fail. Consequently, bypass IKE
traffic (service) in the pre-IPSec filter. The rule is created automatically when the software is installed. Rules
bypassing the DHCP and SPRP packets are also created when installing the software.
Chapter 6 Traffic Filters
33
6.1
What Is a Traffic Filter?
The filter rules complement the protection provided by IPSec. By filtering IP packets, you can discard connections from and to potentially hostile hosts and filter out unwanted traffic. The traffic filtering rules allow
the system administrator to limit access to services.
The traffic filtering in the SSH Sentinel software is broken down to filtering taking place before and after the
IPSec transformation is performed on the data packet transmitted. As far as the incoming traffic is concerned, the pre-filter is applied before the IPSec encapsulation is removed and the post-filter after removing
it. Following the same logic, the pre-filter is applied on the outgoing traffic before the IPSec encapsulation is
inserted and the post-filter after inserting it.
This kind of a setup is required to be able to filter IPSec encrypted traffic. Since IPSec encrypted traffic is of
ESP protocol, it obviously is not affected by filter rules that handle TCP and UDP traffic. Consequently, the
generic filtering of the outbound traffic is often performed with the pre-IPSec filter and of the inbound traffic with post-IPSec filtering. However, both filters are executed on all traffic, no matter if it is IPSec
encrypted or not. Since the user interface and the management of both filters is identical, they are explained
here together. The examples and pictures are taken from the pre-IPSec filter.
Figure 6.1 The basic listing of the pre-IPSec filter rules
34
6.2
Managing Filter Rules
6.2.1
Adding Rules
To add a new filter rule, go through the following steps:
1.
Select the Pre-IPSec Filter branch in the policy tree and click the Add button.
2.
Fill in the appropriate values. See Section 6.3 ’Filter Rule Properties’ for assistance.
3.
Accept the changes by clicking OK. To not to add the rule after all, click Cancel and your changes disappear.
4.
6.2.2
Removing Rules
To remove a rule:
1.
Select the rule on Policy Editor.
2.
Click the Remove button.
3.
To make the removal permanent, click either OK or Apply. Clicking OK also closes Policy Editor. You
can restore the rule set after even several removals by clicking Cancel, provided that you have not yet
committed the changes with Apply or OK.
6.2.3
Viewing and Editing Rules
Once you have created a filter rule, you can view and modify the rule properties at any time. Remember,
however, that you cannot update a rule in a centrally managed policy. To see the basic listing of the rules,
expand the Pre-IPSec Filter branch. To get a more detailed listing, double-click Pre-IPSec Filter.
To view the details of a rule and to edit the values do the following:
1.
Open the Filter Rule Properties dialog box by selecting the rule and clicking the Properties button.
2.
View and edit the values. See Section 6.3 ’Filter Rule Properties’ for assistance.
3.
When ready, accept the changes by clicking OK. To discard your changes, click Cancel. Both buttons
return you to Policy Editor.
4.
6.2.4
35
Modifying the Evaluation Order
The filter rules are listed in the order that they are evaluated, the order being from top to bottom. The first
rule that matches the connection is applied and no more rules are evaluated. Thus, if you want to reject FTP
connections in general, but to accept them from one particular host, called host-1, you create two rules: one
to bypass FTP from host-1 and another to reject it from any host. The more specific bypass rule must be
evaluated before the general rejection rule.
To modify the evaluation order, do the following:
1.
Select the rule you want to reposition. Two arrow buttons appear now below the policy tree.
2.
Move the rule upwards or downwards with the arrow buttons. You can also use the menu commands
Move Up and Move Down.
3.
6.2.5
Enabling and Disabling Rules
You can disable a rule - and naturally later enable it again. To disable (enable):
1.
Select the rule with the secondary mouse button and select Rule Enabled in the menu that opens. A
check mark appears next to the menu item when the rule is enabled. When disabled, a little x-mark
appears on the rule icon and the check mark disappears from the menu.
2.
Remember to put your changes into effect by clicking the Apply button.
6.2.6
Auditing Rules
To audit a rule, do one of the following:
•
Select the rule with the secondary mouse button. Click Audit Rule in the menu that opens. A check
mark appears to indicate that the rule is now audited. Also, a little exclamation mark appears on the rule
icon. OR
•
Select the rule and open the Rule Properties dialog box. Click the Advanced tab to view the audit
options. Select the Audit this rule option. Click OK to return.
To stop auditing a rule, do the opposite:
•
Select the rule with the secondary mouse button and click Audit Rule again. The check mark disappears from the menu as well as the exclamation mark on the rule icon. OR
•
On the Advanced page of the Rule Properties dialog box, clear the check box Audit this rule.
Remember to put your changes into effect by clicking the Apply button. To learn the details of auditing, see
Section 13.1 ’Auditing’.
36
6.3
Filter Rule Properties
The rule properties are shown on the Filter Rule Properties dialog box with two pages, General and
Advanced.
Filter type
Filter action
The action taken on the data packet is bypass, drop, or reject. When bypassed, the data packet is forwarded to the TCP/IP stack (incoming packet) or to the network (outgoing packet) as it is. Dropping
traffic means that the data packet is discarded. Rejecting the traffic also discards the data packet, but the
sender is informed that the transmission was rejected.
Direction
A rule can only affect the inbound traffic, that is, the data packet coming from a remote origin into the
local host or the outbound traffic, data packets from the local host to a remote target. The rule can also
affect both directions: inbound and outbound.
Protocol
The upper level (transport layer) protocol. The available options are listed in the drop down list: UDP,
TCP, ICMP, TCP and UDP, and any. Selecting any means that the rule matches traffic of all protocols,
including ESP (IPSec traffic).
Local host
Port / service
The local host port used or the service name. Since each service (application) has a distinct port associated with it, you can reject one service while allowing others by specifying the port. You can type in the
port number (e.g. 10), port number range (e.g. 10-20) or select the service and the port from the dropdown list.
Remote host / network
Host / network
Select the remote network (host) from the list of available network definitions or click the ... button to
define a new network. See Section 6.3.3 ’Network Editor’ for details.
Port / service
The remote host port used or the service name. Since each service (application) has a distinct port associated with it, you can reject one service while allowing others by specifying the port. You can type in
the port number (e.g. 10), port number range (e.g. 10-20) or select the service and the port from the
drop-down list.
Description
Free-form text that appears on the bottom of Policy Editor when the rule is selected. You can edit the
text by clicking the Change button and typing a new description in the text field that appears.
37
Figure 6.2 The filter rule properties
6.3.2
Advanced Properties
Audit Options
The audit options are shown on the Advanced page of the Filter Rule Properties dialog box.
Audit this rule
To audit the rule, select this check box. For more information on auditing, see Section 13.1 ’Auditing’.
6.3.3
Network Editor
To define and name networks for your internal application, use the Network Editor dialog box:
1.
Open the editor by clicking the ... button right from the Host / network field on the General page of the
Filter Rule Properties dialog box.
2.
The defined networks are listed in the Defined networks box. Click the New button to define a new
network. The text fields below the button become active.
3.
Fill in the values:
4.
•
Network name is for your own reference only. Something descriptive is recommended.
•
The IP address of the network.
•
The subnet mask of the network.
Click OK to add the new network. To discard your changes, click Cancel. Both return you to the Filter
Rule Properties dialog box.
You can use the defined networks in any rule that you configure. To remove a network, click Remove.
38
Figure 6.3 The network editor
Chapter 7 IPSec-Protected Connections
39
7.1
What Are IPSec-Protected Connections?
7.1.1
Virtual Private Network (VPN) Connections
A virtual private network is a setup where a private network is made accessible to authorized users connecting to it from a remote location. The private network is protected by a security gateway. All traffic in to and
out of the network traverses the gateway. Between the security gateway and the user host, the connection is
established over a public network. The virtual private network connections are typically used for accessing a
corporate network from a home office or some other remote location and connecting geographically dispersed offices. enabling remote access to a network and for remote working.
Between the host and the security gateway, an IPSec-protected tunnel is created. The data transmitted is
encrypted and the communicating parties are authenticated. The security associations are bound to the security gateway.
Figure 7.1 A typical virtual private network layout.
7.1.2
Secured Connections
If you establish a secured connection with a remote host, the data transmitted is encrypted. Also, both ends
are authenticated.
40
Secured connections are simple peer-to-peer IPSec-protected connections. Important IP connections like
remote administration of computers, file transfer or download, sending and receiving email, Web browsing
and IP telephony are commonly protected by IPSec.
Figure 7.2 The peer-to-peer connection layout.
7.1.3
Secured Networks
A secured network can be seen as an expansion of the concept of secured connection. A single policy rule
affects the data traffic within an entire network segment. All traffic is encrypted and the hosts authenticated.
A secured network provides protection against active malicious attacks, unauthenticated network access,
network sniffing and data tampering. Even wireless local area networks (WLAN), which are extremely vulnerable due to their open nature can be effectively protected.
It is recommended that when secured network rules are applied, a WINS server is used to avoid extra broadcast traffic. The Microsoft NetBIOS protocol, which is commonly encapsulated in TCP and UDP headers
(and therefore subject to IPSec rules), is a rather noisy protocol and may generate IPSec/IKE negotiation
"storms" between the hosts.
Figure 7.3 The secured network layout.
41
Even if a secured network rule covers a network segment, the connection is made and the security association pair is bound to one host. Consequently, several connections and pairs of security associations based on
one secured network rule can exist simultaneously.
7.2
Managing Connection Rules
7.2.1
Adding VPN Connection Rules
To insert a new virtual private network connection rule, go through the following steps:
1.
Select VPN Connections in the policy tree and click the Add button. OR Select VPN Connections
with the secondary mouse button and click Add New Rule in the menu that opens.
2.
The dialog box Add VPN Connection opens. Fill in the values:
•
The domain name or IP address of the remote security gateway. You can switch from host name to
IP address and back with the button on the right.
•
Select the remote network from the list of defined networks. If the network is not yet defined, click
the ... button to name it. See Section 7.3.7 ’Network Editor’ for details.
3.
Select the Use legacy proposal option to use the short form of the proposal. Click the Properties button
to specify the rule properties in more detail. If you want to test the connection, click Diagnostics. It is
recommended to always run the diagnostics on the connection at this stage. Click OK to proceed.
4.
Figure 7.4 Adding a rule on a virtual private network connection
7.2.2
Adding Secured Connection Rules
To insert a new secured connection rule, go through the following steps:
1.
Select Secured Connections in the policy tree and click the Add button. OR Select Secured Connections with the secondary mouse button and click Add New Rule in the menu that opens.
2.
The dialog box Add Secured Connection opens. Fill in the values:
•
The domain name or the IP address of the remote host.
•
The authentication key of authenticate your host.
42
3.
To specify the rule properties in detail, click the Properties button. Test the connection by clicking the
Diagnostics button. Running the diagnostics on the connection at this stage is recommended. Click OK
to proceed.
4.
Figure 7.5 Adding a new peer-to-peer secured connection
7.2.3
Adding Secured Network Rules
To insert a new secured network rule, go through the following steps:
1.
Select Secured Networks in the policy tree and click the Add button. OR Select Secured Networks
with the secondary mouse button and click Add New Rule in the menu that opens.
2.
The dialog box Add Secured Network opens. Fill in the values:
3.
•
Select the network from the list of defined network. To define a new network, click the ... button.
•
The authentication key to authenticate your host.
Click Properties to specify the rule properties in more detail. Click OK to proceed.
Figure 7.6 Adding a secured network rule
4.
7.2.4
Removing Rules
To remove a rule:
1.
2.
3.
43
can restore the rule set after even several removals by clicking Cancel, provided that you have not yet
committed the changes with Apply or OK.
7.2.5
Viewing and Editing Rules
Once you have created a rule on a connection, you can view and modify the rule properties at any time.
Remember, however, that you cannot update rules in a centrally managed policy. To see the basic listing of
the rules, expand the appropriate branch (VPN Connections, Secured Connections, or Secured Networks). To get a more detailed listing, double-click the branch. To view the details of a rule and to edit the
values do the following:
Figure 7.7 The basic listing of the secured connection rules
1.
Open the Rule Properties dialog box by selecting the rule and clicking the Properties button.
2.
View and edit the values. See Section 7.3 ’Rule Properties’ for assistance. You can shift between the
two pages with the General and Advanced tabs.
3.
When ready, accept the changes by clicking OK. To discard your changes, click Cancel. Both buttons
return you to Policy Editor.
4.
Since updating a rule should be reflected in the corresponding security association, updating a rule - clicking
Apply or OK - destroys the corresponding security associations.
44
7.2.6
Testing Connections
To test a virtual private network or a secured connection, run the diagnostics:
1.
2.
Click the Diagnostics button.
3.
When complete, the results of the diagnostics are displayed. If the diagnostics is successful, the established connection parameters are shown. If the diagnostics fails you are informed on the cause.
It is recommended that you run the connection diagnostics already when you create a rule. If the packets are
dropped due to a failed negotiation when actually establishing the connection, you are not informed about it.
The diagnostics runs a normal connection negotiation. However, the security associations that a created as a
result of the negotiation, are destroyed immediately. Also, if the security associations exist when the diagnostics is run, they are destroyed.
7.2.7
Enabling and Disabling Rules
You can disable a rule - and naturally later enable it again. To disable (enable):
1.
Select the rule with the secondary mouse button and select Rule Enabled in the menu that opens. A
check mark appears next to the menu item when the rule is enabled. When disabled, a little x-mark
appears on the rule icon and the check mark disappears from the menu.
2.
7.2.8
Auditing Rules
•
icon. OR
•
•
•
Remember to put your changes into effect by clicking the Apply button. To learn the details of auditing, see
Section 13.1 ’Auditing’.
7.2.9
45
Opening VPN Connections
You can open VPN connections from SSH Sentinel main menu:
1.
Open the SSH Sentinel main menu by clicking the application icon on the Windows task bar with the
secondary mouse button.
2.
Select Open VPN and further the VPN connection you want to open. The connection is now opened. If
the connection cannot be opened, an error message is displayed.
You can set a VPN connection to be automatically opened when the Policy Manager is started by selecting
the option Open on start-up on the Advanced page of the Rule Properties dialog box.
Remember, that only one VPN connection using the virtual adapter can be open simultaneously. If you try to
open several, the software can function unexpectedly.
7.3
Rule Properties
The rule properties can be seen on the Rule Properties dialog box with two pages, General and Advanced.
Security gateway
VPN connections only. The domain name or the IP address of the security gateway. You can shift
between domain name and IP address with the button to the right of the text box.
Remote network
VPN connections only. The name of the remote network. You can name and define the network with the
editor that opens by clicking the ... button. See Section 7.3.7 ’Network Editor’ for reference.
Remote host
Secured connections only. The domain name or the IP address of the remote host. You can shift between
domain name and IP address with the button to the right of the text box.
Network
Secured networks only. The name of the remote network. You can name and define the network with the
editor that opens by clicking the ... button. See Section 7.3.7 ’Network Editor’ for reference.
Authentication key
Select the authentication key used to authenticate your host from the list of available keys. The available
keys include both the certificates and the pre-shared keys. See Chapter 10 ’Managing My Keys’ for
details on authentication key management.
Proposal template
Normally, use the normal proposal. The normal proposal includes all the values of each parameter supported by SSH Sentinel. Since some IPSec software products cannot handle such long proposals, SSH
Sentinel supports a short form of the proposal. The legacy proposal, contains only a few alternative values of each parameter. Click the Settings buttons to view the proposal parameters. See Section 7.3.3
’Proposal Parameters’ for details.
46
Acquire virtual IP address
VPN connections only. Select to receive a virtual IP address belonging to the private network you are
connecting to for seamless integration with it. Click the Settings button to specify the settings. See Section 7.3.5 ’Virtual IP Address’ for details.
Extended authentication required
VPN connections only. Select if the security gateway expects you to log in. Click the Settings button to
specify the login information. See Section 7.3.6 ’Extended Authentication’ for details.
Description
Free-form text that appears on the bottom of the Policy Editor window when you have the rule selected.
You can edit the text by clicking the Change button and typing the new description in the text field that
appears.
Figure 7.8 The general properties of a virtual private network (VPN) connection
7.3.2
Advanced Properties
Security Association Lifetimes
Click the Settings button to control the lifetimes of the IKE and IPSec security associations. See Section
7.3.4 ’Security Association Lifetimes’ for reference.
Audit this rule
To audit the rule, select the check box. For more information on auditing, see Section 13.1 ’Auditing’.
Apply IP compression
When selected, each data packet transmitted is compressed. Consequently, transmitting it is faster. The
compression is performed only if the other end also supports it. SSH Sentinel supports IP deflate compression.
47
Discover path maximum transfer unit (PMTU)
To avoid data fragmentation, the maximum size of the transfer unit is discovered. In other words, the
system finds out how big a data packet it can transmit along the connection. Then it makes sure to send
maximum-size data packets. Consequently, the data is distributed to a minimal number of packets and
transmission is faster and less prone to errors.
Enable Network Address Transformation Traversal (NAT-T)
Network Address Translation is a method by which IP addresses are mapped from one network realm to
another. A situation like this occurs, when a private network with private addresses, is connected to the
Internet. Traditional virtual private network solutions cannot work, however, with network address
translation due to security problems. NAT Traversal is a solution to this. It is performed only if the other
end also supports it.
Open on start-up
VPN connections only. If selected, this virtual private network connection is opened automatically when
Policy Manager is started. Remember that you only can have one virtual network connection using the
virtual adapter open at a time. You can open and close VPN connections from the tray menu.
Figure 7.9 The advanced properties of a virtual private network (VPN) connection
7.3.3 Proposal Parameters
To control the IKE and IPSec proposal parameters:
1.
Open the Proposal Parameters dialog box by clicking Settings button under the title IKE / IPSec proposal on the General page of the Rule Properties dialog box.
2.
Set the values. The number of alternatives of each parameter depends on your choice on the proposal
template. The normal template contains all the values whereas legacy only a limited selection. You
choose the template on the General page of the Rule Properties dialog box.
48
3.
Select the option Attach only the selected values to the proposal if you want to limit the size of the
proposal to only the values selected and visible on the dialog box. Otherwise, all the values are included
in the proposal and your selections are treated as preferred, first choice values.
4.
Click OK to accept your changes and to return. Clicking Cancel discards the changes.
IKE Proposal
The parameters of an IKE proposal:
Proposal parameter
Encryption Algorithm
Integrity
IKE Mode
IKE Group
Normal proposal
AES, Twofish, Blowfish,
CAST, 3DES, DES
MD5, SHA-1
Main, aggressive
MODP 768, 1024, 1536
i.e. groups 1, 2, 5 respectively
Legacy proposal
3DES, DES
MD5, SHA-1
Main, aggressive
MODP 768, 1024, 1536
Encryption algorithm
The algorithm applied to encrypt the message. The algorithms differ in strength, AES being widely considered the strongest and DES the weakest.
Integrity function
To ensure integrity, hash functions are used to calculate a check sum that reveals if the data packet is
altered while being transmitted.
IKE mode
There are two Internet Key Exchange (IKE) modes: main and aggressive. The latter is faster, whereas
the former is more flexible and thus more likely to succeed.
IKE group
When negotiating a connection, the communicating parties also settle the actual keys used to encrypt
the data. The keys are based on the private keys of each party and some random data. The random data
generation is based on pool bits. The IKE group basically tells the number of pool bits. The more pool
bits, the larger numbers in question. The larger the number, the harder to break. Consequently, more
pool bits means more secure.
IPSec Proposal
The parameters of an IPSec proposal :
Proposal parameter
Encryption Algorithm
Integrity
IPSec Mode
PFS Group
Normal proposal
AES, Twofish, Blowfish,
CAST, 3DES, DES
HMAC-MD5, HMAC-SHA-1
Tunnel
MODP 768, 1024, 1536
Legacy proposal
3DES, DES
HMAC-MD5, HMAC-SHA-1
Tunnel
MODP 768, 1024, 1536
Encryption algorithm
The algorithm applied to encrypt the message. The algorithms differ in strength, AES being widely considered the strongest and DES the weakest.
49
Integrity
To ensure integrity, hash functions are used to calculate a check sum that reveals if the data packet is
altered while being transmitted.
IPSec mode
The alternatives are transport and tunnel. Only tunnel is possible in a virtual private network connection.
PFS group
The perfect forward secrecy (PFS) group tells the number of pool bits in Diffie-Hellman key exchange.
More pool bits means slower but more secure operation.
What Is a Proposal?
To agree on the connection parameters Internet Key Exchange (IKE) is performed. As the result of the negotiations, the IKE and IPSec security associations (SAs) are established. As the name implies, proposal is the
starting point for the negotiation. For each parameter, the proposal contains all the values that t he local host
supports. For example, SSH Sentinel supports several encryption algorithm. It includes all algorithms in the
proposal and offers them one after another until the remote host picks one.
7.3.4
Security Association Lifetimes
To control the lifetimes of the established IKE and IPSec security associations:
1.
Open the Security Associations dialog box by clicking Settings button under the title Security Association Lifetimes on the Advanced page of the Rule Properties dialog box.
2.
Use the sliders to set the values or type the figure in the appropriate field . There are distinct but similar
controls for IKE and IPSec security associations. You can control the lifetime by elapsed time (minutes)
or transferred data (megabytes). Whenever either limit is reached, the existing security association is
destroyed and a new, eventually, established. To revert to the default values, click the Defaults button.
The settings only affect this connection rule and the associated security associations.
3.
Click OK to accept your changes and to return. Cancel discards the changes.
Figure 7.10 The security association lifetimes
50
What Are the Security Associations?
The security associations (SAs) are established as the result of the Internet Key Exchange. During the first
phase of the process, IKE phase one, the Internet Key Exchange security associations, IKE SAs for short, are
created. The IPSec security associations are then established in the next step, IKE phase two, under the protection provided by the IKE security associations. An IPSec security association is a contract between the
two communicating entities - the local and the remote host - on how the communication should be secured.
Among other things, the contract dictates the encryption algorithm and the authentication keys used.
A security association is always one way, meaning that in a typical situation two are needed: one from the
local host to the remote host and another from the remote to the local. When negotiating the security association, the communicating entities also settle the lifetime of the association. Once the period has run out, the
association is not valid any more. If there is communication going on between the two hosts, new associations are set up.
7.3.5
Virtual IP Address
Applicable to the virtual private network connection rules only. To acquire a virtual IP address from the private network:
1.
Select the option Acquire Virtual IP Address on the General page of the Rule Properties dialog box.
2.
Click the Settings button to open the Virtual IP Address dialog box in order to specify the settings.
3.
Select the protocol supported by the security gateway to dynamically assign the IP address. The choices
are: Dynamic Host Configuration Protocol (DHCP), Layer 2 Tunnelling Protocol (L2TP) and IKE
Config Mode. Specify the address manually, if the gateway does not support any of the protocols.
4.
Specify the IP addresses of the Domain Name System (DNS) and Windows Name System (WINS)
servers if the information is not delivered by the security gateway. If you selected L2TP as the protocol,
you must specify these values manually, even if the server passes them to you.
5.
Click OK to return.
Figure 7.11 Selecting the protocol for assigning the virtual IP address
51
What Is a Virtual IP Address?
To create an illusion of seamless integration with the remote private network, you can introduce an extra IP
address belonging to the address space of the private network, when accessing the network. In order to
achieve this higher level of integration, SSH Sentinel creates an additional network interface that appears to
be connected directly to the remote network. The adapter is physically unconnected, but serves its purpose
by making the local computer think that it has a network interface attached to the remote network. We call
this type of a network adapter a virtual adapter. You can view the settings of the adapter by double-clicking
Network in Control Panel but you should never alter the settings.
SSH Sentinel supports all the three existing protocols to carry out the task of dynamically assigning the virtual IP address to the host: Dynamic Host Configuration Protocol (DHCP), Layer 2 Tunnel Protocol (L2TP)
and IKE Config Mode. In addition, as a fallback option, the software allows specifying the virtual IP address
manually.
In the current version of the software, the number of virtual adapters is limited to one. In practice, this limits
the number of concurrently open virtual private network connections using virtual adapters to one, which,
however, should be enough for a typical user.
Dynamic Host Configuration Protocol (DHCP)
DHCP is the technologically most advanced protocol for assigning virtual IP address dynamically. The
protocol is relatively new and not yet supported by many vendors. However, since it is simple and reliable, it is likely to become popular.
The VPN client (the local host) sends a DHCP request to the security gateway over the IPSec tunnel.
The gateway then relays the request to the DHCP server which assigns an IP address and the WINS and
DNS information to the client. When communicating with the private network, the VPN client uses
native IPSec tunnel mode.
Layer 2 Tunnelling Protocol (L2TP)
The L2TP protocol, commonly used when communicating with Microsoft products, has a built-in
method called PPP to allow the gateway to assign an IP address to the client. The protocol can be
secured with IPSec encapsulation. It originates from the LAC/LNS dial-up tunneling architecture, used
in the past by several internet service providers (ISP). Microsoft prefers this approach in Windows 2000
and XP platform server architecture, where it can be seen as a transition step from PPTP towards IPSecprotected virtual private network.
Even though L2TP implements topology characteristic to dial-up networking, it does not limit the use to
dial-up connections. In fact, all of the virtual IP protocols supported by SSH Sentinel can be used in
association with any type of a network connection.
IKE Config Mode
The IKE Config Mode is commonly used to acquire the virtual IP address when communicating with
devices from various vendors including Cisco and Nortel. The protocol, also known as IKE phase 1.5, is
designed to establish various connection parameters and can also be used for assigning the virtual IP
address to the VPN client. When communicating with the private network, the VPN client uses native
IPSec tunnel mode.
The deployment of the protocol has been slowed down because of interoperability problems due to the
fact that vendors have implemented different versions of the expired standard draft. SSH Sentinel supports the latest version and uses the Cisco devices as the reference implementation in testing.
52
Manual Specification
Specify the virtual IP address by hand, if the security gateway does not support any of the protocols
mentioned above. Specifying the address manually does demand some functionalities from the gateway.
These are related to adding some static route entries and doing proxy ARP.
7.3.6
Extended Authentication
Applicable to the virtual private network connection rules only. To specify the login information for
extended authentication:
1.
Select the option Apply extended authentication on the General page of the Rule Properties dialog
box.
2.
Click the Settings button to open the Extended Authentication dialog box where you specify the login
information.
3.
If you want
•
to be prompted for the login, select the option Prompt to login
•
the login information to be submitted automatically by the system, select option Submit login
information automatically. Type the login name and the password in the fields provided.
4.
If the VPN gateway supports the newest draft version of extended authentication, select the check box Use authentication method types. The client and the gateway negotiate if extended authentication is
applied, and if it is, how is it performed.
5.
Click OK to return.
What Is Extended Authentication?
Some security gateways expect you to log in order to access the resources. With SSH Sentinel, you can submit the login information automatically or you can be prompted for login.
7.3.7
Network Editor
Applicable to the virtual private network connection rules and the secured network rules only. To define and
name networks for your internal application, use the Network Editor dialog box:
1.
Open the editor by clicking the ... button right from the Network field on the General page of the Rule
Properties dialog box.
2.
The defined networks are listed in the Defined networks box. Click the New button to define a new
network. The text fields below the button become active.
3.
Fill in the values:
4.
•
Network name is for your own reference only. Something descriptive is recommended.
•
The IP address of the network.
•
The subnet mask of the network.
Click OK to add the new network. To discard your changes, click Cancel. Both take you back to the
Rule Properties dialog box.
You can use the defined networks in any rule that you configure. To remove a network, click Remove.
Chapter 8 Default Response Rule
53
8.1
What Is the Default Response ?
The default response rule is applied on the incoming data packet if none of the specific rules can be evaluated. The response to IPSec and unprotected IP traffic is configured separately.
8.2
Managing Default Response Rule
8.2.1
Viewing and Editing Default Response Rule
To view and modify the default rule, do the following:
1.
Expand the Default Response branch in the policy tree, select any of the properties under it and click
the Properties button.
2.
The Default Response Rule dialog box with two pages, the IPSec Response and the IP Traffic Handler opens. View and edit the values.
3.
Once ready, click the OK button to accept the changes. Cancel discards the changes. Both buttons close
the dialog box and return you to Policy Editor.
4.
8.2.2
Auditing Default Response Rule
To audit the default response rule:
1.
Open the Default Response Rule dialog box and click the IPSec Response tab to open the correct
page.
2.
Select the option Audit this rule in the lower part of the dialog box. The default response to both IPSec
and unprotected IP traffic will be audited once you put the changes into effect on Policy Editor.
3.
The audit log is likely to contain an excessive number of events if your response to general broadcast
messages from various servers in the network are also included. Therefore, auditing does not include the
54
broadcast messages by default. However, if you wish to audit also default response to broadcast traffic,
select the option Audit Broadcast Traffic.
4.
Once ready, click the OK button to accept the changes. Cancel discards the changes. Both buttons close
the dialog box and return you to Policy Editor.
5.
8.3
IPSec Response
Trust policy
Selecting the option Trust all certificates means that all certificates received from any remote host are
trusted by your host without further verification. If you do not select this option and your host receives a
certificate that cannot be trusted, the traffic is dropped. In the latter case, a certificate can be trusted if it
is included in the trusted host certificates in key management, or if it is issued by a certification authority that you trust.
Trusting the certificate applies only to the connection at hand. In other words, the certificate is not
included in you general trust policy in the key management. Moreover, this setting only affects the
default IPSec traffic handling. The general trust policy is resolved from the settings on the Key Management page.
Local host authentication
The default response identity describes how your host will authenticate itself. There are two authentication methods available, a certificate and a pre-shared key. You can specify both or just one of them.
When negotiating the connection, the remote host, acting as the initiator, specifies which authentication
key your host should submit.
The certificate is initially set as part of the installation process. If you only created the self-signed certificate during the installation, it is shown here. However, if you successfully enrolled for a certificate
from a certification authority and simultaneously received the certificate, then that certificate is shown
here.
You can change both settings by selecting a certificate/pre-shared key from the respective list. Note, that
you can set either to not in use, meaning that the authentication key is not available.
8.3.1
Audit Options
Audit this rule
To audit the default response rule, select this option.
Audit broadcast traffic
To include your response to general broadcast messages from various servers in the network in the audit
log, select this option. Selecting the option is likely to result in an excessive number of events in the log.
55
Figure 8.1 The default response to incoming IPSec-protected traffic
8.4
IP Traffic Handler
You can choose between two options:
Allow unprotected IP traffic
You can choose to allow all such unprotected IP traffic to which none of the specific rules matches. In
other words, you allow all unprotected traffic not specifically discarded by a filter rule. Remember that
even if allowed by the default rule, the data packets are next forwarded to the post-IPSec filter, where
some of the packets might be discarded.
Deny unprotected IP traffic
Alternatively, you can choose to deny the unprotected traffic by default. In other words, you discard all
traffic not specifically bypassed by a rule in the pre-IPSec filter.
56
Chapter 9 Authentication Key Management
57
9.1
What Is Authentication?
Besides integrity and confidentiality, authentication is a vital part of secured communications. Authentication is a part of Internet Key Exchange (IKE).
9.1.1
Authentication Keys
An authentication key binds together an identity and a proof on it. In a network, the identity is customarily a
(static) IP address or domain name. Consequently, it is the computer, the host, that is authenticated, not the
person using it. In SSH Sentinel, there are two types of authentication keys available: pre-shared keys and
certificates.
Pre-Shared Keys
The pre-shared keys are secrets that are shared by the communicating parties prior to the communication
taking place. To communicate, both parties prove that they know the secret. The security of a shared secret
depends on how "good" the password is. Passwords that are common words are extremely vulnerable to dictionary attacks, for example. Consequently, using a pre-shared secret as an authentication method should be
replaced by certificates whenever possible. If pre-shared keys are used, the secrets should be chosen carefully. Follow the guidelines set up by your network administrator.
Certificates and Key Pairs
A certificate is a more elaborate authentication method, which is based on the use of an authentication key
pair. The key pair contains a public and a private key that can be used for encryption. As the names imply,
the public key is public to the network whereas the private is known exclusively by the entity holding the
certificate. The keys are mathematically dependent but the private key cannot be derived from the public.
Furthermore, they are uniquely related: what is encrypted with one can only be decrypted with the other. A
certificate contains an identity - the host IP address, for example - and the public key of the key pair for
proof. What is missing, however, is the binding between the identity and the proof: how do we really know
that hosts really are who they claim to be?
58
9.1.2
Certification Authorities
The binding between the public key and the identity is enforced by a certification authority (CA). An authority guarantees that a binding is valid and a certificate can be used for authentication.
An entity, a host, can enroll for certification by submitting its identity (its static IP address, for example) and
the public key. The certification authority the issues the certificate, if appropriate. To enforce the certificate,
the authority signs the certificate with its digital signature.
Public-Key Infrastructure
A public-key infrastructure is an elaboration of the concept of certification authority and certification enrollment. In such an environment, there are certification authorities that issue certificates and end entities (hosts)
that enroll for certificates. Furthermore, there can be several levels of certification authorities. An end entity
might receive a certificate from a low-level authority, who, in turn, has received its certificate from an upperlevel authority. In a public-key infrastructure, the reasoning follows a logical pattern: If you trust an authority, you trust all certificates issued by it. Consequently, you trust a certificate only if you can trust the authority that has issued it. The chain of certificates can be very long: the certificate of the authority can in turn be
issued by another upper-level authority etc. If necessary, the chain must be followed all the way to the root
certification authority to resolve the trust.
Certification Revocation Lists
The certification authorities publish certification revocation lists (CRL) to point out those certificates that for
some reason have lost their credibility. Before trusting a certificate the CRLs should be checked. If there are
several authorities along the certificate chain, the revocation lists published by each of them must be
checked.
Directory Services
To be able to locate the revocation list that a certification authority has placed on a remote server, you need
to define a directory service. The directory services are also taken advantage of, when locating centrally
managed policies on remote servers and the certificates associated with such policies.
9.1.3
Self-Signed Certificates
While the public-key infrastructure technology is maturing, you are still likely to encounter situations where
no infrastructure can be taken advantage of. SSH Sentinel supports the use of self-signed certificates to be
able to do certificate-based authentication even if no public-key infrastructure is available. A certificate
issued by a certification authority is protected by the digital signature of the authority. In a self-signed certificate, instead of the signature of an authority, the digital signature of the host itself appears. Consequently,
you should accept the self-signed certificates of remote host only after careful consideration - after all, you
only have the remote partner's word on it that the remote partner is who he claims to be. However, if you
know who you are communicating with, and you verify the certificate fingerprints over the phone, for example, it is reasonable to assume that the communications is secure.
When being installed, SSH Sentinel always creates a self-signed certificate to your host. It is included in
your My Keys listing and also in the listing of the trusted certification authorities. This self-signed certificate created as part of the installation is considered your local identity which should always be present. If
you try to remove it, the system forces you to create a new self-signed certificate for replacement. If you
accept a remote host self-signed certificate, it is included in the trusted remote hosts branch and your own
59
self-signed certificate is used to digitally sign the certificate. Since you consider your own self-signed certificate a certification authority, the chain of certificates is complete.
9.1.4
Exchanging Authentication Keys
The authentication keys are exchanged when establishing the IKE (Internet Key Exchange) security associations, in phase-1 of the negotiation. If both hosts accept the authentication of the other end, the negotiation
succeeds - unless something else goes wrong. If they do not, the negotiation fails. To accept the remote end
certificate, the local host must be able to trust the certificate: The root certification authority certificate must
be available or, in case of self-signed certificates, the remote host certificate must be available in the system.
Since the negotiation might fail just because a certificate is missing, it is always advisory to run the diagnostics on a IPSec rule when it is created. The diagnostics prompt you about the missing certificate whereas if
the negotiation fails, the data packets are simply dropped.
9.2
Key Management
The authentication keys are displayed on the Key Management page of Policy Editor. There are various
categories with the following explanations:
Figure 9.1 The Key Management page of the Policy Editor
Trusted policy servers
You can share a policy from a server listed here. The management of these certificates follows the logic
of public-key infrastructures. The trusted policy servers are explained in Section 4.4 ’Trusted Policy
Servers’. They are common to all policies.
Trusted certification authorities
These are the certificates of the certification authorities that you trust. They are separate for each policy.
60
Trusted remote host
These are the self-signed certificates of hosts in the network that you for some reason have decided to
trust. It cannot be overemphasized that the self-signed certificates should be treated with careful consideration and you should only trust one if you have strong arguments for it. These certificates are defined
separately for each policy.
Directory services
The directory services are needed when locating certification revocation lists, for example. The directory services are defined separately for each policy.
My keys
These are the authentication keys of the local host. The keys include both the pre-shared keys and the
certificates. Further, both self-signed certificates and the certificates issued by a certification authority
are listed here. Your own authentication keys are common to all policies.
Chapter 10 Managing My Keys
61
10.1 What Are My Keys?
The keys used for the authentication of your own host are listed under the My Keys branch on the Key Management page of Policy Editor. In SSH Sentinel, there are two types of authentication keys:
•
certificates
•
pre-shared keys
A certificate is always associated with an authentication key pair. The certificates can further be classified in
two categories:
•
certificates issued by a certification authority
•
self-signed certificates
The certificates found on a smart card are listed under the Accession Keys branch. Refer to the SSH Accession Lite documentation for instructions on how to manage the authentication keys found on a smart cards.
10.2 Managing My Certificates
The common management of certificates as explained in Chapter 11 ’Certificate Management’, applies to
managing the certificates of the local host, too. The few extra operations that you can perform on your own
certificates are explained in the following.
10.2.1 Accession Keys
The certificates found on a smart card are listed under the Accession Keys branch. Smart cards are managed
with SSH Accession Lite. Once you insert the smart card in the reader, they are shown in SSH Sentinel.
However, you must import the certificate of the certification authority that has issued your certificate. For
details on how to accomplish this, see Section 11.2.1 ’Importing Certificates’. The management of the smart
cards and the authentication keys is done with SSH Accession Lite. Refer to its documentation for further
information.
62
10.2.2 Creating Certificates
A wizard guides you through the process of creating a new certificate:
1.
2.
Launch the wizard. If you want to create
•
a new certificate based on an existing key pair, select the key pair and click the Add button.
•
a new key pair and a certificate based on it, select the My Keys branch and click the Add button.
Select the authentication key type on the New Authentication Key dialog box that opens. You can
either
•
create a new key pair and certificate by selecting the option Create a new authentication key pair
and certificate,
•
include the selected key pair in the certification request and enroll for a new certificate by selecting
the option Enroll for a new certificate, or
•
create a new pre-shared key by selecting the option Create a new pre-shared key. Refer to Section
10.3.1 ’Creating Pre-Shared Keys’ for further information.
Click Next to proceed.
3.
Skip this step, if you are not creating the authentication key pair.In this step, the authentication key pair
is created. First, a random seed for the key generation is collected. The seed is given by you moving the
mouse or typing in text. User random input is taken advantage of to ensure that the keys generated are
unique. The chance that two inputs are alike and the keys generated similar, is infinitesimal. Having
collected enough data for the seed, the software calculates the actual key pair. This may take some
twenty seconds to complete. After the generation is complete, click Next to proceed.
4.
On the Certificate Information dialog box, specify the information concerning the identity of the certificate. Fill in the fields with appropriate values:
Primary identifier
The primary piece of information that identifies your host. You can choose between the IP address, the
domain name and the e-mail address. It is recommended that you choose either of the first two. Only
static domain names and IP addresses should be used. If your host lacks both a static IP address and a
static domain name, select an e-mail address instead. However, since IPSec rules are normally bound to
a domain names or an IP addresses, this might cause interoperability problems with other software
products.
The field below changes its name according to your choice on primary identifier. Type in it the actual
identifier: the IP address of your host, the domain name of your host or the e-mail address.
Advanced
By clicking the Advanced button, the Advanced Information dialog box opens. You can specify the
organizational unit, the organization and the country.
ClickNext to proceed.
5.
Next, specify how to enroll for certification, on the Certificate Enrollment dialog box. You can either
•
Create a self-signed certificate,
•
Create a certification request and enroll for certification immediately online, or
•
Create a certification request and save it in a file for later enrollment.
Click Next to proceed.
6.
63
The next step depends on your choice in the previous step:
•
Self-signed certificate: SSH Sentinel creates the self-signed certificate.
•
Online enrollment: The Certification Authority dialog box appears. Fill in the appropriate values:
Enrollment Protocol
Two online enrollment protocols are supported: Simple Certificate Enrollment Protocol (SCEP)
and Certificate Management Protocol (CMP).
CA Server Address
The address (URL) of the server.
CA Certificate
The certificate of the certification authority. The certificate is needed to encrypt your certificate
request before sending it to the certification authority.
You can type the name of the certificate in this field in which case the system fetches a certificate
by that name from the address (URL) in the previous field. Alternatively, you can type in the
address (URL) where the certificate can be found or click the Browse button to locate the file
where the certificate can be found. You can also use the menu item Paste from Clipboard, if you
have copied the certificate to the Clipboard in advance.
Use proxy server
Select, if necessary. Click the Settings button to specify the values. Not that is must be possible to
resolve the certification authority address (URL) on the loca host.
Reference Number
Needed if CMP protocol is applied in enrollment. The reference number along with the key (see
below) is used to identify the user requesting the certificate.
Key
Needed if CMP protocol is applied in enrollment. A shared secret, granted by the certification
authority. The key identifies the user requesting the certificate
ClickNext to enroll.
•
7.
Off-line request: On the Certification Request File dialog box, select the file where to save the
request. Click the Browse button to locate the file.
Click Finish to complete the creation of a new certificate.
If you saved your request in a file, you must take care of delivering your request to the certification authority
yourself.
10.2.3 Importing Certificates
When importing a certificate of the local host you can
64
•
import only the certificate
•
import the certificate with the corresponding key pair
•
import the certificate, the corresponding key pair and the certificate of the certification authority
The certificate can be of the following format: Privacy Enhanced Mail (PEM), binary or PKCS#12. The last
mentioned can also contain the key pair and the certificate of the authority. If you try to import a certificate
but the corresponding key pair cannot be found, not in the certificate file nor in the key management tree, the
system prompts you to locate the file containing key pair in PKCS#1 format. For general instructions on
how to import a certificate, see Section 11.2.1 ’Importing Certificates’.
Importing PKCS#12 certificate files
A certificate file of format PKCS#12 contains the end entity (local host) certificate, the authentication key
pair and the certificate of the certification authority that has issued the end entity certificate. You can import
all of these:
1.
Select the My Keys branch on the Key Management page with the secondary mouse button and click
Import in the menu that opens. Note that the Add button launches the wizard for creating a new authentication key.
2.
On the Open dialog box, browse the file system for the certificate file. You can restrict the number of
files shown by the appropriate selection in the Files of type field.
3.
The system first prompts for the password that protects the key pair against unauthorized access. Then,
you are asked to verify the importation of first the end entity certificate and next the certification authority certificate. To import, click Yes in both. Be sure only to import certificates that you can trust. If necessary, check the fingerprint of the certificates.
4.
Note that the certification authority certificate is imported to the active policy only. However, since your
own certificates are common to all policies, the certificate just imported is visible in any policy. Thus, if
you change the active policy, the certificate appears not trusted in the new, active policy. To make it
trusted in the other policies, you must import the certification authority certificate to each of these policies. You can either import the certificate from the PKCS#12 file or copy the certificate to the Clipboard
and paste it from there.
5.
Since the certificates are not yet saved in the rule database, they now appear as if they were not trusted.
Click Apply on Policy Editor to update the rule database.
10.2.4 Removing the Default Identity Certificate
The self-signed certificate created as a part of the software installation is considered your default identity
which should always be present. If you try to remove the certificate, the system forces you to create a new
self-signed certificate which is then considered the default identity. Only if the creation is successful, the old
default identity certificate is removed.
10.2.5 Polling Certification Requests
1.
Once you have sent a certification request to an authority, the certificate appears in pending status. You
can poll the status of your request:
1.
Select the certificate in pending status. Click the Poll button, that appears.
2.
The system polls the certificate. If the certification authority has already issued you the certificate, the
polling returns the certificate to you. If the request is still pending, the status is not updated.
65
The system automatically polls the requests from time to time. As soon as the authority issues the certificate,
the status is updated.
10.3 Managing Pre-Shared Keys
10.3.1 Creating Pre-Shared Keys
A wizard guides you through the process of creating a new certificate:
1.
Select the My Keys branch or any of the items under it, and click the Add button.
2.
Select the option Create a new pre-sharedpre-shared key on the New Authentication Key dialog
box. Click Next to proceed.
3.
The dialog box called Pre-Shared Key Information opens. Fill in the appropriate values:
Name
Give the pre-shared key an arbitrary name. Something descriptive is recommended.
Shared secret
Type in the secret shared by you and the other end. The text will not be shown in plain text. The security
of a shared secret depends on how "good" the password is. Passwords that are common words are
extremely vulnerable to dictionary attacks, for example. Consequently, using a pre-shared secret as an
authentication method should be replaced by certificates whenever possible. If pre-shared keys are used,
the secrets should be chosen carefully. Follow the guidelines set up by your network administrator.
Confirm Shared Secret
Retype the string to detect potential typos.
Fingerprint (SHA-1)
The system automatically calculates a checksum on the shared secret using SHA-1 MAC algorithm,
while you type it. The fingerprint is unique and the calculation is extremely hard to invert, meaning that
it is virtually impossible to figure out the shared secret, even if you know the algorithm and the fingerprint. You can confirm with the other communicating party, that the secret that you are using is the
same, by exchanging the fingerprint on the phone, for example. That way, there is no need to reveal the
actual secret. Naturally, both ends need to apply the same algorithm in order to get similar fingerprints.
4.
Click Finish to complete the creation of a pre-shared key.
The identity of the pre-shared key is set to no identity by default. You can update the identity information, as
well as other properties of a pre-shared key, on the Pre-Shared Key dialog box. See Section 10.3.4 ’PreShared Key Properties’ for details.
10.3.2 Viewing and Editing Pre-Shared Keys
The pre-shared keys are listed under the My keys branch of the key management tree. You can view and edit
a pre-shared key on the Pre-Shared Key Properties dialog box:
1.
Select the pre-shared key and click the Properties button.
66
2.
The Pre-Shared Key dialog box opens. View and edit the values. You can shift between the two pages
with the General and Identity tabs.
3.
Once ready, click OK to accept the changes and to return to Policy Editor. To discard the changes,
click Cancel.
4.
set and the key management. Thus Apply or OK enforces and Cancel discards all changes made so far.
10.3.3 Removing Pre-Shared Keys
To remove a pre-shared key:
1.
Select the key on Policy Editor.
2.
3.
To make the removal permanent, click either OK or Apply. OK also closes Policy Editor. You can
restore the key management tree after even several removals by clicking Cancel, provided that you have
not yet enforced the changes with Apply or OK.
10.3.4 Pre-Shared Key Properties
The pre-shared key properties are shown on the Pre-Shared Key Properties dialog box with two pages, the
General and the Identity.
General Properties
Pre-Shared Key
The name of the pre-shared key. It is given by the user when creating the pre-shared key. Not updateable.
Key Identity
The local host identifier. You can change the identity on the Identity sheet.
Shared Secret
The secret in non-readable form. Bear in mind, that the security of a pre-shared secret depends on how
"good" the secret is as a password. Passwords that are common words are extremely vulnerable to dictionary attacks, for example. Consequently, using a pre-shared secret as an authentication method
should be replaced by certificates whenever possible. If pre-shared keys are used, the secrets should be
chosen carefully. Follow the guidelines set up by your network administrator.
Confirm Secret
The check field to avoid typos.
Fingerprint
The checksum of the shared secret calculated by the system using SHA-1 MAC algorithm. The fingerprint is unique and the calculation is extremely hard to invert, meaning that it is virtually impossible to
figure out the shared secret, even if you know the algorithm and the fingerprint. You can confirm with
the other communicating party, that the secret that you are using is the same, by exchanging the finger-
67
print on the phone, for example. That way, there is no need to reveal the actual secret. Naturally, both
ends need to apply the same algorithm in order to get similar fingerprints.
Figure 10.1 The properties of a pre-shared key
Identity
The identities associated with the pre-shared key are shown on the Identity page. You can specify the identity of both the local and the remote host. By default, both identities are set to no identity.
Local subject identity
This piece of information identifies your host. Select if you want to specify the host IP address, host
domain name or administrator e-mail address. Naturally, you can also set the identity to no identity. A
static IP address or domain name is recommended. In the field below, specify the actual identifier.
Remote subject identity
This piece of information identifies the remote host. Select if you want to specify the host IP address,
host domain name or administrator e-mail address. Naturally, you can also set the identity to no identity. A static IP address or domain name is recommended. In the field below, specify the actual identifier.
68
Chapter 11 Certificate Management
69
11.1 What Is a Certificate?
The certificates in the key management fall into the following categories:
•
certificates of the local host (My keys)
•
certificates of the trusted certification authorities
•
certificates of the trusted remote hosts
•
certificates of the trusted policy servers
The category dictates the purpose of the certificate. However, the general management of the certificates is
very much alike across the categories. The following descriptions of certificate management can be applied
to all certificates unless otherwise stated. The few special operations on the certificates of the local host are
explained in Section 10.2 ’Managing My Certificates’.
11.2 Managing Certificates
11.2.1 Importing Certificates
Why Import Certificates Manually?
Situations when you have to manually import a certificate include the following:
•
You have enrolled for certification and the authority returns the certificate in a file.
•
A remote host or a certification authority provides its certificate in a file.
Needless to say, be careful to only import certificates that you trust.
What Happens when Importing?
To import only usable certificates, SSH Sentinel does some elementary checking on them:
1.
The overall usability: the certificate encoding should be correct and the system should be able to read
the certificate.
2.
The validity period should not be passed.
70
3.
SSH Sentinel requires that the digital signature extension is selected.
4.
If you are adding a certification authority, then the corresponding flag field should be available.
When importing a self-signed certificate of a remote host, the system signs the certificate with the selfsigned certificate of the local host. Since your own self-signed certificate listed is considered a trusted certification authority, the certificate chain is complete. You can import certificates of PEM (Privacy Enhanced
E-mail), PKCS#12 or binary formats.
Importing from a File
To add a certificate from a file, follow these steps:
1.
Select the branch in the key management tree where you want to add the certificate and select Import in
the menu that opens with the secondary mouse button. If you are importing a local host certificate,
select the correct key pair. For details on how to import certificates from a file in PKCS#12 format, see
Section 10.2.3 ’Importing Certificates’.
2.
In the dialog box that opens, browse for the certificate in your file system. Once you have located it,
click Open. You can import a certificate of PEM (Privacy Enhanced E-mail), PKCS#12 or binary formats. The system shows you the basic information, including the fingerprint, of each certificate being
imported and asks you to verify the importing. Be sure to only import certificates that you trust. If necessary, check the fingerprint with the other end, the certification authority, for example.
3.
Alternatively, you can drag and drop a PEM encoded certificate file to the key management tree. Simply,
drag the file over the correct branch (or key pair in case of a local host certificate) and drop it there.
If you are importing a certification authority, trusted policy server or a remote host certificate, the Add button functions similarly to the Import menu item. However, in association with the local host certificates, the
Add button launches the wizard for creating a new authentication key. See Section 10.2.2 ’Creating Certificates’.
Pasting from Clipboard
You can also paste a certificate which you previously have copied to the Clipboard:
1.
Select the correct branch (or key pair if pasting a certificate of the local host) from the key management
tree with the secondary mouse button.
2.
Select Paste in the menu that opens. The normal key bindings, Shift+Insert and Ctrl-v also work.
3.
Click Apply or OK to put your changes into effect. Clicking OK also closes Policy Editor. To discard
the changes, click Cancel. Note: These actions affect all modifications in the rule set and the key management. Thus clicking Apply or OK enforces and clicking Cancel discards all changes made so far.
Selecting from List
You can import certificates of certification authorities by selecting them from a list. The certification athtority certificates found on a smart card are shown in this list. Before you can use a smart card certificate for
authentication, you must import the corresponding certification authority certificate.
1.
Double-click the Select from List branch under Certification Authorities in the key management tree.
71
2.
A dialog box containing a listing of certificates, opens. The certificates found on a smart card are shown
on the SSH Accession page. Mark those you want to add by checking the box on the left. You can view
a certificate by selecting it and clicking the View button.
3.
When you have selected the certificates click the OK button to import. To not to import any, click Cancel. Both buttons return you to Policy Editor.
4.
11.2.2 Exporting Certificates
To export a certificate, in other words, to save it to a file, do the following:
1.
Select the certificate you want to export and click the View button to open the Certificate Information
dialog box.
2.
Click the Export button. A standard dialog box for saving files opens.
3.
Select the location where you want to store the file and the file format. You can save the certificate in
PEM and binary formats.
4.
Once you have saved the certificate, you find yourself back on the Certificate Information dialog box.
Click Close to return to Policy Editor.
Copying Certificates to Clipboard
You can copy a certificate to the Clipboard where it is available for pasting into various applications:
1.
Select the certificate you want to copy.
2.
Open the menu with the secondary mouse button and select Copy.
11.2.3 Renaming Certificates
To rename a certificate:
1.
Select the certificate.
2.
Open the menu with the secondary mouse button and click Rename.
3.
Type in the new name. The name of the certificate is for your own reference only.
4.
Click Apply or OK to confirm the change. Clicking OK also closes Policy Editor. To discard the
changes, click Cancel. Note: These actions affect all modifications in the rule set and the key management. Thus clicking Apply or OK enforces and clicking Cancel discards all changes made so far.
11.2.4 Removing Certificates
To remove a certificate:
1.
Select the certificate on Policy Editor.
2.
72
3.
can restore the key management tree after even several removals by clicking Cancel, provided that you
have not yet committed the changes with OK or Apply.
You cannot remove a certificate that is used in a rule. If you try to, the system will prompt you to first
remove the dependency, then remove the certificate.
The self-signed certificate created as a part of the software installation is considered your default identity
which should always be present. If you try to remove the certificate, the system forces you to create a new
self-signed certificate which is then considered the default identity. Only if the creation is successful, the old
default identity certificate is removed.
11.2.5 Viewing Certificate Information
To view a certificate, open the Certificate Information dialog box:
1.
Select the certificate you want to view and click the View button.
2.
View the information. You can shift between the two pages with the General and Details tabs.
3.
Once ready, close the dialog box by clicking Close.
The Export button is used for exporting certificates as explained in Section 11.2.2 ’Exporting Certificates’
11.2.6 Viewing and Editing Certificate Properties
To view and modify the properties of a certificate
1.
Select the certificate whose properties you want to view or edit and click the Properties button.
2.
View and edit the information on the Certificate Properties dialog box.
3.
Once ready, click OK to accept the changes and return to Policy Editor. To discard the changes, click
Cancel instead.
4.
11.3 Certificate Information
The certificate information is shown on the Certificate Information dialog box. The General page shows a
few main values whereas the Details page lists them all.
Certification path
The certification path shows how the certificate has inherited the trust. Suppose, that the certificate is
issued by a certification authority called A1. Then A1 is shown in the list. And, suppose that A1 has
received its certificate from an upper-level certification authority called B2. Then, both B2 and A1
would be listed. Since you trust B2, you can trust the certificate it has issued to A1. Thus, you trust A1
and also the certificates issued by it. If the certificate is a root certification authority certificate, it is
alone in the list. If the certificate validity period has passed by, the text Not trusted is shown.
73
Subject name
The so-called common name of the certificate holder. The host domain name, for example.
Alternative Names
An alternative name of the host. Typically the IP address, the domain name or e-mail address.
Issuer name
The issuer of the certificate, the certification authority.
Valid from
The beginning of the validity period, date and time. Outside of the validity period, the certificate is classified as not trusted.
Valid to
The end of the validity period, date and time. Outside of the validity period, the certificate is classified
as not trusted.
Certificate fingerprint
A checksum on the certificate calculated by the system. With the fingerprint, it is easy and fast to verify
if two people are talking about the same certificate. They only need to check that the algorithm used and
the fingerprint itself are the same.
Version
The version of the X.509 certificate.
Serial number
The serial number of the certificate, given by the issuing authority. The certification authority binds a
consecutive number to each certificate it issues.
Figure 11.1 The certificate information
74
Issuer Alt. Names
An alternative name of the certification authority. Typically the IP address, the domain name or an email address.
Usage
A description on how the certificate is intended to be used. Common examples are authentication and
certifying other certificates.
CRL distribution point
Information on how the certificate revocation list (CRL) can be found. Revocation lists are published by
certification authorities and they list all the certificates, issued by the authority in question, that for
some reason have lost their credibility. The value in this field is merely a search key. The directory services, see Chapter 12 ’Directory Services’ are taken advantage of, when actually locating the revocation
list.
Signature algorithm
The algorithm applied to create the keys associated with the certificated.
Fingerprint algorithm
The algorithm used to calculate the certificate fingerprint, a checksum of the certificate. With the fingerprint, it is easy and fast to verify if two people are talking about the same certificate. They only need to
check that the algorithm used and the fingerprint itself are the same.
Fingerprint
The checksum of the certificate.
Public Key
The public key associated with the certificate. The data field shows the algorithm and key length
whereas the key itself can be seen on the lower half of the window.
For documentation on the Export button, see Section 11.2.2 ’Exporting Certificates’.
11.4 Certificate Properties
Trust in certification path verification
In the normal case, the option is selected and the certification authority trusted. In some situations, however, you might not want to trust the certificate but still want to store the certificate in the system. Then,
a certificate this authority has issued to your own host, is displayed with the Not trusted label on it. You
do not accept the certificates of remote hosts issued by this authority as authentication, either. (See the
option below for further discussion.)
Accept connections if authenticated with a certificate issued by this CA
This option is only available, if the option above is selected. If you then select this option, you accept
connections from and to the remote hosts with certificates issued by the certification authority. If you do
not select this option, the net effect of the two options is that you do not accept connections from the
remote hosts that authenticate with certificates issued by this authority, even though you actually trust
the certificates. However, you do consider your own certificates issued by the authority applicable for
authentication.
75
Issues certification revocation lists (CRL)
If selected, the certification authority publishes certification revocation lists (CRL) which should be
checked before making the final decision on trusting a certificate.
Figure 11.2 The certificate properties
76
Chapter 12 Directory Services
77
Chapter 12Directory Services
12.1 What Are Directory Services?
The certification authorities publish revocation lists (CRLs) on certificates that for some reason have lost
their credibility. Before establishing a connection, your system should check the revocation list, to verify
that the remote end's certificate is still trusted by the authority that has issued it.
To be able to locate the revocation list that a certification authority has placed on a remote server, you need
to define a directory service. The directory services are also taken advantage of, when locating centrally
managed policies on remote servers and the certificates associated with such policies.
12.2 Managing Directory Services
12.2.1 Adding Directory Services
To add a directory service, do the following:
1.
Select the Directory Services branch on Policy Editor, and click the Add button to open the Directory
Service dialog box.
2.
Fill in the values:
•
Give the service a descriptive name.
•
Specify the server name and the port.
•
If necessary, specify the proxy settings.
3.
See Section 12.3 ’Directory Service Properties’ for further reference.
4.
Once ready, click OK to add the service. To discard your changes, click Cancel. Both buttons return
you to Policy Editor.
5.
78
12.2.2 Viewing and Editing Directory Services
Expand the Directory Services branch and you see a listing on the existing directory services. The details
of a service are shown on the Directory Service dialog box. To view and edit the values, do the following:
1.
On the Key Management page, select the directory service you want to view and click the Properties
button OR double-click the directory service you want to view or edit.
2.
The Directory Service dialog box opens. There are two pages, the General and the Advanced. View
and update the values.
3.
Once ready, click OK to accept your changes. Cancel discards the changes you made on this dialog
box. Both close the Directory Service dialog box and return you to Policy Editor.
4.
12.2.3 Removing Directory Services
To remove a directory service:
•
Select the directory service on Policy Editor.
•
•
can restore the key management tree after even several removals by clicking Cancel, provided that you
have not yet enforced the changes with Apply or OK.
Figure 12.1 The general properties of a directory service
79
12.3 Directory Service Properties
Name
A descriptive name given by you to the directory service. It will be used as the name shown under the
Directory Services branch in the key management.
Access protocol
The protocol used in accessing the service. At the moment, only Lightweight Directory Access Protocol
(LDAP) is supported.
Server name
The server that provides the directory service.
Submit login information automatically
Select if the server requires you to log in and if you want to submit the login information automatically.
Specify the login name and password in the fields provided.
12.3.2 Advanced Properties
Server port
The number of the server port used.
Proxy settings
The proxy and socks settings are taken advantage of when getting through the firewall if the server is
protected by one. Select the option Use a proxy server if necessary. Click the Settings button to view
and edit the settings. Note that it must be possible to resolve the server address on the local host.
12.3.3 Proxy and Socks Settings
You can specify the HTTP and socks proxy settings manually or click the Auto-detect button to automatically find out the settings. To accept the changes, click OK. To discard, click Cancel. Both buttons return
you to the Directory Service window.
80
Chapter 13 Maintenance
81
Chapter 13Maintenance
There are several tools available in SSH Sentinel to monitor the network traffic. These tools range from connection diagnostics - simple IKE probing to check a single connection - to general network traffic statistics
and to auditing rules.
13.1 Auditing
You can set any of the rules in the security policy to be audited. Being audited, each time the rule is applied,
it appears as an event in an audit log. You can view the audit log through a Web interface.
13.1.1 Auditing Rules
You can set any of the rules - filter rules, IPSec rules, and the default response rule - to be audited. Naturally,
you can audit any number rules simultaneously.
•
icon. OR
•
•
•
For details on how to audit the default response rule, refer to Section 8.2.2 ’Auditing Default Response
Rule’
82
13.1.2 Audit Settings
Manage the audit logs, on the Audit Settings dialog box. To open the dialog box:
1.
Select Auditing in the SSH Sentinel main menu.
2.
Select Audit Settings in the submenu that opens.
Figure 13.1 The audit settings
Allowed Users
Allowed users
The Allowed users box lists all the users that are granted access to your audit logs. When opening the
web interface to view the logs, user name and password are inquired.
You can add users by clicking the Add button and typing the user name and password (twice for
checkup) in the text fields provided. You can remove users with the Remove button and change the
password by clicking the Properties button.
Audit server port
The port to access the audit server with the interface to the audit logs.
Allow remote access to audit server
If selected, remote access to the audit server is allowed. If not selected, the audit server can only be
accessed from your local host.
Log file disk space usage
The log files tend to increase in size, especially if you include a large number of rules and there is a lot of
network action on your host. It is crucial that you limit the size of the log files and that you remove old files
regularly. Use these controls to achieve automatic clean-up and limitation of disk usage.
83
Min. free space
This setting limits the size of the audit log by dictating how much free space there should be left on the
hard disk after the audit log is saved. If there is no space left, the log is not written and thus you miss the
events.
To change, either move the slider or type the figure in the field provided. The scale is from 0 to 1024
megabytes.
Remove after
This figure shows the clean-up interval. All logs older that the limit are automatically removed from the
hard disk.
To change the figure, either move the slider or type the figure in the text filed. The scale is from 0 to 365
days.
Audit folder location
The path tells where the audit log is stored. You can specify the location by clicking the Browse button.
13.1.3 Viewing Audit Logs
You view the audit logs with a web browser interface. To be able to access the resources, exclude the local
host (127.0.0.1) from those hosts for which a proxy server is used. To view the logs, select View Audit Logs
under Auditing in the SSH Sentinel main menu. The interface first prompts you for the user name and password which are set on the Audit Settings dialog box. Having typed those correctly, the main page with general information opens. The host in question is identified on the first page by the IP address and the DNS
name. Click View audit logs link to see a listing on available logs and select the one you want to view.
The system creates an audit log every day, even an empty log if there are no events to log. A new event is
written in the log each time a rule being audited is applied. Changing the applied policy does not change the
audit log file.
You can reduce the number of events shown by filtering the events by time and remote host. The listing
shows the following information on each event:
Time
The logging time.
Event
The type of the event. If the event was triggered by an IPSec rule, the type of the event is trigger. Internet Key Exchange (IKE) causes events Phase 1 succeeded, Phase 1 failed, Phase 2 succeeded and
Phase 2 failed. If the event was triggered by a filter rule, the event is, depending of the action, bypass,
drop or reject. If it was the default response rule that allowed the traffic, the event is allow. In addition,
there are various events caused by the IKE engine, like delete payload received or invalid payload
length most often reporting a problem.
Rule/Source
If the event was caused by a rule that was applied, the group of the rule (e.g. pre-IPSec filter, secured
connection) is shown in this field. Click to see the details of the rule. If the rule has been removed or
altered it obviously cannot be viewed. But the event can also be triggered by the IKE engine, in which
case the filed contains IKE.
84
Local
The IP address of the local host. Click to see the details.
Direction
The arrow denotes the direction of the network traffic.
Remote
The IP address of the remote host. Click to see the details.
Protocol
The traffic protocol.
Count
The events are written in the log every five seconds. If during that time, the same event is detected multiple times, the count is increased rather that the event written several times.
13.2 IKE Log
To detect and study problems in establishing connections to remote hosts, use the SSH Sentinel IKE Log
with information on Internet Key Exchange (IKE) negotiations. The information can also be written into a
file. Open the IKE Log from the SSH Sentinel main menu: Select Auditing and View IKE Log Window.
Figure 13.2 The IKE Log window.
The amount of information you receive depends on your choice of logging level:
•
If set off, no information is logged.
•
On the low level, you get information about the success or failure of the negotiation. In case of a successful negotiation, the parameters established are shown. If the negotiation fails, you will get a rough
idea of the reason.
•
On the moderate level, more detailed information about the negotiation is shown. The moderate level is
usually suitable for finding the reason for a failed negotiation.
•
85
The detailed level gives you all the available information. In most cases, the detailed level should not be
used because of the excessive amount of messages. Using the detailed level, also slows down the negotiations.
To write the messages to a file, select the Log to file option and browse for the file where to write the messages.
If you close the log window while logging to a file, the system asks if you wish to keep on writing the messages to the file. If you choose to continue logging, it will not stop until you specifically turn logging off.
13.3 Connection Diagnostics
You can test a secured connection or a virtual private network connection by running the diagnostics on it.
To run the diagnostics, select the rule and click the Diagnostics button. Alternatively, you can select Diagnostics in the menu that opens with the right mouse button.
It is recommended that you run the connection diagnostics already when you create a rule. If the packets are
dropped due to a failed negotiation when actually establishing the connection, you are not informed about it.
The diagnostics runs a normal connection negotiation. However, the security associations that a created as a
result of the negotiation, are destroyed immediately. Also, if the security associations exist when the diagnostics is run, they are destroyed.
Figure 13.3 The results of a connection diagnostics.
13.4 Statistics
The SSH Sentinel Statistics shows the information on data traffic from and to your host. You can view the
established security associations, the data packets transmitted and the errors detected in the data traffic, for
example.
86
Open SSH Sentinel Statistics from the main menu by selecting View Statistics. There are two pages on the
dialog box: Security Associations and IPSec Statistics.
13.4.1 Security Associations
The Security Associations page shows the established and currently existing security associations.
Name
The IP address or DNS name of the other end.
Type
The type of the security association, ESP or ESP+IPComp
KBytes in
The amount of data received by the local host.
KBytes out
The amount of data transmitted by the local host.
You can terminate a security association by selecting it and clicking the Terminate button.
Figure 13.4 The established security associations are displayed on the Statistics dialog box
13.4.2 IPSec Statistics
On the IPSec Statistics page, you can monitor the overall data traffic on your local host.
Encryption
The graphics indicate the data throughput in kilobytes.
87
Network Usage History
The diagram shows the history of data traffic. It distinguishes between plaintext packets, encrypted packets
and dropped packets.
IKE Negotiations
IKE Phase-1 Total
The total number of IKE Phase-1 negotiations started.
IKE Phase-1 Failed
The number of those IKE Phase-1 negotiations that have failed.
IKE Quick Mode Total
The total number of IKE negotiations started in quick mode.
IKE Quick Mode Failed
The number of the IKE negotiations in quick mode that have failed.
IP Packets
Here you see the number of IP packets in transmission. There are separate figures for AH, ESP and plaintext packets as well as for packets dropped by the filter rules and triggered by the IPSec engine.
Figure 13.5 The IPSec statistics
IPSec Errors
With the information presented in this box, you can track errors in the data packets received. There are separate figures for different types of errors. Errors that fall beyond the categories are classified as other errors.
Decryption and decompression errors are simply errors that occur when a data packet is decrypted or
decompressed, respectively. An authentication error occurs when the origin of the data packet can not be
authenticated, that is, you do not trust the certificate of the other end, for example. Replay errors are associ-
88
ated with a well-known attack type in the Internet: some hostile party transmits the same data packets over
and over again. When there is something wrong with the padding inserted to a data packet that would otherwise be short, a padding error occurs.
Chapter 14 Glossary
89
Chapter 14Glossary
This glossary contains definitions of special terms and abbreviations used in the customer documents of
SSH Communications Security. For more information on terms related to Internet security, see RFC 2828.
access control A security measure that prevents unauthorized use of resources. In the IPSec context, the
resources to which access is being controlled are usually the computing cycles of a host, the data stored in it,
the network behind a security gateway, or the bandwidth on that network.
Advanced Encryption Standard (AES)
AES is the new U.S. government standard for a symmetric
encryption algorithm. AES uses the Rijndael block cipher and it is defined by the National Institute of
Standards and Technology (NIST) in FIPS 197.
authentication The verification of the identity of a person or a process. In a communications system,
authentication verifies that messages come from their stated source.
Authentication Header (AH) An upper level header located between the IP header and the payload
within an IP packet. Typically, an AH includes an integrity check value (ICV) of the transfer-independent
contents of the IP packet. The exact nature of the checksum depends on the transformation used. An AH is
used to ensure the integrity of the whole IP packet, including both the payload and the IP header. It does not
provide data confidentiality. The AH transformation is defined in RFC 2402.
availability A security service that addresses the security concerns engendered by attacks on networks
that deny or degrade service. For example, in IPSec, the use of replay prevention mechanisms in AH and
ESP support availability.
base 64 A method of representing six-bit strings of binary data (values 0-63) using 64 ASCII characters.
Base 64 encoding was originally used with Privacy Enhanced Mail (PEM), thus it is sometimes referred to
as PEM-encoding.
block cipher A representative of symmetric (secret-key) encryption algorithms that encrypts a fixed
length block of plaintext (for example, 64 bits) at a time. With a block cipher, the same plaintext block will
always encrypt to the same ciphertext block, under the same key.
90
Chapter 14 Glossary
Blowfish A symmetric block cipher designed by Bruce Schneier. Blowfish uses a block size of 64 bits
and a key length of 32 to 448 bits.
Border Gateway Protocol (BGP) A routing protocol that is normally used between independent Internet service providers. The protocol is defined in RFC 1771.
CAST-128 A symmetric block cipher with a block size of 64 bits and a key length of up to 128 bits.
CAST-128 is believed to be very strong. See RFC 2144 for more information.
certificate
Certificates are digital documents that are used for verifying the identity of communicating
parties. In this documentation, the term certificate is commonly used to refer to X.509 public-key certificates. A public-key certificate binds identity information about an entity to the entity's public key for a certain validity period.
certificate enrollment
Certificate enrollment is an action wherein a public key gets certified by a certification authority (CA). In this action a client provides the CA with a public key and some additional data in
a certification request. The CA signs this key together with additional information with its own private key
and returns the signed certificate to the client.
Certificate Management Protocol (CMP)
CMP defines online interactions between the end entities,
the registration authorities, and the certification authority in a PKI. It is developed by the PKIX Working
Group of the IETF and specified in RFC 2510. An advanced version of CMP, known as CMPv2, is currently
an Internet-Draft.
certificate revocation list (CRL)
A signed list containing the serial numbers of the certificates that
have been revoked or suspended by the certificate issuer (the CA) before their expiration date. The CA usually issues new CRLs at frequent intervals. Current PKIX implementation of CRLs is the X.509 version 2
CRL. See RFC 2459 for more information.
certification authority (CA) An entity in a PKI that issues digital certificates (especially X.509 publickey certificates) and vouches for the binding between the data items in a certificate.
Certificate users (end entities) depend on the validity of information provided by a certificate. Thus, a CA
should be someone that the end entities trust, and usually holds an official position created and granted
power by a government, a corporation, or some other organization.
certification request
A certification request contains at least the public key and some identity information of the entity making the request, and it is signed with the private key of the entity. Certification
requests are generated by end entities or RAs and sent to the CA. If allowed by the certificate policy of the
CA, a certificate can be issued based on the request.
ciphertext
TText which has been encrypted by an encryption system. The opposite is plaintext.
Chapter 14 Glossary
91
confidentiality A security service that protects data from unauthorized disclosure. Usually, unauthorized
disclosure of application level data is the primary concern, but the disclosure of the external characteristics
of communication can also be a concern in some circumstances. The traffic flow confidentiality service
addresses this latter concern by concealing source and destination addresses, message length, or frequency
of communication. In the IPSec context, using ESP in tunnel mode, especially at a security gateway, can
provide some level of traffic flow confidentiality. See also traffic analysis.
cryptology
methods.
The branch of mathematics that studies the mathematical foundations of cryptographic
Data Encryption Standard (DES)
DES is a U.S. Federal Information Processing Standard (FIPS) that
defines the Data Encryption Algorithm (DEA). The term DES is also commonly used when referring to the
algorithm.
The algorithm itself is a symmetric block cipher with a block size of 64 bits and a key length of 64 bits (of
which 8 are parity bits). It was created in the 1970s by IBM assisted by the U.S. National Security Agency
(NSA). Based on Horst Feistel's ideas, the team of scientists at IBM devised a cipher that has influenced the
science of cryptology.
The controversy around DES key length and design issues has developed many variants of the original algorithm. 3DES (also known as triple DES or TDEA) is the most accepted. Most of what is known about block
ciphers is due to analysis of DES. DEA and TDEA are defined in FIPS 46-3. 3DES
Diffie-Hellman key exchange A method for key exchange between two parties. This method can be
used to generate an unbiased secret key over an insecure medium. The method has many variants. A well
known attack called the man-in-the-middle attack forces the use of digital signatures or other means of
authentication with the Diffie-Hellman protocol.
digital signature By encrypting a digest of a message with the private key, authentication can later be
performed by applying the public key to an encrypted digest (digital signature) and comparing the result to
the digest of the message.
Digital Signature Algorithm (DSA) DSA is a public-key algorithm for digital signatures. The DSA
algorithm was invented by the U.S. National Security Agency (NSA) and it is defined by NIST in FIPS
186-2. For more information, see e.g. Bruce Schneier: "Applied Cryptography". See also DSS.
Digital Signature Standard (DSS) The U.S. digital signature standard defined by National Institute of
Standards and Technology (NIST). It is a standard for digital signatures using the DSA public-key algorithm and the SHA-1 hash algorithm.
domain name A domain name is a textual name for an Internet host, e.g. www.ssh.com. The Domain
Name System (DNS) infrastructure is used to map domain names to IP addresses. See STD 13 for more
information.
denial of service (DoS) Denotes attacks that do not cause a security violation per se, but harm the availability of a service. For example, if an attacker sends lots of forged packets to an IPSec VPNhost, they may
92
Chapter 14 Glossary
degrade the performance of the host. One of the design goals in the SSH IPSEC architecture has been to
minimize the consequences of denial-of-service attacks.
Dynamic Host Configuration Protocol (DHCP) A protocol that provides a means to dynamically allocate IP addresses to computers on local area networks (LANs). The system administrator assigns a range of
IP addresses to DHCP, and each client computer on the LAN has its TCP/IP software configured to request
an IP address from the DHCP server. The request and grant process uses a lease concept with a controllable
time period. DHCP is defined in RFC 2131.
Encapsulating Security Payload (ESP) An upper level IP header that denotes that the contents of the
payload are encrypted and possibly also otherwise protected. An ESP may appear after the IP header, after
an ESP header or theoretically also elsewhere within an IP packet. An ESP only protects the contents of the
payload, not any associated header. Therefore it is possible, for example, to change any field in the header
of the IP packet carrying an ESP without causing a security violation. The contents of the ESP header are
unknown to anyone not possessing information about the transformation and SA needed to recover the protected data. An ESP may also contain integrity protection. The ESP protocol is defined in RFC 2406. .
encryption A security mechanism used for the transformation of data from an intelligible form (plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The inverse transformation process
is called decryption.
end entity A human user or an application to whom a certificate is issued. The end entity has also the
private key counterpart of the public key in the certificate.
firewall A node located on the perimeter of an administrative domain that implements the security policy of the domain. A firewall usually performs address and port-based packet filtering and usually has
proxy servers for e-mail and other services.
General Packet Radio Service (GPRS) An emerging data transmission technique based on GSM that
does not set up a continuous channel from a portable terminal for the transmission and reception of data, but
transmits and receives data in packets. GPRS allows data rates from 56 to 114 kbit/s. As GPRS becomes
available, mobile users of virtual private networks (VPN) will be able to access the private network continuously rather than through a dial-up connection.
Global System for Mobile Communications (GSM) GSM is a standard for digital mobile communications, with a capability for international roaming. GSM is operated in the 900 MHz and 1800 MHz frequency bands in Europe and Asia, and in the 800 MHz and 1900 MHz frequency bands in the Americas.
Traditional GSM handsets allow data rates of up to 14.4 kbit/s. HSCSD and GPRS have been developed to
improve the data capabilities of GSM.
hash function An algorithm that computes a short digest of a longer message. The digest is usually of a
fixed size. See also MD5 and SHA-1.
Hash Message Authentication Code (HMAC) A secret-key authentication algorithm. Data integrity
and data origin authentication as provided by HMAC depend on the scope of the distribution of the secret
Chapter 14 Glossary
93
key. If only the source and destination know the HMAC key, this provides both data origin authentication
and data integrity for packets sent between the two parties. If the HMAC is correct, this proves that it must
have been added by the source.
High Speed Circuit Switched Data (HSCSD) An enhancement of GSM allowing circuit switched data
transmission over a GSM link at up to 57.6 kbit/s.
host Any node that does not forward packets that are not addressed to the node itself. Generally this
term is used to refer to any computer or other computing device connected to an IP-based network.
Hypertext Transfer Protocol (HTTP) HTTP is the protocol used to transfer Web pages from a WWW
server to the browser. The HTTP client sends requests to the server, and gets some data as a response.
HTTP identifies objects on the server using URIs or URLs. For more information, see RFC 2068.
integrity
A security service that ensures that data modifications are detectable. Integrity services need
to match application requirements. Although authentication and integrity services are often cited separately, in practice they are intimately connected and almost always offered together.
integrity check value (ICV) Usually, an HMAC algorithm using either MD5 or SHA-1 hash functions,
but possibly also a DES-MAC or HMAC-RIPEMD algorithm. See also integrity.
Internet Engineering Task Force (IETF) An international standards body that has standardized the IP
protocol and most of the other successful protocols used on the Internet. The IETF Web pages are available
at .
Internet Key Exchange (IKE) The key-establishment protocol used with IPSec. IKE was formerly
called the ISAKMP/Oakley key exchange. The IKE protocol is defined in RFC 2409, RFC 2408, and RFC
2407.
Internet Protocol (IP) The network layer for the TCP/IP protocol suite, defined in STD 5. IP is a connectionless, best-effort packet switching protocol. It provides packet routing, fragmentation, and re-assembly through the data link layer.
Internet Protocol Security (IPSec) A protocol suite for protecting IP traffic at packet level defined by
the Internet Engineering Task Force (IETF). IPSec can be used for protecting the data transmitted by any
service or application that is based on IP. The IPSec protocols are defined in RFC 2401. RFC 2411 is a good
starting point for reading about IPSec.
Internet Security Association and Key Management Protocol (ISAKMP)
A protocol for establishing, negotiating, modifying, and deleting SAs. ISAKMP provides a framework for authentication and key
exchange but does not define them. ISAKMP is designed to be key exchange independent. That is, it is
designed to support many different key exchanges. The ISAKMP/Oakley combines ISAKMP with the
Oakley key exchange. Oakley describes a series of key exchanges called modes and details the services pro-
94
Chapter 14 Glossary
vided by each. For example, perfect forward secrecy for keys, identity protection, and authentication.
ISAKMP is a part of the IKE protocol.
IP address In IPv4, a 32-bit number that identifies the devices using the IP protocol. An IP address can
be unicast, broadcast, or multicast. Please see STD 5 for more information.
IP header The part of the IP packet that carries data used on packet routing. The size of this header is 20
bytes, but usually the IP options following this header are also calculated as header. The maximum length of
the header is 60 bytes. The header format is defined in STD 5 (also RFC 791).
IP packet A self-contained, independent entity of data carrying sufficient information to be routed from
the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network. The Internet Protocol (IP) is defined in STD 5.
IP payload
The part of the IP packet that carries upper level application data.
IP version 4 (IPv4)
This is the current version of the Internet Protocol (IP).
IP version 6 (IPv6) This is a new version of the Internet Protocol (IP) ("next generation" IP). Among
other improvements it has an extended address space and better security. It is described in RFC 2460. There
is no version five.
Layer Two Tunneling Protocol (L2TP) L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications. L2TP is defined in
RFC 2661.
Lightweight Directory Access Protocol (LDAP)
LDAP is a directory access protocol defined by RFC
2251 and RFC 1777 for accessing directories supporting the X.500 models, while not incurring the
resource requirements of the X.500 Directory Access Protocol (DAP). This protocol is specifically targeted
at management applications and browser applications that provide read/write interactive access to directories. The protocol is carried directly over TCP or other transport, bypassing much of the session/presentation overhead of X.500 DAP.
life duration In IKE, life duration means the actual length of the security association's (SA) life. It can
be specified either as the maximum number of seconds the SA can be used, or as the maximum number of
kilobytes that can be transmitted using the SA.
MARS A symmetric block cipher with a block size of 128 bits and a variable key length (from 128 to
448 bits). MARS is designed by IBM and it was one of the five final candidates for the U.S. Advanced
Encryption Standard (AES).
Maximum Transfer Unit (MTU) A control value used for avoiding unnecessary fragmentation of TCP
packets. The TCP Maximum Segment Size (MSS) detection achieves this by limiting the size of TCP pack-
Chapter 14 Glossary
95
ets to match the MTU of the underlying network. Special care is needed when tunneling packets in a way
that increases their size; the tunneling node may then need to do Path MTU discovery to avoid fragmentation.
MD5 A message-digest algorithm developed by Ron Rivest of RSA Security. It computes a secure, irreversible, cryptographically strong 128-bit hash value for a document. The algorithm is documented in RFC
1321. Newer 160-bit algorithms such as SHA-1 are thought to be more secure than MD5.
NAT-Traversal (NAT-T) IPSec and NAT do not normally work together, as IPSec considers the packet
processing of NAT as a violation of communications integrity. The IPSec NAT-Traversal solution was
developed by SSH Communications Security to overcome this incompatibility problem. NAT-Traversal
works by encapsulating the IPSec packets into UDP envelopes that contain information on recreating the
IPSec packet. The UDP traffic follows the same route as the IKE negotiation. NAT-Traversal is currently an
Internet-Draft.
Network Address Translation (NAT) A network address translator is a device that is connected to two
networks, and translates IP addresses in packets sent across it. Typically, one of the networks will use global addresses, and the other will use local addresses. NATs are becoming increasingly common on the
Internet, because the available IP address space is running scarce and NATs help large organizations to
avoid renumbering their computers if they, for example, change Internet service providers.
There are two variations of traditional NAT: IP Network Address Translation (also called Basic NAT), and
Network Address Port Translation (NAPT), which may map multiple (local) IP addresses to a single (global) IP address but with different port numbers. Obviously, only TCP and UDP protocols work over NAPT.
For more information on traditional NAT, see RFC 3022. In addition to traditional NAT, a method called
Network Address Translation - Protocol Translation (NAT-PT) exists for translating between IPv4 and IPv6
addresses. NAT-PT is described in RFC 2766.
Network File System (NFS)
ing on heterogeneous systems.
node
NFS is a standard that implements a client/server architecture for file shar-
In this document, a node refers to any system implementing the TCP/IP protocol suite.
Network Time Protocol (NTP) A protocol used for synchronizing timekeeping among a set of distributed time servers and clients on the Internet. The protocol is capable of accuracy within milliseconds over
long time periods. It is defined in STD 12 (RFC 1119).
Online Certificate Status Protocol (OCSP) In some applications, such as banking and e-commerce, it
may be necessary to obtain certificate revocation status that is more timely than is possible with CRLs.
OCSP may be used to determine the current revocation status of a digital certificate, instead of or as a supplement to checking against a periodically published CRL. OCSP is described in RFC 2560.
packet filtering A method for determining how passing IP packets should be handled. Packet filtering
is applied to all IP packets passing the IPSec Engine. Packet filtering may modify the IP packet, pass it
intact, or even drop it.
96
Chapter 14 Glossary
Path MTU Path Maximum Transfer Unit. Different from the MTU in the sense that Path MTU is bound
to the source and destination addresses of the network. Path MTU discovery is discussed in RFC 1191.
perfect forward secrecy (PFS) Refers to the notion that any single key being compromised will permit
access to only data protected by that single key. In order for PFS to exist, the key used to protect transmission of data must not be used to derive any additional keys. If the key used to protect transmission of data
was derived from some other keying material, that material must not be used to derive any more keys. Also
referred to as public-key forward secrecy (PFS).
PKCS #1 This standard defines the usage of RSA algorithm in encryption and digital signatures. It contains explicit suggestions for the encoding of keys and algorithm input formatting.
PKCS #7 This standard defines the general syntax for data that may have cryptography applied to it. This
data includes digital signatures and recursive digital envelope encoding for cryptographic objects.
PKCS #8
This standard describes syntax for private-key information, including a private key and a set
of attributes. The standard also describes syntax for encrypted private keys.
PKCS #10
This standard defines a format for certification requests.
PKCS #11 This standard defines CryptoKi, which is an interface for cryptographic devices (for example,
smart cards and cryptographic accelerators).
PKCS #12 This standard defines a portable format for storing or transporting a user's private keys, certificates, and miscellaneous secrets. PKCS #12 is supported by common Web browsers for importing and
exporting user private keys.
PKCS #15 This standard defines how keys, certificates, and application-specific data may be stored on
an ISO/IEC 7816 compliant smart card.
PKIX Public-Key Infrastructure (X.509); a collective name for an architecture and set of protocols
based on X.509, drafted by an IETF working group of the same name.
plaintext
Text which has not been encrypted. The opposite is ciphertext.
Point-to-Point Protocol (PPP)
PPP provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is defined in STD 51 (also RFC 1661).
pre-shared secret
The use of pre-shared secrets (pre-shared keys) in authentication means that the communicating parties have a shared password or key that has been generated beforehand.
Chapter 14 Glossary
97
Pre-shared secrets can be used in IKE. In this case two peers have configured a shared password that is used
to authenticate the end points by means of encryption (A can decipher packet B has encrypted, therefore A
knows B knows the same secret it knows and vice versa). This authentication method scales badly and is
useable for a very limited number of hosts. For a large set of hosts certificate-based authentication should be
used.
Privacy Enhanced Mail (PEM) A suite of protocols for encryption, authentication, message integrity,
and key management. For more information, see RFC 1421. PEM is commonly used to refer to an encoding
method where binary objects such as certificates are converted to a printable format using a 64-character
subset of the alphabet (this is also known as base 64 encoding).
private key In public-key cryptography the private key is only known to the holder, and it can be used to
sign and decrypt messages.
proxy Proxy is a cache server that acts as a firewall, protecting the local network. It allows an application inside the proxy to access resources on the global Internet.
public key In public-key cryptography the public key, which is included in the certificate, can be used
to verify signatures and encrypt messages.
public-key cryptography In contrast to symmetric (secret-key) cryptography with just one cipher key,
in public-key cryptography each person or host has two keys. One is the private key, which is used for signing outgoing messages and decrypting incoming messages, the other is the public key, which is used by
others to confirm the authenticity of a signed message coming from that person and for encrypting messages addressed to that person. The private key must not be available to anyone but its owner, but the public
key is spread via trusted channels to anyone.
Public-Key Cryptography Standards (PKCS) The PKCS standards are a document series from RSA
Laboratories. Some of the most important PKCS standards include PKCS #1 for RSA encryption and signature formats, PKCS 7 for cryptographic message encapsulation, PKCS #10 for certification requests, and
PKCS #11 for a cryptographic token interface commonly used with smart cards.
public-key infrastructure (PKI) PKI consists of end entities possessing key pairs, certification authorities, certificate repositories (directories), and all the other software, components, and entities required
when utilizing public-key cryptography.
RC5 A symmetric block cipher designed by Ronald Rivest for RSA Security in 1994. RC5 uses a block
size of 32 to 128 bits and a key length of 0 to 2040 bits. Also the number of encryption rounds can range
from 0 to 255.
RC6 A symmetric block cipher based on RC5 and designed by Rivest, Sidney, and Yin for RSA Security. The block size, the key size, and the number of rounds are variable; the upper limit on the key size is
2040 bits. RC6 was one of the five final candidates for the U.S. Advanced Encryption Standard (AES).
98
Chapter 14 Glossary
registration authority (RA)
An optional entity in a PKI, separate from the CA(s). The functions that
the RA performs will vary from case to case but may include identity authentication and name assignment,
key generation, token distribution, and revocation reporting.
Request For Comments (RFC)
located at .
A document of the Internet Society under standardization. RFCs can be
Rijndael Designed by Joan Daemen and Vincent Rijmen, Rijndael is a symmetric block cipher with a
variable block size of 128, 192, or 256 bits and a variable key length of 128, 192, or 256 bits. Rijndael is the
algorithm used in the U.S. Advanced Encryption Standard (AES).
router A node that forwards packets not addressed to itself. Requirements for a router are defined in
RFC 1812.
RSA A public-key encryption and digital signature algorithm, invented by Ron Rivest, Adi Shamir, and
Leonard Adleman. For more information, see e.g. Bruce Schneier: "Applied Cryptography". The RSA
algorithm was patented by RSA Security, but the patent expired in September 2000.
security association (SA) A unidirectional connection created for security purposes. All traffic traversing an SA is provided the same security processing. In the IPSec context, an SA is an internet layer abstraction implemented through the use of an AH or ESP. It contains data controlling how a transformation is
applied to an IP packet. The data is determined using specially defined SA management mechanisms. The
data may be a result of an automated SA and key negotiation or it may be defined manually. This term is
defined in RFC 2401.
security policy The purpose of an security policy is to decide how an organization is going to protect
itself. The policy will generally require two parts: a general policy and specific rules (system specific policy). The general policy sets the overall approach to security. The rules define what is and what is not
allowed. In this document the term security policy is typically used when referring to the latter. The security
policy describes how data is protected, which traffic is allowed or denied, and who is able to use the network resources.
Simple Certificate Enrollment Protocol (SCEP)
SCEP is developed by Cisco Systems and VeriSign.
It is an enrollment protocol supported by Cisco's routers.
Secure Hash Algorithm (SHA) A United States standard for a cryptographically strong hash algorithm,
designed by National Security Agency (NSA) and defined by National Institute of Standards and Technology (NIST). See also MD5.
security gateway (SGW) An intermediate system that acts as the communications interface between
two networks. The internal subnetworks and hosts served by a security gateway are presumed to be trusted
because of shared local security administration. See also trusted subnetwork.
The set of hosts and networks on the external side of the security gateway is viewed as not trusted or less
trusted. In the IPSec context, a security gateway is the point at which an AH or ESP is implemented in order
Chapter 14 Glossary
99
to serve a set of internal hosts. A security gateway provides security services for these hosts when they
communicate with external hosts also employing IPSec either directly or via another security gateway. The
term is defined in RFC 2401.
security parameters index (SPI) An arbitrary value used in combination with a destination address and
a security protocol to uniquely identify an SA. The SPI is carried in AH and ESP protocols to enable the
receiving system to select the SA under which a received IP packet will be processed. An SPI has only local
significance as it is defined by the creator of the SA, which is usually the receiver of the IP packet carrying
the SPI. Thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose
to interpret the bits in an SPI to facilitate local processing. This term is defined in RFC 2401.
SHA-1 Improved version of the original Secure Hash Algorithm (SHA). The algorithm produces a 160bit message digest and it is considered very good. It is part of the U.S. Digital Signature Standard (DSS) and
it is defined in FIPS 180-1
Simple Network Management Protocol (SNMP) A protocol that is commonly used to monitor the status of routers and other network elements. The protocol is defined in STD 15 (also RFC 1157).
smart card A smart card, or an integrated circuit card, is a device for secure identification of users of
information systems. Typically smart cards contain a processor that can do a private-key operation using a
private key on the card, some kind of a file system that can hold certificates, public keys, or other data relevant for the use of the card.
SOCKS
SOCKS is a protocol for traversing through application gateway firewalls. It allows an application inside the firewall to access resources on the global Internet. The protocol is defined in RFC 1928.
Standard (STD) A subseries of Request For Comments (RFC) that specify Internet standards. The standards in the STD series also retain their RFC numbers.
stream cipher A representative of symmetric (secret-key) encryption algorithms that encrypt a single bit
at a time. With a stream cipher, the same plaintext bit or byte will encrypt to a different bit or byte every
time it is encrypted.
traffic analysis The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. For example, frequency of transmission, the identities of the conversing parties, sizes of
IP packets, and flow identifiers.
transformation A particular type of change applied to an IP packet. For example, ESP encryption, AH
integrity service, and payload compression are transformation types. An SA supplies the keys and other
association-specific data to a transformation. The IPSEC transformations are defined in RFC 2401, RFC
2402, RFC 2403, RFC 2406, and RFC 2405. .
100
Chapter 14 Glossary
Transmission Control Protocol (TCP) A widely used connection-oriented, reliable (but insecure) communications protocol. This is the standard transport protocol used on the Internet. It is defined in STD 7
(also RFC 793).
Transport Layer Security (TLS) Transport Layer Security is a protocol providing confidentiality,
authentication, and integrity for stream-like connections. It is typically used to secure HTTP connections.
The protocol is being standardized by a working group of the IETF.
trusted subnetwork A subnetwork of hosts and routers that can trust each other not to engage in active
or passive attacks. It is also assumed that the underlying communications channel such as a LAN or CAN is
not being attacked by any other means.
Twofish A strong and fast block cipher designed by Bruce Schneier. Twofish was one of the five final
candidates for the United States government's new cipher standard, AES (Advanced Encryption Standard).
Twofish uses a block size of 128 bits and a key length of up to 256 bits.
uniform resource identifier (URI) URIs are supposed to identify resources or objects in the world or on
the Internet. They are defined in RFC 2396. The most commonly used form of an URI is an URL.
uniform resource locator (URL) URLs are used to describe the location of Web pages, and are also
used in many other contexts. An example of an URL is http://www.ssh.com/ipsec/index.html. They are
defined in RFC 1738 and RFC 1808. URLs are a special case of URIs
User Datagram Protocol (UDP) A datagram-oriented unreliable communications protocol widely used
on the Internet. It is a layer over the IP protocol. UDP is defined in STD 6 (also RFC 768).
virtual private network (VPN) Virtual private networking is the use of encryption in the lower protocol
layers to provide a secure connection through an otherwise insecure network, typically the Internet. The
encryption may be performed, for example, by firewall software, by a router, or by a dedicated VPN security gateway.
X.500 The family of joint ITU-T/ISO standards defining the X.500 Directory. The directory can be used
for many applications, such as storing certificates, or information about people. LDAP is often used to
access the X.500 Directory.
X.509 The ITU-T X.509 recommendation defines the formats for X.509 certificates and X.509 CRLs.
Different X.509 applications are further defined by the PKIX Working Group of the IETF. These include
X.509 version 3 public-key certificates and X.509 version 2 CRLs.
Index
101
Index
Numerics
3DES 14, 48
A
abbreviations 89
active policy 18, 21, 23, 24
adding
directory services 77
policies 21
rules 34, 41, 42
VPN connection rules 41
Advanced Encryption Standard (AES) 98
AES 14, 48
aggressive mode 48
allow 28, 31, 55
application security 9
audit log 18, 82, 83
audit settings 18, 82
auditing 18, 35, 37, 44, 46, 53, 81
default response rule 53, 55, 81
rules 35, 37, 44, 46, 81
authentication 9, 57, 58, 61
authentication key 45, 57
authentication key pair 12, 57, 62
B
Basic NAT 95
Blowfish 14, 48
bypass 27, 29, 30, 31, 32, 36
C
cache server 97
CAST 14, 48
centrally managed policy 22, 24
certificate 57, 61, 69
creating 12, 13, 14, 62, 63
enrollment 13, 14, 58, 62
exporting 71
fingerprint 73, 74
importing 63, 69, 70
information 72
not trusted 72
pending 64
polling 64
properties 72, 74
removing 71
renaming 71
viewing 72
Certificate Management Protocol (CMP) 13, 14, 63
certificate revocation list (CRL) 58, 74, 75, 77
certification authority 13, 20, 58, 59, 61, 63, 69
certification path 72
certification request 13, 14, 62, 63
Cisco Systems 98
confidentiality 9
connection diagnostics 41, 42, 44, 85
creating
certificates 13, 14, 62, 63
pre-shared keys 65
creating certificates 12, 13
CryptoKi 96
D
Data Encryption Algorithm (DEA) 91
datagram 100
DEA 91
decryption 92
default identity certificate 12, 64, 72
default response rule 20, 27, 28, 31, 53
auditing 53, 55, 81
editing 53
IP traffic handler 55
IPSec response 54
viewing 53
default response trust policy 54
defining networks 37, 52
deny 28, 31, 55
DES 14, 48, 91
diagnostics 41, 42, 44, 85
Diffie-Hellman key exchange 49
digest 91, 92
digital signature 91
102
Directory Access Protocol (DAP) 94
directory service 20, 58, 60, 74, 77
adding 77
editing 78
properties 79
removing 78
viewing 78
disabling rules 35, 44
Domain Name System (DNS) 91
drop 27, 29, 30, 31, 32, 36
DSA 91
Dynamic Host Configuration Protocol (DHCP) 50,
51
E
eavesdropping 8
editing
default response rule 53
policies 22
pre-shared keys 65
rules 34, 43
enabling rules 35, 44
encryption algorithm 14, 48
encryption speed 14
enrolling for a certificate 13, 14, 58, 62
enrollment protocol 13, 63
evaluation order 29, 35
exporting
certificates 71
extended authentication 46, 52
F
faking network addresses 8
Federal Information Processing Standard (FIPS) 91
filter rule 34
selector 27, 36
fingerprint 65, 67, 73, 74
FIPS 180-1 99
FIPS 186-2 91
FIPS 197 89
FIPS 46-3 91
G
glossary 89
H
hash function 48
hijacking communications 8
I
IBM 91, 94
identity 66, 67
IKE Config Mode 50, 51
Index
IKE group 48
IKE Log Window 18, 84
IKE mode 48
IKE proposal 47, 49
importing
certificates 63, 69, 70
policies 22
initiator 28
installation
remote 11
requirements 11
installing SSH Sentinel 12
integrated circuit card 99
integrity 9, 48
integrity check value (ICV) 89
Internet 8
Internet Engineering Task Force (IETF) 8
Internet host 91
Internet Key Exchange (IKE) 28, 30, 32, 57, 59, 84,
87, 96
Internet Protocol (IP) 8
IP compression 46
IP spoofing 8
IP version 4 (IPv4) 8, 95
IP version 6 (IPv6) 8, 95
IPSec 8, 93
IPSec Engine 17, 28, 95
IPSec mode 49
IPSec rule 28
ITU-T X.509 100
K
key exchange 91
Key Management page 19, 20, 59, 61
L
Layer 2 Tunnelling Protocol (L2TP) 50, 51
legacy proposal 41, 45
licensing agreement 12
Lightweight Directory Access Protocol (LDAP) 79
local policy 21, 23
M
main mode 48
maintenance 81
managing
certificates 61
connection rules 41
filter rules 34
incoming traffic 31, 32
outgoing traffic 29, 30
policies 21, 22, 23
pre-shared keys 65
rules 34, 35, 41, 42, 43, 44
Index
man-in-the-middle attack 91
maximum transfer unit (MTU) 47
modifying evaluation order 35
My Keys 20, 59, 60, 61, 62, 69
N
NAT Traversal (NAT-T) 47
National Institute of Standards and Technology
(NIST) 89, 91, 98
National Security Agency (NSA) 91, 98
NAT-PT 95
Network Address Port Translation (NAPT) 95
Network Address Translation (NAT) 47
Network Editor 37, 52
network error 8
normal proposal 45
O
off-line enrollment 13, 14, 63
online enrollment 13, 63
opening
Policy Editor 19
VPN connections 19, 47
operating system security 9
P
peer-to-peer connection 40
pending certification request 64
perfect forward secrecy (PFS) 49
PKCS#1 64
PKCS#10 63
PKCS#12 63, 64, 70
platform support 11
policy
activating 18, 23, 24
adding 21
centrally managed 22, 24
editing 22
expiry time 24
importing 22
local 21, 23
properties 22, 23
removing 22
shared 24
signature 24
viewing 22
Policy Editor 17, 18, 19, 27, 28, 61
Policy Manager 17, 18, 19, 28
starting 19
stopping 19
polling
centrally managed policies 22
certificates 64
post-IPSec filter 28, 30, 33
103
pre-IPSec filter 28, 29, 31, 33
pre-shared key 57, 61, 96
creating 65
editing 65
fingerprint 65, 67
properties 66
removing 66
viewing 65
primary identifier 62
Privacy Enhanced Mail (PEM) 64, 70
private key 57
proposal template 45
proxy server 63
proxy settings 14, 79
public key 57, 90
public-key infrastructure (PKI) 9, 13, 58
R
reject 27, 29, 30, 31, 32, 36
remote installation 11
removing
certificates 71
policies 22
pre-shared keys 66
rules 34, 42
SSH Sentinel 15
renaming
certificates 71
responder 28
RFC 1119 95
RFC 1157 99
RFC 1191 96
RFC 1321 95
RFC 1421 97
RFC 1661 96
RFC 1738 100
RFC 1771 90
RFC 1777 94
RFC 1808 100
RFC 1812 98
RFC 1928 99
RFC 2068 93
RFC 2131 92
RFC 2144 90
RFC 2251 94
RFC 2396 100
RFC 2401 93, 98, 99
RFC 2402 89, 99
RFC 2403 99
RFC 2404 99
RFC 2405 99
RFC 2406 92, 99
RFC 2407 93
104
RFC 2408 93
RFC 2409 93
RFC 2411 93
RFC 2459 90
RFC 2460 94
RFC 2510 90
RFC 2560 95
RFC 2661 94
RFC 2766 95
RFC 2828 89
RFC 3022 95
RFC 768 100
RFC 791 94
RFC 793 100
RSA 96, 97
RSA Security 95, 97, 98
rule
adding 34, 41, 42
auditing 35, 37, 44, 46, 81
disabling 35, 44
editing 34, 43
enabling 35, 44
properties 36, 37, 45
removing 34, 42
viewing 34, 43
rule database 17, 28
rule evaluation order 29, 35
S
Secure Hash Standard (SHS) 98, 99
secured connection 28, 40
secured network 28, 40
security association 28, 29, 46, 49, 50
Security Policy page 19, 20, 27
security problem 9
selector 27, 36
self-signed certificate 13, 58, 61, 62, 70
shared policy 24
shared secret 65, 66
Simple Certificate Enrollment Protocol (SCEP) 13,
63
Simple Policy Retrieval Protocol (SPRP) 22
Simple Policy Specification Language (SPSL) 22
smart card 18, 61
socks settings 79
spoofing 8
SSH Accession Lite 12, 15, 18, 61
SSH Sentinel agent 18, 19
SSH Sentinel help 19
SSH Sentinel icon 18, 19
SSH Sentinel licensing agreement 12
SSH Sentinel support 8, 19
starting Policy Manager 19
statistics 18, 85
Index
STD 12 95
STD 13 91
STD 15 99
STD 5 93, 94
STD 51 96
STD 6 100
STD 7 100
stopping Policy Manager 19
supported platforms 7, 11
T
taking over communications 8
TCP/IP 100
TDEA 91
terms 89
testing connections 41, 42, 44, 85
traffic filter 20, 27, 33
troubleshooting 18, 81, 84
trusted policy server 20, 25, 59, 69
trusted remote host 20, 60, 69
tunnel mode 49
Twofish 14, 48
U
updating SSH Sentinel 12, 15
usepackage{float} 1
V
VeriSign 98
viewing
audit logs 83
certificates 72
default response rule 53
policies 22
pre-shared keys 65
rules 34, 43
virtual IP address 46, 50, 51
virtual private network (VPN) 28, 39
W
Windows 2000 11
Windows 95 7, 11
Windows 98 7, 11
Windows Me 7, 11
Windows NT4 7, 11
Windows XP 7, 11
X
X.500 Directory 94, 100
X.509 v2 CRL 90, 100
X.509 v3 certificate 100
Index
105

SSH Sentinel 1.3.2 User Manual

Transcription

Similar documents

Certificate of Registration Glasseal Products Inc.

ISO 9001:2008 Certified - AFC

Certificate of Registration Glasseal Products Inc.

ssh real estate represents pond lehocky stern giordano in 52000 sf

parathom - Stillwaters Law Firm

HPC at IU - Hands-on exercises - Research Technologies

Master of Optometry (M.Optom) - The Sankara Nethralaya Academy

Certificate of Registration Williamston Products, Inc.

12-29-15 TEFCU FUSE Brochure-web

III-Structural Composite CD`s 9-14