mylove_x138x_forever
New Member
Download miễn phí Đề tài Phần mềm bảo mật trên môi trường Solaris
Mục lục
Mở đầu
Chương 1: Khái quát chung về giải pháp bảo vệ gói IP bằng kỹ
thuật mật mã
1.1 Can thiệtp mật mã vào hệ thống mạng dùng giao thức TCP/IP
1.1.1 Can thiệp mật mã vào các tầng trong giao thức TCP/IP1
1.1.2 ý nghĩa của việc can thiệp mật mã vào tầng IP 8
1.1.2.1 Bảo vệ được dữ liệu của tất cả các ứng dụng dùng giao thức
TCP/IP
1.1.2.2 Không phải can thiệp và sửa đổi các ứng dụng hiện có
1.1.2.3 Trong suốt với người dùng
1.1.2.4Tăng cường các khả năng của Firewall
1.1.2.5 Giảm số đầu mối cần can thiệp dịch vụ an toàn
1.1.2.6 Cho phép bảo vệ dữ liệu của một số ứng dụng giao tiếp thời gian thực
1.2 Giao thức an toàn tầng Internet
1.2.1 Quá trình truyền dữ liệu của giao thức TCP/IP
1.2.2 Cấu trúc TCP/IP với giao thức an toàn tầng Internrt
1.3 Các dịch vụ bảo vệ gói IP bằng kỹ thuật mật mã
1.3.1 Dịch vụ bí mật
1.3.2 Dịch vụ xác thực và toàn vẹn
1.3.3 Kết hợp dịch vụ bí mật với dịch vụ xác thực, an toàn
1.3.4 Kỹ thuật đóng gói trong việc bảo vệ gói IP
1.4 Mô hình chức năng của hệ thống bảo vệ gói IP dùng kỹ thuật mật mã
1.4.1 Liên kết an toàn trong hệ thống bảo vệ gói IP
1.4.1.1 Khái niệm về liên kết an toàn
1.4.1.2 Mối quan hệ giữa liên kết an toàn và giao thức an toàn tầng IP
1.4.2 Mô hình chúc năng của hệ thống bảo vệ gói IP bằng kỹ thuật mật mã
1.4.3 Những yếu tố ản hưởng đến dộ an toàn của hệ thống bảo vệ gói IP
1.4.3.1 Độ an toàn của các thuật toán mã hoá và xác thực dữ liệu
1.4.3.2 Độ an toàn của giao thức thiết lập liên kết an toàn
1.4.3.3 An toàn hệ thống
Chương II: Cơ chế quản lý dữ liệu của giao thức TCP/IP trên Solaris
2.1 Giới thiệu về luồng (Stream) trong Solaris
2.1.1 Khái niệm về luồng
2.1.2 Các thao tác trên luồng
2.1.3 Các thành phần của luồng
2.1.3.1 Các hàng đợi (queue)
2.1.3.2 Các thông báo (Message)
2.1.3.3 Các mô đun
2.1.3.4 Các tiên trình điều khiển (Driver)
2.2 Cơ chế quản lý luồng (Stream mechanism)
2.2.1 Giới thiệu về cơ chế quản lý luồng
2.2.2 Xây dựng luồng
2.2.2.1 Mở một file thiết bị STREAMS
2.2.2.2 Thêm và huỷ các mô đun
2.2.2.3 Đóng một luồng
2.3 Các trình xử lý luồng
2.3.1 Các thủ tục put và service
2.3.1.1 Thủ tục put
2.3.1.2 Thủ tục service
2.4 Các thông báo
2.4.1 Giới thiệt về thông báo
2.4.2 Cấu trúc thông báo
2.4.3 Gửi và nhận thông báo
2.4.5 Cấu trúc hàng đợi (queue)
2.4.5 Xử lý các thông báo
2.4.6 Giao diện dịch vụ
2.4.7 Một số cấu trúc dữ liệu được dùng trong luồng
2.5 Các trình điều khiển
2.5.1 Tổng quan về trình điều khiển
2.5.2 Đa luồng (Multiplexing)
2.5.2.1 Giới thiệu về đa luồng
2.5.2.2 Xây dựng đa luồng STREAMS TCP/IP
Chương III: Giải pháp bảo vệ dữ liệu trong nhân hệ điều hành Solaris
3.1 Giải pháp bảo vệ gói IP trên Solaris bằng kỹ thuật mật mã
3.1.1 Đặt vấn đề
3.1.2 Mô hình mạng WAN bảo vệ gói IP bằng kỹ thuật mật mã
3.1.3 Giải pháp bắt gói IP để thực hiện việc mã hoá
3.1.4 Quản lý dữ liệu gói IP tại tầng IPF
3.1.5 Cơ chế mã hoá dữ liệu gói IP của STREAMS TCP/IP
3.1.6 Quản lý gói tại STREAMS TCP/IP
3.1.7 Mã dữ liệu trong gói IP
3.1.8 Tích hợp nút mã hoá với Router lọc gói
Chương IV: Khảo sát khả năng chống lại các phần mềm Hacker và
tốc độ truyền dữ liệu của hệ thống bảo vệ gói IP trên Solaris
4.1 Khảo sát khả năng bảo vệ gói IP trên mạng LAN của bộ phần mềm
IPSEC_SUN
4.1.1 Khả năng ngăn chặn các tấn công bằng phần mềm Sniffit V.0.3.5
4.1.2 Khả năng ngăn chặn các tấn công bằng phần mềm IPSCAN
4.1.3 Khẳ năng ngăn chặn và tấn công bằng phần mềm Packetboy
4.1.4 Khẳ năng ngăn chặn các tấn công bằng phần mềm ICMP_Bomber
4.1.5 So sánh khẳ năng chống lại các phần mềm tấn công của bộ phần
mềm IPSEC_SUN và bộ phần mềm FreeS/WAN
4.2 Khảo sát sự ảnh hưởng của bộ phần mềm IPSEC_SUN đối với thời
gian truyền dữ liệu của một số dịch vụ
4.2.1 Khảo sát sự ảnh hưởng của bộ phần mềm IPSEC_SUN đối với thời
gian truyền dữ liệu của dịch vụ truyền tệp FTP (File Transfer Protocol)
4.2.2 So sánh thời gian truyền dữ liệu giữa hai hệ thống dùng IPSEC_SUN và FreeS/WAN
Kết luận 89
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Tóm tắt nội dung tài liệu:
đầu mối (notes) đ−ợc kết hợp với nótrong hệ thống file và đ−ợc truy nhập dùng lời gọi hệ thống open(). Mỗi đầu vào
hệ thống file t−ơng ứng với một thiết bị minor riêng rẽ của trình điều khiển. Việc
mở các thiết bị minor của các trình điều khiển tạo ra các luồng riêng rẽ đ−ợc kết
nối giữa tiến trình ng−ời dùng và trình điều khiển. Một mô tả file (file
description) đ−ợc trả lại bởi lời gọi open đ−ợc dùng để truy nhập tới luồng.
Khi thiết bị đ−ợc mở, một tiến trình ng−ời dùng có thể gửi dữ liệu tới thiết bị
dùng lời gọi hệ thống write() và nhận dữ liệu từ các thiết bị dùng lời gọi hệ thống
read(). Việc truy nhập luồng dùng các lời gọi hệ thống read và write t−ơng thích
với cơ chế vào ra ký tự truyền thống. Lời gọi hệ thống close() đóng một thiết bị
và huỷ một luồng đ−ợc liên kết bởi lần gọi open cuối cùng. Điều khiển luồng
(flow control) là một cơ chế STREAMS điều khiển tốc độ các thông báo truyền
qua các mô đun, trình điều khiển, đầu luồng và các tiến trình. Điều khiển luồng
có tác động riêng rẽ đến luồng. Nó hạn chế số ký tự có thể xếp hàng để xử lý tại
một hàng đợi bất kỳ trong luồng . Cơ chế này hạn chế các vùng nhớ đệm và việc
xử lý tại các hàng đợi và trong một luồng bất kỳ. Điều khiển luồng không tác
động đến các thông báo có quyền −u tiên cao.
2.1.3 Các thành phần của luồng
2.1.3.1 Các hàng đợi (queue)
Một hàng đợi là một giao diện giữa một trình điều khiển STREAMS hay
mô đun với phần còn lại của luồng. Mỗi thể hiện (instance) của một trình điều
khiển đ−ợc mở hay một mô đun đ−ợc thêm vào có một cặp hàng đợi đ−ợc cấp
phát, một hàng đợi đọc (đón dữ liệu từ d−ới lên) và một hàng đợi viết (đón dữ
liệu từ trên xuống). Các hàng đợi luôn luôn đ−ợc cấp phát nh− một cặp liền kề,
t−ơng tự nh− một mảng của các cấu trúc. Hàng đợi có địa chỉ thấp là hàng đợi
đọc, hàng đợi có địa chỉ cao là hàng đợi viết.
33
Một thủ tục service của hàng đợi đ−ợc cần đến để xử lý các thông báo trên
hàng đợi. Nó chuyển các thông báo khỏi hàng đợi, xử lý chúng, và gọi thủ tục put
của mô đun tiếp theo trong luồng để chuyển thông báo đã đ−ợc xử lý tới hàng đợi
tiếp theo.
Một thủ tục put của hàng đợi đ−ợc cần đến bởi thủ tục put hay service để
thêm một thông báo tới hàng đợi hiện tại. Nếu một mô đun không cần xử lý
thông báo, thủ tục put của nó có thể gọi thủ tục put của hàng đợi liền kề.
Mỗi hàng đợi có một con trỏ chỉ tới trình (routine) open và close.
Trình open của trình điều khiển đ−ợc gọi khi trình điều khiển lần đầu tiên
đ−ợc mở và mỗi lần luồng mở. Trình open của mô đun đ−ợc gọi khi mô đun lần
đầu tiên đ−ợc thêm vào luồng và mọi lần mở của luồng. Trình close của mô đun
đ−ợc gọi khi mô đun bị xoá khỏi luồng. Trình close của trình điều khiển đ−ợc gọi
khi luồng bị tháo dỡ (dismantled).
2.1.3.2 Các thông báo (message)
Tất cả các đầu vào và đầu ra của STREAMS đ−ợc dựa trên các thông báo.
Các đối t−ợng đ−ợc chuyển giữa các mô đun STREAMS là các con trỏ chỉ tới các
thông báo. Tất cả các thông báo STREAMS dùng hai cấu trúc thông báo (msgb
và datab) để chỉ tới dữ liệu thông báo (message data). Các cấu trúc dữ liệu này
mô tả kiểu của thông báo và chứa các con trỏ chỉ tới dữ liệu của thông báo, cũng
nh− các thông tin khác. Các thông báo đ−ợc gửi qua luồng bằng việc gọi thủ tục
put của mỗi mô đun hay trình điều khiển trong luồng.
a.Các kiểu thông báo
Tất cả các thông báo STREAMS đ−ợc gán các kiểu thông báo xác định
cách thức sử dụng chúng bởi mô đun và trình điều khiển và việc điều khiển
chúng bởi đầu luồng. Một trình điều khiển hay một mô đun có thể gán hầu hết
các kiểu tới các thông báo mà chúng sinh ra và một mô đun có thể thay đổi kiểu
của các thông báo trong quá trình xử lý chúng. Đầu luồng sẽ chuyển đổi các lời
gọi hệ thống nhất định tới các kiểu thông báo riêng và gửi chúng xuống, đồng
thời đầu luồng đáp ứng các lời gọi khác bằng việc sao chép nội dung của các kiểu
thông báo đ−ợc gửi lên.
Hầu hết các kiểu thông báo đ−ợc trao đổi ở phạm vi bên trong STREAMS
và chỉ có thể chuyển từ thành phần này tới thành phần khác của STREAMS. Một
vài kiểu thông báo, ví dụ nh− M_DATA, M_PROTO, M_PCPROTO có thể
34
chuyển giữa một đầu luồng và các tiến trình ng−ời dùng. Các thông báo
M_DATA chứa dữ liệu trong một luồng và giữa một đầu luồng và một tiến trình
ng−ời dùng. Các thông báo M_PROTO hay M_PCPROTO chứa dữ liệu và các
thông tin điều khiển.
Nh− chỉ ra trong hình 2.2, một thông báo STREAMS chứa một hay nhiều
khối thông báo (message block) liên kết với nhau và đ−ợc gắn với khối thông báo
đầu tiên của cùng thông báo.
Các thông báo có thể tồn tại đơn lẻ (stand-alone) khi thông báo đ−ợc xử lý
bởi một thủ tục.
Hình 2.2: Một thông báo của luồng
Một cách luân phiên, một thông báo có thể đợi để đ−ợc xử lý trên một danh
sách liên kết của các thông báo đ−ợc gọi là hàng đợi thông báo. Trong hình 2.3
thông báo 2 đ−ợc liên kết với thông báo 1.
Khi một thông báo đ−ợc xếp hàng trong một hàng đợi, khối đầu tiên của
thông báo chứa các liên kết tới các thông báo tr−ớc và sau ở trên cùng một hàng
đợi thông báo và một liên kết tới khối thông báo thứ hai của thông báo (nếu nó
tồn tại). Đầu (head) và đuôi (tail) của hàng đợi thông báo đ−ợc chứa trong hàng
đợi. Các trình STREAMS (STREAMS routine) cho phép các nhà phát triển điều
khiển các thông báo và hàng đợi thông báo.
b.Quyền −u tiên xếp hàng thông báo
Message queueing Priority) 35
Hình 2.3: Các thông báo trên một hàng đợi thông báo
Trong những tr−ờng hợp nhất định, các thông báo chứa thông tin khẩn
(urgent information) phải chuyển nhanh qua luồng. Để đáp ứng đòi hỏi này,
STREAMS cung cấp nhiều lớp quyền −u tiên . Tất cả các thông báo có một
tr−ờng quyền −u tiên đ−ợc gán . Các thông báo bình th−ờng (Normal message) có
quyền −u tiên là 0. Các thông báo −u tiên có quyền lớn hơn 0. Các thông báo −u
tiên cao có quyền −u tiên cao do kiểu thông báo của chúng. Theo quy −ớc,
STREAMS ngăn chặn việc các thông báo −u tiên cao bị khoá bởi điều khiển
luồng và dùng thủ tục service để xử lý chúng tr−ớc tất cả các thông báo bình
th−ờng trên hàng đợi. Điều này giúp cho các thông báo −u tiên cao đi qua các mô
đun trong thời gian trễ tối thiểu.
Các thông báo bình th−ờng (không −u tiên) đ−ợc đặt tại cuối hàng đợi sau
tất cả các thông báo khác trong hàng đợi. Các thông báo −u tiên có thể là các
thông báo −u tiên cao hay các thông báo băng −u tiên (priority band). Các thông
báo −u tiên cao đ−ợc đặt tại đầu của hàng đợi nh−ng sau tất cả các thông báo −u
tiên cao khác đang tồn tại trong hàng đợi. Các thông báo băng −u tiên cho phép
cung cấp các dữ liệu khẩn đ−ợc đặt trong hàng đợi sau các thông báo −u tiên cao
và tr−ớc cá...