Định tuyến SIP

Một phần của tài liệu Tìm hiểu giao thức SIP và xây dựng ứng dụng minh họa (Trang 48)

Định tuyến SIP là việc xử lý bởi một thực thể SIP để xác định thực thể kế tiếp mà yêu cầu cần chuyển tiếp. Xử lý gồm 2 bước:

• Xác định URI SIP của hop kế tiếp dựa trên header của thông điệp và cấu

hình cũng như logic dịch vụ. URI là nhân tố chính để định tuyến vì nó chứa diễn giải cuối cùng của yêu cầu.

¾Trong trường hợp là UA việc xác định dựa trên URI và header

ROUTE. Nếu có header ROUTE thì URI hop kế tiếp là header ROUTE, nếu không thì URI của hop kế tiếp là URI của yêu cầu.

¾Trong trường hợp proxy nếu có header ROUTE thì lấy header

ROUTE làm URI của hop kế tiếp. Nếu không có header ROUTE và proxy không có quyền trong miền của URI yêu cầu thì URI hop tiếp theo là URI của yêu cầu. Nếu proxy có quyền thì sẽ truy vấn Location service và lấy địa chỉ liên hệ dạng URI.

• Tìm hiểu địa chỉ IP, port và phương thức vận chuyển để đến hop kế tiếp. 5.3. Chỉnh sửa phiên SIP:

Bất kỳ phiên nào cũng có thể chỉnh sửa trong lúc đang diễn ra. Khi UA muốn chỉnh sửa phiên nó tạo ra một INVITE mới với số CALL-ID đang tồn tại. Giá trị TAG không thay đổi do đó dialog ID cũng không đổi. SDP sẽ chứa sự thay đổi thật sự vì

vậy khi nhận được thông điệp INVITE mới UAS sẽ kiểm tra phiên bản SDP và xem

cái gì được chỉnh sửa so với phiên bản gốc. Nếu UAS bên nhận yêu cầu không chấp nhận chỉnh sửa nó gửi 488 NOT ACCEPTABLE HERE và header WARNING sẽ cho biết lý do tại sao. Nếu UAS gửi 200 OK nhưng không nhận được ACK thì nó sẽ gửi BYE và chấm dứt phiên.

5.4. Chấm dứt phiên SIP:

Bất kỳ UA nào cũng có thể chấm dứt phiên. Thông điệp BYE dùng để chấm dứt phiên. Thông điệp BYE cũng chấm dứt dialog giữa 2 thiết bị. Có nghĩa là BYE không gửi bên ngoài của dialog. Nếu không có dialog hay phiên nào được thành lập thì BYE không được sử dụng. Thông điệp CANCEL sẽ dùng trong trường hợp này để hủy yêu cầu trước khi phiên thành lập.

UAC tạo thông điệp và gửi đến UAS, UAS chưa trả lời yêu cầu do đó UAS

không biết yêu cầu nên UAC phải tạo CANCEL để hủy yêu cầu. UAS sẽ gửi 487 REQUEST TERMINATED để trả lời CANCEL.

UA chấm dứt phiên có thể là do người dùng muốn chấm dứt phiên hoặc có lỗi.

Ví dụ UAS gửi 200 OK nhưng không nhận được ACK thì sẽ gửi BYE để chấm dứt

Chương 6: Bảo mật SIP

6.1. Các tấn công mạng:

6.1.1. Registration Hijacking:

SIP sử dụng các thông điệp dạng text rất rõ ràng dễ hiểu vì vậy thông điệp SIP có thể bị bắt và đọc trộm trên mạng. Sau đó hacker có thể sử dụng những thông tin đó để giả dạng user để truy cập vào mạng với tài khoản của user đó. Với tài khoản hợp lệ hacker sau đó có thể thay đổi thông tin đăng ký với registrar và những giao dịch phiên sau đó sẽ chuyển tới hacker thay vì thuê bao người dùng. Một cách thức khác là bắt thông điệp đăng ký của user và gửi lại với địa chỉ đăng ký là của hacker. Sau đó thông tin của phiên sẽ gửi đến hacker.

6.1.2. Session Hijacking:

Loại tấn công này đã bắt đầu với WEB. Khi browser truy cập vào web

server lần đầu ví dụ là một trang mua bán thì phải nhập tên đăng nhập và mật

khẩu. Để tiện dụng cho những lần sau không cần gõ lại tên đăng nhập và mật

khẩu người phát triển WEB tạo ra cookies để lưu dữ liệu trên máy cá nhân của người dùng. Điều này có thể dẫn đến cookies có thể bị copy và hacker sử dụng cookies để giành quyền truy cập vào mạng.

Một cách kiểm tra loại tấn công này là kiểm tra ngày giờ của yêu cầu. Khi UAS nhận được 1 yêu cầu nó so sánh với đồng hồ của nó. Nếu sự chênh lệch quá lớn nó sẽ từ chối yêu cầu.

6.1.3. Impersonating a Server:

Loại tấn công này có thể thấy trên web là hacker sử dụng một trang web giống như trang web thật để người dùng gõ số tài khoản ngân hàng và mật khẩu.

Những thông tin này có thể được lưu lại và bán trên mạng. Hacker có thể lừa

người dùng vào trang web giả đó bằng nhiều cách hoặc xâm nhập vào DNS và thay đổi tên miền chỉ đến trang web giả mạo. Trong mạng SIP cũng xảy ra tình trạng như vậy và thuê bao bị chuyển đến server ứng dụng giả mạo làm ảnh hưởng đến thuê bao.

6.1.4. Tampering with Message Bodies:

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.

Một phần của tài liệu Tìm hiểu giao thức SIP và xây dựng ứng dụng minh họa (Trang 48)

Tải bản đầy đủ (PDF)

(64 trang)