Thân của thông điệp SIP là dạng text do đó nếu hacker bắt được thông điệp, hacker có thể thay đổi nội dung thông điệp. Điều này thực sự rắc rối nếu thông điệp được gửi bởi chính phủ.
6.1.6. Denial of Service and Amplification:
Tấn công DoS có nhiều cách khác nhau. Một cách đơn giản là làm ngập lụt mạng. sử dụng bộ tạo yêu cầu hacker sẽ tạo ra hàng triệu yêu cầu INVITE và gửi cho server làm server không thể xử lý kịp và sẽ từ chối phục vụ những yêu cầu thật sự. Cách tấn công DoS khác là tấn công DNS server. Khi DNS server bị tấn
công và từ chối phục vụ thì những server có địa chỉ được lưu trữ trong DNS
server sẽ bị ảnh hưởng do không phân giải được tên miền.
6.1.7. Bots and DDoS Attacks:
Bot là những đoạn mã nằm trên các thiết bị của người dùng. Khi người
dùng kết nối mạng, bot có thể tự mở cổng và lây lan qua các thiết bị khác.
Bot cũng có thể được điều khiển từ xa thông qua một server. Bot sử dụng
giao thức Internet Relay Chat (IRC) để giao tiếp với URL đã được lập trình
thành những đoạn mã.
Nhiều Bot sử dụng để tăng số lần truy cập vào một website hay một liên kết trên website nhằm kiếm tiền trên cơ sở số lần truy cập vào website. Khi hacker kiểm soát được nhiều bot thì tập hợp những bot này nằm dưới sự điều khiển của một người, những bot này gọi là botnet. Botnet có thể tấn công DoS làm tê liệt hệ thống.
6.2. Giải pháp bảo mật:
Để ngăn chặn những tấn công đã mô tả những dịch vụ bảo mật cần thiết cung cấp bởi SIP là:
• Authentication: là quy trình để xác thực một người trong mạng SIP.
• Integrity: Dùng để khẳng định rằng thông điệp SIP không bị chỉnh sửa.
• Confidentiality: Đảm bảo những thông tin nhạy cảm không bị tiết lộ tới bên thứ ba. Cái này được thực hiện bởi việc mã hóa.
Để bảo mật SIP các kỹ thuật sau được sử dụng: 6.2.1. Network-layer security (IPSec):
IPSec là tập hợp những giao thức mạng phát triển bởi IETF để hỗ trợ bảo mật trong việc trong đổi các gói ở mức mạng. Dịch vụ IPSec hỗ trợ là:
Xác thực.
Bảo đảm dữ liệu tin cậy.
Bảo vệ sự toàn vẹn dữ liệu.
IPSec có thể hoạt động trong hai chế độ:
Chế độ transport:
Trong chế độ này nó đưa ra sự bảo vệ cho những giao thức lớp trên là lớp transport như UDP,TCP..
Chế độ tunnel:
Trong chế độ này nó đưa ra sự bảo vệ cho IP header và tạo tunnel giữa hai gateway bảo mật.
IPSec có thể sử dụng kỹ thuật khóa public hay khóa được thống nhất trước chứa trong gateway hoặc host. Để cài đặt trao đổi khóa IPSec sử dụng giao thức IKE.
Hai mô hình SIP tiêu biểu trong IPSec là:
Giao tiếp bảo mật giữa hai nút hay hai mang SIP:
Trong trường hợp này gateway hoặc host cần có khóa chia sẻ
trước hoặc có thể truy cập vào cấu trúc khóa public. Hình sau mô tả mô hình này:
Giao tiếp bảo mật giữa UA và mạng SIP:
Trong trường hợp này user có khóa bí mật chứa đựng trong smart
card. Sự xác thực và đồng ý khóa được thực hiện qua giao thức AKA (Authentication and Key Agreement).
IPSec sử dụng những giao thức khác nhau để bảo mật mức gói cho IP.
này chỉ server được xác thực bằng TLS. Trong trường hợp này cần một bộ máy xác thực người dùng khác. TLS cung cấp ba giai đoạn cơ bản:
Thương lượng sự mã hóa và thuật toán toàn vẹn dữ liệu.
Trao đổi khóa và sử dụng kỹ thuật khóa public.
Di chuyển sự mã hóa sử dụng symmetric cipher.
Hai mô hình SIP sử dụng TLS là:
Giao tiếp bảo mật giữa hai nút kế nhau:
Hai proxy SIP có thể có hai kết nối TLS, mỗi cái cho một hướng di chuyển. Cả hai có những chứng chỉ bảo mật và sự xác thực có thể thực hiện.
Giao tiếp bảo mật giữa UA và mạng SIP:
Trong trường hợp này server proxy sở hữu một chứng chỉ và UA
xác thực server bằng cách kiểm tra nó. TLS đưa ra sự tin cậy, toàn vẹn và xác thực dữ liệu. Cho xác thực client một bộ máy khác được sử dụng.
6.2.3. SIPS URI scheme:
Định dạng SIPS URI cũng định nghĩa một URI bảo mật. SIPS URI là như SIP URI ngoại trừ SIPS sẽ thay cho SIP.
sips: abc@xyz.com
SIPS URI xác định một tài nguyên cần bảo mật với TLS. SIPS URI có
thể sử dụng cho user hoặc server.
Khi sử dụng như là một AOR một yêu cầu SIP hướng SIPS URI sẽ được
bảo vệ bằng cách sử dụng TLS từ người khởi tạo đến domain của người nhận. Trong domain của người nhận yêu cầu sẽ được phân phối với sự bảo mật. Nhưng
bộ máy bảo mật sẽ phụ thuộc vào domain người nhận. Khi được sử dụng để xác định server, SIPS URI chỉ ra TLS sẽ được sử dụng.
6.2.4. HTTP authentication:
HTTP authentication sử dụng hai header sau để thực hiện chức năng này:
• WWW-Authenticate Header:
WWW-Authenticate header chứa đựng sự thách thức tạo bởi server và thực hiện lược đồ xác thực theo các tham số. Các tham số xác thực chính là:
¾Nonce:
Một chuỗi dữ liệu chỉ rõ server sẽ được tạo mỗi lúc response 401 được thành lập.
¾Realm:
Trong SIP tham số này xác định domain bảo vệ.Có nghĩa là UAs phải biết username và password họ dùng. Khi response 401 được nhận UAs có thể trình bày tham số realm đã nhận trong header WWW-
Authenticate Header vì vậy người dùng có thể đưa ra username và
password đúng.
¾qop-options:
Nó có hai giá trị “auth” và “auth-int”. “auth” chỉ rõ sự xác thực và “auth-int” là xác thực kèm với sự toàn vẹn dữ liệu.
¾opaque:
Một chuỗi dữ liệu chỉ rõ bởi server sẽ trả lại bởi client không thay đổi trong Authorization header. Nó được sử dụng để vận chuyển thông tin tình trạng phiên.
• Authorization Header: Có các tham số sau:
¾Response:
Một chuỗi 32 ký tự thập lục để chứng minh người dùng biết mật khẩu.
¾Username:
Username trong realm.
¾Realm:
Xác định realm trong credentials đã cung cấp.
¾Nonce:
6.2.5. S/MIME:
Thông điệp SIP có thể mang thân MIME. Chuẩn MIME bao gồm bộ
máy bảo mật nội dung. Nó gọi là S/MIME, nó cung cấp sự xác thực tin cậy và toàn vẹn dữ liệu.
Ví dụ:
Ví dụ này sẽ sử dụng TLS với xác thực HTTP là phương thức chung nhất của bảo mật SIP. Khi user bắt đầu họ sẽ khởi tạo thủ tục đăng ký. Để tránh việc tấn côn hijack việc đăng ký user phải thành lập nối kết TLS với server registrar. Sau đó việc bắt tay TLS sẽ diễn ra. Tiếp theo là UA và server sẽ trao đổi khóa mã hóa và thuật toán mã hóa và toàn vẹn dữ liệu. Cuối cùng sau khi các bước trên được thực hiện, UA có thể giao tiếp với registrar.
Sau đó UA sẽ tạo request REGISTER và gửi yêu cầu này trên nối kết TLS. Yêu cầu sẽ bị từ chối bởi registrar với response 401 (Unauthorized) để UA phải xác thực. Response 401 (Unauthorized) sẽ bao gồm yêu cầu phải xác thực trong header WWW-Authenticate. UA sau đó sẽ gửi yêu cầu REGISTER bao gồm
header Authorization chứa đựng thông tin xác thực. Nếu việc kiểm tra được
Khi nối kết TLS được thành lập INVITE được gửi đến Proxy.ocean.com. Proxy này sẽ thấy Resquest URI sẽ nằm trong domain của nó và truy vần location service và xác định nơi INVITE được gửi đến.
Phần III:
Cài đặt giao thức và xây dựng ứng dụng minh họa giao thức SIP
Chương 7:
Cài đặt giao thức và xây dựng ứng dụng LEO 7.1. Thư viện lớp SIP:
7.1.1. Các thành phần của thư viện:
• Các Collections:
Header Collection: Sử dụng một từ điển chứa các đối tượng
Header. Có chứa các phương thức thêm, xóa, tìm kiếm header.
HeaderValueCollection: Sử dụng một danh sách để chứa các giá trị
của header.
ParameterCollection: Sử dụng một từ điển chứa các tham số của
header.
• Các lớp:
Trong namespace System.Net.Sip có các lớp:
¾Dialog: Dùng để tạo và quản lý dialog của một phiên từ một
request hay response.
¾DialogStates: Chứa tình trạng của Dialog.
¾MessageReceivedEventArgs: Dùng để tạo các tham số của sự
kiện nhận thông điệp.
¾MessageSentEventArgs: Dùng để tạo các tham số của sự kiện
gửi thông điệp.
¾Lớp trừu tượng transport: là cơ sở chung cho các lớp cài đặt cụ thể là UdpTransport và TcpTransport
¾TransportProtocol: Chứa tên các giao thức. 1. TransportStateException: Chứa các lỗi transport.
Trong namespace System.Net.Sip.Headers có các lớp là tên các
header và value của header dùng để cài đặt các đối tượng header và giá trị các header đó.
Trong namespace System.Net.Sip.Messages có các lớp:
¾Lớp trừu tượng Messages: là cơ sở chung của các lớp Request và
7.2. Mô tả ứng dụng:
7.2.1. Tổng quan về ứng dụng:
Ứng dụng học anh văn trực tuyến:
• Tên ứng dụng:LEO (Learning English Online).
• Mục đích: Minh họa giao thức SIP.
• Đặc điểm:
Ứng dụng LEO dùng để minh họa giao thức SIP. Cho mục đích minh họa Leo chỉ có một số chức năng đơn giản để tạo và chỉnh sửa phiên.
7.2.2. Môi trường xây dựng:
Môi trường xây dựng ứng dụng LEO là C#. Việc sử dụng C# là vì những lý do như:
• C# là một ngữ lập trình hướng đối tượng nên nó có đặc điểm là dễ viết
mã chỉnh sửa và nâng cấp.
• C# là ngôn ngữ hỗ trợ nhiều về lập trình mạng. Nó có sẵn nhiều gói dùng cho lập trình mạng.
• C# có thể dễ dàng nhúng các đối tượng multimedia vào form khi lập
trình.
7.3. Cấu trúc ứng dụng:
7.3.1. Thành phần của ứng dụng:
Ứng dụng gồm 2 phần: client và server.
• Client:
Giao diện Client gồm có 3 form:
¾Form chính Learning English Online: Form này gồm có menu để
tạo form cấu hình, tạo, chỉnh sửa và chấm dứt phiên. Ngoài ra form còn dùng để chọn bài học và một khung để xem nội dung.
¾Form cấu hình: Form này để thiết lập các thông số của ứng dụng
bao gồm địa chỉ IP và port lắng nghe của server.
¾Form tạo và chỉnh sửa phiên: From này dùng để tạo yêu cầu
INVITE với quyền chọn loại media.
Các lớp:
¾Lớp Config: Dùng để lưu giữ và chỉnh sửa thông số server tại
client.
¾Lớp Session: Dùng để tạo và chỉnh sửa phiên.
¾Lớp LEO: dùng để xử lý các response và xem nội dung của các file
media được gửi từ server.
• Server:
Giao diện server gồm có form chính để hiển thị thông tin giao tiếp.
Lớp LEOServer: Dùng để xử lý các request và hiển thị thông tin giao
tiếp từ client.
• Project SIP:
Là thư viện dùng chung cho client và server đã cài đặt như phần 7.1. 7.4. Giao diện người dùng và cấu hình:
7.4.1. Giao diện người dùng:
Client có các form sau:
• Form tạo phiên:
Server có form sau:
7.4.2. Cấu hình:
• Port: Cổng lắng nghe trên server. 7.5. Xử lý logic của ứng dụng:
Do mục đích minh họa. Ứng dụng sẽ thực hiện những chức năng đơn giản như tạo phiên, chỉnh sửa phiên và chấm dứt phiên. Quy trình thực hiện như sau:
• User sẽ cấu hình địa chỉ và port của server.
• Ứng dụng sẽ lưu xuống client để lần sau sử dụng.
• User sẽ tạo phiên với các thông tin như loại media.
• Ứng dụng client sẽ tạo yêu cầu INVITE gửi đến server.
• Server tạo response và gửi lại client.
• User sẽ chọn bài học và xem nội dung.
• User chỉnh sửa phiên.
• User sẽ chọn bài học và xem nội dung.
• User chấm dứt phiên.
• Ứng dụng gửi yêu cầu BYE đến server.
• Server tạo response và gửi đến client.
Nhận xét đánh giá
Giao thức SIP là một giao thức khá mới (bản dự thảo đầu tiên cho giao thức SIP xuất hiện vào tháng 12/1996) nhưng với cú pháp rõ ràng dễ hiểu cũng như vai trò quan trọng của nó mà hiện nay rất nhiều tổ chức đã sử dụng nó như là giao thức tín hiệu chủ yếu. Có thể nói rằng SIP là một giao thức tín hiệu với vai trò khởi tạo, chỉnh sửa và quản lý phiên phổ biến nhất trên thế giới. Sự ra đời của nó không loại bỏ những giao thức khác mà với tính tương thích cao nó sử dụng để hỗ trợ các giao thức khác nhằm đạt kết quả tốt nhất trong truyền thông.
Vì những đặc điểm ưu việt như vậy mà giao thức SIP đã được chuẩn hóa bởi tổ chức IETF (The Internet Engineering Task Force – một tổ chức chịu trách nhiệm chính
với việc định nghĩa các chuẩn Internet) trong RFC 3261. Hiện nay IETF có một đội
ngũ chuyên chỉnh sửa và phát triển SIP là SIP WG(Session Initiation Protocol Working Group).
Trong luận văn này với những hiểu biết cơ bản về giao thức SIP mục tiêu của em chỉ là tìm hiểu giao thức này và cụ thể hóa những hiểu biết của mình về giao thức SIP bằng cách cài đặt thư viện lớp SIP theo những chuẩn hóa của RFC 3261 và viết ứng dụng minh họa hoạt động theo giao thức SIP.
Với một giao thức được chuẩn hóa như vậy thì tương đối là dễ hiểu và thống nhất so với những giao thức chưa được chuẩn hóa, nhưng đối với em nó cũng là mới lạ nên cũng khó tránh khỏi những khó khăn khi tiếp cận với giao thức này. Với phần trình
bày đề tài của mình tuy là chưa đầy đủ toàn bộ về giao thức SIP nhưng nó cũng thể
hiện được một phần hiểu biết của em về giao thức này.
Với những hành trang như vậy trong tương lai em sẽ tìm hiểu sâu hơn về giao thức này vì hiện nay nó khá phổ biến và tương lai có lẽ sẽ sử dụng nó nhiều trong truyền thông.
Tài liệu tham khảo
[1] RFC 2543 SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E.
Schooler, J. Rosenberg. March 1999.
[2] RFC 3261 SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G.
Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. June 2002.
[3] www.w3c.org.
[4] JSR 22 JAIN SLEE API specifi cation [5] JSR 32 JAIN SIP API specifi cation
[6] JSR 116 SIP Servlet API
[7] JSR 135 Mobile Media API
[8] JSR 165 SIMPLE Instant Messaging
[9] JSR 180 SIP API for J2ME
[10] JSR 240 JAIN SLEE v 1.1
[11] JSR 289 SIP Servlet v 1.1
[12] JSR 309 Media Server Control API
[13] JSR908 Java Media Framework 2.2.1
[14] SESSION INITIATION PROTOCOL (SIP) Controlling Convergent Networks
Travis Russell.